On Thu, Aug 06, 2009 at 06:06:54PM +0200, Guido Günther wrote:
> > - dom-safe-pull: Updates the repository if it's fast-forward. Helps to
> > keep a clean history without a lot of administrative-merges.
> Wouldn't it make sense to have these two merged? Like:
>
> gbp-pull uri
>
> and
>
> cd $repo
> gbp-pull
Well, I see you argument for merging, but I doubt it would be actually
useful. In fact, all gbp users (and the users of our tools) are
forcibly users with git knowledge. As such, they are already used to
the distinction between a clone and a pull. Hence, I don't think
you'll gain anything in merging.
Also, the merge will actually be a big "if" at the beginning, choosing
among the two cases. So, also from an implementative point of view,
it's not clear to me what are you going to gain ...
> I'd also be great to built these things using the python gbp stuff in
> git-buildpackge. This would have the advantage that you get gbp config
> parsing for free and this way you could figure out the correct remove
> upstream and pristine-tar branches by looking at the configuration
> instead of "guessing". What do you think?
Seems like a good idea for pull (assuming you already have that git
part wrapper in the Python part). For the clone part I stand on my
observation: debcheckout already has some logics for checking out
Debian specific knowledge (i.e., the topgit stuff) which would be
unwise to duplicate. On that, I still suggest to make the checkout
script a wrapper invoking debcheckout.
BTW, the checkout scripts should rather be named "clone".
ACK on the rest.
Cheers
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
