3

A common thing I do in git (especially when working allone on a project) is merging the current topic branch into the master branch with a fast-forward merge. What bothers me a bit is that I have to first checkout the master branch, which changes all changed files in the working tree back to their original state, and then merge the topic branch which sets the files to the new state again.

This causes my IDE to recompile all changed files since it sees that they have been touched, which is actually unnecessary, because the files' contents are the same as before as the same commit is checked out as before.

Is there some git magic to achieve the same result without git touching the working tree?

jederik
  • 352
  • 2
  • 7
  • Although not fast-forward, see this related question: https://stackoverflow.com/q/10637584/4138912 – doak Dec 20 '18 at 21:36

3 Answers3

6

There is a sneaky trick for this using git push.

Note that when you git push origin foo:foo, this calls up a second Git at your remote named origin, delivers to that Git any necessary commits and other Git objects, then asks the other Git: Please set your branch or tag foo to the same commit as mine. The other Git either says Yes, that's fine, I did it or No, that's not a fast-forward operation, I cannot do that without losing commits.1

This means that git push has within it the logic needed to detect whether something is a fast-forward operation. If only you could push your branch xyz to your own Git's branch master ... and in fact, you can!

git push . xyz:master

tells your Git to call itself—the remote . means "me, myself". Next, you send the other Git any commits you have that they don't. Since they are you, that's nothing at all, and goes really fast. :-) Last, it asks that they (i.e., you) set their (i.e., your) master to match your xyz, but only if that's a fast-forward operation on their (i.e., your) master.

All of this happens without changing anything else about your own Git repository. It's essentially a simple (although sneaky) way of testing: "is moving some branch name a fast-forward operation? if so, do it, if not, don't."

1This assumes there are no prohibited updates via pre-receive and update hooks. Such hooks could also reject a push, for some reason other than non-fast-forward.

torek
  • 448,244
  • 59
  • 642
  • 775
  • +1 because it checks for fast-forward and updates master in one single line. I chose the other one thow because it somehow feels too "sneaky" for me to use push for a local operation. I didn't even dare to test it on my productive code. – jederik Jun 16 '17 at 15:16
1

One way to do it is to force update the master branch:

git branch -f master feature

This will work fine for fast forward merges. But if the master branch has divergent changes (that feature does not have), it'll mess up master.

You can issue the command:

git log ..master --oneline

while on the feature branch to confirm that there are no such commits.

Cristian Lupascu
  • 39,078
  • 16
  • 100
  • 137
1

You can use git worktree to perform the merge in temporary location, fastforward or not.

max630
  • 8,762
  • 3
  • 30
  • 55