Re: [PATCH] Optional shrinking of RCS keywords in git-p4

[David Brown <git@davidb.org>]

On Mon, Sep 15, 2008 at 03:22:33PM -0400, Daniel Barkalow wrote:

>Actually, the problem seems to be that git-p4 tries to create the modified 
>file by applying the git-generated diff to the p4-provided file, and this 
>fails if the context for the git-generated diff contains a keyword, since 
>the p4-provided file has it expanded and git has it collapsed.

It is very likely that I've never made a change within context-lines
of a RCS header.  The files we have with these headers tend to also
comment blocks at the top that don't change after the file is created.

>I think the right solution is for git-p4 to check that p4 thinks the file 
>is the correct file and then simply replace it rather than trying to 
>generate the right result by patching. To be a bit more careful, git-p4 
>could check that the contents it's replacing actually would exactly match 
>the git contents if the keywords were callapsed (if the p4 setting is to 
>use keywords in this file).

Part of the problem is that p4 isn't very good at knowing whether
files have changed or not.  'p4 sync' will update the file _if_ if
thinks your version is out of date, but it does nothing if someone has
locally modified the file, hence the need for the 'p4 sync -f'.

A simple way to be paranoid would be something (shell-ish) like:

   p4 print filename | collapse-keywords | git hash-object --stdin

and make sure that is the version we think the file should have
started with.  I think we're really just making sure we didn't miss a
P4 change that someone else made underneath, and we're about to back
out.

Even this isn't robust from p4's point of view.  The p4 model is to do
a 'p4 edit' on the file, and then the later 'p4 submit' will give an
error if someone else has updated the file.  This would require using
p4's conflict resolution, and I'm guessing someone using git-p4 would
rather abort the submit and rebase.

David