[arch-dev-public] Git for the repos

[Ionut Biru]

On 08/25/2011 03:49 AM, Tom Gundersen wrote:
> On Thu, Aug 25, 2011 at 1:24 AM, Jan de Groot<jan at jgc.homeip.net>  wrote:
>> On Thu, 2011-08-25 at 00:15 +0200, Tom Gundersen wrote:
>>> Thanks to everyone involved with pushing this. I can not wait to get
>>> rid of SVN. Doing anything but the most trivial operations is a huge
>>> PITA.
>>
>> IMHO the only nice features I like from git that aren't in SVN are
>> bisect and the possibility to work on a local copy without being online.
>
> That, in addition to easy branching/merging, rebasing and reverting.
> This is all possible with SVN of course, but it becomes much more
> cumbersome.
>
>> The first part is something we don't use for packaging,
>
> We don't use it because we can't. I think we should though, especially
> for the non-trivial packages (that contain lots of patches or other
> tweaks). In order for bisection to be useful, we'd need to be able to
> do smaller patches, and that's not really practical without local
> commits.
>
>> the 2nd part is
>> not a very big issue if we make our server faster.
>
> Local commits have nothing to do with speed, at least not for me (once
> I push out my patches, I'm done for the day and go to make myself a
> coffee). Having local commits and simple branching/merging makes it
> much easier to make atomic commits, even if you are not sure if you
> want to push them to the repos yet (you want to test the package more
> first).
>

Local commits, pushing patches? Usually a common commit for packages 
don't have more than 2 lines of changes. Do you really need local 
commits for that, branching and merging?

What I found it interesting is that pro git are those who don't do a lot 
of packaging around here and have now only couples of packages in their 
maintenance.

You guys describe a workflow for a coding project and I understand how 
cool is git, but for packaging I don't see any reason to use it.

> At the moment I have the choice between making all my changes, testing
> the resulting package and committing with message "lots of churn". Or
> committing after each change, but then I'd only end up testing the
> package after pushing all the commits.
>

You are doing testing wrong. What about commit only after everything is 
tested?

> All that said, I think the most important point to keep in mind when
> comparing SVN and git is what are people used to and comfortable with.
> And people are going to be used to whatever upstream are using (that's
> after all where we get our patches, and where we do our bisection,
> submit our fixes, etc).
>
> I don't know what the global statistics are like as I only maintain a
> very few number of packages, but looking at the projects I have
> currently checked out (my own and related packages): 28 use git, 1 use
> CVS (but I can't deal with that and use a git mirror) and 1 use svn
> (that's us).
>
> I don't have a full understanding of the details of the proposed git
> solution, so all I'm saying is that I'm positive to the idea.
>
> Cheers,
>
> Tom


-- 
Ionuț