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

Re: [RFC/PATCH 1/2] Introduce CHERRY_HEAD

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Feb 15, 2011, 23:08 UTC
Message-ID
<20110215230859.GB17812@elie>
In-Reply-To
<7v4o84nbuh.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
Show 5 quoted lines
>> I wonder if cherry-pick shouldn't also write MERGE_MSG or similar so
>> that gets taken care of automatically?  That would also allow options
>> like -x and -m to work better.
>
> Hm, that probably is a good idea.
Turns out it already does. :)
>> +++ b/Documentation/git-cherry-pick.txt
>> @@ -16,6 +16,25 @@ Given one or more existing commits, apply the change each one
[...]
Show 17 quoted lines
>> +When it is not obvious how to apply a change, the following
>> +happens:
>> +
>> +1. The current branch and `HEAD` pointer stay at the last commit
>> +   successfully made.
>> +2. The `CHERRY_HEAD` ref is set to point at the commit that
>> +   introduced the change that is difficult to apply.
>> +3. Paths in which the change applied cleanly are updated both
>> +   in the index file and in your working tree.
>> +4. For conflicting paths, the index file records up to three
>> +   versions, as described in the "TRUE MERGE" section of
>> +   linkgit:git-merge[1].  The working tree files will include
>> +   a description of the conflict bracketed by the usual
>> +   conflict markers `<<<<<<<` and `>>>>>>>`.
>
> What happened to the `=======`?  I thought you were copying and pasting
> from the said section.
Hmm, maybe as a temporary cop-out:
	What it is not obvious how to apply a change, the following
	happens:
	1. The current branch ...
	...
	3. Paths in which the change applied cleanly are updated both
	   in the index file and in your working tree.
	4. For conflicting paths, the index file and working tree
	   files record a description of the conflict, as described
	   in the "TRUE MERGE" section of linkgit:git-merge[1].

I didn't want to copy and paste wholesale to avoid dull reading and to avoid the two copies falling out of sync. Maybe there should be a page on conflicts and their resolution for git-merge(1), git-rebase(1), git-cherry-pick(1), and git-revert(1) to refer to?

Previous: Jay SoffianNext: Jay Soffian
Message 10 of 27 in “CHERRY_HEAD”
  1. 0/2 CHERRY_HEADJay Soffian, Feb 15, 2011
  2. 1/2 Introduce CHERRY_HEADJay Soffian, Feb 15, 2011
  3. Junio C HamanoFeb 15, 2011
  4. Jonathan NiederFeb 15, 2011
  5. Junio C HamanoFeb 15, 2011
  6. Bert WesargFeb 15, 2011
  7. Junio C HamanoFeb 15, 2011
  8. Bert WesargFeb 15, 2011
  9. Jay SoffianFeb 15, 2011
  10. Jonathan NiederFeb 15, 2011
  11. 2/2 Teach commit to handle CHERRY_HEAD automaticallyJay Soffian, Feb 15, 2011
  12. Jay SoffianFeb 15, 2011
  13. Junio C HamanoFeb 15, 2011
  14. Jonathan NiederFeb 15, 2011
  15. Jay SoffianFeb 15, 2011
  16. Jonathan NiederFeb 15, 2011
  17. Jay SoffianFeb 16, 2011
  18. Jonathan NiederFeb 16, 2011
  19. Documentation: clarify interaction of --reset-author with --authorJonathan Nieder, Feb 16, 2011
  20. Junio C HamanoFeb 16, 2011
  21. Ævar Arnfjörð BjarmasonFeb 15, 2011
  22. Junio C HamanoFeb 15, 2011
  23. Jay SoffianFeb 15, 2011
  24. Ævar Arnfjörð BjarmasonFeb 15, 2011
  25. Jay SoffianFeb 15, 2011
  26. Miles BaderFeb 16, 2011
  27. Christian CouderFeb 17, 2011

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.