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.
See Question&Answers more detail:
os