{"thread":{"id":"9292","subject":"merge time","startedAt":"2007-07-29T17:33:56Z","lastAt":"2007-07-31T20:07:09Z","messageCount":35,"participants":["Matthew L Foster","Jakub Narebski","Linus Torvalds","david@lang.hm","Steffen Prohaska","Junio C Hamano","Shawn O. Pearce","Jeff King","Sean","Rogan Dawes","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"49000","messageId":"630183.45851.qm@web51001.mail.re2.yahoo.com","threadId":"9292","inReplyTo":null,"subject":"merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-29T17:33:56Z","receivedAt":"2007-07-29T17:33:56Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\nSorry to bring up the time issue again [that I am perhaps still confused about] but I have been\nplaying around with git more and I think I can phrase my question/observation better.\n\n>From viewing gitweb.cgi I have observed a situation where Linus creates a tag, say rc1, and then\nhe later merges changes but some subset of those changes/commits show up in the list in time order\nas taking place _before_ the rc1 tag was made even though they were merged after. Do I describe a\nreal or possible phenomenon? And does this happen because the developer that made the subset of\nchanges in question commit them to his/her local repository in time order before the rc1 tag was\nmade? So an external repository had the change before the rc1 tag was made but Linus' repository\ndidn't? But internally git on Linus' machine knows that the gitweb.cgi displayed time order is\nwrong as far as the state is concerned because each repository's index file keeps local track of\nthe true local state [just time isn't reconcilable], or am I missing something(s)?\n\nIs it possible for gitweb.cgi to have a new view mode that sorts/displays the list based on merge\ntime for commits (the time merged into Linus' or whatever repository) so the above situation\ndoesn't happen? The actual time of a local commit should be the time it was merged locally not the\ntime it was created externally/originally, right? Where can I find the gitweb.cgi source/package?\nI could maybe hack gitweb.cgi myself.\n\nPlease CC me on any replies since I am not subscribed to the list.\n\n-Matt\n\n\n\n \n____________________________________________________________________________________\nGet the Yahoo! toolbar and be alerted to new email wherever you're surfing.\nhttp://new.toolbar.yahoo.com/toolbar/features/mail/index.php\n"},{"id":"49020","messageId":"f8j795$qfi$1@sea.gmane.org","threadId":"9292","inReplyTo":"630183.45851.qm@web51001.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-29T23:19:03Z","receivedAt":"2007-07-29T23:19:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: Matthew L Foster , git@vger.kernel.org]\n\nPlease, word wrap lines around 70 - 76 column.\n\nMatthew L Foster wrote:\n\n> Sorry to bring up the time issue again [that I am perhaps still confused\n> about] but I have been playing around with git more and I think I can\n> phrase my question/observation better. \n> \n> From viewing gitweb.cgi I have observed a situation where Linus creates\n> a tag, say rc1, and then he later merges changes but some subset of those\n> changes/commits show up in the list in time order as taking place _before_\n> the rc1 tag was made even though they were merged after.\n\nOf course. The time ordering is by the time commits were _created_,\nnot when they were merged.\n\nIn git, you can try tu use --topo-order parameter to git-log. In gitweb,\nnot yet.\n\n> Do I describe a real or possible phenomenon?\n\nReal phenomenon.\n\n> And does this happen because the developer that made the subset of changes\n> in question commit them to his/her local repository in time order before\n> the rc1 tag was made? So an external repository had the change before the\n> rc1 tag was made but Linus' repository didn't?\n\nThat's correct. Well, Linus' repository might have had change, but just\nnot merged in, but that is just small detail.\n\n> But internally git on Linus' machine knows that the \n> gitweb.cgi displayed time order is wrong as far as the state is concerned\n> because each repository's index file keeps local track of the true local\n> state [just time isn't reconcilable], or am I missing something(s)? \n\nGit does not know, and git proper has no utility to show for each commit\nwhen it was merged to given branch. And that is even more complicated by\nthe fast-forward merges. Reflog (local matter, not displayed in gitweb,\navailable as \"git reflog show \" or \"git log --show-reflog\n[]\" in git) keeps track of the branch tip history; it doesn't offer\ninformation [you think] you want.\n\n> Is it possible for gitweb.cgi to have a new view mode that sorts/displays\n> the list based on merge time for commits (the time merged into Linus' or\n> whatever repository) so the above situation doesn't happen? The actual\n> time of a local commit should be the time it was merged locally not the \n> time it was created externally/originally, right?\n\nI don't think that it is possible, but you are welcome to try...\n\n> Where can I find the gitweb.cgi source/package?\n> I could maybe hack gitweb.cgi myself.\n\nGitweb is now in the git.git repository, in gitweb/gitweb.perl\n(see also gitweb/README and gitweb/INSTALL).\n \n> Please CC me on any replies since I am not subscribed to the list.\n\nPlease Cc: list.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"49033","messageId":"alpine.LFD.0.999.0707291623160.3442@woody.linux-foundation.org","threadId":"9292","inReplyTo":"630183.45851.qm@web51001.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-29T23:35:46Z","receivedAt":"2007-07-29T23:35:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 29 Jul 2007, Matthew L Foster wrote:\n> \n> From viewing gitweb.cgi I have observed a situation where Linus creates \n> a tag, say rc1, and then he later merges changes but some subset of \n> those changes/commits show up in the list in time order as taking place \n> _before_ the rc1 tag was made even though they were merged after.\n\nAbsolutely. This is very common indeed. It's even more common with not the \n-rc1 tag, but a release.\n\nWhen I cut a full release, that \"opens the floodgates\" for the merge \nwindow, and a lot of people who have committed their changes (maybe \nweeks or *months* before) but where the changes weren't appropriate to be \nmerged before the merge window, will now ask me to pull.\n\nSo you may have the situation that 2.6.22 was released, but then a few \ndays later I'll merge stuff that was actually committed two weeks before \nthe 2.6.22 release, but was not _in_ the release.\n\n> Do I describe a real or possible phenomenon? And does this happen \n> because the developer that made the subset of changes in question commit \n> them to his/her local repository in time order before the rc1 tag was \n> made?\n\nYes. I would seriously suggest you not use \"gitweb\" as your way to look at \nthe repository, because you'll never see all the interactions that way. \n\nCloning a git repository (not necessarily the kernel, but it needs to be \nsomething with concurrent developement), and exploring it locally with \n\"gitk\" or \"qgit\" is a _lot_ more informative. When you see the actual \nhistory chains graphically, something that might look \"odd\" in gitweb \n(commits that look old but weren't there a few days ago) suddenly makes \ntons of sense.\n\n> So an external repository had the change before the rc1 tag was made but \n> Linus' repository didn't? But internally git on Linus' machine knows \n> that the gitweb.cgi displayed time order is wrong as far as the state is \n> concerned because each repository's index file keeps local track of the \n> true local state [just time isn't reconcilable], or am I missing \n> something(s)?\n\nWell, there i sno \"wrong\" time. There are just \"different\" times. The only \nthing git really tracks is not actually the time (that's purely for human \nconsumption), but the *relationship* between commits. So git really very \nfundmanetally just tracks things like \"commit X was the parent of commit \nY\", and the time is really immaterial.\n\nThe time, to git, is not really different from authorship: it's very \nimportant to track when something was done, but it's really purely \ninformational, exactly the same way the _author_ is purely informational. \nIt has no \"meaning\" for git itself.\n\n> Is it possible for gitweb.cgi to have a new view mode that \n> sorts/displays the list based on merge time for commits (the time merged \n> into Linus' or whatever repository) so the above situation doesn't \n> happen?\n\nThe public repositories don't even know what the merge time was for me. \nThat's a purely local feature, and while I can see it in my private \nrepository that I actually did the merge in, I don't publish that \ninformation. It's incidental, and quite frankly, it's \"wrong\" to care: \nbecause \"Linus' tree\" is really not even supposed to be special.\n\n\t\tLinus\n"},{"id":"49038","messageId":"241612.78983.qm@web51007.mail.re2.yahoo.com","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707291623160.3442@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T01:11:07Z","receivedAt":"2007-07-30T01:11:07Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n\n> Well, there i sno \"wrong\" time. There are just \"different\" times. The only \n> thing git really tracks is not actually the time (that's purely for human \n> consumption), but the *relationship* between commits. So git really very \n> fundmanetally just tracks things like \"commit X was the parent of commit \n> Y\", and the time is really immaterial.\n\nIs it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and\nuse the time merge C happened locally for both instead of using the time commits X and Y were\ncreated? It seems to me changes showing up as being made long before they really were merged is a\nvery serious problem verification wise but if everyone is using git then perhaps it's not as bad\nas I think. What happens when security bug fix Z errantly seems to be in v2.6.22 but in reality\nits not?\n\nThanks for the responses,\n-Matt\n\n\n\n ____________________________________________________________________________________\nPark yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.\nhttp://autos.yahoo.com/green_center/ \n"},{"id":"49039","messageId":"Pine.LNX.4.64.0707291823370.6331@asgard.lang.hm","threadId":"9292","inReplyTo":"241612.78983.qm@web51007.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-07-30T01:27:56Z","receivedAt":"2007-07-30T01:27:56Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Sun, 29 Jul 2007, Matthew L Foster wrote:\n\n> --- Linus Torvalds wrote:\n>\n>> Well, there i sno \"wrong\" time. There are just \"different\" times. The only\n>> thing git really tracks is not actually the time (that's purely for human\n>> consumption), but the *relationship* between commits. So git really very\n>> fundmanetally just tracks things like \"commit X was the parent of commit\n>> Y\", and the time is really immaterial.\n>\n> Is it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and\n> use the time merge C happened locally for both instead of using the time commits X and Y were\n> created?\n\ngit knows what's a decendent of what, but gitweb doesn't show it well. \nthat's why Linus suggested you look at gitk or qgit.\n\nby the way, you probably mean that commits X and Y are parents of merge C, \nnot decendants.\n\nbut if git did what you wanted it would show every commit with the time of \nthe merge, and that wouldn't help you anyway.\n\n> It seems to me changes showing up as being made long before they really were merged is a\n> very serious problem verification wise but if everyone is using git then perhaps it's not as bad\n> as I think. What happens when security bug fix Z errantly seems to be in v2.6.22 but in reality\n> its not?\n\nyou don't look at the dates to see if the bugfix is in 2.6.22 you look at \nthe graph or ask git to tell you\n\nremember that in git you don't have one-true-trunk of the project, you \nhave a mesh of interconnected points, some of which are pointed to by tags \nthat tell you that other people thought that they are particularly \ninteresting.\n\nDavid Lang\n\n> Thanks for the responses,\n> -Matt\n>\n>\n>\n> ____________________________________________________________________________________\n> Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center.\n> http://autos.yahoo.com/green_center/\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"49041","messageId":"alpine.LFD.0.999.0707291914451.3442@woody.linux-foundation.org","threadId":"9292","inReplyTo":"241612.78983.qm@web51007.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-30T02:29:14Z","receivedAt":"2007-07-30T02:29:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 29 Jul 2007, Matthew L Foster wrote:\n> \n> Is it possible for git and/or gitweb to know that commits X and Y are descendents of merge C and\n> use the time merge C happened locally for both instead of using the time commits X and Y were\n> created?\n\nThe data exists, but there is nothing to make \"C\" special. Or rather, the \ntwo \"sides\" of C that got merged are 100% equivalent.\n\nYou'd probably have to read a lot of old emails (from very early in the \ngit process) to see the whole picture. But the fact is, in a distributed \nenvironment, the parents to a merge C are totally equivalent.\n\nSo thus when you talk about merge new code into an old repository (and \ngiving those new commits the same date as the merge), that is actually \ntechnically 100% equivalent to merging the other way around, and thus \nyou'd have to give all the *old* commits that new merge date too!\n\nAnd yes, this does happen. It's not at all the case that I always merge \nother peoples tree: quite often other people merge _my_ tree, and the end \nresult really is that they pulled in the changes _I_ had done.\n\n[ Side note: we do actually try to avoid that, just because it makes the \n history harder to read, and the resulting criss-cross merges, while \n technically not a problem at all, can confuse people. But when I say \n \"try to avoid that\", I mean just that: it's not a hard rule, and the \n reverse merging _does_ happen, and there are good reasons for why it \n happens.\n\n So *most* of the time, the history looks like it's me merging other \n peoples code, but then every once in a while, the merge is done by the \n other side. And from a pure technical standpoint, the two cases are \n totally equivalent, and git is very fundamentally designed to *not* \n care. ]\n\nSo there is never really any way to say that one side of a merge is \nspecial. The closest you can get is saying\n\n - the first parent is special.\n\n This is \"see merges from the viewpoint of the merger\", but as \n mentioned, the person who actually did the merge isn't necessarily me, \n so while this is a totally self-consistent view, it's not really the \n view you are looking for.\n\n You can get some of this view by using \"git log --first-parent\", which \n basically follows commits preferentially using the first parent, and \n thus \"prefers\" history as seen by whoever did the merge.\n\nor\n\n - the *local* repository is special (but this is a purely repository- \n local viewpoint).\n\n This is what \"reflogs\" give you, and what \"git log -g\" shows. It shows \n the history not as it pertains to parenthood, but as the tip-of-tree \n has changed in *that* repository.\n\nbut neither of those are really \"sensible\" (the first one will give \n*wildly* different results if the repository is ever \"switched around\" \nbecause it's not merged by a single person, and the second one is a purely \nlocal thing and has no meaning for anybody else.\n\nThe fact is, distributed history isn't one-dimensional. You *cannot* \nlinearize it as some one-dimensional time. Impossible. Any system that \ntries is broken. Fundamentally.\n\n\t\tLinus\n"},{"id":"49043","messageId":"498048.62681.qm@web51002.mail.re2.yahoo.com","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707291914451.3442@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T02:43:10Z","receivedAt":"2007-07-30T02:43:10Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n--- Linus Torvalds wrote:\n\n> The fact is, distributed history isn't one-dimensional. You *cannot* \n> linearize it as some one-dimensional time. Impossible. Any system that \n> tries is broken. \n\nI don't want distributed history, I want what local time changes were merged locally. That is why\nI described a separate view for this feature, this feature request is not meant to replace how\ntime is currently not being used. :)\n\n-Matt\n\n\n \n____________________________________________________________________________________\nPinpoint customers who are looking for what you sell. \nhttp://searchmarketing.yahoo.com/\n"},{"id":"49044","messageId":"alpine.LFD.0.999.0707292000190.4161@woody.linux-foundation.org","threadId":"9292","inReplyTo":"498048.62681.qm@web51002.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-30T03:06:27Z","receivedAt":"2007-07-30T03:06:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 29 Jul 2007, Matthew L Foster wrote:\n> \n> --- Linus Torvalds wrote:\n> \n> > The fact is, distributed history isn't one-dimensional. You *cannot* \n> > linearize it as some one-dimensional time. Impossible. Any system that \n> > tries is broken. \n> \n> I don't want distributed history, I want what local time changes were \n> merged locally.\n\nThe point is, there is no \"locally\".\n\nDo you mean locally on my machine? That's actually *different* from the \nlocally on the public machines, and no, I wouldn't give you that \ninformation anyway (since that information would include the mistakes that \nI fixed up ;)\n\nAnd in fact, even on the public machines, the \"locally\" would be different \ndepending on things like mirroring delays, although that is currently \nhidden by the fact that kernel.org uses rsync for mirroring rather than \nusing git natively.\n\nSo in theory, we could pick one particular public kernel.org machine, and \nuse the times as _that_ machine sees it, but the fact is, that isn't how \ngit works. No normal git command will ever show you such a senseless \nordering.\n\nI suspect that the closest you could get to what you want would be to \nactually run git-cvsserver on kernel.org to export the git data as \"CVS\" \ndata, and then you could use a CVS client that gets a linearized model of \nhistory. That is, afaik, the only way to give you what you want.\n\nAnd quite frankly, I'd never ask the kernel.org maintainers to do \nsomething that perverse. You could ask them, and maybe they would do so \nout of some really perverse self-destructive death-wish, but quite \nfrankly, you'd probably be better off setting up such a git->CVS gateway \non some local machine yourself.\n\n\t\t\tLinus\n"},{"id":"49046","messageId":"alpine.LFD.0.999.0707292011170.4161@woody.linux-foundation.org","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707292000190.4161@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-30T03:16:01Z","receivedAt":"2007-07-30T03:16:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 29 Jul 2007, Linus Torvalds wrote:\n>\n> So in theory, we could pick one particular public kernel.org machine, and \n> use the times as _that_ machine sees it, but the fact is, that isn't how \n> git works. No normal git command will ever show you such a senseless \n> ordering.\n\nSo to be constructive, and just tell you what the *sensible* ordering is:\n\n - get a kernel git clone\n\n - do \"git pull\" to update it.\n\n - do\n\n\tgitk ORIG_HEAD..\n\n to show what the new stuff is after each update, or do something like\n\n\tgitk v2.6.23-rc1..\n\n to show what is new after -rc1 (or \"gitk @{2.days.ago}..\" to see what \n is new in _your_ tree in the last two days or whatever).\n\nNo commit dates anywhere. Just commit relationships and your *local* views \nof time.\n\n(Sure, gitk will show you the commit dates too, but they aren't important, \nsince they have no meaning as to whether a commit got merged into \n2.6.23-rc1 or not).\n\n\t\tLinus\n"},{"id":"49051","messageId":"706148.71958.qm@web51005.mail.re2.yahoo.com","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707292000190.4161@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T03:57:11Z","receivedAt":"2007-07-30T03:57:11Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n \n> The point is, there is no \"locally\".\n> \n> Do you mean locally on my machine? That's actually *different* from the \n> locally on the public machines, and no, I wouldn't give you that \n> information anyway (since that information would include the mistakes that \n> I fixed up ;)\n\nOk that explains it. How about locally on gitX.kernel.org [would have to be real git repository]?\nI'd want gitweb.cgi running on my local repository to use the local time of local merges to ensure\nthe problem I described at the start of this thread doesn't happen. Git reset --hard can be used\nto fix mistakes and that wouldn't show? \n\n> And in fact, even on the public machines, the \"locally\" would be different \n> depending on things like mirroring delays\n\nYes, it should be different, everyone's local commit/merge order is not the same.\n\n> So in theory, we could pick one particular public kernel.org machine, and \n> use the times as _that_ machine sees it, but the fact is, that isn't how \n> git works. No normal git command will ever show you such a senseless \n> ordering.\n\nIs local commit order really senseless? Using local commit order and/or the local time of local\nmerges would solve the problem I mentioned in the start of this thread? I don't think this info\nhas to be exported to CVS, a web interface to git and/or git itself should be able to tell us what\nlocal time order and/or what local commit order merges were made in.\n\n-Matt\n\n\n\n \n____________________________________________________________________________________\nTake the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. \nhttp://mobile.yahoo.com/go?refer=1GNXIC\n"},{"id":"49055","messageId":"12852.286.qm@web51002.mail.re2.yahoo.com","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707292011170.4161@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T04:13:44Z","receivedAt":"2007-07-30T04:13:44Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"--- Linus Torvalds wrote:\n\n> (Sure, gitk will show you the commit dates too, but they aren't important, \n> since they have no meaning as to whether a commit got merged into \n> 2.6.23-rc1 or not).\n\n\n\n\n\n \n____________________________________________________________________________________\nBe a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. \nhttp://answers.yahoo.com/dir/?link=list&sid=396545433\n"},{"id":"49063","messageId":"6FE9FFD6-B5D7-4E1D-A4E8-B6D0E9517503@zib.de","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707291914451.3442@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-30T06:10:31Z","receivedAt":"2007-07-30T06:10:31Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 30, 2007, at 4:29 AM, Linus Torvalds wrote:\n\n> So there is never really any way to say that one side of a merge is\n> special. The closest you can get is saying\n>\n> - the first parent is special.\n>\n> This is \"see merges from the viewpoint of the merger\", but as\n> mentioned, the person who actually did the merge isn't \n> necessarily me,\n> so while this is a totally self-consistent view, it's not really \n> the\n> view you are looking for.\n>\n> You can get some of this view by using \"git log --first-parent\", \n> which\n> basically follows commits preferentially using the first parent, \n> and\n> thus \"prefers\" history as seen by whoever did the merge.\n\nIn general the first parent is not special, agreed. But could one\ndeliberately built a history by following certain rules that make\nthe first parent _always_ a special one?\n\nI think of a quite simple example. Topic branches are always\nbranched off the master, and later merged back. The master, which\nis the branch an official release is created from, must always be\nthe first parent during a merge. It doesn't matter who does the\nmerges or who does the releases, as long as he follows the rule\nto start from the last release point and merge in all changes in\nthe appropriate way, such that the first parent rule is followed.\n\nHere are two applications that I think would be interesting:\n\n1) The kernel history. If you went from a current release back\nalong the first parents you'd see the changes that entered the\nofficial kernel sorted backwards in time. I believe the history of\nthe kernel is already an approximation of this rule. But maybe I'm\nwrong.\n\n2) Developing using topic branches. You start topic branches and\nstart developing new features. Only later you fix problems on all\nsupported platforms, polish and review the changes. Not every\ncommit on the topic branch has the same quality, e.g. the early\ncommits may not even compile on all supported platforms. But the\ntip of the topic branch passes all required tests. After a merge\nof the topic branch to a stable branch it would be nice to\ndistinguish the stable history from the less polished commits on\nthe topic branch. I think this could be achieved if the first\nparent always is linked to a stable commit.\n\nI'm sure some will propose that instead of (2) I should rewrite a\ntopic branch such that every single commit passes all quality\nrequirements. But I strongly believe it is a viable choice not to\ndo so. It may just be too much work and often it's sufficient and\neasier to polish the tip of a topic branch.\n\nFast-forward merges would break both of the scenarios. But would\nthey be possible without fast-forward merges?\n\nWould it be possible to ensure that all commits along the\nfirst-parent-path have 'release' quality and all release tags are\nlocated along this path? What would be the right rules to achieve\nthis objective?\n\n\tSteffen\n"},{"id":"49065","messageId":"7vbqdumlo1.fsf@assigned-by-dhcp.cox.net","threadId":"9292","inReplyTo":"6FE9FFD6-B5D7-4E1D-A4E8-B6D0E9517503@zib.de","subject":"Re: merge time","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-30T06:48:46Z","receivedAt":"2007-07-30T06:48:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This is an old topic rehashed from time to time. The last time\nwas March this year if I recall correctly.\n\n http://thread.gmane.org/gmane.comp.version-control.git/41931/focus=41983\n \nI tend to agree that it would make sense to allow something like:\n\n $ git merge --no-fast-forward -m 'Merge topic XYZ' xyz\n\nbut at the same time Linus is pretty clear that he would not use\nthat for his kernel merges, so even if we add that feature,\ngitweb at k.org that shows linux-2.6 history would not see it.\n"},{"id":"49070","messageId":"E49A2B0B-DAA3-4A03-925D-D3D113F907F1@zib.de","threadId":"9292","inReplyTo":"7vbqdumlo1.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge time","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-30T07:44:03Z","receivedAt":"2007-07-30T07:44:03Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 30, 2007, at 8:48 AM, Junio C Hamano wrote:\n\n> I tend to agree that it would make sense to allow something like:\n>\n> $ git merge --no-fast-forward -m 'Merge topic XYZ' xyz\n\nAnother option could be to force a commit before the merge, even\nif there are no changes to commit, something like\n\n $ git commit --force -m 'MARK'\n\n[to my knowledge, --force or similar is not yet available]\n\n\tSteffen\n"},{"id":"49072","messageId":"20070730074937.GT20052@spearce.org","threadId":"9292","inReplyTo":"E49A2B0B-DAA3-4A03-925D-D3D113F907F1@zib.de","subject":"Re: merge time","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-07-30T07:49:37Z","receivedAt":"2007-07-30T07:49:37Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Steffen Prohaska wrote:\n> Another option could be to force a commit before the merge, even\n> if there are no changes to commit, something like\n> \n> $ git commit --force -m 'MARK'\n> \n> [to my knowledge, --force or similar is not yet available]\n\ngit-force-commit:\n\n git config --global alias.force-commit \\\n '! git update-ref HEAD $(echo MARK | git commit-tree HEAD -p HEAD)'\n\nBut you didn't hear it from me. ;-)\n\nYes, I've actually done this once in a while. But only to create\nsome temporary throw-away state that I need for some diff operation\nor whatnot. Usually because I make it in one repository, but want\nto fetch it into another and fetch likes moving refs to commits\nbetter than refs to trees. Oh, and I'm usually passing in more\nthan one -p, and usually not HEAD as the tree. But whatever.\n\n-- \nShawn.\n"},{"id":"49073","messageId":"577C7529-4C3C-40D4-B86A-8B3CE888C997@zib.de","threadId":"9292","inReplyTo":"20070730074937.GT20052@spearce.org","subject":"Re: merge time","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-30T08:09:16Z","receivedAt":"2007-07-30T08:09:16Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 30, 2007, at 9:49 AM, Shawn O. Pearce wrote:\n\n> git-force-commit:\n>\n> git config --global alias.force-commit \\\n> '! git update-ref HEAD $(echo MARK | git commit-tree HEAD -p HEAD)'\n\nI needed to slightly modify it\n\n git config --global alias.force-commit \\\n '! git update-ref HEAD $(echo MARK | git commit-tree $(git cat- \nfile commit HEAD | grep ^tree | cut -b 6-) -p HEAD)'\n\n> But you didn't hear it from me. ;-)\n\nI'll tell no-one ;)\n\n\tSteffen\n"},{"id":"49074","messageId":"20070730081439.GA907@coredump.intra.peff.net","threadId":"9292","inReplyTo":"577C7529-4C3C-40D4-B86A-8B3CE888C997@zib.de","subject":"Re: merge time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-30T08:14:40Z","receivedAt":"2007-07-30T08:14:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 30, 2007 at 10:09:16AM +0200, Steffen Prohaska wrote:\n\n> I needed to slightly modify it\n>\n> git config --global alias.force-commit \\\n> '! git update-ref HEAD $(echo MARK | git commit-tree $(git cat-file \n> commit HEAD | grep ^tree | cut -b 6-) -p HEAD)'\n\nHow about \"git commit-tree HEAD^{tree} -p HEAD\"?\n\nBut I think making a \"fake\" commit to force non-fast-forward is the\nwrong thing. You really want to make your \"extra\" commit be the merge\nthat wouldn't have happened (which unfortunately is not as simple as\njust creating a commit by hand, since you have to actually _do_ the\nmerge to get the tree).\n\n-Peff\n"},{"id":"49076","messageId":"7vhcnml2no.fsf@assigned-by-dhcp.cox.net","threadId":"9292","inReplyTo":"20070730081439.GA907@coredump.intra.peff.net","subject":"Re: merge time","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-30T08:24:43Z","receivedAt":"2007-07-30T08:24:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> But I think making a \"fake\" commit to force non-fast-forward is the\n> wrong thing. You really want to make your \"extra\" commit be the merge\n> that wouldn't have happened (which unfortunately is not as simple as\n> just creating a commit by hand, since you have to actually _do_ the\n> merge to get the tree).\n\nI do agree that if you really want to create a commit instead of\nallowing a fast forward, you really should create a proper merge\ncommit.\n\nBut it is not hard. If it is a fast forward in reality but you\nare marking it as a real merge by creating a merge commit, then:\n\n - The tree is obviously the merged branch that is a fast\n forward of your old HEAD;\n\n - The first parent of the resulting merge is your old HEAD; and\n\n - The second parent of the resulting merge is the merged\n branch.\n\nSo:\n\n\tgit merge --no-fast-forward other\n\nwhen other is a fast forward of HEAD would do:\n\n\tgit commit-tree other^{tree} -p HEAD -p other\n"},{"id":"49075","messageId":"E1575DD6-AC8C-49FD-A765-801A19E1FA73@zib.de","threadId":"9292","inReplyTo":"20070730081439.GA907@coredump.intra.peff.net","subject":"Re: merge time","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-30T08:25:25Z","receivedAt":"2007-07-30T08:25:25Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 30, 2007, at 10:14 AM, Jeff King wrote:\n\n>\n> How about \"git commit-tree HEAD^{tree} -p HEAD\"?\n\nThanks, I wasn't aware of this syntax.\n\n> But I think making a \"fake\" commit to force non-fast-forward is the\n> wrong thing. You really want to make your \"extra\" commit be the merge\n> that wouldn't have happened (which unfortunately is not as simple as\n> just creating a commit by hand, since you have to actually _do_ the\n> merge to get the tree).\n\nI agree. But I think except for being 'fake' there shouldn't be any\nproblems with the extra commit.\n\n\tSteffen\n"},{"id":"49077","messageId":"20070730083156.GA3150@coredump.intra.peff.net","threadId":"9292","inReplyTo":"7vhcnml2no.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-30T08:31:56Z","receivedAt":"2007-07-30T08:31:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 30, 2007 at 01:24:43AM -0700, Junio C Hamano wrote:\n\n> But it is not hard. If it is a fast forward in reality but you\n> are marking it as a real merge by creating a merge commit, then:\n\nOf course, I was not thinking right. I was considering the difficulty of\ninvoking the merge machinery, but of course by definition for a\nfast-forward you don't have to.\n\n> when other is a fast forward of HEAD would do:\n> \n> \tgit commit-tree other^{tree} -p HEAD -p other\n\nYes, that makes sense.\n\n-Peff\n"},{"id":"49078","messageId":"20070730083223.GB3150@coredump.intra.peff.net","threadId":"9292","inReplyTo":"E1575DD6-AC8C-49FD-A765-801A19E1FA73@zib.de","subject":"Re: merge time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-30T08:32:23Z","receivedAt":"2007-07-30T08:32:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 30, 2007 at 10:25:25AM +0200, Steffen Prohaska wrote:\n\n> I agree. But I think except for being 'fake' there shouldn't be any\n> problems with the extra commit.\n\nProblems, no. But it will look ugly when browsing history. :)\n\n-Peff\n"},{"id":"49080","messageId":"Pine.LNX.4.64.0707300133210.6478@asgard.lang.hm","threadId":"9292","inReplyTo":"20070730083223.GB3150@coredump.intra.peff.net","subject":"Re: merge time","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-07-30T08:34:55Z","receivedAt":"2007-07-30T08:34:55Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 30 Jul 2007, Jeff King wrote:\n\n> On Mon, Jul 30, 2007 at 10:25:25AM +0200, Steffen Prohaska wrote:\n>\n>> I agree. But I think except for being 'fake' there shouldn't be any\n>> problems with the extra commit.\n>\n> Problems, no. But it will look ugly when browsing history. :)\n\nyes, but this entire thread was an attempt to avoid browsing the history \nand instead figure out the relationships between commits by dates. so the \npeople wanting this don't care how ugly it makes the history (but since \nthey want to do this in other people's repositories this won't work for \nthem either)\n\nDavid Lang\n"},{"id":"49081","messageId":"20070730084138.GA4100@coredump.intra.peff.net","threadId":"9292","inReplyTo":"Pine.LNX.4.64.0707300133210.6478@asgard.lang.hm","subject":"Re: merge time","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-07-30T08:41:38Z","receivedAt":"2007-07-30T08:41:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 30, 2007 at 01:34:55AM -0700, david@lang.hm wrote:\n\n> yes, but this entire thread was an attempt to avoid browsing the history and \n> instead figure out the relationships between commits by dates. so the people \n> wanting this don't care how ugly it makes the history (but since they want \n> to do this in other people's repositories this won't work for them either)\n\nI think we drifted a bit from that with Steffen's original message...\n\nIf you followed a strict policy of always merging topics to a \"base\"\nbranch as your first parent, then never allowing fast forwards should\nallow a very easy-to-read history in gitk. The left-most line of commits\nwould simply be a record of topics getting merged in, and would never\ncontain any \"non-base\" commits.\n\n-Peff\n"},{"id":"49098","messageId":"20070730073352.51ab68ec.seanlkml@sympatico.ca","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707292011170.4161@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-07-30T11:33:52Z","receivedAt":"2007-07-30T11:33:52Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Sun, 29 Jul 2007 20:16:01 -0700 (PDT)\nLinus Torvalds wrote:\n\n\n> \tgitk v2.6.23-rc1..\n> \n> to show what is new after -rc1 (or \"gitk @{2.days.ago}..\" to see what \n> is new in _your_ tree in the last two days or whatever).\n\nIt sounds like that would be the proper way to address the issue\nwithin Gitweb as well. Assuming the issue is users wanting to\nsee changes since a specific release, offering a \"Commits since tag\"\noption or some such should resolve it.\n\nSean\n"},{"id":"49101","messageId":"46ADDD3B.3000806@dawes.za.net","threadId":"9292","inReplyTo":"630183.45851.qm@web51001.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-07-30T12:44:43Z","receivedAt":"2007-07-30T12:44:43Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Matthew L Foster wrote:\n> Sorry to bring up the time issue again [that I am perhaps still confused about] but I have been\n> playing around with git more and I think I can phrase my question/observation better.\n> \n> From viewing gitweb.cgi I have observed a situation where Linus creates a tag, say rc1, and then\n> he later merges changes but some subset of those changes/commits show up in the list in time order\n> as taking place _before_ the rc1 tag was made even though they were merged after. Do I describe a\n> real or possible phenomenon? And does this happen because the developer that made the subset of\n> changes in question commit them to his/her local repository in time order before the rc1 tag was\n> made? So an external repository had the change before the rc1 tag was made but Linus' repository\n> didn't? But internally git on Linus' machine knows that the gitweb.cgi displayed time order is\n> wrong as far as the state is concerned because each repository's index file keeps local track of\n> the true local state [just time isn't reconcilable], or am I missing something(s)?\n> \n> Is it possible for gitweb.cgi to have a new view mode that sorts/displays the list based on merge\n> time for commits (the time merged into Linus' or whatever repository) so the above situation\n> doesn't happen? The actual time of a local commit should be the time it was merged locally not the\n> time it was created externally/originally, right? Where can I find the gitweb.cgi source/package?\n> I could maybe hack gitweb.cgi myself.\n> \n> Please CC me on any replies since I am not subscribed to the list.\n> \n> -Matt\n\nThe last time this topic came up, folks either created (or pointed to) \nreflogs as a way to determine the changes to the local state of a repo.\n\ni.e. by checking the reflog for a ref, you could say that that ref was \nchanged from v2.6.20 to v2.6.21 at such and such date and time.\n\nThat would allow you to determine what commits were available via that \nref at a particular time, regardless of the actual commit dates.\n\nTo the best of my knowledge, though, reflogs are not enabled by default \non bare repos, and gitweb makes no use of the reflogs anyway.\n\nRogan\n"},{"id":"49107","messageId":"78813.86273.qm@web51002.mail.re2.yahoo.com","threadId":"9292","inReplyTo":"46ADDD3B.3000806@dawes.za.net","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T16:14:31Z","receivedAt":"2007-07-30T16:14:31Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\nMaybe I am the only one that thinks the web interface should be just as feature rich as the\ncommand line interface? \n\n-Matt\n\n\n\n \n____________________________________________________________________________________\nBoardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.\nhttp://get.games.yahoo.com/proddesc?gamekey=monopolyherenow \n"},{"id":"49109","messageId":"Pine.LNX.4.64.0707301719450.14781@racer.site","threadId":"9292","inReplyTo":"78813.86273.qm@web51002.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-30T16:20:45Z","receivedAt":"2007-07-30T16:20:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 30 Jul 2007, Matthew L Foster wrote:\n\n> Maybe I am the only one that thinks the web interface should be just as \n> feature rich as the command line interface?\n\n*lol* I would be _nice_. But frankly, how do you want to get the power \nof the command line into a website, _without_ reproducing a command line? \nI can _script_ the command line, for example.\n\nCiao,\nDscho\n"},{"id":"49111","messageId":"304921.71128.qm@web51008.mail.re2.yahoo.com","threadId":"9292","inReplyTo":"Pine.LNX.4.64.0707301719450.14781@racer.site","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T16:24:01Z","receivedAt":"2007-07-30T16:24:01Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n--- Johannes Schindelin wrote:\n \n> > Maybe I am the only one that thinks the web interface should be just as \n> > feature rich as the command line interface?\n> \n> *lol* I would be _nice_. But frankly, how do you want to get the power \n> of the command line into a website, _without_ reproducing a command line? \n> I can _script_ the command line, for example.\n\nCreating a webified command line is a perfectly fine solution towards making gitweb.cgi as full\nfeatured as git is.\n\n-Matt\n\n\n ____________________________________________________________________________________\nShape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 \n"},{"id":"49112","messageId":"46AE1100.2020005@dawes.za.net","threadId":"9292","inReplyTo":"78813.86273.qm@web51002.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2007-07-30T16:25:36Z","receivedAt":"2007-07-30T16:25:36Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"Matthew L Foster wrote:\n> Maybe I am the only one that thinks the web interface should be just as feature rich as the\n> command line interface? \n> \n> -Matt\n> \n\nWell, having said that \"Use reflogs\" was the general response, I don't \nthink that anyone ever really followed through and made it a readily \naccessible feature, even on the command line.\n\nThat is, the reflogs are readily accessible, but noone made it possible \nto link them to the commits in such a way that the dates/times change as \nyou seem to desire.\n\nOf course, you can do things like:\n\n$ git show HEAD@{2.days.ago}\n\nto see what HEAD looked like 2 days ago, but you can't do things like \nget gitk to show you that this tag only appeared in your repo 2 days ago.\n\n(Keep in mind, of course, that reflogs are referring to YOUR local copy \nof the git repo, not what HEAD was on the server that you cloned from.)\n\nAnd also keep in mind that on the command line you can invoke a lot of \n\"plumbing commands\" that you certainly wouldn't expect to be exposed in \na web interface.\n\nRogan\n"},{"id":"49113","messageId":"28948.8052.qm@web51002.mail.re2.yahoo.com","threadId":"9292","inReplyTo":"46AE1100.2020005@dawes.za.net","subject":"Re: merge time","fromName":"Matthew L Foster","fromEmail":"mfoster167@yahoo.com","sentAt":"2007-07-30T17:06:59Z","receivedAt":"2007-07-30T17:06:59Z","isPatch":false,"sender":{"key":"mfoster167@yahoo.com","avatar":null},"body":"\n--- Rogan Dawes wrote:\n\n> And also keep in mind that on the command line you can invoke a lot of \n> \"plumbing commands\" that you certainly wouldn't expect to be exposed in \n> a web interface.\n\nIf the web interface requires logins over https why can't plumbing commands be exposed to the web?\nThough I agree not everything needs to be webified. What I envision is a wikipedia style interface\nfront end with git remaining the backend so you can more easily browse the file system and see\nhistory and diff the way you can on Wikipedia. But that idea is very separate from my concern that\nright now gitweb.cgi effectively has a bug in it because it sorts using external/superset commit\norder/time rather than local commit order which causes changes to appear as if they were made \nbefore they were really merged locally.\n\n-Matt\n\n\n\n \n____________________________________________________________________________________\nPinpoint customers who are looking for what you sell. \nhttp://searchmarketing.yahoo.com/\n"},{"id":"49115","messageId":"Pine.LNX.4.64.0707301007020.11330@asgard.lang.hm","threadId":"9292","inReplyTo":"28948.8052.qm@web51002.mail.re2.yahoo.com","subject":"Re: merge time","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-07-30T17:13:06Z","receivedAt":"2007-07-30T17:13:06Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 30 Jul 2007, Matthew L Foster wrote:\n\n> --- Rogan Dawes wrote:\n>\n>> And also keep in mind that on the command line you can invoke a lot of\n>> \"plumbing commands\" that you certainly wouldn't expect to be exposed in\n>> a web interface.\n>\n> If the web interface requires logins over https why can't plumbing commands be exposed to the web?\n> Though I agree not everything needs to be webified. What I envision is a wikipedia style interface\n> front end with git remaining the backend so you can more easily browse the file system and see\n> history and diff the way you can on Wikipedia. But that idea is very separate from my concern that\n> right now gitweb.cgi effectively has a bug in it because it sorts using external/superset commit\n> order/time rather than local commit order which causes changes to appear as if they were made\n> before they were really merged locally.\n\nwhat you are asking for would be a very useful piece of software, but \nthat's very different from the current gitweb. you are fileing a bug about \nthe software doing what it was designed to do. yes, it could be done \ndifferently. yes, that would be useful. but the software to do so is \nmostly a new product, not a simple tweak to the existing gitweb software.\n\nright now gitweb isn't designed for figuring out what was merged when, \nit's just for retreiving specific versions.\n\nif someone really wanted to do this, the right answer may be to take the \nconcept of gitk and webify it (think SVG for the graphics and AJAX \ninterfaces to retreive the info as needed). I think this would be a very \nuseful tool, but it would be a lot of work to implement.\n\nbut without the graph showing the commits and how they are related to each \nother, you really are crippled in your ability to figure out how things \nare related to each other. Date order just doesn't cut it.\n\nDavid Lang\n"},{"id":"49117","messageId":"alpine.LFD.0.999.0707301038380.4161@woody.linux-foundation.org","threadId":"9292","inReplyTo":"20070730084138.GA4100@coredump.intra.peff.net","subject":"Re: merge time","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-30T17:42:29Z","receivedAt":"2007-07-30T17:42:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 30 Jul 2007, Jeff King wrote:\n> \n> If you followed a strict policy of always merging topics to a \"base\"\n> branch as your first parent, then never allowing fast forwards should\n> allow a very easy-to-read history in gitk.\n\nOnly if only *one* person ever does any merges.\n\nImmediately when you have other people merging code, you're now back in \nthe same boat.\n\nThis is why I personally think the whole policy of \"no fast forward\" is \ntotally broken. It's only usable in a non-distributed environment, where \nthere is one central person who does everythng (a so-called \"star \ntopology\").\n\n\t\t\tLinus\n"},{"id":"49156","messageId":"f8lmt4$h1t$1@sea.gmane.org","threadId":"9292","inReplyTo":"Pine.LNX.4.64.0707301007020.11330@asgard.lang.hm","subject":"Re: merge time","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-30T21:57:56Z","receivedAt":"2007-07-30T21:57:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"david@lang.hm wrote:\n\n> if someone really wanted to do this, the right answer may be to take the \n> concept of gitk and webify it (think SVG for the graphics and AJAX \n> interfaces to retreive the info as needed). I think this would be a very \n> useful tool, but it would be a lot of work to implement.\n> \n> but without the graph showing the commits and how they are related to each \n> other, you really are crippled in your ability to figure out how things \n> are related to each other. Date order just doesn't cut it.\n\nBy the way, gitweb at repo.or.cz has graphical log (a la gitk) using\ngit-browser by Arteem Khodush, which uses JavaScript library for graphics\n(creating lines box by box) and a bit of AJAX-ism.\n\nI was thinking about using \"template\" PNG with transparency and colored\nboxes to have lighter than git-browser graphical history in gitweb, but...\n\nBy the way, you can try to add --topo-order support to gitweb, although I'm\nnot sure if it would do what you want.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"49238","messageId":"9DCA19D8-EDAE-4D04-A8C1-E0FF0A71DC93@zib.de","threadId":"9292","inReplyTo":"alpine.LFD.0.999.0707301038380.4161@woody.linux-foundation.org","subject":"Re: merge time","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-07-31T18:06:24Z","receivedAt":"2007-07-31T18:06:24Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Jul 30, 2007, at 7:42 PM, Linus Torvalds wrote:\n\n> On Mon, 30 Jul 2007, Jeff King wrote:\n>>\n>> If you followed a strict policy of always merging topics to a \"base\"\n>> branch as your first parent, then never allowing fast forwards should\n>> allow a very easy-to-read history in gitk.\n>\n> Only if only *one* person ever does any merges.\n>\n> Immediately when you have other people merging code, you're now \n> back in\n> the same boat.\n>\n> This is why I personally think the whole policy of \"no fast \n> forward\" is\n> totally broken. It's only usable in a non-distributed environment, \n> where\n> there is one central person who does everything (a so-called \"star\n> topology\").\n\nI think no fast forward merges can always provide useful information.\n\nPublic releases are often created from a public, linear branch that\nis not arbitrarily jumping around. Even if more than one person creates\nsuch releases there must be some agreement upon the responsibility for\nthe release and thus for the branch the releases are created from.\n\nIf all agreed to merge topics following the \"no fast forward\" policy and\nto use the release branch as a first parent, the commits along the first\nparents would document how commits came into the release branch. Non \nfast\nforward merges would always document that a series of commits was added\nto the release branch at once at the (local time) of the merge commit.\n\nIf fast forwards are allowed it depends on whether the release branch \ncan\nbe fast-forwarded over a series of commits on a topic branch or not.\nIn case of fast-forward, the history makes you believe each of the \ncommits\nof the topic branch entered the release branch separately. It hides that\nthey were all merged at once.\n\nI think, avoiding fast forwards may also be used to document a different\nlevel of quality required from commits to a topic branch and from \ncommits\nto the release branch. A the time of the merge the tip of a topic branch\nmust fulfill all quality requirements, for example compile on all \nplatforms\nand pass all tests. But this need not be the case for every single \ncommit\non the topic branch. If you avoid fast forwards you still get a chain of\ncommits along the first parent that would fulfill your quality \nrequirements.\nIf you allowed a fast forward over a low quality topic branch your chain\nmight be broken and you can't be sure, which commits will have high \nquality\nand which one have a lower quality.\n\nYou may argue that this is all crap because every single commit \nshould be\nof highest quality, but I think this is unrealistic. Especially if \nmore than\none person is jointly working on a topic branch and less experienced and\nmore experienced developers work together. It may also be rational to \nfirst\nget the basic functionality right and later polish work for several \nplatforms\nand usage scenarios.\n\nObviously other techniques, like rewriting a topic branch to a \nperfect commit\nseries may be used as well. But from my understanding this may be \nhard if more\nthan a single person is involved. You could also squash the complete \ntopic\nbranch into a single commit but then valuable history might get lost.\n\nI don't see why what I have in mind would break if other people are \nmerging\ncode, too. They may or may not follow my local rules. But at the time of\nmerging their changes, I can enforce my local quality policy and \ndocument\nthis by create a merge commit.\n\nThis could even be applied recursively. You could start to do a \ncouple of\nmerges but only thoroughly test the final result of the last merge. \nYou could\nthen enforce a link between the last very stable commit before you \ndid all the\nmerges and the very well tested result after the final merge by \nenforcing a\n\"no fast forward\" merge.\n\nI'm not quite sure if such a history would be useful in the long term or\nmay just become to complex. I'm also not sure if the artificial links \nwould\ncause any trouble. I'm wondering, for example, if there are any cases \nin which\nthe additional links would make branching and merging harder.\n\n\tSteffen\n"},{"id":"49246","messageId":"Pine.LNX.4.64.0707311306000.2453@asgard.lang.hm","threadId":"9292","inReplyTo":"9DCA19D8-EDAE-4D04-A8C1-E0FF0A71DC93@zib.de","subject":"Re: merge time","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-07-31T20:07:09Z","receivedAt":"2007-07-31T20:07:09Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"main trunk is at commit X\n\ndeveloper clones Y and adds a patch to it\n\nthe merge from Y's tree to the main trunk is a fast-forward\n\nDavid Lang\n\nOn Tue, 31 Jul 2007, Steffen Prohaska wrote:\n\n> Date: Tue, 31 Jul 2007 20:06:24 +0200\n> From: Steffen Prohaska \n> To: Linus Torvalds \n> Cc: Jeff King , david@lang.hm,\n> Shawn O. Pearce , Junio C Hamano ,\n> Matthew L Foster , git@vger.kernel.org\n> Subject: Re: merge time\n> \n>\n> On Jul 30, 2007, at 7:42 PM, Linus Torvalds wrote:\n>\n>> On Mon, 30 Jul 2007, Jeff King wrote:\n>> > \n>> > If you followed a strict policy of always merging topics to a \"base\"\n>> > branch as your first parent, then never allowing fast forwards should\n>> > allow a very easy-to-read history in gitk.\n>> \n>> Only if only *one* person ever does any merges.\n>> \n>> Immediately when you have other people merging code, you're now back in\n>> the same boat.\n>> \n>> This is why I personally think the whole policy of \"no fast forward\" is\n>> totally broken. It's only usable in a non-distributed environment, where\n>> there is one central person who does everything (a so-called \"star\n>> topology\").\n>\n> I think no fast forward merges can always provide useful information.\n>\n> Public releases are often created from a public, linear branch that\n> is not arbitrarily jumping around. Even if more than one person creates\n> such releases there must be some agreement upon the responsibility for\n> the release and thus for the branch the releases are created from.\n>\n> If all agreed to merge topics following the \"no fast forward\" policy and\n> to use the release branch as a first parent, the commits along the first\n> parents would document how commits came into the release branch. Non fast\n> forward merges would always document that a series of commits was added\n> to the release branch at once at the (local time) of the merge commit.\n>\n> If fast forwards are allowed it depends on whether the release branch can\n> be fast-forwarded over a series of commits on a topic branch or not.\n> In case of fast-forward, the history makes you believe each of the commits\n> of the topic branch entered the release branch separately. It hides that\n> they were all merged at once.\n>\n> I think, avoiding fast forwards may also be used to document a different\n> level of quality required from commits to a topic branch and from commits\n> to the release branch. A the time of the merge the tip of a topic branch\n> must fulfill all quality requirements, for example compile on all platforms\n> and pass all tests. But this need not be the case for every single commit\n> on the topic branch. If you avoid fast forwards you still get a chain of\n> commits along the first parent that would fulfill your quality requirements.\n> If you allowed a fast forward over a low quality topic branch your chain\n> might be broken and you can't be sure, which commits will have high quality\n> and which one have a lower quality.\n>\n> You may argue that this is all crap because every single commit should be\n> of highest quality, but I think this is unrealistic. Especially if more than\n> one person is jointly working on a topic branch and less experienced and\n> more experienced developers work together. It may also be rational to first\n> get the basic functionality right and later polish work for several platforms\n> and usage scenarios.\n>\n> Obviously other techniques, like rewriting a topic branch to a perfect commit\n> series may be used as well. But from my understanding this may be hard if \n> more\n> than a single person is involved. You could also squash the complete topic\n> branch into a single commit but then valuable history might get lost.\n>\n> I don't see why what I have in mind would break if other people are merging\n> code, too. They may or may not follow my local rules. But at the time of\n> merging their changes, I can enforce my local quality policy and document\n> this by create a merge commit.\n>\n> This could even be applied recursively. You could start to do a couple of\n> merges but only thoroughly test the final result of the last merge. You could\n> then enforce a link between the last very stable commit before you did all \n> the\n> merges and the very well tested result after the final merge by enforcing a\n> \"no fast forward\" merge.\n>\n> I'm not quite sure if such a history would be useful in the long term or\n> may just become to complex. I'm also not sure if the artificial links would\n> cause any trouble. I'm wondering, for example, if there are any cases in \n> which\n> the additional links would make branching and merging harder.\n>\n> \tSteffen\n>\n>\n"}]}