Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive

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

Theodore Tso <tytso@mit.edu> writes:

> On Sun, Nov 11, 2007 at 06:21:44PM -0800, Junio C Hamano wrote:
> ...
>> I am fine with this list, perhaps except apply.
>
> I was borderline on apply, but given that people are familiar with
> patch -p1, the only real advantage git-apply has is that automatically
> deals with new files (which "git commit -a" or "git add -u" won't
> automatically get).

Although more importantly git-apply is much more strict and
safer than patch by default, that distinction will probably not
register with total newbies; not much would be lost if we do not
list git-apply, I'd guess.

> What did you think about cherry-pick?  Was that omitted by accident?

As "git show | git apply --index" would be good enough for
simple projects, omission of git-cherry-pick is not as serious
compared to ommission of git-revert, whose alternatives would be
"commit --amend" and "rebase" which are not suitable for
published history.

> My mental model for git newbies is that they would probably be pulling
> from upstream repositories (so I was tempted to remove git-init from
> the common commands list), but they would rarely be cherry-picking or
> reverting other people's changes.

I'd agree with that, but reverting and cherry-picking would also
be done on the commits the user builds on top of other people's
changes.

> They probably would be submitting changes back upstream using e-mail
> before they learn how to publish their own repository, so commands I'd
> be tempted to add would include git-format-patch, git-send-email, and
> git-cherry.  But these commands are pretty complicated for beginners....

I'd half agree with that.  People coming from CVS workflow will
be pushing and pulling from their central repositories, without
format-patch and send-email.  For them revert would matter more
together with fetch, rebase and push.