Re: [PATCH v2 3/3] Add option to transpose parents of merge commit

2012-11-28 Thread Junio C Hamano 
Johannes Sixt j.s...@viscovery.net writes:

 Am 11/28/2012 0:00, schrieb Kacper Kornet:
 When the changes are pushed upstream, and in the meantime someone else
 updated upstream branch git advises to use git pull. This results in
 history:
 
  ---A---B---C--
  \ /
   D---E

 The commit message will say:

   Merge branch 'master' of /that/remote

   * 'master' of /that/remote:
 E
 D

 where B is the local commit. D, E are commits pushed by someone else
 when the developer was working on B. However sometimes the following
 history is preferable:
 
 ---A---D---C'--
 \ /
  '-B-'

 Better:

  ---A--D--E--C'
  \  /
   `B

Yup, that topology is what Kacper's workflow wants.

Stepping back a bit, however, I am not sure if that is really true.
The goal of this topic seems to be to keep one integration branch
and always merge *into* that integration branch, never *from* it,
but for what purpose?  Making the log --first-parent express the
integration branch as a linear series of progress?  If so, I suspect
a project with such a policy would dictate that D and E also be on a
side branch, i.e. the history would look more like this:

  D---E
 / \
  --A---X---C---
 \ /
  `---B

with X being a --no-ff merge of the topic that consists of these two
commits.

 In this case, the commit message should say... what? Certainly not the
 same thing. But I do not see that you changed anything in this regard.

True.  If the goal is to emulate a merge of B from a side branch
into _the_ integration branch, the summary should also emulate the
message that would be given when the remote pulled from your current
branch.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] Add option to transpose parents of merge commit

2012-11-27 Thread Junio C Hamano 
Kacper Kornet drae...@pld-linux.org writes:

 +--transpose-parents::
 + Transpose the parents in the final commit. The change is made
 + just before the commit so the meaning of 'our' and 'their'
 + concepts remains the same (i.e. 'our' means current branch before
 + the merge).
 +

How does this interact with Octopus merges?

 diff --git a/builtin/commit.c b/builtin/commit.c
 index ee0e884..ab2b844 100644
 --- a/builtin/commit.c
 +++ b/builtin/commit.c
 @@ -1477,6 +1477,7 @@ int cmd_commit(int argc, const char **argv, const char 
 *prefix)
   } else if (whence == FROM_MERGE) {
   struct strbuf m = STRBUF_INIT;
   FILE *fp;
 + int reversed_order=0;

Style. s/=/ = /;

 + OPT_BOOLEAN(0, transpose-parents, reversed_order, N_(reverse order 
 of parents)

It smells more like --reverse-parents (if you deal only with
two-head merges), no?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] Add option to transpose parents of merge commit

2012-11-27 Thread Kacper Kornet 
On Tue, Nov 27, 2012 at 06:18:00PM -0800, Junio C Hamano wrote:
 Kacper Kornet drae...@pld-linux.org writes:

  +--transpose-parents::
  +   Transpose the parents in the final commit. The change is made
  +   just before the commit so the meaning of 'our' and 'their'
  +   concepts remains the same (i.e. 'our' means current branch before
  +   the merge).
  +

 How does this interact with Octopus merges?

It moves the original first parent to the last position. And nothing
more. I have forgotten to mention it in the documentation.

  diff --git a/builtin/commit.c b/builtin/commit.c
  index ee0e884..ab2b844 100644
  --- a/builtin/commit.c
  +++ b/builtin/commit.c
  @@ -1477,6 +1477,7 @@ int cmd_commit(int argc, const char **argv, const 
  char *prefix)
  } else if (whence == FROM_MERGE) {
  struct strbuf m = STRBUF_INIT;
  FILE *fp;
  +   int reversed_order=0;

 Style. s/=/ = /;

  +   OPT_BOOLEAN(0, transpose-parents, reversed_order, N_(reverse order 
  of parents)

 It smells more like --reverse-parents (if you deal only with
 two-head merges), no?

I have changes to --transpose-parents because of the octopus merges.
Although it is not a mathematical transposition in this case, but a cycle
permutation. 

-- 
  Kacper
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] Add option to transpose parents of merge commit

2012-11-27 Thread Johannes Sixt 
Am 11/28/2012 0:00, schrieb Kacper Kornet:
 When the changes are pushed upstream, and in the meantime someone else
 updated upstream branch git advises to use git pull. This results in
 history:
 
  ---A---B---C--
  \ /
   D---E

The commit message will say:

  Merge branch 'master' of /that/remote

  * 'master' of /that/remote:
E
D

 where B is the local commit. D, E are commits pushed by someone else
 when the developer was working on B. However sometimes the following
 history is preferable:
 
 ---A---D---C'--
 \ /
  '-B-'

Better:

 ---A--D--E--C'
 \  /
  `B

In this case, the commit message should say... what? Certainly not the
same thing. But I do not see that you changed anything in this regard.

-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html