▲ 461 ▼ Linus Torvalds built Git in 10 days - and never imagined it would last 20 years (www.zdnet.com) submitted 1 year ago by cm0002@lemmy.world to c/programming@programming.dev 70 comments fedilink hide all child comments
[–] SpaceNoodle@lemmy.world 9 points 1 year ago (2 children) What do you mean by "are a thing?" Git has branches. permalink fedilink source parent hideshow 4 child comments replies: [–] notabot@lemm.ee 7 points 1 year ago (1 child) Git branches are very different to Mercurial branches. In git they're similar to tags that move along with the head commit of that particular branch. In Mercurial every commit contains meta data indicating the branch it's on. It also has a query language that lets you do sone quite neat things with selecting groups of commits based on their metadata, which can be useful in code reviews and similar. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 3 points 1 year ago (2 children) That just sounds like an implementation detail. Can you provide an example of something that's possible in Mercurial, but not git? permalink fedilink source parent hideshow 4 child comments replies: [–] Kayana@ttrpg.network 3 points 1 year ago (1 child) I've never used Mercurial, but a simple one based on the explanations and my experience with Git: Locating the branch a commit originated from. If a git branch has been merged into (or rebased on) main or another branch, there's no way to tell which commit came from which branch. But sometimes I'd really like that information to figure out what prompted a certain change. Without it, I need to use external tools like a ticketing system and hope the other developers added in the necessary information. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago* That seems to be the opposite of useful if a commit is initially pushed to a development branch, which is relatively standard practice; now you're polluting the tree with data that's purposefully ephemeral, and even potentially leaking internal information. Also, I'd argue that such deep details do belong in another tool, rather than asking the source control tool perform triple duty by being a CR and issue tracker as well. permalink fedilink source parent [–] notabot@lemm.ee 1 point 1 year ago Most of the time you're right, it's little more than a detail, but sometimes I miss the querying that it allowed. You could ask for things like a list of all branches that branched from a specific parent branch and modified a specific file, Which can be handy when you want to understand the impact a change might have before you make it and try merging. Having the branch name embedded in the commit means you can meaningfully ask this sort of question. In git's model you can't say a changeset is in a specific branch once there are child branches further downstream because the changeset is in all of those branches. Rather than come up with lots of examples for other queries (I know it wasn't the focus of your question, but I think it's really neat), I found this page which seems like a reasonable description. permalink fedilink source parent [–] alsimoneau@lemmy.ca 3 points 1 year ago (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 4 points 1 year ago (1 child) What information is "loosed" when another commit is made to the branch? permalink fedilink source parent hideshow 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 3 points 1 year ago (1 child) 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 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 1 point 1 year ago (1 child) 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 2 child comments replies: [–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] notabot@lemm.ee 7 points 1 year ago (1 child) Git branches are very different to Mercurial branches. In git they're similar to tags that move along with the head commit of that particular branch. In Mercurial every commit contains meta data indicating the branch it's on. It also has a query language that lets you do sone quite neat things with selecting groups of commits based on their metadata, which can be useful in code reviews and similar. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 3 points 1 year ago (2 children) That just sounds like an implementation detail. Can you provide an example of something that's possible in Mercurial, but not git? permalink fedilink source parent hideshow 4 child comments replies: [–] Kayana@ttrpg.network 3 points 1 year ago (1 child) I've never used Mercurial, but a simple one based on the explanations and my experience with Git: Locating the branch a commit originated from. If a git branch has been merged into (or rebased on) main or another branch, there's no way to tell which commit came from which branch. But sometimes I'd really like that information to figure out what prompted a certain change. Without it, I need to use external tools like a ticketing system and hope the other developers added in the necessary information. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago* That seems to be the opposite of useful if a commit is initially pushed to a development branch, which is relatively standard practice; now you're polluting the tree with data that's purposefully ephemeral, and even potentially leaking internal information. Also, I'd argue that such deep details do belong in another tool, rather than asking the source control tool perform triple duty by being a CR and issue tracker as well. permalink fedilink source parent [–] notabot@lemm.ee 1 point 1 year ago Most of the time you're right, it's little more than a detail, but sometimes I miss the querying that it allowed. You could ask for things like a list of all branches that branched from a specific parent branch and modified a specific file, Which can be handy when you want to understand the impact a change might have before you make it and try merging. Having the branch name embedded in the commit means you can meaningfully ask this sort of question. In git's model you can't say a changeset is in a specific branch once there are child branches further downstream because the changeset is in all of those branches. Rather than come up with lots of examples for other queries (I know it wasn't the focus of your question, but I think it's really neat), I found this page which seems like a reasonable description. permalink fedilink source parent
[–] SpaceNoodle@lemmy.world 3 points 1 year ago (2 children) That just sounds like an implementation detail. Can you provide an example of something that's possible in Mercurial, but not git? permalink fedilink source parent hideshow 4 child comments replies: [–] Kayana@ttrpg.network 3 points 1 year ago (1 child) I've never used Mercurial, but a simple one based on the explanations and my experience with Git: Locating the branch a commit originated from. If a git branch has been merged into (or rebased on) main or another branch, there's no way to tell which commit came from which branch. But sometimes I'd really like that information to figure out what prompted a certain change. Without it, I need to use external tools like a ticketing system and hope the other developers added in the necessary information. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago* That seems to be the opposite of useful if a commit is initially pushed to a development branch, which is relatively standard practice; now you're polluting the tree with data that's purposefully ephemeral, and even potentially leaking internal information. Also, I'd argue that such deep details do belong in another tool, rather than asking the source control tool perform triple duty by being a CR and issue tracker as well. permalink fedilink source parent [–] notabot@lemm.ee 1 point 1 year ago Most of the time you're right, it's little more than a detail, but sometimes I miss the querying that it allowed. You could ask for things like a list of all branches that branched from a specific parent branch and modified a specific file, Which can be handy when you want to understand the impact a change might have before you make it and try merging. Having the branch name embedded in the commit means you can meaningfully ask this sort of question. In git's model you can't say a changeset is in a specific branch once there are child branches further downstream because the changeset is in all of those branches. Rather than come up with lots of examples for other queries (I know it wasn't the focus of your question, but I think it's really neat), I found this page which seems like a reasonable description. permalink fedilink source parent
[–] Kayana@ttrpg.network 3 points 1 year ago (1 child) I've never used Mercurial, but a simple one based on the explanations and my experience with Git: Locating the branch a commit originated from. If a git branch has been merged into (or rebased on) main or another branch, there's no way to tell which commit came from which branch. But sometimes I'd really like that information to figure out what prompted a certain change. Without it, I need to use external tools like a ticketing system and hope the other developers added in the necessary information. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago* That seems to be the opposite of useful if a commit is initially pushed to a development branch, which is relatively standard practice; now you're polluting the tree with data that's purposefully ephemeral, and even potentially leaking internal information. Also, I'd argue that such deep details do belong in another tool, rather than asking the source control tool perform triple duty by being a CR and issue tracker as well. permalink fedilink source parent
[–] SpaceNoodle@lemmy.world 2 points 1 year ago* That seems to be the opposite of useful if a commit is initially pushed to a development branch, which is relatively standard practice; now you're polluting the tree with data that's purposefully ephemeral, and even potentially leaking internal information. Also, I'd argue that such deep details do belong in another tool, rather than asking the source control tool perform triple duty by being a CR and issue tracker as well. permalink fedilink source parent
[–] notabot@lemm.ee 1 point 1 year ago Most of the time you're right, it's little more than a detail, but sometimes I miss the querying that it allowed. You could ask for things like a list of all branches that branched from a specific parent branch and modified a specific file, Which can be handy when you want to understand the impact a change might have before you make it and try merging. Having the branch name embedded in the commit means you can meaningfully ask this sort of question. In git's model you can't say a changeset is in a specific branch once there are child branches further downstream because the changeset is in all of those branches. Rather than come up with lots of examples for other queries (I know it wasn't the focus of your question, but I think it's really neat), I found this page which seems like a reasonable description. permalink fedilink source parent
[–] alsimoneau@lemmy.ca 3 points 1 year ago (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 4 points 1 year ago (1 child) What information is "loosed" when another commit is made to the branch? permalink fedilink source parent hideshow 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 3 points 1 year ago (1 child) 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 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 1 point 1 year ago (1 child) 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 2 child comments replies: [–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] SpaceNoodle@lemmy.world 4 points 1 year ago (1 child) What information is "loosed" when another commit is made to the branch? permalink fedilink source parent hideshow 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 3 points 1 year ago (1 child) 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 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 1 point 1 year ago (1 child) 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 2 child comments replies: [–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 3 points 1 year ago (1 child) 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 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 1 point 1 year ago (1 child) 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 2 child comments replies: [–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] SpaceNoodle@lemmy.world 3 points 1 year ago (1 child) 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 2 child comments replies: [–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 1 point 1 year ago (1 child) 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 2 child comments replies: [–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] bleistift2@sopuli.xyz 1 point 1 year ago* (1 child) 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 1 point 1 year ago (1 child) 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 2 child comments replies: [–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] SpaceNoodle@lemmy.world 1 point 1 year ago (1 child) 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 2 child comments replies: [–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] alsimoneau@lemmy.ca 0 points 1 year ago (1 child) It makes the history clearer. permalink fedilink source parent hideshow 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] SpaceNoodle@lemmy.world 2 points 1 year ago (1 child) How is a Mercurial commit tree clearer than a git commit tree? permalink fedilink source parent hideshow 2 child comments replies: [–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] alsimoneau@lemmy.ca 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 2 child comments replies: [–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent
[–] SpaceNoodle@lemmy.world 2 points 1 year ago No, merging in git does not make branches disappear. permalink fedilink source parent