10 ms·

Git does not track branch history. This makes review of historical branches tedious. This isn't true. It's just the Fossil example has a better UI tha

Git does not track branch history. This makes review of historical branches tedious. This isn't true. It's just the Fossil example has a better UI than their github example. Pop open gitk or anything with a nicer UI and you can easily follow branch history.

dchest 9y ago
Nope. A branch in git is just a pointer to the tip of the branch: $ cat .git/refs/heads/master 170ec1365f9fc0ca281e72e6789d1df281d168ae From it, you can infer the commit history which gitk shows, but if you delete the branch (and discard the reflog), it's gone. In Fossil, each check-in (commit) actually records the name of the branch it belongs to: http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wi...
- simcop2387 9y ago
  Don't even need to delete the branch, git reset <newcommit> will reset the branch to the given commit, throwing out whatever was there before. You may want to add --hard to that, depending on what you're doing.
- mbell 9y ago
  Commits in git can have multiple parents, aka 'merge commits'. Using them maintains the branch history.
  - 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.)
- hn_throwaway_99 9y ago
  Yeah, honestly, the other arguments didn't carry much weight with me, but this one I find really annoying. When I'm looking back at history that had a bunch of merges, I don't want to have to guess which branch was which before a merge. It also seems like such an easy thing to add - you can kind of hack it up by just adding the branch name to the commit message with a pre-commit hook, but it would be really nice if git just kept track of it for you.
  - chronial 9y ago
    > When I'm looking back at history that had a bunch of merges, I don't want to have to guess which branch was which before a merge. Merges in git actually have a "direction", i.e. git records which branch was merged into which. So that information is recorded.
    - dchest 9y ago
      It records which commits the commit came from, not which branch. merge /\ commit-hash1 commit-hash2 When branching, Fossil creates a branch commit with the branch name (similar to git tag object), and also records changes to branch name in commits.
    - lozenge 9y ago
      Except for fast forward merges, which I generally disable. (And pull should be set to ffonly)
      - chronial 9y ago
        Yeah, the git cli in its default settings is very hostile towards that information ^^. Pull actually works the wrong way around – it merges the remote branch into the local branch and then pushes that as the new remote branch. So if you follow the first parent, you land in the pullers local part and bypass everything he merged.
- occams_chainsaw 9y ago
  I can easily follow the history of long-deleted remote branches that I never had to begin with... you might need to pull it by ID instead of by name to get it locally, but you can still view the name, history, commits, diffs...
  - deleted 9y ago
    [deleted]
  - dchest 9y ago
    Again, that's not the same. Each commit in Fossil belongs to some branch, because its name and the fact of adding or removing a name is recorded directly in the commit artifact. In Git, branches are local references to commit (local in a sense that they are different for each repository instance, but can be synchronized). In Fossil, you can see which branch name the commit belongs to and if the parent commit had the same branch name or not; in Git branches are ephemeral entities which don't belong to commits, and once you delete the branch there's no way to know which name of the branch it belonged to. http://fossil-scm.org/index.html/doc/trunk/www/branching.wiki http://fossil-scm.org/index.html/doc/trunk/www/branching.wik... In fact, I'd say Subversion, Git, and Fossil call different things "branches". Note: I'm not saying that one way is superior to another, I'm just saying that Fossil does track branch history, but Git doesn't.
    - occams_chainsaw 9y ago
      i'm just not getting what you mean. if i delete a branch, i CAN still see the branch (and its name) the commits belonged to, even if i never had that branch locally.
      - dchest 9y ago
        You can't see its name, try it.
        occams_chainsaw 9y ago
        i absolutely can, though. i went through this recently, trying to get back to a commit from nearly a year ago in a repo i'd never touched before. the annoying part of getting it back was that you can't just do "checkout {name}" you have to do it by the SHA ID and then commit again by the original name, but before all that, you can 100% follow any since-deleted branch by its name. there's just a weird disconnect between viewing its history and having it directly in your hands again.

dchest 9y ago

Nope. A branch in git is just a pointer to the tip of the branch: $ cat .git/refs/heads/master 170ec1365f9fc0ca281e72e6789d1df281d168ae From it, you can infer the commit history which gitk shows, but if you delete the branch (and discard the reflog), it's gone. In Fossil, each check-in (commit) actually records the name of the branch it belongs to: http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wi...

simcop2387 9y ago
Don't even need to delete the branch, git reset <newcommit> will reset the branch to the given commit, throwing out whatever was there before. You may want to add --hard to that, depending on what you're doing.
mbell 9y ago
Commits in git can have multiple parents, aka 'merge commits'. Using them maintains the branch history.
- 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.)
hn_throwaway_99 9y ago
Yeah, honestly, the other arguments didn't carry much weight with me, but this one I find really annoying. When I'm looking back at history that had a bunch of merges, I don't want to have to guess which branch was which before a merge. It also seems like such an easy thing to add - you can kind of hack it up by just adding the branch name to the commit message with a pre-commit hook, but it would be really nice if git just kept track of it for you.
- chronial 9y ago
  > When I'm looking back at history that had a bunch of merges, I don't want to have to guess which branch was which before a merge. Merges in git actually have a "direction", i.e. git records which branch was merged into which. So that information is recorded.
  - dchest 9y ago
    It records which commits the commit came from, not which branch. merge /\ commit-hash1 commit-hash2 When branching, Fossil creates a branch commit with the branch name (similar to git tag object), and also records changes to branch name in commits.
  - lozenge 9y ago
    Except for fast forward merges, which I generally disable. (And pull should be set to ffonly)
    - chronial 9y ago
      Yeah, the git cli in its default settings is very hostile towards that information ^^. Pull actually works the wrong way around – it merges the remote branch into the local branch and then pushes that as the new remote branch. So if you follow the first parent, you land in the pullers local part and bypass everything he merged.
occams_chainsaw 9y ago
I can easily follow the history of long-deleted remote branches that I never had to begin with... you might need to pull it by ID instead of by name to get it locally, but you can still view the name, history, commits, diffs...
- deleted 9y ago
  [deleted]
- dchest 9y ago
  Again, that's not the same. Each commit in Fossil belongs to some branch, because its name and the fact of adding or removing a name is recorded directly in the commit artifact. In Git, branches are local references to commit (local in a sense that they are different for each repository instance, but can be synchronized). In Fossil, you can see which branch name the commit belongs to and if the parent commit had the same branch name or not; in Git branches are ephemeral entities which don't belong to commits, and once you delete the branch there's no way to know which name of the branch it belonged to. http://fossil-scm.org/index.html/doc/trunk/www/branching.wiki http://fossil-scm.org/index.html/doc/trunk/www/branching.wik... In fact, I'd say Subversion, Git, and Fossil call different things "branches". Note: I'm not saying that one way is superior to another, I'm just saying that Fossil does track branch history, but Git doesn't.
  - occams_chainsaw 9y ago
    i'm just not getting what you mean. if i delete a branch, i CAN still see the branch (and its name) the commits belonged to, even if i never had that branch locally.
    - dchest 9y ago
      You can't see its name, try it.
      - occams_chainsaw 9y ago
        i absolutely can, though. i went through this recently, trying to get back to a commit from nearly a year ago in a repo i'd never touched before. the annoying part of getting it back was that you can't just do "checkout {name}" you have to do it by the SHA ID and then commit again by the original name, but before all that, you can 100% follow any since-deleted branch by its name. there's just a weird disconnect between viewing its history and having it directly in your hands again.