git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 12, 2007, 07:26 UTC
Message-ID
<7vhcjr53hp.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20071112062222.GA17462@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
Show 8 quoted lines
> 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.

Previous: Theodore TsoNext: Mike Hommey
Message 21 of 29 in “Deprecate git-fetch-pack?”
  1. Daniel BarkalowNov 10, 2007
  2. Junio C HamanoNov 11, 2007
  3. Ask Bjørn HansenNov 11, 2007
  4. Johannes SchindelinNov 11, 2007
  5. Junio C HamanoNov 11, 2007
  6. Theodore TsoNov 11, 2007
  7. Junio C HamanoNov 11, 2007
  8. Johannes SchindelinNov 11, 2007
  9. Theodore TsoNov 11, 2007
  10. Jakub NarebskiNov 12, 2007
  11. Jon LoeligerNov 12, 2007
  12. Johannes SchindelinNov 12, 2007
  13. Jon LoeligerNov 12, 2007
  14. Johannes SchindelinNov 12, 2007
  15. Jon LoeligerNov 12, 2007
  16. 1/2 Make the list of common commands more exclusiveTheodore Ts'o, Nov 12, 2007
  17. 2/2 Remove hint to use "git help -a"Theodore Ts'o, Nov 12, 2007
  18. Junio C HamanoNov 12, 2007
  19. Ping YinNov 12, 2007
  20. Theodore TsoNov 12, 2007
  21. Junio C HamanoNov 12, 2007
  22. Mike HommeyNov 12, 2007
  23. Johannes SchindelinNov 12, 2007
  24. Ask Bjørn HansenNov 12, 2007
  25. Andreas EricssonNov 12, 2007
  26. Theodore TsoNov 12, 2007
  27. Andreas EricssonNov 12, 2007
  28. Ask Bjørn HansenNov 12, 2007
  29. Mike HommeyNov 11, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.