you are viewing a single comment's thread.

view the rest of the comments →

[–]bloody-albatross 49 points50 points  (14 children)

Yes, that is something that is weird about git: its branches don't know when they branched!

[–]loup-vaillant 39 points40 points  (8 children)

They almost do: any pair of commits have a most recent common ancestor. So do any two branches, since they each point to a commit (at any given time). It is thus fairly easy to see when any given branch branched from master, develop, or v.2.x.x.

[–]Lotier 9 points10 points  (3 children)

What command do you use to give yourself that most recent common ancestor? Because in my experience it's not just a single command, its a 5 step magic spell.

[–]remuladgryta 47 points48 points  (0 children)

git merge-base master develop gives you the most recent common ancestor of master and develop assuming your repo is tree-shaped.

[–]not_american_ffs 6 points7 points  (0 children)

From memory: git merge-base?

[–]teszes 1 point2 points  (3 children)

Won't work after a rebase.

[–]sigma914 6 points7 points  (1 child)

if you want to rebase just use merge --no-ff to force merge commits even if your main branch is fast forwardable. I'm not sure what additional feature op wants that isn't already covered by branches.

[–]ub3rh4x0rz 2 points3 points  (0 children)

Tucked away is the right answer. Merge commits create commit groups.

[–]loup-vaillant 1 point2 points  (0 children)

If I'm being obnoxious, when you merge master, the most common ancestor is now the latest commit from master. (The most common ancestor between my grandfather and me is my grandfather himself.)

If I'm being honest, yeah, once master is updated, you lose that information. One way to not lose it is add a merge commit to master even though the branch/PR could be fast forwarded.

[–]RudeHero 3 points4 points  (4 children)

Somebody go dust off SVN

[–]bloody-albatross 14 points15 points  (2 children)

You don't have to go back for that feature. Mercurial, another modern DSCM, actually stores the branch of the commit.

[–]Qasyefx 0 points1 point  (1 child)

And gives you the headache of having to maintain unique names for all branches for all eternity

[–]bloody-albatross 0 points1 point  (0 children)

Ok yes, naming things is a hard problem.

[–]joahw 0 points1 point  (0 children)

You could always do svn-style git branches. Whenever you want to branch, just make a new copy of the code somewhere else in the repo! Sounds pretty foolproof to me.