How to force a pull to succeed?

How to force a pull to succeed?

[Jeffrey Walton]

I scp'd a file to another machine for testing. The change tested OK,
so I checked it in on the original machine.

I'm now on the remote machine, and I'm trying to pull the same exact
file that exists on both local and remote. Git won't allow me to do
it, even with -f.

I'd really like -f (or another switch) to work as expected. I don't
like issuing extra command or extra typing.

How do I force the pull to succeed?

Thanks in adavnce.

**************

qotom:cryptopp$ git pull
Updating 30ac06d..30ac53f
error: Your local changes to the following files would be overwritten by merge:
        datatest.cpp
Please commit your changes or stash them before you merge.
Aborting
qotom:cryptopp$ git pull -f
Updating 30ac06d..30ac53f
error: Your local changes to the following files would be overwritten by merge:
        datatest.cpp
Please commit your changes or stash them before you merge.

Re: How to force a pull to succeed?

[Junio C Hamano]

Jeffrey Walton <noloader@gmail.com> writes:

> I scp'd a file to another machine for testing. The change tested OK,
> so I checked it in on the original machine.
> ...
> How do I force the pull to succeed?

Git doesn't know (or care) if you "scp"ed a file from a known to be
good place, or if you modified it in the editor.  When it notices
that there are differences you may rather not to lose in these files
(because they are different from HEAD), it refrains from touching
them.

So the way to go forward is for you to make sure that you do not
have such local changes in the repository that your "pull" is trying
to touch.  An easiest way would be to do

	git checkout HEAD -- <paths>..

before doing a "git pull" to clear the damage you caused manually
with your "scp".  

Re: How to force a pull to succeed?

[Jeffrey Walton]

On Mon, May 15, 2017 at 11:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeffrey Walton <noloader@gmail.com> writes:
>
>> I scp'd a file to another machine for testing. The change tested OK,
>> so I checked it in on the original machine.
>> ...
>> How do I force the pull to succeed?
>
> Git doesn't know (or care) if you "scp"ed a file from a known to be
> good place, or if you modified it in the editor.  When it notices
> that there are differences you may rather not to lose in these files
> (because they are different from HEAD), it refrains from touching
> them.
>
> So the way to go forward is for you to make sure that you do not
> have such local changes in the repository that your "pull" is trying
> to touch.  An easiest way would be to do
>
>         git checkout HEAD -- <paths>..

Thanks. That's an extra command. Is there any way to roll it up into
one command?

> before doing a "git pull" to clear the damage you caused manually
> with your "scp".

There's no damage. Its expected.

Jeff

Re: How to force a pull to succeed?

[Junio C Hamano]

Jeffrey Walton <noloader@gmail.com> writes:

> On Mon, May 15, 2017 at 11:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeffrey Walton <noloader@gmail.com> writes:
>>
>>> I scp'd a file to another machine for testing. The change tested OK,
>>> so I checked it in on the original machine.
>>> ...
>>> How do I force the pull to succeed?
>>
>> Git doesn't know (or care) if you "scp"ed a file from a known to be
>> good place, or if you modified it in the editor.  When it notices
>> that there are differences you may rather not to lose in these files
>> (because they are different from HEAD), it refrains from touching
>> them.
>>
>> So the way to go forward is for you to make sure that you do not
>> have such local changes in the repository that your "pull" is trying
>> to touch.  An easiest way would be to do
>>
>>         git checkout HEAD -- <paths>..
>
> Thanks. That's an extra command. Is there any way to roll it up into
> one command?

        git checkout HEAD -- <paths>.. && git pull

;-)

>> before doing a "git pull" to clear the damage you caused manually
>> with your "scp".
>
> There's no damage. Its expected.

The fact that you think it is expected is immaterial. Git doesn't
know (or care) how you made the files different from HEAD, so it
looks like a damage to it.

Re: How to force a pull to succeed?

[Jeffrey Walton]

On Mon, May 15, 2017 at 11:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeffrey Walton <noloader@gmail.com> writes:
>
>> On Mon, May 15, 2017 at 11:27 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Jeffrey Walton <noloader@gmail.com> writes:
>>>
>>>> I scp'd a file to another machine for testing. The change tested OK,
>>>> so I checked it in on the original machine.
>>>> ...
>>>> How do I force the pull to succeed?
>>>
>>> Git doesn't know (or care) if you "scp"ed a file from a known to be
>>> good place, or if you modified it in the editor.  When it notices
>>> that there are differences you may rather not to lose in these files
>>> (because they are different from HEAD), it refrains from touching
>>> them.
>>>
>>> So the way to go forward is for you to make sure that you do not
>>> have such local changes in the repository that your "pull" is trying
>>> to touch.  An easiest way would be to do
>>>
>>>         git checkout HEAD -- <paths>..
>>
>> Thanks. That's an extra command. Is there any way to roll it up into
>> one command?
>
>         git checkout HEAD -- <paths>.. && git pull
>
> ;-)
>
>>> before doing a "git pull" to clear the damage you caused manually
>>> with your "scp".
>>
>> There's no damage. Its expected.
>
> The fact that you think it is expected is immaterial. Git doesn't
> know (or care) how you made the files different from HEAD, so it
> looks like a damage to it.

'git pull' fails and its expected, but 'git pull -f' is supposed to
succeed. That's what -f is supposed to do.

Is there a way to add intelligence to Git so that it sees they are the
_exact_ same file, and it stops bothering me with details of problems
that don't exist?

It seems like adding the intelligence is a good enhancement. A version
control tool has to do three things: check-out, check-in, and
determine differences. Its not doing a good job of determining
differences considering they are the exact same file.

Jeff

Re: How to force a pull to succeed?

[Jeff King]

On Mon, May 15, 2017 at 11:47:14PM -0400, Jeffrey Walton wrote:

> > The fact that you think it is expected is immaterial. Git doesn't
> > know (or care) how you made the files different from HEAD, so it
> > looks like a damage to it.
> 
> 'git pull' fails and its expected, but 'git pull -f' is supposed to
> succeed. That's what -f is supposed to do.

Well, no. "pull -f" does something else, and is documented as such.

> Is there a way to add intelligence to Git so that it sees they are the
> _exact_ same file, and it stops bothering me with details of problems
> that don't exist?
> 
> It seems like adding the intelligence is a good enhancement. A version
> control tool has to do three things: check-out, check-in, and
> determine differences. Its not doing a good job of determining
> differences considering they are the exact same file.

AFAICT there are basically two changes we could consider here:

  1. Some kind of --force option to git-merge and git-pull that just
     overwrites files, regardless of content. That's not much better
     than "git reset --hard && git merge", but I suppose it might save
     the state of files that wouldn't otherwise be affected by the
     merge. We already have something similar for "checkout -f".

  2. Right now the verify_uptodate() check happens deep in unpack-trees,
     which doesn't actually know what the merge result is going to be
     for that file. In some cases (like yours) the threeway result is
     trivial, but in others it requires doing an actual content-level
     merge. But in theory we could get the entire merge result and only
     then decide whether to write it in place (after comparing to the
     on-disk contents).

     I suspect that covering the latter would take some major surgery to
     the way that the merge code works. The trivial cases could probably
     be handled inside unpack-trees.

Neither seem totally unreasonable to me. But without working patches,
there's not much to discuss.

-Peff