Thread (19 messages) 19 messages, 5 authors, 2019-11-04

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 =config
Personally 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help