"git pull --rebase" fails if pager.pull is true, after producing a colorized diff it cannot apply

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If you run:

    git config pager.pull true

in the hope of getting the output of "git pull" via a pager, you are
in for a surpise the next time you run "git pull --rebase" and it has
to rebase your work.  It will fail with a nonsensical error message:

> Applying: First B commit
> fatal: unrecognized input
> Repository lacks necessary blobs to fall back on 3-way merge.
> Cannot fall back to three-way merge.
> Patch failed at 0001 First B commit
> The copy of the patch that failed is found in:
>    /home/cederp/badcolor/repo-b/.git/rebase-apply/patch
>
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git rebase --abort".

Using "cat -vet" to look at the problematic patch, you can see that
there are embedded escape codes that tries to colorize the patch.

This bug is dependent on the TERM setting.  On my system (Ubuntu
14.04) it reproduces if TERM=vt220 or TERM=rxvt-unicode, but not if
TERM=dumb.  It might depend on the color.diff setting as well, but
it does reproduce with the default setting.

The following script reproduces the problem.  I've tried both git
2.4.3 and git 2.5.0.

----- cut here -----
#!/bin/sh
set -e -x

# All created files are created inside the "badcolor" directory.
mkdir badcolor
cd badcolor

# Create a bare repo.
mkdir upstream.git
(cd upstream.git && git init --bare)

# Make an initial commit.
git clone upstream.git repo-a
(cd repo-a && echo one > a && git add a && git commit -m"First A commit")
(cd repo-a && git push origin master)

# Make a second clone.
git clone upstream.git repo-b

# Make one more commit, that the second clone won't have for a while.
(cd repo-a && echo two > a && git add a && git commit -m"Second A commit")
(cd repo-a && git push origin master)

# Create a third commit; this make the history non-linear, but since
# the commit only touched a new file it should be trivial to linearize
# it.
(cd repo-b && echo one > b && git add b && git commit -m"First B commit")

# Set pager.pull true so that we trigger the bug.
(cd repo-b && git config pager.pull true)

# Attempt to make the history linear.  This command will fail if TERM
# specifies a color-capable terminal.

(cd repo-b && git pull --rebase)

exit 0
----- cut here -----

Thanks,

    /ceder
-- 
Per Cederqvist <cederp@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]