{"thread":{"id":"21307","subject":"keeping track of where a patch begins","startedAt":"2009-10-21T14:45:15Z","lastAt":"2009-10-30T08:37:18Z","messageCount":8,"participants":["E R","Nicolas Pitre","Junio C Hamano","Thomas Rast","Jeff King","Pascal Obry"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125605","messageId":"3a69fa7c0910210745r311cf18xf966f5c63650cde6@mail.gmail.com","threadId":"21307","inReplyTo":null,"subject":"keeping track of where a patch begins","fromName":"E R","fromEmail":"pc88mxer@gmail.com","sentAt":"2009-10-21T14:45:15Z","receivedAt":"2009-10-21T14:45:15Z","isPatch":false,"sender":{"key":"pc88mxer@gmail.com","avatar":null},"body":"Hi,\n\nWe've started to use git at work. Developers create branches for their\npatches (which we call \"tickets\" because they are related to our\nticketing system), and those branches are picked up by an integration\nteam and merged together to form a release. Hopefully this is not too\nunconventional.\n\nIdeally a developer will start their ticket branch from a previous\nrelease. However, occasionally a developer working on multiple tickets\nwill forget to switch back to a release node when creating a new\nticket branch. Then code from the first ticket inadvertently gets\nadded to the second ticket, and this is a problem if integration\ndecides to include the second ticket in the release but not the first.\n\nWhat solutions have you come up with to either to catch or prevent\nthis from happening? It is possible to determine what node a branch\nstarted from?\n\nIt seems that somehow the node that the patch begins at has to be\neither identified, marked or remembered, and it might have to done\noutside of git. Then the integration team or other tools can validate\nthe starting node to ensure that it complies with the build process.\n\nThanks,\nER\n"},{"id":"125628","messageId":"alpine.LFD.2.00.0910211402490.21460@xanadu.home","threadId":"21307","inReplyTo":"3a69fa7c0910210745r311cf18xf966f5c63650cde6@mail.gmail.com","subject":"Re: keeping track of where a patch begins","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-21T18:14:37Z","receivedAt":"2009-10-21T18:14:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 21 Oct 2009, E R wrote:\n\n> What solutions have you come up with to either to catch or prevent\n> this from happening? It is possible to determine what node a branch\n> started from?\n\nThis can be determined by looking at the gitk output.\n\nAlso 'git merge-base' can give you that node, given the main branch and \nthe topic branch.  See documentation about git-merge-base.\n\nThen if you need to move a branch to another starting node, then 'git \nrebase' is what you need (again the git-rebase documentation is pretty \ndetailed).\n\n\nNicolas\n"},{"id":"125637","messageId":"7veiow4iqc.fsf@alter.siamese.dyndns.org","threadId":"21307","inReplyTo":"alpine.LFD.2.00.0910211402490.21460@xanadu.home","subject":"Re: keeping track of where a patch begins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-10-21T20:03:55Z","receivedAt":"2009-10-21T20:03:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@fluxnic.net> writes:\n\n> On Wed, 21 Oct 2009, E R wrote:\n>\n>> What solutions have you come up with to either to catch or prevent\n>> this from happening? It is possible to determine what node a branch\n>> started from?\n>\n> This can be determined by looking at the gitk output.\n>\n> Also 'git merge-base' can give you that node, given the main branch and \n> the topic branch.  See documentation about git-merge-base.\n>\n> Then if you need to move a branch to another starting node, then 'git \n> rebase' is what you need (again the git-rebase documentation is pretty \n> detailed).\n\nThat is a correct way to diagnose the mistake and recover from it, but\nunfortunately it is a rather weak tool to identify the mistake in the\nfirst place.\n\nA branch in git, as Randal often used to say on #git, is an illusion---it\npoints only at the top and does not identify the bottom.\n\nBut it does _not_ have to stay that way at the Porcelain level.\n\nHere is a rough sketch of one possible solution.  It is not fully thought\nout; the basic idea is probably sound but I did not try to exhaustively\ncover changes to various tools that are necessary to maintain the\ninvariants this scheme requires.\n\n (0) Define a way to identify the bottom of a branch.  One way to do this\n     is by an extra ref (e.g. refs/branchpoints/frotz).  Then the commits\n     between refs/branchpoints/frotz..refs/heads/frotz identifies the\n     commits on the branch.  None of the additional restrictions below\n     applies when the branch does not have such bottom defined (i.e.\n     created by the current git without this extension).\n\n (1) At branch creation, the branchpoint is noted.  E.g.\n\n     $ git branch frotz master~4\n\n     would internally become\n\n     $ git update-ref refs/heads/frotz master~4\n     $ git update-ref refs/branchpoints/frotz master~4\n\n     You would also need to cover \"checkout -b\".\n\n (2) You can grow the branch naturally with \"commit\", \"am\" and \"merge\".\n     The bottom of the branch does not have to move with these operations.\n\n (3) Operations that alter histories, e.g. \"commit --amend\", \"rebase\",\n     \"reset\", while on a branch that records its bottom need to be taught\n     to pay attention to not break its bottom.  Paying attention needs to\n     take different forms depending on the operation; some probably will\n     forbid the operation while others would automatically adjust the\n     bottom.\n\n     Examples (not exhaustive):\n\n (3-a) \"branch -f frotz $commit\"\n\n     This moves the tip of the branch.  Unless $commit is already some\n     part of the existing frotz branch, we should probably forbid it for\n     simplicity, when a bottom is defined for the branch.\n\n     We could later loosen the rule so that $commit is only required to be\n     a descendant of existing bottom of the branch to support a workflow\n     like this:\n\n     $ git checkout -b frotz master~4 ;# records branchpoint\n     $ edit; git add; git commit; ... ;# builds history\n     $ git checkout HEAD^             ;# go back somewhere on frotz\n     $ edit; git add; git commit; ... ;# builds an alternate history\n     $ git show-branch HEAD frotz     ;# check progress\n     $ git diff frotz HEAD            ;# is this one better?\n     $ git branch -f frotz            ;# I prefer this new one better\n\n (3-b) \"reset $commit\" (with or without --hard/--soft/--mixed)\n\n     This is similar to (3-a) above; $commit has to be a descendant of\n     existing bottom.\n\n (3-c) \"commit --amend\"\n\n     $ git checkout -b frotz master~4 ;# records branchpoint\n     $ git commit --amend             ;# rewrite the bottom???\n\n     would probably be a mistake, as the end result would make the frotz\n     branch forked from master~5 with the first commit on the branch a\n     fix-up to what is already in the master branch.\n\n     However, this is a valid way to work:\n\n     $ git checkout -b frotz master~4 ;# records branchpoint\n     $ edit; git add; git commit      ;# builds history\n     $ git commit --amend             ;# fix the tip\n\n     and it does not have to do anything to the bottom.\n\n (3-d) \"rebase\"\n\n     $ git checkout -b frotz master~4 ;# records branchpoint\n     $ edit; git add; git commit; ... ;# builds history\n     $ git rebase --onto master       ;# transplants the branch\n\n     would make the \"onto\" commit the new bottom.  Another interesting\n     thing to note is that we do not have to compute which commits to\n     transplant with merge-base with the \"onto\" commit, because we know\n     the bottom commit of the branch.\n\n (4) Operations that browse histories, e.g. \"log\", \"show-branch\", while on\n     a branch that records its bottom can be taught to pay attention to\n     the bottom.  For example, it is conceivable that\n\n     $ git log\n     $ git log -- Documentation/\n\n     without an explicit branch name that fell back to the default HEAD\n     while on branch \"frotz\" might be better run with an implicit bottom\n     ^refs/branchpoint/frotz.\n\nWe probably could kill the other bird in the nearby thread that wants to\nadd a description to a branch, if this scheme is fully implemented (no, I\nam not going to start coding right away, as this message is just a sketch\nof what we _could_ do), As we will fully know in what operations we need\nto update the branchpoint ref, we could make the refs/branchpoints/frotz\nan annotated tag, and store the description for the branch in that tag.\nWhenever we need to adjust the branchpoint, we update it while carrying\nthe branch description message over to the new tag object.\n"},{"id":"125644","messageId":"alpine.LFD.2.00.0910211623370.21460@xanadu.home","threadId":"21307","inReplyTo":"7veiow4iqc.fsf@alter.siamese.dyndns.org","subject":"Re: keeping track of where a patch begins","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2009-10-21T20:50:02Z","receivedAt":"2009-10-21T20:50:02Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 21 Oct 2009, Junio C Hamano wrote:\n\n> Nicolas Pitre <nico@fluxnic.net> writes:\n> \n> > On Wed, 21 Oct 2009, E R wrote:\n> >\n> >> What solutions have you come up with to either to catch or prevent\n> >> this from happening? It is possible to determine what node a branch\n> >> started from?\n> >\n> > This can be determined by looking at the gitk output.\n> >\n> > Also 'git merge-base' can give you that node, given the main branch and \n> > the topic branch.  See documentation about git-merge-base.\n> >\n> > Then if you need to move a branch to another starting node, then 'git \n> > rebase' is what you need (again the git-rebase documentation is pretty \n> > detailed).\n> \n> That is a correct way to diagnose the mistake and recover from it, but\n> unfortunately it is a rather weak tool to identify the mistake in the\n> first place.\n\nWell... The \"mistake\" is probably going to be different depending on the \nwork flow used.  I don't think there is a generic definition of such \nmistakes.\n\nIn this case, simply having\n\n\tif [ $(git merge-base $expected_branch_point $branch) != \\\n\t     $(git rev-parse $expected_branch_point) ]; then\n\t\t(complain/refuse the merge of $branch)\n\tfi\n\nshould be quite sufficient as an enforcing proper branch policy.  Of \ncourse the $expected_branch_point is something that is determined \noutside of Git.\n\n> A branch in git, as Randal often used to say on #git, is an illusion---it\n> points only at the top and does not identify the bottom.\n> \n> But it does _not_ have to stay that way at the Porcelain level.\n> \n> Here is a rough sketch of one possible solution.  It is not fully thought\n> out; the basic idea is probably sound but I did not try to exhaustively\n> cover changes to various tools that are necessary to maintain the\n> invariants this scheme requires.\n\nI never came across a situation where such an elaborated scheme was \nneeded to actually record and maintain that information, or could be \nreally useful.  And some branches might be built on top of a sub-branch \nalready, making the real branch's bottom the sub-branch's instead in a \ngiven context.  It all depends on the work flow and the convention used \nfor a project.  And the tool has no way to figure that out (is this the \nreal branch bottom or should it be one or more level down?), etc.\n\n> We probably could kill the other bird in the nearby thread that wants to\n> add a description to a branch, if this scheme is fully implemented\n\nWell, I think we gain in flexibility by keeping those things separate \nthough.  Blending data structures together is not always a good thing.\n\nWe have reflog data separate from the refs themselves, so I think that \nhaving .git/desc/refs/* containing simple text files would be good \nenough and simple to implement/use.\n\n\nNicolas\n"},{"id":"125687","messageId":"200910221027.32739.trast@student.ethz.ch","threadId":"21307","inReplyTo":"7veiow4iqc.fsf@alter.siamese.dyndns.org","subject":"Re: keeping track of where a patch begins","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-22T08:27:31Z","receivedAt":"2009-10-22T08:27:31Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> \n> A branch in git, as Randal often used to say on #git, is an illusion---it\n> points only at the top and does not identify the bottom.\n> \n> But it does _not_ have to stay that way at the Porcelain level.\n> \n> Here is a rough sketch of one possible solution.  It is not fully thought\n> out; the basic idea is probably sound but I did not try to exhaustively\n> cover changes to various tools that are necessary to maintain the\n> invariants this scheme requires.\n> \n>  (0) Define a way to identify the bottom of a branch.  One way to do this\n>      is by an extra ref (e.g. refs/branchpoints/frotz).  Then the commits\n>      between refs/branchpoints/frotz..refs/heads/frotz identifies the\n>      commits on the branch.  None of the additional restrictions below\n>      applies when the branch does not have such bottom defined (i.e.\n>      created by the current git without this extension).\n> \n>  (1) At branch creation, the branchpoint is noted. [...]\n> \n>  (2) You can grow the branch naturally with \"commit\", \"am\" and \"merge\".\n>      The bottom of the branch does not have to move with these operations.\n> \n>  (3) Operations that alter histories, e.g. \"commit --amend\", \"rebase\",\n>      \"reset\", while on a branch that records its bottom need to be taught\n>      to pay attention to not break its bottom. [...]\n> \n>  (4) Operations that browse histories, e.g. \"log\", \"show-branch\", while on\n>      a branch that records its bottom can be taught to pay attention to\n>      the bottom. [...]\n\nI think this not only changes the model of branches, but also commits,\nto some extent.  Currently, commit have no intrinsic branch\nmembership; if you say\n\n  git branch foo bar\n\nyou cannot distinguish whether the commits on 'bar' were created on\n'foo' or on 'bar'.  (By git's means; of course the decision would\nfavour 'master' if I had used that instead.)\n\nTechnically your proposal does not change this fact very much; it is\nstill possible to create \"clones\" of branches that are\nindistinguishable.  However, to the *user* I think we would create a\nnotion that \"a commit belongs to one specific branch\", in that, during\nthe course of normal operations, a commit will end up on exactly one\n\n  git rev-list --first-parent base..branch\n\nrange.\n\n(Not sure if I consider this as an argument in favour or against yet,\nbut I wanted to point it out anyway.)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"125932","messageId":"20091026143006.GA3300@sigill.intra.peff.net","threadId":"21307","inReplyTo":"7veiow4iqc.fsf@alter.siamese.dyndns.org","subject":"Re: keeping track of where a patch begins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-10-26T14:30:07Z","receivedAt":"2009-10-26T14:30:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 21, 2009 at 01:03:55PM -0700, Junio C Hamano wrote:\n\n>  (0) Define a way to identify the bottom of a branch.  One way to do this\n>      is by an extra ref (e.g. refs/branchpoints/frotz).  Then the commits\n>      between refs/branchpoints/frotz..refs/heads/frotz identifies the\n>      commits on the branch.  None of the additional restrictions below\n>      applies when the branch does not have such bottom defined (i.e.\n>      created by the current git without this extension).\n\nHmm. This feels like redundant information to me. It has always been\ngit's strategy to record the history graph, and to use merge bases as\nthe \"bottom\" of branches, rather than keeping an artificial \"started\nhere\" commit. So I am trying to see the advantages of recording a static\nbottom versus doing a merge-base calculation later. Some things I can\nthink of:\n\n  - a bottom implies a specific commit, whereas a merge-base is always\n    with respect to anothe tip. So to have a default \"bottom\" calculated\n    by merge-base, you need a default \"upstream\". Which we do have, but\n    of course it is subject to being rewound.\n\n  - your merge-base will move when you merge. But arguably, that is a\n    good thing. If you are talking about \"git log\" only looking at the\n    commits on this branch (as you do later in the quoted email), I\n    would expect to see only stuff that happened since upstream last\n    merged. Although to be honest, I am not sure such a limit is all\n    that useful. We already have \"git log upstream..branch\".\n\nSo I am not really clear on what you are trying to accomplish by\nrecording such a bottom. Your steps (0) through (3) seem to be leading\nup to this use case:\n\n>  (4) Operations that browse histories, e.g. \"log\", \"show-branch\", while on\n>      a branch that records its bottom can be taught to pay attention to\n>      the bottom.  For example, it is conceivable that\n> \n>      $ git log\n>      $ git log -- Documentation/\n> \n>      without an explicit branch name that fell back to the default HEAD\n>      while on branch \"frotz\" might be better run with an implicit bottom\n>      ^refs/branchpoint/frotz.\n\nIf that is all you want, can't we just default to something like:\n\n  $ git log $(git for-each-ref --format='%(upstream)' $(git symbolic-ref HEAD)))..\n\nOf course it would be much easier to type as \"git log @{upstream}..\" :)\n\n-Peff\n"},{"id":"126358","messageId":"4AEA94EB.8080304@obry.net","threadId":"21307","inReplyTo":"200910221027.32739.trast@student.ethz.ch","subject":"Re: keeping track of where a patch begins","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2009-10-30T07:25:31Z","receivedAt":"2009-10-30T07:25:31Z","isPatch":false,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"\nLe 22/10/2009 10:27, Thomas Rast a écrit :\n> I think this not only changes the model of branches, but also commits,\n> to some extent.  Currently, commit have no intrinsic branch\n> membership; if you say\n>\n>    git branch foo bar\n>\n> you cannot distinguish whether the commits on 'bar' were created on\n> 'foo' or on 'bar'.  (By git's means; of course the decision would\n> favour 'master' if I had used that instead.)\n\nI have been looking for a way to know that. I've even post a question \nabout this on this mailing-list long time ago IIRC.\n\nTo me there is case where it is important to know which are the commits \ndone on a topic branch for example. When working on multiple topic it is \ndifficult to remember which commits have been done on this specific \nbranch. This is needed to rebase onto:\n\n    $ git rebase --onto somebranch <topic_base> <topic_head>\n\nA common idiom, but one as to think hard (& right) to properly get the \ntopic_base today.\n\nJust my 2 cents!\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry                           Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--|    http://www.obry.net  -  http://v2p.fr.eu.org\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B\n"},{"id":"126360","messageId":"200910300937.22949.trast@student.ethz.ch","threadId":"21307","inReplyTo":"4AEA94EB.8080304@obry.net","subject":"Re: keeping track of where a patch begins","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-10-30T08:37:18Z","receivedAt":"2009-10-30T08:37:18Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Pascal Obry wrote:\n> \n> Le 22/10/2009 10:27, Thomas Rast a écrit :\n> > I think this not only changes the model of branches, but also commits,\n> > to some extent.  Currently, commit have no intrinsic branch\n> > membership\n[...]\n> To me there is case where it is important to know which are the commits \n> done on a topic branch for example. When working on multiple topic it is \n> difficult to remember which commits have been done on this specific \n> branch. This is needed to rebase onto:\n> \n>     $ git rebase --onto somebranch <topic_base> <topic_head>\n> \n> A common idiom, but one as to think hard (& right) to properly get the \n> topic_base today.\n\nBut how frequently do your topics start on other topics?  Otherwise\nthey will start on an integration or maint branch, and in the git.git\nmodel where each integration branch is contained in the next \"less\nstable\" one, that means you can just specify 'pu' or equivalent.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}