Hi,
I have setup several 'topic branches' for a project I am maintaining.
For several ones, I want to merge them into master.
Here is what I am trying to use:
git checkout master git merge -m "Message" topic-branch
The merge is correct but there is not merge message when I do a git log.
I have tried either with and without -m, I even tried with git merge "merge message" topic-branch but then it failed.
What is the correct way to have merge message ?
Thank you
-- Xavier
Re: git merge and merge message
On Sun, Mar 11, 2007 at 04:05:04PM +0100, Xavier Maillard wrote:
> Hi, > > I have setup several 'topic branches' for a project I am > maintaining. > > For several ones, I want to merge them into master. > > Here is what I am trying to use: > > git checkout master > git merge -m "Message" topic-branch > > The merge is correct but there is not merge message when I do a > git log. > > I have tried either with and without -m, I even tried with git > merge "merge message" topic-branch but then it failed. > > What is the correct way to have merge message ?
Have you done any work on the master branch since you branched the topic branch off from it? If not, the merge is just a "fast forward"--no merge commit is created, and instead the head of the master branch is just updated to point at the same commit as the head of the topic branch.
(Maybe git-merge could warn in the case of -m provided with a fast-forward?)
--b.
[PATCH] git-merge: warn when -m provided on a fast forward
Warn the user that the "-m" option is ignored in the case of a fast forward. That may save some confusion in the case where the user doesn't know about fast forwards yet and may not realize that the behavior here is intentional.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu> --- git-merge.sh | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh index 4afcd95..8b6fcf0 100755 --- a/git-merge.sh +++ b/git-merge.sh @@ -294,7 +294,12 @@ f,*) git-update-index --refresh 2>/dev/null new_head=$(git-rev-parse --verify "$1^0") && git-read-tree -v -m -u --exclude-per-directory=.gitignore $head "$new_head" && - finish "$new_head" "Fast forward" || exit + msg="Fast forward" + if test -n "$have_message" + then + msg="$msg (no commit created; -m option ignored)" + fi + finish "$new_head" "$msg" || exit dropsave exit 0 ;;
-- 1.5.0.gb75812-dirty
Re: git merge and merge message
From: "J. Bruce Fields" <bfields@fieldses.org>
On Sun, Mar 11, 2007 at 04:05:04PM +0100, Xavier Maillard wrote:
> The merge is correct but there is not merge message when I do a > git log.
Have you done any work on the master branch since you branched the topic branch off from it? If not, the merge is just a "fast forward"--no merge commit is created, and instead the head of the master branch is just updated to point at the same commit as the head of the topic branch.
No I did not touch master before. It could explain that behaviour then :)
I am still in my baby-learn phase but git really rocks (I am still lost with branches and tags but I am trying hard to understand.).
Thank you.
-- Xavier
Linus TorvaldsRe: git merge and merge message
On Sun, 11 Mar 2007, Xavier Maillard wrote:
> On Sun, Mar 11, 2007 at 04:05:04PM +0100, Xavier Maillard wrote: > > The merge is correct but there is not merge message when I do a > > git log. > > Have you done any work on the master branch since you branched the topic > branch off from it? If not, the merge is just a "fast forward"--no > merge commit is created, and instead the head of the master branch is > just updated to point at the same commit as the head of the topic > branch. > > No I did not touch master before. It could explain that behaviour > then :)
Indeed.
The "don't merge, just fast-forward" is the right thing to do for working together. However, I can well imagine that if you actually work with branches not as "distributed development", but *just* as "topic branches", then having the "useless" merge (with the parents actually being parents of each other) migth actually be nice from a documentation standpoint.
I'm torn on this. I really dislike anything but fast-forward, because I have a strong suspicion that it will cause "alpha male" behaviour (where maintainers use the "useless merge" as a way to mark their territory), which I think is actually really bad form.
At the same time, I think that the kind of behaviour that Xavier is talking about, where you actually end up having feature branches for your own project, and then using
git merge -m "Merge feature Xyz" xyz-branch
is potentially a really good way of making it clear that the code along the branch you merged did Xyz.
My other rule in life is that a tool should not *force* a certain policy (although encouraging good behaviour by making that the *easy* thing to do is a good idea), so I think that it would probably be ok to add a flag to "git merge" to say "force a merge commit", which would disable the fast-forward behaviour.
(And if you don't support it for "git pull", maybe that's enough of a disincentive that you won't see the "maintainer marking his territory by peeing in the snow" behaviour).
Comments? Do people think it would be a good idea to do
git merge --no-fast-forward -m "Merge feature Xyz" xyz-branch
as an option?
Linus
Re: git merge and merge message
Linus Torvalds wrote:
> Comments? Do people think it would be a good idea to do > > git merge --no-fast-forward -m "Merge feature Xyz" xyz-branch > > as an option? > >
Actually there's at least one tree where this should be activated -- yours. If you perform a fast-forward merge, there's no record of the merge, no record of which tree was pulled, and no sign-off from you. The commits just appear there. It partially defeats the sign-off system.
This feature would be good for top-level trees and for major subsystem trees IMO.
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
Linus TorvaldsRe: git merge and merge message
On Sun, 11 Mar 2007, Avi Kivity wrote:
> > Actually there's at least one tree where this should be activated -- yours. > If you perform a fast-forward merge, there's no record of the merge, no record > of which tree was pulled, and no sign-off from you. The commits just appear > there. It partially defeats the sign-off system.
Well, the thing is, I explicitly don't *want* the merges to show up if it's a fast-forward.
Maybe it's just me, and maybe I'm odd, but I have for several years now really thought of Linux development as being this collection of maintainers, rather than being a "Linus at the top" kind of situation.
So yes, obviously I do end up getting a lot of merges attributed to me, simply because *in practice* my tree is generally the top of the food chain, but I think that's a practical issue because people generally want to avoid confusion by having a known maintainer, and it shouldn't be a design thing.
So I dislike the "hierarchical model" so much that even though it's true, I don't want to make it even _more_ true. I'd rather make it less true, and at least personally think of Linux development more as a "network of developers where some people are just more connected than others". I'm not saying that people are equal (because they aren't), but at the same time I do think that it should be perfectly fine if submaintainers pull from each other if they ever need to - ie pulling should work side-ways and not just up the "command chain".
So I think the hierarchical thing is largely a social thing, but not one that is necessarily the only way of doing things.
And I believe that it might actually be *better* if we were to have some more merging side-ways. Yes, I've been rather involved in kernel development for fifteen years, and I don't really see myself stopping it either, but at the same time, I think that in the really long run, it would be a really interesting experiment to try to run things as a more "amorphous" development group of people that just trust each other, than a very hierarchical one.
And I really think tools matter, and that it's a much more healthy environment if you *don't* have the situation where people mark their merges in a hierarchy. If you have people pulling from each other, rather than a "central repo" model, it really *is* wrong to say "Merge feature Xyz", because when you then later pull the other way, now that merge message makes no sense any more.
> This feature would be good for top-level trees and for major subsystem trees > IMO.
I realize that it can be useful, and I obviously use the "merge.summary" config variable that does make it a non-symmetric situation anyway, and maybe I'm just fighting windmills. It's just that I actually dislike the central repository model so much that I dislike it even when the central repository is *me*.
The Linux kernel is actually a bit strange in this way. I've always encouraged people to have their own repositories, in ways that most other projects do not. So I'm really happy with things like distributions maintaining their own versions, and with developers having their own trees, and keeping me honest that way. The -mm tree, the -aa tree, the -ck tree etc.
I think it's a sign o fa healthy community when there is competition in the maintainer space. Now, people don't always agree with how I do things, and yeah, every few years there is some flame war about how I suck ("Linus doesn't scale" kind of thing), but I think that to keep me reasonably honest, people always need to have alternatives.
So when I really screw up, or become just _too_ impolite and offend too many people, I hope that there will be some other person maintaining his own tree, and people will just flock to that one instead. That's how things *should* work. And that's why I don't want to have too strict a hierarchy, or the tools being geared towards a central model.
So I realize that in practice, when things work reasonably well, you *will* have a central repository. At the same time, I want the tools and the infrastructure to support the case when somebody says "Linus does a horrible job, and I can do better".
So I'll fight tooth and nail to show that I'm better and smarter than any other kernel maintainer, of course, but I'll do that because I *like* the competition, not because I make the tools favor me, thank you very much.
Linus
Re: git merge and merge message
Linus Torvalds wrote:
> On Sun, 11 Mar 2007, Avi Kivity wrote: > >> Actually there's at least one tree where this should be activated -- yours. >> If you perform a fast-forward merge, there's no record of the merge, no record >> of which tree was pulled, and no sign-off from you. The commits just appear >> there. It partially defeats the sign-off system. >> > > Well, the thing is, I explicitly don't *want* the merges to show up if > it's a fast-forward. > > Maybe it's just me, and maybe I'm odd, but I have for several years now > really thought of Linux development as being this collection of > maintainers, rather than being a "Linus at the top" kind of situation. >
Maybe you are a little odd, but I don't think that it's just you. It's quite clear that there are some areas where you don't generally involve yourself, and others where you do.
> So yes, obviously I do end up getting a lot of merges attributed to me, > simply because *in practice* my tree is generally the top of the food > chain, but I think that's a practical issue because people generally want > to avoid confusion by having a known maintainer, and it shouldn't be a > design thing. >
As it is, whether a merge is recorded or is practically random: if two perfectly rebased pull requests come in, one will just appear magically in the tree and the other will have a merge record.
You could make most pulls have no merge record by rebasing them, but that would cause confusion since commits would just appear and it would be impossible to trace them based on the contents of one's tree alone.
I agree it shouldn't be a design thing: I think that on the lower level of the "tree of trees", people should avoid merge records since they are just noise (and indeed most/all maintainers present perfectly groomed trees which have no relation to how development actually happened), but on the top levels, we need the traceability. We need the record of a decision that was made to pull from X's tree at date Y.
> So I dislike the "hierarchical model" so much that even though it's true, > I don't want to make it even _more_ true. I'd rather make it less true, > and at least personally think of Linux development more as a "network of > developers where some people are just more connected than others". I'm not > saying that people are equal (because they aren't), but at the same time I > do think that it should be perfectly fine if submaintainers pull from each > other if they ever need to - ie pulling should work side-ways and not just > up the "command chain". >
-mm and a few other trees approximate that model. These types of trees mostly use quilt, though, which allows an "editable history" mode of operation.
As a maintainer, I would be very wary of pulling sideways. There's the risk of the final upstream being very different from what one pulls, and therefore one is left with a pile of conflicts to fix. There's the risk of the other tree not being pulled at all, blocking one's own work. I don't even want to think about a "no single upstream" mode, that would confuse users in addition to developers.
> So I think the hierarchical thing is largely a social thing, but not one > that is necessarily the only way of doing things. > > And I believe that it might actually be *better* if we were to have some > more merging side-ways. Yes, I've been rather involved in kernel > development for fifteen years, and I don't really see myself stopping it > either, but at the same time, I think that in the really long run, it > would be a really interesting experiment to try to run things as a more > "amorphous" development group of people that just trust each other, than a > very hierarchical one. >
The hierarchical model does have advantages: you can always get a decision (it may be the wrong one, but it's better than no decision), and more important, it's clear and understandable.
> I realize that it can be useful, and I obviously use the "merge.summary" > config variable that does make it a non-symmetric situation anyway, and > maybe I'm just fighting windmills. It's just that I actually dislike the > central repository model so much that I dislike it even when the central > repository is *me*. > >
Maybe you would like it more if the central repository wasn't you :) - it really provides a reference frame against which to work, even if it is moving all the time. It reduces the risks of working on something that is going away.
-- error compiling committee.c: too many arguments to function
Johannes SchindelinRe: git merge and merge message
Hi,
On Sun, 11 Mar 2007, Avi Kivity wrote:
> Linus Torvalds wrote: > > Comments? Do people think it would be a good idea to do > > > > git merge --no-fast-forward -m "Merge feature Xyz" xyz-branch > > > > as an option? > > > > > > Actually there's at least one tree where this should be activated -- > yours. If you perform a fast-forward merge, there's no record of the > merge, no record of which tree was pulled, and no sign-off from you. > The commits just appear there. It partially defeats the sign-off > system. > > This feature would be good for top-level trees and for major subsystem > trees IMO.
What? You should sign-off on stuff you did not review? Or do you review the stuff _before_ merging? I don't.
Ciao, Dscho
Junio C HamanoRe: git merge and merge message
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> This feature would be good for top-level trees and for major subsystem >> trees IMO. > > What? You should sign-off on stuff you did not review? Or do you review > the stuff _before_ merging? I don't.
Actually I've done a few merging recently, and I do review the stuff before merging. It is easier to review after making a merge, so technically the review happens _after_ merging but if I do not like what the other branch has, I can throw it away with "reset --hard ORIG_HEAD", which means in practice the review is done before.
Re: git merge and merge message
Johannes Schindelin wrote:
>>> >>> >> Actually there's at least one tree where this should be activated -- >> yours. If you perform a fast-forward merge, there's no record of the >> merge, no record of which tree was pulled, and no sign-off from you. >> The commits just appear there. It partially defeats the sign-off >> system. >> >> This feature would be good for top-level trees and for major subsystem >> trees IMO. >> > > What? You should sign-off on stuff you did not review? Or do you review > the stuff _before_ merging? I don't. >
Obviously one signs off only after some sort of review. Some merges might be reviewed line-by-line, and some might be reviewed by looking at the maintainer's name and shortlog for a sanity check, but obviously you don't pull blind.
Anyway currently whether a merge record and a sign-off appear is a fairly random decision, based on the time of the last rebase the pullee did. Whichever way is chosen (record/no record) I don't think it should be based on that.
-- error compiling committee.c: too many arguments to function
Junio C HamanoRe: git merge and merge message
Linus Torvalds <torvalds@linux-foundation.org> writes:
> At the same time, I think that the kind of behaviour that Xavier is > talking about, where you actually end up having feature branches for your > own project, and then using > > git merge -m "Merge feature Xyz" xyz-branch > > is potentially a really good way of making it clear that the code along > the branch you merged did Xyz. > > My other rule in life is that a tool should not *force* a certain policy > (although encouraging good behaviour by making that the *easy* thing to do > is a good idea), so I think that it would probably be ok to add a flag to > "git merge" to say "force a merge commit", which would disable the > fast-forward behaviour. > > (And if you don't support it for "git pull", maybe that's enough of a > disincentive that you won't see the "maintainer marking his territory by > peeing in the snow" behaviour). > > Comments? Do people think it would be a good idea to do > > git merge --no-fast-forward -m "Merge feature Xyz" xyz-branch > > as an option? > > Linus
For one thing, this would make the earlier "first parent log summary" idea useful again.
The big picture of the evolution history of my 'next' can be seen by taking only the first parent ancestry, since the commit message in each of them has the summary of commit^..commit, coming from the fmt-merge-message output. This is because there won't be any fast-forward on 'next' as I never fork off of the tip of 'next'.
However, that is not true for my 'master'. When I merge a topic back into 'master' when the 'master' hasn't added any obvious and trivial fixups or improvements since the topic forked, it would result in a fast-forward. --no-fast-forward can be used to cure this.
So in that sense I think --no-fast-forward is a useful ingredient to make a history that is easy to read in "fast parent log" fashion, but:
(1) it is only just one "enabler" -- you still need the
discipline to build your history that way, and (2) it is dubious if it is really useful to present the
history in "fast parent log" fashion for even trivial
topics.Regarding (2), a fast-forward into the trunk (or master) is a sign that nothing else was going on in the meantime, so it is either the series was very short (suggesting "_trivial_ changes on top of master"), and/or the only focus of the project during that timeperiod (suggesting "trivial changes _on top of master_"), either of which may mean that it would be good enough to just have a commit log message that says "This concludes the series I started at commit Xyz to do blah" without having an extra forced merge.
If the answer to (2) is "yes, it is useful", then maybe building such a history needs to be helped with more tool support (that is my point (1) above).
For example, _if_ I wanted to (mind you, in reality I don't think I necessarily do), I could forbid direct single-parent commits on top of 'master' branch, and force --no-fast-forward when merging to 'master' branch. That perhaps would be achieved by marking the branch with 'branch.master.integrationonly = true' configuration.
Junio C Hamano[RFC] git log --first-parent
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes: > >> Comments? Do people think it would be a good idea to do >> >> git merge --no-fast-forward -m "Merge feature Xyz" xyz-branch >> >> as an option? >> >> Linus > > For one thing, this would make the earlier "first parent log > summary" idea useful again.
While I was writing "What's cooking" tonight, I came up with this patch so that I can view what's in topic branches.
This time somehow I ended up having to cross merge a few topics (e.g. jc/fetch which is the partial C rewrite has been cooking long enough that merging 'master' to get Nico's OBJ_TYPE cleanups has become useful), and also 'next' is a pure integration branch, and it turns out that reviewing them with
$ git log --first-parent master..jc/fetch
was easier to view what really was going on on that particular topic, without getting distracted with what was merged from sideways.
---
diff --git a/revision.c b/revision.c index 3c2eb12..8afc196 100644 --- a/revision.c +++ b/revision.c @@ -350,6 +350,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st { struct commit_list *parent = commit->parents; unsigned left_flag; + int add, rest; if (commit->object.flags & ADDED) return; @@ -395,18 +396,19 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st return; left_flag = (commit->object.flags & SYMMETRIC_LEFT); - parent = commit->parents; - while (parent) { + + rest = !revs->first_parent_only; + for (parent = commit->parents, add = 1; parent; add = rest) { struct commit *p = parent->item; parent = parent->next; - parse_commit(p); p->object.flags |= left_flag; if (p->object.flags & SEEN) continue; p->object.flags |= SEEN; - insert_by_date(p, list); + if (add) + insert_by_date(p, list); } } @@ -836,6 +838,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch handle_all(revs, flags); continue; } + if (!strcmp(arg, "--first-parent")) { + revs->first_parent_only = 1; + continue; + } if (!strcmp(arg, "--reflog")) { handle_reflog(revs, flags); continue; diff --git a/revision.h b/revision.h index 6ae39e6..55e6b53 100644 --- a/revision.h +++ b/revision.h @@ -46,7 +46,8 @@ struct rev_info { boundary:2, left_right:1, parents:1, - reverse:1; + reverse:1, + first_parent_only:1; /* Diff flags */ unsigned int diff:1,
Jeff KingRe: [RFC] git log --first-parent
On Tue, Mar 13, 2007 at 01:55:36AM -0700, Junio C Hamano wrote:
> $ git log --first-parent master..jc/fetch
You might recall the 25-way hydra merge I was discussing a few weeks ago. I ended up simply making a series of pair-wise merges; this "--first-parent" option is the perfect tool for visualizing it, especially "gitk --first-parent". Please consider merging it.
-Peff
Martin LanghoffRe: git merge and merge message
On 3/12/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> The "don't merge, just fast-forward" is the right thing to do for working > together. However, I can well imagine that if you actually work with > branches not as "distributed development", but *just* as "topic branches", > then having the "useless" merge (with the parents actually being parents > of each other) migth actually be nice from a documentation standpoint.
Well, actually I do quite a bit of work in private repos, and it is more useful to know *trivially* that the branches are in the same place, and get me and my team into the "it's about the content, stupid" mindset.
So after all the flamefesting, I drank the content-is-king koolaid and if a pull leads to a fast-forward, I'm happy. If it's a pointless merge I often rebase to linearise.
> I'm torn on this.
Man, you're getting soft in the middle ;-) First, git gets a newline conversion option to please windows users that don't use the many GOOD programming editors that know a unix newline from a UFO (and those are the majority these days, or so I hear). And now _this_! Tsk, tsk!
> I really dislike anything but fast-forward, because I > have a strong suspicion that it will cause "alpha male" behaviour (where > maintainers use the "useless merge" as a way to mark their territory), > which I think is actually really bad form.
I share your concern. And for Xavier's case ref logs should do the trick anyway.
cheers,
m