Re: [RFC/PATCH] Option to revert order of parents in merge commit
On Fri, Nov 23, 2012 at 06:58:49PM -0800, Junio C Hamano wrote: Kacper Kornet drae...@pld-linux.org writes: The following patch is an attempt to implement this idea. I think revert is a wrong word (implying you have already done something and you are trying to defeat the effect of that old something), and you meant to say reverse (i.e. the opposite of normal) or something. You are right. Probably transpose is the best description what the patch really does. I am unsure about the usefulness of this, though. After completing a topic on branch A, you would merge it to your own copy of the integration branch (e.g. 'master') and try to push, which may be rejected due to non-fast-forwardness: $ git checkout master $ git merge A $ git push At that point, if you _care_ about the merge parent order, you could do this (still on 'master'): $ git fetch origin $ git reset --hard origin/master $ git merge A $ test test test $ git push With --reverse-parents, it would become: $ git pull --reverse-parents $ test test test $ git push which certainly is shorter and looks simpler. The workflow however would encourage people to work directly on the master branch, which is a bit of downside. Our developers work mainly on master branches. The project consists of many thousands independent git repositories, and at the given time a developer usually wants to make only one commit in the given repository and push his changes upstream. So he usually doesn't care to make a branch. Then after failed pushed, one needs to add creation and removal of temporary branch (see the commit message of the suggested patch). The possibility to do git pull --reverse-parent would make the life easier in this case. Is there any interaction between this pull --reverse-parents change and possible conflict resolution when the command stops and asks the user for help? For example, whom should --ours and -X ours refer to? Us, or the upstream? The change of order of parents happens at the very last moment, so ours in merge options is local version and theirs upstream. -- Kacper Kornet -- 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: [RFC/PATCH] Option to revert order of parents in merge commit
Kacper Kornet drae...@pld-linux.org writes: Is there any interaction between this pull --reverse-parents change and possible conflict resolution when the command stops and asks the user for help? For example, whom should --ours and -X ours refer to? Us, or the upstream? The change of order of parents happens at the very last moment, so ours in merge options is local version and theirs upstream. That may be something that wants to go to the proposed commit log message. I am neutral on the feature (i.e. not against it but not extremely enthusiastic about it either). Thanks. -- 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
[RFC/PATCH] Option to revert order of parents in merge commit
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 my commit. D, E are commits pushed by someone else when I 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. Presently to
obtain it, instead of git pull, one needs to do (assuming that I am on
the master branch):
git fetch origin
git branch tmp_branch
git reset --hard origin/master
git merge tmp_branch
Reverting from wrong pull is more cumbersome. It would be simpler if git
merge learn an option to reverse order of parents in the produced
commits, so one could do:
git fetch origin
git merge --revert-order origin/master
The following patch is an attempt to implement this idea.
Signed-off-by: Kacper Kornet drae...@pld-linux.org
---
I'm not 100% percent sure that it is a good idea. But it would make life
of our developers easier and produced nicer history then using git pull.
Git pull seems to written for a case of single maintainer who gathers
contributions from other developers and incorporates them in master
branch. However in my opinion it doesn't produce best history when many
developers modify the canonical repository.
builtin/commit.c | 22 ++
builtin/merge.c | 16
commit.c | 11 +++
commit.h | 2 ++
4 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..ab2b844 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1427,7 +1427,6 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
unsigned char sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = parents;
- struct stat statbuf;
int allow_fast_forward = 1;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
@@ -1478,10 +1477,21 @@ 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);
- pptr = commit_list_insert(current_head, pptr)-next;
+ if((fp = fopen(git_path(MERGE_MODE), r))) {
+ 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);
+ }
+ 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),
@@ -1496,12 +1506,8 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
}
fclose(fp);
strbuf_release(m);
- if (!stat(git_path(MERGE_MODE), statbuf)) {
- if (strbuf_read_file(sb, git_path(MERGE_MODE), 0)
0)
- die_errno(_(could not read MERGE_MODE));
- if (!strcmp(sb.buf, no-ff))
- allow_fast_forward = 0;
- }
+ 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..8d0ed18 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, revert-order, 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 =
Re: [RFC/PATCH] Option to revert order of parents in merge commit
Kacper Kornet drae...@pld-linux.org writes: The following patch is an attempt to implement this idea. I think revert is a wrong word (implying you have already done something and you are trying to defeat the effect of that old something), and you meant to say reverse (i.e. the opposite of normal) or something. I am unsure about the usefulness of this, though. After completing a topic on branch A, you would merge it to your own copy of the integration branch (e.g. 'master') and try to push, which may be rejected due to non-fast-forwardness: $ git checkout master $ git merge A $ git push At that point, if you _care_ about the merge parent order, you could do this (still on 'master'): $ git fetch origin $ git reset --hard origin/master $ git merge A $ test test test $ git push With --reverse-parents, it would become: $ git pull --reverse-parents $ test test test $ git push which certainly is shorter and looks simpler. The workflow however would encourage people to work directly on the master branch, which is a bit of downside. Is there any interaction between this pull --reverse-parents change and possible conflict resolution when the command stops and asks the user for help? For example, whom should --ours and -X ours refer to? Us, or the upstream? -- 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
