{"thread":{"id":"47904","subject":"Git \"branch properties\"-- thoughts?","startedAt":"2018-02-22T18:30:10Z","lastAt":"2018-03-16T20:15:02Z","messageCount":4,"participants":["Paul Smith","Phillip Wood","Junio C Hamano","clime"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"339937","messageId":"1519324188.6391.156.camel@mad-scientist.net","threadId":"47904","inReplyTo":null,"subject":"Git \"branch properties\"-- thoughts?","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2018-02-22T18:29:48Z","receivedAt":"2018-02-22T18:30:10Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"Hi all.  I'm wondering if anyone has any thoughts about the best, or\neven any, way to have \"branch properties\": some extra information which\nis attached to a branch (that is, the actual branch name not the commit\nit currently points to).\n\nMy requirements are that the information needs to be pushed to the\nserver, so that lets out branch descriptions for example.  Ideally the\ninformation would also be easily updated and available in all clones\nduring normal fetch operations but this isn't a hard requirement: I\ncould script it.\n\nMy immediate desire is to find a way to mark a branch as \"frozen\", that\nwill control which pushes are allowed.  I use gitolite on my server and\nI can easily write a server hook that will handle the checking,\nrejecting, etc.  I already have such an infrastructure.  What I need is\na way to know which branches are in that state, so my hook can see that\nand DTRT.  There are other \"branch properties\" I could envision, too,\nbut don't have a real need right now.\n\nOf course I could embed the frozen state into the gitolite repository\nconfiguration.  Indeed, I have already implemented \"locks\" for obsolete\nbranches.  But \"frozen\" is a more ephemeral state and requiring access\nto the gitolite repository to manage it is just not what I want; it's a\nseparate repository so the state is not visible, requires privileges I\nreally don't want to hand out to everyone, and is generally difficult. \nI want some users to be able to manage frozen branches relatively\neasily, and all users to be able to see the state of which branches are\nfrozen, etc.\n\nSo then I thought about creating a \"frozen\" tag, like \"frozen/v1.0\" or\nsomething.  This is slightly weird because it is applied to a commit,\nwhich is not really right, but whatever: it's just a marker so I would\njust be checking to see if it exists or not.  The other problem is that\nGit tags are not intended to be transient/moveable.  While you CAN\ndelete them and move them, when someone pulls the repository they won't\nget that update by default.  Since the hook is server-side the fact\nthat the local repository has the wrong information doesn't matter for\nbehavior, but it's confusing for people.  So, it's not ideal.\n\nI thought about creating a branch, like \"frozen/v1.0\", rather than a\ntag.  I don't need a branch here, and no one would push to that branch\n(I'd have to disallow that in my hooks), and the commit associated with\nthe branch would not be relevant most likely.  I would only check to\nsee if the branch existed, or not.  Branches are nice because creating\nand deleting them is handled automatically (if you use prune\nconsistently, which we do because we have tons of transient branches).\n\nThen I looked into using notes, and they look interesting, but they're\nassociated with a specific commit as well and I don't want that: a\nfrozen branch can still have new commits pushed to it they just have\nmeet certain criteria.  This makes them hard to translate into a branch\nname.\n\nSo far, using a special branch name seems the most \"reasonable\".  But,\nI wonder if I missed some cool aspect if Git that would work better, or\nif anyone else has other suggestions.\n\nCheers!\n"},{"id":"340015","messageId":"2607f7e8-b680-50ac-0c08-7abc35499f1d@talktalk.net","threadId":"47904","inReplyTo":"1519324188.6391.156.camel@mad-scientist.net","subject":"Re: Git \"branch properties\"-- thoughts?","fromName":"Phillip Wood","fromEmail":"phillip.wood@talktalk.net","sentAt":"2018-02-23T11:22:58Z","receivedAt":"2018-02-23T11:23:07Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"On 22/02/18 18:29, Paul Smith wrote:\n> \n> Hi all.  I'm wondering if anyone has any thoughts about the best, or\n> even any, way to have \"branch properties\": some extra information which\n> is attached to a branch (that is, the actual branch name not the commit\n> it currently points to).\n> \n> My requirements are that the information needs to be pushed to the\n> server, so that lets out branch descriptions for example.  Ideally the\n> information would also be easily updated and available in all clones\n> during normal fetch operations but this isn't a hard requirement: I\n> could script it.\n> \n> My immediate desire is to find a way to mark a branch as \"frozen\", that\n> will control which pushes are allowed.  I use gitolite on my server and\n> I can easily write a server hook that will handle the checking,\n> rejecting, etc.  I already have such an infrastructure.  What I need is\n> a way to know which branches are in that state, so my hook can see that\n> and DTRT.  There are other \"branch properties\" I could envision, too,\n> but don't have a real need right now.\n> \n> Of course I could embed the frozen state into the gitolite repository\n> configuration.  Indeed, I have already implemented \"locks\" for obsolete\n> branches.  But \"frozen\" is a more ephemeral state and requiring access\n> to the gitolite repository to manage it is just not what I want; it's a\n> separate repository so the state is not visible, requires privileges I\n> really don't want to hand out to everyone, and is generally difficult. \n> I want some users to be able to manage frozen branches relatively\n> easily, and all users to be able to see the state of which branches are\n> frozen, etc.\n> \n> So then I thought about creating a \"frozen\" tag, like \"frozen/v1.0\" or\n> something.  This is slightly weird because it is applied to a commit,\n> which is not really right, but whatever: it's just a marker so I would\n> just be checking to see if it exists or not.  The other problem is that\n> Git tags are not intended to be transient/moveable.  While you CAN\n> delete them and move them, when someone pulls the repository they won't\n> get that update by default.  Since the hook is server-side the fact\n> that the local repository has the wrong information doesn't matter for\n> behavior, but it's confusing for people.  So, it's not ideal.\n> \n> I thought about creating a branch, like \"frozen/v1.0\", rather than a\n> tag.  I don't need a branch here, and no one would push to that branch\n> (I'd have to disallow that in my hooks), and the commit associated with\n> the branch would not be relevant most likely.  I would only check to\n> see if the branch existed, or not.  Branches are nice because creating\n> and deleting them is handled automatically (if you use prune\n> consistently, which we do because we have tons of transient branches).\n> \n> Then I looked into using notes, and they look interesting, but they're\n> associated with a specific commit as well and I don't want that: a\n> frozen branch can still have new commits pushed to it they just have\n> meet certain criteria.  This makes them hard to translate into a branch\n> name.\n> \n> So far, using a special branch name seems the most \"reasonable\".  But,\n> I wonder if I missed some cool aspect if Git that would work better, or\n> if anyone else has other suggestions.\n> \n> Cheers!\n> \n\nHi Paul\n\nIt would certainly be nice to be able to share branch descriptions so\nthat if I clone a repository I can get a bit more detail about the ideas\nbehind each branch. Shared descriptions could be displayed in web uis. I\nsometimes find myself wanting something like notes for branches as well\nto make a todo list for future commits. Maybe there could be a well\nknown refs (say refs/metadata) that contains public metadata for other\nrefs. In the same way that refs/notes/commits contains a tree of commit\nids refs/metadata would contain ref paths without the leaning ref/.\nUnder than directory there would be a subtree with the metadata - files\ncalled description, frozen, a directory of notes etc. So for\nrefs/heads/master you'd have refs/metadata/heads/description containing\nthe description refs/metadata/heads/master/notes/... containing the\nnotes I want to share and refs/heads/metadata/master/frozen to indicate\nif the branch was frozen.\n\nBest Wishes\n\nPhillip\n"},{"id":"340076","messageId":"xmqqo9kfs8ju.fsf@gitster-ct.c.googlers.com","threadId":"47904","inReplyTo":"2607f7e8-b680-50ac-0c08-7abc35499f1d@talktalk.net","subject":"Re: Git \"branch properties\"-- thoughts?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-02-23T21:25:09Z","receivedAt":"2018-02-23T21:25:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Phillip Wood <phillip.wood@talktalk.net> writes:\n\n> It would certainly be nice to be able to share branch descriptions so\n> that if I clone a repository I can get a bit more detail about the ideas\n> behind each branch. Shared descriptions could be displayed in web uis. I\n\nOne thing to note is that there is no universal identity for\nbranches across repositoryes that push and pull from each other.  My\n'refs/heads/master' may be copied to your 'refs/remotes/origin/master'\nso in that sense, any \"branch property\" I give to my 'master' branch\n(including the 'branch.master.description') could be copied to its\ncorresponding \"remote-tracking branch property\" you have, but that\nis the easy part.\n\nIt is quite hard to figure out how these branch properties you\nacquired from me on my branches affect properties of _your_ own\nbranches that build on top of the branches you obtained from me.\n\nPerhaps a narrow special case of two or more people collaborating on\na single topic branch with the same focus would be helped by blindly\nsharing the \"branch property\" across the local and remote-tracking\nbranches that share the same name.  I.e. the shared repository may\nhave 'optimize-frotz' topic branch, you and your friend both copy to\nyour 'refs/remotes/origin/optimize-frotz' remote-tracking branch,\nand these copies will share the same \"branch properties\" copied from\nthe shared repository.  Then if you and your friend both work on the\ntopic by \"git checkout -b optimize-frotz origin/optimize-frotz\",\nperhaps your and your friend's optmize-frotz branch would inherit\nthe same \"branch properties\" copied from their upstream.  Because\nall of the participants are focused on a rather narrow task of\n\"optimizing the frotz feature\" on their branches that share the same\nname, pretending as if these are \"logically\" the same branch, and\nenforcing that by sharing the \"branch properties\", may make sense.\n\nBut for a generic branch like 'master', that arrangement would not\nwork well, I am afraid.  You may have N copies of the same project,\nwhere the 'master' branch of each is used to work on separate topic.\nThe focus of the 'master' branch of the overall project would be\nquite different from each of these copies you have, hence it is\nlikely that it would be inappropriate to share the task list and\nstuff you would want to add to branch descriptions and branch\nproperties between the shared repository's 'master' and any of your\n'master' in these N copies you have.\n\nSo...\n"},{"id":"341926","messageId":"1521230968-26591-1-git-send-email-clime7@gmail.com","threadId":"47904","inReplyTo":"xmqqo9kfs8ju.fsf@gitster-ct.c.googlers.com","subject":"Re: Git \"branch properties\"-- thoughts?","fromName":"clime","fromEmail":"clime7@gmail.com","sentAt":"2018-03-16T20:09:28Z","receivedAt":"2018-03-16T20:15:02Z","isPatch":false,"sender":{"key":"clime7@gmail.com","avatar":"https://gravatar.com/avatar/d99ae46a5b0f57415bb74fc6c8ecd7eec304ff769f298c3be00fabf961b215ff?d=mp&s=160"},"body":">But for a generic branch like 'master', that arrangement would not\n>work well, I am afraid.  You may have N copies of the same project,\n>where the 'master' branch of each is used to work on separate topic.\n>The focus of the 'master' branch of the overall project would be\n>quite different from each of these copies you have, hence it is\n>likely that it would be inappropriate to share the task list and\n>stuff you would want to add to branch descriptions and branch\n>properties between the shared repository's 'master' and any of your\n>'master' in these N copies you have.\n>\n>So...\n\nI think it could work in a way that other people branch properties\nare only taken into account if you don't have your own properties of\nthose same names already set. In that case, git would initialize\nyour branch properties from the other branch of the same name and\ninform you about it. Of course, you should always have a way to overwrite\nany property to a value of your choice. So what you would be getting\nfrom others were basically default values (inspired by\nhttps://docs.python.org/3.5/library/stdtypes.html#dict.setdefault).\n\nWould it work? This sounds pretty good to me. I would really love\nto have a chance to implement this feature if people were\ninterested in it.\n\nclime\n"}]}