4 ms·

The problem with this approach is the local branch is no longer represented in the shared branch. So if I'm working on a larger feature and want to PR an inter

by Pxtl 6y ago

The problem with this approach is the local branch is no longer represented in the shared branch. So if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge. If I want to merge my hotfix topic branch into both the release and the master branch, their commits won't match so I can't check if it's present in both automatically. If a topic branch is left up instead of deleted after a squash merge, I can't even see that master is ahead of it! Squash is an ugly hack that creates as many problems as it solves. I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking.

Chris2048 6y ago
But doesn't that assume that you based your larger feature on the local branch, instead of the squashed public version? If you wanted to build on the previous commit, why wouldn't you build on the squashed version?
- adrianmsmith 6y ago
  > If you wanted to build on the previous commit, why wouldn't you build on the squashed version? alexmingoia proposed: > That way one gets clean shared history while preserving local work history. But if you keep on building upon the squashed versions each time you do a merge, you won't have convenient access to the local work history any more. If you wanted to have access to the local work history you'd need to keep each branch alive still, each time based on the squashed history plus your individual commits up until the next squash.
  - Chris2048 6y ago
    I suppose you could cherry-pick the new branch onto the squashed version, but I'm still not sure of the value. You have the local work history already, and that work is done to the point of it being squashed and pushed. Why would you need to keep referencing it to the point that it's inconvenient to have it in another branch? > you'd need to keep each branch alive still, each time based on the squashed history plus your individual commits up until the next squash. exactly what I do, and there are maybe just three or four branches I maintain for reference, very few squashed branches are useful a couple of weeks after they are released.
DarkWiiPlayer 6y ago
> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking. Maybe you can do something similar to that with git-replace? Otherwise, you could just tag your commits by putting something in the commit message and use `git grep` to search for those commits. Then you could just build a small helper script that 1. greps for a tag 2. loops over the found commits 3. rewinds them or whatever and 4. squashes the resulting commits. Dunno, there's a bunch of other ways depending on how exactly you want it. But I agree that grouping commits would be pretty cool :D
nicoburns 6y ago
> if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge. I usually deal with this by `git rebase`ing your feature branch on top of the shared branch as soon as the PR is merged. You sometimes still get merge conflicts with this approach, but they're always in the code you've just written so they're usually pretty easy to fix.
- bananaface 6y ago
  The problem with rebasing is you might break every one of those commits, which defeats the purpose of chunking the work like that in the first place (since its no longer an honest reflection of what was happening/what worked at each point).
  - nicoburns 6y ago
    I usually rebase and then squash so that becomes a non-issue. I often find I want to commit more often than the code is in a working state, so I like to be able to erase that history later. I try to keep the whole branch small enough that it'a fine being in one commit.
takeda 6y ago
> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking. Isn't this what git does by default when you merge your changes? The merge commits group small commits together.
WorldMaker 6y ago
> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking. Merge commits work fine for most of that, you just have to adapt to merge UX/commands: --first-parent (to git log, git annotate, etc) gives you clean history viewing of just your "groups" (your merge commits). --first-parent even works for bisect allowing you start by figuring out which merge commit brought in a change (and then dig into the merge branch itself if needed as a second bisect). You can revert or cherry pick merges if you provide the -m (mainline) flag to tell it which parent to consider the mainline (usually the first parent, but not always depending on your intended revert/cherry-pick; it complicates what you need to know about the revert/cherry-pick, but if you are in the process of revert/cherry-picking you should already be figuring out what your mainline is and expecting some possible complications). I think sometimes the only "problem" with Merge commits is too few pretty UX tools default to a --first-parent view of the git graph and don't themselves provide good tool for picking that -m (mainline) for revert/cherry-pick.
- bradstewart 6y ago
  This. I hated working with merge commits until I discovered --first-parent. I'm not sure how it evaded my attention for so long.
  - WorldMaker 6y ago
    I think it is an interesting tools problem: making interesting graph diagrams of the full git log graph is a fun and interesting problem and often looks great in screenshots, but rarely is a particularly "useful" view to most users. It's not as "fun", doesn't produce as many shiny/colorful screenshots, to build --first-parent views by default and introduce (and test) graph drill-down based user experiences.

by Pxtl 6y ago

Chris2048 6y ago

But doesn't that assume that you based your larger feature on the local branch, instead of the squashed public version? If you wanted to build on the previous commit, why wouldn't you build on the squashed version?

adrianmsmith 6y ago
> If you wanted to build on the previous commit, why wouldn't you build on the squashed version? alexmingoia proposed: > That way one gets clean shared history while preserving local work history. But if you keep on building upon the squashed versions each time you do a merge, you won't have convenient access to the local work history any more. If you wanted to have access to the local work history you'd need to keep each branch alive still, each time based on the squashed history plus your individual commits up until the next squash.
- Chris2048 6y ago
  I suppose you could cherry-pick the new branch onto the squashed version, but I'm still not sure of the value. You have the local work history already, and that work is done to the point of it being squashed and pushed. Why would you need to keep referencing it to the point that it's inconvenient to have it in another branch? > you'd need to keep each branch alive still, each time based on the squashed history plus your individual commits up until the next squash. exactly what I do, and there are maybe just three or four branches I maintain for reference, very few squashed branches are useful a couple of weeks after they are released.

DarkWiiPlayer 6y ago

> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking. Maybe you can do something similar to that with git-replace? Otherwise, you could just tag your commits by putting something in the commit message and use `git grep` to search for those commits. Then you could just build a small helper script that 1. greps for a tag 2. loops over the found commits 3. rewinds them or whatever and 4. squashes the resulting commits. Dunno, there's a bunch of other ways depending on how exactly you want it. But I agree that grouping commits would be pretty cool :D

nicoburns 6y ago

> if I'm working on a larger feature and want to PR an intermediate part and continue working, I'm in for a bad merge. I usually deal with this by `git rebase`ing your feature branch on top of the shared branch as soon as the PR is merged. You sometimes still get merge conflicts with this approach, but they're always in the code you've just written so they're usually pretty easy to fix.

bananaface 6y ago
The problem with rebasing is you might break every one of those commits, which defeats the purpose of chunking the work like that in the first place (since its no longer an honest reflection of what was happening/what worked at each point).
- nicoburns 6y ago
  I usually rebase and then squash so that becomes a non-issue. I often find I want to commit more often than the code is in a working state, so I like to be able to erase that history later. I try to keep the whole branch small enough that it'a fine being in one commit.

takeda 6y ago

WorldMaker 6y ago

> I desperately wish git had a "group commits" feature that let me manage a cluster of related commits as a single commit for the purposes of history-viewing, reverting, and cherry-picking. Merge commits work fine for most of that, you just have to adapt to merge UX/commands: --first-parent (to git log, git annotate, etc) gives you clean history viewing of just your "groups" (your merge commits). --first-parent even works for bisect allowing you start by figuring out which merge commit brought in a change (and then dig into the merge branch itself if needed as a second bisect). You can revert or cherry pick merges if you provide the -m (mainline) flag to tell it which parent to consider the mainline (usually the first parent, but not always depending on your intended revert/cherry-pick; it complicates what you need to know about the revert/cherry-pick, but if you are in the process of revert/cherry-picking you should already be figuring out what your mainline is and expecting some possible complications). I think sometimes the only "problem" with Merge commits is too few pretty UX tools default to a --first-parent view of the git graph and don't themselves provide good tool for picking that -m (mainline) for revert/cherry-pick.

bradstewart 6y ago
This. I hated working with merge commits until I discovered --first-parent. I'm not sure how it evaded my attention for so long.
- WorldMaker 6y ago
  I think it is an interesting tools problem: making interesting graph diagrams of the full git log graph is a fun and interesting problem and often looks great in screenshots, but rarely is a particularly "useful" view to most users. It's not as "fun", doesn't produce as many shiny/colorful screenshots, to build --first-parent views by default and introduce (and test) graph drill-down based user experiences.