[PATCH] A few build.sh features

[Nicolai Hähnle]

Am Dienstag 17 Februar 2009 21:12:45 schrieb Dan Nicholson:
> On Tue, Feb 17, 2009 at 11:19 AM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> > Am Dienstag 17 Februar 2009 15:25:44 schrieb Dan Nicholson:
> >> On Mon, Feb 16, 2009 at 11:15 AM, Ian Romanick <idr at freedesktop.org> 
wrote:
> >> > -----BEGIN PGP SIGNED MESSAGE-----
> >> > Hash: SHA1
> >> >
> >> > Brian Rogers wrote:
> >> >> Here are a few patches that do things I found useful.
> >> >>
> >> >>
> >> >> 1. Specify -p to run 'git pull' on each component before building it.
> >> >
> >> > NAK.  You really want 'git fetch ; git rebase origin/<current
> >> > branch>'. git-pull really is the wrong thing to do here!  I have a
> >> > separate script that does this for everything in the tree.  The
> >> > function that does the fetch / rebase is:
> >>
> >> I don't know what version of git this showed up in, but you can just
> >> run "git pull --rebase" so it runs rebase instead of merge. So, you
> >> could probably just use that.
> >>
> >> On the other hand, I suspect that most people using build.sh are
> >> people that are just trying to keep up with xorg git and don't have
> >> patches that they're trying to keep on top of master. In that case, a
> >> simple pull would probably be fine for build.sh. I think anyone
> >> developing X probably has their own build setup not using build.sh.
> >
> > Please never, ever use this kind of logic. The people who want to start
> > with developing X have just as little clue about the intricacies of the
> > build system as the people who are only trying to track xorg git. So they
> > will look in the same places for tools to help with their needs.
> >
> > In a very real way, it is *more* important for those helper scripts to
> > work well for people who are actually doing the development, because
> > having good development tools helps attracts developers.
>
> If you want to write a patch that does whatever you're proposing, go
> for it. I'm making the case that Brian's patch is good enough to be
> committed right now. After all, git has far more intelligence about
> how to manage pulls than I do, so I'd rather keep that logic out of
> build.sh. It is not a git frontend, and just calling git-pull will
> work correctly more often than trying to manage the pull from
> build.sh. Using git-pull does not prevent anyone from developing X.

When will git pull --rebase fail for people who are just tracking git? But 
this is really not about the details of git anyway.

My point was more that your argument that developers are not an important 
consideration for those kinds of helper scripts "because developers don't use 
them anyway" is a bit misplaced because developers tend to learn the ropes 
from whatever is easily available online, including those helper scripts.

> Furthermore, I'm saying that people that are already using the git
> workflow for development know how they want to handle pulls and
> probably are managing it already. Do you use build.sh to manage your
> pulls/build for mesa?

Well, for Mesa itself scripts wouldn't be too useful for me since I just love 
handling many branches in my own work, but I use it to manage everything else 
(I build all of X myself because I got tired of problems with a mixture of 
distro packages with git builds). And yes, those other packages might have a 
handful custom patches from time to time.

cu,
Nicolai