Git merge squash repeatedly

Question

I'm trying to have two branches with binary files in git - one "development" and one "stable". The development branch can have several changes of these files before I want to "release" them to the stable branch (and the stable branch has those files renamed, in case that's relevant).

I could do a normal merge, this works fine, but preserves too much history - when pulling the "stable" branch, all intermediate commits from the "development" branch are pulled as well (because they're parent commits). But we're talking about binary files that don't have any sensible merging strategy (except theirs/ours), so the actual history of the files on the development branch is useless. When I pull the "stable" branch, I get this:

          X-------------------G stable
         /                   /
    a---b---c---d---e---f---g development

Because G has a parent in the development branch, I get the whole history of the development branch (data objects for c, d, e, f and g) in my repository, which I'm not interested in (X is the same as b, with some file renaming applied).

So I tried to git merge --squash changes from the development branch to the stable branch. The first such merge and commit went OK, the results were as expected (nice change log in the commit message, no relation to the development branch):

          X-------------------G stable
         /                   
    a---b---c---d---e---f---g development

After I pull this squashed stable branch, I get this in my repository, which is what I want:

a---b---X---G

But the second merge failed (because git had no way to know how much I merged already and got confused).

• Is it possible to somehow record the merge, without producing a "merge commit" with two parents?
• Or, is it possible to tell git to merge only a certain "range" of revisions, like in SVN?
• Or, is it possible to do a normal merge without having to download all refs from the other branch when pulling?
• Or should I provide a custom merge driver for the files in question, that simply renames "their" version to "our", thereby resolving the conflicts? I'm still afraid that --squash will always try to merge the whole history, up to the common parent, solving only half of my problem.

Update: rebasing

If I understand rebasing correctly, I'll end up with this:

                              X stable
                             /
    a---b---c---d---e---f---g development

Which gets me all the data I'm not interested in (c, d, e, f) and as a bonus, I'll loose the information that b was a stable version in the branch.

Each development revision adds about 5MB to the repository size (and repacking the whole repo shrinks it only about 10%), the "stable" branch comes almost for free (the data is already there). I want pulling a single new revision from the stable branch to pull only the new 5MB, but instead updating from X to G downloads 25MB, because I'm somehow not able to say that I don't care about the contents of c, d, e and f.

Answer 1

Starting with

      X stable
     /                   
a---b---c---d---e---f---g development

You can use the following steps to copy the last commit from your development branch to your stable branch:

git checkout development@{0}  # get working tree from "development", detach HEAD
git reset --soft stable  # reposition detached HEAD on "stable"
git commit  # enter the appropriate commit message
git branch temp  # create a temporary branch "temp" at HEAD
git checkout temp  # get on the new temporary branch
git branch -M stable  # rename "temp" to "stable"

so you end up with:

      X-------------------G stable
     /                   
a---b---c---d---e---f---g development

If you continue work on "development", e.g.,

      X-------------------G stable
     /                   
a---b---c---d---e---f---g---h---i---j development

you can repeat the same git commands as above and you will end up with:

      X-------------------G-----------J stable
     /                   
a---b---c---d---e---f---g---h---i---j development

Answer 2

This isn't the right place to use merge --squash. One good place to use it is in a throwaway topic branch, which you're going to merge into your main branch and then get rid of. All the development done in the topic branch is shown as one commit in the main branch. In your situation, you should merge from the development branch normally, and then use git-rebase --interactive to squash the commits you want.

Is it possible to somehow record the merge, without producing a "merge commit" with two parents?

If I understand the question correctly, no. Absolutely not.

Is it possible to tell git to merge only a certain "range" of revisions, like in SVN?

Yes. git merge [commit hash]

Or, is it possible to do a normal merge without having to download all refs from the other branch when pulling?

See answer to previous question.

Or should I provide a custom merge driver for the files in question, that simply renames "their" version to "our", thereby resolving the conflicts? I'm still afraid that --squash will always try to merge the whole history, up to the common parent, solving only half of my problem.

No! Just don't use git merge --squash. This isn't the right place to use it!

Answer 3

you could use git rebase -i (interactive mode) to sqash all your changes, just change the lines to m or meld (update: for newer Git releases type s or squash)

you will than have a single commit which you can merge. if you want every step of yours reserved, you have to create another branch on your hacking branch before doing the rebase, this can be done with git branch small-dirty-changes-i-don’t-want-anybody-to-see

all this has to be done before attempting to merge; step by step:

# on branch "hacking": hack commit hack commit hack commit

# create a reference to your history
$ git branch dirty-history

# sqash your commits by setting all lines to "meld"
$ git rebase -i

# checkout master or the branch you want to merge to
$ git checkout master

# merge your squashed commit
$ git merge hacking
# or: $ git pull hacking

Answer 4

The top voted answer effectively diffs the stable and the development branches and applies all changes missing in the stable as one commit. There is an alternative way to do this:

$ git checkout stable 
$ git diff stable development | git apply --index -   
$ git commit

Before you commit, you can review the staged files. If you want to abort the process after you applied the diff, you can just use basic commands to remove changes from index and working directory.

$ git reset --hard

You can repeat the process any number of times, since you are effectively just diff-ing the tips of both the branches each time you need to merge.

Note that there is assumption here that applies to the other answer as well: there are no commits in the stable branch other than the ones that came from the development branch. If the same line were changed independently in both branches, unlike a regular merge, this approach would not give you a conflict. Instead, it would just override the changes in the stable branch with the ones in development.

If you are concerned about this, each time you commit on stable, you can put the merged development commit hash range in the commit message. That way, you have some record, if you ever need to backtrack.

Answer 5

I'm new to git, but it seems like --squash is what you want, you just need to handle the branch differently.

$ git merge --squash development
$ git branch -d development
$ git checkout -b development
# continue work on development branch

This would essentially truncate the history of the development branch, and the next merge would only be what you wanted. Looking at the man page it seems like git branch -f development might do the same thing as deleting and recreating the branch.

As I said, I'm pretty new to git, so I'd love some feedback on this idea.