Hacker News Reader

Comment by dchest | Hacker News Reader

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.wi...

View on HN

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.

> 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.

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.

Except for fast forward merges, which I generally disable. (And pull should be set to ffonly)

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.

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.

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...

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.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.

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.

You can't see its name, try it.

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.

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").

The default message is "Merge branch '<name>'"

:-)

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.

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.

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

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.

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

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.)

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.

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.

> or even the history of the branch

That is not true. You get a branch diagram just like the fossil example in the OP.

Reply on news.ycombinator.com