Re: git diff woes
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Nov 12, 2007, 10:50 UTC
- Message-ID
- <Pine.LNX.4.64.0711121047590.4362@racer.site>
- In-Reply-To
- <47382C84.50408@op5.se>
Hi,
On Mon, 12 Nov 2007, Andreas Ericsson wrote:
Show 20 quoted lines
> Johannes Schindelin wrote: > > > And sure you can trust the hunk header. Like most of the things, the > > relate to the _original_ version, since the diff is meant to be > > applied as a forward patch. > > > > So for all practical matters, the diff shows the correct thing: "in > > this hunk, which (still) belongs to that function, change this and > > this." > > > > Of course, that is only the case if you accept that the diff should be > > applied _in total_, not piecewise. IOW if you are a fan of GNU patch > > which happily clobbers your file until it fails with the last hunk, > > you will not be happy. > > > > You're right. GNU patch will apply one hunk and then happily churn on > even if it fails. git-apply will apply all hunks or none, so all hunks > can assume that all previous hunks were successfully applied. So what > was your point again?
My point was that this diff is not to be read as if the previous hunks had been applied. Just look at the context: it is also the original file.
It seems I am singularly unable to explain plain concepts as this: a diff assumes that the file is yet unchanged.
So I'll stop.
Ciao, Dscho