git merge and merge message

git merge and merge message

[Xavier Maillard]

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

[J. Bruce Fields]

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

[J. Bruce Fields]

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

[Xavier Maillard]

   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

Re: git merge and merge message

[Linus Torvalds]

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

[Avi Kivity]

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.

Re: git merge and merge message

[Linus Torvalds]

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

[Avi Kivity]

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

Re: git merge and merge message

[Johannes Schindelin]

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

Re: git merge and merge message

[Junio C Hamano]

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

[Avi Kivity]

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

Re: git merge and merge message

[Junio C Hamano]

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.

[RFC] git log --first-parent

[Junio C Hamano]

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,

Re: [RFC] git log --first-parent

[Jeff King]

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

Re: git merge and merge message

[Martin Langhoff]

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