Merging Upstream Repo with --Squash

Question

I'm using a forked repo on GitHub and from time to time I need to merge in work on the real ("upstream") repo, as described here.

I would love to squash their changes like this

git pull https://github.com/mixedinkey-opensource/MIKMIDI.git MIDIFiles --squash

but... will my stuff be automatically merge-able with the upstream repo later? Or will those squashed commits cause my repo to differ greatly from the upstream repo, even if my changes were very few?

Using `--squash` is likely to increase the chance of getting merge conflicts, since git has to use an earlier common ancestor for later merges. I can't see any reason why you would want to do this. What are you trying to achieve? — Sven Marnach, Jan 22 '15 at 15:26
@SvenMarnach as I'm working, the main repo is advancing by dozens of commits. They will have commits before and after what I'm doing. I want to keep my history clean, so I don't confuse what I'm working on. A cluttered git history is hard to read, and although I can probably grep it just fine, this is an additional hassle. Does that make sense? — Dan Rosenstark, Jan 22 '15 at 16:01
Using `--squash` doesn't really make the history of *your* branch any cleaner. You still get one commit per merge. — Sven Marnach, Jan 22 '15 at 16:06
@SvenMarnach sorry, you're saying that when I pull the upstream branch, it comes into one commit? I thought it comes into my branch's history as a ton of different commits, some after and some before the current HEAD. No? I'm sure I'm not understanding something/anything. Any help helps, thank you! — Dan Rosenstark, Jan 22 '15 at 21:48
Fetching from upstream will fetch the individual commits. If you merge the upstream branch into your branch (e.g. `git merge upstream/master`), this will either create a single merge commit on your branch or perform a fast-forward, depending on whether you did any changes since the last merge. In the former case, `git log` for your branch will only show one merge commit, in the latter case it will show the individual upstream commits. If you want to avoid the fast-forward , you can either use the `--no-ff` flag to `git merge` or `git pull`, or… — Sven Marnach, Jan 23 '15 at 11:39
…rewind the previous merge using `git reset --hard HEAD^` (warning: this will throw away all local changes. Stash first if you want to keep them) and then simply call `git merge` again. You should only go for the latter option if you haven't published the first merge commit yet. — Sven Marnach, Jan 23 '15 at 11:42
Thanks @SvenMarnach, I'm still digesting this but it makes sense. — Dan Rosenstark, Jan 25 '15 at 01:49

score 2 · Answer 1 · edited May 23 '17 at 12:12

Even for subtree, a pull --squash can be troublesome

That command is more used on the integrator side, when you merge a PR (Pull Request) branch into your original repo (in order to get only one commit).
See for instance "Merging a PR (yours or contributors)"

Remember that pull requests are equivalent to a remote github branch with potentially a multitude of commits.
In this case it is recommended to squash remote commit history to have one commit per issue, rather than merging in a multitude of contributor's commits.
In order to do that, as well as close the PR at the same time, it is recommended to use squash commits.

So in your case, it is recommended to not use squash.

Merging Upstream Repo with --Squash

1 Answers1