Re: EasyGit Integration

[Junio C Hamano <gitster@pobox.com>]

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".

>> 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).