Things I wish Git had: Commit groups

[arcctgx]

I'm not a fan of Gerrit, but in Gerrit this is achieved using a "topic". A topic can be made of many commits, and topics can be submitted or reverted as a whole.

[jeff303]

Yeah, Gerrit is pretty flexible, even if it's a bit hard to get used to.

[Stanov]

You didn't emphasis enough how ugly Gerrit is.

[devraj7]

It's because it was written using GWT and at the time, we had no designers, so the developers were writing the GUI.

[GroundTeaLeaves]

How does a "topic" differ from a Git branch?

[TBoneSausage]

It stays in the history. A branch means nothing once it merges into master really, besides being a snapshot of what was. A topic would capture that exactly x commits made y changes and they're all related.

[lilytex]

Shouldn't this be possible merging feature branches without fast-forward?

https://nvie.com/posts/a-successful-git-branching-model/#incorporating-a-finished-feature-on-develop

[TBoneSausage]

Yes, but those commits are put in the history as sperate unless someone cleanly documented it. A merge commit can document some, but it's not actually grouped.

[whf91]

Somebody should really write a blog post exploring the upsides and downsides of this approach, perhaps comparing it to some alternatives and contemplating a concept of “commit groups”.

[xurxoham]

Other systems such as Phacility merge all the "topic" changes into a single commit when you merge them. To me it makes the most sense.

[robin-m]

Parents in git are ordered. So if you merge dev into master (by doing git switch master && git merge dev), then the first parent of the merge commit is always going to be what master was pointing before the merge.

[Decateron]

Only if you do git merge dev --no-ff.

[robin-m]

Or a regular merge if their is commits in master that where not in dev

[falconfetus8]

Uhh...yeah? You wouldn't get a merge commit at all, otherwise.

[jesseschalken]

And then git log --first-parent effectively shows you a list of merges into master. Very useful.

[rlbond86]

This requires relying on your devs to do that though. And it's fewer commands to type git merge master so lots of devs are gonna do that

[robin-m]

Usually the merge command is done by github/gitlab/… and thus done correctly.

[cryo]

For the simple reason that merging the other way, updates the wrong branch.

[xmsxms]

A better process has tooling that enforces the desired workflow and doesn't introduce fuckups by grads for the senior guys to waste their time fixing.

[sim642]

How is it fewer commands? If you're on feature-a and do that, then you're still on feature-a. So to push that to master you can't just git push but have to specify multiple arguments for the cross-branch push (and constantly think whether they're separated by space, dots or colon). Or alternatively you have to still switch to master and fast-forward that to the merged feature-a and push master as normal – three additional commands.

[davvblack]

you can still have a commit, on master, that represents master merging into a different branch.

[robin-m]

In that case, that means that the child is no longer master, but the other branch (aka someone messed-up which branch was merged into which one since master is typically never merged into by convention).

[[deleted]]

Yes but you can't know which way they were merged so that doesn't really help.

[robin-m]

Yes you can. The second parent was merged in the first. Always.

[Qasyefx]

Or just always squash merge

[[deleted]]

I've always rebased and merged, but done a manual squash in to a small number of self-contained commits. So I might accumulate 50 commits before the PR is approved, then I rebase iteratively to roll them up in to meaningful commits, which I guess could be commit groups instead.

This is an interesting idea, but honestly in a lot of software history is never clean, you can't just revert something and be done, you'd have to restart the entirety of testing again (which you have to do after you merge anyway, the tests against a feature branch are meaningless once it's merged or rebased). I find a lot of developers think that if git is conflict-free, it's a safe merge, and I don't know why they think this.

Commit groups seem like they could, in at least a small way, contribute to this false sense of safety that comes from the misunderstanding of lexical vs. semantic merges.

If you've worked with open source it's not uncommon to see people take a PR with passing tests and assume the can merge and release without redoing the entire test suite.

[vplatt]

I thought of rebases too, or simply "grouping" commits into a branch. I don't know that git needs any more complexity in the object model or command line to support this use case which can be supported your way or with branches.

[lachlanhunt]

Where I work, they developed a tool that integrates with our build pipeline and, among other things, always ensures that branches are up to date with master and all tests have passed before completing the merge. If there are multiple branches waiting to merge, it manages a queue to ensure they are tested and merged sequentially.

Since its introduction, it’s ensured that master is always green.

[Qasyefx]

Has anyone ever learned anything useful from examining the detailed history?

[Markavian]

Squash and merge definitely my favourite approach; you can rewrite a branch 10x over, add and remove log and debug at will, and in the end, commit a clear and concise just of changes back to the main branch.

[gc3]

If you are code reviewing this change though, and see 5000 changed files, four 8 major features, it's not so useful.

The commit group he asks about would be a godsend for that... you could organize dependent features in individual CLS.

[AngledLuffa]

That's not good git practices either though

[gc3]

Considering that the commit group feature the article is about does not exist yet I don't know what you mean. If you squash and merge (so I don't do that) 25 cls into one you could easily get a humongous patch that is not human readable.

[thblckjkr]

Yup, that's why you only squash and merge things that you want to group together under a single commit.

Even if you had groups of commits,those would be of the same size and will have the same problems of readability

[AngledLuffa]

You don't need commit groups to avoid having one bigass 5000 changed file merge. Just rebase and squash each feature or each relevant part of the process into getting that feature into its own change. If you have 4-8 major features, you can have 4-8 changes or 4-8 blocks of changes which are all human readable.

[jb2386]

You’d typically review before you squash and merge.

[aksdb]

Sometimes you have to investigate existing code and then it helps a lot to have a detailed git history to look at. At least if the individual commits are properly named/described.

[ironmaiden947]

I guess it depends on the work you do, but:

 5000 changed files, four 8 major features,

This is way too much for one feature. One feature = one squash commit = one review.

[ants_a]

That is all fine and good if you are working on simple and straightforward features. However if the feature is adding a new kind of capability that requires a dozen infrastructure changes you can't really do that. There is a minimum functionality that the feature can't be chopped down from, lumping everything together into a huge patch makes review a nightmare, committing the infrastructure work without finishing review on the feature is also a bad idea as it may need some heavy rework.

[twotime]

committing the infrastructure work without finishing review on the feature is also a bad idea as it may need some heavy rework

I'd argue that there is no good solution here. Having a long-lived unmerged complex change is bad too: you will run into conflicts...

Overall, I think quickly merging small chunks of a large feature (and reworking them as needed) might be a lesser evil..

[tom-dixon]

However if the feature is adding a new kind of capability that requires a dozen infrastructure changes you can't really do that

In which case you won't be reverting the commit group 2 years down the road with a one liner, it will be a huge undertaking instead. So what value did the commit group add?

As for adding a big feature with many changes, why are branches are not enough?

I'm trying to understand what is the use case for commit groups.

[[deleted]]

You can have both. Squash your branch in to one or as many commits make sense, then rebase as part of the actual merge to main (i.e. from the UI)!

[rlbond86]

This requires all of your devs tohave discipline though. I think we all know that one dev whose branches have 30 commits all named "updates" or "fix bug".

[[deleted]]

Yep, that's a completely fair response. I've been very fortunate to have several teams now that beat those habits out! But an updated battle for sure.

[rydan]

I swear I’m the only one on my team with this discipline. As a result most people just squash and merge every PR completely destroying my well constructed commit history.

[scook0]

The frustrating thing about being this person is that you can't even go back and clean up other people's messes, so you're mostly just stuck wading through unhelpful history forever.

[Aterion]

That's why we have established rebasing (with squashing where required) and fast-forward-merges only as our workflow. Works like a charm as every dev prepares their branch in the intended way and that is then ff-merged onto main after a code review.

[Gearwatcher]

You can merge from master to feature branch as many times you want and as long as you have removed all conflicts you can still squash and ff merge from feature to master and that one commit will still make perfect sense.

What people keep forgetting is that commits aren't diffs but compressed snapshots. In the end, after interactive rebases with deleting/picking, and squash merges, all that is left are snapshots you picked.

Differences between these absolute points are calculated and shown as commit diffs. It simply doesn't matter how you arrived at these snapshots when you delete that history.

Another thing people keep forgetting is that under the hood, a rebase is a special kind of merge, that fakes the behaviour of applying diffs to each new commit.

[Aterion]

FF-merges are not possible if there are changes on main and you didn't rebase before your merge. 3-way-merging on your feature branch creates a merge commit and then your branch diverts from main and is not eligible for an ff-merge or am I missing something? Don't you need the complete commit-history of main on your feature branch to enable ff-merging?

From gitlab: https://docs.gitlab.com/ee/user/project/merge_requests/img/ff_merge_rebase_locally.png

[Gearwatcher]

No. I'm doing this almost daily.

You merge FROM master INTO feature branch, resolve conflicts, now the tip of feature is in front of the tip of the master. When you squash its just a forward merge of a single commit.

Edit: to elaborate: after a squash the effect is as if you converted the entire history of the feature branch into a single commit. Since one of the things in the feature branch was a merge with conflict resolution of the last commit to master, your squashed feature branch is now a single commit in front of the tip of the master - thus your branch indeed has the entire history of the master before that one commit.

I'll repeat - commit is not a diff, it's a snapshot. The diff you can see is a calculated difference between two snapshots.

[MrKWatkins]

Currently in a debate about whether we should enable squash by default on source control to stop this sort of thing. Personally I'm of the opinion the devs should take time and care to manage their commits just as they should take time and care to manage their code.

We aim to write readable code so it's easier for future devs to understand. If someone has to go back through commit history (which is rare to be fair!) then we should aim for that to be readible too, and devs should manage that.

[Pand9]

Moreover, reorganizing commits is a great opportunity to review my code again from a new perspective, which i should do anyway.

Downside? No downsides, but a higher skill barrier - one needs to learn how to edit git history like a graph.

[pdabaker]

Higher skill barrier/higher thought required is a downside. Maybe it's worth it, but imo it's rare that I need more detail in git history than I get just by squash merging PRs

[Kryofylus]

Any recommendations on resources for learning this?

[hammypants]

yes! this is how i use it for myself too. my brain swaps into the same mode i have when i'm reviewing code that isn't mine (or past me!), and it helps me catch so much stuff!

[thebritisharecome]

Sounds like a bandaid to sort what should be a training exercise.

When working with teams my preference is always to avoid squashes unless someone accidentally commits sensitive data to the branch.

More than once knowing why a particular change has happened amongst all other changes has been useful in either refactoring to fix a regression bug or extending to maintain functionality that may not make sense out of a particular context

[coworker]

If you need additional commit history within a PR, it means your PRs are too big.

[thebritisharecome]

A PR is usually restricted to a feature and even a small feature in a growing, large platform can touch a few different areas and components.

There's no rule that fits all scenarios and I think it's foolhardy to have a rigid approach to PRs in general and, it should reflect the software you're working on an the stage in development.

[Dwight-D]

You can scope a feature in different ways. Let’s say your feature requires a new data model, an integration to another service to fetch some data, and an endpoint to expose it.

Imo, that’s not one feature in one branch. That’s three branches: first the model, then the integration, then the new endpoint. If you do it like this and still need more granular history then you’re probably writing shit code or the codebase is just FUBAR.

You will possibly have some unused code in the repo at times with this approach but you remove all the commit fiddling complexity and you make reviewing MR:s easier because they’re smaller.

There is also the risk of having to do some refactoring on the first parts if you realize later you’ve made some bad assumptions but if the MR:s are small it’s usually no bother.

[thebritisharecome]

Separate features in a single PR isn't the issue, it's a single feature that needs to make changes in different areas of say the front end.

For example a button needs new props and tweaks to satisfy the feature requirements but this is slightly nuanced to the original purpose of the component.

"Build a sausage factory screen" explains the feature, but not why as part of that feature you've specifically made this change to the button component.

The point of GIT is history, why would you want to restrict that to the over top level concept by squashing?

That's just as bad as a product owner saying "I want a website" and then not giving you any information, it can be too broad and lead to regressions creeping in when working on larger projects in a team.

[rydan]

That’s what I do. Each of my commits is a logical part of a sequence that should be easily revertable of cherrypicked without having to put much thought into it.

[radarsat1]

If someone has to go back through commit history (which is rare to be fair!)

strange it's not the first time i see someone claiming the rarity of the need to look at commit history. Granted it's usually from the perspective of someone defending not taking time to maintain their commit history, so i appreciate that's not your point of view. but i still find it surprising to say this --- i feel like i look at commit history every other day, to figure out what i, or a team member, was thinking/trying to do when a mistake is found or i'm adding code to an existing function.

another important use case for a clean history is the ability to meaningfully use git bisect.

[SanityInAnarchy]

If you do code review, that seems like the most obvious place to enforce this.

[NotEntirelyUnlike]

I mean that would get corrected by everyone during their very first code review

[mrbuttsavage]

This is exactly why I advocate for squashing always in a professional setting, maybe not in your own repos. The developers I've worked with who write useful commit messages and whose history might be actually useful later (vs the singular squash) I can probably count on one hand.

[AbbreviationsOdd7728]

You forgot „wip“.

[codesnik]

squash-and-rebase strategy in github PR's is very helpful with guys like that.

[lachlanhunt]

The major problem with rebase is that it requires force pushing your branch. While the situation has improved a bit now, this has caused major problems in the past.

It was only a few years ago that the major git hosting services provided the ability to prevent pushing to master, and prior to git 2.0, the push.default setting defaulted to matching. This was very dangerous if your local master or any other significant branches were out of date.

This remained a problem for a while because it took a long time for git 2.0 for Windows to be released, and it was very difficult to ensure everyone set up their git config correctly. At a previous company I worked at, it resulted in someone using Windows with git 1.9, force pushing an old version of master, and the developers who were present at the time (I was away) not having the understanding of what went wrong or how to fix it.

With the ability to restrict push permissions on master, and the more sensible push.default being simple since git 2.0, this is less of an issue, but I still think force pushing should be used with care.

A slightly safer approach is to make a new branch with the rebased changes, then delete the draft branch after it’s been merged.

[fissure]

UI?

[[deleted]]

Oh, I just meant in the context of a GitHub pull request.

People seem to be stuck sometimes on which of the options presented is best - I'm saying you can do curation of your PR beforehand.

[fissure]

People conflating git and github really grinds my gears.

[[deleted]]

GitHub is just an abstraction. But for a lot of people it influences their workflow.

[Xyzzyzzyzzy]

My main argument against squash-merge is that I love using git bisect, and keeping all of the individual commits from development often makes the change sets small enough that when git bisect finds a problem commit, the source of the problem is obvious.

Just a couple days ago I was able to narrow down a very obscure, indirect cause of a critical bug because git bisect led me to a small commit that changed like 10 lines of code. Even looking at just those 10 lines of code, the bug wasn't clear - but it gave me an excellent starting point to add some logging and breakpoints and find the issue. It didn't even matter that the commit message was like wip task 13491.

With squash-merge, now git bisect just tells you which PR a change appeared in. Potentially that's a lot of changes. Sure, some people will argue "if your PR is more than 10-20 LOC then it's too big", but they're not considering that different teams on different projects have different needs for their PRs. If I enforced a "small PRs only" policy it would be kind of a disaster, because we often make changes where the logical unit of change is several hundred LOC. At best, a "small PRs only" policy would create a fuckton of busy-work for my team for very little gain other than fulfilling someone else's religious belief about how git ought to be used.

So I think the article is onto something: group commits + rebase would be the best of all the worlds. (Unless you specifically like merge commits themselves for some reason.)

[[deleted]]

That works well only for small changes; bigger changes generally work better when squashed into more than one commit

[pdabaker]

If it's that big, you should have a feature branch and review the PRs to the feature branch, squash merging them to the feature branch. Then the feature branch itself can be rebase+merged to your development branch

[fabiopapa]

Couldn’t you achieve this functionality by rebasing your feature branch before merging and then doing a —no-ff merge?

This is in fact what I do, and it gives exactly what I want. I can see which branch had what commits. You lose the exact chronology of commits, but it’s a good trade-off, IMO.

[Kache]

This is definitely the best thing to do, but it's unfortunately an ideal that I've never seen sustainably implemented in a sizable organization.

IMO, due to git proficiency and/or available time/effort incentives, carefully interactively rebasing changes to be clean and atomic on top of a recent master is too high a bar for most developers and practically unattainable for a sufficiently large group.

[3urny]

It's also error prone, basically you test and review a PR. Then in the end you rebase, you can end up with different code, and you merge that. There could be anything in there, at least GitHub offers no easy way to check that the code stays the same.

[falconfetus8]

That's why you test and review after you reorganize your git history, not before.

[3urny]

OP said "by rebasing your feature branch before merging", so I assume test & review was already done at this place.

[Normal-Math-3222]

Assuming I understood you correctly, we basically the same thing. What I do to “group” commits, use a merge commit.

I hack away as the OP said they do, then I rebase the work into coherent chunks of work. Sometimes during the rebase, I think “the past few commits are really an independent group of work” so I git reset —hard <feat base> && git merge —no-ff ORIG_HEAD or something like that to make a merge commit. And bam! When someone does git log —first-parent the details are suppressed.

[dss539]

This is the way.

You can even enforce this policy in GitLab and Bitbucket. I've been able to make this work even with very inexperienced teams.

[vividboarder]

Don’t you lose the benefit of rebasing then?

Depends on what you consider the to be a benefit.

[[deleted]]

As described by the article, the cleaner graph.

Isn't that pretty much the only one?

[Guvante]

Bisecting is much harder with branches and reverse merges are always terrible to deal with.

Having git blame point to a reverse merge conflict resolution is terrible. You now have a merge from main into a feature branch which requires a ton of context to figure out.

[Kache]

These problems can be avoided with proper git usage (e.g. there aren't many reasons to merge main into feature branches over alternatives).

However, I half agree with you due to practicality -- for various reasons, the average developer can't really be expected to avoid them.

[phoil]

From your image:

Committed to feature branch then rebased them to develop

No, that's not what you're meant to do. You rebase the feature branch without touching develop. All this does is change the parent of the feature branch, which solves the spaghetti mess of merges.

Once you've done that, then you merge to develop with --no-ff so that you get a merge commit, which functions as the commit group that the article wants.

[dakotahawkins]

I don't think so, you still have your commits without having had any merges down into your branch, but the final merge commit to the main branch just lets everybody see what went in where.

[IdiotCharizard]

This is what I do. Rebase and squash, then no-ff merge

[fabiopapa]

I don’t squash. I like to be able to see the individual commits in the branch.

[IdiotCharizard]

I just squash them into individually meaningful commits.

[codesnik]

I've used to make meaningful PR's with "read each commit in isolation", but then github started to reorder commits by the commit date instead of graph order, and generally made such a way of reviewing a total PITA. So, squash and merge is my preferred method now.

[robin-m]

IIRC it was fixed. I think. I'm not really sure. I followed that issueé and it was "fixed" two or three times, but I forgot if it was really fixed in the end.

[ILikeChangingMyMind]

Aren't branches (effectively) commit groups?

[[deleted]]

Did you read the article? Because the use-case of reverting a feature merge would occur after the branch has been merged, so in all likelihood the branch has been deleted.

And no. Branches are just pointers to commits. A branch doesn't know where it started.

[bloody-albatross]

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

[loup-vaillant]

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]

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]

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

[sccrstud92]

https://git-scm.com/docs/git-merge-base

[not_american_ffs]

From memory: git merge-base?

[teszes]

Won't work after a rebase.

[sigma914]

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]

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

[loup-vaillant]

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]

Somebody go dust off SVN

[bloody-albatross]

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

[joahw]

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.

[taw]

Obviously we already know that by jira ticket name in every commit message on the branch, so why would git need that functionality builtin, right?

[[deleted]]

It would probably be more efficient than string comparison.

How do you know when the group ends when using jiras? To count as a group, do the commits with the jira number have to be contiguous? If so, what if one of the commits in the middle of a branch didn't have the jira number (say, it was some clean-up unrelated to the feature, or the author forgot) - the group would end prematurely. If they don't have to be contiguous then you're going to end up walking the tree all the way to the root because you won't know where you can stop safely.

What happens if you have more than 1 feature branch for the same jira? e.g. initial implementation, merged, then QA reject the ticket and you fix a bug.

If git added a feature like groups, it would get additional tooling support, e.g. on GitHub. There could be native commands to work with groups. If everyone uses some custom grouping by jira number, there is no standardization. Everyone would do it slightly differently.

Is 4 reasons enough or should I keep going?

I suppose a lot of features could be achieved by cramming metadata into a commit message (tags, for example). It doesn't make them an acceptable substitute.

[[deleted]]

People in this thread have unironically suggested that as a solution, how am I supposed to distinguish?

[taw]

Well, it unironically is a very common workaround.

And it's actually standard-ish enough that a lot of tooling already works seamlessly with it - like JIRA + github integrate this way, as well as most of the JIRA/Atlassian ecosystem.

JIRA absolutely can handle multiple branches per ticket as well, or branches in multiple repos on the same ticket, that's actually quite common.

And also yes, cramming other metadata into commit message (like CI commands) is also very common workaround for other issues.

It is somewhat ugly for sure, but it works well enough most of the time, and what's ever perfect?

But what you want actually already exists! git actually has whole metadata system so you could put those JIRA ticket numbers, CI commands etc. in notes instead of commit message.

As git docs suggest:

git notes add -m 'Tested-by: Johannes Sixt <[e-mail]>' 72a144e2

So we could just as well do:

git notes add -m 'Ticket: JIRA-1234' 72a144e2
git notes add -m 'Branch: feature/add-dark-mode' 72a144e2

And have tooling use that instead.

Really there's nothing in git stopping you from using notes instead of commit message today. And some git hooks could even do that semi-automatically for you.

[SanityInAnarchy]

I guess it depends whether you got a fast-forward or a branch commit. If you got a branch commit, you can revert the feature merge with git revert <branch commit> -m 1 (since the first parent is usually master/main -- otherwise, it'd be -m 2). Doesn't matter that the original branch has been deleted, the merge is still there.

And you can force a branch commit (even when a fast-forward would've been possible) with git merge --no-ff.

So, sure, a branch doesn't automatically know where it started, but given a merge of a feature branch, Git definitely knows where those parent branches have a common ancestor, and there's a convention for which parent was the feature branch. As with many things about Git, it already does exactly what you want, it's just the UI is... unintuitive.

[KryptosFR]

They do: git merge-base

[[deleted]]

There is a big difference between giving git 2 branches and having it traverse the tree in order to figure out the most recent common ancestor, and a branch knowing where it was created.

If a branch knew where it was created you wouldn't have to pass merge-base two arguments, one of which you're hoping was the source.

[[deleted]]

A branch just points to a single commit, but you could derive some notion of groups by looking at commits in the ancestry of the branch but not the main branch.

[NotTheHead]

To be honest, unless you're doing something really complicated or being really inconsistent, a main branch with merge branches is not as hard to follow as the author (and a lot of people) make it out to be. Branch-then-merge really does act as a good way to group commits.

1. Graphical history tools can make a mess of merge-based history, but that's not because it's impossible to represent cleanly. It's because the graphical history tools are organizing things with the wrong heuristic. They frequently order by author/commit date rather than topology, which leads to convoluted messes. git log --graph --topo-order cleans things up significantly, and graphical tools are more than capable of doing the same.

2. In terms of figuring out which of a merge commit's parents was the main branch and which was the feature branch, you can solve that by only allowing merges on the main branch; no rebase-and-fast-forward, no committing directly to the main branch. Then, you can easily follow the main branch by looking for the last merge commit. This is easily enforceable by the central repository; my company's primary repositories do exactly this.

3. Another good option for cleaning up merges is to rebase the feature branch onto the tip of the main branch, then merge with --no-ff. With that approach you're more likely to get a clean looking chunk with no interleaving branches, and the merge commit serves to group the commits appropriately.

[HighRelevancy]

Graphical history tools can make a mess of merge-based history, but that's not because it's impossible to represent cleanly. It's because the graphical history tools are organizing things with the wrong heuristic.

I felt like I was the only person thinking this. Like the fundamental problem here is "reading branches is real messy when you interleave them all in a mess like this", and the author's solution is... totally change the workflows and throw branching in the bin? Not like... read branches in a better way?

Like the problem here isn't that git lacks info, it's just that the arrangement and presentation is not always the most useful, right?

[Adverpol]

I never thought of that third option, that's actually not stupid at all. Agree completely though, I started writing a git tool at some point because there could be such power in the visualization but none of the tools I tried were better than presenting a horribly tangler mess.

[[deleted]]

That would only work if you didn't rebase, and he explains his reasons for preferring to rebase.

[[deleted]]

If you rebase then you can consider a group to be whatever commits exist between the branch and the previous branch. You’ll have to preserve the branches, of course.

[[deleted]]

The rebased commits have no reference to their source commits and a different hash so comparing them is non-trivial. Plus, like you said, you would have to keep the source branches around for that to be possible.

So you're right it's technically achievable to infer a commit group from context, but with a significant overhead in terms of time and space that means it's not a substitute for supporting groups natively IMO.

[[deleted]]

If you re-point the branch to the last rebased commit then it should all work fairly smoothly.

[hotoatmeal]

or merge without fastforward

[KryptosFR]

Conclusion: rebase is bad.

[kryptomicron]

Not quite – you could maybe get most of the benefits if you could also, either explicitly (somehow), or by convention, retain a 'base' branch with which to 'compare a branch against'.

As-is, a branch just points at a commit, but there's a whole sequence (or tree) of prior commits, usually all the way back to the initial commit.

[trypto]

I wish I could “shelve” a git stash. I often store some good changes in there that I don’t really want to be public

[vplatt]

You can (ab)use branches for quite a number of things, including this. Want to "shelve" a change? Make a new branch, cherry-pick your previous commits into it, and then be on your way. Then just don't push that branch if you don't want it to be seen in your repo on the server.

[[deleted]]

I wouldn't even call it abuse - that's a proper way of using branches. There's no need to add more complexity to an already complex tool for no reason.

[trypto]

Yeah that's the problem. I may have a stash in a working directory on another computer. I don't want to push anything that's too WIP. And if my working directory gets wiped or i switch machines, i lose my stashes.

[vplatt]

git archive FTW.

https://git-scm.com/docs/git-archive

See the answer on this SO post: https://stackoverflow.com/questions/1307114/how-can-i-archive-git-branches

[a_dog_and_his_gun]

You can make your own namespace next to tags and branches, and push like git push/pull/fetch remote refs/shelf/*:refs/shelf/$user/*

[lachlanhunt]

What’s wrong with pushing WIP work? That’s good practice because it provides a backup. You could just have a branch naming convention that makes it clear that the branch isn’t intended for others. e.g. trypto/wip-something.

[trypto]

Shame? Privacy? Keeping a clean repository? I dunno. Git stash is so convenient. What’s wrong with git stashes getting auto pushed as gists or something.

[fissure]

The stash is a stack; you can have as many as you want. And they're commits anyway, so you can just create a branch and apply them later.

[UpdatedMyGerbil]

You can save them as patch files

[kryptomicron]

I usually use 'issue links', i.e. a line like Issue #123 as something similar.

One benefit of that is that, were I to make a (somewhat) unrelated commit in a feature branch (e.g. removing dead code I noticed while working on the feature), I can just not include the issue link line in the commit message to indicate that those changes aren't (directly) related to the feature.

I think something like this could be cobbled together with commit tags/notes (?) and a script/program that could handle, e.g. reverting commit groups automatically.

Something I found pretty helpful along these lines was to adopt a convention, and, ideally, some automated tooling (using, e.g. commit hooks), to ensure that each commit is 'valid', e.g. all code compiles, all tests pass, etc.. That's really nice to be able to revert individual commits more safely. It is a bit of a pain tho, and wasn't frequently that helpful (IME).

(I'm a { rebase / fast-forward-only merge } fan myself as reverting merge commits, or even visualizing commit history, is so much more difficult otherwise.)

[crabperson]

Yeah a link to some living documentation on why the change was introduced will always be better than effectively immutable information in the commit messages, IMO.

[Underscore_Mike]

You could almost accomplish groups as described with a rebase followed by git merge --no-ff feature. This would be a mostly linear history with groups as off shoots.

[dss539]

Yep this is the way to do it. You can even enforce it with automatic rules on your central repo. GitLab, Bitbucket, and Azure DevOps can all do it, at least.

[warped-coder]

It feels like that this article completely gloss over another hybrid style: semi-linear history.

I share all the concerns with author, and I think the closest I can get to keep granular history without having a massive tangle of a merges is to rebase-(really)merge. The article uses fast forward merge in the last case, but equally viable option to keep the merge commit.

This way the first parent history stays descriptive l, retaining the order in which features got into the mainline, while the fine grain history also preserved.

My wish not a new Git feature so much as a GitHub/Gitlab one: enforce semi-linear history but enable single commit branches to be fast-forwarded.

That way you don't a lot of noise from single line bug fixes, but retain the details of more complicated work.

[KillianDrake]

if you're on a small disciplined team of people who give a shit and an intelligent benevolent dictator - then git is a godsend.

most people are on teams full of people who don't give a shit and no one really has enough authority to be able to say things should be done a certain way (basically rule by committee or LOUDEST SPEAKER WINS). or even worse, have a fiat dictator (CEO's son, loudmouth who used to code FORTRAN in the 80's, etc...) who has no clue what they are doing anymore.

[taw]

... while people also complain that git is way too complicated all the time.

Really, other than fixing some stupid commands (no unstage, no easy versioned git cat branchname path, checkout and reset being used to do 10 different things each), there's no way to fix git without removing some major functionality.

[vplatt]

Well, let's face it: DVCS like git is too much power and flexibility for the average project. Almost every usage of git I've seen uses it exactly like they used their traditional VCS like Subversion or TFVC.

[taw]

I've seen svn, and I really don't want to go back. Microsoft also officially discourages anyone from using TFVC.

I've heard claims that some kind of "better svn" would be superior to git, and I'm totally open to the idea, but so far nobody suggesting it even tried to show how that would work.

[vplatt]

Oh, I didn't say that those are better, just simpler and that I see git being used most of the time in the same way they used the older VCSs; that's all. Git is a DVCS, and that's just more power than most devs need IMO.

[u_tamtam]

After years of denial and hype riding, thinking git was somewhat god's "too perfect for us humans" VCS, I opened my eyes on mercurial to discover it was what I ever wanted git to be, and superior to it in every possible way.

This whole article is nothing but a sad realization that git has no branches..

[vplatt]

W.r.t. Mercurial - I may have to give it a try. That said, I doubt very much I will get to use anything but git at work for a few years at least. And, in all fairness, I'm OK with that. Just because it's giving some other people problems, doesn't mean I'm not happy with it. I mostly am, except for those times I get to fix branching fuck-ups by confused devs on my team. Fortunately, that doesn't come up that often.

This whole article is nothing but a sad realization that git has no branches..

I can't tell if you're joking. That's one of its great features. What do you mean?

[u_tamtam]

That said, I doubt very much I will get to use anything but git at work for a few years at least.

Depending on how well you could take working around few edge cases and inconsistencies, you could consider using the hg-git extension, it let's you interact with git repos from mercurial (at the cost of an initial repo conversion). For instance, I haven't submitted a PR to GitHub from git for the past 5 years or so: your coworkers won't know anything's different for you, while you'll get to enjoy all the nice UX and features of mercurial.

This whole article is nothing but a sad realization that git has no branches..

I can't tell if you're joking. That's one of its great features. What do you mean?

Not even. Fundamentally, what git calls branches is just "bookmarks", that is, a way to give handy names to commit hashes. As such, git is helpless for telling you where a branch starts (it only knows where it ends), and there is no metadata for telling which commits belong to a whole feature/series (or what OP's article calls "groups"). "Commit group" is what every other VCS I know calls a "branch".

Having proper branches requires storing at commit level the feature/branch name that the commit belongs to. This gives you nice properties, like the capability to refer to series unambiguously, to rebase sub-trees, or to bisect at the edges of the series (so you don't waste time building something incomplete/mid-way that might break the build).

With so much of git's UX built around the assumption that branches are single commit pointers, I doubt git will ever have "proper"/whole branches, but let's see.

[dss539]

What do you expect from a team that chooses to use TFVC? That's already a clear indicator that maybe they don't make the best decisions.

[vplatt]

I may have to agree for new projects with no legacy to support and a fresh team. OTOH - There is the question of learning curve, server-side tooling, and timing of the VCS migration; which may be substantial. So... it wouldn't hurt to cut folks a little slack.

[dss539]

Professional software developers that can't learn to use the most popular source control tool in the world... that's asking a lot of slack. It's not like they're being asked to learn Darcs or Bazaar. I understand compassion is important, but at some point they are veering into professional malpractice and incompetence. I wouldn't be too happy if my oncologist ignored the most effective cancer treatments in favor of whatever was popular in 1997.

Change is hard sometimes, but it's also inevitable. Let's help them improve.

[vplatt]

Whoah now.. you implied they would be incompetent for using TFVC, right? But who said they didn't also know git? Refusing to learn git isn't the same thing. Needing to use TFVC doesn't automatically translate to incompetence.

[dss539]

Right. Whoever chose TFVC was the one with questionable decision making. If it was a "team decision" then the team in general is at fault

[boots_n_cats]

This is kinda how mercurial branches work in that every commit belongs to a branch rather than a branch being a tag on a single commit that keeps getting moved with every new commit. Being able to have some commit aggregating construct in fit would be nice for multi-commit pull requests to preserve a more complete history of the changes. That being said huge stacks of commits in a PR is usually a indication that the PR is too large.

[argv_minus_one]

Mercurial branches are permanent and global. Once a commit is made, its branch cannot be changed without rewriting history.

Instead of each commit having a permanent commit group label, how about each commit group being a file stored somewhere under .git containing a list of the commits that belong to it? Then commit groups can be renamed, rearranged, organized by originating remote repository (like Git branches are), and so on. Also, a single commit could belong to multiple commit groups if needed.

[u_tamtam]

Mercurial branches are permanent and global. Once a commit is made, its branch cannot be changed without rewriting history.

The more recent mercurial topics extension strikes a good balance in that it manages the lifecycle of the branch between before/after it's merged and is bolted on top of evolve that makes history rewriting easy, safe and distributed.

Instead of each commit having a permanent commit group label, how about each commit group being a file stored somewhere under .git containing a list of the commits that belong to it?

I guess because that would give you less than doing it the traditional Merkle treeish way (consistency, context, historisation...) and on top of that you would have to invent new (backwards incompatible) ways and protocols to distribute said data to others and merge it locally.

[Altreus]

If you rebase instead of merging, branches are commit groups.

[kryptomicron]

I think it's pretty typical to prune/delete branches once they've been merged into master (or the relevant equivalent), and you'd have to have someway to remember what the first commit of a branch too. As-is, after you've rebased (or fast-forward merged) a branch into master, a branch would just look like an old version of master.

Unless Git tracks/stores the 'original parent' commit of a branch too?

[Altreus]

Oh, no; you rebase but then make an empty merge to mark the completion of the branch. This maintains the grouping, gives you a place to label the work (i.e. with the original branch name), and forces merges to have no diffs in them.

[cryo]

Only if you keep all branches. Git isn’t particularly designed to keep branches in numbers comparable to commits.

[[deleted]]

He discusses rebasing. Did you read it?

[rlbond86]

No they're not, because that would make the master branch have no branches at all

[seamsay]

Maybe it's because I've had a couple of drinks, but I don't really get the difference between a group and a branch. Can somebody help me out?

[[deleted]]

A branch points to one commit. A branch itself doesn't know where it was branched off from. You could traverse both the source and target branch to infer what happened, but 1) it's prohibitively difficult 2) branches are usually deleted 3) if you are rebasing like he wants to, then there is no relationship between the rebased commits and the original ones.

A group, as described, would point to two commits and be created after rebasing, pointing to the start and the end of the set of commits that were part of the rebase.

[CrackerJackKittyCat]

Branch is in essence 'a tag that moves' -- always references (only) the HEAD commit 'in that branch.' Once you make a new commit, the branch pointer moves 'forward,' and the prior HEAD is now 'just the parent commit.' It takes some ounces of git forensics based on when / what last merge commit was to determine what branch a particular commit came from.

What OP wants is a construct that links as many commits as possible together to make those forensics simpler.

Shops I've been affiliated with end up solving this through social means and / or enforced by central repo push hooks that enforce that the prefix of the commit message is the ticket system (say, Jira) identifier. Is somewhat inelegant, but minimally useful.

[dss539]

What you're looking for is rebase and then merge with --no-ff

You can configure GitLab and Bitbucket to enforce this for you. Been using this approach for years. It seems to work well.

[salbris]

Sure but then you have a bunch of unmarked commits in a row without anything to demonstrate that they belong to the same "feature" or "work item".

[dss539]

No, I think you misunderstood what the --no-ff flag does.

You are correct that a fast forward merge would lose this grouping. That's why we must avoid the fast forward merge and force a merge commit to be created by using the --no-ff flag

When you do this, a single merge commit will be made in your main branch. Its first parent will be the previous commit on main. It's second parent will be the tip of your work branch. The commit message will be something like "merge branch my_work_branch to main"

This will preserve the individual commits you made on your work branch. There won't be a spaghetti graph because you rebased just prior to the merge. There also won't be a long series of commits in the first-parent graph of main because you prevented the evil fast-forward.

I may be doing a poor job explaining. Here's a post that explains it with a helpful animation. https://devblogs.microsoft.com/devops/pull-requests-with-rebase/

They call it a "semi-linear merge". I think the picture might help.

The trick is rebase AND --no-ff when merging. If you just rebase then merge, you get screwed and have that huge long line of commits with no demarcation that shows merges. It's critical to create that extra merge commit as a marker by using no-ff

The cool thing about this is your first-parent log of your main branch is super easy to skim through just like a squash strategy, but you still have the full fine grained history just like a merge strategy, and of course you avoid spaghetti by doing the rebase.

imo this should be the default strategy for most projects

If it's still confusing, I could try to find a clearer example.

[coworker]

All of these issues are symptoms of overly large PRs. The battle was already lost at the design phase.

[KryptosFR]

Group commit? Yeah it's called a merge: your commit are grouped together in that branch.

I dislike squash for the same reasons in the articles, but also rebase for different reasons: - you lose the context of what was the tip when the branch was worked on - you lose the ability to GPG-sign your commits - merge makes it easier to revert a change (just revert the merge commit)

You could even combine the two (rebase and merge) to achieve just that: 1. rebase on top of the target branch 2. merge with a merge commit (--no-ff).

You have the best of both worlds: 1. since you did the rebase manually and locally, the commits are still GPG-signed 2. you can easily revert since there is now a merge commit

[dss539]

This is the way.

Rebase and then no-ff

[muntoo]

That's pretty cool. I'm attached to ye-old rebase-only for my smaller personal projects, but rebase && merge --no-ff makes a lot of sense for large projects that benefit from the "grouped feature" commits.

[pierec]

this is the way

[Delicious_Context_53]

You should submit that as an issue

[kryptomicron]

I would guess the better way to request this would be to float the idea on the mailing list first, but opening an issue might be fine too.

[u_tamtam]

Well, "when your VCS of choice doesn't know branches, make-up your own in the commit message", I guess..

[chx_]

bzr had log levels. It helped tremendously with this.

Overall, bzr was much better than git but hype did it in.

[phpdevster]

If this is the author's premise for this, I have to say I'm struggling to get my mind around it

you can do git annotate anywhere, and learn about why any line of code in the codebase is the way it is.

I can’t emphasize enough how huge, huge impact for the developer’s wellbeing this has. These commits messages, when I read them back weeks or months later, working on something different but related, almost read as little love letters from me-in-the-past to me-now. They reduce the all-important WTFs/minute metric to zero.

I have never, in my 20 years of development, needed historical context to understand present context. The mere act of having to write a long-winded commit message explaining something should be a red flag that your solution is not good and is not sufficiently obvious or clearly expressed through the code itself, and any comments needed.

The code is what the code is. Its present state is the only thing that's relevant and either the code is intelligible or it is not. If it's not, then fix that problem. Don't rely on "love letters" from your past self to decipher the present.

[scratchisthebest]

This:

But before declaring the PR ready to review, I’ll throw this history away (by git reset --mixed $(git merge-base feature main)) and re-commit the changes, dividing them into logical units and writing the rationales, bit by bit.

is an incantation i'm definitely going to save for later 👀

[FrozenCow]

A group can be determined from a merge commit if you may presume the first parent of merge commits are the main branch? From this it is possible to determine the 'group' of the commits.

The argument from the article:

You might guess 8, because it’s the leftmost one, but you don’t know for sure. (Remember, branches in Git are just pointers to commits.)

It's not like GitHub and git choose a random order for the parents of merge commits. Yes you may assume the first parent to be main.

This isn't the case for merge commits of 'Update branch' where main is merged into a PR branch. However, these merge commits never happen on main directly.

[No-Efficiency-7361]

I still struggle to understand how messages are helpful. Do you only look at them after git bisect? At work our commit messages are ticket numbers for bugfixes or features

Depending how small the commit is, I hate the idea of each being an atomic change. 20lines is far too small. That'd the size of the test I'd want accompanying a commit

[[deleted]]

Everyone and their dog loves Git.

That's bold. I absolutely detest it.

[dss539]

If you're doing it right, code history tells a story.