464
Linus Torvalds built Git in 10 days - and never imagined it would last 20 years (www.zdnet.com)
submitted 1 year ago by to c/programming@programming.dev
70 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 3 points 1 year ago (9 children)

No, git has labels on heads of branches. Once the head moves you loose the information. It also makes for a more messy history, which I believe created the whole "rebase everything" philosophy to cope.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 4 points 1 year ago (8 children)

    What information is "loosed" when another commit is made to the branch?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 1 point 1 year ago* (7 children)

    If I hand you a commit, you cannot tell which ‘branch’ it is on without searching the git history and hoping that you only get one answer. That’s a bummer if, for instance, you’re a github action and only get handed the commit. If it’s on the master branch, I want to do different things than if it’s a dev branch.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 3 points 1 year ago (6 children)

    A commit all by itself doesn't mean as much without context.

    Why would I not want to be able to apply a commit to any arbitrary branch?

    Also, GitHub is not git - it's based on git. Any shortcomings it may have aren't necessarily due to a flaw in git.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 1 point 1 year ago* (5 children)

    A commit all by itself doesn’t mean as much without context.

    Luckily a commit points to its parent, which means the context is inherently present. What’s your point?

    Why would I not want to be able to apply a commit to any arbitrary branch?

    Nobody said that.

    Any shortcomings it may have aren’t necessarily due to a flaw in git.

    True enough.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 1 point 1 year ago (4 children)

    Your claim appears to be that Mercurial binds commits to branches, and I'm explaining how I fail to see the advantage.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 0 points 1 year ago (3 children)

    It makes the history clearer.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 year ago (2 children)

    How is a Mercurial commit tree clearer than a git commit tree?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 0 points 1 year ago (1 child)

    Branches are distinct.

    Let's say you have a main and a dev branch, and you periodically merge dev into main. Because of fast forwarding (on by default) the main branch is completely gone from the history. If you then add bug fixes and project branches it becomes a tangled mess really quickly and it's nearly impossible to understand the structure by looking at the tree.

    On mercurial every branch is named and distinct forever. You don't have to try to understand what happened to the project since it's obvious by looking at the tree.

    Now there are ways to have a clean git history, but afaik you either need to make sure nobody ever messes it up or have everyone rebase everything and only keep the history of the main branch.

    When working in a hyper structured organization that may work, but for more casual developers (scientists, students) that aren't system experts and where you have messy history, mercurial default settings are less confusing, easier to learn and produce better results.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •