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

Re: git-scm.com refresh

From
Felipe Contreras <felipe.contreras@gmail.com>
Date
May 6, 2012, 02:31 UTC
Message-ID
<CAMP44s28Xy4PB-k33RYU=W2Wa+SLs7GDkhr=DohUP_hqr5ur9Q@mail.gmail.com>
In-Reply-To
<7vwr4q6qbh.fsf@alter.siamese.dyndns.org>
On Sun, May 6, 2012 at 3:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 32 quoted lines
> Scott Chacon <schacon@gmail.com> writes:
>
>>> As "diff" is listed in "Basic Snapshotting", and it will not
>>> be able to achieve that without being able to apply its output back to the
>>> working tree or to the index, I would suggest moving "apply" to the
>>> section as well.
>>
>> I have to disagree.  You are thinking of 'apply' from an internals
>> perspective I have to assume, because I use 'diff' every single day
>> for all sorts of stuff ("what is modified and unstaged?", "what is
>> modified and staged?", "what is different between these two branches?"
>> etc) ...
>
> The other day when I was surfing the 'net, I found a blog that was
> complaining about Git UI.  Some of the things were worth listening to, but
> there was one item I really had to scratch my head where the misconception
> behind the complaint came from.  I am typing from memory without bothering
> to go back to the site to quote, but the complaint essentially was:
>
>        Getting a patch is easy with "git diff", but to apply it you need
>        to make it an email and feed it to "git am"???  That's crazy.
>
> Of course it *is* crazy, if that were the case. I was wondering why the
> obvious "patch" (or "git apply") did not get into the mind of the author,
> and I think I now know why.
>
> If the owner of the site that people call "git's home page" does not care
> about those who take diffs and apply them as patches, and thinks "git
> apply" as a mere implementation detail of "git am", it is understandable
> that such a misconception is spread widely to harm users without getting
> corrected. Who knows other Git fanboys are spreading misinformation in a
> similar way. Sigh...

So you think moving "git apply" to another section there is going to fix the problem? And what is the problem? That some random guy in a blog post thinks it's crazy to use 'git format-patch' and 'git am'? I don't think that's a problem worth worrying about, and I don't think it's crazy.

Who cares if people don't know about "git apply"? I too have used it very rarely, and almost every time I gave up. It's not really useful because if there are conflicts (and there usually are), the thing just fails, and 'git apply --reject' (horrible name BTW; apply and reject a patch?) is too cumbersome. It's much easier to just avoid it.

Show 13 quoted lines
>> ... where I can't think of a single time I've ever used 'apply'.  In
>> fact, even the times when I have needed to apply a patch generated
>> from 'diff' I used 'patch -p1' because I know it better.
>
> As you are supposed to be one of the top-level Git Teachers, I wish you
> knew better.  Here is a free Git lesson.  Consider "git apply" as
>
>    a better version of "patch" that knows how to work better with Git by
>    understanding rename and binary patches, and allows them to be applied
>    to the working tree and the index (the latter is most useful when the
>    patch contains new files)
>
> and teach it as such.
It's still basically useless.
> "diff" pairs with "apply", and "format-patch" pairs with "am".

A contributor uses 'format-patch' often, a maintainer uses 'am' often, but who uses 'apply'? Nobody. Who uses 'diff'? Everybody.

'git diff' is *essential* to see what's going on with the staging area, and the working directory.

When do you actually *need* 'git apply'? Never; you can always achieve the same in different ways probably much easier.

> I wouldn't mind adding "git patch" as a built-in synonym/alias for "git
> apply", if you think that would make the above pairing more obvious.  Many
> computer users know what "patch" does already even they have never used
> any SCM.

'git patch' would certainly make more sense, but even more would be to make it actually usable so mergetool could be used in case of conflicts, or even just having the typical conflict markers.

But even with all that, it still wouldn't be as essential as 'git diff'.
Cheers.
-- 
Felipe Contreras
Previous: Junio C HamanoNext: Scott Chacon
Message 9 of 28 in “git-scm.com refresh”
  1. Scott ChaconMay 4, 2012
  2. Jakub NarebskiMay 5, 2012
  3. Scott ChaconMay 5, 2012
  4. Josh JuranMay 5, 2012
  5. Junio C HamanoMay 5, 2012
  6. Felipe ContrerasMay 5, 2012
  7. Scott ChaconMay 5, 2012
  8. Junio C HamanoMay 6, 2012
  9. Felipe ContrerasMay 6, 2012
  10. Scott ChaconMay 6, 2012
  11. Philip OakleyMay 6, 2012
  12. Junio C HamanoMay 7, 2012
  13. Junio C HamanoMay 8, 2012
  14. Andreas SchwabMay 8, 2012
  15. Junio C HamanoMay 8, 2012
  16. Andrew SayersMay 5, 2012
  17. Felipe ContrerasMay 5, 2012
  18. Philip OakleyMay 5, 2012
  19. Neal KreitzingerMay 6, 2012
  20. Neal KreitzingerMay 6, 2012
  21. Matthieu MoyMay 6, 2012
  22. Scott ChaconMay 6, 2012
  23. Christian CouderMay 7, 2012
  24. Ævar Arnfjörð BjarmasonMay 7, 2012
  25. A Large Angry SCMMay 7, 2012
  26. Matthieu MoyMay 7, 2012
  27. Heiko VoigtMay 9, 2012
  28. Antonio OspiteMay 8, 2012

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.