{"thread":{"id":"36518","subject":"Tagging a branch as \"not fitted for branching\" ?","startedAt":"2014-04-28T12:09:43Z","lastAt":"2014-04-29T17:43:24Z","messageCount":4,"participants":["Jean-Noël Avila","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"239903","messageId":"535E4507.2070805@gmail.com","threadId":"36518","inReplyTo":null,"subject":"Tagging a branch as \"not fitted for branching\" ?","fromName":"Jean-Noël Avila","fromEmail":"avila.jn@gmail.com","sentAt":"2014-04-28T12:09:43Z","receivedAt":"2014-04-28T12:09:43Z","isPatch":false,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Most manuals on git state that it is bad practice to push -f a branch \nafter have meddled with its history, because this would risk to upset \nthe repositories of the coworkers. On the other hand, some workflows use \nbranches to propose modifications, and need some rewritting of the \nhistory after some review steps. In this case, the branch should only be \nseen as a mere pile of patches. Having this two-sided discourse is often \nmisunderstood by casual git users.\n\nThe proposed solution would be to be able to flag the branches with a \nspecial tag \"not fitted for branching\" that a collaborator could use \nwhen pushing it. This tag would be passed on to any pulled remote. When \nanother collaborator would then issue a \"git checkout -b\", the command \nwould fail with a warning message, unless forced with '-f'.\n\nIs this feature already present? If not, would it be of any interest?\n\nBest regards,\n\nJean-Noël AVILA\n"},{"id":"240089","messageId":"xmqqoazlm3ji.fsf@gitster.dls.corp.google.com","threadId":"36518","inReplyTo":"535E4507.2070805@gmail.com","subject":"Re: Tagging a branch as \"not fitted for branching\" ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-28T23:34:41Z","receivedAt":"2014-04-28T23:34:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noël Avila <avila.jn@gmail.com> writes:\n\n> Most manuals on git state that it is bad practice to push -f a branch\n> after have meddled with its history, because this would risk to upset\n> the repositories of the coworkers. On the other hand, some workflows\n> use branches to propose modifications, and need some rewritting of the\n> history after some review steps. In this case, the branch should only\n> be seen as a mere pile of patches. Having this two-sided discourse is\n> often misunderstood by casual git users.\n>\n> The proposed solution would be to be able to flag the branches with a\n> special tag \"not fitted for branching\" that a collaborator could use\n> when pushing it. This tag would be passed on to any pulled\n> remote. When another collaborator would then issue a \"git checkout\n> -b\", the command would fail with a warning message, unless forced with\n> -f'.\n>\n> Is this feature already present? If not, would it be of any interest?\n\nSince nobody seems to be responding...\n\nI do not think there is anything like that.  I am not personally\ninterested in it very much without seeing much details on how we go\nabout implementing such a feature.  Note that I am not speaking on\nbehalf of the project, or as its maintainer, but just as one of the\nactive contributors to the project, so my \"not interested\" is in no\nway final.\n\nThere are ways other than \"checkout -b\" to end up having your\ncommits on top of a forbidden commit.  Are you going to cover all of\nthem and at what point?  You may rebase your work based on 'master'\n(which is not one of these forbidden branches) onto it.  You may\nstart your WIP on top of 'master', realize that you need something\nthat is cooking only in 'pu' (which is a forbidden-to-be-built-on\nbranch), and then do a \"git checkout -m pu^0\" in order to further\nexperiment with it in an ideal world in which that prerequiste of\nyours already has graduated, and then decide to keep the WIP on a\nbranch that you are not going to publish with \"git branch wip\" after\ncommiting it on a detached HEAD.  Requiring \"-f\" during such an\nexploratory, idea-forming programming exercise might be a bit too\nmuch, and I cannot offhand see where the good place is to require\n\"-f\" in the first place.  At the final \"git branch wip\" step is too\nlate, as you have already expended a lot of effort to build that\nWIP, and your saying \"git branch wip\" should be an enough clue for\nGit that you do mean to save it.\n\nAt the first glance, I do agree (and to only this part I can say \"I\nam interested in\") that it might be a good idea if we had a bit more\nformal way to convey that branch 'pu' is not something you may want\nto base your final work on, but I am not sure if such a tag would\nhelp very much in practice or would be seen as a mere unnecessary\nroadblock that prevents them from freer experiments once the\ndevelopers get used to the convention of their projects.\n"},{"id":"240119","messageId":"535F56A2.9020900@gmail.com","threadId":"36518","inReplyTo":"xmqqoazlm3ji.fsf@gitster.dls.corp.google.com","subject":"Re: Tagging a branch as \"not fitted for branching\" ?","fromName":"Jean-Noël Avila","fromEmail":"avila.jn@gmail.com","sentAt":"2014-04-29T07:37:06Z","receivedAt":"2014-04-29T07:37:06Z","isPatch":false,"sender":{"key":"jn.avila@free.fr","avatar":"https://avatars.githubusercontent.com/u/156172?v=4"},"body":"Le 29/04/2014 01:34, Junio C Hamano a écrit :\n> Jean-Noël Avila <avila.jn@gmail.com> writes:\n>\n>> Most manuals on git state that it is bad practice to push -f a branch\n>> after have meddled with its history, because this would risk to upset\n>> the repositories of the coworkers. On the other hand, some workflows\n>> use branches to propose modifications, and need some rewritting of the\n>> history after some review steps. In this case, the branch should only\n>> be seen as a mere pile of patches. Having this two-sided discourse is\n>> often misunderstood by casual git users.\n>>\n>> The proposed solution would be to be able to flag the branches with a\n>> special tag \"not fitted for branching\" that a collaborator could use\n>> when pushing it. This tag would be passed on to any pulled\n>> remote. When another collaborator would then issue a \"git checkout\n>> -b\", the command would fail with a warning message, unless forced with\n>> -f'.\n>>\n>> Is this feature already present? If not, would it be of any interest?\n> Since nobody seems to be responding...\n>\n> I do not think there is anything like that.  I am not personally\n> interested in it very much without seeing much details on how we go\n> about implementing such a feature.  Note that I am not speaking on\n> behalf of the project, or as its maintainer, but just as one of the\n> active contributors to the project, so my \"not interested\" is in no\n> way final.\n>\n> There are ways other than \"checkout -b\" to end up having your\n> commits on top of a forbidden commit.  Are you going to cover all of\n> them and at what point?  You may rebase your work based on 'master'\n> (which is not one of these forbidden branches) onto it.  You may\n> start your WIP on top of 'master', realize that you need something\n> that is cooking only in 'pu' (which is a forbidden-to-be-built-on\n> branch), and then do a \"git checkout -m pu^0\" in order to further\n> experiment with it in an ideal world in which that prerequiste of\n> yours already has graduated, and then decide to keep the WIP on a\n> branch that you are not going to publish with \"git branch wip\" after\n> commiting it on a detached HEAD.  Requiring \"-f\" during such an\n> exploratory, idea-forming programming exercise might be a bit too\n> much, and I cannot offhand see where the good place is to require\n> \"-f\" in the first place.  At the final \"git branch wip\" step is too\n> late, as you have already expended a lot of effort to build that\n> WIP, and your saying \"git branch wip\" should be an enough clue for\n> Git that you do mean to save it.\n>\n> At the first glance, I do agree (and to only this part I can say \"I\n> am interested in\") that it might be a good idea if we had a bit more\n> formal way to convey that branch 'pu' is not something you may want\n> to base your final work on, but I am not sure if such a tag would\n> help very much in practice or would be seen as a mere unnecessary\n> roadblock that prevents them from freer experiments once the\n> developers get used to the convention of their projects.\n\nThank you for your reply.\n\nI had not looked at other scenarios and the use cases that you bring up \nshow that this feature would be far more complex than first estimated. I \nwas more focused on the simplest case that is the broadest in the github \nfashion. Basing a work on a remote 'pu' branch when using advanced \nbranch management commands may not raise any warning, or these warnings \ncould be muffled with a config property.\n\nAfter thinking a bit more on this, the initial idea encompassed another \nfeature: enable people to push without \"-f\" when they have created these \nkind of branches. In your daily management of the pu branch for git, do \nyou have to use the -f flag a lot? Would it be helpful to just tell git \n\"I know what I am doing on this branch\"? In this feature, the tagging \nwould only be local.\n"},{"id":"240189","messageId":"xmqqeh0gkp4z.fsf@gitster.dls.corp.google.com","threadId":"36518","inReplyTo":"535F56A2.9020900@gmail.com","subject":"Re: Tagging a branch as \"not fitted for branching\" ?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-04-29T17:43:24Z","receivedAt":"2014-04-29T17:43:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jean-Noël Avila <avila.jn@gmail.com> writes:\n\n> .... In your daily management of the pu\n> branch for git, do you have to use the -f flag a lot?\n\nDuring the day I prepare and validate all the branches I am going to\npublish, and at the end of the day, I run \"git push\" (no options)\nwith something like this in my .git/config:\n\n        [remote \"origin\"]\n                url = k.org:/pub/scm/git/git.git\n\t\tfetch = +refs/heads/*:refs/remotes/origin/*\n                push = heads/master\n                push = heads/next\n                push = +heads/pu\n                push = heads/maint\n\nI may be on any branch (not one of these four branches) when I need\nto run \"git push\" before I ran out of the office to catch my bus, so\nthese explicit \"which branches are to be pushed\" configuration that\ndoes not change what is pushed based on the current branch is\nperfect match for *my* workflow.  I know 'pu' is always forced, so a\nsingle \"+\" in front of only that one would allow me to rely on the\nfast-forward safety for other branches to stop me from rewinding\nthem.\n\nI could be also using the --force-with-lease support to validate\nthat the current value of 'pu' matches what I expect with versions\nof Git post 1.8.5, but I happen to be the only person who publishes\nthere, so there is no need for an extra safety.\n\nIf it were not for +heads/pu thing, I could even have relied on the\n\"matching\" mode, because these four branches are the only ones I\nhave there, and most of the local branches I have do not have any\nreason to be on that remote repository.\n\nI should caution that the use of \"matching\" mode or the explicit\n\"remote.*.push\" specifications are not suitable for non-maintainer\nworkflows, though.  As most of the people are non-maintainers, we\nare switching the default to upcoming Git 2.0 release.\n"}]}