merging individual files

merging individual files

[Chris Marshall]

Suppose that merging branch dev1 into master would result in three files, f1,
f2, and f3 being changed, and that I only want to merge the changes for f1 and
f2 and not the changes for f3 currently.  Later on, I want to accept the f3
changes.  Suppose further that the changes to f1, f2, and f3 occurred in a
single commit to branch dev1.

What is the simplest way to use git to achieve that effect?

More generally, I need a way to accept the changes for one or two files while
rejecting the changes for a potentially large number of files, then later on 
accepting the changes for the large number of files.

I work at a company where perforce is currently used for all development and am
trying to work out the git equivalents to all of the perforce flows we use. 
This workflow is the only one that I am stumped on.

One solution that occurs to me is to create a temporary branch off of the (most
recent) common ancestor of master and br1, let's say br2, checkout the files
from br1 that I want to merge into master and commit those to br2, then merge
br2 into master:

git checkout common_ancestor_commit
git checkout -b br2
git checkout br1 f1 f2
git commit
git checkout master
git merge br2
git branch -d br2

This strikes me as not too bad of a procedure, as long as there is a graceful
way of determining the most recent common ancestor of br1 and master.  What's
the simplest way of doing that?

Re: merging individual files

[Michael J Gruber]

Chris Marshall venit, vidit, dixit 13.08.2009 22:16:
> Suppose that merging branch dev1 into master would result in three files, f1,
> f2, and f3 being changed, and that I only want to merge the changes for f1 and
> f2 and not the changes for f3 currently.  Later on, I want to accept the f3
> changes.  Suppose further that the changes to f1, f2, and f3 occurred in a
> single commit to branch dev1.
> 
> What is the simplest way to use git to achieve that effect?
> 
> More generally, I need a way to accept the changes for one or two files while
> rejecting the changes for a potentially large number of files, then later on 
> accepting the changes for the large number of files.
> 
> I work at a company where perforce is currently used for all development and am
> trying to work out the git equivalents to all of the perforce flows we use. 
> This workflow is the only one that I am stumped on.
> 
> One solution that occurs to me is to create a temporary branch off of the (most
> recent) common ancestor of master and br1, let's say br2, checkout the files
> from br1 that I want to merge into master and commit those to br2, then merge
> br2 into master:
> 
> git checkout common_ancestor_commit
> git checkout -b br2
> git checkout br1 f1 f2
> git commit
> git checkout master
> git merge br2
> git branch -d br2
> 
> This strikes me as not too bad of a procedure, as long as there is a graceful
> way of determining the most recent common ancestor of br1 and master.  What's
> the simplest way of doing that?
> 

That would be simply git merge-base master br1.

BUT: The main problem here is that git is not file based, but
revision/commit/tree based. In the above, you're basically losing all
the history common_ancestor_commit..br1 which produced br1's version of
f1 and f2, in the sense that a git log master will not show that part of
the history at all.

If it makes sense to change f1 and f2 without changing f3 that probably
means that the pertinent commit should have been split. Is it an option
for you to rewrite br1's history? That would be the most gittish solution.

Alternatively, you could
git checkout master
git merge --no-commit br1
git checkout --ours f3
git commit # add a note about f3 in the commit message

That way at least you have the full history on master. Note that this
will tell git that br1 is merged in, that is you can't use merge later
on to pull in the changes to f3.
Then, when you want to get that change to f3, you can br1's version of
f3 using git checkout br1 -- f3 and committing that to master. But you
should really rewrite br1 ;)

Michael

Re: merging individual files

[Chris Marshall]

Michael J Gruber <git <at> drmicha.warpmail.net> writes:
> > This strikes me as not too bad of a procedure, as long as there is a 
graceful
> > way of determining the most recent common ancestor of br1 and master.  
What's
> > the simplest way of doing that?
> > 
> 
> That would be simply git merge-base master br1.
> 
> BUT: The main problem here is that git is not file based, but
> revision/commit/tree based. In the above, you're basically losing all
> the history common_ancestor_commit..br1 which produced br1's version of
> f1 and f2, in the sense that a git log master will not show that part of
> the history at all.

Well put, I agree.  One of the main arguments I am going to use to try to 
convince my fellows to switch from perforce to git is the usefulness of git 
blame.  I would be defeating that with my procedure.

> 
> If it makes sense to change f1 and f2 without changing f3 that probably
> means that the pertinent commit should have been split. Is it an option
> for you to rewrite br1's history? That would be the most gittish solution.

Yes, I like the idea of rewriting br1's history.

So, given that f1, f2, ..., fn were changed together in one commit X on br1, I 
want to break f1 and f2 out of X and put them into X', then leave the rest of 
the f3,...,fn changes in Y'.

Let's say X was the last commit on br1.  

What would the commands to do that look like?

Re: merging individual files

[Michael J Gruber]

Chris Marshall venit, vidit, dixit 14.08.2009 16:31:
> Michael J Gruber <git <at> drmicha.warpmail.net> writes:
>>> This strikes me as not too bad of a procedure, as long as there is a 
> graceful
>>> way of determining the most recent common ancestor of br1 and master.  
> What's
>>> the simplest way of doing that?
>>>
>>
>> That would be simply git merge-base master br1.
>>
>> BUT: The main problem here is that git is not file based, but
>> revision/commit/tree based. In the above, you're basically losing all
>> the history common_ancestor_commit..br1 which produced br1's version of
>> f1 and f2, in the sense that a git log master will not show that part of
>> the history at all.
> 
> Well put, I agree.  One of the main arguments I am going to use to try to 
> convince my fellows to switch from perforce to git is the usefulness of git 
> blame.  I would be defeating that with my procedure.
> 
>>
>> If it makes sense to change f1 and f2 without changing f3 that probably
>> means that the pertinent commit should have been split. Is it an option
>> for you to rewrite br1's history? That would be the most gittish solution.
> 
> Yes, I like the idea of rewriting br1's history.
> 
> So, given that f1, f2, ..., fn were changed together in one commit X on br1, I 
> want to break f1 and f2 out of X and put them into X', then leave the rest of 
> the f3,...,fn changes in Y'.
> 
> Let's say X was the last commit on br1.  
> 
> What would the commands to do that look like?
> 

If you're on br1, I would:

git rebase -i X^
# change "pick" to "edit" in front of X in the list you get
git checkout X^ -- f3 f4 f5
git commit --amend
git checkout X -- f3 f4 f5
git commit

For the 2nd commit, using the -c option may be beneficial.

Cheers,
Michael

Re: merging individual files

[Michael J Gruber]

Michael J Gruber venit, vidit, dixit 14.08.2009 17:28:
> Chris Marshall venit, vidit, dixit 14.08.2009 16:31:
>> Michael J Gruber <git <at> drmicha.warpmail.net> writes:
>>>> This strikes me as not too bad of a procedure, as long as there is a 
>> graceful
>>>> way of determining the most recent common ancestor of br1 and master.  
>> What's
>>>> the simplest way of doing that?
>>>>
>>>
>>> That would be simply git merge-base master br1.
>>>
>>> BUT: The main problem here is that git is not file based, but
>>> revision/commit/tree based. In the above, you're basically losing all
>>> the history common_ancestor_commit..br1 which produced br1's version of
>>> f1 and f2, in the sense that a git log master will not show that part of
>>> the history at all.
>>
>> Well put, I agree.  One of the main arguments I am going to use to try to 
>> convince my fellows to switch from perforce to git is the usefulness of git 
>> blame.  I would be defeating that with my procedure.
>>
>>>
>>> If it makes sense to change f1 and f2 without changing f3 that probably
>>> means that the pertinent commit should have been split. Is it an option
>>> for you to rewrite br1's history? That would be the most gittish solution.
>>
>> Yes, I like the idea of rewriting br1's history.
>>
>> So, given that f1, f2, ..., fn were changed together in one commit X on br1, I 
>> want to break f1 and f2 out of X and put them into X', then leave the rest of 
>> the f3,...,fn changes in Y'.
>>
>> Let's say X was the last commit on br1.  
>>
>> What would the commands to do that look like?
>>
> 
> If you're on br1, I would:
> 
> git rebase -i X^
> # change "pick" to "edit" in front of X in the list you get
> git checkout X^ -- f3 f4 f5
> git commit --amend
> git checkout X -- f3 f4 f5
> git commit

followed by

git rebase --continue

of course ;)

> 
> For the 2nd commit, using the -c option may be beneficial.
> 
> Cheers,
> Michael
> 

Re: merging individual files

[Chris Marshall]

Michael J Gruber <git <at> drmicha.warpmail.net> writes:
> > If you're on br1, I would:
> > 
> > git rebase -i X^
> > # change "pick" to "edit" in front of X in the list you get
> > git checkout X^ -- f3 f4 f5
> > git commit --amend
> > git checkout X -- f3 f4 f5
> > git commit
> 
> followed by
> 
> git rebase --continue
> 
> of course ;)
> 
> > 
> > For the 2nd commit, using the -c option may be beneficial.
> > 
> > Cheers,
> > Michael
> > 
> 
> 

Michael:

Thanks so much for your help, this is a lot of fun!

It occurs to me that another way (that doesn't use rebase) would be this:
git branch -m br1 br1-old
git checkout br1-old
git reset HEAD~
git checkout -b br1
git add f1
git commit -m "f1"
git add f2 f3
git commit -m "f2"
git branch -d br1-old (history eraser button ;-)

git checkout master
git merge br1~ (which now only pulls f1's changes)
(work for a while)
git merge br1 (which now pulls f2 and f3).

I like this sequence because it's so explicit about what's going on.

Are there any conceptual problems going this route that I am missing that might
screw up history?

Chris Marshall