| Message ID | pull.762.git.1605221038.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Use main as default branch name | expand |
On Thu, Nov 12, 2020 at 5:55 PM Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote: > This is the big one. This changes the default of init.defaultBranch to main, > reflecting what many open source projects already did (which was followed by > GitHub, Azure Repos and others). I want to plant a big red flag here for the record. I am against this change. At the very least in the manner it is being made. I started a separate thread [1] explaining the reasoning. In addition to the manner--which I argue in that other thread should be done for Git 3.0--I also object to the reasoning behind the change. Let me know if you would rather hear my arguments against the reasoning here, or in the other thread. Cheers. [1] https://lore.kernel.org/git/CAMP44s3BJ3dGsLJ-6yA-Po459=+m826KD9an4+P3qOY1vkbxZg@mail.gmail.com/
On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote: > This is the big one. This changes the default of init.defaultBranch to main, > reflecting what many open source projects already did (which was followed by > GitHub, Azure Repos and others). I don't have an issue with the end goal of s/master/main|$whatever/ as UX here as noted in previous related review rounds. But I don't think this series as it stands is anywhere near ready. This is 27 patches of s/master/main/ in the tests, followed by making the change to the default in refs.c without as much as a single documentation update to inform users of the change. I don't see the point in doing these sorts of test suite changes, it just seems like needless churn. But I have not read the whole backlog of previous iterations of this & related patches, so bear with me. Why not instead do what we did when we added protocol v2 to the tests, e.g. in 8a1b0978ab ("test: request GIT_TEST_PROTOCOL_VERSION=0 when appropriate", 2019-12-23) we simply set the t5515 test to always run with protocol v1. If you'd do this: diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh index 70a9d2d8ab..939c8b2f83 100755 --- a/t/t5515-fetch-merge-logic.sh +++ b/t/t5515-fetch-merge-logic.sh @@ -11,6 +11,9 @@ test_description='Merge logic in fetch' GIT_TEST_PROTOCOL_VERSION=0 export GIT_TEST_PROTOCOL_VERSION +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME + . ./test-lib.sh build_script () { Of course that also needs: index fa347ed3e1..2d700a171b 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -1711,10 +1711,8 @@ test_lazy_prereq SHA1 ' test_lazy_prereq REBASE_P ' test -z "$GIT_TEST_SKIP_REBASE_P" ' -# Special-purpose prereq for transitioning to a new default branch name: -# Some tests need more than just a mindless (case-preserving) s/master/main/g -# replacement. The non-trivial adjustments are guarded behind this -# prerequisite, acting kind of as a feature flag -test_lazy_prereq PREPARE_FOR_MAIN_BRANCH ' - test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" = main + +test_lazy_prereq MAIN_BRANCH_IS_MASTER ' + test -z "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" || + test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" = "master" ' Because (but see "later" a few paragraphs later), the logic as it stands on "master" is entirely backwards & broken. I.e. if you don't set GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME or set it to "master" we now skip a bunch of tests ... which only work if the value is "master". If you set it to "main" they'll break. Then instead of ending up with a hardcoding of "main" we'd be able to run the tests with a new custom branch name (even one with whitespace in it). That coverage is plenty to test any branch name hardcoding. The remaining tests that would still have "master" would then just be dealt with by the same thing we did for the too-protocol-v1-specific tests, i.e.: diff --git a/t/t3502-cherry-pick-merge.sh b/t/t3502-cherry-pick-merge.sh index 8b635a196d..354f9bd851 100755 --- a/t/t3502-cherry-pick-merge.sh +++ b/t/t3502-cherry-pick-merge.sh @@ -8,6 +8,8 @@ test_description='cherry picking and reverting a merge ' +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME . ./test-lib.sh test_expect_success setup ' Except unlike protocol v1/v2 we're really not gaining anything in coverage by going further, it's not the point of any of these tests to test for the default branch name. It's a *lot* of churn, "Later": After writing the above I see from 704fed9ea2 ("tests: start moving to a different default main branch name", 2020-10-23) that this state of affairs is intentional. But doesn't discuss why the more usual (because we've done it that way a few times before) v1/v2-esque transition wasn't done instead. Doing it the other way still seems better. We're now not running our full tests in anticipation for this series landing on "master", and after applying this we're still not running all of them. Anyway, enough with discussing this detail of the test suite churn. My main objection to this version of it is: After this series as it stands lands what's a rather big UI change in git isn't discussed *anywhere* in the docs. I'm not saying we need some similar s/master/main/g in Documentation/ as what's being done here in t/, but I think a bare minimum for a rather big UI change like this is: 1) Let's at least talk about it in some way in git-init(1), i.e. that it used to be "master" before version so-and-so and is now different. With this series applied we still say: Documentation/git-init.txt:If not specified, fall back to the default name: `master`. 2) Ditto in the init.defaultBranch and things like that 3) After all this effort at eliminating "master" entirely in the tests we're still shipping a sample hook that expects "master" on "git init", and breaks now that it's "main" And maybe stuff like: 4) Have "git init" emit some new advice message saying that the default has changed and we've init-ed a new repo with a "main" branch. Our primary concern should be the vast majority of users who don't follow this topic on Twitter, don't read this mailing list, and are just going to waste 10 minutes of their day because some script they've had working for years using "git init" did something unexpected. Let's at least aim to make that 5 minutes instead by making the change more discoverable.
Hi Ævar, On Fri, 13 Nov 2020, Ævar Arnfjörð Bjarmason wrote: > On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote: > > > This is the big one. This changes the default of init.defaultBranch to main, > > reflecting what many open source projects already did (which was followed by > > GitHub, Azure Repos and others). > > I don't have an issue with the end goal of s/master/main|$whatever/ as > UX here as noted in previous related review rounds. But I don't think > this series as it stands is anywhere near ready. > > This is 27 patches of s/master/main/ in the tests, followed by making > the change to the default in refs.c without as much as a single > documentation update to inform users of the change. Of course, this is _the one_ patch series mentioned in https://github.com/gitgitgadget/git/pull/655 that does _not_ link back to the meta-PR. So you're right, on its own, these 28 patches do not make sense. And if you split off the 28th patch, the remaining 27 patches make even less sense. The reason why I partitioned the changes this way was that it is a _ton_ of patches to review, and in many ways, these 28 patches are the most important ones to review (I didn't want to just rely on the CI builds passing, I reviewed those patches carefully, multiple times, to make sure that they made sense in the goal to transition to `main`). I will respond to the rest of your concerns later, Dscho > > I don't see the point in doing these sorts of test suite changes, it > just seems like needless churn. But I have not read the whole backlog of > previous iterations of this & related patches, so bear with me. > > Why not instead do what we did when we added protocol v2 to the tests, > e.g. in 8a1b0978ab ("test: request GIT_TEST_PROTOCOL_VERSION=0 when > appropriate", 2019-12-23) we simply set the t5515 test to always run > with protocol v1. If you'd do this: > > diff --git a/t/t5515-fetch-merge-logic.sh b/t/t5515-fetch-merge-logic.sh > index 70a9d2d8ab..939c8b2f83 100755 > --- a/t/t5515-fetch-merge-logic.sh > +++ b/t/t5515-fetch-merge-logic.sh > @@ -11,6 +11,9 @@ test_description='Merge logic in fetch' > GIT_TEST_PROTOCOL_VERSION=0 > export GIT_TEST_PROTOCOL_VERSION > > +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master > +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > + > . ./test-lib.sh > > build_script () { > > Of course that also needs: > > index fa347ed3e1..2d700a171b 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -1711,10 +1711,8 @@ test_lazy_prereq SHA1 ' > test_lazy_prereq REBASE_P ' > test -z "$GIT_TEST_SKIP_REBASE_P" > ' > -# Special-purpose prereq for transitioning to a new default branch name: > -# Some tests need more than just a mindless (case-preserving) s/master/main/g > -# replacement. The non-trivial adjustments are guarded behind this > -# prerequisite, acting kind of as a feature flag > -test_lazy_prereq PREPARE_FOR_MAIN_BRANCH ' > - test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" = main > + > +test_lazy_prereq MAIN_BRANCH_IS_MASTER ' > + test -z "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" || > + test "$GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME" = "master" > ' > > Because (but see "later" a few paragraphs later), the logic as it stands > on "master" is entirely backwards & broken. I.e. if you don't set > GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME or set it to "master" we now skip a > bunch of tests ... which only work if the value is "master". If you set > it to "main" they'll break. > > Then instead of ending up with a hardcoding of "main" we'd be able to > run the tests with a new custom branch name (even one with whitespace in > it). That coverage is plenty to test any branch name hardcoding. > > The remaining tests that would still have "master" would then just be > dealt with by the same thing we did for the too-protocol-v1-specific > tests, i.e.: > > diff --git a/t/t3502-cherry-pick-merge.sh b/t/t3502-cherry-pick-merge.sh > index 8b635a196d..354f9bd851 100755 > --- a/t/t3502-cherry-pick-merge.sh > +++ b/t/t3502-cherry-pick-merge.sh > @@ -8,6 +8,8 @@ test_description='cherry picking and reverting a merge > > ' > > +GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master > +export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > . ./test-lib.sh > > test_expect_success setup ' > > Except unlike protocol v1/v2 we're really not gaining anything in > coverage by going further, it's not the point of any of these tests to > test for the default branch name. It's a *lot* of churn, > > "Later": After writing the above I see from 704fed9ea2 ("tests: start > moving to a different default main branch name", 2020-10-23) that this > state of affairs is intentional. But doesn't discuss why the more usual > (because we've done it that way a few times before) v1/v2-esque > transition wasn't done instead. > > Doing it the other way still seems better. We're now not running our > full tests in anticipation for this series landing on "master", and > after applying this we're still not running all of them. > > Anyway, enough with discussing this detail of the test suite churn. My > main objection to this version of it is: > > After this series as it stands lands what's a rather big UI change in > git isn't discussed *anywhere* in the docs. > > I'm not saying we need some similar s/master/main/g in Documentation/ as > what's being done here in t/, but I think a bare minimum for a rather > big UI change like this is: > > 1) Let's at least talk about it in some way in git-init(1), i.e. that > it used to be "master" before version so-and-so and is now > different. With this series applied we still say: > > Documentation/git-init.txt:If not specified, fall back to the default name: `master`. > > 2) Ditto in the init.defaultBranch and things like that > > 3) After all this effort at eliminating "master" entirely in the tests > we're still shipping a sample hook that expects "master" on "git > init", and breaks now that it's "main" > > And maybe stuff like: > > 4) Have "git init" emit some new advice message saying that the default > has changed and we've init-ed a new repo with a "main" branch. > > Our primary concern should be the vast majority of users who don't > follow this topic on Twitter, don't read this mailing list, and are just > going to waste 10 minutes of their day because some script they've had > working for years using "git init" did something unexpected. > > Let's at least aim to make that 5 minutes instead by making the change > more discoverable. >
On Fri, Nov 13, 2020 at 7:00 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > On Thu, Nov 12 2020, Johannes Schindelin via GitGitGadget wrote: > After this series as it stands lands what's a rather big UI change in > git isn't discussed *anywhere* in the docs. > > I'm not saying we need some similar s/master/main/g in Documentation/ as > what's being done here in t/, but I think a bare minimum for a rather > big UI change like this is: Why not? Isn't this change being championed on behalf of users who find the word offensive? Why would it be offensive to see the word on the commands you type on the command line, but not offensive if the documentation tells you to type those commands? This does not compute. And worse; for the rest of the users that don't find the word offensive (99.9% of them?), the documentation is left in an inconsistent state, where some commands would not work as they are stated. If a word is so offensive it has to be erased from the Git lexicon, then it has to be erased *everywhere*, or at least everywhere a user might look. Cheers.
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > This is the big one. This changes the default of init.defaultBranch to main, > reflecting what many open source projects already did (which was followed by > GitHub, Azure Repos and others). I'll keep this brief as I'm still offline/vacation til next week. As other people already said, I'd prefer to see - all tests updated to work, without losing any coverage, regardless of the default for the init.defaultbranch is. Some test scripts may require setting init.defaultBranch='master' at the top in the 'setup' part (I've shown how in my response to t4013 patchset) if the body of the test relies too heavily on the primary branch to be 'master'. On the other hand, some test scripts may require setting init.defaultBranch='main' at the top, if they have been converted to work _only_ with 'main'. Both of these are unfortunate, but it is much better than losing test coverage during the test update effort. Some test scripts may not need any "this test would only work with 'master|main', so we are forcing". After your test update series so far, hopefully many may already be ready to be force to 'main' even when the Git binary may still use 'master' as the fallback default for init.defaultBranch. - a well thought-out transition plan (including user education and publicity), with the final "flip of the fallback default". and I'd strongly prefer that these two to be done separately. Since we cannot anticipate how long the latter would take with unknown amount of distraction, I'd prefer 100% of our tests keep working while the fallback default for init.defaultBranch is 'master', and they still work on the flag day when the default is changed to 'main' (or 'primary' for that matter---after all, tests that care too deeply what the primary branch name is, and have been updated to eradicate 'master' from them, would be forcing 'main', so the hardcoded fallback default in our binary should not matter). Thanks.
Junio C Hamano <gitster@pobox.com> writes: > Some test scripts may require setting init.defaultBranch='master' > at the top in the 'setup' part (I've shown how in my response to > t4013 patchset) if the body of the test relies too heavily on the > primary branch to be 'master'. Ah, I realized we have much better mechanism already in the form of GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME environment. So, my three wishes in this message now become - lose PREPARE_FOR_MAIN_BRANCH prerequisite as quickly as possible by doing the following two. - Use that mechanism to force 'main' in test scripts that now only can work with 'main', even before we change the fallback default from master to main in the production code, so that we won't lose test coverage. - The same for test scripts that are not converted yet to force use of 'master', so that we could change the fallback default from master to main in the production code even before converting these other scripts, so that we won't lose test coverage. Thanks.
Hi Junio, On Mon, 16 Nov 2020, Junio C Hamano wrote: > Junio C Hamano <gitster@pobox.com> writes: > > > Some test scripts may require setting init.defaultBranch='master' > > at the top in the 'setup' part (I've shown how in my response to > > t4013 patchset) if the body of the test relies too heavily on the > > primary branch to be 'master'. > > Ah, I realized we have much better mechanism already in the form of > GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME environment. > > So, my three wishes in this message now become > > - lose PREPARE_FOR_MAIN_BRANCH prerequisite as quickly as possible Okay, we're on the same page here. > by doing the following two. A couple of test cases already have the `PREPARE_FOR_MAIN_BRANCH` prereq (in preparation for transitioning the test suite, which is what I will settle for in v2 of this patch series). Most notably, t5526 and t9902, which I had to exclude to avoid clashing with branches that are currently in flight. So my goal is to transition the test suite as quickly as possible, by first converting the majority in v2 of this patch series, and then handling the rest of the test scripts individually, on top of the in-flight topics. > - Use that mechanism to force 'main' in test scripts that now only > can work with 'main', even before we change the fallback default > from master to main in the production code, so that we won't lose > test coverage. That's precisely what I do, incrementally, by adjusting that `case` statement in `t/test-lib.sh` whenever a range of test scripts has been transitioned. In patch 2/28, it looks like this: case "$TEST_NUMBER" in [01]*) GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME ;; esac By patch 26/28, it looks like this: case "$TEST_NUMBER" in 3404|4013|5310|5526|6300|7064|7817|9902) # Avoid conflicts with patch series that are cooking at the same # time # as the patch series changing the default of # `init.defaultBranch`. GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME ;; *) GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME ;; esac > - The same for test scripts that are not converted yet to force use > of 'master', so that we could change the fallback default from > master to main in the production code even before converting > these other scripts, so that we won't lose test coverage. Okay, I could have done it that way by starting with case "$TEST_NUMBER" in [01]*) GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME ;; *) GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME ;; esac But that would result in a funny-looking intermediate state with a `master` arm, then `main`, then again `master`. Besides, it would be more complicated because t/t5411-proc-receive-hook.sh and t/t5515-fetch-merge-logic.sh already ask for `main`, but by setting it before sourcing `test-lib.sh`, and therefore we would have to special-case them in that `case` from the get-go. Therefore, in the interest of making this patch series _slightly_ easier to review (you still have to look at the _bottom_ of most of those patches to catch the crucial change to `t/test-lib.sh`), I would like to keep the patch series in the current shape. Will send v2 in a moment. Thanks, Dscho
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > Hi Junio, > > On Mon, 16 Nov 2020, Junio C Hamano wrote: > >> Junio C Hamano <gitster@pobox.com> writes: >> >> > Some test scripts may require setting init.defaultBranch='master' >> > at the top in the 'setup' part (I've shown how in my response to >> > t4013 patchset) if the body of the test relies too heavily on the >> > primary branch to be 'master'. >> >> Ah, I realized we have much better mechanism already in the form of >> GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME environment. >> >> So, my three wishes in this message now become >> >> - lose PREPARE_FOR_MAIN_BRANCH prerequisite as quickly as possible > > Okay, we're on the same page here. Yeah, you may have noticed after reading my recent messages to this topic, my initial reaction was mostly triggered by "eh, are we losing test coverage too much?" before re-reading what the patches (both what we have already merged and these 28 final stretch patches) actually do, and realizing that they aim at preparing us so that we can flip the fallback default any time we like. So we are very much on the same page. > That's precisely what I do, incrementally, by adjusting that `case` > statement in `t/test-lib.sh` whenever a range of test scripts has been > transitioned. In patch 2/28, it looks like this: > > case "$TEST_NUMBER" in > [01]*) > GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main > export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > ;; > esac > > By patch 26/28, it looks like this: > > case "$TEST_NUMBER" in > 3404|4013|5310|5526|6300|7064|7817|9902) > # Avoid conflicts with patch series that are cooking at the same > # time > # as the patch series changing the default of > # `init.defaultBranch`. > GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master > export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > ;; > *) > GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main > export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > ;; > esac I actually am not a big fan of the centralized table of "these want to run with main". My ideal would be to have an explicit assignment of either master or main for tests that absolutely require the default to be one of these names at the top of these script, and any test scripts that do not care what the initial branch is called (perhaps because they begin by switching to a branch whose name is picked by them immediately after they start and use that name throughout) won't have GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME in them. I think we can live with a centralized "case", but I have trouble with seeing only two arms in the above case statement, whether which one gets the asterisk. There may be ones that need to force 'master', there may be ones that need to force 'main', but hopefully many do not even have to force and can work with either. And seeing "everything else works only with 'main'" is a bit disappointing. But if you must have a case with only two arms, i.e. "these are exceptions" and "everything else", I think the above (i.e. we refrain from touching these and force them to 'master' as exceptions, but everything else is forced to 'main') is better than having them the other way around. Thanks.
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > This is the big one. This changes the default of init.defaultBranch to main, > reflecting what many open source projects already did (which was followed by > GitHub, Azure Repos and others). Can we please not simply replace one hard coded branch name with another? Having a blessed name for the initially created branch continues to imply the branch has special significance. As the initially created branch does not have special significance can we please do something that does not imply that? Instead of having a fixed name across all repos for the initially created branch can we instead use the directory name of the repo for the branch name? Advantages: - The branch name that is somewhat meaningful to the creator of the git repo. I have at least two repos where I wound up doing this by hand. So at least for me it is something I am doing anyway. - Tools can not hard code the name of an initially created branch and expect it to work. This moves us farther from the realm of people assuming incorrectly that there is something special about the branch created by default. - As the name is somewhat meaningful. This change to the initial branch name becomes something that can be argued is a technical improvement rather than a simple political statement. At least for my usage main is a pretty huge misnomer as I barely use the branch with the master. Renaming my unused branch main implies that I am using the tool wrong. I don't look in on the git list very often so perhaps I am missing a conversation where all of the details were thought through. If so please point me at that conversation. Otherwise can we please use this opportunity to come up with something that is actually better than naming the default branch main, rather than just something just as awkward whose only advantage is that people don't think it is politically incorrect this week. Eric
On Tue, Nov 17, 2020 at 3:10 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > This is the big one. This changes the default of init.defaultBranch to main, > > reflecting what many open source projects already did (which was followed by > > GitHub, Azure Repos and others). > > Can we please not simply replace one hard coded branch name with > another? I thought precisely the same thing. This should be easy to do if we make "origin" be a pseudo ref that points to "origin/HEAD" (and we could introduce "origin/@"). That way there will never be a need to type "origin/master", or having it as an upstream, you can simply set "origin" as the upstream tracking "branch". > I don't look in on the git list very often so perhaps I am missing a > conversation where all of the details were thought through. If so > please point me at that conversation. Otherwise can we please use this > opportunity to come up with something that is actually better than > naming the default branch main, rather than just something just as > awkward whose only advantage is that people don't think it is > politically incorrect this week. This is the thread: https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/ Unfortunately in my opinion the most important topics--like your suggestion--were not even mentioned. Everyone focused on the wrong thing (e.g. what would be a better name for "master"). Cheers.
ebiederm@xmission.com (Eric W. Biederman) writes: > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> This is the big one. This changes the default of init.defaultBranch to main, >> reflecting what many open source projects already did (which was followed by >> GitHub, Azure Repos and others). > > Can we please not simply replace one hard coded branch name with > another? > > Having a blessed name for the initially created branch continues to > imply the branch has special significance. As the initially created > branch does not have special significance can we please do > something that does not imply that? I personally am fond of this line of "let's not treat one single thing any special among others" approach, but I think the way people use the initially created branch tends to make it special at the end of the day. While the project is still in its infancy, you may use that as the only branch until the tree of the project starts to take its shape, perhaps with subdirectories dedicated to sources, documentation, and overall build procedure, etc. Then you may start to fork different branches to work on topics that last more than one commit's worth of time and then it is likely you'd use the initially created branch as the integration branch, until you start to need the second and third integration branches. Like it or not, the primary integration branch would inevitably end up being something more special than others, and it is likely that using the initially created branch for that purpose would be the most convenient. There however may exist two or more equally significant branches, not just one special one, though, but it is reasonable to have at least one special one. I think using some word that is derived from $(basename $(pwd)) as the name of the initial branch may be a more reasonable choice than using any single word that tries to fit everybody (which will *not* exist). When a user says "git init tinyshell" to start a project to create a tiny shell, "tinyshell" may be one reasonable choice to refer to its primary integration branch. Everything that goes into it will become part of the tinyshell project. But if there is a woke-safe word that can refer to "the primary integration branch", calling the initially created branch with that word by default is also equally a reasonable approach. I personally do not like the word 'main' used as such, but the rest of the world seems to be moving in that direction, so being consistent with them would help users who want to do mkdir project && cd project git init ... some workflow specific 'git config' here ... git remote add $URL origin git pull origin and have it be an enhanced equivalent to git clone $URL project The latter will try to find the name used for the primary branch on the other side and use the same name; the former would not work that way, but if "git init" uses a fallback default that is most common, it would hurt less. In any case, the updated version of these 28 patches no longer has the final "switch the fallback default to 'main'" step, and the good thing is that the other 27 patches will help us moving in any direction. If we choose to dynamically derive the initial branch name, these steps make sure that such a change won't break our testsuite. > Instead of having a fixed name across all repos for the initially > created branch can we instead use the directory name of the repo for the > branch name? > > Advantages: > > - The branch name that is somewhat meaningful to the creator of the git > repo. > > I have at least two repos where I wound up doing this by hand. So at > least for me it is something I am doing anyway. Direct "other side" of the coin is that the name meaningful to the creator may be different from project to project, so those who want to try peeking projects that are so far unknown to them will have to guess what that meaningful thing is. When visiting a random github repository and presented by 47 different branches, it would be more helpful for such a visitor to have a reliable "this is likely to be the primary integration branch" cue. Not having a convention is worse than having a convention some folks may find suboptimal from usability's point of view. > - Tools can not hard code the name of an initially created branch and > expect it to work. Cannot? Is this a dogmatic declaration? If tools that are meant to work with variety of projects with a single "special" branch and do things relative to that special branch (e.g. perhaps the special branch is the primary integration branch, and the tool may list commits that are not yet in that branch), a toolsmith has multiple choices. The tool can take the name of the "special" branch from the end-user to be most flexible, of the tool can hardcode the most commonly used name for the "special" branch to be out-of-the-box useful for majority of projects. Most sensible folks may do the former, but I do not think the latter is a bad choice. And even those who do the former has to fall back to some hardcoded value when the user didn't give the name of the "special" branch, because end-users are greedy and will demand such a "convenience" feature, saying "in most repositories, this name is commonly used for the 'special' branch---why force us to type the same thing?"
On Tue, Nov 17, 2020 at 4:57 PM Junio C Hamano <gitster@pobox.com> wrote: > ebiederm@xmission.com (Eric W. Biederman) writes: > > - The branch name that is somewhat meaningful to the creator of the git > > repo. > > > > I have at least two repos where I wound up doing this by hand. So at > > least for me it is something I am doing anyway. > > Direct "other side" of the coin is that the name meaningful to the > creator may be different from project to project, so those who want > to try peeking projects that are so far unknown to them will have to > guess what that meaningful thing is. When visiting a random github > repository and presented by 47 different branches, it would be more > helpful for such a visitor to have a reliable "this is likely to be > the primary integration branch" cue. Not having a convention is > worse than having a convention some folks may find suboptimal from > usability's point of view. But a convention is just that: a convention. If we already know "origin/HEAD" is very likely pointing to the integration branch, then why do we need to know what that branch is called in that particular project? Just refer to that branch as "origin/@", or just "origin". That would work for projects that follow the convention, and those who don't. Why does the tool need to care? Cheers.
On Tue, Nov 17, 2020 at 04:47:56PM -0600, Felipe Contreras wrote: > On Tue, Nov 17, 2020 at 3:10 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > > > "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > > > > > This is the big one. This changes the default of init.defaultBranch to main, > > > reflecting what many open source projects already did (which was followed by > > > GitHub, Azure Repos and others). > > > > Can we please not simply replace one hard coded branch name with > > another? > > I thought precisely the same thing. > > This should be easy to do if we make "origin" be a pseudo ref that > points to "origin/HEAD" (and we could introduce "origin/@"). Didn't we already do this long ago? refs/remotes/%s/HEAD is special in the dwim_ref() lookup: $ git rev-parse --symbolic-full-name origin refs/remotes/origin/master Or did you have something else in mind? I think I have occasionally hit spots where saying "origin" instead of "origin/master" does not work. I can't think of any offhand now, though (I thought perhaps "git checkout -b foo origin" or "git branch --set-upstream-to=origin", but both seem to work). > > I don't look in on the git list very often so perhaps I am missing a > > conversation where all of the details were thought through. If so > > please point me at that conversation. Otherwise can we please use this > > opportunity to come up with something that is actually better than > > naming the default branch main, rather than just something just as > > awkward whose only advantage is that people don't think it is > > politically incorrect this week. > > This is the thread: > > https://lore.kernel.org/git/CAOAHyQwyXC1Z3v7BZAC+Bq6JBaM7FvBenA-1fcqeDV==apdWDg@mail.gmail.com/ > > Unfortunately in my opinion the most important topics--like your > suggestion--were not even mentioned. Everyone focused on the wrong > thing (e.g. what would be a better name for "master"). There is another thread from the same time that contains quite a lot of discussion on logistics. This subthread in particular raises the notion of "let's try to minimize needing a special branch-name at all": https://lore.kernel.org/git/875zbrcpgh.fsf@evledraar.gmail.com/ And indeed, it led to some other bug-fixes in improvements in the time since then: - submodule--helper was fixed to use HEAD from the remote as its fallback rather than a hard-coded "master" - fast-export --anonymize no longer treats "master" as special, but instead grew a flexible system for leaving some bits intact - fmt-merge-msg gained new options for configuring when it will print "into <branch>" So really all that is left is deciding what to do when: git init git commit -m foo is run. Obviously we added a config variable here, but we still fall back to a hard-coded name. One suggestion was to not use any name, and either require "git checkout -b some-branch" first, or commit onto a detached HEAD: https://lore.kernel.org/git/B4814F42-7AF8-4D80-93D4-FAF752C72F21@me.com/ The simplicity has some appeal to me, but it's even less backwards-compatible than falling back to a new different name. I think Eric's suggestion of using the directory name as a default was not previously mentioned. I'm not sure I would like that myself (I find value in having a consistent "this is the main branch" name across different repositories, at least for my workflows). And it creates all of the same "every tutorial is now out of date" issues. But it is neutral. I wouldn't be opposed to seeing it as a configurable option. -Peff
Jeff King <peff@peff.net> writes: > I think Eric's suggestion of using the directory name as a default was > not previously mentioned. I'm not sure I would like that myself (I find > value in having a consistent "this is the main branch" name across > different repositories, at least for my workflows). And it creates all > of the same "every tutorial is now out of date" issues. But it is > neutral. I wouldn't be opposed to seeing it as a configurable option. I actually recall hearing it from Eric, not on this list, directly back in the timeframe of these previous dicsussions. I somehow thought I relayed it to the community, perhaps #git-devel on freenode, but apparently not to this list. Yes, init.defaultBranchName is defined to be a string, so it is a bit tricky to introduce special values that mean "no, not a hardcoded value but derive dynamically based on X". Perhaps use a prefix that is not allowed in a refname, perhaps like this update to the function that uses the value read from the init.defaultBranch configuration variable. refs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git c/refs.c w/refs.c index 392f0bbf68..3fbc697cd8 100644 --- c/refs.c +++ w/refs.c @@ -576,6 +576,12 @@ char *repo_default_branch_name(struct repository *r) if (!ret) ret = xstrdup("master"); + else if (!strcmp(ret, ":dirname")) + ret = ... do the $(basename $(cwd)) thing ...; + else if (!strcmp(ret, ":some other magic")) + ret = ... do some other magic thing ...; + else if (ret[0] == ':') + die(_("%s - unrecognised magic", ret); full_ref = xstrfmt("refs/heads/%s", ret); if (check_refname_format(full_ref, 0))
Felipe Contreras <felipe.contreras@gmail.com> writes: > If we already know "origin/HEAD" is very likely pointing to the > integration branch, then why do we need to know what that branch is > called in that particular project? > > Just refer to that branch as "origin/@", or just "origin". "git merge origin" turns into "git merge origin/HEAD", I think, and we had it for quite some time. But repositories may not even have any origin to begin with. The one I am typing this message in certainly does not. And we need some fallback default when origin/HEAD cannot be used anyway, and that is where the convention comes in again. You cannot escape from it, and ... > That would work for projects that follow the convention, and those who > don't. Why does the tool need to care? ... certainly it would not work for me.
On Tue, Nov 17, 2020 at 5:33 PM Jeff King <peff@peff.net> wrote: > On Tue, Nov 17, 2020 at 04:47:56PM -0600, Felipe Contreras wrote: > > This should be easy to do if we make "origin" be a pseudo ref that > > points to "origin/HEAD" (and we could introduce "origin/@"). > > Didn't we already do this long ago? refs/remotes/%s/HEAD is special in > the dwim_ref() lookup: > > $ git rev-parse --symbolic-full-name origin > refs/remotes/origin/master Hmmm. For some reason none of my remotes do have a HEAD. If I do "git remote add", and then fetch, the HEAD doesn't seem to be present.
On Tue, Nov 17, 2020 at 6:10 PM Junio C Hamano <gitster@pobox.com> wrote: > > Felipe Contreras <felipe.contreras@gmail.com> writes: > > > If we already know "origin/HEAD" is very likely pointing to the > > integration branch, then why do we need to know what that branch is > > called in that particular project? > > > > Just refer to that branch as "origin/@", or just "origin". > > "git merge origin" turns into "git merge origin/HEAD", I think, and > we had it for quite some time. > > But repositories may not even have any origin to begin with. The > one I am typing this message in certainly does not. And we need > some fallback default when origin/HEAD cannot be used anyway, and > that is where the convention comes in again. You cannot escape from > it, and ... I did not say the convention can be escaped, I said the convention can be minimized. Since apparently there's already support for "origin/HEAD", a lot of documentation can avoid the term "origin/master", and simply use "origin". However, we need to make sure users have a properly set up "origin/HEAD", and at least in my case none of my remotes have set it up. Looking at the code, it seems: git clone URL test Is different than: git init test git remote add origin URL git fetch origin git checkout -b $favorite origin In the latter there is no origin/HEAD, and I don't see why that should be the case. Cheers.
On Tue, Nov 17, 2020 at 06:18:03PM -0600, Felipe Contreras wrote: > On Tue, Nov 17, 2020 at 5:33 PM Jeff King <peff@peff.net> wrote: > > On Tue, Nov 17, 2020 at 04:47:56PM -0600, Felipe Contreras wrote: > > > > This should be easy to do if we make "origin" be a pseudo ref that > > > points to "origin/HEAD" (and we could introduce "origin/@"). > > > > Didn't we already do this long ago? refs/remotes/%s/HEAD is special in > > the dwim_ref() lookup: > > > > $ git rev-parse --symbolic-full-name origin > > refs/remotes/origin/master > > Hmmm. For some reason none of my remotes do have a HEAD. > > If I do "git remote add", and then fetch, the HEAD doesn't seem to be present. Yes, I have run into that, and it's definitely annoying. The refs/remotes/<remote>/HEAD symref is created by clone, but is not updated by "fetch". That's intentional, because it's supposed to represent a local choice (that is merely seeded by the remote side). But it seems like adding it if it's missing might be reasonable. I'm not sure if "git remote add" should be doing it (it already can do it with "git remote set-head -a", but that is not the default when adding a new remote, which otherwise does not contact the network at all). Or if "git fetch" should be doing it. Certainly having "fetch --update-remote-head" would be fine, but that doesn't really solve the problem (which is that people don't realize they need to specify it). There was some related discussion in: https://lore.kernel.org/git/CAEXP2g8-reK+u2FaO=mMP-nsvuDDWGpwV_tyKG5L5XpU=1LQeg@mail.gmail.com/ but I don't think any patches came out of that. -Peff
On Tue, Nov 17, 2020 at 04:07:28PM -0800, Junio C Hamano wrote: > Jeff King <peff@peff.net> writes: > > > I think Eric's suggestion of using the directory name as a default was > > not previously mentioned. I'm not sure I would like that myself (I find > > value in having a consistent "this is the main branch" name across > > different repositories, at least for my workflows). And it creates all > > of the same "every tutorial is now out of date" issues. But it is > > neutral. I wouldn't be opposed to seeing it as a configurable option. > > I actually recall hearing it from Eric, not on this list, directly > back in the timeframe of these previous dicsussions. I somehow > thought I relayed it to the community, perhaps #git-devel on > freenode, but apparently not to this list. Could be. I don't keep up with the irc logs. > Yes, init.defaultBranchName is defined to be a string, so it is a > bit tricky to introduce special values that mean "no, not a > hardcoded value but derive dynamically based on X". Perhaps use a > prefix that is not allowed in a refname, perhaps like this update to > the function that uses the value read from the init.defaultBranch > configuration variable. Yeah, I restrained myself from getting too far into thinking about syntax, but I agree we'd want something like that. It might also be OK to use something that's extremely unlikely to be a default branch name (like BASENAME), but the ":" syntax you have here isn't bad. Yet another option is a separate variable (that if set means we do not look at init.defaultBranch at all). IMHO, though, all of this is orthogonal to question of what the default is. Unless we are thinking the basename thing would work as a default, but I don't think that resolves any of the backwards-compatibility concerns. -Peff
On Tue, Nov 17, 2020 at 7:22 PM Jeff King <peff@peff.net> wrote: > > On Tue, Nov 17, 2020 at 06:18:03PM -0600, Felipe Contreras wrote: > > > On Tue, Nov 17, 2020 at 5:33 PM Jeff King <peff@peff.net> wrote: > > > On Tue, Nov 17, 2020 at 04:47:56PM -0600, Felipe Contreras wrote: > > > > > > This should be easy to do if we make "origin" be a pseudo ref that > > > > points to "origin/HEAD" (and we could introduce "origin/@"). > > > > > > Didn't we already do this long ago? refs/remotes/%s/HEAD is special in > > > the dwim_ref() lookup: > > > > > > $ git rev-parse --symbolic-full-name origin > > > refs/remotes/origin/master > > > > Hmmm. For some reason none of my remotes do have a HEAD. > > > > If I do "git remote add", and then fetch, the HEAD doesn't seem to be present. > > Yes, I have run into that, and it's definitely annoying. The > refs/remotes/<remote>/HEAD symref is created by clone, but is not > updated by "fetch". That's intentional, because it's supposed to > represent a local choice (that is merely seeded by the remote side). But > it seems like adding it if it's missing might be reasonable. The equivalent of this choice is in "git remote add -m": With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` is set up to point at remote's `<master>` branch. See also the set-head command. This is of course inconsistent. Is it the "head", or is it the "master"? Presumably if we want to avoid the term "master", then this option needs to be renamed. In my opinion unless this option has been explicitly set, "origin/HEAD" should keep track of whatever remote head is set. If somebody updates its remote HEAD from "master" to "main", then origin/HEAD should be updated accordingly. Granted, this may be some overhead in the 99.999% of the cases where the remote HEAD is the same, so it may not be worth even thinking about it. But at least the first fetch after "git remote add" should fetch it, in my opinion (unless it's manually configured already). I'm not sure if origin/HEAD can contain some placeholder so that "git fetch" knows what to do. Cheers.
On Tue, Nov 17, 2020 at 07:45:21PM -0600, Felipe Contreras wrote: > > Yes, I have run into that, and it's definitely annoying. The > > refs/remotes/<remote>/HEAD symref is created by clone, but is not > > updated by "fetch". That's intentional, because it's supposed to > > represent a local choice (that is merely seeded by the remote side). But > > it seems like adding it if it's missing might be reasonable. > > The equivalent of this choice is in "git remote add -m": > > With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` > is set up to point at remote's `<master>` branch. See also the > set-head command. Wow, I'm not sure how that option escaped my notice for all these years. Of course it would be much more useful if it pulled the value from the remote HEAD (but again, unless we use "-f" we are not contacting the remote at all). > This is of course inconsistent. Is it the "head", or is it the "master"? > > Presumably if we want to avoid the term "master", then this option > needs to be renamed. Agreed that the naming is bad. > In my opinion unless this option has been explicitly set, > "origin/HEAD" should keep track of whatever remote head is set. > > If somebody updates its remote HEAD from "master" to "main", then > origin/HEAD should be updated accordingly. Granted, this may be some > overhead in the 99.999% of the cases where the remote HEAD is the > same, so it may not be worth even thinking about it. > > But at least the first fetch after "git remote add" should fetch it, > in my opinion (unless it's manually configured already). I'm not sure > if origin/HEAD can contain some placeholder so that "git fetch" knows > what to do. If it's simply not present (which is the case now after "git remote add"), then it might be reasonable for "git fetch" to use that as the hint to fill it in. That would also make "git remote add -f" just work, I believe. It does mean that you can _change_ the value of origin/HEAD, but you wouldn't be allowed to delete it without fetch trying to re-create it. I suspect this is quite rare, but we might want an escape hatch config. E.g., remote.origin.updateHEAD that can be set to one of: - never; do not touch it - create-if-missing; as discussed here - always; update it on every fetch And then it is just a question of what the default is. Currently it is "never". I suspect most people would be happy with "always", but it does break some existing flows. But perhaps "create-if-missing" is a good medium. -Peff
Hi, Jeff King wrote: > On Tue, Nov 17, 2020 at 07:45:21PM -0600, Felipe Contreras wrote: >> Jeff King wrote: >>> Yes, I have run into that, and it's definitely annoying. The >>> refs/remotes/<remote>/HEAD symref is created by clone, but is not >>> updated by "fetch". That's intentional, because it's supposed to >>> represent a local choice (that is merely seeded by the remote side). But >>> it seems like adding it if it's missing might be reasonable. >> >> The equivalent of this choice is in "git remote add -m": >> >> With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` >> is set up to point at remote's `<master>` branch. See also the >> set-head command. > > Wow, I'm not sure how that option escaped my notice for all these years. > Of course it would be much more useful if it pulled the value from the > remote HEAD (but again, unless we use "-f" we are not contacting the > remote at all). When would I want this implicit "set-head -a" and *not* want "-f"? [...] >> Presumably if we want to avoid the term "master", then this option >> needs to be renamed. > > Agreed that the naming is bad. That said, single-letter options often have bad names. (That's part of why these days I try to push back against single-letter options unless a flag is frequently used.) For consistency with "git clone -b", I suppose one might expect it to be "git remote add -b". Or even better, to retire the option and have people run "git remote set-head" separately. [...] > E.g., remote.origin.updateHEAD that can be set to one of: > > - never; do not touch it > > - create-if-missing; as discussed here > > - always; update it on every fetch > > And then it is just a question of what the default is. Currently it is > "never". I suspect most people would be happy with "always", but it does > break some existing flows. But perhaps "create-if-missing" is a good > medium. Thanks for bringing this up --- this is something I had been interested in as well but hadn't gotten around to contacting the list about it. The default value for a config setting like this has two purposes: - it makes the config setting for affected people who have not discovered it - it provides a sensible, predictable standard behavior Those two goals are often in tension, as they were for example when setting the default for push.default. If I consider them separately: - to make as smooth a transition as possible for people who were relying on "git remote set-head", a good behavior would be to *fail the fetch* when the remote HEAD changes. That would force the user to make a choice between "never" and "always". - one way to relax that without hurting that goal too much would be to fail the fetch when the remote HEAD changes from something other than "master" or "main". That way, the common case (moving from a default to a project-appropriate setting) would work without friction, and in other cases the user could make a choice between "never" and "always". - all that said, the default that I prefer is simply "always". Like Felipe hinted, this is a simple, intuitive behavior that most people would expect. As a transition plan, I can imagine going from one of those first two to the third after some appropriate period of time has passed. What do you think? Thanks, Jonathan
Jeff King wrote: > IMHO, though, all of this is orthogonal to question of what the default > is. Unless we are thinking the basename thing would work as a default, > but I don't think that resolves any of the backwards-compatibility > concerns. If we think it would make sense as the *eventual* default, we could use [init] defaultBranchName = (i.e., an empty string) to request it early.
Eric W. Biederman wrote: > Instead of having a fixed name across all repos for the initially > created branch can we instead use the directory name of the repo for the > branch name? > > Advantages: > > - The branch name that is somewhat meaningful to the creator of the git > repo. > > I have at least two repos where I wound up doing this by hand. So at > least for me it is something I am doing anyway. Example: this would make the main branch in a new git.git repository default to "git". However, we would be free to switch to some other workflow-specific name like "stable". > - Tools can not hard code the name of an initially created branch and > expect it to work. > > This moves us farther from the realm of people assuming incorrectly > that there is something special about the branch created by default. What's especially nice about this is that a repository's local basename and the URL at which it gets published do not always coincide. So scripts designed to be robust would be more likely to use commands like "git branch --show-current" instead of trying to guess using the new rule. That said, if I put myself in the shoes of such a script author for a moment, I'm likely to be irritated. What started as a static string now becomes something dynamic. If I put myself in the shoes of someone who has *inherited* a script (a testsuite, maybe), I'm likely to be even more irritated. For testsuites, one can buy time by setting init.defaultBranch, but not for other scripts. Are there things we can do to make a script author's life easier? Today if I want to look up a remote repository's default branch, the best I can do is git ls-remote --symref origin HEAD The output is not as easy to parse as I'd like: it's split between two lines and has multiple fields on each line. Worse, it is slow, since it scans all refs instead of just the ref I wanted. Even worse, if another ref in the remote repository ends with /HEAD (e.g., refs/remotes/someremote/HEAD), it prints that, too. If I could do something like git ls-remote --format='%(symref)' --exact-match origin HEAD (using for-each-ref style formats, and allowing exact matching) then that would be helpful. In general, this aspect of a less deterministic first branchname is appealing; it would result in improving the quality of the ecosystem of tools built around Git. This is what I like most about this proposal. [...] > At least for my usage main is a pretty huge misnomer as I barely use the > branch with the master. Renaming my unused branch main implies that I > am using the tool wrong. Is that because "master" is inherited from your upstream? Which branch would you want people to check out by default when they clone from your repo? For what it's worth: - I find this proposal really tempting, and have liked it since the moment gitster brought it up on #git-devel. The main reason I haven't brought it up since then is that I didn't have a patch implementing it. :) - That said, a fixed string as default would be fine with me, too. Thanks, Jonathan
Jonathan Nieder <jrnieder@gmail.com> writes: >> IMHO, though, all of this is orthogonal to question of what the default >> is. Unless we are thinking the basename thing would work as a default, >> but I don't think that resolves any of the backwards-compatibility >> concerns. > > If we think it would make sense as the *eventual* default, we could use > > [init] > defaultBranchName = > > (i.e., an empty string) to request it early. I am not opposed to the idea to invent a notation that asks for the basename behaviour, but I do not think it is a good idea to use "an empty string" for that. I'd rather see us use some consistent naming convention to denote any new "non-constant string" thing. What Peff suggested is a more viable possibility, for example. When "[init] defaultBranchAlgorithm = <name>" is set, the fixed string "init.defaultBranch" is ignored and the algorithm specified with its name is invoked to come up with a name dynamically. We may start with something like 'dirname' as the only supported algorithm but that way we would avoid painting ourselves in a corner out of which we cannot escape (e.g. we may come up with a better way than the basename thing, and we would not have a good way to give it a name that is easy to use if we wasted "an empty string" for the basename thing).
Jonathan Nieder <jrnieder@gmail.com> writes: > That said, if I put myself in the shoes of such a script author for a > moment, I'm likely to be irritated. What started as a static string > now becomes something dynamic. If I put myself in the shoes of > someone who has *inherited* a script (a testsuite, maybe), I'm likely > to be even more irritated. It is conceptually really nice to say that we do not use words like 'master' and 'main' that are 'meaningless' in the context of thinking about the workflow used for the project and instead pick the word the end user chose to call (some aspect of) the project (i.e. the name of the directory to host its working tree). It however is much harder to defend the design in real life because it can lead to the irritations you mention. > Are there things we can do to make a script author's life easier? It largely depends on what "specialness" of 'master' branch the script is interested in, isn't it? > Today if I want to look up a remote repository's default branch, > the best I can do is > > git ls-remote --symref origin HEAD > > The output is not as easy to parse as I'd like:... In a sense, these follower repositories are easier to work with. You have refs/remotes/origin/HEAD that indicates what the owner of the local repository considers of the most significance; it is initialized to match what the remote had pointed with its HEAD when the repository was cloned, but the local user can repoint it when the local interest diverge from that of the remote's. And you do not need to talk over the network with ls-remote to find that out (actually asking ls-remote may actively be wrong after the local user repointed it); you only need to ask 'git symbolic-ref' which is totally local.
On Tue, Nov 17, 2020 at 8:06 PM Jeff King <peff@peff.net> wrote: > On Tue, Nov 17, 2020 at 07:45:21PM -0600, Felipe Contreras wrote: > > The equivalent of this choice is in "git remote add -m": > > > > With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` > > is set up to point at remote's `<master>` branch. See also the > > set-head command. > > Wow, I'm not sure how that option escaped my notice for all these years. > Of course it would be much more useful if it pulled the value from the > remote HEAD (but again, unless we use "-f" we are not contacting the > remote at all). Seems to come basically untouched since 2007: b6f5da1e0f (Teach git-remote add to fetch and track) > And then it is just a question of what the default is. Currently it is > "never". I suspect most people would be happy with "always", but it does > break some existing flows. But perhaps "create-if-missing" is a good > medium. Agreed. Personally I don't see any problem with "create-if-missing", but creating a configuration and defaulting to "never" should be a good first step. I'm sending an RFC patch to that effect. Cheers.
On Tue, Nov 17, 2020 at 8:39 PM Jonathan Nieder <jrnieder@gmail.com> wrote: > Jeff King wrote: > > On Tue, Nov 17, 2020 at 07:45:21PM -0600, Felipe Contreras wrote: > >> Jeff King wrote: > > >>> Yes, I have run into that, and it's definitely annoying. The > >>> refs/remotes/<remote>/HEAD symref is created by clone, but is not > >>> updated by "fetch". That's intentional, because it's supposed to > >>> represent a local choice (that is merely seeded by the remote side). But > >>> it seems like adding it if it's missing might be reasonable. > >> > >> The equivalent of this choice is in "git remote add -m": > >> > >> With `-m <master>` option, a symbolic-ref `refs/remotes/<name>/HEAD` > >> is set up to point at remote's `<master>` branch. See also the > >> set-head command. > > > > Wow, I'm not sure how that option escaped my notice for all these years. > > Of course it would be much more useful if it pulled the value from the > > remote HEAD (but again, unless we use "-f" we are not contacting the > > remote at all). > > When would I want this implicit "set-head -a" and *not* want "-f"? This is what I often do: git remote add origin $url git fetch origin That should work (update origin/HEAD), and it currently doesn't. > > E.g., remote.origin.updateHEAD that can be set to one of: > > > > - never; do not touch it > > > > - create-if-missing; as discussed here > > > > - always; update it on every fetch > > > > And then it is just a question of what the default is. Currently it is > > "never". I suspect most people would be happy with "always", but it does > > break some existing flows. But perhaps "create-if-missing" is a good > > medium. > > Thanks for bringing this up --- this is something I had been > interested in as well but hadn't gotten around to contacting the list > about it. > > The default value for a config setting like this has two purposes: > > - it makes the config setting for affected people who have not > discovered it > > - it provides a sensible, predictable standard behavior > > Those two goals are often in tension, as they were for example when > setting the default for push.default. > > If I consider them separately: > > - to make as smooth a transition as possible for people who were > relying on "git remote set-head", a good behavior would be to > *fail the fetch* when the remote HEAD changes. That would force > the user to make a choice between "never" and "always". We don't need to fail the fetch, we can print a warning so the user can decide what to do next, including ignoring the warning. Moreover, since projects rarely change the HEAD, we might want to print the warning always, until the user sets the configuration. > - one way to relax that without hurting that goal too much would be to > fail the fetch when the remote HEAD changes from something other > than "master" or "main". That way, the common case (moving from a > default to a project-appropriate setting) would work without > friction, and in other cases the user could make a choice between > "never" and "always". This thread started in an attempt to move away from hard-coded values. This doesn't help in my opinion. > - all that said, the default that I prefer is simply "always". Like > Felipe hinted, this is a simple, intuitive behavior that most people > would expect. > > As a transition plan, I can imagine going from one of those first two > to the third after some appropriate period of time has passed. I think the default should be "missing", after a warning period. And perhaps change it to "always" in the next major version, but that basically gets rid of the manual "origin/HEAD" that seems to have been there since forever (at least 2007). I personally don't see any point in manually setting the HEAD (I have never done so), but that's just me, others might. Cheers.
Hi Junio, On Tue, 17 Nov 2020, Junio C Hamano wrote: > Jonathan Nieder <jrnieder@gmail.com> writes: > > >> IMHO, though, all of this is orthogonal to question of what the default > >> is. Unless we are thinking the basename thing would work as a default, > >> but I don't think that resolves any of the backwards-compatibility > >> concerns. > > > > If we think it would make sense as the *eventual* default, we could use > > > > [init] > > defaultBranchName = > > > > (i.e., an empty string) to request it early. > > I am not opposed to the idea to invent a notation that asks for the > basename behaviour, but I do not think it is a good idea to use "an > empty string" for that. I'd rather see us use some consistent > naming convention to denote any new "non-constant string" thing. At least in the tests, using the empty string for `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME` is equivalent for not setting it at all, i.e. to trigger the fall-back. So yes, I totally agree that triggering an interactive prompt by the empty value is not really a good idea (nor a particularly intuitive behavior). With your idea to special-case any value starting with a colon, `:ask:` seems like a saner approach. Having said that, I would still favor the fall-back `main` over this idea: it is a much smaller (and less annoying) change of behavior to use a less loaded name than to change from a previously non-interactive to a now-interactive operation. As to using the base name by default: I don't think that is a good idea at all. Not only doesn't it work when you run `git init` in the root directory (which some people do, and that's totally okay with me), it also does not work with any base name that isn't a valid ref name. Try this at home: $ git check-ref-format --branch "My Documents" fatal: 'My Documents' is not a valid branch name So while it is a cute idea, in general it will simply fail, and is therefore worse than any alternative that does _not_ fail in general. > What Peff suggested is a more viable possibility, for example. When > "[init] defaultBranchAlgorithm = <name>" is set, the fixed string > "init.defaultBranch" is ignored and the algorithm specified with its > name is invoked to come up with a name dynamically. We may start > with something like 'dirname' as the only supported algorithm but > that way we would avoid painting ourselves in a corner out of which > we cannot escape (e.g. we may come up with a better way than the > basename thing, and we would not have a good way to give it a name > that is easy to use if we wasted "an empty string" for the basename > thing). Indeed. In the spirit of minimizing disruption (as promised in https://sfconservancy.org/news/2020/jun/23/gitbranchname/), I would like to stay away from changing the default behavior _that_ much. My current plan is to implement a warning in `git init` (much like the `pull.rebase` one, which I thought would raise outcries of frustration, but to my surprise this did not happen, and `git init` is _a lot_ less common than `git pull`). This needs to be done with care, obviously. I haven't looked yet, but I think there is a chance that `git clone` would implicitly look at `init.defaultBranch` only to override it later by the name of the remote primary branch. In that case, we obviously do not want to warn the user because the `init.defaultBranch` value is not actually used. Ciao, Dscho
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > So yes, I totally agree that triggering an interactive prompt by the empty > value is not really a good idea (nor a particularly intuitive behavior). Puzzled. Nobody talked about going interactive so far and I didn't suggest it---even though I think it is a cute idea to give a "what branch name do you want to use?" prompt, I do not think it is practical. I thought it was obvious, but the key to coming up with a name dynamically instead of using a fixed string is to derive from a cue the end user gives, not directly use what the end user gives. I do not think anybody in the discussion meant by "the <basename> thing" to literally use $(basename $(cwd)) output, but use it to derive a token that check-ref-format likes. As you may have already known when you wrote them, "My Documents" or the root directory case are red herring---it would be trivial to derive "MyDocuments" or "my-documents" for the former, and for the latter, it is totally OK for the deriving rule to come up with any of "unnamed", "initial", etc. Most of the thing you said in the message I am responding to did not make much sense to me. Perhaps you can retry after reading the message you are responding to again? Thanks.
Hi Junio, On Tue, 17 Nov 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > case "$TEST_NUMBER" in > > 3404|4013|5310|5526|6300|7064|7817|9902) > > # Avoid conflicts with patch series that are cooking at the same > > # time > > # as the patch series changing the default of > > # `init.defaultBranch`. > > GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master > > export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > > ;; > > *) > > GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main > > export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME > > ;; > > esac > > I actually am not a big fan of the centralized table of "these want > to run with main". My ideal would be to have an explicit assignment > of either master or main for tests that absolutely require the > default to be one of these names at the top of these script, and any > test scripts that do not care what the initial branch is called > (perhaps because they begin by switching to a branch whose name is > picked by them immediately after they start and use that name > throughout) won't have GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME in them. I will make it so in v3. It does make sense, too: the four patch series I sent out in the past hours address some issues that I would have otherwise missed in the transition (in particular, two test cases with `test_must_fail` in them would have continued to pass, but for the wrong reason, during the transition to `main`. Ciao, Dscho
On 17/11/2020 22:55, Junio C Hamano wrote: > I personally > do not like the word 'main' used as such, but the rest of the world > seems to be moving in that direction, I feel that 'main' is rather a rather dull and boring sort of word. In that sense, it could be useful as the fall back for those who haven't yet got a clear view of what they want to call their first born. So I sort of support both views. An alternative in the other direction is to go with the 'not currently on any branch' (detached at nowhere) but then require users to deliberately create their first branch with their chosen name. This moves the 'backward incompatibility' to a different place, which may be easier to manage. -- Philip
Hi Philip, On Wed, 18 Nov 2020, Philip Oakley wrote: > An alternative in the other direction is to go with the 'not currently > on any branch' (detached at nowhere) but then require users to > deliberately create their first branch with their chosen name. This > moves the 'backward incompatibility' to a different place, which may be > easier to manage. It might be easier to manage for _us_, the Git developers. But every user who initializes a repository and wants to push now needs to take the extra step to give their unnamed branch ("detached HEAD" is _still_ confusing new users!!!) a name. That would be much more disruptive than choosing a "rather dull and boring" name instead of a rather racially-charged one. And we promised to try to minimize the disruption to Git users. Ciao, Dscho
Hi Dscho, On 19/11/2020 00:00, Johannes Schindelin wrote: > Hi Philip, > > On Wed, 18 Nov 2020, Philip Oakley wrote: > >> An alternative in the other direction is to go with the 'not currently >> on any branch' (detached at nowhere) but then require users to >> deliberately create their first branch with their chosen name. This >> moves the 'backward incompatibility' to a different place, which may be >> easier to manage. > It might be easier to manage for _us_, the Git developers. But every user > who initializes a repository and wants to push now Is this 'emerges fully formed' initialise & push really that common. I'd be expecting a few add & commits prior to the push, so plenty of time for deciding and creating the chosen branch. At least that was the thought process... > needs to take the extra > step to give their unnamed branch > ("detached HEAD" is _still_ confusing > new users!!!) a name. I'd only mentioned the detached head to keep the devs happy ;-) I'm quite happy with a "not on any named branch yet" type message for normal usage. > > That would be much more disruptive than choosing a "rather dull and > boring" name instead of a rather racially-charged one. "Main" is fine, but Junio had mention say "Primary" as being more positive, but that is begging the question for the user. We should let them chose. Hence using the not greatly inspiring 'main' as a starter offering would match that desire that the user should, ideally, make their own choice. > > And we promised to try to minimize the disruption to Git users. ...but we haven't said 'it' is an ignorable issue. There's still a lot of old documentation and inertia to overcome. > > Ciao, > Dscho Philip
Hello, It's worth noting that the word "slave" comes from the en_slav_ement of Slavs (the Slavic people of Eastern Europe). I encourage the whole git team to really think about the changes you are making. It was just reported to me that a professional friend of mine had confusion as to why, after initializing a new repository, they couldn't navigate to the `master` branch of their repository. I understand this is back-of-the-napkin type math but stay with me for one moment. I also understand GitHub is not all of git users, but I just pulled the number to help me out here. If GitHub has 40 million users but let's say half of them aren't active, so now we are at 20 million. (Replace this number with how many actual users of git are out there.) Let's even say half of them are on board and aware of this "harmless" change to a more "sensitive" doublespeak representation of the "master" copy/branch of the repo. That leaves us with 10 million users of git that are either unaware or are not on board. Let's say it takes 3 minutes for a user to search on the web why exactly they can't navigate to their "master" branch. That's 30 million minutes of time wasted, or about 57 man-YEARs of time wasted.... for what? When do we put our foot down and say enough is enough, and not everything is offensive? Again, please reconsider making this change towards doublespeak and consider the ramifications of how much actual human life & time will be wasted. Kind Regards, Peter On Wed, Nov 18, 2020 at 6:01 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > > Hi Philip, > > On Wed, 18 Nov 2020, Philip Oakley wrote: > > > An alternative in the other direction is to go with the 'not currently > > on any branch' (detached at nowhere) but then require users to > > deliberately create their first branch with their chosen name. This > > moves the 'backward incompatibility' to a different place, which may be > > easier to manage. > > It might be easier to manage for _us_, the Git developers. But every user > who initializes a repository and wants to push now needs to take the extra > step to give their unnamed branch ("detached HEAD" is _still_ confusing > new users!!!) a name. > > That would be much more disruptive than choosing a "rather dull and > boring" name instead of a rather racially-charged one. > > And we promised to try to minimize the disruption to Git users. > > Ciao, > Dscho
On 19/11/2020 00:30, Peter Hadlaw wrote: > That leaves us with 10 million users of git that are either unaware or > are not on board. Let's say it takes 3 minutes for a user to search on > the web why exactly they can't > navigate to their "master" branch. That's 30 million minutes of time > wasted, or about 57 man-YEARs of time wasted.... for what? That's (3 mins) probably about the same amount of time as most users waste on stack overflow for Git questions, or the old 'RTFM', for their problems in a typical week anyway. 3 mins out of a 35 hr week, over a 44 week x 25 year life is 1.3 ppm, unless you work too hard and too long, where it's an even lower ppm. There are mechanism in this series for setting the default branch name. -- Philip
There's still a responsibility for ~57 years worth of human life that doesn't actually need to be put at risk. Someone forgetting how to rebase a branch in some given way and then having to search is their own responsibility. On the other hand, this is a decision made on their behalf, without their consent, ... on everyone's behalf. If you're not going to change the default without user input, are you going to ask the user for a default branch name? Figure out the math and annoyance on that. On Wed, Nov 18, 2020 at 6:44 PM Philip Oakley <philipoakley@iee.email> wrote: > > On 19/11/2020 00:30, Peter Hadlaw wrote: > > That leaves us with 10 million users of git that are either unaware or > > are not on board. Let's say it takes 3 minutes for a user to search on > > the web why exactly they can't > > navigate to their "master" branch. That's 30 million minutes of time > > wasted, or about 57 man-YEARs of time wasted.... for what? > That's (3 mins) probably about the same amount of time as most users > waste on stack overflow for Git questions, or the old 'RTFM', for their > problems in a typical week anyway. > > 3 mins out of a 35 hr week, over a 44 week x 25 year life is 1.3 ppm, > unless you work too hard and too long, where it's an even lower ppm. > > There are mechanism in this series for setting the default branch name. > > -- > Philip >
Philip Oakley <philipoakley@iee.email> writes: > An alternative in the other direction is to go with the 'not currently > on any branch' (detached at nowhere) but then require users to > deliberately create their first branch with their chosen name. This > moves the 'backward incompatibility' to a different place, which may be > easier to manage. As has already been mentioned by Peff, I do not think that is a workable alternative, especially given that people are generally afraid of and easily get confused by being on a detached HEAD. And there is no such thing as unborn detached HEAD. Existing versions of Git would not consider a $GIT_DIR that does not have any HEAD, which means a new repository created by such an "initially there is no branch" version of Git cannot be accessed by any existing versions of Git. It raises the backward incompatibility of such an approach to a whole new level that is simply unmanageable, I am afraid.
Hi Junio, On Wed, 18 Nov 2020, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > So yes, I totally agree that triggering an interactive prompt by the empty > > value is not really a good idea (nor a particularly intuitive behavior). > > Puzzled. > > Nobody talked about going interactive so far and I didn't suggest > it---even though I think it is a cute idea to give a "what branch > name do you want to use?" prompt, I do not think it is practical. The interactive prompt was what I understood your "a notation that asks for the basename behaviour" comment. The "ask" was what tripped me up, I always interpret that as interactive. But now that I re-read it, I understand that you had not thought that far yet. > I thought it was obvious, but the key to coming up with a name > dynamically instead of using a fixed string is to derive from a cue > the end user gives, not directly use what the end user gives. I do > not think anybody in the discussion meant by "the <basename> thing" > to literally use $(basename $(cwd)) output, but use it to derive a > token that check-ref-format likes. As you may have already known > when you wrote them, "My Documents" or the root directory case are > red herring---it would be trivial to derive "MyDocuments" or > "my-documents" for the former, and for the latter, it is totally OK > for the deriving rule to come up with any of "unnamed", "initial", > etc. The more magic you introduce, the less intuitive the whole thing gets, and the more disruptive the change. > Most of the thing you said in the message I am responding to did not > make much sense to me. Perhaps you can retry after reading the > message you are responding to again? Could you be a bit more specific? Was it the "I already use the empty string to force a fall-back, it cannot also mean something else" that did not make sense? Or my comment that special-casing values that start with a colon would look saner to me? Or the comment about the basename in a root directory? Or referencing the SFC statement that we want to minimize disruption? Or my stated preference to go with `main` in order to fulfill that promise of minimizing the disruption to users? Or my current plan to introduce an `advise()` call when running `git init` that tells users that the fall-back for `init.defaultBranch` will change soon and that users are encouraged to configure it if they care about keeping the current fall-back? Or that all of this needs to be done with care? The message you refer to might not have been the best example of clear communication, but it hardly deserved _that_ response. Ciao, Dscho
On 19/11/2020 01:51, Junio C Hamano wrote: > Philip Oakley <philipoakley@iee.email> writes: > >> An alternative in the other direction is to go with the 'not currently >> on any branch' (detached at nowhere) but then require users to >> deliberately create their first branch with their chosen name. This >> moves the 'backward incompatibility' to a different place, which may be >> easier to manage. > As has already been mentioned by Peff, I do not think that is a > workable alternative, especially given that people are generally > afraid of and easily get confused by being on a detached HEAD. Yes, our use of the technical phrase 'detached HEAD' is confusing, compared with the more pleasant 'not on any branch', or 'not at a branch tip'. Such is the curse of knowledge. > > And there is no such thing as unborn detached HEAD. Existing > versions of Git would not consider a $GIT_DIR that does not have any > HEAD, which means a new repository created by such an "initially > there is no branch" version of Git cannot be accessed by any > existing versions of Git. Isn't this, essentially, because there is no 'empty/null commit' that we (HEAD) could start at? There have been a few cases where I've been 'annoyed' that we're missing that. (rather than the orphan branch approach) > > It raises the backward incompatibility of such an approach to a > whole new level that is simply unmanageable, I am afraid. OK, accepted. Philip
Philip Oakley <philipoakley@iee.email> writes: > On 19/11/2020 01:51, Junio C Hamano wrote: >> Philip Oakley <philipoakley@iee.email> writes: >> >>> An alternative in the other direction is to go with the 'not currently >>> on any branch' (detached at nowhere) but then require users to >>> deliberately create their first branch with their chosen name. This >>> moves the 'backward incompatibility' to a different place, which may be >>> easier to manage. >> As has already been mentioned by Peff, I do not think that is a >> workable alternative, especially given that people are generally >> afraid of and easily get confused by being on a detached HEAD. > Yes, our use of the technical phrase 'detached HEAD' is confusing, > compared with the more pleasant 'not on any branch', or 'not at a branch > tip'. Such is the curse of knowledge. To me "not on a branch [tip]" is also confusing, as in fact you are, as is easily seen after you perform a few commits, and now HEAD points directly to the tip of the branch (that has no other references). I wonder why Git didn't rather adopt "unnamed branch" or "nameless branch" to describe this mode of operation? -- Sergey
On 19/11/2020 11:10, Sergey Organov wrote: > Philip Oakley <philipoakley@iee.email> writes: > >> On 19/11/2020 01:51, Junio C Hamano wrote: >>> Philip Oakley <philipoakley@iee.email> writes: >>> >>>> An alternative in the other direction is to go with the 'not currently >>>> on any branch' (detached at nowhere) but then require users to >>>> deliberately create their first branch with their chosen name. This >>>> moves the 'backward incompatibility' to a different place, which may be >>>> easier to manage. >>> As has already been mentioned by Peff, I do not think that is a >>> workable alternative, especially given that people are generally >>> afraid of and easily get confused by being on a detached HEAD. >> Yes, our use of the technical phrase 'detached HEAD' is confusing, >> compared with the more pleasant 'not on any branch', or 'not at a branch >> tip'. Such is the curse of knowledge. > To me "not on a branch [tip]" is also confusing, as in fact you are, as > is easily seen after you perform a few commits, and now HEAD points > directly to the tip of the branch (that has no other references). > > I wonder why Git didn't rather adopt "unnamed branch" or "nameless > branch" to describe this mode of operation? Given the ephemeral nature of branches they sound like good suggestion. However I suspect "history" to be the "why" of the current 'detached head' usage. Maybe it's a side reference to Nearly Headless Nick or other discussions of the time (aka lost in history)? -- Philip
Philip Oakley <philipoakley@iee.email> writes: > On 19/11/2020 11:10, Sergey Organov wrote: >> Philip Oakley <philipoakley@iee.email> writes: >> >>> On 19/11/2020 01:51, Junio C Hamano wrote: >>>> Philip Oakley <philipoakley@iee.email> writes: >>>> >>>>> An alternative in the other direction is to go with the 'not currently >>>>> on any branch' (detached at nowhere) but then require users to >>>>> deliberately create their first branch with their chosen name. This >>>>> moves the 'backward incompatibility' to a different place, which may be >>>>> easier to manage. >>>> As has already been mentioned by Peff, I do not think that is a >>>> workable alternative, especially given that people are generally >>>> afraid of and easily get confused by being on a detached HEAD. >>> Yes, our use of the technical phrase 'detached HEAD' is confusing, >>> compared with the more pleasant 'not on any branch', or 'not at a branch >>> tip'. Such is the curse of knowledge. >> To me "not on a branch [tip]" is also confusing, as in fact you are, as >> is easily seen after you perform a few commits, and now HEAD points >> directly to the tip of the branch (that has no other references). >> >> I wonder why Git didn't rather adopt "unnamed branch" or "nameless >> branch" to describe this mode of operation? > Given the ephemeral nature of branches they sound like good > suggestion. Sure, so to me they sound even more natural in Git context than in any other VCS I'm aware of. > > However I suspect "history" to be the "why" of the current 'detached > head' usage. > Maybe it's a side reference to Nearly Headless Nick or other discussions > of the time (aka lost in history)? I do have a few commits at which HEAD has been detached, not once at some. Bloody they are. -- Sergey
Sergey Organov <sorganov@gmail.com> writes: > To me "not on a branch [tip]" is also confusing, as in fact you are, as > is easily seen after you perform a few commits, and now HEAD points > directly to the tip of the branch (that has no other references). Aren't you confused about what "on a branch" means? After either of these two operations, your HEAD may point at the same commit, but the former is on a branch (the master branch), and the latter is not. git checkout master git checkout master^0 The difference between these two states does *NOT* come from which commit HEAD points at. The difference comes from what happens when you make a new commit starting from that state. The former (i.e. you are on a branch) grows the branch. The latter (i.e. you are not on a branch) does not grow any branch. This is an unrelated trivia, but did anybody know that we were pretty much on the detached HEAD all the time for more than a month of early life of Git, until cad88fdf (git-init-db: set up the full default environment, 2005-05-30)?
Junio C Hamano <gitster@pobox.com> writes: > Sergey Organov <sorganov@gmail.com> writes: > >> To me "not on a branch [tip]" is also confusing, as in fact you are, as >> is easily seen after you perform a few commits, and now HEAD points >> directly to the tip of the branch (that has no other references). > > Aren't you confused about what "on a branch" means? I believe I'm not. > > After either of these two operations, your HEAD may point at the > same commit, but the former is on a branch (the master branch), and > the latter is not. > > git checkout master > git checkout master^0 > > The difference between these two states does *NOT* come from which > commit HEAD points at. Sure. > > The difference comes from what happens when you make a new commit > starting from that state. The former (i.e. you are on a branch) > grows the branch. Sure. > The latter (i.e. you are not on a branch) does not grow any branch. That's one way of looking at it, resulting in this "detached HEAD" thingy that is too technical for the git user proper, I think. Moreover, it immediately raises the question: if it doesn't grow any branch, /what/ does it grow? Another way of describing it, that I prefer, is that you /are/ on an /unnamed/ branch and new commits grow this particular /unnamed/ branch. No need not only for "detached", but even for "HEAD" to be known to the user to get the idea, I think. > > This is an unrelated trivia, but did anybody know that we were > pretty much on the detached HEAD all the time for more than a month > of early life of Git, until cad88fdf (git-init-db: set up the full > default environment, 2005-05-30)? I was not aware, and it seems that in my terminology it'd sound: "Git didn't have named branches until cad88fdf". -- Sergey
On 22/11/2020 10:21, Sergey Organov wrote: > Junio C Hamano <gitster@pobox.com> writes: > >> Sergey Organov <sorganov@gmail.com> writes: >> >>> To me "not on a branch [tip]" is also confusing, as in fact you are, as >>> is easily seen after you perform a few commits, and now HEAD points >>> directly to the tip of the branch (that has no other references). >> Aren't you confused about what "on a branch" means? > I believe I'm not. Isn't this one of those "implementation detail" viewpoint arguments, combined with some incompleteness in various places. From a naive english user perspective , 'on' a branch can also mean anywhere along a branch and not just at the tip. Being at a commit along a branch can be tricky to appreciate (that on/at distinction isn't immediately obvious..) > >> After either of these two operations, your HEAD may point at the >> same commit, but the former is on a branch (the master branch), and >> the latter is not. >> >> git checkout master >> git checkout master^0 >> >> The difference between these two states does *NOT* come from which >> commit HEAD points at. > Sure. From an implementation perspective one can go two ways, and we tell the user which way we went, even though, ultimately, we look at the same commit. Though, for an unborn branch we don't have a null commit value (c.f. empty tree) to help in being 'detached at nowhere'. > >> The difference comes from what happens when you make a new commit >> starting from that state. The former (i.e. you are on a branch) >> grows the branch. > Sure. > >> The latter (i.e. you are not on a branch) does not grow any branch. > That's one way of looking at it, resulting in this "detached HEAD" > thingy that is too technical for the git user proper, I think. Moreover, > it immediately raises the question: if it doesn't grow any branch, /what/ > does it grow? > > Another way of describing it, that I prefer, is that you /are/ on an > /unnamed/ branch and new commits grow this particular /unnamed/ branch. > No need not only for "detached", but even for "HEAD" to be known to the > user to get the idea, I think. I don't think we can start like this and continue with a commit on top of the orphaned 'unnamed' branch. (Not tried it though..) > >> This is an unrelated trivia, but did anybody know that we were >> pretty much on the detached HEAD all the time for more than a month >> of early life of Git, until cad88fdf (git-init-db: set up the full >> default environment, 2005-05-30)? > I was not aware, and it seems that in my terminology it'd sound: "Git > didn't have named branches until cad88fdf". > > -- Sergey
Philip Oakley <philipoakley@iee.email> writes: > On 22/11/2020 10:21, Sergey Organov wrote: >> Junio C Hamano <gitster@pobox.com> writes: >> >>> Sergey Organov <sorganov@gmail.com> writes: >>> >>>> To me "not on a branch [tip]" is also confusing, as in fact you are, as >>>> is easily seen after you perform a few commits, and now HEAD points >>>> directly to the tip of the branch (that has no other references). >>> Aren't you confused about what "on a branch" means? >> I believe I'm not. > > Isn't this one of those "implementation detail" viewpoint arguments, > combined with some incompleteness in various places. > > From a naive english user perspective , 'on' a branch can also mean > anywhere along a branch and not just at the tip. Being at a commit along > a branch can be tricky to appreciate (that on/at distinction isn't > immediately obvious..) >> >>> After either of these two operations, your HEAD may point at the >>> same commit, but the former is on a branch (the master branch), and >>> the latter is not. >>> >>> git checkout master >>> git checkout master^0 >>> >>> The difference between these two states does *NOT* come from which >>> commit HEAD points at. >> Sure. > From an implementation perspective one can go two ways, and we tell the > user which way we went, even though, ultimately, we look at the same > commit. AFAIU, the only difference is that HEAD points to the commit directly in the case of "detached HEAD", while it points to the commit indirectly through the branch reference in the usual case. > > Though, for an unborn branch we don't have a null commit value (c.f. > empty tree) to help in being 'detached at nowhere'. We can pretend we have a null commit for the sake of regularity, even though Git implementation has none. Actually, it looks like a few things would be easier if Git got the "Adam" commit that is the ultimate final parent of everything in the first place, but it didn't. >> >>> The difference comes from what happens when you make a new commit >>> starting from that state. The former (i.e. you are on a branch) >>> grows the branch. >> Sure. >> >>> The latter (i.e. you are not on a branch) does not grow any branch. >> That's one way of looking at it, resulting in this "detached HEAD" >> thingy that is too technical for the git user proper, I think. Moreover, >> it immediately raises the question: if it doesn't grow any branch, /what/ >> does it grow? >> >> Another way of describing it, that I prefer, is that you /are/ on an >> /unnamed/ branch and new commits grow this particular /unnamed/ branch. >> No need not only for "detached", but even for "HEAD" to be known to the >> user to get the idea, I think. > I don't think we can start like this and continue with a commit on top > of the orphaned 'unnamed' branch. (Not tried it though..) I rather believe we can, no problems, and that's why "detached HEAD" behaves exactly as unnamed branch would. To make it obvious "detached HEAD" is in fact a subset of the usual case, imagine that "detached HEAD" is rather first implemented by pointing to a branch reference with a hidden name that in turn points to the commit, and then this "incognito branch reference" is optimized-out as being invisible anyway, so HEAD now points to the commit itself. -- Sergey Organov
On 22/11/2020 13:23, Sergey Organov wrote: >>>> The latter (i.e. you are not on a branch) does not grow any branch. >>> That's one way of looking at it, resulting in this "detached HEAD" >>> thingy that is too technical for the git user proper, I think. Moreover, >>> it immediately raises the question: if it doesn't grow any branch, /what/ >>> does it grow? >>> >>> Another way of describing it, that I prefer, is that you /are/ on an >>> /unnamed/ branch and new commits grow this particular /unnamed/ branch. >>> No need not only for "detached", but even for "HEAD" to be known to the >>> user to get the idea, I think. >> I don't think we can start like this and continue with a commit on top >> of the orphaned 'unnamed' branch. (Not tried it though..) > I rather believe we can, no problems, and that's why "detached HEAD" behaves > exactly as unnamed branch would. > > To make it obvious "detached HEAD" is in fact a subset of the usual > case, imagine that "detached HEAD" is rather first implemented by > pointing to a branch reference with a hidden name that in turn points to > the commit, and then this "incognito branch reference" is optimized-out > as being invisible anyway, so HEAD now points to the commit itself. > Thinking about some options... After a `git init`: We can hack HEAD to "ref: refs/heads/" (i.e. a symref to an unnamed branch) and `git status` will report "No commits yet". My PS1 will report the current branch as "()" (i.e. an empty name). However, `git branch` reports "Failed to resolve HEAD as a valid ref.", and `git commit` reports "cannot lock ref 'HEAD': there is a non-empty directory '.git/refs/heads/' blocking reference 'refs/heads/'". So, there could be the option to detect that unnamed ref state (no characters after the final "/") without going "Fatal:". However there is still the potential difficulty that after the first commit on that unnamed branch we would have the difficult choice of: - either keeping that unnamed ref/branch symref, and have nowhere to hold the new commit name (oid), because HEAD is already acting as the place holder for the symref, - or we have to lose the place holder symref and place the new commit oid into HEAD, leaving us back at the regular "detached head", but for an as yet unnamed orphan branch. (tested on Windows[1]) For the second case we would still need to ensure that protections are in place to avoid loosing those detached commits if the user switches/checks out to new branch based on some other oid. (for that to happen then that checkout oid must be somewhere in the unnamed branch, but the latest tip commits should need checking to prevent unexpected loss - the current warning may not be enough...) At the moment there is a lot of 'lock-in' for the status quo, and the alternative may not be any better, and have some backward compatibility issues, though those may be overstated, depending on how repos are being 'shared'. Philip [1] phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/unnamed () $ git version git version 2.29.2.windows.2
On Sun, Nov 22, 2020 at 4:24 AM Sergey Organov <sorganov@gmail.com> wrote: > > Junio C Hamano <gitster@pobox.com> writes: > > The latter (i.e. you are not on a branch) does not grow any branch. > > That's one way of looking at it, resulting in this "detached HEAD" > thingy that is too technical for the git user proper, I think. Moreover, > it immediately raises the question: if it doesn't grow any branch, /what/ > does it grow? > > Another way of describing it, that I prefer, is that you /are/ on an > /unnamed/ branch and new commits grow this particular /unnamed/ branch. > No need not only for "detached", but even for "HEAD" to be known to the > user to get the idea, I think. This is precisely what it is conceptually. And there's absolutely no need for the user to know what HEAD is behind the curtains, especially since they can just use @, and think of it as "the current branch". It is clearly a branch, for example you can do "git push origin @:my-fix". Cheers.
Felipe Contreras <felipe.contreras@gmail.com> writes:
> It is clearly a branch, for example you can do "git push origin @:my-fix".
Hmm, you can also do "git push origin c2f3bf071e:maintenance", but
it does not make a bare object name a branch.
At least I doubt the "clearly" part of your statement. There might
be a better example to support the above claim, but this one is not.