{"thread":{"id":"52161","subject":"git branch --edit-description a custom file","startedAt":"2019-10-30T18:39:55Z","lastAt":"2019-11-04T19:50:56Z","messageCount":21,"participants":["Denton Liu","Jeff King","Johannes Schindelin","Phillip Wood","Philip Oakley","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"385170","messageId":"20191030183950.GA21277@generichostname","threadId":"52161","inReplyTo":null,"subject":"git branch --edit-description a custom file","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-10-30T18:39:50Z","receivedAt":"2019-10-30T18:39:55Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi all,\n\nIt seems like everyone working on git.git has their own patch management\nsystem. Currently, I keep all of my branch-specific configurations\n(including CC lists) and patches in a worktree within the repo so that I\ncan keep my configs synced around on different computers.\n\nOne thing that's missing about this setup is that I would like to\nversion my branch descriptions as well since I use those to generate\ncover letters. Unfortunately, `git branch --edit-description` only\noperates on .git/config.\n\nAs a workaround, I rewrote `git branch --edit-description` as a\nshell-script that can operate on any config file but I feel like a more\ngeneral solution should be warranted.\n\nWould changing the option to `git branch --edit-description[=]`\nmake sense, where the `` is optional but if it's specified,\nit'll operate on that file instead of the .git/config.\n\nAlternately, would it make sense to support a $GIT_CONFIG environment\nvariable globally? That is, when $GIT_CONFIG is specified, git will\nread/write from $GIT_CONFIG instead of .git/config? It'd be a little\nheavy-handed for me to make the change just for this one use-case but\nperhaps people may find other uses for it?\n\nThoughts?\n\n-Denton\n"},{"id":"385177","messageId":"20191030202835.GB29013@sigill.intra.peff.net","threadId":"52161","inReplyTo":"20191030183950.GA21277@generichostname","subject":"Re: git branch --edit-description a custom file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-30T20:28:35Z","receivedAt":"2019-10-30T20:28:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 30, 2019 at 11:39:50AM -0700, Denton Liu wrote:\n\n> It seems like everyone working on git.git has their own patch management\n> system. Currently, I keep all of my branch-specific configurations\n> (including CC lists) and patches in a worktree within the repo so that I\n> can keep my configs synced around on different computers.\n> \n> One thing that's missing about this setup is that I would like to\n> version my branch descriptions as well since I use those to generate\n> cover letters. Unfortunately, `git branch --edit-description` only\n> operates on .git/config.\n> \n> As a workaround, I rewrote `git branch --edit-description` as a\n> shell-script that can operate on any config file but I feel like a more\n> general solution should be warranted.\n> \n> Would changing the option to `git branch --edit-description[=]`\n> make sense, where the `` is optional but if it's specified,\n> it'll operate on that file instead of the .git/config.\n\nThat makes sense to me (though I don't use branch descriptions myself).\nI actually wish a lot of auto-written config (like branch.*.merge) was\nwritten to a file besides .git/config, and then just included. It would\nmake it easier to keep your actual config file cleaner (I usually take\nthe opposite route and version-control my own config in a separate file\nthat I include from .git/config).\n\n> Alternately, would it make sense to support a $GIT_CONFIG environment\n> variable globally? That is, when $GIT_CONFIG is specified, git will\n> read/write from $GIT_CONFIG instead of .git/config? It'd be a little\n> heavy-handed for me to make the change just for this one use-case but\n> perhaps people may find other uses for it?\n\nWe used to have such a thing, and it opened a lot of weird corner cases.\nJust thinking about the case you mentioned: would people be confused if\n\"GIT_CONFIG=foo git branch --edit-description\" doesn't respect\ncore.editor specified in .git/config?\n\n-Peff\n"},{"id":"385193","messageId":"20191030224328.GB44961@generichostname","threadId":"52161","inReplyTo":"20191030202835.GB29013@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-10-30T22:43:28Z","receivedAt":"2019-10-30T22:43:34Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Peff,\n\nOn Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n> On Wed, Oct 30, 2019 at 11:39:50AM -0700, Denton Liu wrote:\n> \n> > It seems like everyone working on git.git has their own patch management\n> > system. Currently, I keep all of my branch-specific configurations\n> > (including CC lists) and patches in a worktree within the repo so that I\n> > can keep my configs synced around on different computers.\n> > \n> > One thing that's missing about this setup is that I would like to\n> > version my branch descriptions as well since I use those to generate\n> > cover letters. Unfortunately, `git branch --edit-description` only\n> > operates on .git/config.\n\nDscho brought up in the GGG thread[1] that perhaps we want to treat\nbranch descriptions like notes and have them all under something like\n`refs/notes/branches`. This would certainly solve my problem of\nhaving versioned descriptions and it would probably do it in a much more\ngeneral way than having a versioned included config.\n\nAnyone see any potential problems with this approach?\n\n> > \n> > As a workaround, I rewrote `git branch --edit-description` as a\n> > shell-script that can operate on any config file but I feel like a more\n> > general solution should be warranted.\n> > \n> > Would changing the option to `git branch --edit-description[=]`\n> > make sense, where the `` is optional but if it's specified,\n> > it'll operate on that file instead of the .git/config.\n> \n> That makes sense to me (though I don't use branch descriptions myself).\n> I actually wish a lot of auto-written config (like branch.*.merge) was\n> written to a file besides .git/config, and then just included. It would\n> make it easier to keep your actual config file cleaner (I usually take\n> the opposite route and version-control my own config in a separate file\n> that I include from .git/config).\n\nYeah, I've also wanted the same... I've thought about just symlinking\n.git/config away but I think that causes other problems that I don't\nwant to deal with.\n\n> \n> > Alternately, would it make sense to support a $GIT_CONFIG environment\n> > variable globally? That is, when $GIT_CONFIG is specified, git will\n> > read/write from $GIT_CONFIG instead of .git/config? It'd be a little\n> > heavy-handed for me to make the change just for this one use-case but\n> > perhaps people may find other uses for it?\n> \n> We used to have such a thing, and it opened a lot of weird corner cases.\n> Just thinking about the case you mentioned: would people be confused if\n> \"GIT_CONFIG=foo git branch --edit-description\" doesn't respect\n> core.editor specified in .git/config?\n\nI found the original thread that removed the functionality[2]. I'm\nprobably not going to go with this approach since the notes approach\nseems more promising but going back to your question, I think that would\nmake sense since by specifying GIT_CONFIG, a user is explicitly\noverriding .git/config so they should also be aware of the consequences.\n\nThanks for your thoughts,\n\nDenton\n\n[1]: https://github.com/gitgitgadget/git/issues/438\n[2]: https://public-inbox.org/git/alpine.LNX.1.00.0806300328380.19665@iabervon.org/\n\n> \n> -Peff\n"},{"id":"385197","messageId":"20191031061832.GA20830@sigill.intra.peff.net","threadId":"52161","inReplyTo":"20191030224328.GB44961@generichostname","subject":"Re: git branch --edit-description a custom file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-31T06:18:32Z","receivedAt":"2019-10-31T06:18:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:\n\n> On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n> Dscho brought up in the GGG thread[1] that perhaps we want to treat\n> branch descriptions like notes and have them all under something like\n> `refs/notes/branches`. This would certainly solve my problem of\n> having versioned descriptions and it would probably do it in a much more\n> general way than having a versioned included config.\n> \n> Anyone see any potential problems with this approach?\n\nI don't think it would be `refs/notes/`, as that is assumed to contain\nmappings of object ids (and if I understand correctly, this would be a\nmapping of branch names to data.\n\nYou could just have \"refs/meta/descriptions/foo\" pointing to a blob\nwhich contains the description of \"refs/heads/foo\". That makes it easy\nto edit descriptions, even if you don't like using \"git branch\n--edit-description\".\n\nYou could also have \"refs/meta/descriptions\" to point to a _single_ blob\nwith all of the descriptions. It could even be in the existing config\nformat. And then you could include it with \"[include] blob = ...\". That\ndoesn't exist yet, but it would be easy to add (it was something I had\nalways considered when writing the config-include code, but there was\nnever really a good use; and you do have to be careful about pointing to\nuntrusted blobs). That's a convoluted way to get where you want, but I\nwonder if integrating to the existing config system would have any\nbenefits. I haven't really thought it through.\n\n(Of course that's also only one step away from having a versioned config\nfile in your .git directory, but it might possibly be a bit easier to\nmanage, since it would always be committed).\n\nThat's mostly off-the-top-of-my-head rambling, so please disregard\nanything that seems totally off-base. :)\n\n-Peff\n"},{"id":"385211","messageId":"nycvar.QRO.7.76.6.1910311119080.46@tvgsbejvaqbjf.bet","threadId":"52161","inReplyTo":"20191031061832.GA20830@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-10-31T10:22:16Z","receivedAt":"2019-10-31T10:22:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Thu, 31 Oct 2019, Jeff King wrote:\n\n> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:\n>\n> > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n> > Dscho brought up in the GGG thread[1] that perhaps we want to treat\n> > branch descriptions like notes and have them all under something like\n> > `refs/notes/branches`. This would certainly solve my problem of\n> > having versioned descriptions and it would probably do it in a much more\n> > general way than having a versioned included config.\n> >\n> > Anyone see any potential problems with this approach?\n>\n> I don't think it would be `refs/notes/`, as that is assumed to contain\n> mappings of object ids (and if I understand correctly, this would be a\n> mapping of branch names to data.\n>\n> You could just have \"refs/meta/descriptions/foo\" pointing to a blob\n> which contains the description of \"refs/heads/foo\". That makes it easy\n> to edit descriptions, even if you don't like using \"git branch\n> --edit-description\".\n\nThe only problem with this is that it's not really versioned, as it\nwould be hard to go back to previous versions and/or share the history\nvia pushing to a remote repository.\n\nBut I guess that a very simple pseudo branch would do it, where\n`refs/meta/` would point to a commit that has a tree\nwith a single file in it: `description.txt`.\n\nI now like that idea a lot better than my original notes idea.\n\nCiao,\nDscho\n\n>\n> You could also have \"refs/meta/descriptions\" to point to a _single_ blob\n> with all of the descriptions. It could even be in the existing config\n> format. And then you could include it with \"[include] blob = ...\". That\n> doesn't exist yet, but it would be easy to add (it was something I had\n> always considered when writing the config-include code, but there was\n> never really a good use; and you do have to be careful about pointing to\n> untrusted blobs). That's a convoluted way to get where you want, but I\n> wonder if integrating to the existing config system would have any\n> benefits. I haven't really thought it through.\n>\n> (Of course that's also only one step away from having a versioned config\n> file in your .git directory, but it might possibly be a bit easier to\n> manage, since it would always be committed).\n>\n> That's mostly off-the-top-of-my-head rambling, so please disregard\n> anything that seems totally off-base. :)\n>\n> -Peff\n>\n"},{"id":"385215","messageId":"8b9021fa-f60c-a2e0-1174-a2fc1f11c476@gmail.com","threadId":"52161","inReplyTo":"nycvar.QRO.7.76.6.1910311119080.46@tvgsbejvaqbjf.bet","subject":"Re: git branch --edit-description a custom file","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-10-31T11:00:02Z","receivedAt":"2019-10-31T11:00:08Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi\n\nOn 31/10/2019 10:22, Johannes Schindelin wrote:\n> Hi Peff,\n> \n> On Thu, 31 Oct 2019, Jeff King wrote:\n> \n>> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:\n>>\n>>> On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n>>> Dscho brought up in the GGG thread[1] that perhaps we want to treat\n>>> branch descriptions like notes and have them all under something like\n>>> `refs/notes/branches`. This would certainly solve my problem of\n>>> having versioned descriptions and it would probably do it in a much more\n>>> general way than having a versioned included config.\n>>>\n>>> Anyone see any potential problems with this approach?\n>>\n>> I don't think it would be `refs/notes/`, as that is assumed to contain\n>> mappings of object ids (and if I understand correctly, this would be a\n>> mapping of branch names to data.\n>>\n>> You could just have \"refs/meta/descriptions/foo\" pointing to a blob\n>> which contains the description of \"refs/heads/foo\". That makes it easy\n>> to edit descriptions, even if you don't like using \"git branch\n>> --edit-description\".\n> \n> The only problem with this is that it's not really versioned, as it\n> would be hard to go back to previous versions and/or share the history\n> via pushing to a remote repository.\n> \n> But I guess that a very simple pseudo branch would do it, where\n> `refs/meta/` would point to a commit that has a tree\n> with a single file in it: `description.txt`.\n\nHaving some way to share branch metadata would be nice. I like the idea \nof using commits so we can merge changes and revert to a previous \nversion. There is some previous discussion here [1]. I'd really like to \nbe able to share the upstream for a branch between two computers as \nwell. I also use a commit containing a tree with a single file stored at \nrefs/todo/ (and fetched to refs/remote//todo/) \nto share todo lists with notes and ideas for future commits on branches \nthat I'm working on on more than one machine. Having them version \ncontrolled so they can be merged has been useful.\n\nBest Wishes\n\nPhillip\n\n[1] \nhttps://public-inbox.org/git/1519324188.6391.156.camel@mad-scientist.net/\n\n\n> I now like that idea a lot better than my original notes idea.\n> \n> Ciao,\n> Dscho\n> \n>>\n>> You could also have \"refs/meta/descriptions\" to point to a _single_ blob\n>> with all of the descriptions. It could even be in the existing config\n>> format. And then you could include it with \"[include] blob = ...\". That\n>> doesn't exist yet, but it would be easy to add (it was something I had\n>> always considered when writing the config-include code, but there was\n>> never really a good use; and you do have to be careful about pointing to\n>> untrusted blobs). That's a convoluted way to get where you want, but I\n>> wonder if integrating to the existing config system would have any\n>> benefits. I haven't really thought it through.\n>>\n>> (Of course that's also only one step away from having a versioned config\n>> file in your .git directory, but it might possibly be a bit easier to\n>> manage, since it would always be committed).\n>>\n>> That's mostly off-the-top-of-my-head rambling, so please disregard\n>> anything that seems totally off-base. :)\n>>\n>> -Peff\n>>\n"},{"id":"385218","messageId":"nycvar.QRO.7.76.6.1910311229150.46@tvgsbejvaqbjf.bet","threadId":"52161","inReplyTo":"8b9021fa-f60c-a2e0-1174-a2fc1f11c476@gmail.com","subject":"Re: git branch --edit-description a custom file","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-10-31T11:30:52Z","receivedAt":"2019-10-31T11:31:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Phillip,\n\nOn Thu, 31 Oct 2019, Phillip Wood wrote:\n\n> On 31/10/2019 10:22, Johannes Schindelin wrote:\n> >\n> > On Thu, 31 Oct 2019, Jeff King wrote:\n> >\n> > > On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:\n> > >\n> > > > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n> > > > Dscho brought up in the GGG thread[1] that perhaps we want to treat\n> > > > branch descriptions like notes and have them all under something like\n> > > > `refs/notes/branches`. This would certainly solve my problem of\n> > > > having versioned descriptions and it would probably do it in a much more\n> > > > general way than having a versioned included config.\n> > > >\n> > > > Anyone see any potential problems with this approach?\n> > >\n> > > I don't think it would be `refs/notes/`, as that is assumed to contain\n> > > mappings of object ids (and if I understand correctly, this would be a\n> > > mapping of branch names to data.\n> > >\n> > > You could just have \"refs/meta/descriptions/foo\" pointing to a blob\n> > > which contains the description of \"refs/heads/foo\". That makes it easy\n> > > to edit descriptions, even if you don't like using \"git branch\n> > > --edit-description\".\n> >\n> > The only problem with this is that it's not really versioned, as it\n> > would be hard to go back to previous versions and/or share the history\n> > via pushing to a remote repository.\n> >\n> > But I guess that a very simple pseudo branch would do it, where\n> > `refs/meta/` would point to a commit that has a tree\n> > with a single file in it: `description.txt`.\n>\n> Having some way to share branch metadata would be nice. I like the idea of\n> using commits so we can merge changes and revert to a previous version. There\n> is some previous discussion here [1]. I'd really like to be able to share the\n> upstream for a branch between two computers as well. I also use a commit\n> containing a tree with a single file stored at refs/todo/ (and fetched\n> to refs/remote//todo/) to share todo lists with notes and\n> ideas for future commits on branches that I'm working on on more than one\n> machine. Having them version controlled so they can be merged has been useful.\n\nAnd while we're dreaming: it would be nice to discern between \"push\nupstreams\" and \"base upstreams\". Example: when I work on the\n`fix-t5516-flakiness` branch, I target `upstream/master`, but I push to\n`dscho`, i.e. my \"push upstream\" is `dscho/fix-t5516-flakiness`.\n\nCiao,\nDscho\n\n> Best Wishes\n>\n> Phillip\n>\n> [1] https://public-inbox.org/git/1519324188.6391.156.camel@mad-scientist.net/\n>\n>\n> > I now like that idea a lot better than my original notes idea.\n> >\n> > Ciao,\n> > Dscho\n> >\n> > >\n> > > You could also have \"refs/meta/descriptions\" to point to a _single_ blob\n> > > with all of the descriptions. It could even be in the existing config\n> > > format. And then you could include it with \"[include] blob = ...\". That\n> > > doesn't exist yet, but it would be easy to add (it was something I had\n> > > always considered when writing the config-include code, but there was\n> > > never really a good use; and you do have to be careful about pointing to\n> > > untrusted blobs). That's a convoluted way to get where you want, but I\n> > > wonder if integrating to the existing config system would have any\n> > > benefits. I haven't really thought it through.\n> > >\n> > > (Of course that's also only one step away from having a versioned config\n> > > file in your .git directory, but it might possibly be a bit easier to\n> > > manage, since it would always be committed).\n> > >\n> > > That's mostly off-the-top-of-my-head rambling, so please disregard\n> > > anything that seems totally off-base. :)\n> > >\n> > > -Peff\n> > >\n>\n>\n"},{"id":"385221","messageId":"9aa1cefc-daeb-e702-95ba-1e83f8f7dcfe@iee.email","threadId":"52161","inReplyTo":"nycvar.QRO.7.76.6.1910311229150.46@tvgsbejvaqbjf.bet","subject":"Re: git branch --edit-description a custom file","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-10-31T13:45:31Z","receivedAt":"2019-10-31T13:45:32Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi,\nOn 31/10/2019 11:30, Johannes Schindelin wrote:\n> And while we're dreaming: it would be nice to discern between \"push\n> upstreams\" and \"base upstreams\". Example: when I work on the\n> `fix-t5516-flakiness` branch, I target `upstream/master`, but I push to\n> `dscho`, i.e. my \"push upstream\" is `dscho/fix-t5516-flakiness`.\n>\n> Ciao,\n> Dscho\nYep, the triangular workflow of 'publish' v 'upstream' v 'local' is \nquite tricky. There is little user facing docs for that.\n\nMany of my branches have the wrong \"upstream\" in the sense that it's the \npush-publish remote that holds copies of my work (i.e. I manually select \nthe push-remote every time;-), even though the branches are set to track \nthe original start point's upstream.\n\nPhilip\n"},{"id":"385222","messageId":"20191031154217.GA30187@sigill.intra.peff.net","threadId":"52161","inReplyTo":"9aa1cefc-daeb-e702-95ba-1e83f8f7dcfe@iee.email","subject":"Re: git branch --edit-description a custom file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-31T15:42:17Z","receivedAt":"2019-10-31T15:42:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 31, 2019 at 01:45:31PM +0000, Philip Oakley wrote:\n\n> Hi,\n> On 31/10/2019 11:30, Johannes Schindelin wrote:\n> > And while we're dreaming: it would be nice to discern between \"push\n> > upstreams\" and \"base upstreams\". Example: when I work on the\n> > `fix-t5516-flakiness` branch, I target `upstream/master`, but I push to\n> > `dscho`, i.e. my \"push upstream\" is `dscho/fix-t5516-flakiness`.\n> > \n> > Ciao,\n> > Dscho\n> Yep, the triangular workflow of 'publish' v 'upstream' v 'local' is quite\n> tricky. There is little user facing docs for that.\n> \n> Many of my branches have the wrong \"upstream\" in the sense that it's the\n> push-publish remote that holds copies of my work (i.e. I manually select the\n> push-remote every time;-), even though the branches are set to track the\n> original start point's upstream.\n\nDo either of you use remote.pushDefault, branch.*.pushRemote, or\n@{push}?\n\nMy triangular config for git.git looks like:\n\n [remote \"origin\"]\n\turl = https://github.com/gitster/git.git\n [remote \"github\"]\n\turl = https://github.com/peff/git.git\n [remote]\n\tpushDefault = github\n [branch \"jk/foo\"]\n\tremote = origin\n\tmerge = refs/heads/master\n\nThen upstream comparisons, \"git rebase\" etc without arguments, do what I\nwant: compare against master. And \"git push\" without arguments does what\nI want: push this branch to my fork. And if I need to refer to the\npushed version for some reason (e.g., comparing what I just changed to\nwhat I last sent out, \"git range-diff @{u} @{push} HEAD\" does the right\nthing.\n\n-Peff\n"},{"id":"385226","messageId":"20191031173507.GA70819@generichostname","threadId":"52161","inReplyTo":"20191031061832.GA20830@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-10-31T17:35:07Z","receivedAt":"2019-10-31T17:35:14Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"On Thu, Oct 31, 2019 at 02:18:32AM -0400, Jeff King wrote:\n> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:\n> \n> > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n> > Dscho brought up in the GGG thread[1] that perhaps we want to treat\n> > branch descriptions like notes and have them all under something like\n> > `refs/notes/branches`. This would certainly solve my problem of\n> > having versioned descriptions and it would probably do it in a much more\n> > general way than having a versioned included config.\n> > \n> > Anyone see any potential problems with this approach?\n> \n> I don't think it would be `refs/notes/`, as that is assumed to contain\n> mappings of object ids (and if I understand correctly, this would be a\n> mapping of branch names to data.\n> \n> You could just have \"refs/meta/descriptions/foo\" pointing to a blob\n> which contains the description of \"refs/heads/foo\". That makes it easy\n> to edit descriptions, even if you don't like using \"git branch\n> --edit-description\".\n> \n> You could also have \"refs/meta/descriptions\" to point to a _single_ blob\n> with all of the descriptions. It could even be in the existing config\n> format. And then you could include it with \"[include] blob = ...\". That\n> doesn't exist yet, but it would be easy to add (it was something I had\n> always considered when writing the config-include code, but there was\n> never really a good use; and you do have to be careful about pointing to\n> untrusted blobs). That's a convoluted way to get where you want, but I\n> wonder if integrating to the existing config system would have any\n> benefits. I haven't really thought it through.\n\nI like the ability to include blobs for several reasons:\n\nMain one is that it handles the versioned branch description problem.\nBut it goes further than that, there are a lot of config properties that\nteams might want to share amongst each other. For example, whenever a\nproject has a custom smudge filter, usually they include some sort of\nconfig in the project's README or some sort of setup script. With some\nway to include a shared version of some config, this might be simpler.\n\n> \n> (Of course that's also only one step away from having a versioned config\n> file in your .git directory, but it might possibly be a bit easier to\n> manage, since it would always be committed).\n> \n> That's mostly off-the-top-of-my-head rambling, so please disregard\n> anything that seems totally off-base. :)\n\nThanks for the discussion on this, I probably won't be implementing the\nblob config stuff for the purpose of branch descriptions but I think\nit's a good thing to think about.\n\n> \n> -Peff\n"},{"id":"385228","messageId":"20191031180632.GB2133@sigill.intra.peff.net","threadId":"52161","inReplyTo":"20191031173507.GA70819@generichostname","subject":"Re: git branch --edit-description a custom file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-31T18:06:32Z","receivedAt":"2019-10-31T18:06:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 31, 2019 at 10:35:07AM -0700, Denton Liu wrote:\n\n> > You could also have \"refs/meta/descriptions\" to point to a _single_ blob\n> > with all of the descriptions. It could even be in the existing config\n> > format. And then you could include it with \"[include] blob = ...\". That\n> > doesn't exist yet, but it would be easy to add (it was something I had\n> > always considered when writing the config-include code, but there was\n> > never really a good use; and you do have to be careful about pointing to\n> > untrusted blobs). That's a convoluted way to get where you want, but I\n> > wonder if integrating to the existing config system would have any\n> > benefits. I haven't really thought it through.\n> \n> I like the ability to include blobs for several reasons:\n> \n> Main one is that it handles the versioned branch description problem.\n> But it goes further than that, there are a lot of config properties that\n> teams might want to share amongst each other. For example, whenever a\n> project has a custom smudge filter, usually they include some sort of\n> config in the project's README or some sort of setup script. With some\n> way to include a shared version of some config, this might be simpler.\n\nThere are some past discussions on sharing config, and the security\nissues around it. The crux of it is that you probably ought to be\nvetting config you get from elsewhere (because it can execute arbitrary\ncode). At which point being able to refer to a blob isn't all _that_\nuseful, because these two processes are not all that different:\n\n git show origin/meta:shared-config\n # ok, looks good; _don't_ just include it by that name, though,\n # because it may be updated by a fetch\n git branch -f meta origin/meta\n git config include.blob meta:shared-config\n\n git show origin/meta:shared-config\n # ok, looks good\n git cat-file blob origin/meta:shared-config >.git/shared-config\n git config include.path shared-config\n\nThere's a specific discussion I'm thinking of which goes into this line\nof thinking, but I'm having trouble finding it in the archive. But IIRC,\nthe conclusion was negative towards directly including the blob because\nit doesn't make life better for careful users, and it makes it very easy\nto be unsafe for non-careful users.\n\nThere's also some (negative) discussion in this much older subthread:\n\n https://public-inbox.org/git/20120126074208.GD30474@sigill.intra.peff.net/\n\n-Peff\n"},{"id":"385230","messageId":"20191031181920.GB70819@generichostname","threadId":"52161","inReplyTo":"nycvar.QRO.7.76.6.1910311119080.46@tvgsbejvaqbjf.bet","subject":"Re: git branch --edit-description a custom file","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-10-31T18:19:20Z","receivedAt":"2019-10-31T18:19:26Z","isPatch":false,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Dscho,\n\nOn Thu, Oct 31, 2019 at 11:22:16AM +0100, Johannes Schindelin wrote:\n> Hi Peff,\n> \n> On Thu, 31 Oct 2019, Jeff King wrote:\n> \n> > On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:\n> >\n> > > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n> > > Dscho brought up in the GGG thread[1] that perhaps we want to treat\n> > > branch descriptions like notes and have them all under something like\n> > > `refs/notes/branches`. This would certainly solve my problem of\n> > > having versioned descriptions and it would probably do it in a much more\n> > > general way than having a versioned included config.\n> > >\n> > > Anyone see any potential problems with this approach?\n> >\n> > I don't think it would be `refs/notes/`, as that is assumed to contain\n> > mappings of object ids (and if I understand correctly, this would be a\n> > mapping of branch names to data.\n> >\n> > You could just have \"refs/meta/descriptions/foo\" pointing to a blob\n> > which contains the description of \"refs/heads/foo\". That makes it easy\n> > to edit descriptions, even if you don't like using \"git branch\n> > --edit-description\".\n> \n> The only problem with this is that it's not really versioned, as it\n> would be hard to go back to previous versions and/or share the history\n> via pushing to a remote repository.\n> \n> But I guess that a very simple pseudo branch would do it, where\n> `refs/meta/` would point to a commit that has a tree\n> with a single file in it: `description.txt`.\n\nSo how would you envision the workflow for this? Would it be something\nlike,\n\n\t$ git checkout feature-1\n\n\t$ git branch --edit-description=ref # instead of =config\n\t# editor opens up, :wq\n\n\t# is it find to have an autogenerated commit message?\n\t$ git show refs/meta/feature-1\n\tcommit 80dfea1dc4492aaabc80d23fbaffe86da55ee098 (refs/meta/feature-1)\n\tAuthor: Denton Liu \n\tDate: 42 seconds ago\n\n\t Update ref description\n\n\tdiff --git a/description.txt b/description.txt\n\tnew file mode 100644\n\tindex 0000000..ed03a4b\n\t--- /dev/null\n\t+++ b/description.txt\n\t@@ -0,0 +1 @@\n\t+this is a description\n\nI have some open questions about this, though:\n\n* Since we're planning on sharing these descriptions with the outside\n world, how would the ref layout look like? If we're not using the\n refs/remotes namespace will it make fetching and merging notes harder?\n I know that collaborating with notes is a pain so how do we avoid\n making the same mistake?\n\n* On the above point, what if local descriptions are at\n refs/meta/heads/feature-1 while remote descriptions are at\n refs/meta/remotes/*/feature-1?\n\n* What would a merge workflow look like? Would we have wrapper commands\n for it or do users just have to checkout the description branch\n themselves?\n\nThanks,\n\nDenton\n\n> \n> I now like that idea a lot better than my original notes idea.\n> \n> Ciao,\n> Dscho\n"},{"id":"385235","messageId":"4ef79cfb-b970-2b2b-131d-3f47e6b0e308@gmail.com","threadId":"52161","inReplyTo":"20191031181920.GB70819@generichostname","subject":"Re: git branch --edit-description a custom file","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-10-31T19:53:18Z","receivedAt":"2019-10-31T19:53:25Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Denton & Dscho\n\nOn 31/10/2019 18:19, Denton Liu wrote:\n> Hi Dscho,\n> \n> On Thu, Oct 31, 2019 at 11:22:16AM +0100, Johannes Schindelin wrote:\n>> Hi Peff,\n>>\n>> On Thu, 31 Oct 2019, Jeff King wrote:\n>>\n>>> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:\n>>>\n>>>> On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:\n>>>> Dscho brought up in the GGG thread[1] that perhaps we want to treat\n>>>> branch descriptions like notes and have them all under something like\n>>>> `refs/notes/branches`. This would certainly solve my problem of\n>>>> having versioned descriptions and it would probably do it in a much more\n>>>> general way than having a versioned included config.\n>>>>\n>>>> Anyone see any potential problems with this approach?\n>>>\n>>> I don't think it would be `refs/notes/`, as that is assumed to contain\n>>> mappings of object ids (and if I understand correctly, this would be a\n>>> mapping of branch names to data.\n>>>\n>>> You could just have \"refs/meta/descriptions/foo\" pointing to a blob\n>>> which contains the description of \"refs/heads/foo\". That makes it easy\n>>> to edit descriptions, even if you don't like using \"git branch\n>>> --edit-description\".\n>>\n>> The only problem with this is that it's not really versioned, as it\n>> would be hard to go back to previous versions and/or share the history\n>> via pushing to a remote repository.\n>>\n>> But I guess that a very simple pseudo branch would do it, where\n>> `refs/meta/` would point to a commit that has a tree\n>> with a single file in it: `description.txt`.\n> \n> So how would you envision the workflow for this? Would it be something\n> like,\n> \n> \t$ git checkout feature-1\n> \n> \t$ git branch --edit-description=ref # instead of =config\n\nPersonally I'd prefer a config setting that meant --edit-description \nstored the description in a ref instead of the current config key (or \nperhaps as well as so format-patch can just get the latest branch \ndescription from the config key)\n\n> \t# editor opens up, :wq\n> \n> \t# is it find to have an autogenerated commit message?\n> \t$ git show refs/meta/feature-1\n> \tcommit 80dfea1dc4492aaabc80d23fbaffe86da55ee098 (refs/meta/feature-1)\n> \tAuthor: Denton Liu \n> \tDate: 42 seconds ago\n> \n> \t Update ref description\n> \n> \tdiff --git a/description.txt b/description.txt\n> \tnew file mode 100644\n> \tindex 0000000..ed03a4b\n> \t--- /dev/null\n> \t+++ b/description.txt\n> \t@@ -0,0 +1 @@\n> \t+this is a description\n> \n> I have some open questions about this, though:\n> \n> * Since we're planning on sharing these descriptions with the outside\n> world, how would the ref layout look like? If we're not using the\n> refs/remotes namespace will it make fetching and merging notes harder?\n> I know that collaborating with notes is a pain so how do we avoid\n> making the same mistake?\n\nI'd love to see a consensus around putting remote versions of refs/foo \nunder refs/remote//foo. To share notes I add a refspec that \nfetches to refs/remote//notes. It is a pain that 'git pull' \nwont merge them for me though.\n\n> * On the above point, what if local descriptions are at\n> refs/meta/heads/feature-1 while remote descriptions are at\n> refs/meta/remotes/*/feature-1?\n> \n> * What would a merge workflow look like? Would we have wrapper commands\n> for it or do users just have to checkout the description branch\n> themselves?\n\nTeaching 'git pull' to (configurably) merge things under \nrefs/remote//foo to refs/foo would be a useful addition, \nthen it could merge notes and any other refs people are sharing.\n\nBest Wishes\n\nPhillip\n\n\n> Thanks,\n> \n> Denton\n> \n>>\n>> I now like that idea a lot better than my original notes idea.\n>>\n>> Ciao,\n>> Dscho\n"},{"id":"385238","messageId":"20191031200739.GA19313@sigill.intra.peff.net","threadId":"52161","inReplyTo":"4ef79cfb-b970-2b2b-131d-3f47e6b0e308@gmail.com","subject":"Re: git branch --edit-description a custom file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-10-31T20:07:39Z","receivedAt":"2019-10-31T20:07:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 31, 2019 at 07:53:18PM +0000, Phillip Wood wrote:\n\n> > So how would you envision the workflow for this? Would it be something\n> > like,\n> > \n> > \t$ git checkout feature-1\n> > \n> > \t$ git branch --edit-description=ref # instead of =config\n> \n> Personally I'd prefer a config setting that meant --edit-description stored\n> the description in a ref instead of the current config key (or perhaps as\n> well as so format-patch can just get the latest branch description from the\n> config key)\n\nYes, a config option makes much more sense to me. Both the writers and\nreaders will need to know where to find the data.\n\n> > * Since we're planning on sharing these descriptions with the outside\n> > world, how would the ref layout look like? If we're not using the\n> > refs/remotes namespace will it make fetching and merging notes harder?\n> > I know that collaborating with notes is a pain so how do we avoid\n> > making the same mistake?\n> \n> I'd love to see a consensus around putting remote versions of refs/foo under\n> refs/remote//foo. To share notes I add a refspec that fetches\n> to refs/remote//notes. It is a pain that 'git pull' wont merge\n> them for me though.\n\nThe trouble with that sort of scheme is that it conflicts with the\ncurrent namespace scheme, which puts the remote \"notes\" branch in\n\"refs/remotes//notes\". And it's not just a problem if you\nwant to have a branch called \"notes\". Think about what \"git fetch\n--prune\" would do.\n\nI do think the world would be a better place if we mapped (all or a\nsubset of) the remote \"refs/\" into \"refs/remotes//\". I.e.,\nreally creating \"refs/remotes/origin/heads\" and even\n\"refs/remotes/origin/tags\". But we'd need to re-adjust the way that some\nref lookups work (e.g., looking in refs/remotes/*/tags for tags).\n\nThere was some work by Johan Herland around the v1.8 time-frame, but it\nstalled:\n\n https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/\n\nAnd here's some later discussion:\n\n https://public-inbox.org/git/CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com/\n\nSo in short, I agree very much with the direction you're discussing, but\nI think there's some fundamental work that needs done first.\n\n-Peff\n"},{"id":"385260","messageId":"822d51af-d522-bf2c-72de-f54a4ccb3b38@gmail.com","threadId":"52161","inReplyTo":"20191031200739.GA19313@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-11-01T12:29:43Z","receivedAt":"2019-11-01T12:29:50Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Peff\n\nOn 31/10/2019 20:07, Jeff King wrote:\n> On Thu, Oct 31, 2019 at 07:53:18PM +0000, Phillip Wood wrote:\n> [...]\n>>\n>> I'd love to see a consensus around putting remote versions of refs/foo under\n>> refs/remote//foo. To share notes I add a refspec that fetches\n>> to refs/remote//notes. It is a pain that 'git pull' wont merge\n>> them for me though.\n> \n> The trouble with that sort of scheme is that it conflicts with the\n> current namespace scheme, which puts the remote \"notes\" branch in\n> \"refs/remotes//notes\". And it's not just a problem if you\n> want to have a branch called \"notes\". Think about what \"git fetch\n> --prune\" would do.\n\nI was suggesting a convention of using refs/remote/ not refs/remotes/ \nfor tracking remote refs that are not branches to avoid that problem. \nIt's not ideal to have remote branches under a different namespace to \nall the other remote refs but it does avoid breaking current setups. I \nhaven't thought it through but perhaps in the long run we could migrate \nremote branches to refs/remote//heads/ and treat \nrefs/remotes// as an alias for \nrefs/remote//heads/. As you say below we'd need to think \nabout how to use remote tags as well.\n\n> I do think the world would be a better place if we mapped (all or a\n> subset of) the remote \"refs/\" into \"refs/remotes//\". I.e.,\n> really creating \"refs/remotes/origin/heads\" and even\n> \"refs/remotes/origin/tags\". But we'd need to re-adjust the way that some\n> ref lookups work (e.g., looking in refs/remotes/*/tags for tags).\n> \n> There was some work by Johan Herland around the v1.8 time-frame, but it\n> stalled:\n> \n> https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/\n> \n> And here's some later discussion:\n> \n> https://public-inbox.org/git/CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com/\n> \n> So in short, I agree very much with the direction you're discussing, but\n> I think there's some fundamental work that needs done first.\n\nThanks for the links, I'll have a read through them.\n\nBest Wishes\n\nPhillip\n\n> -Peff\n> \n"},{"id":"385268","messageId":"20191101164955.GA26219@sigill.intra.peff.net","threadId":"52161","inReplyTo":"822d51af-d522-bf2c-72de-f54a4ccb3b38@gmail.com","subject":"Re: git branch --edit-description a custom file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-11-01T16:49:55Z","receivedAt":"2019-11-01T16:49:58Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 01, 2019 at 12:29:43PM +0000, Phillip Wood wrote:\n\n> > > I'd love to see a consensus around putting remote versions of refs/foo under\n> > > refs/remote//foo. To share notes I add a refspec that fetches\n> > > to refs/remote//notes. It is a pain that 'git pull' wont merge\n> > > them for me though.\n> > \n> > The trouble with that sort of scheme is that it conflicts with the\n> > current namespace scheme, which puts the remote \"notes\" branch in\n> > \"refs/remotes//notes\". And it's not just a problem if you\n> > want to have a branch called \"notes\". Think about what \"git fetch\n> > --prune\" would do.\n> \n> I was suggesting a convention of using refs/remote/ not refs/remotes/ for\n> tracking remote refs that are not branches to avoid that problem. It's not\n> ideal to have remote branches under a different namespace to all the other\n> remote refs but it does avoid breaking current setups. I haven't thought it\n> through but perhaps in the long run we could migrate remote branches to\n> refs/remote//heads/ and treat refs/remotes// as an\n> alias for refs/remote//heads/. As you say below we'd need to\n> think about how to use remote tags as well.\n\nOh indeed, I totally missed that subtlety. Sorry.\n\n> Thanks for the links, I'll have a read through them.\n\nMaybe I've managed to trick you into working on the greater refs/remotes\norganization problem, though. ;)\n\n-Peff\n"},{"id":"385278","messageId":"0bd3d494-ff99-9895-d913-51a24f8092af@gmail.com","threadId":"52161","inReplyTo":"20191101164955.GA26219@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Phillip Wood","fromEmail":"phillip.wood123@gmail.com","sentAt":"2019-11-01T20:35:52Z","receivedAt":"2019-11-01T20:35:58Z","isPatch":false,"sender":{"key":"phillip.wood@dunelm.org.uk","avatar":null},"body":"Hi Peff\n\nOn 01/11/2019 16:49, Jeff King wrote:\n> On Fri, Nov 01, 2019 at 12:29:43PM +0000, Phillip Wood wrote:\n> \n>>>> I'd love to see a consensus around putting remote versions of refs/foo under\n>>>> refs/remote//foo. To share notes I add a refspec that fetches\n>>>> to refs/remote//notes. It is a pain that 'git pull' wont merge\n>>>> them for me though.\n>>>\n>>> The trouble with that sort of scheme is that it conflicts with the\n>>> current namespace scheme, which puts the remote \"notes\" branch in\n>>> \"refs/remotes//notes\". And it's not just a problem if you\n>>> want to have a branch called \"notes\". Think about what \"git fetch\n>>> --prune\" would do.\n>>\n>> I was suggesting a convention of using refs/remote/ not refs/remotes/ for\n>> tracking remote refs that are not branches to avoid that problem. It's not\n>> ideal to have remote branches under a different namespace to all the other\n>> remote refs but it does avoid breaking current setups. I haven't thought it\n>> through but perhaps in the long run we could migrate remote branches to\n>> refs/remote//heads/ and treat refs/remotes// as an\n>> alias for refs/remote//heads/. As you say below we'd need to\n>> think about how to use remote tags as well.\n> \n> Oh indeed, I totally missed that subtlety. Sorry.\n\nI should have made the difference clearer, it's easy to miss the missing \n's'\n\n>> Thanks for the links, I'll have a read through them.\n> \n> Maybe I've managed to trick you into working on the greater refs/remotes\n> organization problem, though. ;)\n\nMaybe we'll see once I've read those threads next week!\n\nPhillip\n> -Peff\n> \n"},{"id":"385298","messageId":"xmqqk18i516f.fsf@gitster-ct.c.googlers.com","threadId":"52161","inReplyTo":"20191031200739.GA19313@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-02T04:53:28Z","receivedAt":"2019-11-02T04:53:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> There was some work by Johan Herland around the v1.8 time-frame, but it\n> stalled:\n>\n> https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/\n>\n> And here's some later discussion:\n>\n> https://public-inbox.org/git/CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com/\n>\n> So in short, I agree very much with the direction you're discussing, but\n> I think there's some fundamental work that needs done first.\n\nYes, I think this comes up from time to time in different guise. I\nthik the latest iteration is in the thread:\n\nhttps://public-inbox.org/git/CA+P7+xpdYMA8L-_Y+W5q7_zbj9RNcH1erY=dVbDG-EDOiHhTwA@mail.gmail.com/\n"},{"id":"385345","messageId":"49625b39-61dc-f702-eeba-9bdec60a42d1@iee.email","threadId":"52161","inReplyTo":"20191031154217.GA30187@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-11-03T17:56:04Z","receivedAt":"2019-11-03T17:56:08Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Peff,\n\nOn 31/10/2019 15:42, Jeff King wrote:\n> On Thu, Oct 31, 2019 at 01:45:31PM +0000, Philip Oakley wrote:\n>\n>> Hi,\n>> On 31/10/2019 11:30, Johannes Schindelin wrote:\n>>> And while we're dreaming: it would be nice to discern between \"push\n>>> upstreams\" and \"base upstreams\". Example: when I work on the\n>>> `fix-t5516-flakiness` branch, I target `upstream/master`, but I push to\n>>> `dscho`, i.e. my \"push upstream\" is `dscho/fix-t5516-flakiness`.\n>>>\n>>> Ciao,\n>>> Dscho\n>> Yep, the triangular workflow of 'publish' v 'upstream' v 'local' is quite\n>> tricky. There is little user facing docs for that.\n>>\n>> Many of my branches have the wrong \"upstream\" in the sense that it's the\n>> push-publish remote that holds copies of my work (i.e. I manually select the\n>> push-remote every time;-), even though the branches are set to track the\n>> original start point's upstream.\n> Do either of you use remote.pushDefault, branch.*.pushRemote, or\n> @{push}?\nI haven't been using those configs, and was only vaguely aware of them \nand what, if anything, they did (inc how to set them up _systematically_)\n\n>\n> My triangular config for git.git looks like:\n>\n> [remote \"origin\"]\n> \turl = https://github.com/gitster/git.git\n> [remote \"github\"]\n> \turl = https://github.com/peff/git.git\n> [remote]\n> \tpushDefault = github\n> [branch \"jk/foo\"]\n> \tremote = origin\n> \tmerge = refs/heads/master\n\nI had recently seen your <20190731055832.GA18039@sigill.intra.peff.net> \n(Wed, 31 Jul 2019 01:58:33 -0400) which mentioned your setting.\n>\n> Then upstream comparisons, \"git rebase\" etc without arguments, do what I\n> want: compare against master. And \"git push\" without arguments does what\n> I want: push this branch to my fork. And if I need to refer to the\n> pushed version for some reason (e.g., comparing what I just changed to\n> what I last sent out, \"git range-diff @{u} @{push} HEAD\" does the right\n> thing.\n\nI am trying to write myself some 'user' based notes covering the \npublish-backup-collaborate-upstream viewpoints of the different repo \nsettings as the config pages rarely give that viewpoint (hence my bad \nsetup).\n\nThere's also still the 'triangle' workflow to clarify - does it refer to \npatch based flow, or to a three-way repo config?\n\nI suspect there are more configs that need setting up for a proper \nstable user experience (e.g. the merge setting of '--ff-only' when the \nlocal branch \"--follow\"s the upstream but should never have local changes).\n\n-- \nPhilip\n"},{"id":"385357","messageId":"xmqqd0e81g33.fsf@gitster-ct.c.googlers.com","threadId":"52161","inReplyTo":"20191031154217.GA30187@sigill.intra.peff.net","subject":"Re: git branch --edit-description a custom file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-11-04T03:21:52Z","receivedAt":"2019-11-04T03:21:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Do either of you use remote.pushDefault, branch.*.pushRemote, or\n> @{push}?\n>\n> My triangular config for git.git looks like:\n>\n> [remote \"origin\"]\n> \turl = https://github.com/gitster/git.git\n> [remote \"github\"]\n> \turl = https://github.com/peff/git.git\n> [remote]\n> \tpushDefault = github\n> [branch \"jk/foo\"]\n> \tremote = origin\n> \tmerge = refs/heads/master\n>\n> Then upstream comparisons, \"git rebase\" etc without arguments, do what I\n> want: compare against master. And \"git push\" without arguments does what\n> I want: push this branch to my fork. And if I need to refer to the\n> pushed version for some reason (e.g., comparing what I just changed to\n> what I last sent out, \"git range-diff @{u} @{push} HEAD\" does the right\n> thing.\n\nYeah, I do recall we had quite a lot of design discussions around\n\"triangular\" workflow when we introduced these facilities, and if I\nam not mistaken, the above is the way they are designed to be used.\n\nThanks for an example.\n"},{"id":"385416","messageId":"20191104195053.GA20900@sigill.intra.peff.net","threadId":"52161","inReplyTo":"49625b39-61dc-f702-eeba-9bdec60a42d1@iee.email","subject":"Re: git branch --edit-description a custom file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-11-04T19:50:53Z","receivedAt":"2019-11-04T19:50:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 03, 2019 at 05:56:04PM +0000, Philip Oakley wrote:\n\n> > Then upstream comparisons, \"git rebase\" etc without arguments, do what I\n> > want: compare against master. And \"git push\" without arguments does what\n> > I want: push this branch to my fork. And if I need to refer to the\n> > pushed version for some reason (e.g., comparing what I just changed to\n> > what I last sent out, \"git range-diff @{u} @{push} HEAD\" does the right\n> > thing.\n> \n> I am trying to write myself some 'user' based notes covering the\n> publish-backup-collaborate-upstream viewpoints of the different repo\n> settings as the config pages rarely give that viewpoint (hence my bad\n> setup).\n> \n> There's also still the 'triangle' workflow to clarify - does it refer to\n> patch based flow, or to a three-way repo config?\n\nI think it's solely about the three-way repo config. The key thing is\nthat \"somehow\" the commits I push to my fork end up in the upstream\nrepository. In git.git, that happens via the mailing list workflow. But\nin projects based on GitHub, it's cross-fork pull requests. I guess in a\nproject like linux.git, it could even via real \"git pull\" commands.\n\nBut in any of those cases, the config I showed would be what you want.\n(I forgot to show that I also set push.default to \"current\", since the\ndefault \"simple\" wouldn't make much sense).\n\n> I suspect there are more configs that need setting up for a proper stable\n> user experience (e.g. the merge setting of '--ff-only' when the local branch\n> \"--follow\"s the upstream but should never have local changes).\n\nPossibly. I don't actually keep a regular \"master\" branch in my local\nclone. I use \"origin/master\" as the upstream base for my branches, and\nfor when I need to test the current vanilla behavior to reproduce a bug\n(I just \"git checkout origin/master\" and work on a detached HEAD).\n\nIf you did keep such a branch, though, then yeah, I think you'd want to\nuse --ff-only, because it's just tracking upstream.\n\n-Peff\n"}]}