[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [BUG]: star-merge merge should result in conflict w
Re: [Gnu-arch-users] [BUG]: star-merge merge should result in conflict while it merge file partially succesfully (corrupted sources)
Wed, 22 Sep 2004 10:01:01 -0500
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
Karel Gardas <address@hidden> writes:
> I'm using tla-1.2 and while doing experimental star-merge merge I've found
> that star-merge merge some files which should result in conflict and in
> addition this merge is wrong and in fact should be considered as a source
> code corruption (i.e. merge touches C++ method which it should not). When
> I try to "manually" simulate star-merge by diffing -u patch-setX
> patch-setY and applying this to the problematic file manually I got:
Would you be willing to make public the cacherev and changesets so we
can take a look at what's going on? If not the exact code, a dummy
archive with similar code that exhibits the same behaviour could be
added to the tla test framework.
> thinkpad:/tmp/test2$ patch < template.h.patch
> patching file template.h
> Reversed (or previously applied) patch detected! Assume -R? [n]
> Apply anyway? [n]
> Skipping patch.
> 2 out of 2 hunks ignored -- saving rejects to file template.h.rej
> and correctly template.h is not touched at all. I have also test this
> behaviour with tla-1.2.1 and it's the same (buggy as 1.2). To be precise:
> this patch contains two hunk and star-merge produce conflict on the first
> hunk and merges "succesfully" the second. The result is corrupted source.
Hm. Why isn't applying what hunks it can successfully and rejecting
the hunks that it can't the correct behaviour?
You seem to imply arch should always reject all hunks from a file if
any hunks fail to apply, but that doesn't seem useful in the general
Arch alerted you of patching conflicts right? Doesn't that imply you
need to check the source in case it's no longer semantically correct?
> My question is, which parameters are exactly used while executing diff and
> patch to try to simulate this exactly.
Use the source, Luke!
There's exactly one call site for each of diff, diff3, and patch. You
can find them by grepping libarch/* for cfg__gnu_. Their invocations
diff -u -L $ORIG_LABEL -L $MOD_LABEL $ORIG_PATH $MOD_PATH
diff3 -E --merge -L TREE -L ANCESTOR -L MERGE-SOURCE $MY_PATH
patch -f -s --posix -i $PATH_PATH -o $TREE_FILE_BASE $ORIGINAL
(Patch is also invoked optionally with --reverse or --forward if the
same flag is passed to tla as part of a mergingcommand.)