Re: git branch --edit-description a custom file
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Nov 1, 2019, 20:35 UTC
- Message-ID
- <0bd3d494-ff99-9895-d913-51a24f8092af@gmail.com>
- In-Reply-To
- <20191101164955.GA26219@sigill.intra.peff.net>
Hi Peff
On 01/11/2019 16:49, Jeff King wrote:
Show 23 quoted lines
> On Fri, Nov 01, 2019 at 12:29:43PM +0000, Phillip Wood wrote: > >>>> 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 was suggesting a convention of using refs/remote/ not refs/remotes/ for >> tracking remote refs that are not branches to avoid that problem. It's not >> ideal to have remote branches under a different namespace to all the other >> remote refs but it does avoid breaking current setups. I haven't thought it >> through but perhaps in the long run we could migrate remote branches to >> refs/remote/<remote-name>/heads/ and treat refs/remotes/<remote-name>/ as an >> alias for refs/remote/<remote-name>/heads/. As you say below we'd need to >> think about how to use remote tags as well. > > Oh indeed, I totally missed that subtlety. Sorry.
I should have made the difference clearer, it's easy to miss the missing 's'
>> Thanks for the links, I'll have a read through them. > > Maybe I've managed to trick you into working on the greater refs/remotes > organization problem, though. ;)
Maybe we'll see once I've read those threads next week!
Phillip
> -Peff >