Re: [Quilt-dev] quilt sync

[Jean Delvare]

Hi Mike,

On Fri, 14 Jul 2017 18:08:09 -0400, tikkoneus wrote:
> I just discovered quilt and I think it's a great tool. I've learned just 
> enough to be dangerous so I'd like some advice before proceeding.
> 
> One of my use cases is using it alongside a VCS (primarily svn or git) 
> to manage personal or local modifications which don't belong in the VCS. 

I kind of do the same (to prepare patch series before I actually commit
them, but the situation is the same.)

> This breaks quilt quickly when any modifications (git pull / svn update 
> / hackity-hack) are made to quilt-tracked files but those modifications 
> shouldn't be added to the quilt patch (which is what will happen on 
> quilt refresh). One can advise quilt pop before any operations that 
> might possibly affect quilt files,

Indeed.

> but it's not always possible

Why not?

> and if you forget then it gets messy.

Hell yes. That's indeed a real problem for that kind of setup, to which
no solution exists to my knowledge.

> The pdf doc even calls out that it may be 
> possible to resynchronize the index but it's probably worth starting 
> with a new scratch working directory.

Not sure what you mean... Quilt doesn't even have the notion of index,
merely only a tree of backed up files. Which part of the pdf
documentation are you referring to?

> Example: Create a quilt patch P. Create file F and 'quilt add' it, which 
> copies the current version to the index. Make modification M1 and quilt 
> refresh which creates a patchfile. Now some other modification M2 
> happens to F /while M1 is applied /and you don't want M2 to be included 
> in P. The trouble is that quilt starts by verifying that F + P = working 
> copy of F, which it won't.
> 
> I'm picturing 'quilt sync' which is essentially "pop && replace index && 
> push", where the pop operation uses "patch -R" to reverse the given 
> patch from the /working /copy of F. That would leave F + M1 + M2 - M1 = 
> F + M2. Copy that version of the file into the index, then push M1, and 
> now M1 is in fact the only patch on top of the index. 'quilt refresh' 
> after a sync operation should do nothing.
> 
> My questions are:
> 
>   * Should I be doing this at all? (Am I missing something obvious or
>     fundamental about how quilt works? Will this abuse or break the
>     database? Has this already been considered and rejected for good
>     reasons? Is there a better tool or better way to do what I'm trying
>     to do?)

I am worried by two limitations of such a "sync" command which would
probably make it as dangerous as the situation you are trying to avoid
in the first place:

1* You assume that there is only one (quilt) patch applied. What if
several (quilt) patches are applied (with a possible overlap of
modified files)?

2* You assume that the applied (quilt) patch is up-to-date, that is, M1
matches the patch file. If this is not the case (that is, other changes
were made to F and "quilt refresh" was not called yet) then after a
"git pull" there is no way for quilt to differentiate between the local
changes you forgot to refresh and the changes pulled from git / svn /
whatever.

This means you would have to remember to call "quilt refresh" before
"git pull", and to call "quilt sync" afterward. I can't see the benefit
compared to the current situation where you have to remember to call
"quilt pop --refresh" before and "quilt push" afterward.

>   * Any tips on how to go about implementing it?

If you are going to spend any time on this, I would advise implementing
pre-pull/post-pull hooks in git. Git already has a bunch of hooks (see
man 5 githooks) but surprisingly not these. It may be possible to abuse
the post-checkout hook as post-pull (didn't test) but without the first
half it isn't that useful.

If we had such hooks, we could write down the top (quilt) patch name
somewhere then invoke "quilt pop -a" before pulling and "quilt push
$oldtop" after pulling. Straightforward and safe.

> I'm happy to submit a pull request but I want to make sure it's a good 
> idea and I approach it correctly.

I'm afraid you are trying to fix the problem at the wrong place of the
chain.

-- 
Jean Delvare
SUSE L3 Support