git merge-file fails with bash process substitution operator that uses git show -
i'm trying merge changes file in git 1 isn't under version control (more context) using 3-way-merge.
as there git merge-file <local> <base> <other>
expects 3 files , don't fancy creating intermediate files , forgetting clean them up, used bash <(...)
process substitution operator quite often.
it turns out doesn't seem work expected following example shows on git 2.4.2 , 2.4.3 on 2 different systems.
example:
let's create small test know we're talking about. we'll create file foo.txt
(the 1 in git 2 versions @ least) , file bar.txt
not under version control:
git init echo -e 'foo\nbar' > foo.txt git add foo.txt git commit -m'init' echo -e 'foo\nbar\nend' > foo.txt git commit -a -m'end' echo -e 'start\nfoo\nbar' > bar.txt git show head^:foo.txt > foo.txt.base git show master:foo.txt > foo.txt.end
this leaves couple of files this:
foo.txt @ head^ & foo.txt.base:
foo bar
foo.txt @ master & foo.txt.end:
foo bar end
bar.txt:
start foo bar
with intermediate files:
so let's run git merge-file -p bar.txt foo.txt.base foo.txt.end
:
start foo bar end
this output i'd following method well.
with process substitution:
but if run: git merge-file -p bar.txt <(git show head^:foo.txt) <(git show master:foo.txt)
, output:
start foo bar
this not expected , (sometimes!) echo $?
prints 1
indicating error.
what's weirder couldn't understand behavior decided re-run above command (up-arrow) , more puzzled when output appeared:
<<<<<<< bar.txt start foo bar ======= foo bar end >>>>>>> /dev/fd/62
as didn't expect fail, less non-deterministic ran again couple of times find output well:
<<<<<<< bar.txt start foo bar ======= >>>>>>> /dev/fd/62
to narrow down problem tried git merge-file -p bar.txt <(echo -e 'foo\nbar') <(echo -e 'foo\nbar\nend')
reliably prints expected merge:
start foo bar end
question
can explain weird behavior?
i can fix not using process substitution, i'd understand why happens i'm using process substitution in lot of bash scripts. i'd interested in workarounds allow me still use process substitution.
also if think bug i'm interested in component originates from: git show
, git merge-file
or bash?
as pointed out in comments , here might problem <(...)
providing fifo file doesn't support seek
. same behavior shown in zsh unless invoked this:
git merge-file -p bar.txt =(git show head^:foo.txt) =(git show master:foo.txt)
this means problem originates git merge-file
expecting files can seek
on, while <(...)
doesn't provide these.
Comments
Post a Comment