Re: [Q] merge squash unexpected conflicts

Cory Sharp [off-list ref] writes:

Am I doing something a little wrong or unexpected?  Is there a way
around this squash conflict behavior?  This doesn't seem to happen
with plain merge without squash.

Of course.  That's the whole point of recording a merge as a merge.

On Wed, May 13, 2009 at 8:21 PM, Junio C Hamano [off-list ref] wrote:

Cory Sharp [off-list ref] writes:

quoted

Am I doing something a little wrong or unexpected?  Is there a way
around this squash conflict behavior?  This doesn't seem to happen
with plain merge without squash.

Of course.  That's the whole point of recording a merge as a merge.

$ git help merge

  --squash
           Produce the working tree and index state as if a real merge
happened. ... This allows you to create a
           single commit on top of the current branch whose effect is
the same as merging another branch.

Cory Sharp venit, vidit, dixit 14.05.2009 05:57:

On Wed, May 13, 2009 at 8:21 PM, Junio C Hamano [off-list ref] wrote:

quoted

Cory Sharp [off-list ref] writes:

quoted

Am I doing something a little wrong or unexpected?  Is there a way
around this squash conflict behavior?  This doesn't seem to happen
with plain merge without squash.

Of course.  That's the whole point of recording a merge as a merge.

$ git help merge

  --squash
           Produce the working tree and index state as if a real merge
happened. ... This allows you to create a
           single commit on top of the current branch whose effect is
the same as merging another branch.

The problem is simply in the "...". You cut out the vital part:


        but do not actually make a commit or
        move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
        cause the next `git commit` command to create a merge
        commit.

See? Tree: yes, index: yes, merge info: no.

Git does perform a (tree) merge with --squash, but records the resulting
tree as an ordinary non-merge commit (with a single parent).

I'm not sure whether the statement about the index is completely
correct, though. During a merge the index records info about the merge
(stages :1: etc.) but that as missing with --squash. Only the resulting
tree is added to the index. How about the below?

Michael

diff --git a/Documentation/merge-options.txt

b/Documentation/merge-options.txt
index 637b53f..adadf8e 100644

--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt

@@ -39,7 +39,8 @@

 --squash::
        Produce the working tree and index state as if a real
-       merge happened, but do not actually make a commit or
+       merge happened (except for the merge information),
+       but do not actually make a commit or
        move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
        cause the next `git commit` command to create a merge
        commit.  This allows you to create a single commit on

On Thu, May 14, 2009 at 5:17 AM, Michael J Gruber
[off-list ref] wrote:

Cory Sharp venit, vidit, dixit 14.05.2009 05:57:

quoted

On Wed, May 13, 2009 at 8:21 PM, Junio C Hamano [off-list ref] wrote:

quoted

Cory Sharp [off-list ref] writes:

quoted

Am I doing something a little wrong or unexpected?  Is there a way
around this squash conflict behavior?  This doesn't seem to happen
with plain merge without squash.

Of course.  That's the whole point of recording a merge as a merge.

$ git help merge

  --squash
           Produce the working tree and index state as if a real merge
happened. ... This allows you to create a
           single commit on top of the current branch whose effect is
the same as merging another branch.

The problem is simply in the "...". You cut out the vital part:


       but do not actually make a commit or
       move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
       cause the next `git commit` command to create a merge
       commit.

See? Tree: yes, index: yes, merge info: no.

Git does perform a (tree) merge with --squash, but records the resulting
tree as an ordinary non-merge commit (with a single parent).

I'm not sure whether the statement about the index is completely
correct, though. During a merge the index records info about the merge
(stages :1: etc.) but that as missing with --squash. Only the resulting
tree is added to the index. How about the below?

Now I see, thanks for the help.  The elided part, at the time I elided
it, did not make me understand that merge info was not written,
particularly when surrounded by its original accompanying text.

Thanks again,
Cory