Merge into locally modified files?

Merge into locally modified files?

[skillzero]

If I have some local changes to a file that I don't want to commit
(e.g. temp debug changes like printf's) and I see somebody else has
pushed some changes to that file, how do I merge their changes to the
file while trying to preserve my local changes (and conflicting if
it's not possible)?

After a git fetch, I tried 'git checkout --merge origin/master <path
to my locally modified file>', but that just overwrote my local
changes.

I'm converting people from CVS to git and this is a common thing
people do with CVS. They have some local changes and see that the
server has some other changes so they do 'cvs up' and it tries to
merge changes from the server into the locally modified file. The
local changes are often things that will never be committed. I know
git tries to avoid things you can't undo, but like a 'git checkout
<file>' that can't be undone, is there a way to say "merge what you
can and generate conflict markers for things you can't?".

I think what I want to do is the equivalent of rebasing for local
modified files rather than committed files.

Re: Merge into locally modified files?

[Johan Herland]

On Monday 08 June 2009, skillzero@gmail.com wrote:
> If I have some local changes to a file that I don't want to commit
> (e.g. temp debug changes like printf's) and I see somebody else has
> pushed some changes to that file, how do I merge their changes to the
> file while trying to preserve my local changes (and conflicting if
> it's not possible)?
>
> After a git fetch, I tried 'git checkout --merge origin/master <path
> to my locally modified file>', but that just overwrote my local
> changes.
>
> I'm converting people from CVS to git and this is a common thing
> people do with CVS. They have some local changes and see that the
> server has some other changes so they do 'cvs up' and it tries to
> merge changes from the server into the locally modified file. The
> local changes are often things that will never be committed. I know
> git tries to avoid things you can't undo, but like a 'git checkout
> <file>' that can't be undone, is there a way to say "merge what you
> can and generate conflict markers for things you can't?".
>
> I think what I want to do is the equivalent of rebasing for local
> modified files rather than committed files.

Being a CVS convert myself, I know this may be difficult to grasp when 
coming from CVS. Here's the deal: In the scenario you describe above, 
CVS forces you to merge your local modifications with the updates from 
the server. Thus, if/when you commit your changes, they will no longer 
be your changes only, but they will also contain whatever you did to 
resolve the conflicts. (This is also know as "merge-before-commit".)

Git, instead encourages you to commit your changes _first_ 
(aka. "commit-before-merge"), so that your changes are not necessarily 
affected by the updated changes from the server. By committing your 
changes first, you can choose at a later date whether to _merge_ your 
changes into the updates from the server (in a separate merge commit), 
or whether to _rebase_ your changes on top of the updates from the 
server (as if you made your changes after the update, and not before 
the update).

In this scenario, since you have not published your changes, it makes 
sense to rebase them on top of the updates from the server. In other 
words, what you should do is first "git commit" your changes, and 
then "git fetch" and "git rebase origin/master". (You can also use "git 
pull --rebase" instead of the last two commands.)

Now, since you probably don't want to push your changes (debug printfs 
etc.), you should probably put them on a separate branch, so that they 
are not automatically part of your next "git push". If you have already 
committed them to you local "master" branch, you can do the following:

	git checkout -b debug  # Create and switch to a new branch "debug"
	git branch -f master HEAD^ # Reset "master" to the previous commit

Your "master" is now back "in sync" with the server, and you have a 
debug branch which contains your debug printfs. Now, when you make 
further changes, you can choose whether to put them on "master" 
or "debug".  With a default push configuration, "git push" will now 
push "master", but not "debug", so your debug printfs will stay in your 
local repo. Note that if you still need the debug printfs after there 
are more commits on "master", you will have to

	git checkout debug
	git rebase master

to put your debug printfs back on top of the "master" branch.


BTW, I find it very helpful to use gitk to visualize the commit history 
before and after each of these commands, so that I get a "natural" feel 
for how each command operates on the commit graph.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Merge into locally modified files?

[skillzero]

On Mon, Jun 8, 2009 at 11:22 AM, Johan Herland <johan@herland.net> wrote:
>
> Git, instead encourages you to commit your changes _first_
> (aka. "commit-before-merge"), so that your changes are not necessarily
> affected by the updated changes from the server.

The problem I have with this is that it's a lot of extra work to
commit, pull (which will create a merge commit), then back out the
merge commit git pull did, back out my local commit, then re-apply my
local changes. I typically always have some modified files in my tree
for little things I may never want to commit. I'll tweak some build
Makefile build setting (e.g. enable extra logging, some debug printfs,
etc.). These changes are very transient. We tend to pull in changes
several times a day as people change stuff.

It looks like I can use git stash to help here. If I do 'git stash &&
git pull && git stash pop', it seemed to work in a simple example. If
I had no changes, I'd need to be careful to not try to do a git stash
pop since it would haven't stashed anything.

Is this something that would be pretty easy to add to git pull (or I
guess really to git merge since pull is just fetch+merge)? Maybe
something like a 'git pull --rebase-local'? If I wanted to add
something like this, should I just start by looking at git stash and
see how it does it and try to integrate support for that into git
merge (and make sure git pull will pass that option through to git
merge)? Conceptually, it seems easy, but I don't know how hard it
would be to get it into the code.

Re: Merge into locally modified files?

[Johan Herland]

On Monday 08 June 2009, skillzero@gmail.com wrote:
> On Mon, Jun 8, 2009 at 11:22 AM, Johan Herland <johan@herland.net> wrote:
> > Git, instead encourages you to commit your changes _first_
> > (aka. "commit-before-merge"), so that your changes are not necessarily
> > affected by the updated changes from the server.
>
> The problem I have with this is that it's a lot of extra work to
> commit, pull (which will create a merge commit), then back out the
> merge commit git pull did, back out my local commit, then re-apply my
> local changes.

I never suggested you do something convoluted like that. What I suggested 
was:

1. "git commit" your local changes
2. "git pull --rebase"

After this, your local changes will be on top of the pulled changes. (Then 
you can put them on a separate branch, if you're paranoid about accidentally 
pushing them to the server.)

> I typically always have some modified files in my tree
> for little things I may never want to commit. I'll tweak some build
> Makefile build setting (e.g. enable extra logging, some debug printfs,
> etc.). These changes are very transient. We tend to pull in changes
> several times a day as people change stuff.

Yes, and that's why I suggest you keep your debug stuff on a separate 
branch, so that it's easily separated from the mainline development.

> It looks like I can use git stash to help here. If I do 'git stash &&
> git pull && git stash pop', it seemed to work in a simple example.

Yes, that's another way of doing it; possibly better than my suggestion.

> If I had no changes, I'd need to be careful to not try to do a git stash
> pop since it would haven't stashed anything.

If this is the only thing you use 'git stash' for, you could start off with 
a 'git stash clear'. That way, there would be nothing to 'pop' if there was 
nothing to 'stash'.

> Is this something that would be pretty easy to add to git pull (or I
> guess really to git merge since pull is just fetch+merge)? Maybe
> something like a 'git pull --rebase-local'? If I wanted to add
> something like this, should I just start by looking at git stash and
> see how it does it and try to integrate support for that into git
> merge (and make sure git pull will pass that option through to git
> merge)? Conceptually, it seems easy, but I don't know how hard it
> would be to get it into the code.

Feel free to whip up a patch. I can't say whether it'll be accepted or not.


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

Re: Merge into locally modified files?

[Andreas Ericsson]

skillzero@gmail.com wrote:
> If I have some local changes to a file that I don't want to commit
> (e.g. temp debug changes like printf's) and I see somebody else has
> pushed some changes to that file, how do I merge their changes to the
> file while trying to preserve my local changes (and conflicting if
> it's not possible)?
> 
> After a git fetch, I tried 'git checkout --merge origin/master <path
> to my locally modified file>', but that just overwrote my local
> changes.
> 
> I'm converting people from CVS to git and this is a common thing
> people do with CVS. They have some local changes and see that the
> server has some other changes so they do 'cvs up' and it tries to
> merge changes from the server into the locally modified file. The
> local changes are often things that will never be committed. I know
> git tries to avoid things you can't undo, but like a 'git checkout
> <file>' that can't be undone, is there a way to say "merge what you
> can and generate conflict markers for things you can't?".
> 
> I think what I want to do is the equivalent of rebasing for local
> modified files rather than committed files.


git stash && git pull && git stash pop

should do roughly what you want.

/Andreas

Re: Merge into locally modified files?

[Jon Smirl]

On Mon, Jun 8, 2009 at 1:30 PM, <skillzero@gmail.com> wrote:
> If I have some local changes to a file that I don't want to commit
> (e.g. temp debug changes like printf's) and I see somebody else has
> pushed some changes to that file, how do I merge their changes to the
> file while trying to preserve my local changes (and conflicting if
> it's not possible)?
>
> After a git fetch, I tried 'git checkout --merge origin/master <path
> to my locally modified file>', but that just overwrote my local
> changes.

I use stgit to do this all of the time. stgit is all about patch
stacks. You just add your debug stuff to a stgit patch and then you
can push/pop it.

stg new debug-patch
..make debug edits..
stg refresh

git fetch origin
stg rebase origin/master
... fix conflicts, you get prompted...

you're done.


>
> I'm converting people from CVS to git and this is a common thing
> people do with CVS. They have some local changes and see that the
> server has some other changes so they do 'cvs up' and it tries to
> merge changes from the server into the locally modified file. The
> local changes are often things that will never be committed. I know
> git tries to avoid things you can't undo, but like a 'git checkout
> <file>' that can't be undone, is there a way to say "merge what you
> can and generate conflict markers for things you can't?".
>
> I think what I want to do is the equivalent of rebasing for local
> modified files rather than committed files.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: Merge into locally modified files?

[Sitaram Chamarty]

On 2009-06-08 19:14:38, skillzero@gmail.com <skillzero@gmail.com> wrote:

> Is this something that would be pretty easy to add to git pull (or I
> guess really to git merge since pull is just fetch+merge)? Maybe
> something like a 'git pull --rebase-local'? If I wanted to add

I'd just use an alias.  Either a bash alias like
    alias cvsup='git stash && git pull && git stash pop'
or a git alias like
    git config --global alias.cvsup '!git stash && git pull && git stash pop'

The latter is probably better aesthetically, and you'd call
it by saying "git cvsup".

Far cleaner than patching git-pull, no?