Re: [PATCH 00/30] [RFC] extensions.refFormat and packed-refs v2 file format
- From
Sean Allred <allred.sean@gmail.com>
- Date
- Nov 30, 2022, 18:37 UTC
- Message-ID
- <87cz94xozi.fsf@gmail.com>
- In-Reply-To
- <CAFQ2z_MLwUoaSTG04LJYHgJH-QYJEuZ9bQcTsV8mXwxBbz7Egg@mail.gmail.com>
Han-Wen Nienhuys <hanwen@google.com> writes:
> To be honest, I don't understand why symrefs are such a generic > concept; I've only ever seen them used for HEAD.
I've been only lurking in this thread (and loosely following along, even!) but I do want to call out that I have recently considered perhaps abusing symrefs to point to normal feature branches. In our workflow, we have documentation records identified by a numeric ID -- the code changes corresponding to that documentation (testing instructions, etc.) use formulaic branch names like `feature/123456`.
It is sometimes beneficial for two or more of these documentation records to perform their work on the same code branch. There are myriad reasons for this, some better than others, but I want to avoid getting mired in whether or not this is a good idea. It does happen and is sometimes even the best way to do it.
In these scenarios, I've considered having `feature/2` be a symref to `feature/1` so that both features can always 'know' what to call their branch for operations like checkout. I've done this on a smaller scale in the past to great effect.
Nothing is set in stone here for us, but I did want to call this out as a potential real-world use case.
-- Sean Allred