git: pull doesn't work

[dmik]

Final testing shows that git pull is somehow broken in git 2.0.0 (dmik branch). An attempt to pull from any repo gives something like this:

D:>git pull -v
Password for 'https://dmik@bitbucket.org':
From https://bitbucket.org/dmik/test
 = [up to date]      master     -> origin/master
 - not something we can merge7293a3f24e44318563

The last line looks quite bogus. We can't release like that, it needs fixing.

[dmik]

As you know pull is basically a shortcut for two commands: fetch (that downloads the new changes and stores them in the local clone associated with the respective remote branch) and merge (that merges the downloaded changes from the remote branch to the respective local branch). The fetch part works (I changed some file in the test repo from another computer, pushed it to bitbucket and it was successfully downloaded on OS/2 when pulling). The merge part doesn't (as the message says).

[dmik]

I tried updating my branch to 2.1.0 (I've put it to vendor already) but apparently it doesn't help. This must be an OS/2 specific problem then. BTW, I created #37 for working on 2.1.0 since it has some other problems (an OS/2-specific regression between 2.0.0 and 2.1.0) — I'm not going to work on it right now. We'll stick with 2.0.0 for the time being.

[dmik]

It seems to be related to EOLs (what a surprise). Somehow when reading the list of revisions to merge, git also treats \r as a part of the revision spec. It fails to find such a revision and aborts. I'm investigating on how to solve this best.

[dmik]

I fixed the problem in r855:

git: Fix EOL interpretation in pull command.

On OS/2 sed is known to write out files in text mode (terminated with \n\r)
while the pull script would only expect \n. As a result, the remaining \r
would be mistakenly interpreted as part of the revision number causing a
failure.

Short tests show that everything works fine now. Will do a long round (after merging this to trunk and updating it to 2.1.0 from the vendor branch as my previous tests of 2.1.0 didn't show any other regressions besides this one).

[dmik]

It's worth mentioning that the bug was very old: as old as 1.7.3.2 at least. It didn't hurt us before (i.e. in the bauxite's builds) because he had some custom code for exec where he stripped spaces and EOLs from command line arguments which I dropped (to reduce the amount of platform-dependent code which isn't to useful).