tags:

views:

351

answers:

3

Say I have a feature branch, into which I merge upstream changes prior to pushing my changes back:

git branch feature1
... [edit my code]
... [commit]
git fetch origin master
git merge fetch_head [or rebase]
... [resolve conflicts]
... [build and test code]

At this point I wish to push my changes. The normal way of doing this would be:

git checkout master [changes a bunch of working tree files]
git merge feature1  [changes the same files right back]

This works fine, but will make the (date-checking) compiler think that a whole bunch of files are dirty and needs a rebuild even though the contents are the same. Is there a way to checkout-and-merge that leaves the working tree unchanged in this case?

Something like:

git checkout master --merge-branch feature1

EDIT:

I am only talking about fast forward merges that by definition would not change the state of the files.

+2  A: 

you can push from anywhere. Doesn't matter what you have checked out, or whether the commits you want to push are in master.

git push REMOTE_REPO feature1:master

see git help push

Hint: git push remoteRepo localRef:remoteRef

The second half of this is to reset your master branch. You can do this forcibly if you really want to like this:

# while still on feature1 branch
git branch -f master origin/master

# now master, feature1 and origin/master are all the same so
# no files will get touched here:
git checkout master
JasonWoof
That's true, and fixes half of the problem. Even so, I can't really remain on the feature branch after it's completed. Since I'd pretty much would like to go back to master I would still have this (rather minor) problem.
Tomas Lundell
well, the other part of your question (about wanting the modification times of your files somehow magically changed to the right thing) isn't really solvable. There's no way for git to know which files were compiled when. So git always updates timestamps when it changes files. This results in some extra re-compiling, but that's much better than it failing to re-compile when it should sometimes.
JasonWoof
maybe you'd like to have another clone on your computer, so you can have both checked out at once? If you care about space, it's possible to have two local clones share repo storage.
JasonWoof
I guess I was hoping that for fast forward merges git would be able to checkout-and-merge without touching any of the files (since none of them would change by definition). It's not a big deal, just a minor inconvenience.
Tomas Lundell
A: 

There is no way that merge (or rebase) can work without touching the working directory (and index), as there can be merge conflicts that have to be resolved using working directory (and/or index).

You can always have another clone (perhaps using alternates, or symlinking objects directory, to save disk space), or another working directory with contrib/workdir/git-new-workdir. Or use a tool such as ccache.

Jakub Narębski
A: 

If there are no conflicts, a merge can be performed entirely in the index and there should be no need to touch the work tree, no? Is there a way to achieve this? Failing that, is there a way a merge can be done with the plumbing that results in only the conflicting files being created in a designated location? Or is this the default, since the general model is not to touch non-changed files?

Jeremy