3 ms·

I wish git had a builtin notion of two different types of commits: working commits and release commits. I really like making tiny, continuous commits as I work

I wish git had a builtin notion of two different types of commits: working commits and release commits. I really like making tiny, continuous commits as I work. It's a great flow. git-revert becomes a Ctrl-Z on steroids. I don't what to clutter up the "official" history, with all these tiny changes, many of which don't even compile. That breaks git-bissect and all kinds of other flows. So the only option is to squash commits. But there's something deeply uncomfortable and unsettling about permanently re-writing history. Plus, it's nice to have a history of those working commits as an artifact. If I'm trying to unpack the reason that I did something 9 months ago, then seeing a replay of the code changes is super-useful.

deleted 6y ago
[deleted]
IggleSniggle 6y ago
You could get this behavior pretty easily with a double merge: “main” which contains the squashed commits and “history” which contains all commits as well as “main” merged back in post-squash. I do see your point though. Edit: the only reason to merge “main” into “history” is to enforce convergence.
madhadron 6y ago
I go one step further and work entirely in get rebase -i where I build up a stack of tiny, incremental commits. This also lets me get small changes reviewed and committed on a nearly daily basis instead of building up days or weeks of work. I've been wishing for a git GUI that lets me drag hunks around such a stack so I don't have to keep moving them by hand.
amenghra 6y ago
You want this for git: https://www.mercurial-scm.org/wiki/GroupExtension https://www.mercurial-scm.org/wiki/GroupExtension
mpweiher 6y ago
> two different types of commits: working commits and release commits ?? git tag ??
WorldMaker 6y ago
You can use merge commits to create your release groups. Use tools like --first-parent to limit the depth you see of the graph by default; that clutter can still be there, but you can take advantage of the nature of the graph itself to "declutter" simply by setting the "depth" you are working in.

deleted 6y ago

[deleted]

IggleSniggle 6y ago

You could get this behavior pretty easily with a double merge: “main” which contains the squashed commits and “history” which contains all commits as well as “main” merged back in post-squash. I do see your point though. Edit: the only reason to merge “main” into “history” is to enforce convergence.

madhadron 6y ago

I go one step further and work entirely in get rebase -i where I build up a stack of tiny, incremental commits. This also lets me get small changes reviewed and committed on a nearly daily basis instead of building up days or weeks of work. I've been wishing for a git GUI that lets me drag hunks around such a stack so I don't have to keep moving them by hand.

amenghra 6y ago

You want this for git: https://www.mercurial-scm.org/wiki/GroupExtension https://www.mercurial-scm.org/wiki/GroupExtension

mpweiher 6y ago

> two different types of commits: working commits and release commits ?? git tag ??

WorldMaker 6y ago

You can use merge commits to create your release groups. Use tools like --first-parent to limit the depth you see of the graph by default; that clutter can still be there, but you can take advantage of the nature of the graph itself to "declutter" simply by setting the "depth" you are working in.