Re: [PATCH 2/2] Add keyword unexpansion support to convert.c

[Andy Parkins <andyparkins@gmail.com>]

On Tuesday 2007, April 17, Linus Torvalds wrote:

> Try this:
>
>  - File-A in revision 1:
>
> 	$ID: some random crap about rev1 $
> 	Line 2
>
>  - same file in revision 2:
> 	$ID: some other random crap about rev2 $
> 	Line 2 got modified
>
> and think about it. Your diff will be something like
>
> 	@@ -1,2 +1,2 @@
> 	 $ID:$
> 	-Line 2
> 	+Line 2 got modified
>
> and the diff WON'T EVEN APPLY!

Why on earth would it not apply?  It's being applied using git-apply, 
which will unexpand the keywords as it goes - as I keep saying.  When 
the apply engine is looking for the context it's going to collapse the 
keyword, so the context will match and the diff WILL EVEN APPLY.

As Junio said in his reply, git-apply doesn't currently call 
convert_to_git(), but that's easily implemented.

> In other words, there's no way in hell you can make this work. You'll

You keep saying these sweepingly general things.  It can be made to 
work.

> end up always having to edit the keywords parts of diffs to make them
> apply if they are part of the context.

No I don't.  If I had to then the keyword code would be broken.  No one 
in their right mind would think that was an acceptable thing to do.

> (This, btw, is something that a CVS person says "so what?" about.
> They're _used_ to having to do it. It's how you do merges in CVS.
> Really. How many people have actually *worked* with branches in CVS

That's because CVS is rubbish.  What has that got to do with it?

> on any complex project with any nontrivial work happening on the
> branch? I have. I hated CVS for many reasons. Keywords was just a
> small small detail in that hate relationship, but it was one of
> them!)

You really can stop trying to persuade me that CVS is no good for 
version control - I agree, a thousand times I agree.  There are a lot 
of things that CVS does in a broken manner, that doesn't mean that git 
does the same thing in a broken manner.



Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com