Hi Andreas,
git is not doing a plain patch, it is doing a merge. It is not unusual
for a merge to have changes that are already present on both sides.
... which just goes to show that it is very easy to make a fool of
yourself with git if you have no mental model of what it does.
That's not
On Mai 21 2020, Thomas Koenig wrote:
> Obviously, reverting the already applied patch was a no-op.
Obviously not, since the first revert was partial only.
> I would assume that git noticed that, and could issue a message
> like "applying diff to foo.c failed". patch(1) manages it.
git is not
Am 21.05.20 um 13:05 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig wrote:
An error message or warning from git might have been nice, though.
How can it know?
Obviously, reverting the already applied patch was a no-op.
I would assume that git noticed that, and could issue a message
On Mai 21 2020, Thomas Koenig wrote:
> An error message or warning from git might have been nice, though.
How can it know?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Am 21.05.20 um 11:45 schrieb Andreas Schwab:
On Mai 21 2020, Thomas Koenig via Gcc wrote:
$ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
on origin/releases/gcc-9, and now only the ChangeLog entries reversed
(which is not wanted), but the code is unchanged (which is even
less
On Mai 21 2020, Thomas Koenig via Gcc wrote:
> $ git revert r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6
>
> on origin/releases/gcc-9, and now only the ChangeLog entries reversed
> (which is not wanted), but the code is unchanged (which is even
> less wanted).
You are trying to revert a
