Re: Proposed git migration plan
Hi Sandro,
> I rarely need to use log, and I used to work on the svn repo on a 56k
[..]
that you rarely use log is (a) not relevant to the people who would use it
and (b) quite possibly highly influenced by the fact that svn log is so slow
and painful. Remember that the tool can shape the user.
>> Cheap local branches which let you pill up work in progress patches /
>> rewrite without having to keep several copy of the same svn repo. The
>> branches in git are just a name pointing to a commit in the tree.
>>
>> The stash, which let you save your uncommited changes and come back to
>> them later (think of it as lightweight branches). That is really nice
>> when you have to interrupt your workflow, stash it, handle the
>> interrupt, reapply your stash and resume work.
>>
>> Tags can be signed with gpg. They are a pointer to a commit just like
>> branches, and hence don't force you to do a full copy to create a tag.
>>
>> Switching between branches is a breeze and does not need network access
>> either.
>
> I was referring to attractive features of git in regarding to Debian
> packaging
these *are* things that are attractive for packaging work.
* I use branches extensively when experimenting with changes to packaging.
What gets pushed might not look like that was what happened, but the branch
was there along the way.
* I use stash quite a lot to be able to better articulate the work I'm doing
in commits and as testing smaller changes. I even used it the other day in
my little case story on git-buildpackage.
* (signed tags are probably an inherently good thing, but are really only
nice to have for us at this stage)
* Because I use branches a lot, I switch between them, rebase work and merge
it quite a lot.
> well, let's first see the list of problems/features we have/want and
> then let's talk later of the solutions to them, not the other way
> around
This discussion has been had many times before over many years. Of late, the
difficulty in switching VCS has been the blocker. I don't think there are
many people who are unconvinced that switching makes sense from a technical
or workflow perspective. I also don't think there are many people who are
interested in rehashing the entire discussion yet again. It's almost as
boring as systemd discussions.
Fundamentally, one of the problems is svn. Even if you don't want the thigns
git offers, just use git as a new version of svn spelt differently, then
you'll still be able to work effectively on packages and you only have two
new commands you need to use (assuming you aren't already using debcheckout
and debcommit, of course).
Subversion lacks features that make packaging work much easier to do. The
tools shape what you do -- you said that you don't use branches or log much
and that's going to be partly because they are so crap in svn. In the past,
I didn't use these features either when I was only using svn. Now I know
they are useful things, I use them quite a lot because they are so easy and
efficient in git. When I go back to working on svn projects, I realise how
much the tool is deficient and how much the deficiencies of the tool lead to
deficiencies in process.
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ stuart@nanonanonano.net
Debian Developer http://www.debian.org/ stuart@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Reply to: