{"thread":{"id":"7195","subject":"git merge and merge message","startedAt":"2007-03-11T15:05:04Z","lastAt":"2007-03-13T14:17:51Z","messageCount":15,"participants":["Xavier Maillard","J. Bruce Fields","Linus Torvalds","Avi Kivity","Junio C Hamano","Johannes Schindelin","Martin Langhoff","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"36810","messageId":"200703111505.l2BF54Kq006625@localhost.localdomain","threadId":"7195","inReplyTo":null,"subject":"git merge and merge message","fromName":"Xavier Maillard","fromEmail":"zedek@gnu.org","sentAt":"2007-03-11T15:05:04Z","receivedAt":"2007-03-11T15:05:04Z","isPatch":false,"sender":{"key":"zedek@gnu.org","avatar":null},"body":"Hi,\n\nI have setup several 'topic branches' for a project I am\nmaintaining.\n\nFor several ones, I want to merge them into master.\n\nHere is what I am trying to use:\n\ngit checkout master\ngit merge -m \"Message\" topic-branch\n\nThe merge is correct but there is not merge message when I do a\ngit log.\n\nI have tried either with and without -m, I even tried with git\nmerge \"merge message\" topic-branch but then it failed.\n\nWhat is the correct way to have merge message ?\n\nThank you\n-- \nXavier\n"},{"id":"36816","messageId":"20070311160424.GA629@fieldses.org","threadId":"7195","inReplyTo":"200703111505.l2BF54Kq006625@localhost.localdomain","subject":"Re: git merge and merge message","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-03-11T16:04:24Z","receivedAt":"2007-03-11T16:04:24Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Mar 11, 2007 at 04:05:04PM +0100, Xavier Maillard wrote:\n> Hi,\n> \n> I have setup several 'topic branches' for a project I am\n> maintaining.\n> \n> For several ones, I want to merge them into master.\n> \n> Here is what I am trying to use:\n> \n> git checkout master\n> git merge -m \"Message\" topic-branch\n> \n> The merge is correct but there is not merge message when I do a\n> git log.\n> \n> I have tried either with and without -m, I even tried with git\n> merge \"merge message\" topic-branch but then it failed.\n> \n> What is the correct way to have merge message ?\n\nHave you done any work on the master branch since you branched the topic\nbranch off from it? If not, the merge is just a \"fast forward\"--no\nmerge commit is created, and instead the head of the master branch is\njust updated to point at the same commit as the head of the topic\nbranch.\n\n(Maybe git-merge could warn in the case of -m provided with a\nfast-forward?)\n\n--b.\n"},{"id":"36819","messageId":"20070311162856.GB629@fieldses.org","threadId":"7195","inReplyTo":"20070311160424.GA629@fieldses.org","subject":"[PATCH] git-merge: warn when -m provided on a fast forward","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-03-11T16:28:56Z","receivedAt":"2007-03-11T16:28:56Z","isPatch":true,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"Warn the user that the \"-m\" option is ignored in the case of a fast\nforward. That may save some confusion in the case where the user\ndoesn't know about fast forwards yet and may not realize that the\nbehavior here is intentional.\n\nSigned-off-by: \"J. Bruce Fields\" \n---\n git-merge.sh | 7 ++++++-\n 1 files changed, 6 insertions(+), 1 deletions(-)\n\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 4afcd95..8b6fcf0 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -294,7 +294,12 @@ f,*)\n \tgit-update-index --refresh 2>/dev/null\n \tnew_head=$(git-rev-parse --verify \"$1^0\") &&\n \tgit-read-tree -v -m -u --exclude-per-directory=.gitignore $head \"$new_head\" &&\n-\tfinish \"$new_head\" \"Fast forward\" || exit\n+\tmsg=\"Fast forward\"\n+\tif test -n \"$have_message\"\n+\tthen\n+\t\tmsg=\"$msg (no commit created; -m option ignored)\"\n+\tfi\n+\tfinish \"$new_head\" \"$msg\" || exit\n \tdropsave\n \texit 0\n \t;;\n-- \n1.5.0.gb75812-dirty\n"},{"id":"36840","messageId":"200703111815.l2BIFHbq010315@localhost.localdomain","threadId":"7195","inReplyTo":"20070311160424.GA629@fieldses.org","subject":"Re: git merge and merge message","fromName":"Xavier Maillard","fromEmail":"zedek@gnu.org","sentAt":"2007-03-11T18:15:17Z","receivedAt":"2007-03-11T18:15:17Z","isPatch":false,"sender":{"key":"zedek@gnu.org","avatar":null},"body":" From: \"J. Bruce Fields\" \n\n On Sun, Mar 11, 2007 at 04:05:04PM +0100, Xavier Maillard wrote:\n\n > The merge is correct but there is not merge message when I do a\n > git log.\n\n Have you done any work on the master branch since you branched the topic\n branch off from it? If not, the merge is just a \"fast forward\"--no\n merge commit is created, and instead the head of the master branch is\n just updated to point at the same commit as the head of the topic\n branch.\n\nNo I did not touch master before. It could explain that behaviour\nthen :)\n\nI am still in my baby-learn phase but git really rocks (I am\nstill lost with branches and tags but I am trying hard to\nunderstand.).\n\nThank you.\n-- \nXavier\n"},{"id":"36850","messageId":"Pine.LNX.4.64.0703111309410.9690@woody.linux-foundation.org","threadId":"7195","inReplyTo":"200703111815.l2BIFHbq010315@localhost.localdomain","subject":"Re: git merge and merge message","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-11T20:19:00Z","receivedAt":"2007-03-11T20:19:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 11 Mar 2007, Xavier Maillard wrote:\n> On Sun, Mar 11, 2007 at 04:05:04PM +0100, Xavier Maillard wrote:\n> > The merge is correct but there is not merge message when I do a\n> > git log.\n> \n> Have you done any work on the master branch since you branched the topic\n> branch off from it? If not, the merge is just a \"fast forward\"--no\n> merge commit is created, and instead the head of the master branch is\n> just updated to point at the same commit as the head of the topic\n> branch.\n> \n> No I did not touch master before. It could explain that behaviour\n> then :)\n\nIndeed.\n\nThe \"don't merge, just fast-forward\" is the right thing to do for working \ntogether. However, I can well imagine that if you actually work with \nbranches not as \"distributed development\", but *just* as \"topic branches\", \nthen having the \"useless\" merge (with the parents actually being parents \nof each other) migth actually be nice from a documentation standpoint.\n\nI'm torn on this. I really dislike anything but fast-forward, because I \nhave a strong suspicion that it will cause \"alpha male\" behaviour (where \nmaintainers use the \"useless merge\" as a way to mark their territory), \nwhich I think is actually really bad form.\n\nAt the same time, I think that the kind of behaviour that Xavier is \ntalking about, where you actually end up having feature branches for your \nown project, and then using\n\n\tgit merge -m \"Merge feature Xyz\" xyz-branch\n\nis potentially a really good way of making it clear that the code along \nthe branch you merged did Xyz.\n\nMy other rule in life is that a tool should not *force* a certain policy \n(although encouraging good behaviour by making that the *easy* thing to do \nis a good idea), so I think that it would probably be ok to add a flag to \n\"git merge\" to say \"force a merge commit\", which would disable the \nfast-forward behaviour.\n\n(And if you don't support it for \"git pull\", maybe that's enough of a \ndisincentive that you won't see the \"maintainer marking his territory by \npeeing in the snow\" behaviour).\n\nComments? Do people think it would be a good idea to do\n\n\tgit merge --no-fast-forward -m \"Merge feature Xyz\" xyz-branch\n\nas an option?\n\n\t\t\tLinus\n"},{"id":"36855","messageId":"45F46713.6030702@qumranet.com","threadId":"7195","inReplyTo":"Pine.LNX.4.64.0703111309410.9690@woody.linux-foundation.org","subject":"Re: git merge and merge message","fromName":"Avi Kivity","fromEmail":"avi@qumranet.com","sentAt":"2007-03-11T20:31:15Z","receivedAt":"2007-03-11T20:31:15Z","isPatch":false,"sender":{"key":"avi@qumranet.com","avatar":null},"body":"Linus Torvalds wrote:\n> Comments? Do people think it would be a good idea to do\n>\n> \tgit merge --no-fast-forward -m \"Merge feature Xyz\" xyz-branch\n>\n> as an option?\n>\n> \n\nActually there's at least one tree where this should be activated -- \nyours. If you perform a fast-forward merge, there's no record of the \nmerge, no record of which tree was pulled, and no sign-off from you. \nThe commits just appear there. It partially defeats the sign-off system.\n\nThis feature would be good for top-level trees and for major subsystem \ntrees IMO.\n\n-- \nDo not meddle in the internals of kernels, for they are subtle and quick to panic.\n"},{"id":"36859","messageId":"7vwt1nv6r5.fsf@assigned-by-dhcp.cox.net","threadId":"7195","inReplyTo":"Pine.LNX.4.64.0703111309410.9690@woody.linux-foundation.org","subject":"Re: git merge and merge message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-11T20:56:46Z","receivedAt":"2007-03-11T20:56:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> At the same time, I think that the kind of behaviour that Xavier is \n> talking about, where you actually end up having feature branches for your \n> own project, and then using\n>\n> \tgit merge -m \"Merge feature Xyz\" xyz-branch\n>\n> is potentially a really good way of making it clear that the code along \n> the branch you merged did Xyz.\n>\n> My other rule in life is that a tool should not *force* a certain policy \n> (although encouraging good behaviour by making that the *easy* thing to do \n> is a good idea), so I think that it would probably be ok to add a flag to \n> \"git merge\" to say \"force a merge commit\", which would disable the \n> fast-forward behaviour.\n>\n> (And if you don't support it for \"git pull\", maybe that's enough of a \n> disincentive that you won't see the \"maintainer marking his territory by \n> peeing in the snow\" behaviour).\n>\n> Comments? Do people think it would be a good idea to do\n>\n> \tgit merge --no-fast-forward -m \"Merge feature Xyz\" xyz-branch\n>\n> as an option?\n>\n> \t\t\tLinus\n\nFor one thing, this would make the earlier \"first parent log\nsummary\" idea useful again.\n\nThe big picture of the evolution history of my 'next' can be\nseen by taking only the first parent ancestry, since the commit\nmessage in each of them has the summary of commit^..commit,\ncoming from the fmt-merge-message output. This is because there\nwon't be any fast-forward on 'next' as I never fork off of the\ntip of 'next'.\n\nHowever, that is not true for my 'master'. When I merge a topic\nback into 'master' when the 'master' hasn't added any obvious\nand trivial fixups or improvements since the topic forked, it\nwould result in a fast-forward. --no-fast-forward can be used\nto cure this.\n\nSo in that sense I think --no-fast-forward is a useful\ningredient to make a history that is easy to read in \"fast\nparent log\" fashion, but:\n\n (1) it is only just one \"enabler\" -- you still need the\n discipline to build your history that way, and\n\n (2) it is dubious if it is really useful to present the\n history in \"fast parent log\" fashion for even trivial\n topics.\n\nRegarding (2), a fast-forward into the trunk (or master) is a\nsign that nothing else was going on in the meantime, so it is\neither the series was very short (suggesting \"_trivial_ changes\non top of master\"), and/or the only focus of the project during\nthat timeperiod (suggesting \"trivial changes _on top of\nmaster_\"), either of which may mean that it would be good enough\nto just have a commit log message that says \"This concludes the\nseries I started at commit Xyz to do blah\" without having an\nextra forced merge.\n\nIf the answer to (2) is \"yes, it is useful\", then maybe building\nsuch a history needs to be helped with more tool support (that\nis my point (1) above). \n\nFor example, _if_ I wanted to (mind you, in reality I don't\nthink I necessarily do), I could forbid direct single-parent\ncommits on top of 'master' branch, and force --no-fast-forward\nwhen merging to 'master' branch. That perhaps would be achieved\nby marking the branch with 'branch.master.integrationonly = true'\nconfiguration.\n"},{"id":"36862","messageId":"Pine.LNX.4.64.0703111348230.9690@woody.linux-foundation.org","threadId":"7195","inReplyTo":"45F46713.6030702@qumranet.com","subject":"Re: git merge and merge message","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-11T21:05:51Z","receivedAt":"2007-03-11T21:05:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 11 Mar 2007, Avi Kivity wrote:\n> \n> Actually there's at least one tree where this should be activated -- yours.\n> If you perform a fast-forward merge, there's no record of the merge, no record\n> of which tree was pulled, and no sign-off from you. The commits just appear\n> there. It partially defeats the sign-off system.\n\nWell, the thing is, I explicitly don't *want* the merges to show up if \nit's a fast-forward. \n\nMaybe it's just me, and maybe I'm odd, but I have for several years now \nreally thought of Linux development as being this collection of \nmaintainers, rather than being a \"Linus at the top\" kind of situation. \n\nSo yes, obviously I do end up getting a lot of merges attributed to me, \nsimply because *in practice* my tree is generally the top of the food \nchain, but I think that's a practical issue because people generally want \nto avoid confusion by having a known maintainer, and it shouldn't be a \ndesign thing.\n\nSo I dislike the \"hierarchical model\" so much that even though it's true, \nI don't want to make it even _more_ true. I'd rather make it less true, \nand at least personally think of Linux development more as a \"network of \ndevelopers where some people are just more connected than others\". I'm not \nsaying that people are equal (because they aren't), but at the same time I \ndo think that it should be perfectly fine if submaintainers pull from each \nother if they ever need to - ie pulling should work side-ways and not just \nup the \"command chain\".\n\nSo I think the hierarchical thing is largely a social thing, but not one \nthat is necessarily the only way of doing things. \n\nAnd I believe that it might actually be *better* if we were to have some \nmore merging side-ways. Yes, I've been rather involved in kernel \ndevelopment for fifteen years, and I don't really see myself stopping it \neither, but at the same time, I think that in the really long run, it \nwould be a really interesting experiment to try to run things as a more \n\"amorphous\" development group of people that just trust each other, than a \nvery hierarchical one.\n\nAnd I really think tools matter, and that it's a much more healthy \nenvironment if you *don't* have the situation where people mark their \nmerges in a hierarchy. If you have people pulling from each other, rather \nthan a \"central repo\" model, it really *is* wrong to say \"Merge feature \nXyz\", because when you then later pull the other way, now that merge \nmessage makes no sense any more.\n\n> This feature would be good for top-level trees and for major subsystem trees\n> IMO.\n\nI realize that it can be useful, and I obviously use the \"merge.summary\" \nconfig variable that does make it a non-symmetric situation anyway, and \nmaybe I'm just fighting windmills. It's just that I actually dislike the \ncentral repository model so much that I dislike it even when the central \nrepository is *me*.\n\nThe Linux kernel is actually a bit strange in this way. I've always \nencouraged people to have their own repositories, in ways that most other \nprojects do not. So I'm really happy with things like distributions \nmaintaining their own versions, and with developers having their own \ntrees, and keeping me honest that way. The -mm tree, the -aa tree, the -ck \ntree etc.\n\nI think it's a sign o fa healthy community when there is competition in \nthe maintainer space. Now, people don't always agree with how I do things, \nand yeah, every few years there is some flame war about how I suck (\"Linus \ndoesn't scale\" kind of thing), but I think that to keep me reasonably \nhonest, people always need to have alternatives. \n\nSo when I really screw up, or become just _too_ impolite and offend too \nmany people, I hope that there will be some other person maintaining his \nown tree, and people will just flock to that one instead. That's how \nthings *should* work. And that's why I don't want to have too strict a \nhierarchy, or the tools being geared towards a central model.\n\nSo I realize that in practice, when things work reasonably well, you \n*will* have a central repository. At the same time, I want the tools and \nthe infrastructure to support the case when somebody says \"Linus does a \nhorrible job, and I can do better\".\n\nSo I'll fight tooth and nail to show that I'm better and smarter than any \nother kernel maintainer, of course, but I'll do that because I *like* the \ncompetition, not because I make the tools favor me, thank you very much.\n\n\t\t\tLinus\n"},{"id":"36868","messageId":"Pine.LNX.4.63.0703112241040.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7195","inReplyTo":"45F46713.6030702@qumranet.com","subject":"Re: git merge and merge message","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-11T21:41:48Z","receivedAt":"2007-03-11T21:41:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Mar 2007, Avi Kivity wrote:\n\n> Linus Torvalds wrote:\n> > Comments? Do people think it would be a good idea to do\n> > \n> > \tgit merge --no-fast-forward -m \"Merge feature Xyz\" xyz-branch\n> > \n> > as an option?\n> > \n> > \n> \n> Actually there's at least one tree where this should be activated -- \n> yours. If you perform a fast-forward merge, there's no record of the \n> merge, no record of which tree was pulled, and no sign-off from you. \n> The commits just appear there. It partially defeats the sign-off \n> system.\n> \n> This feature would be good for top-level trees and for major subsystem \n> trees IMO.\n\nWhat? You should sign-off on stuff you did not review? Or do you review \nthe stuff _before_ merging? I don't.\n\nCiao,\nDscho\n"},{"id":"36882","messageId":"7vfy8busjv.fsf@assigned-by-dhcp.cox.net","threadId":"7195","inReplyTo":"Pine.LNX.4.63.0703112241040.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git merge and merge message","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-12T02:03:32Z","receivedAt":"2007-03-12T02:03:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> This feature would be good for top-level trees and for major subsystem \n>> trees IMO.\n>\n> What? You should sign-off on stuff you did not review? Or do you review \n> the stuff _before_ merging? I don't.\n\nActually I've done a few merging recently, and I do review the\nstuff before merging. It is easier to review after making a\nmerge, so technically the review happens _after_ merging but if\nI do not like what the other branch has, I can throw it away\nwith \"reset --hard ORIG_HEAD\", which means in practice the\nreview is done before.\n"},{"id":"36885","messageId":"46a038f90703112007y2baf7205v56a1ad4b784e93f0@mail.gmail.com","threadId":"7195","inReplyTo":"Pine.LNX.4.64.0703111309410.9690@woody.linux-foundation.org","subject":"Re: git merge and merge message","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-03-12T03:07:02Z","receivedAt":"2007-03-12T03:07:02Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/12/07, Linus Torvalds wrote:\n> The \"don't merge, just fast-forward\" is the right thing to do for working\n> together. However, I can well imagine that if you actually work with\n> branches not as \"distributed development\", but *just* as \"topic branches\",\n> then having the \"useless\" merge (with the parents actually being parents\n> of each other) migth actually be nice from a documentation standpoint.\n\nWell, actually I do quite a bit of work in private repos, and it is\nmore useful to know *trivially* that the branches are in the same\nplace, and get me and my team into the \"it's about the content,\nstupid\" mindset.\n\nSo after all the flamefesting, I drank the content-is-king koolaid and\nif a pull leads to a fast-forward, I'm happy. If it's a pointless\nmerge I often rebase to linearise.\n\n> I'm torn on this.\n\nMan, you're getting soft in the middle ;-) First, git gets a newline\nconversion option to please windows users that don't use the many GOOD\nprogramming editors that know a unix newline from a UFO (and those are\nthe majority these days, or so I hear). And now _this_! Tsk, tsk!\n\n> I really dislike anything but fast-forward, because I\n> have a strong suspicion that it will cause \"alpha male\" behaviour (where\n> maintainers use the \"useless merge\" as a way to mark their territory),\n> which I think is actually really bad form.\n\nI share your concern. And for Xavier's case ref logs should do the\ntrick anyway.\n\ncheers,\n\n\nm\n"},{"id":"36921","messageId":"45F58D59.7000605@qumranet.com","threadId":"7195","inReplyTo":"Pine.LNX.4.64.0703111348230.9690@woody.linux-foundation.org","subject":"Re: git merge and merge message","fromName":"Avi Kivity","fromEmail":"avi@qumranet.com","sentAt":"2007-03-12T17:26:49Z","receivedAt":"2007-03-12T17:26:49Z","isPatch":false,"sender":{"key":"avi@qumranet.com","avatar":null},"body":"Linus Torvalds wrote:\n> On Sun, 11 Mar 2007, Avi Kivity wrote:\n> \n>> Actually there's at least one tree where this should be activated -- yours.\n>> If you perform a fast-forward merge, there's no record of the merge, no record\n>> of which tree was pulled, and no sign-off from you. The commits just appear\n>> there. It partially defeats the sign-off system.\n>> \n>\n> Well, the thing is, I explicitly don't *want* the merges to show up if \n> it's a fast-forward. \n>\n> Maybe it's just me, and maybe I'm odd, but I have for several years now \n> really thought of Linux development as being this collection of \n> maintainers, rather than being a \"Linus at the top\" kind of situation. \n> \n\nMaybe you are a little odd, but I don't think that it's just you. It's \nquite clear that there are some areas where you don't generally involve \nyourself, and others where you do.\n\n> So yes, obviously I do end up getting a lot of merges attributed to me, \n> simply because *in practice* my tree is generally the top of the food \n> chain, but I think that's a practical issue because people generally want \n> to avoid confusion by having a known maintainer, and it shouldn't be a \n> design thing.\n> \n\nAs it is, whether a merge is recorded or is practically random: if two \nperfectly rebased pull requests come in, one will just appear magically \nin the tree and the other will have a merge record.\n\nYou could make most pulls have no merge record by rebasing them, but \nthat would cause confusion since commits would just appear and it would \nbe impossible to trace them based on the contents of one's tree alone.\n\nI agree it shouldn't be a design thing: I think that on the lower level \nof the \"tree of trees\", people should avoid merge records since they are \njust noise (and indeed most/all maintainers present perfectly groomed \ntrees which have no relation to how development actually happened), but \non the top levels, we need the traceability. We need the record of a \ndecision that was made to pull from X's tree at date Y.\n\n\n> So I dislike the \"hierarchical model\" so much that even though it's true, \n> I don't want to make it even _more_ true. I'd rather make it less true, \n> and at least personally think of Linux development more as a \"network of \n> developers where some people are just more connected than others\". I'm not \n> saying that people are equal (because they aren't), but at the same time I \n> do think that it should be perfectly fine if submaintainers pull from each \n> other if they ever need to - ie pulling should work side-ways and not just \n> up the \"command chain\".\n> \n\n-mm and a few other trees approximate that model. These types of trees \nmostly use quilt, though, which allows an \"editable history\" mode of \noperation.\n\nAs a maintainer, I would be very wary of pulling sideways. There's the \nrisk of the final upstream being very different from what one pulls, and \ntherefore one is left with a pile of conflicts to fix. There's the risk \nof the other tree not being pulled at all, blocking one's own work. I \ndon't even want to think about a \"no single upstream\" mode, that would \nconfuse users in addition to developers.\n\n> So I think the hierarchical thing is largely a social thing, but not one \n> that is necessarily the only way of doing things. \n>\n> And I believe that it might actually be *better* if we were to have some \n> more merging side-ways. Yes, I've been rather involved in kernel \n> development for fifteen years, and I don't really see myself stopping it \n> either, but at the same time, I think that in the really long run, it \n> would be a really interesting experiment to try to run things as a more \n> \"amorphous\" development group of people that just trust each other, than a \n> very hierarchical one.\n> \n\nThe hierarchical model does have advantages: you can always get a \ndecision (it may be the wrong one, but it's better than no decision), \nand more important, it's clear and understandable.\n\n> I realize that it can be useful, and I obviously use the \"merge.summary\" \n> config variable that does make it a non-symmetric situation anyway, and \n> maybe I'm just fighting windmills. It's just that I actually dislike the \n> central repository model so much that I dislike it even when the central \n> repository is *me*.\n>\n> \n\nMaybe you would like it more if the central repository wasn't you :) - \nit really provides a reference frame against which to work, even if it \nis moving all the time. It reduces the risks of working on something \nthat is going away.\n\n-- \nerror compiling committee.c: too many arguments to function\n"},{"id":"36922","messageId":"45F58E5F.5070000@qumranet.com","threadId":"7195","inReplyTo":"Pine.LNX.4.63.0703112241040.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: git merge and merge message","fromName":"Avi Kivity","fromEmail":"avi@qumranet.com","sentAt":"2007-03-12T17:31:11Z","receivedAt":"2007-03-12T17:31:11Z","isPatch":false,"sender":{"key":"avi@qumranet.com","avatar":null},"body":"Johannes Schindelin wrote:\n>>> \n>>> \n>> Actually there's at least one tree where this should be activated -- \n>> yours. If you perform a fast-forward merge, there's no record of the \n>> merge, no record of which tree was pulled, and no sign-off from you. \n>> The commits just appear there. It partially defeats the sign-off \n>> system.\n>>\n>> This feature would be good for top-level trees and for major subsystem \n>> trees IMO.\n>> \n>\n> What? You should sign-off on stuff you did not review? Or do you review \n> the stuff _before_ merging? I don't.\n> \n\nObviously one signs off only after some sort of review. Some merges \nmight be reviewed line-by-line, and some might be reviewed by looking at \nthe maintainer's name and shortlog for a sanity check, but obviously you \ndon't pull blind.\n\nAnyway currently whether a merge record and a sign-off appear is a \nfairly random decision, based on the time of the last rebase the pullee \ndid. Whichever way is chosen (record/no record) I don't think it should \nbe based on that.\n\n\n-- \nerror compiling committee.c: too many arguments to function\n"},{"id":"36988","messageId":"7vfy89ldyv.fsf_-_@assigned-by-dhcp.cox.net","threadId":"7195","inReplyTo":"7vwt1nv6r5.fsf@assigned-by-dhcp.cox.net","subject":"[RFC] git log --first-parent","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-13T08:55:36Z","receivedAt":"2007-03-13T08:55:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> Comments? Do people think it would be a good idea to do\n>>\n>> \tgit merge --no-fast-forward -m \"Merge feature Xyz\" xyz-branch\n>>\n>> as an option?\n>>\n>> \t\t\tLinus\n>\n> For one thing, this would make the earlier \"first parent log\n> summary\" idea useful again.\n\nWhile I was writing \"What's cooking\" tonight, I came up with\nthis patch so that I can view what's in topic branches.\n\nThis time somehow I ended up having to cross merge a few topics\n(e.g. jc/fetch which is the partial C rewrite has been cooking\nlong enough that merging 'master' to get Nico's OBJ_TYPE\ncleanups has become useful), and also 'next' is a pure\nintegration branch, and it turns out that reviewing them with\n\n\t$ git log --first-parent master..jc/fetch\n\nwas easier to view what really was going on on that particular\ntopic, without getting distracted with what was merged from\nsideways.\n\n---\n\ndiff --git a/revision.c b/revision.c\nindex 3c2eb12..8afc196 100644\n--- a/revision.c\n+++ b/revision.c\n@@ -350,6 +350,7 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st\n {\n \tstruct commit_list *parent = commit->parents;\n \tunsigned left_flag;\n+\tint add, rest;\n \n \tif (commit->object.flags & ADDED)\n \t\treturn;\n@@ -395,18 +396,19 @@ static void add_parents_to_list(struct rev_info *revs, struct commit *commit, st\n \t\treturn;\n \n \tleft_flag = (commit->object.flags & SYMMETRIC_LEFT);\n-\tparent = commit->parents;\n-\twhile (parent) {\n+\n+\trest = !revs->first_parent_only;\n+\tfor (parent = commit->parents, add = 1; parent; add = rest) {\n \t\tstruct commit *p = parent->item;\n \n \t\tparent = parent->next;\n-\n \t\tparse_commit(p);\n \t\tp->object.flags |= left_flag;\n \t\tif (p->object.flags & SEEN)\n \t\t\tcontinue;\n \t\tp->object.flags |= SEEN;\n-\t\tinsert_by_date(p, list);\n+\t\tif (add)\n+\t\t\tinsert_by_date(p, list);\n \t}\n }\n \n@@ -836,6 +838,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch\n \t\t\t\thandle_all(revs, flags);\n \t\t\t\tcontinue;\n \t\t\t}\n+\t\t\tif (!strcmp(arg, \"--first-parent\")) {\n+\t\t\t\trevs->first_parent_only = 1;\n+\t\t\t\tcontinue;\n+\t\t\t}\n \t\t\tif (!strcmp(arg, \"--reflog\")) {\n \t\t\t\thandle_reflog(revs, flags);\n \t\t\t\tcontinue;\ndiff --git a/revision.h b/revision.h\nindex 6ae39e6..55e6b53 100644\n--- a/revision.h\n+++ b/revision.h\n@@ -46,7 +46,8 @@ struct rev_info {\n \t\t\tboundary:2,\n \t\t\tleft_right:1,\n \t\t\tparents:1,\n-\t\t\treverse:1;\n+\t\t\treverse:1,\n+\t\t\tfirst_parent_only:1;\n \n \t/* Diff flags */\n \tunsigned int\tdiff:1,\n"},{"id":"36996","messageId":"20070313141750.GA26738@coredump.intra.peff.net","threadId":"7195","inReplyTo":"7vfy89ldyv.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git log --first-parent","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-03-13T14:17:51Z","receivedAt":"2007-03-13T14:17:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 13, 2007 at 01:55:36AM -0700, Junio C Hamano wrote:\n\n> \t$ git log --first-parent master..jc/fetch\n\nYou might recall the 25-way hydra merge I was discussing a few weeks\nago. I ended up simply making a series of pair-wise merges; this\n\"--first-parent\" option is the perfect tool for visualizing it,\nespecially \"gitk --first-parent\". Please consider merging it.\n\n-Peff\n"}]}