threads / discuss / 18084

merge, keeping the remote as a new file?

Subject: merge, keeping the remote as a new file?

## tl;dr

7 messages between Mar 2, 2009 and Mar 2, 2009.

replies: 6people: 5as markdown or json

Caleb Cushing· Mar 2, 2009, 00:16 UTC · lore
 I have an unmerged file... the resolution I'd like to have is
checkout the local one for the current file name. take the remote
version and give it a new file name. what's the best way to do that?
-- 
Caleb Cushing

http://xenoterracide.blogspot.com
Jeff King· Mar 2, 2009, 04:11 UTC · re: Caleb Cushing · lore

Re: merge, keeping the remote as a new file?

On Sun, Mar 01, 2009 at 07:16:10PM -0500, Caleb Cushing wrote:
>  I have an unmerged file... the resolution I'd like to have is
> checkout the local one for the current file name. take the remote
> version and give it a new file name. what's the best way to do that?
I would use:
  $ git show :2:file >file
  $ git show :3:file >newfile
  $ git add file newfile

You can do the first with "git checkout --ours", but I don't think there is a way with "checkout" to say "checkout this path, but put it in a different place".

-Peff
Charles Bailey· Mar 2, 2009, 06:36 UTC · re: Jeff King · lore

Re: merge, keeping the remote as a new file?

On Sun, Mar 01, 2009 at 11:11:13PM -0500, Jeff King wrote:
Show 17 quoted lines
> On Sun, Mar 01, 2009 at 07:16:10PM -0500, Caleb Cushing wrote:
> 
> >  I have an unmerged file... the resolution I'd like to have is
> > checkout the local one for the current file name. take the remote
> > version and give it a new file name. what's the best way to do that?
> 
> I would use:
> 
>   $ git show :2:file >file
>   $ git show :3:file >newfile
>   $ git add file newfile
> 
> You can do the first with "git checkout --ours", but I don't think there
> is a way with "checkout" to say "checkout this path, but put it in a
> different place".
> 
> -Peff

You can use git checkout-index --temp --stage=3 and then move it from the auto-generated temporary name into its new place.

The shell function checkout_staged_file in git-mergetool.sh does this programmatically, it's not very beautiful as the output of checkout-index --temp requires a bit of expr magic to get the temporary file name out.

Using a checkout variant instead of a show or a cat-file might be important if you are doing autocrlf or some other smudging.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
Jeff King· Mar 2, 2009, 06:45 UTC · re: Charles Bailey · lore

Re: merge, keeping the remote as a new file?

On Mon, Mar 02, 2009 at 06:36:04AM +0000, Charles Bailey wrote:
> You can use git checkout-index --temp --stage=3 and then move it from
> the auto-generated temporary name into its new place.

Hmm. I was hoping there was something that would use the name "--theirs" instead of the mysterious "stage level 3". But it's still nicer than the "git show" I gave because of:

> Using a checkout variant instead of a show or a cat-file might be
> important if you are doing autocrlf or some other smudging.

Right. For some reason I was thinking that cat-file did not handle this but "git show" did, but I just tested and it clearly doesn't. So yes, you should definitely use checkout-index if you care about conversions.

-Peff
Björn Steinbrink· Mar 2, 2009, 06:59 UTC · re: Jeff King · lore

Re: merge, keeping the remote as a new file?

On 2009.03.02 01:45:19 -0500, Jeff King wrote:
Show 15 quoted lines
> On Mon, Mar 02, 2009 at 06:36:04AM +0000, Charles Bailey wrote:
> 
> > You can use git checkout-index --temp --stage=3 and then move it from
> > the auto-generated temporary name into its new place.
> 
> Hmm. I was hoping there was something that would use the name "--theirs"
> instead of the mysterious "stage level 3". But it's still nicer than the
> "git show" I gave because of:
> 
> > Using a checkout variant instead of a show or a cat-file might be
> > important if you are doing autocrlf or some other smudging.
> 
> Right. For some reason I was thinking that cat-file did not handle this
> but "git show" did, but I just tested and it clearly doesn't. So yes,
> you should definitely use checkout-index if you care about conversions.

Hm, how about this? git checkout --theirs file git mv file newname git checkout HEAD file # Can't use --ours here due to the mv

Should work with the CRLF stuff, uses no plumbing, no stage numbers, there's no messing with random temp file names and it's still just three commands.

Björn
Jeff King· Mar 2, 2009, 07:04 UTC · re: Björn Steinbrink · lore

Re: merge, keeping the remote as a new file?

On Mon, Mar 02, 2009 at 07:59:49AM +0100, Björn Steinbrink wrote:
> Hm, how about this?
> git checkout --theirs file
> git mv file newname
> git checkout HEAD file # Can't use --ours here due to the mv
Actually, you can use --ours if you don't "git mv":
  git checkout --theirs file
  mv file newfile
  git checkout --ours file
  git add file newfile

One more command, but I think more obvious about what is going on (and I think both are better than the other suggestions).

-Peff
Jay Soffian· Mar 2, 2009, 13:05 UTC · re: Jeff King · lore

Re: merge, keeping the remote as a new file?

On Mon, Mar 2, 2009 at 2:04 AM, Jeff King <peff@peff.net> wrote:
Show 16 quoted lines
> On Mon, Mar 02, 2009 at 07:59:49AM +0100, Björn Steinbrink wrote:
>
>> Hm, how about this?
>> git checkout --theirs file
>> git mv file newname
>> git checkout HEAD file # Can't use --ours here due to the mv
>
> Actually, you can use --ours if you don't "git mv":
>
>  git checkout --theirs file
>  mv file newfile
>  git checkout --ours file
>  git add file newfile
>
> One more command, but I think more obvious about what is going on (and I
> think both are better than the other suggestions).

This is a superior answer as well because it avoids plumbing in a situation where plumbing ought not be needed.

j.

← back to recent threads