[pacman-dev] [PATCH 1/2] Enabled new interactive prompt and updated some tests.

[Bryan Ischo]

Dan McGee wrote:
> On Sun, Feb 22, 2009 at 5:33 AM, Bryan Ischo
> <bji-keyword-pacman.3644cb at www.ischo.com> wrote:
>   
>> I'm not trying to solve every existing problem with the pacman source.  I'm
>> just trying to add a new feature without making the code any 'worse' than it
>> was ...
>>
>> And to be honest, I would be happy to add this documentation, but ... I've
>> already constructed and re-constructed my git patches so many times to
>> satisfy requests on this list, I'm afraid I have no more energy to do it all
>> over again just to add some comments in a place where no comments existed
>> previously.  Sorry :(
>>     
>
> Just out of curiousity, how have you been making changes to your
> patches? You do know git makes this quite painless with tools like
> rebase and rebase -i. Part of the reason we make so many requests is
> because changing patches is not a big deal with git, but if you don't
> use the tools to your advantage I could see it being painful.
>
>   

Well I find git to be kind of painful, to be honest.  Maybe I'm not 
using it correctly?  Every git command is very fast, but there are so 
many of them to run as part of recreating patches, and so many little 
details to get right every time.

First problem is that it's not possible to be in two branches at once.  
If my branches were rooted at different subdirectories of my tree, then 
I could have all versions of all of my files in place in my filesystem 
and easily look at different versions.  As it is, I have to re-read man 
pages to see how to cat versions of files from different branches while 
I am working on a given branch.  It's a bit of a pain to keep track of 
everything in this way, and I believe that if different branches were 
stored in different parts of your tree and you didn't have to use git to 
switch your view between them all the time, things would be easier.  
This is how Perforce, and from my reading of documentation, Bazaar 
works, and for me personally, it would be a vast improvement over the 
git workflow.

The way that I incorporate feedback from the list is:

- I have a branch that has my most-recently-sent patches in it.  Call 
that branch 'old'.
- I create a new branch off of master, call that branch 'new'
- I find out what the change number of the first change that I need to 
update is, and I do 'git merge --no-commit <change_number>', to get the 
first change into my new branch.
- I don't know why, but unless there are conflicts, git ignores my 
--no-commit most of the time and commits anyway.  So I then do git reset 
HEAD^.
- Now I'm sitting at a tree with the same modifications that my first 
patch had.  Now I have to go open multiple emails and scan through them, 
checking to see what changes I need to make to that patch, and making them.
- Then I have to run tests and also run pacman manually to make sure 
that my changes to my patch didn't introduce any problem.  Usually I 
just make clean and rebuild everything all the time because I am 
paranoid that the make rules, combined with git changing files 'in 
place' in my filesystem, will not recompile everything correctly.  I 
have no reason to believe this, but I'm just paranoid so I always do a 
clean before a make.
- Finally, I can check in my change.  I do git commit -s, and then open 
the log for my commit to the 'old' branch in a separate window so that I 
can copy over my commit message, changing it as necessary also.
- Then, I repeat the above for the next patch(es) in sequence.  Often 
there are conflicts when merging these in, because of the changes that I 
made to the previous patches in the sequence, and I have to deal with 
that too.
- Any small error in this process results in messed up patches.  
Invariably, I realize mistakes and have to repeat the whole process, 
starting with a new branch, applying the first patch, etc, etc, over and 
over again, as I realize that my change forgot to add a file, or that I 
missing some small thing.  I must just have fumbling fingers, but it 
takes me at least 3 or 4 tries every single time to get the 'perfect' 
patches.
- Finally, I git format-patch to get patches to send.  I use git 
send-email to send them to myself, so that I can then create a new 
branch off of master, and apply them one by one to ensure that they 
apply cleanly.  If so, I use git send-email to send them to the 
pacman-dev list.

The whole process takes hours.  The most frustrating aspect is how 
perfectly everything has to be done or the patch will be wrong, and once 
a wrong patch is in, I have to start all or part of the process over.

Then, I send what I think is the perfect patches to the list, and I get 
feedback and find that I have to do the whole thing all over again, and 
again, and again ...

Thanks,
Bryan