0

I'm familiar with using squash to clean up my branch, but the text for squashing is use commit, but meld into previous commit, which will use the message from the previous commit. I wondering if there's a way to make it quickly use the later commit (or rather, roll up the file changes and use the later commit's message)

An example:

  • 443f7287: "Fixes a lot of stuff" (Second commit chronologically)
    • Files A, B, and C
  • 0ebbd9c0: "Partial commit from when I had to switch tracks temporarily" (first commit chronologically)
    • Files D, E, and F

Run something here and end up with

  • 443f7287: "Fixes a lot of stuff"
    • Files A, B, C, D, E, and F

I know I could do this with rebase, by squashing 443f7287 and then manually copying its commit message onto the resulting commit, but I'm hoping for a one-liner without the interactive-rebase screens. Theoretically, I could stash my changes when I change tracks instead of committing them, but I haven't really gotten a lot of traction when trying to learn stash.

Is there any way to quickly achieve my goals? Is there a better solution?

Improve this question
1
  • 1
    I just do this with interactive pick/squash; this kind of squash retains both commit messages and lets you edit the result. That usually seems easier than anything else.
    – torek
    Commented Feb 21, 2014 at 15:19

2 Answers 2

Reset to default
1

If these commits are at the tip of your branch and you're currently working on the changes that would otherwise be in 443f7287 , you can avoid an interactive rebase by using git commit --amend rather than making a second commit at all. This will prompt you to edit the commit message of the preceding commit, at which point you can specify the commit message that you want.

If you're trying to edit commits that are somewhere deeper in history, I don't believe there's an easy way to avoid using the interactive rebase steps that others have shared.

Improve this answer
5
  • Wouldn't that simply change the message, rather than cleaning up my branch? The state of my code would be correct (A-F would look as I want them to), but they would still be associated with different commits, when I actually want a single commit, encompassing a logical grouping.
    – ABMagil
    Commented Feb 21, 2014 at 15:33
  • 1
    Amending a commit actually rolls your currently staged changes into the preceding commit. I may have been unclear -- I'm approaching this as if you have not yet committed 443f7287. If you know that those changes belong in the preceding commit, you can simply amend them rather than ever having two commits. It's possible that doesn't fit your scenario though.
    – joshtkling
    Commented Feb 21, 2014 at 15:36
  • Ah, I see. Yeah, I'm specifically concerned with the situation where I have already committed both (though I see how my example doesn't explain that well)
    – ABMagil
    Commented Feb 21, 2014 at 15:41
  • Are you at the tip of your branch in this case? You should be able to do a git reset HEAD^ followed by the amend steps that I mentioned above, if so. This temporarily undoes your second commit while preserving the changes and then replays it as an amend to your previous.
    – joshtkling
    Commented Feb 21, 2014 at 15:44
  • It seems like this is the closest I might get. No one-liner, but avoids the rebase-interactive screens.
    – ABMagil
    Commented Feb 21, 2014 at 16:09
0

If you are willing to use the interactive rebase, one thing you can easily do is to take the two lines

pick 0ebbd9c0 Partial commit from when I had to switch tracks temporarily
pick 443f7287 Fixes a lot of stuff

and reorder them

pick 443f7287 Fixes a lot of stuff
pick 0ebbd9c0 Partial commit from when I had to switch tracks temporarily

and then change the second one to a “fixup”:

pick 443f7287 Fixes a lot of stuff
f 0ebbd9c0 Partial commit from when I had to switch tracks temporarily

This will have the same effect as squashing the two together, but it will automatically take the first commit message (“Fixes a lot of stuff”) without any further prompting.

Improve this answer
1
  • 2
    Note that this depends on being able to do the commits in the other order, safely. (This is so in the example case in the question, but not in general.)
    – torek
    Commented Feb 21, 2014 at 15:18

Not the answer you're looking for? Browse other questions tagged or ask your own question.