{"thread":{"id":"43066","subject":"Re: how to show log for only one branch","startedAt":"2006-11-06T03:41:15Z","lastAt":"2006-11-07T23:36:25Z","messageCount":35,"participants":["Jakub Narebski","Rocco Rutte","Liu Yubao","Junio C Hamano","Linus Torvalds","Andy Whitcroft","Andreas Ericsson","Eran Tromer","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"297486","messageId":"454EAEDB.8020909@gmail.com","threadId":"43066","inReplyTo":null,"subject":"how to show log for only one branch","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-06T03:41:15Z","receivedAt":"2006-11-06T03:41:15Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"I'm some confused by `git log', here is a revision graph:\n\na-----> b ---> c ----------------> f ---> g --- master\n \\ /\n `------> d ----------> e ---- test\n\nI hope `git log ...` shows g, f, c, b, a.\n\n`git log master` shows g, f, e, d, c, b, a;\n`git log master ^test` shows g, f, c.\n`git log --no-merges master` shows g, e, d, c, b, a.\n\nThat's to say, I want to view master, master~1, master~2, master~3, ...\nuntil the beginning, no commits in other branches involved.\n\nI have heard git treats all parents equally in a merge operation, so I\nam curious how git decides which parent is HEAD^1.\n\nI feel the HEAD^1 branch is more special than HEAD^2 branch, because HEAD^1\nis usually the working branch and the target branch of merging operation.\nit's a little more convenient to see only commits that really happen in\ncurrent branch, especially for people who come from CVS and Subversion (yes,\nI think git is more interesting than CVS and Subversion:-).\n"},{"id":"294263","messageId":"7vk629f6is.fsf@assigned-by-dhcp.cox.net","threadId":"43066","inReplyTo":"454EAEDB.8020909@gmail.com","subject":"Re: how to show log for only one branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-06T06:12:11Z","receivedAt":"2006-11-06T06:12:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Liu Yubao writes:\n\n> I have heard git treats all parents equally in a merge operation, so I\n> am curious how git decides which parent is HEAD^1.\n\nThe first parent you see when you do \"git cat-file commit HEAD\"\nis the HEAD^1, the second one is HEAD^2, etc.\n\nWith typical Porcelains (including git-core), when you make a\ntrue merge by pulling another branch while on one branch, the\ntip of the branch you were on when you initiated the merge\nbecomes the HEAD^1 of the resulting merge commit.\n\nHowever, that does not mean HEAD^1 is any special in the global\nhistory. It is only locally special when viewed by you who did\nthe merge, and only immediately after you made the merge. After\na while, even you yourself would feel less special about HEAD^1.\n\nImagine the following scenario.\n\n . You fork off from Linus's tip, and you do a great work on the\n kernel for a while.\n\n o---o---o---o Liu\n /\n ---o Linus\n\n . Linus's tip progresses, and there are semantically some\n overlapping changes; you merge from Linus to make sure your\n great work still works with the updated upstream. This merge\n commit (marked '*' in the picture below) has _your_ last\n change as HEAD^1 and Linus's tip as HEAD^2.\n\n o---o---o---o---* Liu\n / /\n ---o---o---o---o---o Linus\n\n . It still works great and you let Linus know about your great\n work. He likes it and pulls from you.\n\nAt this point, the revision history would still look like this:\n\n o---o---o---o---* Liu = Linus\n / /\n ---o---o---o---o---o\n\nThat is, the DAG did not change since you pulled from Linus.\nThe only thing that changed was that Linus's tip now points at\nthe merge commit _you_ made.\n\nThen Linus keeps working, building commits on top of that merge.\n\n Liu\n o---o---o---o---*---o---o---o---o Linus\n / /\n ---o---o---o---o---o\n\nNow, we can say two things about this history.\n\nIf you view the development community \"centered around Linus\",\nthen when somebody looks back the history from Linus's tip,\nwhatever great work you did, that is merely \"one of the many\ncontributions from many people\". The \"mainline\" from this point\nof view is still \"what Linus saw at each point as the tip of his\ndevelopment track\", and among the commits you made (the ones\nbetween the fork point and '*' in the above picture), the last\none, the merge you made was the only one that was once the tip\nof Linus; everything else was \"random work that happend in a\nside branch\". But HEAD^1 is not special if you wanted to have\nthis view.\n\nIn massively parallel and distributed development, whose track\nof development is \"mainline\" is not absolute, and it all depends\non what you are interested in when you do the archaeology.\nLet's say that your work on the side branch was in one specific\narea (say, a device driver work for product X), and nobody\nelse's work in that area appeared on Linus's development track\nsince you forked until your work was merged.\n\nTo somebody who is digging from Linus's tip in order to find out\nhow that driver evolved, your side branch is much more important\nthan what happened on Linus's branch (which everybody would\nloosely say _the_ \"mainline\"). On the other hand, when somebody\nis interested in some other area that was worked on in Linus's\ndevelopment track while your work was done in the side branch,\nfollowing your development track is not interesting; and the\nperson who is interested in this \"other area\" could be you. In\nthat case, you would want to follow Linus's development track.\n\nWhat's mainline is _not_ important, and which parent is first is\neven less so. It solely depends on what you are looking for\nwhich branch matters more. Putting too much weight on the\ndifference between HEAD^1 vs HEAD^2 statically does not make any\nsense.\n\nReflecting this view of history, git log and other history\ntraversal commands treat merge parents more or less equally, and\n_how_ you ask your question affects what branches are primarily\nfollowed. For example, if somebody is interested in your device\ndriver work, this command:\n\n\tgit log -- drivers/liu-s-device/\n\nwould follow your side branch. On the other hand,\n\n\tgit log -- fs/\n\nwould follow Linus's development track while you were forked, if\nyou did not do any fs/ work while on that side branch and\nLinus's development track had works in that area, _despite_ the\nmerge you gave Linus has your development track as its first\nparent.\n"},{"id":"294118","messageId":"454F1175.9080506@gmail.com","threadId":"43066","inReplyTo":"7vk629f6is.fsf@assigned-by-dhcp.cox.net","subject":"Re: how to show log for only one branch","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-06T10:41:57Z","receivedAt":"2006-11-06T10:41:57Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> Liu Yubao writes:\n> \n\nSnip many great detailed description, thank you very much, I have\na question about the way git treats fast forwarding but that will\nbe another topic.\n\n> What's mainline is _not_ important, and which parent is first is\n> even less so. It solely depends on what you are looking for\n> which branch matters more. Putting too much weight on the\n> difference between HEAD^1 vs HEAD^2 statically does not make any\n> sense.\n> \n> Reflecting this view of history, git log and other history\n> traversal commands treat merge parents more or less equally, and\n> _how_ you ask your question affects what branches are primarily\n> followed. For example, if somebody is interested in your device\n> driver work, this command:\n> \n> \tgit log -- drivers/liu-s-device/\n> \n> would follow your side branch. On the other hand,\n> \n> \tgit log -- fs/\n> \n> would follow Linus's development track while you were forked, if\n> you did not do any fs/ work while on that side branch and\n> Linus's development track had works in that area, _despite_ the\n> merge you gave Linus has your development track as its first\n> parent.\n> \n\nThis is perfect and enough for two branches that work on different\nfiles, but if two branches modify same files, \"git log\" can't separate\ncommits clearly. For example, I want to know what happened in your\ngit's \"next\" branch, I hope to get logs like this:\n Merge branch 'jc/pickaxe' into next\n Merge branch 'master' into next\n Merge branch 'js/modfix' into next\n ...\n some good work\n ...\n Merge branch ....\n\nI just want to *outline* what happened in \"next\" branch, if I am interested\nin what have been merged from 'jc/pickaxe' I can follow the merge point again\nor use something like \"git log --follow-all-parents\".\n\nInstead, \"git log\" interlaces logs from many branches, I find it's a little\nconfused: why does \"git log\" of current branch contain many logs from other \nbranches? (This is not a real question, I know the reason)\n\nI indeed understand that HEAD^1 is not always the commit that my work\nbases on before a merge (thanks for your detailed description again:-),\nit doesn't make sense to show HEAD~1, HEAD~2, HEAD~3 and so on, that's\nto say 'git log' will never meet my requirement.\n\nMaybe reflog is what I need, I want to know which commits \"next\" have pointed\nto, but reflog is only for local purpose, it's not downloaded by 'git clone'\n"},{"id":"294951","messageId":"454F31D7.1030202@gmail.com","threadId":"43066","inReplyTo":"7vk629f6is.fsf@assigned-by-dhcp.cox.net","subject":"If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-06T13:00:07Z","receivedAt":"2006-11-06T13:00:07Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Thanks to Junio for his patient explanation about branches in git, I find \nthere is a subtle difference between GIT and regular VCS that can be easily\nneglected by newbies.\n\nI realize that git is a *content tracker*, it only creates commit object\nwhen the corresponding tree is really modified, git records content merging\nbut not usual merging operation, that's why git is called a content tracker.\nThis explains why a merging that is really a fast forwarding doesn't create\nany new commit.\n\nThis feature is different from many regular VCS like CVS and Subversion and\nconfuses newbies that come from them: mainline doesn't make sense too much,\n'git log' shows many logs from other branches. In git, a branch is almost a\ntag, you can't get the *track* of a branch(It's a pity reflog is only for\nlocal purpose). I am used to one-trunk-and-more-side-branches way, every\nbranches are isolated clearly, git makes me very confused at the beginning.\n\n\nThen, what bad *logical* problem will happen if a merging that is really a \nfast forwarding creates a new commit?\n\nIf we throw away all compatibility, efficiency, memory and disk consumption\nproblems,\n(1) we can get the track of a branch without reflog because HEAD^1 is\nalways the tip of target branch(or working branch usually) before merging.\n\n(2) with the track, branch mechanism in git is possibly easier to understand,\nespecially for newbies from CVS or Subversion, I really like git's light \nweight, simple but powerful design and great efficiency, but I am really\nsurprised that 'git log' shows logs from other branches and a side branch can \nbecome part of main line suddenly.\n\nA revision graph represents fast forwarding style merging like this:\n\n (fast forwarding)\n ---- a ............ * ------> master\n \\ /\n b----------c -----> test (three commits with three trees)\n\ncan be changed to:\n\n ---- a (tree_1) ----------- d (tree_3) ------> master\n \\ /\n b (tree_2) ------- c (tree_3) ----> test\n(four commits with three trees, it's normal as more than one way can reach \nRome :-)\n\n\nI don't think I am smarter than any people in this mailing list, in fact\nI am confused very much by GIT's branches at the beginning. There must\nbe many problems I haven't realized, I am very curious about them, any\n"},{"id":"293836","messageId":"20061106133923.GB1151@robert.daprodeges.fqdn.th-h.de","threadId":"43066","inReplyTo":"454F31D7.1030202@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit","fromName":"Rocco Rutte","fromEmail":"pdmef@gmx.net","sentAt":"2006-11-06T13:39:23Z","receivedAt":"2006-11-06T13:39:23Z","isPatch":false,"sender":{"key":"pdmef@gmx.net","avatar":null},"body":"Hi,\n\n* Liu Yubao [06-11-06 21:00:07 +0800] wrote:\n\n>Then, what bad *logical* problem will happen if a merging that is really a fast forwarding creates a new commit?\n\nI don't know what you expect by \"logical\" nor if I get you right, but if \nfast-forward merge a branch to another one, both branches now have \nexactly the same hash. If you create a commit object for a fast-forward \nmerge, both tip hashes not identical anymore... which is bad.\n\nThe identical hash important so that you really know they're identical \nand for future reference like ancestry.\n\n bye, Rocco\n-- \n"},{"id":"295905","messageId":"454F3BED.9010401@op5.se","threadId":"43066","inReplyTo":"454F31D7.1030202@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-06T13:43:09Z","receivedAt":"2006-11-06T13:43:09Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Liu Yubao wrote:\n> Thanks to Junio for his patient explanation about branches in git, I \n> find there is a subtle difference between GIT and regular VCS that can \n> be easily\n> neglected by newbies.\n> \n> I realize that git is a *content tracker*, it only creates commit object\n> when the corresponding tree is really modified, git records content merging\n> but not usual merging operation, that's why git is called a content \n> tracker.\n> This explains why a merging that is really a fast forwarding doesn't create\n> any new commit.\n> \n> This feature is different from many regular VCS like CVS and Subversion and\n> confuses newbies that come from them: mainline doesn't make sense too much,\n> 'git log' shows many logs from other branches. In git, a branch is almost a\n> tag, you can't get the *track* of a branch(It's a pity reflog is only for\n> local purpose). I am used to one-trunk-and-more-side-branches way, every\n> branches are isolated clearly, git makes me very confused at the beginning.\n> \n> \n> Then, what bad *logical* problem will happen if a merging that is really \n> a fast forwarding creates a new commit?\n> \n\nIf \"fake\" commits (i.e., commits that doesn't change any content) are \nintroduced for each merge, it will change the ancestry graph and the \nresulting tree(s) won't be mergable with the tree it merged with, \nbecause each such \"back-merge\" would result in\n* the \"fake\" commit becoming part of history\n* a new \"fake\" commit being introduced\n\nConsider what happens when Alice pulls in Bob's changes. The merge-base \nof Bob's tip is where Alice HEAD points to, so it results in a \nfast-forward, like below.\n\na---b---c---d <--- Alice\n \\\n e---f---g <--- Bob\n\n\nIf, we would have created a fake commit instead, Alice would get a graph \nthat looks like so:\n\na---b---c---d-----------h <--- Alice\n \\ /\n e---f---g <--- Bob\n\n\nNow, we would have two trees that are identical, because the merge can't \ncause conflicts, but Alice and Bob will have reached it in two different \nways. When Bob decides he wants to go get the changes Alice has done, \nhis tree will look something like this:\n\na---b---c---d-----------h <--- Alice\n \\ / \\\n e---f---g---i <--- Bob\n\n\nHe finds it odd that he's got two commits that, when checked out, lead \nto the exact same tree, so he asks Alice to get his tree and see what's \ngoing on. Alice will then end up with this:\n\na---b---c---d-----------h---j <--- Alice\n \\ / \\ /\n e---f---g---i <--- Bob\n\n\nNow there's four commits that all point to identical trees, but the \nancestry graphs differ between all developers. In the case above, \nthere's only two people working at the same project. Imagine the amount \nof empty commits you'd get in a larger project, like the Linux kernel.\n\nFast-forward is a Good Thing and the only sensible thing to do in a \nsystem designed to be fully distributed (i.e., where there isn't \nnecessarily any middle point with which everybody syncs), while scaling \nbeyond ten developers that merge frequently between each other.\n\n> If we throw away all compatibility, efficiency, memory and disk consumption\n> problems,\n> (1) we can get the track of a branch without reflog because HEAD^1 is\n> always the tip of target branch(or working branch usually) before merging.\n> \n> (2) with the track, branch mechanism in git is possibly easier to \n> understand,\n> especially for newbies from CVS or Subversion, I really like git's light \n> weight, simple but powerful design and great efficiency, but I am really\n> surprised that 'git log' shows logs from other branches and a side \n> branch can become part of main line suddenly.\n> \n> A revision graph represents fast forwarding style merging like this:\n> \n> (fast forwarding)\n> ---- a ............ * ------> master\n> \\ /\n> b----------c -----> test (three commits with three trees)\n> \n> can be changed to:\n> \n> ---- a (tree_1) ----------- d (tree_3) ------> master\n> \\ /\n> b (tree_2) ------- c (tree_3) ----> test\n> (four commits with three trees, it's normal as more than one way can \n> reach Rome :-)\n> \n\nThat's where our views differ. In my eyes, \"d\" and \"c\" are exactly \nidentical, and I'd be very surprised if the scm tried to tell me that \nthey aren't, by not giving them the same revid.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"295657","messageId":"eink3u$pmh$1@sea.gmane.org","threadId":"43066","inReplyTo":"454EAEDB.8020909@gmail.com","subject":"Re: how to show log for only one branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-06T15:25:24Z","receivedAt":"2006-11-06T15:25:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Perhaps what you want is git log --committer=?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297511","messageId":"Pine.LNX.4.64.0611060734490.25218@g5.osdl.org","threadId":"43066","inReplyTo":"454F31D7.1030202@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-06T15:48:05Z","receivedAt":"2006-11-06T15:48:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 6 Nov 2006, Liu Yubao wrote:\n> \n> Then, what bad *logical* problem will happen if a merging that is really a\n> fast forwarding creates a new commit?\n\nYou MUST NOT do that.\n\nIf a fast-forward were to do a \"merge commit\", you'd never get into the \nsituation where two people merging each other would really ever get a \nstable result. They'd just keep doing merge commits on top of each other.\n\nGit tracks history, not \"your view of history\". Trying to track \"your \nview\" is fundamentally wrong, because \"your wiew\" automatically means that \nthe project history would not be distributed any more - it would be \ncentralized around what _you_ think happened. That is not a sensible thing \nto have in a distributed system.\n\nFor example, the way to break the \"infinite merges\" problem above is to \nsay that _you_ would be special, and you would do a \"fast-forward commit\", \nand the other side would always just fast-forward without a commit. But \nthat is very fundamentally against the whole point of being distributed. \nNow you're special.\n\nIn fact, even for \"you\", it would be horrible - because you personally \nmight have 5 different repositories on five different machines. You'd have \nto select _which_ machine you want to track. That's simply insane. It's a \ntotally broken model. (You can even get the same situation with just _one_ \nrepository, by just having five different branches - you have to decide \nwhich one is the \"main\" branch).\n\nBesides, doing an empty commit like that (\"I fast forwarded\") literally \ndoesn't add any true history information. It literally views history not \nas history of the _project_, but as the history of just one of the \nrepositories. And that's wrong.\n\nSo just get used to it. You MUST NOT do what you want to do. It's stupid.\n\nIf you want to track the history of one particular local branch, use the \n\"reflog\" thing. It allows you to see what one of your local branches \ncontained at any particular time.\n\nSee\n\n\t[core]\n\t\tlogAllRefUpdates = true\n\ndocumentation in \"man git-update-refs\" (and maybe somebody can write more \nabout it?)\n\n"},{"id":"297441","messageId":"46a038f90611060803o653b5b8cx44d3adcfda699ec5@mail.gmail.com","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611060734490.25218@g5.osdl.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-11-06T16:03:21Z","receivedAt":"2006-11-06T16:03:21Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 11/6/06, Linus Torvalds wrote:\n> On Mon, 6 Nov 2006, Liu Yubao wrote:\n> > Then, what bad *logical* problem will happen if a merging that is really a\n> > fast forwarding creates a new commit?\n> You MUST NOT do that.\n>\n> If a fast-forward were to do a \"merge commit\", you'd never get into the\n> situation where two people merging each other would really ever get a\n> stable result. They'd just keep doing merge commits on top of each other.\n\nIndeed. I used Arch for quite a while and if you were merging between\n2 or more repos it would never reach a stable point even if the code\ndidn't change at all.\n\nIf a group of 3 developers (with one repor per developer) was\ndeveloping at a slow pace (say, a daily commit each, plus a couple of\npull/updates per day) the garbage-commit to content-commit ratio was\nawful. If on a given day noone had made a single commit, we'd still\nhave a whole set of useless updates merged and committed.\n\n> Besides, doing an empty commit like that (\"I fast forwarded\") literally\n> doesn't add any true history information.\n\nAnd as the number of developers and repos grows in a distributed\nscenarios, fast-forwards increasingly outnumber real commits. The\nusefulness of your logs sinks to the sewers.\n\ncheers,\n\n\n"},{"id":"297141","messageId":"Pine.LNX.4.64.0611060928180.3667@g5.osdl.org","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611060734490.25218@g5.osdl.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-06T17:48:24Z","receivedAt":"2006-11-06T17:48:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 6 Nov 2006, Linus Torvalds wrote:\n> \n> Besides, doing an empty commit like that (\"I fast forwarded\") literally \n> doesn't add any true history information. It literally views history not \n> as history of the _project_, but as the history of just one of the \n> repositories. And that's wrong.\n> \n> So just get used to it. You MUST NOT do what you want to do. It's stupid.\n\nBtw, absolutely the _only_ reason people seem to want to do this is \nbecause they want to \"pee in the snow\" and put their mark on things. They \nseem to want to show \"_I_ did this\", even if the \"doing\" was a total \nno-op and they didn't actually generate any real value.\n\nThat's absolutely the last thing you want to encourage, especially when \nthe end result is a history that is totally unreadable and contains more \n\"junk\" than actual real work. \n\nI'll be the first to say that \"merging code\" is often as important as \nactually writing the code in the first place, and that it is important to \nshow who actually did real work to make a patch appear in a project.\n\nIn the kernel, for example, we have \"sign-off\" lines to show what route a \npatch took before it was accepted, and it's very instructive to see (for \nexample) how man patches give credit to somebody like Andrew Morton for \npassing it on versus actually writing the code himself (he has a lot of \nauthorship credit too, but it's absolutely _dwarfed_ by his importance as \na maintainer - and if you were to ask any random kernel developer why \nAndrew is so important, I can pretty much guarantee that his importance is \nvery much about those \"sign-offs\", and not about the patches he authors).\n\nBut at the same time, when it comes to merging, because it actually \nclutters up history a lot, we actively try to _avoid_ it. Many subsystem \nmaintainers purposefully re-generate a linear history, rebased on top of \nmy current kernel, exactly because it makes the history less \"branchy\", \nand because that makes things easier to see.\n\nSo we have actually done work to _encourage_ fast-forwarding over \"merge \nwith a commit\", because the fast-forwarding ends up generating a much more \nreadable and understandable history. Generating a _fake_ \"merge commit\" \nwould be absolutely and utterly horrible. It gives fake credit for work \nthat wasn't real work, and it makes history uglier and harder to read. \n\nSo it's a real NEGATIVE thing to have, and you should run away from it as \nfast as humanly possible.\n\nNow, the kernel actually ends up being fairly branchy anyway, but that's \nsimply because we actually have a lot of real parallel development (I bet \nmore than almost any other project out there - we simply have more commits \ndone by more people than most projects). I tend to do multiple merges a \nday, so even though people linearize their history individually, you end \nup seeing a fair amount of merges. But we'd have a lot _more_ of them if \npeople didn't try to keep history clean.\n\nBtw, in the absense of a merge, you can still tell who committed \nsomething, exactly because git keeps track of \"committer\" information in \naddition to \"authorship\" information. I don't understand why other \ndistributed environments don't seem to do this - because separating out \nwho committed something (and when) from who authored it (and when) is \nactually really really important.\n\nAnd that's not just because we use patches and other SCM's than just git \nto track things (so authorship and committing really are totally separate \nissues), but because even if the author and committer is the same person, \nit's very instructive to realize that it might have been moved around in \nhistory, so it might actually have been cherry-picked later, and the \ncommitter date differs from the author date even if the actual author and \ncommitter are the same person (but you might also have had somebody _else_ \nre-linearize or otherwise cherry-pick the history: again, it's important \nto show the committer _separately_ both as a person and as a date).\n\nAnd because there is a committer field, if you actually want to linearize \nor log things by who _committed_ stuff, you can. Just do\n\n\tgit log --committer=torvalds\n\non the kernel, and you can see the log as it pertains for what _I_ \ncommitted, for example. You can even show it graphically, although it \nwon't be a connected graph any more, so it will tend to be very ugly \n(but you'll see the \"linear stretches\" when somebody did some work). Just \ndo \"gitk --committer=myname\" to see in your own project.\n\n"},{"id":"297802","messageId":"7vslgwcueo.fsf@assigned-by-dhcp.cox.net","threadId":"43066","inReplyTo":"454F1175.9080506@gmail.com","subject":"Re: how to show log for only one branch","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-06T18:16:47Z","receivedAt":"2006-11-06T18:16:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Liu Yubao writes:\n\n> ... For example, I want to know what happened in your\n> git's \"next\" branch, I hope to get logs like this:\n> Merge branch 'jc/pickaxe' into next\n> Merge branch 'master' into next\n> Merge branch 'js/modfix' into next\n> ...\n> some good work\n> ...\n> Merge branch ....\n>\n> I just want to *outline* what happened in \"next\" branch, if I am interested\n> in what have been merged from 'jc/pickaxe' I can follow the merge point again\n> or use something like \"git log --follow-all-parents\".\n\nMy \"next\" is a bad example of this, because it is an integration\nbranch and never gets its own development. It is also a bad\nexample because I can answer that question with this command\nline:\n\n\tgit log --grep='^Merge .* into next$' next\n\nand while it is a perfectly valid answer, I know it would leave\nyou feeling somewhat cheated.\n\n\n"},{"id":"297197","messageId":"454FEDA5.1050607@gmail.com","threadId":"43066","inReplyTo":"7vslgwcueo.fsf@assigned-by-dhcp.cox.net","subject":"Re: how to show log for only one branch","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T02:21:25Z","receivedAt":"2006-11-07T02:21:25Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> Liu Yubao writes:\n> \n>> ... For example, I want to know what happened in your\n>> git's \"next\" branch, I hope to get logs like this:\n>> Merge branch 'jc/pickaxe' into next\n>> Merge branch 'master' into next\n>> Merge branch 'js/modfix' into next\n>> ...\n>> some good work\n>> ...\n>> Merge branch ....\n>>\n>> I just want to *outline* what happened in \"next\" branch, if I am interested\n>> in what have been merged from 'jc/pickaxe' I can follow the merge point again\n>> or use something like \"git log --follow-all-parents\".\n> \n> My \"next\" is a bad example of this, because it is an integration\n> branch and never gets its own development. It is also a bad\n> example because I can answer that question with this command\n> line:\n> \n> \tgit log --grep='^Merge .* into next$' next\n> \n> and while it is a perfectly valid answer, I know it would leave\n> you feeling somewhat cheated.\n> \nsmart trick, but if the logs aren't consistent enough it's hard to\ngrep them out.\n\n"},{"id":"298646","messageId":"454FFCE6.70408@gmail.com","threadId":"43066","inReplyTo":"454F3BED.9010401@op5.se","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T03:26:30Z","receivedAt":"2006-11-07T03:26:30Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Andreas Ericsson wrote:\n> Liu Yubao wrote:\n> \n> If \"fake\" commits (i.e., commits that doesn't change any content) are \n> introduced for each merge, it will change the ancestry graph and the \n> resulting tree(s) won't be mergable with the tree it merged with, \n> because each such \"back-merge\" would result in\n> * the \"fake\" commit becoming part of history\n> * a new \"fake\" commit being introduced\n> \n> Consider what happens when Alice pulls in Bob's changes. The merge-base \n> of Bob's tip is where Alice HEAD points to, so it results in a \n> fast-forward, like below.\n> \n> a---b---c---d <--- Alice\n> \\\n> e---f---g <--- Bob\n> \n> \n> If, we would have created a fake commit instead, Alice would get a graph \n> that looks like so:\n> \n> a---b---c---d-----------h <--- Alice\n> \\ /\n> e---f---g <--- Bob\n> \n> \n> Now, we would have two trees that are identical, because the merge can't \n> cause conflicts, but Alice and Bob will have reached it in two different \n> ways. When Bob decides he wants to go get the changes Alice has done, \n> his tree will look something like this:\n> \n> a---b---c---d-----------h <--- Alice\n> \\ / \\\n> e---f---g---i <--- Bob\n> \n> \n> He finds it odd that he's got two commits that, when checked out, lead \n> to the exact same tree, so he asks Alice to get his tree and see what's \n> going on. Alice will then end up with this:\n> \n> a---b---c---d-----------h---j <--- Alice\n> \\ / \\ /\n> e---f---g---i <--- Bob\n> \n> \n> Now there's four commits that all point to identical trees, but the \n> ancestry graphs differ between all developers. In the case above, \n> there's only two people working at the same project. Imagine the amount \n> of empty commits you'd get in a larger project, like the Linux kernel.\n> \nOh, you remind me, but I have a naive solution for this problem: print\na hint and don't merge commits that contain fake commit, then I know I have\nreached a stable merge point and have same tree with others.\n\nWe create a fake commit for fast forwarding style merge, this fake commit\nis used to record the track of a branch, so we can always follow HEAD^1\nto travel through the history of a branch. In fact, git pays more attention\nto the history of *data modification* than history of *operation*, that is\nright the subtle difference between content tracker and VCS, latter's branch \nhas more information(useful information, I think).\n\nEven if no fake commit is created as git does now, there can be multiple\ncommits with identical tree object, and git can't prevent you from merging\ntwo commits with identical tree object, it just creates an ancestry relation\nto remember the merge point.\n\nAs git(7) says:\n The \"commit\" object is an object that introduces the notion\n of history into the picture. In contrast to the other objects,\n it doesn't just describe the physical state of a tree, it\n describes how we got there, and why.\n\nSo it's clearer to describe a revision graph with nodes for tree\nobjects and edges for commit objects(multiple edges for a merge\ncommit object, I know this will break your habit:-).\n\n> Fast-forward is a Good Thing and the only sensible thing to do in a \n> system designed to be fully distributed (i.e., where there isn't \n> necessarily any middle point with which everybody syncs), while scaling \n> beyond ten developers that merge frequently between each other.\n> \n>> If we throw away all compatibility, efficiency, memory and disk \n>> consumption\n>> problems,\n>> (1) we can get the track of a branch without reflog because HEAD^1 is\n>> always the tip of target branch(or working branch usually) before \n>> merging.\n>>\n>> (2) with the track, branch mechanism in git is possibly easier to \n>> understand,\n>> especially for newbies from CVS or Subversion, I really like git's \n>> light weight, simple but powerful design and great efficiency, but I \n>> am really\n>> surprised that 'git log' shows logs from other branches and a side \n>> branch can become part of main line suddenly.\n>>\n>> A revision graph represents fast forwarding style merging like this:\n>>\n>> (fast forwarding)\n>> ---- a ............ * ------> master\n>> \\ /\n>> b----------c -----> test (three commits with three trees)\n>>\n>> can be changed to:\n>>\n>> ---- a (tree_1) ----------- d (tree_3) ------> master\n>> \\ /\n>> b (tree_2) ------- c (tree_3) ----> test\n>> (four commits with three trees, it's normal as more than one way can \n>> reach Rome :-)\n>>\n> \n> That's where our views differ. In my eyes, \"d\" and \"c\" are exactly \n> identical, and I'd be very surprised if the scm tried to tell me that \n> they aren't, by not giving them the same revid.\nIt doesn't matter, they have same tree, and it's normal too in git\nmultiple commits have same tree, if you use nodes for tree state,\nthat graph will be simple to understand:\n\n a d\n -----tree_1 -------------- tree_3 ----> master\n \\ / \\\n \\ b d/c `-----> test\n \\ /\n `--- tree_2 ---'\n\nThis is the familiar way we used in CVS, I believe there are more\nthan one people confused by fast forwarding style merge and 'git log'\n"},{"id":"298304","messageId":"4550008F.8030809@gmail.com","threadId":"43066","inReplyTo":"20061106133923.GB1151@robert.daprodeges.fqdn.th-h.de","subject":"Re: If merging that is really fast forwarding creates new commit","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T03:42:07Z","receivedAt":"2006-11-07T03:42:07Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Rocco Rutte wrote:\n> Hi,\n> \n> * Liu Yubao [06-11-06 21:00:07 +0800] wrote:\n> \n>> Then, what bad *logical* problem will happen if a merging that is \n>> really a fast forwarding creates a new commit?\n> \n> I don't know what you expect by \"logical\" nor if I get you right, but if \n> fast-forward merge a branch to another one, both branches now have \n> exactly the same hash. If you create a commit object for a fast-forward \n> merge, both tip hashes not identical anymore... which is bad.\nNot so bad, you can know they point to same tree objects.\n\nFast forwarding style merge will blow away the *track* of your branch,\nand this track is useful, that is why reflog appears.\n> \n> The identical hash important so that you really know they're identical \n> and for future reference like ancestry.\nI guess you have mixed identical commits with identical trees. Trees\nis what we really need.\n\nFake commit doesn't mess the ancestry relation, you can refer to\nmy previous mail replied to Andreas Ericsson in this topic.\n> \n> bye, Rocco\n"},{"id":"293863","messageId":"455001EA.5040306@gmail.com","threadId":"43066","inReplyTo":"eink3u$pmh$1@sea.gmane.org","subject":"Re: how to show log for only one branch","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T03:47:54Z","receivedAt":"2006-11-07T03:47:54Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Jakub Narebski wrote:\n> Perhaps what you want is git log --committer=?\n> \nThanks, it can't meet my requirement, if I create two branches\nand merge them, I can't easily tell the track of those two branches.\n"},{"id":"297007","messageId":"45503553.3020605@gmail.com","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611060734490.25218@g5.osdl.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T07:27:15Z","receivedAt":"2006-11-07T07:27:15Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Mon, 6 Nov 2006, Liu Yubao wrote:\n>> Then, what bad *logical* problem will happen if a merging that is really a\n>> fast forwarding creates a new commit?\n> \n> You MUST NOT do that.\n> \n> If a fast-forward were to do a \"merge commit\", you'd never get into the \n> situation where two people merging each other would really ever get a \n> stable result. They'd just keep doing merge commits on top of each other.\nThey can stop merging a fake commit with a real commit that point to same\ntree object, here they reach a stable result: we have same tree content.\n> \n> Git tracks history, not \"your view of history\". Trying to track \"your \n> view\" is fundamentally wrong, because \"your wiew\" automatically means that \n> the project history would not be distributed any more - it would be \n> centralized around what _you_ think happened. That is not a sensible thing \n> to have in a distributed system.\nIt's not my view, it's branch scope view, I can see how a branch evolves\nrelatively independently. In git, branch scope view is more or less neglected.\nAfter fast forwarding merge, I can' tell where a branch come from -- I mean\nthe track of a branch.\n\nIf Junio publishes his reflog, I don't see what conflict will happen between\nhis local view (but now public, and naming it branch scope view seems more\nsensible) and git's global view.\n\nIf this won't lead to problems, it seems also ok to use fake commit for\nfast forwarding style merge, so we can follow HEAD^1 to travel through a\nbranch without reflog.\n\nI hope I have expressed my thought clearly.\n> \n> For example, the way to break the \"infinite merges\" problem above is to \n> say that _you_ would be special, and you would do a \"fast-forward commit\", \n> and the other side would always just fast-forward without a commit. But \n> that is very fundamentally against the whole point of being distributed. \n> Now you're special.\nNo one is special as everybody can create fake commit, any branch (almost\na tag) will never be overwritten to point to a commit object in\nanother branch, branches are relatively independent, that's to say\n'git log' will reflect what has happened really in current branch (a CVS\nsemantical branch, not only a tag that always points to a tip commit).\n> \n> In fact, even for \"you\", it would be horrible - because you personally \n> might have 5 different repositories on five different machines. You'd have \n> to select _which_ machine you want to track. That's simply insane. It's a \n> totally broken model. (You can even get the same situation with just _one_ \n> repository, by just having five different branches - you have to decide \n> which one is the \"main\" branch).\nWhat's the mean of upstream branch then? I have to know I should track\nJunio's public repository.\n\nWhen does one say two branches reach a common point? have same commit(must\npoint to same tree) or have same tree(maybe a fake commit and a real commit)?\nI think git takes the first way.\n\nFast forwarding style merge tends to *automatically* centralize many\nbranches, in CVS people merge two branches and drop side branch to\ncentralize them, they all have central semantics.\n(I don't want to get flame war between CVS/SVN and GIT, I think\ngit is better than them really:-)\n> \n> Besides, doing an empty commit like that (\"I fast forwarded\") literally \n> doesn't add any true history information. It literally views history not \n> as history of the _project_, but as the history of just one of the \n> repositories. And that's wrong.\nSomething like 'git log --follow-all-parent' can show history of the project\nas 'git log' does now.\n> \n> So just get used to it. You MUST NOT do what you want to do. It's stupid.\nYes, I have understood the git way and am getting used to it, I like\nits simple but powerful design and great efficiency, thank all for your\ngood work!\n> \n> If you want to track the history of one particular local branch, use the \n> \"reflog\" thing. It allows you to see what one of your local branches \n> contained at any particular time.\n> \n> See\n> \n> \t[core]\n> \t\tlogAllRefUpdates = true\n> \nThanks, it's a pity I can't pull Junio's reflog :-(\n> documentation in \"man git-update-refs\" (and maybe somebody can write more \n> about it?)\n> \n> \t\tLinus\n> \n"},{"id":"293902","messageId":"45503CFC.7000403@gmail.com","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611060928180.3667@g5.osdl.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T07:59:56Z","receivedAt":"2006-11-07T07:59:56Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Mon, 6 Nov 2006, Linus Torvalds wrote:\n>> Besides, doing an empty commit like that (\"I fast forwarded\") literally \n>> doesn't add any true history information. It literally views history not \n>> as history of the _project_, but as the history of just one of the \n>> repositories. And that's wrong.\n>>\n>> So just get used to it. You MUST NOT do what you want to do. It's stupid.\n> \n> Btw, absolutely the _only_ reason people seem to want to do this is \n> because they want to \"pee in the snow\" and put their mark on things. They \n> seem to want to show \"_I_ did this\", even if the \"doing\" was a total \n> no-op and they didn't actually generate any real value.\n\nWe can kick out fake commits when calculate credits, we can grep logs with\nauthor name to see what he/she has done.\n\nFake commit is only for digging branch scope history, I can *outline* what has\nbeen merged to a branch and don't care about how these good work are done on \nearth.\n\n> \n> That's absolutely the last thing you want to encourage, especially when \n> the end result is a history that is totally unreadable and contains more \n> \"junk\" than actual real work. \n> \n> I'll be the first to say that \"merging code\" is often as important as \n> actually writing the code in the first place, and that it is important to \n> show who actually did real work to make a patch appear in a project.\n> \n> In the kernel, for example, we have \"sign-off\" lines to show what route a \n> patch took before it was accepted, and it's very instructive to see (for \n> example) how man patches give credit to somebody like Andrew Morton for \n> passing it on versus actually writing the code himself (he has a lot of \n> authorship credit too, but it's absolutely _dwarfed_ by his importance as \n> a maintainer - and if you were to ask any random kernel developer why \n> Andrew is so important, I can pretty much guarantee that his importance is \n> very much about those \"sign-offs\", and not about the patches he authors).\n> \n> But at the same time, when it comes to merging, because it actually \n> clutters up history a lot, we actively try to _avoid_ it. Many subsystem \n> maintainers purposefully re-generate a linear history, rebased on top of \n> my current kernel, exactly because it makes the history less \"branchy\", \n> and because that makes things easier to see.\n> \n> So we have actually done work to _encourage_ fast-forwarding over \"merge \n> with a commit\", because the fast-forwarding ends up generating a much more \n> readable and understandable history. Generating a _fake_ \"merge commit\" \n> would be absolutely and utterly horrible. It gives fake credit for work \n> that wasn't real work, and it makes history uglier and harder to read. \n> \n> So it's a real NEGATIVE thing to have, and you should run away from it as \n> fast as humanly possible.\n> \n> Now, the kernel actually ends up being fairly branchy anyway, but that's \n> simply because we actually have a lot of real parallel development (I bet \n> more than almost any other project out there - we simply have more commits \n> done by more people than most projects). I tend to do multiple merges a \n> day, so even though people linearize their history individually, you end \n> up seeing a fair amount of merges. But we'd have a lot _more_ of them if \n> people didn't try to keep history clean.\n\nThat's right the central semantics I have said, git tends to and recommends\na trunk mode development *on a high level*. It's not a bad thing.\n\n> \n> Btw, in the absense of a merge, you can still tell who committed \n> something, exactly because git keeps track of \"committer\" information in \n> addition to \"authorship\" information. I don't understand why other \n> distributed environments don't seem to do this - because separating out \n> who committed something (and when) from who authored it (and when) is \n> actually really really important.\n\nYes, agree.\n\n> \n> And that's not just because we use patches and other SCM's than just git \n> to track things (so authorship and committing really are totally separate \n> issues), but because even if the author and committer is the same person, \n> it's very instructive to realize that it might have been moved around in \n> history, so it might actually have been cherry-picked later, and the \n> committer date differs from the author date even if the actual author and \n> committer are the same person (but you might also have had somebody _else_ \n> re-linearize or otherwise cherry-pick the history: again, it's important \n> to show the committer _separately_ both as a person and as a date).\n> \n> And because there is a committer field, if you actually want to linearize \n> or log things by who _committed_ stuff, you can. Just do\n> \n> \tgit log --committer=torvalds\n> \n > on the kernel, and you can see the log as it pertains for what _I_\n > committed, for example. You can even show it graphically, although it\n > won't be a connected graph any more, so it will tend to be very ugly\n > (but you'll see the \"linear stretches\" when somebody did some work). Just\n > do \"gitk --committer=myname\" to see in your own project.\n >\n > \t\tLinus\n\nI want to separate a branch, not to separate commits by some author, for \nexample, many authors can contribute to git's master branch, I want to\nknow what happened in the master branch like this:\n good work from A;\n good work from C;\n merge from next; -----> I don't care how this feature is realized.\n good work from A;\n ....\n\nAs Junio points out, HEAD^1 is not always the tip of working branch,\nso \"git log\" can't never satisfy me. There is reflog, but it's not public.\n\nBTW: I have a great respect for any man who contributes to Linux and GIT,\nespecially you:-)\n\n"},{"id":"293803","messageId":"200611070908.53121.jnareb@gmail.com","threadId":"43066","inReplyTo":"455001EA.5040306@gmail.com","subject":"Re: how to show log for only one branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-07T08:08:52Z","receivedAt":"2006-11-07T08:08:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Liu Yubao wrote:\n> Jakub Narebski wrote:\n>>\n>> Perhaps what you want is git log --committer=?\n>> \n> Thanks, it can't meet my requirement, if I create two branches\n> and merge them, I can't easily tell the track of those two branches.\n\nUse graphical history viewer then. git-show-branch, gitk (Tcl/Tk),\nqgit (Qt), less used GitView (GTK+), tig (ncurses), least used \ngit-browser (JavaScript). \n\nBTW. that is what subject line (first line of commit message) is for. \nNote the \"gitweb:\", \"Documentation:\", \"autoconf:\", \"Improve build:\" in \nthe git log.\n\n\nBy the way, what is the status of the proposed \"note\" header extension \nto the commit object? One could store name of branch we were/are on, \neven though this is absolutely discouraged...\n-- \nJakub Narebski\n"},{"id":"295320","messageId":"eipflf$k0r$1@sea.gmane.org","threadId":"43066","inReplyTo":"454FEDA5.1050607@gmail.com","subject":"Re: how to show log for only one branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-07T08:21:46Z","receivedAt":"2006-11-07T08:21:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Liu Yubao wrote:\n\n> Junio C Hamano wrote:\n>> [...] It is also a bad\n>> example because I can answer that question with this command\n>> line:\n>> \n>> git log --grep='^Merge .* into next$' next\n>> \n>> and while it is a perfectly valid answer, I know it would leave\n>> you feeling somewhat cheated.\n>> \n> smart trick, but if the logs aren't consistent enough it's hard to\n> grep them out.\n\nWell, commit message for merges are generated automatically. And if you set\nmerge.summary=true in repo config (or your config), then you have shortlog\nin merge commit message by default...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295641","messageId":"4550522D.9060503@shadowen.org","threadId":"43066","inReplyTo":"454FFCE6.70408@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-07T09:30:21Z","receivedAt":"2006-11-07T09:30:21Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Liu Yubao wrote:\n> Andreas Ericsson wrote:\n>> Liu Yubao wrote:\n>>\n>> If \"fake\" commits (i.e., commits that doesn't change any content) are\n>> introduced for each merge, it will change the ancestry graph and the\n>> resulting tree(s) won't be mergable with the tree it merged with,\n>> because each such \"back-merge\" would result in\n>> * the \"fake\" commit becoming part of history\n>> * a new \"fake\" commit being introduced\n>>\n>> Consider what happens when Alice pulls in Bob's changes. The\n>> merge-base of Bob's tip is where Alice HEAD points to, so it results\n>> in a fast-forward, like below.\n>>\n>> a---b---c---d <--- Alice\n>> \\\n>> e---f---g <--- Bob\n>>\n>>\n>> If, we would have created a fake commit instead, Alice would get a\n>> graph that looks like so:\n>>\n>> a---b---c---d-----------h <--- Alice\n>> \\ /\n>> e---f---g <--- Bob\n>>\n>>\n>> Now, we would have two trees that are identical, because the merge\n>> can't cause conflicts, but Alice and Bob will have reached it in two\n>> different ways. When Bob decides he wants to go get the changes Alice\n>> has done, his tree will look something like this:\n>>\n>> a---b---c---d-----------h <--- Alice\n>> \\ / \\\n>> e---f---g---i <--- Bob\n>>\n>>\n>> He finds it odd that he's got two commits that, when checked out, lead\n>> to the exact same tree, so he asks Alice to get his tree and see\n>> what's going on. Alice will then end up with this:\n>>\n>> a---b---c---d-----------h---j <--- Alice\n>> \\ / \\ /\n>> e---f---g---i <--- Bob\n>>\n>>\n>> Now there's four commits that all point to identical trees, but the\n>> ancestry graphs differ between all developers. In the case above,\n>> there's only two people working at the same project. Imagine the\n>> amount of empty commits you'd get in a larger project, like the Linux\n>> kernel.\n>>\n> Oh, you remind me, but I have a naive solution for this problem: print\n> a hint and don't merge commits that contain fake commit, then I know I have\n> reached a stable merge point and have same tree with others.\n\nBut in that situation you and Alice now have different actual history\nDAG's in your repositories.\n\nAlice sees:\na---b---c---d-----------h\n \\ /\n e---f---g\n\nBob sees:\na---b---c---d-----------h\n \\ / \\\n e---f---g---i\n\n\nIf bob now adds a new commit 'j' and alice pulls it back we either have\nto then accept 'i' at alice's end or forever lose the identicality of\nthe commit DAG. At which point our primary benefit of the SHA1 ==\nparent == same commit for everyone is gone. We can no longer say \"this\ncommit is broken\" and everyone know which commit that is.\n\n> \n> We create a fake commit for fast forwarding style merge, this fake commit\n> is used to record the track of a branch, so we can always follow HEAD^1\n> to travel through the history of a branch. In fact, git pays more attention\n> to the history of *data modification* than history of *operation*, that is\n> right the subtle difference between content tracker and VCS, latter's\n> branch has more information(useful information, I think).\n\nAny VCS is concerned with data modification and how its tracked. There\nare two ways you can record history. A series of snapshots (git) or a\nseries of operations (eg cvs and svn). Each has its trade offs,\noperations like diff on snapshots is O(number of files), on diffs they\nare O(number of files * number of deltas).\n\nThe difference here is all about the interpretation of the word\n'branch'. In CVS and others there is the hard concept of a mainline --\nhere is the master copy when something is added here it is \"the one\",\nbranches are temporary places which contain 'different' history such as\na patch branch. You want something on both branches you commit the\nchange twice once to each. In git they are more separate future\nhistories. When they are merged back together the new single history\ncontains the changes in both, neither is more important than the other\nboth represent forward progress. People tend to draw as below giving a\nfalse importance to the 'line' from d->h:\n\na---b---c---d-----------h\n \\ /\n e---f---g\n\nWe probabally should draw the below, h's history contains all history\nfrom both 'up' and 'down' histories. Which is more important? Neither.\n h is made up of a,b,c,d from alice and e,f,g from bob merged by alice.\n\n ---------\n / \\\na---b---c---d h\n \\ /\n e---f---g\n\n\n> \n> Even if no fake commit is created as git does now, there can be multiple\n> commits with identical tree object, and git can't prevent you from merging\n> two commits with identical tree object, it just creates an ancestry\n> relation\n> to remember the merge point.\n> \n> As git(7) says:\n> The \"commit\" object is an object that introduces the notion\n> of history into the picture. In contrast to the other objects,\n> it doesn't just describe the physical state of a tree, it\n> describes how we got there, and why.\n> \n> So it's clearer to describe a revision graph with nodes for tree\n> objects and edges for commit objects(multiple edges for a merge\n> commit object, I know this will break your habit:-).\n\nHow would such a graph look any different?\n\n>> Fast-forward is a Good Thing and the only sensible thing to do in a\n>> system designed to be fully distributed (i.e., where there isn't\n>> necessarily any middle point with which everybody syncs), while\n>> scaling beyond ten developers that merge frequently between each other.\n>>\n>>> If we throw away all compatibility, efficiency, memory and disk\n>>> consumption\n>>> problems,\n>>> (1) we can get the track of a branch without reflog because HEAD^1 is\n>>> always the tip of target branch(or working branch usually) before\n>>> merging.\n>>>\n>>> (2) with the track, branch mechanism in git is possibly easier to\n>>> understand,\n>>> especially for newbies from CVS or Subversion, I really like git's\n>>> light weight, simple but powerful design and great efficiency, but I\n>>> am really\n>>> surprised that 'git log' shows logs from other branches and a side\n>>> branch can become part of main line suddenly.\n>>>\n>>> A revision graph represents fast forwarding style merging like this:\n>>>\n>>> (fast forwarding)\n>>> ---- a ............ * ------> master\n>>> \\ /\n>>> b----------c -----> test (three commits with three\n>>> trees)\n>>>\n>>> can be changed to:\n>>>\n>>> ---- a (tree_1) ----------- d (tree_3) ------> master\n>>> \\ /\n>>> b (tree_2) ------- c (tree_3) ----> test\n>>> (four commits with three trees, it's normal as more than one way can\n>>> reach Rome :-)\n>>>\n>>\n>> That's where our views differ. In my eyes, \"d\" and \"c\" are exactly\n>> identical, and I'd be very surprised if the scm tried to tell me that\n>> they aren't, by not giving them the same revid.\n\nThese two arn't identicle. You have two difference routes to Rome, you\nhave two different lines on your map. To just say 'they' are the same\nand throw one away is to throw away just that history you care about.\n\n> It doesn't matter, they have same tree, and it's normal too in git\n> multiple commits have same tree, if you use nodes for tree state,\n> that graph will be simple to understand:\n> \n> a d\n> -----tree_1 -------------- tree_3 ----> master\n> \\ / \\\n> \\ b d/c `-----> test\n> \\ /\n> `--- tree_2 ---'\n> \n> This is the familiar way we used in CVS, I believe there are more\n> than one people confused by fast forwarding style merge and 'git log'\n> in git.\n\n"},{"id":"296241","messageId":"455055DD.2090903@shadowen.org","threadId":"43066","inReplyTo":"45503553.3020605@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-07T09:46:05Z","receivedAt":"2006-11-07T09:46:05Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Liu Yubao wrote:\n> Linus Torvalds wrote:\n>>\n>> On Mon, 6 Nov 2006, Liu Yubao wrote:\n>>> Then, what bad *logical* problem will happen if a merging that is\n>>> really a\n>>> fast forwarding creates a new commit?\n>>\n>> You MUST NOT do that.\n>>\n>> If a fast-forward were to do a \"merge commit\", you'd never get into\n>> the situation where two people merging each other would really ever\n>> get a stable result. They'd just keep doing merge commits on top of\n>> each other.\n> They can stop merging a fake commit with a real commit that point to same\n> tree object, here they reach a stable result: we have same tree content.\n>>\n>> Git tracks history, not \"your view of history\". Trying to track \"your\n>> view\" is fundamentally wrong, because \"your wiew\" automatically means\n>> that the project history would not be distributed any more - it would\n>> be centralized around what _you_ think happened. That is not a\n>> sensible thing to have in a distributed system.\n> It's not my view, it's branch scope view, I can see how a branch evolves\n> relatively independently. In git, branch scope view is more or less\n> neglected.\n> After fast forwarding merge, I can' tell where a branch come from -- I mean\n> the track of a branch.\n> \n> If Junio publishes his reflog, I don't see what conflict will happen\n> between\n> his local view (but now public, and naming it branch scope view seems more\n> sensible) and git's global view.\n> \n> If this won't lead to problems, it seems also ok to use fake commit for\n> fast forwarding style merge, so we can follow HEAD^1 to travel through a\n> branch without reflog.\n> \n> I hope I have expressed my thought clearly.\n>>\n>> For example, the way to break the \"infinite merges\" problem above is\n>> to say that _you_ would be special, and you would do a \"fast-forward\n>> commit\", and the other side would always just fast-forward without a\n>> commit. But that is very fundamentally against the whole point of\n>> being distributed. Now you're special.\n> No one is special as everybody can create fake commit, any branch (almost\n> a tag) will never be overwritten to point to a commit object in\n> another branch, branches are relatively independent, that's to say\n> 'git log' will reflect what has happened really in current branch (a CVS\n> semantical branch, not only a tag that always points to a tip commit).\n>>\n>> In fact, even for \"you\", it would be horrible - because you personally\n>> might have 5 different repositories on five different machines. You'd\n>> have to select _which_ machine you want to track. That's simply\n>> insane. It's a totally broken model. (You can even get the same\n>> situation with just _one_ repository, by just having five different\n>> branches - you have to decide which one is the \"main\" branch).\n> What's the mean of upstream branch then? I have to know I should track\n> Junio's public repository.\n> \n> When does one say two branches reach a common point? have same commit(must\n> point to same tree) or have same tree(maybe a fake commit and a real\n> commit)?\n> I think git takes the first way.\n> \n> Fast forwarding style merge tends to *automatically* centralize many\n> branches, in CVS people merge two branches and drop side branch to\n> centralize them, they all have central semantics.\n> (I don't want to get flame war between CVS/SVN and GIT, I think\n> git is better than them really:-)\n>>\n>> Besides, doing an empty commit like that (\"I fast forwarded\")\n>> literally doesn't add any true history information. It literally views\n>> history not as history of the _project_, but as the history of just\n>> one of the repositories. And that's wrong.\n> Something like 'git log --follow-all-parent' can show history of the\n> project\n> as 'git log' does now.\n>>\n>> So just get used to it. You MUST NOT do what you want to do. It's stupid.\n> Yes, I have understood the git way and am getting used to it, I like\n> its simple but powerful design and great efficiency, thank all for your\n> good work!\n>>\n>> If you want to track the history of one particular local branch, use\n>> the \"reflog\" thing. It allows you to see what one of your local\n>> branches contained at any particular time.\n>>\n>> See\n>>\n>> [core]\n>> logAllRefUpdates = true\n>>\n> Thanks, it's a pity I can't pull Junio's reflog :-(\n\nOne thing to remember, when you merge the destination into which you\nmerge will be HEAD^1, so by just following that you can get junio's view\nof his branch as he made it.\n\nThis is doesn't terminate properly, sucks the performance of your\nmachine and generally should be erased rather than run; but you get the\nidea:\n\nlet n=0\nwhile git-show --pretty=one -s \"next~$n\"\ndo\n let \"n=$n+1\"\ndone | less\n\n"},{"id":"296535","messageId":"4550721A.9030504@tromer.org","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611060928180.3667@g5.osdl.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Eran Tromer","fromEmail":"git2eran@tromer.org","sentAt":"2006-11-07T11:46:34Z","receivedAt":"2006-11-07T11:46:34Z","isPatch":false,"sender":{"key":"git2eran@tromer.org","avatar":null},"body":"Hi Linus,\n\nOn 2006-11-06 19:48, Linus Torvalds wrote:\n> \n> On Mon, 6 Nov 2006, Linus Torvalds wrote:\n>> Besides, doing an empty commit like that (\"I fast forwarded\") literally \n>> doesn't add any true history information. It literally views history not \n>> as history of the _project_, but as the history of just one of the \n>> repositories. And that's wrong.\n> \n> Btw, absolutely the _only_ reason people seem to want to do this is \n> because they want to \"pee in the snow\" and put their mark on things. They \n> seem to want to show \"_I_ did this\", even if the \"doing\" was a total \n> no-op and they didn't actually generate any real value.\n\nIn a project that uses topic branches extensively, the merge-induced\ncommits give a useful cue about the logical grouping of patches. They\nlet you easily glean the coarse-grained history and independent lines of\nwork (\"pickaxe made it to next\", \"Linus got the libata updates\") without\ngetting bogged down by individual commits, just by looking at the gitk\ngraph. Fast-forwards lose this information, and the more you encourage\nthem, the less grokkable history becomes.\n\nEmpty commits may be the wrong tool to address this (for all the reasons\nyou gave), but there's certainly useful process information that's\ncurrently being lost.\n\n"},{"id":"297145","messageId":"45507692.7050100@gmail.com","threadId":"43066","inReplyTo":"4550522D.9060503@shadowen.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T12:05:38Z","receivedAt":"2006-11-07T12:05:38Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Andy Whitcroft wrote:\n> Liu Yubao wrote: \n> But in that situation you and Alice now have different actual history\n> DAG's in your repositories.\n> \n> Alice sees:\n> a---b---c---d-----------h\n> \\ /\n> e---f---g\n> \n> Bob sees:\n> a---b---c---d-----------h\n> \\ / \\\n> e---f---g---i\n> \n> \n> If bob now adds a new commit 'j' and alice pulls it back we either have\n> to then accept 'i' at alice's end or forever lose the identicality of\n> the commit DAG. At which point our primary benefit of the SHA1 ==\n> parent == same commit for everyone is gone. We can no longer say \"this\n> commit is broken\" and everyone know which commit that is.\n> \nAlice and bob have their own branch scope view respectively, they have two\ndifferent branches, their DAGs in *branch scope view* can\nbe different because they trace the history from different points.\n\nIn branch scope view, you see only one HEAD, it merges changes from\nother branches. Each branch has its own commit DAG.\n\nIn global scope view, you see many HEADs, they fork and merge frequently,\nhere is only one big commit DAG, but you can never see the whole as branches\ncan be distributed over the world.\n\nFake commit doesn't break the DAG in global scope view, it has parents\nas normal commit although the trees pointed by fake commit and its parent\nare same. In fact, git has suck commit already:\n\n a (tree_1) ------- b (tree_2) ---- d (tree_2) ---> master\n \\ /\n `--------------- c (tree_2) ------' -----> test\n\nIf you don't pull from other, you can get different global DAG, it's normal \nobviously. It doesn't matter you get different DAG in branch scope, of course\nthey are different.\n\nThe problem is you can't get branch *track* from global scope view in git, you\ncan't tell which commits a branch has *referred to*. Note following HEAD^1 \nisn't right as Junio pointed out \n(http://marc.theaimsgroup.com/?l=git&m=116279354214757&w=2).\n\nBranch track is useful as people have requested reflog feature (realized, but\nonly for local purpose) and \"note\" extension in commit object.\n\nIf you have a commit A that I haven't pulled, I can't know what you\nrefer to when you say \"Commit A introduced a bug\". I must know where\nto get this commit. After I pull it from other branch, We can say \"this\ncommit is broken\" and everyone know which commit that is.\n\n>> We create a fake commit for fast forwarding style merge, this fake commit\n>> is used to record the track of a branch, so we can always follow HEAD^1\n>> to travel through the history of a branch. In fact, git pays more attention\n>> to the history of *data modification* than history of *operation*, that is\n>> right the subtle difference between content tracker and VCS, latter's\n>> branch has more information(useful information, I think).\n> \n> Any VCS is concerned with data modification and how its tracked. There\n> are two ways you can record history. A series of snapshots (git) or a\n> series of operations (eg cvs and svn). Each has its trade offs,\n> operations like diff on snapshots is O(number of files), on diffs they\n> are O(number of files * number of deltas).\n> \n> The difference here is all about the interpretation of the word\n> 'branch'. In CVS and others there is the hard concept of a mainline --\n> here is the master copy when something is added here it is \"the one\",\n> branches are temporary places which contain 'different' history such as\n> a patch branch. You want something on both branches you commit the\n> change twice once to each. In git they are more separate future\n> histories. When they are merged back together the new single history\n> contains the changes in both, neither is more important than the other\n> both represent forward progress. People tend to draw as below giving a\n> false importance to the 'line' from d->h:\n> \n> a---b---c---d-----------h\n> \\ /\n> e---f---g\n> \n> We probabally should draw the below, h's history contains all history\n> from both 'up' and 'down' histories. Which is more important? Neither.\n> h is made up of a,b,c,d from alice and e,f,g from bob merged by alice.\n> \n> ---------\n> / \\\n> a---b---c---d h\n> \\ /\n> e---f---g\n> \n> \nIf fake commit is introduced, a possible revision graph is like this:\n\n a - * -- c ------- * ---> branchA\n \\ / \\ /\n b ------ * ---- d ---> branchB ('*' stands for fake commit)\n\nIt's indeed not pretty as a linear revision graph that git's fast forwarding\nstyle merge creates, but it can record the tracks of two branches by following\nHEAD^1.\n"},{"id":"298157","messageId":"4550772B.1040308@gmail.com","threadId":"43066","inReplyTo":"455055DD.2090903@shadowen.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Liu Yubao","fromEmail":"yubao.liu@gmail.com","sentAt":"2006-11-07T12:08:11Z","receivedAt":"2006-11-07T12:08:11Z","isPatch":false,"sender":{"key":"yubao.liu@gmail.com","avatar":null},"body":"Andy Whitcroft wrote:\n> \n> One thing to remember, when you merge the destination into which you\n> merge will be HEAD^1, so by just following that you can get junio's view\n> of his branch as he made it.\n> \n> This is doesn't terminate properly, sucks the performance of your\n> machine and generally should be erased rather than run; but you get the\n> idea:\n> \n> let n=0\n> while git-show --pretty=one -s \"next~$n\"\n> do\n> let \"n=$n+1\"\n> done | less\n> \n> -apw\n> \nThis is not a right way to view a branch track in git, see Junio's explanation\n"},{"id":"294866","messageId":"eiptfr$2pd$1@sea.gmane.org","threadId":"43066","inReplyTo":"45507692.7050100@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-07T12:17:42Z","receivedAt":"2006-11-07T12:17:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Liu Yubao wrote:\n[...]\nI think everything stems from the fact that git repositories which pull/push\nwith each other _share_ [parts of] DAG. Learn to live with it, or chose\ndifferent SCM. \n\nYou want branch a path through DAG, not only as lineage sub-DAG... but\nrecodring this information is I think costly.\n\nNote also that the pointers to DAG branches are can be name differently in\ndifferent repositories (e.g. 'master' in one repository might be 'origin'\nin the other, and 'remotes/origin/master' in yet another).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296294","messageId":"455086F5.7070205@shadowen.org","threadId":"43066","inReplyTo":"4550772B.1040308@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-07T13:15:33Z","receivedAt":"2006-11-07T13:15:33Z","isPatch":false,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Liu Yubao wrote:\n> Andy Whitcroft wrote:\n>>\n>> One thing to remember, when you merge the destination into which you\n>> merge will be HEAD^1, so by just following that you can get junio's view\n>> of his branch as he made it.\n>>\n>> This is doesn't terminate properly, sucks the performance of your\n>> machine and generally should be erased rather than run; but you get the\n>> idea:\n>>\n>> let n=0\n>> while git-show --pretty=one -s \"next~$n\"\n>> do\n>> let \"n=$n+1\"\n>> done | less\n>>\n>> -apw\n>>\n> This is not a right way to view a branch track in git, see Junio's\n> explanation\n> about this from http://marc.theaimsgroup.com/?l=git&m=116279354214757&w=2\n\nWell in fact that message tells us more why a branch centric view is\nlikely not useful. This output is still the majority of the time the\nview from the branch integrators point of view. If that is something\nyou care about, I am not sure it is something I care about.\n\n"},{"id":"295260","messageId":"Pine.LNX.4.64.0611070729370.3667@g5.osdl.org","threadId":"43066","inReplyTo":"45503553.3020605@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-07T16:05:22Z","receivedAt":"2006-11-07T16:05:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Nov 2006, Liu Yubao wrote:\n>\n> > If a fast-forward were to do a \"merge commit\", you'd never get into the\n> > situation where two people merging each other would really ever get a stable\n> > result. They'd just keep doing merge commits on top of each other.\n>\n> They can stop merging a fake commit with a real commit that point to same\n> tree object, here they reach a stable result: we have same tree content.\n\nThat's flawed for two reasons:\n\n - identical trees is meaningless. You can have identical trees that had \n different histories and just happened to end up in the same state, and \n you'd still generate a merge commit (because what merges do is show the \n history of the data, and the _history_ merges). \n\n So you're really just introducing a special case, and not even one that \n makes any sense. Either history matters, or it doesn't.\n\n - a distributed system fundamnetally means that nobody is \"special\". And \n a merge is a _joining_ of two threads. Neither of which is special. \n\n Let's say that we have\n\n\tA:\ta -> b -> c -> d\n\n\tB:\ta -> b -> c\n\n and B pulls. You think that it should result in\n\n\tB:\ta -> b -> c ---> e\n\t\t \\ /\n\t\t > d\n\n and I say that that is crazy, because in a distributed system, A and B \n are _equivalent_ and have the same branches, and tell me what would \n have happened if _A_ had pulled from _B_ instead?\n\n That's right: if A had pulled from B, then obviously nothing at all \n would happen, because A already had everything B had.\n\n So the only _logical_ thing to happen is that the end result doesn't \n depend on who merged. And that means that if B merged from A, then the \n end result _has_ to be the same as if A merged from B, namely_\n\n\tB:\ta -> b -> c -> d\n\n and nothing else. Anything else is insane. It's not a distributed \n system any more.\n\n\n\n> > Git tracks history, not \"your view of history\". Trying to track \"your view\"\n> > is fundamentally wrong, because \"your wiew\" automatically means that the\n> > project history would not be distributed any more - it would be centralized\n> > around what _you_ think happened. That is not a sensible thing to have in a\n> > distributed system.\n>\n> It's not my view, it's branch scope view, I can see how a branch evolves\n> relatively independently.\n\nNo you CAN NOT. You think that \"A\" is special. But because you think that \nA is special, you ignore that B had the exact same branch, so your \"branch \nscope view\" is inherently flawed - it's not \"branch scope\" at all, it's \nliterally a \"one person is special\" view.\n\n> In git, branch scope view is more or less neglected. After fast \n> forwarding merge, I can' tell where a branch come from -- I mean the \n> track of a branch.\n\nSure you can. In your reflog. It's only _you_ who care about _your_ \nhistory. Nobody else cares one whit about what your tree looks like.\n\n> If Junio publishes his reflog, I don't see what conflict will happen between\n> his local view (but now public, and naming it branch scope view seems more\n> sensible) and git's global view.\n\nWhy would anybody ever care about Junio's reflog?\n\nAlso, you're ignoring the issue that both I and Martin mentioned: you're \nmaking history harder to read, and adding crud that doesn't actually _do_ \nanything. Your approach is nonsensical from a distributed system \nstandpoint, but it's also _worse_ than just fast-forwarding. If git did \nwhat you suggested, we'd have a lot of extra merge commits that simply \ndon't _help_ anything, and only make things worse.\n\n> What's the mean of upstream branch then? I have to know I should track\n> Junio's public repository.\n\n\"Upstream\" really should have absolutely zero meaning. That's the whole \npoint of distributed. You can merge things sideways, down, up, and the end \nresult doesn't matter. \"upstream\" can merge from you, and you can merge \nfrom him. Thats' the _technology_.\n\nThe only thing that matters is \"trust\". But trust is not something you get \nfrom technology, and trust is something you have to earn. And trust does \nNOT come from digital signatures like some people believe: digital \nsignatures are a way of _verifying_ the trust you have, but they are very \nmuch secondary (or tertiary) to the real issues.\n\nAnd _trust_ is why you'd pull from Junio. Git makes it somewhat easier by \ngiving you default shorthands for the original place you cloned from when \nyou clone a new repository, because often you'd obviously keep trusting \nthe same source, but an important thing here is to realize that it really \nis \"often\". Not always. And it's not about technology.\n\n> When does one say two branches reach a common point? have same commit(must\n> point to same tree) or have same tree(maybe a fake commit and a real commit)?\n> I think git takes the first way.\n\nVery much so. To git, the only (and I really mean _only_) thing that \nmatters from a commit history view is the commit relationships. NOTHING \nelse. What the trees are doesn't matter at all. Where the commits came \nfrom doesn't matter. Who made them doesn't matter either - those are just \n\"documentation\".\n\nSo the _only_ thing that matters for a commit is what its place in history \nwas. We never even look at the trees at all to decide what to do about \nmerging. The only time the trees start to matter is when we've figured out \nwhat the merge relationship is, and then obviously the trees matter, but \neven then they only matter as far as the resulting _tree_ is concerned. \n\n> Fast forwarding style merge tends to *automatically* centralize many\n> branches\n\nYes. Except I wouldn't say \"centralize\", I would very much say \"join\". \nThat's the point of a merge. Two commit histories \"join\" and become one.\n\nBut the reason I don't agree with your choice of wording (\"centralize\")\nthing is fundamental:\n\n - it only happens on one side. The side that does the merge is not \n necessarily the \"central\" one at all.\n\n - there isn't necessarily even such a thing as a \"central\" branch in git \n (and there _shouldn't_ be).\n\nIn fact, the thing I absolutely _detest_ about CVS is how it makes it \nalmost impossible to have multiple \"equally worthy\" branches. Look at the \ngit repository itself that Junio maintains, and please tell me which is \nthe \"trunk\" branch?\n\nGit doesn't even have that concept. There is the concept of a _default_ \nbranch (\"master\"), and yes, the git repository has it. But at the same \ntime, it really is just a default. There are three \"main\" branches that \nJunio maintains, and they only really differ in the degree of development. \nAnd \"master\" isn't even the most stable one - it's just the default one, \nbecause it's smack dab in the middle: recent enough to be interesting, but \nstill stable enough to be worth tracking for just about anybody.\n\nBut really, \"maint\" is the stable branch, and in many ways you could say \nthat \"maint\" is the trunk branch, since that's what Junio still cuts \nreleases from. And \"next\" is the development branch, that gets interesting \nfeatures before they hit the \"master\" branch (and \"pu\" is so far out that \nit's a whole different issue, since it jumps around and doesn't even \nbecome a real history at all).\n\nSee? All of these are _equal_. There is no trunk. There is no \"central\" \nbranch, and if you were to have to decide which one is the most central \none, it's not even the default one, that would probably be \"maint\", since \nthat's the one that keeps getting merged into the other branches.\n\nSo doing a merge doesn't really \"centralize\" anything. It just joins the \ntwo development threads together in that particular line. If \"master\" \nmerges the work in \"maint\", master doesn't really get any more \ncentralized, it just gets the work that \"maint\" did since last time. And \nif there was no other work done at all, then the two branches end up 100% \nidentical - there was no \"merge\" of the work.\n\nThey still have their own identities, though. It's still two branches. \nIt's still \"maint\" and \"master\". They just have the exact same state, and \nthat is as it should be, since they've had the exact same development \nhistory.\n\n"},{"id":"295321","messageId":"eiqcqn$c0$1@sea.gmane.org","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611070729370.3667@g5.osdl.org","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-07T16:39:31Z","receivedAt":"2006-11-07T16:39:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> So doing a merge doesn't really \"centralize\" anything. It just joins the \n> two development threads together in that particular line. If \"master\" \n> merges the work in \"maint\", master doesn't really get any more \n> centralized, it just gets the work that \"maint\" did since last time. And \n> if there was no other work done at all, then the two branches end up 100% \n> identical - there was no \"merge\" of the work.\n\nBy the way, merges happen in _two_ directions. 'Master' merges from 'next'\nwhen 'next' is in sufficiently stable state; 'next' merges from 'master' to\nget changes which were considered stable enough to be put into\n'master' (and 'master' merges in from 'maint', too).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296554","messageId":"Pine.LNX.4.64.0611070841580.3667@g5.osdl.org","threadId":"43066","inReplyTo":"45503CFC.7000403@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-07T17:23:49Z","receivedAt":"2006-11-07T17:23:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Nov 2006, Liu Yubao wrote:\n> \n> Fake commit is only for digging branch scope history, I can *outline* what has\n> been merged to a branch and don't care about how these good work are done on\n> earth.\n\nThe thing is, I think you see a good thing (\"outlining\"), and miss all the \ndownsides (\"extra noise\", \"incorrect outlining\").\n\nYes, I can see it being useful for reading logs in a perfect world.\n\nHowever, in real life, more than half of my fast-forwards are just me \ntracking another branch. An \"outline\" would be _wrong_. I _want_ to \nfast-forward, because I'm moving the trees from one machine to another, \nand the reason it's a fast-forward is exactly the fact that absolutely \nzero work had been done on the machine I'm pulling from - I'm pulling just \nto keep up-to-date.\n\nSo now, just to keep things sane, your scheme would require that people \nAHEAD OF TIME tell the system whether they want to fast-forward or whether \nthey want to create a magic merge commit as a \"outlining\" marker.\n\nSee? Fast-forwarding is absolutely the right thing to do in 99% of all \ncases. For me, it's perhaps only half, because I do several true merges \nevery day, but that's really quite unusual - I'm the top-level maintainer. \nNobody else should EVER do it.\n\nAnd the thing is, I refuse to work with a system that makes one person \nspecial. I _know_ I'm special, I'm the smartest, most beautiful, and just \nsimply the best person on the planet. I don't need a tool that tells me \nso.\n\nSo deep down, what you're really suggesting that there be a special mode \nthat is ONLY ever used for the top-level maintainer, so that he can create \nan \"outline\" in the history.\n\nPut that way, it almost makes sense, until you realize that 99.9% of all \npeople aren't top-level maintainers, and you don't want them creating crap \nlike that. And that \"outlining\" is likely most easily done with\n\n\t( git log lastversion.. | git shortlog ;\n\t git diff --stat --summary lastversion.. ) | less -S\n\ninstead.\n\nBut more importantly, I don't personally like the \"top-level maintainer\" \nmodel. Yes, it's how people do end up working a lot, but quite frankly, \nI'd rather not have the tool support it, especially if there is ever a \nschism in a development process. I want to support _forking_, which very \nmuch implies having somebody pulling the \"wrong way\".\n\nTime for some purely philosophical arguments on why it's wrong to have \n\"special people\" encoded in the tools:\n\nI think that \"forking\" is what keeps people honest. The _biggest_ downside \nwith CVS is actually that a central repository gets so much _political_ \nclout, that it's effectively impossible to fork the project: the \nmaintainers of a central repo have huge powers over everybody else, and \nit's practically impossible for anybody else to say \"you're wrong, and \nI'll show how wrong you are by competing fairly and being better\".\n\nFor example, gcc (and other tools) have gone through this phase. You've \nhad splinter groups (eg pgcc) that did a hell of a lot better work than \nthe main group, and the tools really made it really hard for them to make \nprogress. I think the most important part of a distributed SCM is not even \nto support the \"main trunk\", but to support the notion that anybody can \njust take the thing and compete fairly.\n\nWith the kernel as an example, any group could literally just start their \nown kernel git tree, and git should make it as easy as humanly possible \nfor them to track my tree WHILE _THEY_ STILL REMAIN IN CHARGE of their own \ntree. That doesn't mean that forking is easy - over the years people have \nsimply grown so _used_ to me that they mostly trust me and they are comfy \nworking with me, because even if I've got my quirks (or \"major personality \ndisorders\" as some people might say), people mostly know how to work with \nthem.\n\nBut the point is, there should be no _tool_ issues. As far as git is \nconcerned, every single developer can feel like he is the top-level \nmaintainer - it doesn't have to be a hierarchy, it really can be a \n\"network of equal developers\". I want the _tool_ to have that world-view, \neven if most projects in the end tend to organize more hierarcically than \nthat. Because the \"everybody is equal\" worldview actually matters in the \nonly case that _really_ matters: when problems happen.\n\nFor example: I use git to maintain a few other projects I've started too. \nI use git to maintain git itself, but I'm no longer the maintainer, simply \nbecause I think it's a lot better to step down than stand in the way of \nsomebody better, and because I think it's hard to be the \"lead person\" on \nmultiple projects. \n\nThe same thing is happening to \"sparse\", which was dormant for a while (it \nworked, and I fixed problems as people reported them, but it did \neverything I had set out to do, so my motivation to develop it further had \njust gone down a lot). What happened? Somebody else came along, showed \ninterest, started sending me patches, and I just suggested he start his \nown tree and start maintaining it.\n\nNow, both of those transitions were very peaceful, but it should work that \nway even if the maintainer were to fight tooth and nail to hold on to his \n\"top dog\" status. And that's where it's important that the tool not \nseparate out \"top maintainers\" from \"other people\".\n\n> I want to separate a branch, not to separate commits by some author, for\n> example, many authors can contribute to git's master branch, I want to\n> know what happened in the master branch like this:\n> good work from A;\n> good work from C;\n> merge from next; -----> I don't care how this feature is realized.\n> good work from A;\n\nReally, \"git log | git shortlog\" will come quite close. I use it all the \ntime for the kernel, and it's powerful.\n\nTry it with the kernel archive, just for fun. Do\n\n\tgit log v2.6.19-rc4.. | git shortlog | less -S\n\nwith the current kernel, and see how easy it is to get a kind of feel for \nwhat is going on. We do it by two means:\n\n - sorting by author. \n\n This sounds silly, but it's actually very powerful. It's not so much \n that it credits people better (it does) or that it makes the logs \n shorter by mentioning the person just once (it does that too), it's \n really nice because people tend to automatically do certain things. One \n person does \"random cleanups\". Another one works on \"networking\". A \n third one maintains one particular architecture, and so on..\n\n - encourage people to have a \"topic: explanation\" kind of top line of the \n commit (and encourage people to have that \"summary line\" in the first \n place: not every SCM does that, and everybody else is strictly much \n worse than git)\n\nIn fact, when I do this, I usually _remove_ the merges, because they end \nup being just noise. Really: go and look at the current kernel repo, and \ndo the above one-liner, and realize that I have a hunking big set of \ncommits credited to me right now (it says 30 commits), and in fact I think \nI'm the #1 author right now on that list.\n\nBut when I send out the description, I actually use the \"--no-merges\" flag \nto \"git log\", because those merge messages are _useless_. They really \ndon't do anything at all for me, or for anybody else. Re-run the above \none-liner that way, and suddenly I drop to just 5 commits (and quite \noften, I'm much less - sometimes the _only_ commit I have for an -rc \nrelease is the commit that changes the version number). But it's actually \nmore readable.\n\nSo I can kind of see what you want, but I'm 100% convinced that the \ninformation you _really_ want is better done totally differently.\n\nSo if you want to get the \"big picture\" thing, git does actually support \nyou in several ways. That \"git shortlog\" is very useful, but so is the \n\"drill down by subsystem\". For example, you could do\n\n\tgit log --no-merges v2.6.19-rc4.. arch/ | git shortlog | less -S\n\nand you'd get the \"summary view\" of what happened in architecture- \nspecific code. It's not the same thing as the \"merge log\", but it's \nactually very useful.\n\n(You can do the same with git. Something like\n\n\tgit log --no-merges v1.4.3.4.. | git shortlog | less -S\n\nshows quite clearly that a lot of new stuff is gitweb-related, for \nexample. \n\nCould we do better \"reporting\" tools? I'm absolutely sure we could. It \nmight be interesting to be able to ignore not just commits, but \"trivial \npatches\" too. For example, if you're looking for what changed on a high \nlevel, you're not likely to care about patches that change just a few \nlines. You might want to see only the commits that change an appreciable \nfraction of code, and so it might be very interesting to have a \"git \nshortlog\" that would take patch size into account, for example.\n\nSo I'm not saying that git is perfect. I'm just saying that there are \nbetter ways (with much fewer downsides) to get what you want, than the way \nyou _think_ you want.\n\n"},{"id":"295726","messageId":"7vwt673ylg.fsf@assigned-by-dhcp.cox.net","threadId":"43066","inReplyTo":"45503CFC.7000403@gmail.com","subject":"Re: If merging that is really fast forwarding creates new commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T18:23:23Z","receivedAt":"2006-11-07T18:23:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Liu Yubao writes:\n\n> I want to separate a branch, not to separate commits by some author,\n> for example, many authors can contribute to git's master branch, I\n> want to\n> know what happened in the master branch like this:\n> good work from A;\n> good work from C;\n> merge from next; -----> I don't care how this feature is realized.\n> good work from A;\n> ....\n\nSo you want to see list of commits that happened to be at the\ntip of my 'master' branch. I would not say that view does not\nexist, but it is probably not very useful. And the uselessness\nof it depends majorly on the reason why you say \"I don't care\nhow this feature is realized\" in the above picture. Care to\nelaborate why not?\n\nside note: I do not merge next to master so \"from next\" above in\nreality would be \"from a topic branch\" or \"from maint\", but it\nis otherwise a good example.\n\nWhat appeared in 'master' recently are three kinds of changes:\n\n - Many fixes that still apply to 1.4.3 codebase were sent from\n the list (thanks, everybody!), which were applied to 'maint',\n and merged into 'master'.\n\n - Some other obviously correct fixes and changes that address\n issues on features added after the 1.4.3 release (hence\n missing from 1.4.3 codebase and 'maint' but in 'master') were\n applied directly on 'master'.\n\n - Yet some other fixes and changes that concern post-1.4.3\n codebase (i.e. 'master only' changes) were forked off of the\n tip of 'master' when the patches were received, cooked in\n their own topic branches (which were merged in 'next'), and\n then merged into 'master'.\n\nSo, we have two kinds of obviously correct changes to 'master'\nthat come both from merges and direct applications. Things that\nhappen to address older issues come as merges because they\nequally apply to 'maint' and merged into 'master', things that\naddress newer issues are applied directly. Put it another way,\nthings that come as merges to 'master' are also of two kinds.\nObviously correct one that came through 'maint', and the ones\nthat might have looked slightly wrong in the initial version and\nlater perfected while in its own topic branch and then merged\ninto 'master'.\n\nThe decision between cooking in a topic branch and immediately\napplying to 'master' is not based on the size but more on\nperceived usefulness of the change (something that is correct in\nthe sense that it does not break the system may not deserve to\nbe merged if it does not do useful things) and quality of the\ndesign and implementation. The size of the series obviously\naffect the perception by me but that is secondary.\n\nEven when a patch is something that I should be able to judge as\nobviously correct when I am relaxed and sane, I might lack time\nand concentration to follow it fully, and instead decide to drop\nit into its own topic branch and later merge it into 'master'\nwithout need for much cooking. That kind of patch _could_ have\n(and should have) been applied directly to 'master' but comes as\na merge.\n\nSometimes I apply a patch to 'master' and then later realize\nthat change is needed and applicable to 'maint' as well. That\nis cherry-picked to 'maint', resulting in two independent\ncommits. They _could_ have (and should have) come through a\nmerge from 'maint' to 'master'.\n\nSo the change a patch introduces itself may not even have\nrelevance to the difference between direct application and merge\nat all. In other words, the avenue a particular patch took,\ndifference between direct application and merge, should not\nconcern you. I hope this would illustrate why a view that tries\nto summarize what merges brought in and to give full description\nof what were applied directly does not make much sense.\n\nBy the way, there are two reasons why you cannot have my\nref-logs. First of all, I do not have one on 'master' nor\n'next' myself. More importantly, I rewind and rebuild these\nbranches before pushing out (of course I have some safety valve\nto prevent me from rewinding beyond what I have already pushed\nout), and the ref-log entries for those tips that were rewound\nare not useful to you, and something I would rather not have\npeople to even know about (think of it as giving me some\nprivacy).\n\nIf you really care about the branch tip history of my\nrepository, you can set up ref-log yourself on your remote\ntracking branch.\n\nStrictly speaking, that is the history of fetches by you, not\nthe history of merges and commits by me, but that is what\nmatters more to you. If I pushed my changes out twice a day but\nyou were away for two days, you would have seen the state of my\nrepository four rounds back before you left and when you fetched\nfrom me today you would have the latest; three states in between\nwere not something you can know. But it does not matter -- your\nrepository did not have those three states, so not knowing\nexactly which commit they were would not hurt you when\nbisecting. \"It worked before I pulled yesterday morning but now\nit is broken when I pulled this afternoon\" would help your\nbisect get started, but multiple state changes between the times\nyou fetched cannot matter.\n"},{"id":"294688","messageId":"7vhcxb2b15.fsf@assigned-by-dhcp.cox.net","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611070729370.3667@g5.osdl.org","subject":"Re: If merging that is really fast forwarding creates new commit","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T21:37:42Z","receivedAt":"2006-11-07T21:37:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Git doesn't even have that concept. There is the concept of a _default_ \n> branch (\"master\"), and yes, the git repository has it. But at the same \n> time, it really is just a default. There are three \"main\" branches that \n> Junio maintains, and they only really differ in the degree of development. \n> And \"master\" isn't even the most stable one - it's just the default one, \n> because it's smack dab in the middle: recent enough to be interesting, but \n> still stable enough to be worth tracking for just about anybody.\n>\n> But really, \"maint\" is the stable branch, and in many ways you could say \n> that \"maint\" is the trunk branch, since that's what Junio still cuts \n> releases from.\n\nThe branch 'maint' is meant to be the moral equivalent of the\nefforts of your -stable team, so it shouldn't be \"the trunk\",\nbut you caught me.\n\nWe haven't seen a new release from 'master' for about a month.\nI think the dust has settled already after two big topics\n(packed-refs, delta-offset-base) were merged into 'master' since\nv1.4.3, and it is now time to decide which topics that have been\ncooking in 'next' are the ones I want in v1.4.4. Perhaps by the\nend of the week, I'll cut a v1.4.4-rc1 to start the pre-release\nstabilization process. No new features nor enhancements on\n'master' after that until v1.4.4 final.\n"},{"id":"298290","messageId":"eiqvoh$ebd$1@sea.gmane.org","threadId":"43066","inReplyTo":"7vhcxb2b15.fsf@assigned-by-dhcp.cox.net","subject":"Planned new release of git [was: Re: If merging that is really fast forwarding creates new commit]","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-07T22:02:38Z","receivedAt":"2006-11-07T22:02:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> We haven't seen a new release from 'master' for about a month.\n> I think the dust has settled already after two big topics\n> (packed-refs, delta-offset-base) were merged into 'master' since\n> v1.4.3, and it is now time to decide which topics that have been\n> cooking in 'next' are the ones I want in v1.4.4. Perhaps by the\n> end of the week, I'll cut a v1.4.4-rc1 to start the pre-release\n> stabilization process. No new features nor enhancements on\n> 'master' after that until v1.4.4 final.\n \nDo I understand correctly that the work on not exploding downloaded\npack on fetch, but making it non-thin, and related work on archival\npacks (not to be considered for repacking) is not considered ready\n(and tested)?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295603","messageId":"Pine.LNX.4.64.0611071504200.3667@g5.osdl.org","threadId":"43066","inReplyTo":"eiqvoh$ebd$1@sea.gmane.org","subject":"Re: Planned new release of git [was: Re: If merging that is really fast forwarding creates new commit]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-07T23:06:29Z","receivedAt":"2006-11-07T23:06:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Nov 2006, Jakub Narebski wrote:\n> \n> Do I understand correctly that the work on not exploding downloaded\n> pack on fetch, but making it non-thin, and related work on archival\n> packs (not to be considered for repacking) is not considered ready\n> (and tested)?\n\nI'd like to see a new version with both the packed refs and the \nnon-exploading download on by default. Maybe time for a git-1.5.0 release \nfrom master?\n\n"},{"id":"295912","messageId":"7vac3226c3.fsf@assigned-by-dhcp.cox.net","threadId":"43066","inReplyTo":"eiqvoh$ebd$1@sea.gmane.org","subject":"Re: Planned new release of git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T23:19:08Z","receivedAt":"2006-11-07T23:19:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> We haven't seen a new release from 'master' for about a month.\n>> I think the dust has settled already after two big topics\n>> (packed-refs, delta-offset-base) were merged into 'master' since\n>> v1.4.3, and it is now time to decide which topics that have been\n>> cooking in 'next' are the ones I want in v1.4.4. Perhaps by the\n>> end of the week, I'll cut a v1.4.4-rc1 to start the pre-release\n>> stabilization process. No new features nor enhancements on\n>> 'master' after that until v1.4.4 final.\n> \n> Do I understand correctly that the work on not exploding downloaded\n> pack on fetch, but making it non-thin, and related work on archival\n> packs (not to be considered for repacking) is not considered ready\n> (and tested)?\n\nPerhaps I phrased it badly, but I doubt it.\n\nIn the above I am only saying that it probably is time for me to\ndecide which ones to further merge into 'master', without saying\nwhich ones I think is ready right now. That is because I\nhaven't started thinking about it.\n"},{"id":"297926","messageId":"7v64dq25ja.fsf@assigned-by-dhcp.cox.net","threadId":"43066","inReplyTo":"Pine.LNX.4.64.0611071504200.3667@g5.osdl.org","subject":"Re: Planned new release of git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-07T23:36:25Z","receivedAt":"2006-11-07T23:36:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 7 Nov 2006, Jakub Narebski wrote:\n>> \n>> Do I understand correctly that the work on not exploding downloaded\n>> pack on fetch, but making it non-thin, and related work on archival\n>> packs (not to be considered for repacking) is not considered ready\n>> (and tested)?\n>\n> I'd like to see a new version with both the packed refs and the \n> non-exploading download on by default. Maybe time for a git-1.5.0 release \n> from master?\n\nDon't worry, packed refs is already part of 'master' so whatever\nthe next feature release is called it will be part of it ;-).\n"}]}