4 ms·

Commits in git can have multiple parents, aka 'merge commits'. Using them maintains the branch history.

by mbell 9y ago

dchest 9y ago
They don't maintain the branch name, or even the history of the branch: they just tell what are the parent commits of the commit; as mentioned above, this history can be a "lie". Fossil's history is immutable — once the commit is there, it's there forever (although you can prevent an artifact from being synched or displayed with "shunning").
- mbell 9y ago
  The default message is "Merge branch '<name>'"
  - dchest 9y ago
    :-) That's not a proper data structure, and you can't point to a random commit after merging and deleting a branch, and ask git to tell you which branch it came from.
    - mbell 9y ago
      Yes, you can. The name is not stored in the history other than the merge commit message but the full history is there and you can ask git to show you the merge commit for any commit.
      - dchest 9y ago
        You are talking about history of commits, not branches. Here I commented about tracking branches, hopefully it's more clear: https://news.ycombinator.com/item?id=16806954 https://news.ycombinator.com/item?id=16806954
        mbell 9y ago
        No I'm not, you do _not_ require keeping a branch around to have the complete commit history of the branch, the point it diverged from another branch, all the commits that were on the branch, and the point where it was merged back into another branch. Git doesn't keep the name of the branch in the history outside the merge commit message, but everything else is there.
        dchest 9y ago
        Here's a simple example: - Eve has a repository, Alice and Bob have access to it. Eve goes on vacation and nobody commits to "master"/"trunk". - Alice makes a branch "alice-fixes" and creates commits on it. - Bob comes and creates a branch "bob-features" from some point from "alice-fixes". - Bob then merges "bob-features" into "master" and deletes it. - Alice gets fired and her branch is deleted without merging. In git, you can't see that some of the commits in the history came from "alice-fixes". Fossil, on the other keeps track of branch names and _changes_ in commits: When Alice created her branch: -trunk +alice-fixes When Bob created his branch: -alice-fixes +blob-features When Bob merges his branch: -bob-features +trunk https://imgur.com/a/yRxAD https://imgur.com/a/yRxAD You can't delete this information, because it's recorded in the commit artifacts. You can't delete branches — you can only close and hide them (you can also apply edits to commits by adding "edit" artifacts [don't remember what the are called], but the history is preserved, not modified.)
        mbell 9y ago
        I think that is just an example of losing the branch name, the commit history is the same in both cases. If you really want that behavior from git, you can have it, just create a tag for each branch HEAD. Actually I think this is all that fossil does as well.
        dchest 9y ago
        It's not the same, there's no commit indicating that Bob branched off Alice's branch. It appears as if the whole history before merging belongs to Bob's branch. There is such commit in Fossil. > If you really want that behavior from git, you can have it, just create a tag for each branch HEAD. Actually I think this is all that fossil does as well. Fossil has branch/tag name directly in the checkin manifest (I've linked to the document describing file format somewhere above.) Tag and branch names are embedded directly in the history, they are not separate references to commit hashes like in git.
- mbell 9y ago
  > or even the history of the branch That is not true. You get a branch diagram just like the fossil example in the OP.

Commits in git can have multiple parents, aka 'merge commits'. Using them maintains the branch history.

by mbell 9y ago

Commits in git can have multiple parents, aka 'merge commits'. Using them maintains the branch history.

They don't maintain the branch name, or even the history of the branch: they just tell what are the parent commits of the commit; as mentioned above, this history can be a "lie". Fossil's history is immutable — once the commit is there, it's there forever (although you can prevent an artifact from being synched or displayed with "shunning").

mbell 9y ago
The default message is "Merge branch '<name>'"
- dchest 9y ago
  :-) That's not a proper data structure, and you can't point to a random commit after merging and deleting a branch, and ask git to tell you which branch it came from.
  - mbell 9y ago
    Yes, you can. The name is not stored in the history other than the merge commit message but the full history is there and you can ask git to show you the merge commit for any commit.
    - dchest 9y ago
      You are talking about history of commits, not branches. Here I commented about tracking branches, hopefully it's more clear: https://news.ycombinator.com/item?id=16806954 https://news.ycombinator.com/item?id=16806954
      - mbell 9y ago
        No I'm not, you do _not_ require keeping a branch around to have the complete commit history of the branch, the point it diverged from another branch, all the commits that were on the branch, and the point where it was merged back into another branch. Git doesn't keep the name of the branch in the history outside the merge commit message, but everything else is there.
        dchest 9y ago
        Here's a simple example: - Eve has a repository, Alice and Bob have access to it. Eve goes on vacation and nobody commits to "master"/"trunk". - Alice makes a branch "alice-fixes" and creates commits on it. - Bob comes and creates a branch "bob-features" from some point from "alice-fixes". - Bob then merges "bob-features" into "master" and deletes it. - Alice gets fired and her branch is deleted without merging. In git, you can't see that some of the commits in the history came from "alice-fixes". Fossil, on the other keeps track of branch names and _changes_ in commits: When Alice created her branch: -trunk +alice-fixes When Bob created his branch: -alice-fixes +blob-features When Bob merges his branch: -bob-features +trunk https://imgur.com/a/yRxAD https://imgur.com/a/yRxAD You can't delete this information, because it's recorded in the commit artifacts. You can't delete branches — you can only close and hide them (you can also apply edits to commits by adding "edit" artifacts [don't remember what the are called], but the history is preserved, not modified.)
        mbell 9y ago
        I think that is just an example of losing the branch name, the commit history is the same in both cases. If you really want that behavior from git, you can have it, just create a tag for each branch HEAD. Actually I think this is all that fossil does as well.
        dchest 9y ago
        It's not the same, there's no commit indicating that Bob branched off Alice's branch. It appears as if the whole history before merging belongs to Bob's branch. There is such commit in Fossil. > If you really want that behavior from git, you can have it, just create a tag for each branch HEAD. Actually I think this is all that fossil does as well. Fossil has branch/tag name directly in the checkin manifest (I've linked to the document describing file format somewhere above.) Tag and branch names are embedded directly in the history, they are not separate references to commit hashes like in git.
mbell 9y ago
> or even the history of the branch That is not true. You get a branch diagram just like the fossil example in the OP.