Thread (35 messages) flat view 35 messages, 13 authors, 2016-06-15

Re: [kernel.org users] [RFD] On deprecating "git-foo" for builtins

From: Jakub Narebski <hidden>
Date: 2016-06-15 22:45:15

Perry Wagle [off-list ref] writes:
On Aug 28, 2008, at 2:59 PM, Jeff King wrote:
quoted
quoted
I now have to TEST to find those crazy backwards-incompatibility
bugs before I can upgrade us to 1.6.0.  To test, I have to try to
imagine what I and others were assuming about git.  And this
episode means that I can't make any assumptions about the sanity
of any changes since March, which is the version I'm thinking of
upgrading.

But note that THIS upward compatibility bug has been declared to
not be a bug.  Will any others receive the same stamp?

So please put on your engineer hat, and stop talking about "specious
claims" and hurting feelings.
quoted
 - there has been _one_ such problem, and the person responsible for
   vetting such changes has solicited suggestions for doing better in
   the future. I don't think that is indicative of a pattern of such
   changes.
Ok.  My suggestion is that it shouldn't have been done in the first
place, and we should now revert.  But others are saying over and over
"its done!  live with it!".  I came in late.  What did I miss in the
last 6 months.  Sounds like people have lots of practice with these
water-over-the-dam's, surely this isn't the first time?
Errr... what last 6 months? Using "git <cmd>" over "git-<cmd>"
(also in scripts) was recommended for a long, long time' much more
than those 6 months.

Besides, the question stated in this thread was not whether to move
"git-*" commands outside $(bindir) (usually '/usr/bin'), but whether
to not create or not links (or symlinks, or hardcopy) in gitexecdir.
 
quoted
 - But let's say you have lost some faith in the git development
   process due to _this_ bug. But let's look at the history of this
   bug. It has been discussed several times for the past 2 years, along
   with a mention in the release notes several versions ago. It was not
   a surprise to anybody who has been developing git.
In March 2008, the sample git-hooks and git-web used git<DASH>
commands.  That was the last I looked at git until Tuesday of this
week.
As I said earlier in this thread, if by git-web you mean gitweb this
is simply not true.  _At least_ since commit 25691fb (gitweb: Use
--git-dir parameter instead of setting $ENV{'GIT_DIR'}) gitweb used
dashless form.
But I think I'll still remain wary because 1.6 introduced a nearly
complete renaming of the API for what, in this thread anyway,
completely silly reasons.  If there are good reasons, I haven't seen
them.
IIRC the reasons are git wrapper options linke --paginate or
--git-dir, equal treatment of git aliases, and cluttering of bindir
(which might be ~/bin).

-- 
Jakub Narebski
Poland
ShadeHawk on #git
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help