Re: [Quilt-dev] quilt sync

[tikkoneus]

Jean,

Thanks for your very enlightening perspective!

Regarding issue 2 (that the patch file is up to date) I think that's precisely the issue. Mentally I think to quilt refresh immediately after doing work that I want to record in quilt, just like I git commit immediately after doing work that I want to commit in git. Consequently I find it very easy to forget to pop -a before every non-quilt modification because I'm not mentally in the context of quilt. For the purposes of this sync command I'll exclude all cases where part of M2 should be added to the patch file and part should not, but I don't think that exclusion diminishes the use case.

  [ side note: part of why I got into this in the first place is that my shop uses SVN which doesn't have client side pre-commit hooks. I think a feature like sync, if it works, would expand the use cases for quilt. ]

Issue 1 is easy: update the caches for all applied patches. 'patch -R' to unapply the current patch, what's left goes into the cache, then pop to correctly remove the patch and go to the next one in the stack. Rinse and repeat for all applied patches. Then re-apply all of the patches that had been applied. There is no cache for any patches that weren't applied at the time of the sync operation so that's already taken care of.

The result is that the .pc/{patch}/files have all been rewritten to include the new modifications as if the modifications had happened before the first patch in the stack, like fast-forwarding a git tracking branch.

I've attached a functional attempt. I haven't tested any of the failure cases, or complex cases, but it works pretty well with a multi-patch series in a relatively trivial project. I'm curious to know what you think.

Cheers,

Mike

On 7/18/2017 5:24 AM, Jean Delvare wrote:

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.

sync
Description: Text document