Announcement

Collapse
No announcement yet.

Git 2.28-rc1 Released - Continues The Transition Towards SHA256 Plus Moving Off "Master"

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • tomas
    replied
    I think the following note from the git documentation about the "master" branch really says it all:

    NOTE: The “master” branch in Git is not a special branch. It is exactly like any other branch. The only reason nearly every repository has one is that the git init command creates it by default and most people don’t bother to change it.
    https://git-scm.com/book/en/v2/Git-B...-in-a-Nutshell

    Leave a comment:


  • tomas
    replied
    Originally posted by lucrus View Post

    Exactly, but that does not prevent me to have opinions about the work being done. I'm used to say "If it stinks, it's probably shit" and I feel this one stinks a lot.
    Yes, it really stinks that they want to make it configurable what to name the initial branch in a git repo. How dare they!

    Leave a comment:


  • lucrus
    replied
    Originally posted by tomas View Post
    Like it has always been with open source.
    Exactly, but that does not prevent me to have opinions about the work being done. I'm used to say "If it stinks, it's probably shit" and I feel this one stinks a lot.

    Leave a comment:


  • tomas
    replied
    Originally posted by lucrus View Post

    Times when the only people working at open source projects were all volunteers are over by more than two decades, especially for such big projects like git and Linux. And if you are being paid to develop, you have to do what your employer tells you to do, at least sometimes.
    Yes, and now someone either paid someone to work on this feature or someone is scratching his or hers own itch. Like it has always been with open source. What are you actually arguing about? Unless you yourself pay someone to work on what you think is important in git or persuades someone to work on what you think is important or you yourself starts contributing to git the features you think are important, nothing is going to change. Like it has always been with open source.
    Last edited by tomas; 20 July 2020, 12:36 PM.

    Leave a comment:


  • tomas
    replied
    Originally posted by bug77 View Post
    I wouldn't even qualify it as a "nice to have". I'm closing in on 20 years in the industry and not once have I given a second thought to a VCS' branch naming convention.
    Do you usually give your branches arbitrary names that do not reflect their purpose at all? That seems confusing to me. Besides, changing the name of an existing branch in your git repo is already possible as can be seen from my Stack Overflow reference:
    Code:
    git checkout -b release master  # create and switch to the release branch
    git push -u origin release      # push the release branch to the remote and track it
    git branch -d master            # delete local master
    git push --delete origin master # delete remote master
    git remote prune origin         # delete the remote tracking branch
    Are you now saying you would rather like to remove this possibility?

    In fact, it's much worse than a nice to have, because it introduces another source for bugs (which encoding to use?, does it handle special characters correctly?)
    These rules are already enforced when creating new branches in git. The proposed feature does not change anything regarding this.

    and downright confusion (what prevents someone form calling the main branch "secondary"?).
    Nothing prevents anyone from calling any branch (almost) anything in git, and that's all fine.
    This since a branch in git does not hold any special meaning compared to another branch besides what you decide yourself. That is the beauty of it. And as you already said: "what prevents someone from calling the main branch"...
    It seems to me you would rather like the "master" branch to be named "main" ;-)
    Go ahead, nothing prevents you from doing so.

    And where do we draw a line? Because once the branch names become configurable, another nice to have would a mechanism that looks up branch names for you. You know, totally useless, but still nice to have.
    What does this even mean "mechanism that looks up branch names for you"?
    Last edited by tomas; 20 July 2020, 12:31 PM.

    Leave a comment:


  • lucrus
    replied
    Originally posted by tomas View Post
    This is a flawed argument. People work on what they believe make sense in open source projects.
    Times when the only people working at open source projects were all volunteers are over by more than two decades, especially for such big projects like git and Linux. And if you are being paid to develop, you have to do what your employer tells you to do, at least sometimes.

    Leave a comment:


  • bug77
    replied
    Originally posted by lucrus View Post

    I suspect you did not fully understand bug77 comment. He asked if there is a ticket to make svn trunk configurable, not if svn provides such a feature. His comment focuses on the level of interest for this feature, which is low and that's clear from the fact that none ever filed a bug report for it even in svn.

    Then again, it's obviously nice to have, but it's bad developers have to waste time on this feature, driven by inclusive language reasons, while there are lots of more interesting and useful things they could do instead.
    I wouldn't even qualify it as a "nice to have". I'm closing in on 20 years in the industry and not once have I given a second thought to a VCS' branch naming convention.
    In fact, it's much worse than a nice to have, because it introduces another source for bugs (which encoding to use?, does it handle special characters correctly?) and downright confusion (what prevents someone form calling the main branch "secondary"?).
    And where do we draw a line? Because once the branch names become configurable, another nice to have would a mechanism that looks up branch names for you. You know, totally useless, but still nice to have.

    Leave a comment:


  • tomas
    replied
    Originally posted by lucrus View Post
    Then again, it's obviously nice to have, but it's bad developers have to waste time on this feature, driven by inclusive language reasons, while there are lots of more interesting and useful things they could do instead.
    This is a flawed argument. People work on what they believe make sense in open source projects. No one gets to decide what is "interesting and useful things" and that someone is "wasting their time". You assume that the person(s) working towards this particular goal would be inclined to work on something else instead, but you don't know that. No one except the persons doing the job gets to decide that. That has always been the way of open source: the one that puts in the effort gets to decide. Finally, you don't actually have any proof that this change is at all driven by "inclusive language reasons". In fact, I sincerely doubt it. And even if that would be the case, it would not really matter since the change by itself is sound, regardless of motives.
    Last edited by tomas; 20 July 2020, 06:47 AM.

    Leave a comment:


  • lucrus
    replied
    Originally posted by tomas View Post
    bug77 Just because svn is inferior to git in every possible way, especially working with branches, does not mean git should be forced to use a hardcoded name for its default branch.
    I suspect you did not fully understand bug77 comment. He asked if there is a ticket to make svn trunk configurable, not if svn provides such a feature. His comment focuses on the level of interest for this feature, which is low and that's clear from the fact that none ever filed a bug report for it even in svn.

    Then again, it's obviously nice to have, but it's bad developers have to waste time on this feature, driven by inclusive language reasons, while there are lots of more interesting and useful things they could do instead.

    Leave a comment:


  • tomas
    replied
    bug77 Just because svn is inferior to git in every possible way, especially working with branches, does not mean git should be forced to use a hardcoded name for its default branch. There are perfectly valid use cases for wanting the default branch be named something else than "master". Now, you might not agree with those reasons, but why you would deny someone else to have the possibility to name the default branch something else than "master" when creating a new git repo is beyond me. All of you people raging on and on about SJW and how making the name of the default branch configurable in git spells the end of the world, are making a fool of yourselves. When I first read this news article about the new git version and that they are working on removing the hardcoded assumption about having the default branch named "master" I just thought: yes, that makes perfect sense both from a technical point of view and from a use case perspective. Then I started to read the comments and was baffled. You really ought to get out more. You are starting to imagining things that really are not there. It's unhealthy.
    Last edited by tomas; 20 July 2020, 06:24 AM.

    Leave a comment:

Working...
X