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

Jonathan Nieder [off-list ref] writes:

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.

What happened to the `=======`?  I thought you were copying and pasting
from the said section.

On Tue, Feb 15, 2011 at 23:59, Junio C Hamano [off-list ref] wrote:

Jonathan Nieder [off-list ref] writes:

quoted

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.

quoted

diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 749d68a..e8db99b 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt

@@ -16,6 +16,25 @@ Given one or more existing commits, apply the change each one

 introduces, recording a new commit for each.  This requires your
 working tree to be clean (no modifications from the HEAD commit).

+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.

I think this is clear enough, else you would need to mention the
'|||||||' and conflict_marker_size too.

Bert

On Tue, Feb 15, 2011 at 5:59 PM, Junio C Hamano [off-list ref] wrote:

Jonathan Nieder [off-list ref] writes:

quoted

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.

I must not understand what either of you is asking. MERGE_MSG is
written by cherry-pick already, it's just that it's ignored if you use
commit -c, as cherry-pick advises. (Before this patch series anyway.)

j.

Junio C Hamano wrote:

Jonathan Nieder [off-list ref] writes:

quoted

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. :)

quoted

+++ b/Documentation/git-cherry-pick.txt

@@ -16,6 +16,25 @@ Given one or more existing commits, apply the change each one

[...]

quoted

+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?