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

2012-11-28 Thread Junio C Hamano
Johannes Sixt  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 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


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  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 Junio C Hamano
Kacper Kornet  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


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

2012-11-27 Thread 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

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-'

The difference between C and C' is the order of parents. This change
allow for easier way to obtain this effect by introducing the option
--transpose-parents to git-merge and git-pull, which changes the order
of parents in resulting commit moving the original first parent to
the very end of list of parents.

The transposition is done just before the commit is finalized, so the
meaning of "our" and "their" for conflict resolution is not changed, so
"ours" denotes local version and "theirs" upstream.

Signed-off-by: Kacper Kornet 
---
 Documentation/merge-options.txt |  7 +++
 builtin/commit.c|  8 +++-
 builtin/merge.c | 16 
 commit.c| 11 +++
 commit.h|  2 ++
 git-pull.sh |  4 +++-
 6 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 0bcbe0a..b4fbfdc 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -88,6 +88,13 @@ option can be used to override --squash.
Synonyms to --stat and --no-stat; these are deprecated and will be
removed in the future.
 
+--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).
+
+
 ifndef::git-pull[]
 -q::
 --quiet::
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;
 
if (!reflog_msg)
reflog_msg = "commit (merge)";
@@ -1484,10 +1485,13 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
while (strbuf_getline(&m, fp, '\n') != EOF) {
if (!strcmp(m.buf, "no-ff"))
allow_fast_forward = 0;
+   if (!strcmp(m.buf, "reversed-order"))
+   reversed_order = 1;
}
fclose(fp);
}
-   pptr = &commit_list_insert(current_head, pptr)->next;
+   if (!reversed_order)
+   pptr = &commit_list_insert(current_head, pptr)->next;
fp = fopen(git_path("MERGE_HEAD"), "r");
if (fp == NULL)
die_errno(_("could not open '%s' for reading"),
@@ -1502,6 +1506,8 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
}
fclose(fp);
strbuf_release(&m);
+   if (reversed_order)
+   pptr = &commit_list_insert(current_head, pptr)->next;
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
diff --git a/builtin/merge.c b/builtin/merge.c
index a96e8ea..41738a5 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int abort_current_merge;
 static int show_progress = -1;
 static int default_to_upstream;
 static const char *sign_commit;
+static int reversed_order=0;
 
 static struct strategy all_strategy[] = {
{ "recursive",  DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -213,6 +214,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key id"),
  N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
OPT_BOOLEAN(0, "overwrite-ignore", &overwrite_ignore, N_("update 
ignored files (default)")),
+   OPT_BOOLEAN(0, "transpose-parents", &reversed_order, N_("reverse order 
of parents")),
OPT_END()
 };
 
@@ -822,9 +824,9 @@ static int merge_trivial(struct commit *head, struct 
commit_list *remoteheads)
 
write_tree_trivial(result_tree);
printf(_("Wonderful.\n"));
-   parent->item = head;
+   parent->item = reversed_order ? remoteheads->item : head;
parent->next = xmalloc(sizeof(*parent->next));
-   parent->next->item = remoteheads->item;
+   parent->next->item = reversed_order ? head : remoteheads->item;
parent->next->next = NULL;
prepare_to_commit(remoteheads);
if