2

When using interactive rebase, I don't understand the difference between Fixup-ing a commit into the previous one, and simply deleting all the other commits from the list.

As far as I can tell, since git commits take a snapshot of the entire repository for each commit, fixup doesn't accomplish anything more than creating merge conflicts that I have to resolve.

From the test repository I created and ran test commands on, I get the same results from using fixup, and deleting those commits entirely and only using the last one. What's the point of fixup?

Brandon
  • 3,573
  • 6
  • 19
  • 21
  • 1
    Squash is basically the same as fixup, except squash let's you edit the commit message. –  Jul 14 '14 at 20:16
  • "*...fixup doesn't accomplish anything more than creating merge conflicts that I have to resolve.*" Fixup won't create merge conflicts unless you're somehow reordering snapshots around, otherwise conflicts are essentially resolved already in each snapshot, you're just combining snapshots together. –  Jul 14 '14 at 20:17
  • Whenever I used fixup, I had to go back and fix merge conflicts from what felt like every commit. I think it's related to merge conflicts I had before, but I don't know how. – Brandon Jul 14 '14 at 20:21
  • Are you trying to rebase merge commits? –  Jul 14 '14 at 20:22
  • Some of the commits were merge commits. – Brandon Jul 14 '14 at 20:24
  • That *might* be the issue, but without a specific example to work with, I personally can't say for sure. –  Jul 14 '14 at 20:25
  • I'm not familiar enough with the [rebase scripts](https://github.com/git/git/blob/v2.0.1/git-rebase.sh) (also [this](https://github.com/git/git/blob/v2.0.1/git-rebase--interactive.sh)) to be able to say for sure, but I think rebase basically works via patches (i.e. a diff of changes). It ***reapplies changes*** to branches. That's why simply removing commits from an interactive rebase list ***should not usually be the same as fixup/squashing***. –  Jul 14 '14 at 20:30
  • I still don't understand the point of fixup though. Why not simply remove commits you don't want to see and then be done with it. Does that destroy the graph of commits? For instance, since those commits were removed, the new HEAD can't go back to anything before then? – Brandon Jul 14 '14 at 20:31
  • 1
    Like I said, I think (though I could be wrong) that rebase basically works with sets of differences between commits, not entire snapshots. Simply removing a commit from the rebase list throws away the changes that were introduced by that commit, while fixup/squash preserves those changes, but combines them with the set of previous changes...so you ***keep*** the changes, but you remove the fact that those changes existed in their own commit from the graph history. Simply throwing away the commit from the rebase removes both the history *and* the changes. –  Jul 14 '14 at 20:33

1 Answers1

0

If you've for example two commits on the same part of the code (the second one being a bug fix on the previous committed code), keeping only the second commit will not work because the second commit wouldn't find the base code on which the modifications need to be applied.

In order to keep only one commit for both modifications, the second commit needs to be fixed-up (merged) to the first one.

Source (in french): git merge and rebase

Hope that this answer will help you.

Joël Salamin
  • 3,538
  • 3
  • 22
  • 33