Re: git branch --edit-description a custom file
From: Jeff King <hidden>
Date: 2019-10-31 20:07:41
On Thu, Oct 31, 2019 at 07:53:18PM +0000, Phillip Wood wrote:
quoted
So how would you envision the workflow for this? Would it be something like, $ git checkout feature-1 $ git branch --edit-description=ref # instead of =configPersonally I'd prefer a config setting that meant --edit-description stored the description in a ref instead of the current config key (or perhaps as well as so format-patch can just get the latest branch description from the config key)
Yes, a config option makes much more sense to me. Both the writers and readers will need to know where to find the data.
quoted
* Since we're planning on sharing these descriptions with the outside world, how would the ref layout look like? If we're not using the refs/remotes namespace will it make fetching and merging notes harder? I know that collaborating with notes is a pain so how do we avoid making the same mistake?I'd love to see a consensus around putting remote versions of refs/foo under refs/remote/<remote-name>/foo. To share notes I add a refspec that fetches to refs/remote/<remote-name>/notes. It is a pain that 'git pull' wont merge them for me though.
The trouble with that sort of scheme is that it conflicts with the current namespace scheme, which puts the remote "notes" branch in "refs/remotes/<remote-name>/notes". And it's not just a problem if you want to have a branch called "notes". Think about what "git fetch --prune" would do. I do think the world would be a better place if we mapped (all or a subset of) the remote "refs/" into "refs/remotes/<remote-name>/". I.e., really creating "refs/remotes/origin/heads" and even "refs/remotes/origin/tags". But we'd need to re-adjust the way that some ref lookups work (e.g., looking in refs/remotes/*/tags for tags). There was some work by Johan Herland around the v1.8 time-frame, but it stalled: https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/ And here's some later discussion: https://public-inbox.org/git/CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com/ So in short, I agree very much with the direction you're discussing, but I think there's some fundamental work that needs done first. -Peff