git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/4] deprecating core.preferSymlinkRefs

From
Derrick Stolee <stolee@gmail.com>
Date
Sep 18, 2024, 23:38 UTC
Message-ID
<beb10633-78d7-4fe3-a71b-73d5a4bbb5ac@gmail.com>
In-Reply-To
<20240918232825.2627999-1-gitster@pobox.com>
On 9/18/24 7:28 PM, Junio C Hamano wrote:
Show 5 quoted lines
> Removal of support for core.preferSymlinkRefs at Git 3.0 boundary,
> so that we only write textual symrefs for things like HEAD and
> refs/remotes/origin/HEAD, and still understand symbolic links used
> as symrefs in existing repositories, is a serious proposal this
> patch series makes.

I missed a lot of this discussion about 3.0, but I'm fascinated by the prospect.

Show 20 quoted lines
> What I want people to think about is how to ensure quality of the
> Git 3.0 phase.  We can iterate and polish the proposal phase with as
> much time as we want to spend, just like any new feature.  But Git
> 3.0 phase is with a solid deadline, and before that time, we cannot
> remove the feature for real.  Would we cook such steps in 'next'
> forever until the actual Git 3.0?  To those users who are running
> 'next' based Git, it would mean that some of the changes the
> breaking changes document listed would come a lot earlier to them.
> On the other hand, unless we somehow have a way to expose willing
> volunteers an early access to these "big changes", there is no way
> for them to be as stable and tested.  We should not plan to scramble
> and be able to perfect these changes between Git v3.0-rc0 and Git
> v3.0 final.
> 
> Or perhaps use the "experimental.*" configuration stored in the
> user's ~/.gitconfig to let users opt into Git 3.0 features (one of
> which may be that textual symrefs are always used regardless of the
> core.preferSymlinkRefs setting)?  That way, we can merge these big
> changes early without worrying about accidentally affecting the
> end-user population.

I do like the idea of having someone set 'feature.git3=true' in their global config and having that mean that they are ready to accept the Git 3.0 breaking changes as they are available in a Git 2.x release. As much early testing as we can get would be beneficial.

This would be a way to get your patches 2 & 3 into 'master' and released, but I'm not sure exactly how to keep patch 4 queued for a potential future release. The best I could think of is to have a long-running 'master-v3' branch that takes these cleanup patches and then merges ongoing 'master' changes into them. It would be a gross history to manage, but it could potentially work. It does lead to concerns as to how to communicate that a change to 'master' has broken the 'master-v3' CI or how an incoming change could create conflicts with 'master-v3'.

Sorry I don't have full solutions for you. Only more problems.

Thanks, -Stolee

Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 12 in “deprecating core.preferSymlinkRefs”
  1. 0/4 deprecating core.preferSymlinkRefsJunio C Hamano, Sep 18, 2024
  2. 1/4 refs: deprecate core.preferSymlinkRefsJunio C Hamano, Sep 18, 2024
  3. Patrick SteinhardtSep 30, 2024
  4. 2/4 refs: mostly remove core.preferSymlinkRefsJunio C Hamano, Sep 18, 2024
  5. Jeff KingSep 30, 2024
  6. Junio C HamanoSep 30, 2024
  7. 3/4 refs: remove NO_SYMLINK_HEADJunio C Hamano, Sep 18, 2024
  8. 4/4 refs: remove the last remnants of core.preferSymlinkRefsJunio C Hamano, Sep 18, 2024
  9. Derrick StoleeSep 18, 2024
  10. Junio C HamanoSep 19, 2024
  11. Patrick SteinhardtSep 30, 2024
  12. Junio C HamanoSep 30, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.