Theodore Tso <tytso@xxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
