How to force a pull to succeed?

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.

Jeffrey Walton <noloader@gmail.com> writes:

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".

On Mon, May 15, 2017 at 11:27 PM, Junio C Hamano <gitster@pobox.com> wrote:

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

There's no damage. Its expected.

Jeff

Jeffrey Walton <noloader@gmail.com> writes:

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

;-)

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.

On Mon, May 15, 2017 at 11:42 PM, Junio C Hamano <gitster@pobox.com> wrote:

'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

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

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

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