Re: EasyGit Integration

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 10, 2009, 20:47 UTC
Message-ID: <7vab4fn7dm.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.0906092252210.31536@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

> On the other hand, having multiple porcelains simply divide the user 
> base which is not always a good thing.

The addition of new synonymous commands or options has the same issue of dividing the user base between revert-commit/revert-file folks and revert/checkout people. In addition, it has the subcommand bloat issue I already mentioned. If anything, we should be aiming for _reducing_ them from the current set of ~150; it is silly to dismiss it, saying "one extra added to 150 is less than 1%".

As long as the "fork" is feature complete and the user does not have to resort to git-core, even though it may share the same issue of user base division, at least that would _help_ the users who choose the forked one, who does not have to know the old-timer lingo and concepts. It would be a much better solution than adding stupid synonyms to the existing system.

But coming up with a consistent and complete fork that does not show git-core (not just phrases but also underlying concepts) is a lot of work. That is the primary reason why nobody did "gh".

Show 7 quoted lines

>> But aliases for doing essentially the same thing in slightly different
>> syntax?  I'd rather not to see them called "git foo".  In the end, I think
>> it will harm the users, both new and old.
>
> Again this should be evaluated on a case by case basis.  I think this is 
> clear already that re-targeting commands like revert is _not_ a good 
> idea.  But some other examples are not so controversial.

I do not think there is any disagreement here; each proposal must be judged separately, and no backward compatibility is allowed, unless there is a compelling reason, a clear migration plan, and understanding of how expensive such a backward incompatibility is by all the parties involved.

I do not see how "git branch -s" is an improvement, unless our motto is "we will support any and all conceivable permutations of what is done to what". It says "while creating a branch, switch to it". We say "while switching to a new commit, start a branch by given name there".

I'd throw it into "if we did not have X in the beginning, instead of adding X, we could have added Y and it would have worked equally well" category.

But we already have X.

A rule of thumb I use for judging such a case is that Y must be at least 10 times better than X to replace it, and that has to happen with some deprecation period. Supporting Y in addition to X may probably have lower hurdle, but still Y must be much better than X for that to happen.

If "git resolved" is "git add $(git ls-files -u --name-only)" or even more than that (say, check if the files from the work tree indeed have lost conflict markers), I think that is a wonderful improvement. It does not even fall into the "Y would have worked equally well but we have X" category, as it is something different from the existing command, and does it better (if it works as advertised without funny corner cases, that is).