Re: Re-done kernel archive - real one?

[Russell King <rmk@arm.linux.org.uk>]

On Tue, Apr 19, 2005 at 12:48:52AM +0200, Petr Baudis wrote:
> Dear diary, on Mon, Apr 18, 2005 at 11:53:57PM CEST, I got a letter
> where Russell King <rmk@arm.linux.org.uk> told me that...
> > Maybe Petr can improve the error handling, and incorporate it (or at
> > least some of it) into git-pasky
> 
> This does not need to touch git pull at all now; all the relevant logic
> can change in git merge (and git commit), and I'm hacking that now. It
> should be rather easy, I think.
> 
> I think I won't make git merge commit automatically - I think the user
> should get a chance to do a git diff on what is getting merged to check
> if everything is all right.
> 
> What is actually a little annoying is having to cd ,,merge and then
> back, though. I don't know, but the current pull-merge script does not
> bother with the temporary merge directory neither, even though Linus
> wanted it. Linus, do you still do? ;-)

In the case I highlighted, we don't want to end up having to require
user intervention.  This is a common case here, and was one which was
entirely scripted with BK.

Essentially, with BK, at 7am localtime each morning, I'd:

- update my baseline linux 2.6 tree
- for each working tree which may be pulled from
  - if the baseline is a superset
    - update working tree from baseline

The net result is that my workflow consisted entirely of:

1. commit whatever into working tree
2. test
3. send linus a pull request
4. repeat next day

The tree resynchronisation happened completely and entirely in the
background with no user intervention required at all.

With your suggested requirement for user intervention whenever there's
a merge, it means that this just isn't possible - you could automate
the pulls, but you need to ensure that you'd visited each and every
unmerged tree before the next day, or you don't script it at all and
do the whole thing manually.

Hey, I'm lazy, and that means that just won't get done, and my trees
will end up being horrendously out of date all the time.  But isn't
this precisely what we have computers and scripts for?

-- 
Russell King