[Geany-devel] Git switch

Jiří Techet techet at xxxxx
Thu Jun 17 00:16:36 UTC 2010


On Thu, Jun 17, 2010 at 00:38, Lex Trotman <elextr at gmail.com> wrote:
> <snip>
>
>> Just a few more comments related to the possible switch. First, just
>> an observation - the people who said they don't mind are those who
>> have write access to SVN.
>
> Thats a fair comment, probably because they are the ones who will be
> most affected by the change, who will use it the most,  and will have
> to change their workflow the most.  Humans don't like change, even (or
> especially) programmers who are exposed to lots of it.

That's a fair comment too. It really depends on the percentage of work
being done by the core developers. If the number of patches coming
from outside is marginal, then the time savings gained by switching to
git are marginal too and vice versa. On the other hand, you might get
more external contributors if you make it easier for them to submit
patches by switching to git - but these are only speculations of
course.

>
>  I agree that for them the switch is much
>> less important - they can create their branches to develop and back up
>> the work in progress and for their own development the current
>> workflow is OK. The current situation is worse for external
>> contributors who don't submit their patches so often to have SVN
>> access. They either don't have their work backed up, or they have to
>> create their own repository e.g. at gitorious as I did. When they
>> finish their work, they can't just tell "please pull from here" but
>> have to submit their patches by email. This is harder for the
>> maintainers too - they have to manually apply the patches from the
>> email instead of just "git pull".
>
> This workflow is only likely when changes are submitted by well known
> and experienced submitters.  Otherwise it will be import to local
> clone, check and edit it some, then commit and push upstream, so the
> problems you describe below will still exist AFAICT.  Many patches get

Depends what you do with it. You can keep the contributor's commits
and just add your commit with fixes. Or you can rebase and squash the
fixes with the contributor's commits. You can also chose if you make
the commit as yourself or as the contributor. You have just more
freedom.

> the response, "committed but I changed xxx".  Also you don't want to
> pull every daily backup commit from the user into the main repository.

Sure, the contributor should tell you when he's done and request the
pull only when the code is in a reasonable state. He might also
consider squashing the commits in his history so you don't see his
"internal" bugfixes.

>
>  Finally, it will be the maintainer
>> who makes the commit and the information about the original committer
>> is lost with SVN - with git you see every single commit author (this
>> means you have to add some "thanks to" to the commit message for SVN -
>> this work would be eliminated with git). Finally, you can forget about
>> updating ChangeLog - this can be generated automatically by git (GNOME
>> libraries usually have one pre-git ChangeLog and then a changelog
>> automatically generated from the git history during "make distcheck").
>> So what I want to say here is that while the core developer's
>> development work won't be affected by the switch much, the
>> collaboration with external developers will improve considerably.
>>
>> On the other hand you are right - git is a bit harder to use and there
>> will be many "doh" moments. The learning curve is steeper that with
>> SVN but when you learn it (I really don't want to make an impression
>> I'm an expert here - git still surprises me sometimes),
>
> Now thats the last thing you want from a VCS, surprise, what you want
> is stability, ease of use and simplicity, power and speed are nice to
> haves only if the preceding are there.

Totally agree and this was exactly my point. I was trying to mention
all positive things I see about git and all the negatives as well -
all of them have to be taken into account. The positives are clear and
from the negatives I see only the effort spent to convert the SVN
repository to git (this is where I tried to help a bit) and then the
transitional time until everyone gets used to git and the slightly
different way of doing things.

>
> I understand from reading the Advanced Git book that it is reasonably
> hard to actually lose data, but it also looks rather hard to recover
> from a mistake by an inexperienced user.

Depends how the repository you push to is set up. For GNOME git
repositories the master branch cannot be "undone". But you can
(fortunately) delete other branches so this is where you could lose
data. But remember that git is a distributed VCS so if you do
something really disastrous, there is a very good chance that someone
else has cloned or pulled recently and he can provide his clone for
the recovery. (Say goodbye to your SVN history if the sourceforge
servers get corrupted and you don't have a backup. With git you don't
care - you and many others have more or less up to date clone of it.)

Cheers,

Jiri



More information about the Devel mailing list