What's the best way to make my company migrate to Git?

What's the best way to make my company migrate to Git?

[Daniele Segato]

Hi,

I work as a Developer (mainly Java and web applications) and I'd like
to introduce my company to the use of Git.
I don't have much time to allocate on this matter, so the elapsed for
applying any of your suggestion will probably go from weeks to months
:)

If I manage to migrate I'll be only able to start using git with the
new projects, I don't think that old project will be easily migrated
to Git (unless not until it will be widely accepted and learned by
everyone).
There are, more or less, 30 developers working in different projects
from junior to senior developers.


We use Subversion as versioning system.

The developers are used to work with Eclipse (an open source IDE) that
happen to have a Subversion plugin and they all works on Windows
platform.
I'm the only one who work on a Linux box and use git-svn from command
line as a front end to Subversion.
I already know of (some of) the advantage of using git, but I'm also
aware that it's not that easy to change other people mind on what they
used for years.
So I need to be really persuasive on the advantage of using it, and I
think you can help me on this.

I think that to introduce git in my company I should at least go throw
this 5 points:
1. prepare a project management web application easy to use and
mantain (like github or gitorious for instance) on one of our intranet
servers.
2. achieve knowledge on the git-submodule and to handle binary files
versioning (mainly third party java libraries that are in every
project)
3. learn what I had to know to use Git on windows (i never did this),
and find some user friendly AND graphical tool to propose (i know
there is a Git-eclipse module but I don't know if it is considered
stable and/or full featured)
4. give my managers some reason to migrate/begin to use Git instead of
Subversion
5. do some "school" to other developers



I think there are many of you that went throw this before and I'd like
to have some advice on the 5 point of the list above.

Can you also tell me if you think there is some risk in migrating and
what kind of difficult I could encounter in the process?
For example: like any company we have a proxy and a firewall..
For example: if i had to commit something working from home I connect
to the Subversion via HTTPS and commit, with Git I should have ssh
access which is something that I probably will not have.


I can summarize all this email with just this question: What's the
best way to make my company migrate to Git?

thank you all for any advice.

Daniele

Re: What's the best way to make my company migrate to Git?

[Jakub Narebski]

Daniele Segato <daniele.bilug@gmail.com> writes:

[...]
> I think that to introduce git in my company I should at least go throw
> this 5 points:

> 1. prepare a project management web application easy to use and
>    mantain (like github or gitorious for instance) on one of our
>    intranet servers.

Note that while Gitorious (in Ruby), InDefero (in PHP), and Girocco
(with gitweb, Perl + shell script, used by http://repo.or.cz) are open
source, GitHub is not.  There is GitHub:FI if you want [self] hosted
GitHub-alike, but it is proprietary and it is not cheap.

There is also Gerrit, a web based code review system, which runs in
any standard Java servlet container.

[...]
> Can you also tell me if you think there is some risk in migrating and
> what kind of difficult I could encounter in the process?
> For example: like any company we have a proxy and a firewall..
> For example: if i had to commit something working from home I connect
> to the Subversion via HTTPS and commit, with Git I should have ssh
> access which is something that I probably will not have.

Actually with never Git you can push and pull via HTTP(S) natively,
thanks to git-http-backend.  With older Git you had to use HTTP as
"dumb" protocol, using HTTPS + WebDAV to push (note that for "dumb"
servers git-update-server-info must be run, e.g. via a hook).

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: What's the best way to make my company migrate to Git?

[Andrew Sayers]

Hi Daniele,

I'm a developer getting towards the end of introducing my company to 
Git.  Here are some thoughts based on the (mis)steps I took.


I found that advocating specific steps wasn't that effective - I just 
came across as being pushy and hard to work with.  It was more effective 
to politely show off what I could do with git-svn, and let people get 
jealous enough to work the "how" out for themselves.  Here are some 
examples:

I would quietly bisect a hard-to-fix bug, then say "if it's any help, 
git tells me it was introduced by so-and-so in revision N".  Sometimes 
it was no help, but sometimes it was enough to provoke the appropriate 
"aha!" for the bug.

I would nonchalantly use as many git features as I could while showing 
people my work.  So "here's the diff for my work... grr whitespace ... 
hang on I'll add `-w`... anyway, these are the REAL differences...". The 
fact it was all in glorious technicolour went without mention.

When we had a big merge that nobody was looking forward to, I said "let 
me do it!  It'll give me a chance to practice my git-fu".

When I used svn on somebody else's command-line, I'd blame the mistakes 
I made on being spoiled by Git.  So "I'll just do an `svn log`... argh 
no!  Control-C!  Control-C!  Right, `svn log | less`... my bad, git 
pipes to less automatically."


Over the course of a few months, people became convinced that Git was 
something that makes you more productive.  Our lead developer had a go 
with git-svn for a while, before our boss decided we should all make the 
switch.

I tried to make git-svn as painless as possible with some svn-like 
aliases and a cheatsheet, which I'd be happy to upload if the list could 
suggest a good place to put a PDF and some text.

The move worked for a while, but it turned out that one-and-a-half git 
experts supporting the rest of the team wasn't enough to stop people 
from making rookie mistakes like `git merge`ing into an SVN branch with 
unpushed changes.  We had to accelerate our move to git on the server, 
and I got a lot of exercise and not much work done that month as I 
dashed from desk to desk.

Things gradually calmed down as people got more comfortable with git. 
But I expect to be occasionally called over for a long time as people 
learn new tricks - "how do I, like, cherry-unpick a single commit?"

	- Andrew Sayers

Re: What's the best way to make my company migrate to Git?

[Daniele Segato]

Il giorno sab, 22/05/2010 alle 11.52 +0100, Andrew Sayers ha scritto:
> Hi Daniele,
> 
> I'm a developer getting towards the end of introducing my company to 
> Git.  Here are some thoughts based on the (mis)steps I took.

thanks


> I found that advocating specific steps wasn't that effective - I just 
> came across as being pushy and hard to work with.  It was more effective 
> to politely show off what I could do with git-svn, and let people get 
> jealous enough to work the "how" out for themselves.  Here are some 
> examples:
> 
> I would quietly bisect a hard-to-fix bug, then .... [big-snip]
> 
> Over the course of a few months, people became convinced that Git was 
> something that makes you more productive.  Our lead developer had a go 
> with git-svn for a while, before our boss decided we should all make the 
> switch.

I'm already doing this stuff..
but i'm in the *lead developer* position now, so, if I say that they had
to start using git (at least my team) they will..

But I don't thing going throw git-svn is a good idea.. it has some
limitation over the normal git and you have to be more careful about
rebasing (interactive) and you should avoid merge (as much as I
understood it).

I'd like to make the big move going directly to git.
I don't think i'll had the time to do it now, the new project is already
going on.. but I'd like to have all prepared and ready for the next
one :)


> I tried to make git-svn as painless as possible with some svn-like 
> aliases and a cheatsheet, which I'd be happy to upload if the list could 
> suggest a good place to put a PDF and some text.

I think that may be useful to many.
In my specific case it wouldn't help, since everybody is used to click
around with the git-svn graphical interface, they don't even know the
svn commands to do those stuffs. They are almost all windows-minded :)
you know: "writing when you can click? why?" - I use to think the
opposite :)

What i mean here is: git should be graphical, at least at the beginning,
better if inside eclipse itself.

> The move worked for a while, but it turned out that one-and-a-half git 
> experts supporting the rest of the team wasn't enough to stop people 
> from making rookie mistakes like `git merge`ing into an SVN branch with 
> unpushed changes.  We had to accelerate our move to git on the server, 
> and I got a lot of exercise and not much work done that month as I 
> dashed from desk to desk.

that's what I fear, because we usually are overladen of work and we
can't stand some slow down if it last more then 2-3 days in a row.
If that happen I'll be the one who will be blamed for the issue :)

> Things gradually calmed down as people got more comfortable with git. 
> But I expect to be occasionally called over for a long time as people 
> learn new tricks - "how do I, like, cherry-unpick a single commit?"

Well.. that's ok.. the problem is with things I don't know about git
like: what's the best way to manage binary files? how do I manage
submodules? and so on... if I don't know how to properly reply to those
questions I'll obtain the opposite effect :)

Thanks for your experience,

Daniele

Re: What's the best way to make my company migrate to Git?

[Daniele Segato]

Il giorno ven, 21/05/2010 alle 08.54 -0700, Jakub Narebski ha scritto:
> Daniele Segato <daniele.bilug@gmail.com> writes:
> 
> [...]
> > I think that to introduce git in my company I should at least go throw
> > this 5 points:
> 
> > 1. prepare a project management web application easy to use and
> >    mantain (like github or gitorious for instance) on one of our
> >    intranet servers.
> 
> Note that while Gitorious (in Ruby), InDefero (in PHP), and Girocco
> (with gitweb, Perl + shell script, used by http://repo.or.cz) are open
> source, GitHub is not.  There is GitHub:FI if you want [self] hosted
> GitHub-alike, but it is proprietary and it is not cheap.
> 
> There is also Gerrit, a web based code review system, which runs in
> any standard Java servlet container.

Thanks for the list.
Yes I know GitHub isn't Open Source, and just for this reason it can't
be an option, but it's features are the one I'm looking for.
I never heard of some of the project you listed here, I'll give them a
try.
Did someone worked with some of them and have a review or an opinion
about them?

> 
> [...]
> > Can you also tell me if you think there is some risk in migrating and
> > what kind of difficult I could encounter in the process?
> > For example: like any company we have a proxy and a firewall..
> > For example: if i had to commit something working from home I connect
> > to the Subversion via HTTPS and commit, with Git I should have ssh
> > access which is something that I probably will not have.
> 
> Actually with never Git you can push and pull via HTTP(S) natively,
> thanks to git-http-backend.  With older Git you had to use HTTP as
> "dumb" protocol, using HTTPS + WebDAV to push (note that for "dumb"
> servers git-update-server-info must be run, e.g. via a hook).

Oh, that's interesting. I wasn't aware of this.
I'll go read some doc about this new feature, thanks.

Daniele

Re: What's the best way to make my company migrate to Git?

[Jakub Narebski]

Dnia sobota 22. maja 2010 17:58, Daniele Segato napisał:
> Il giorno ven, 21/05/2010 alle 08.54 -0700, Jakub Narebski ha scritto:
> > Daniele Segato <daniele.bilug@gmail.com> writes:
> > 
> > [...]
> > > I think that to introduce git in my company I should at least go throw
> > > this 5 points:
> > 
> > > 1. prepare a project management web application easy to use and
> > >    mantain (like github or gitorious for instance) on one of our
> > >    intranet servers.
> > 
> > Note that while Gitorious (in Ruby), InDefero (in PHP), and Girocco
> > (with gitweb, Perl + shell script, used by http://repo.or.cz) are open
> > source, GitHub is not.  There is GitHub:FI if you want [self] hosted
> > GitHub-alike, but it is proprietary and it is not cheap.
> > 
> > There is also Gerrit, a web based code review system, which runs in
> > any standard Java servlet container.
> 
> Thanks for the list. [...] I never heard of some of the project you
> listed here, I'll give them a try.

https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools should
be a good source of information about miscelanous git tools.

> Did someone worked with some of them and have a review or an opinion
> about them?

That I can't help you with.

-- 
Jakub Narebski
Poland

Re: What's the best way to make my company migrate to Git?

[Joshua Jensen]

  ----- Original Message -----
From: Daniele Segato
Date: 5/22/2010 9:58 AM
>> There is also Gerrit, a web based code review system, which runs in
>> any standard Java servlet container.
> Did someone worked with some of them and have a review or an opinion
> about them?
I use http://redmine.org/.  It has Git support and generally works 
great.  There is a decent set of plug-ins for it, too.

I set up Gerrit, and I really like what I see there.  Not only does it 
have code review functionality built in, it also knows how to merge 
changes automatically (as I understand it) when everyone buys off on the 
change.

Josh

Re: What's the best way to make my company migrate to Git?

[Lin Mac]

2010/5/22 Andrew Sayers <andrew-git@pileofstuff.org>:
> Hi Daniele,
>
> I'm a developer getting towards the end of introducing my company to Git.
>  Here are some thoughts based on the (mis)steps I took.

I'm a developer who had started to learn git for 1 and a half year,
and start using git for half year. It took me 1 year to make myself
believe that I am ready to use git as my daily working project.
Although I also wants to push my company to use git, but I prefer to
start from one. I "forced" one of my colleague to use git -- I only
use git to share code with him...

BWT, we use svn as well.

> I found that advocating specific steps wasn't that effective - I just came
> across as being pushy and hard to work with.  It was more effective to
> politely show off what I could do with git-svn, and let people get jealous
> enough to work the "how" out for themselves.  Here are some examples:
>
> I would quietly bisect a hard-to-fix bug, then say "if it's any help, git
> tells me it was introduced by so-and-so in revision N".  Sometimes it was no
> help, but sometimes it was enough to provoke the appropriate "aha!" for the
> bug.
>
> I would nonchalantly use as many git features as I could while showing
> people my work.  So "here's the diff for my work... grr whitespace ... hang
> on I'll add `-w`... anyway, these are the REAL differences...". The fact it
> was all in glorious technicolour went without mention.
>
> When we had a big merge that nobody was looking forward to, I said "let me
> do it!  It'll give me a chance to practice my git-fu".
>
> When I used svn on somebody else's command-line, I'd blame the mistakes I
> made on being spoiled by Git.  So "I'll just do an `svn log`... argh no!
>  Control-C!  Control-C!  Right, `svn log | less`... my bad, git pipes to
> less automatically."
My colleague shows amazing insterest on "git add -p".
"see? you could decided what to add to the commit and what no to. you
don't have to always clean the code before you commit...."
With git-svn, he started to use git since then.

> Over the course of a few months, people became convinced that Git was
> something that makes you more productive.  Our lead developer had a go with
> git-svn for a while, before our boss decided we should all make the switch.
>
> I tried to make git-svn as painless as possible with some svn-like aliases
> and a cheatsheet, which I'd be happy to upload if the list could suggest a
> good place to put a PDF and some text.
>
> The move worked for a while, but it turned out that one-and-a-half git
> experts supporting the rest of the team wasn't enough to stop people from
> making rookie mistakes like `git merge`ing into an SVN branch with unpushed
> changes.  We had to accelerate our move to git on the server, and I got a
> lot of exercise and not much work done that month as I dashed from desk to
> desk.
>
> Things gradually calmed down as people got more comfortable with git. But I
> expect to be occasionally called over for a long time as people learn new
> tricks - "how do I, like, cherry-unpick a single commit?"
That's what I'm affraid, so I started from one :p

Even though, I'm often called for questions like "how do I check out
this?" "how do I do 'svn revert')..., and I think it will last
forever.

Before I can really start to use git, I used to joke "git is for gods
like Linus, not for mortal". Of course I don't think so now, but what
I want to say is that git have harder learning curve than svn (at
least I think so). commands are sometimes confusing, and it is very
possible that users would screw thing up if they don't pay attention
when using it.

For example:

It take times to explain the difference of "git reset", "git reset
HEAD^" and "git reset --hard", and "git add <new_file>", "git add
<old_file>", and "git add -p" (why "git add -p" doesn't add my new
file/permission changes....blablabla).

And my first time trying git failed because I found all my previous
commit are "gone", "disappearred", "losted". You could imaging how
frustrated I am. Though latter I found that my commits are not gone,
but dangling!! I commited on no-branch state. But that stop me from
learning git for some time...

Recently, I used git branch "extensively" - I have a lot of branches,
branch have branches, such that one of which became a "tree". To
rebase the "tree" to another base takes 15~20 rebase. It is
error-prone, and I find nothing could release me from such situation.
I have to change my way to add branch.

Have someone experienced with git would greatly reduce the effort and
inconvenience.

Starting from git-svn would be a goot starting point. If people could
be benefit from git-svn, switching to git wouldn't be a big problem.

Best Regards,
Mac Lin

Re: What's the best way to make my company migrate to Git?

[Andrew Sayers]

Hi Daniele,

I agree that a lead developer moving a team from graphical SVN is a
different problem.  I don't think git-gui does SVN, I couldn't work out
how to make TortioseGit work with SVN, and I doubt EGit will like SVN
very much.

You're also right that git-svn has limitations with merging and
rebasing.  Specifically, don't use them unless you know what you're
doing - see `man git-svn` for more.  Git-svn is also less
newbie-friendly than either git or svn on its own.

Having said that, I'd still recommend you try moving a few developers to
git during the lifetime of your current project.  In my experience,
those developers most willing to try something new in the middle of a
project are also the ones that want to get hacking right away on a new
project.  Getting even one developer to start migrating now will be good
practice for you, and will double the number of eyeballs looking at git
issues later on.

Slowing down for less than a week is a very ambitious target - I think
we had about 2 weeks of noticeably reduced productivity, even when I'd
done a lot of work to spread the pain over several months.  Starting git
with a new project might reduce that time a bit - for example, there's
no chance of uncommitted work in an SVN checkout failing to make the
switch.  But it can be more expensive in the long-run, because you have
to make all of your architectural decisions based on what you can
explain to SVN users on day one - for example, my team took about 2-3
weeks to understand how a commit is different from a push, and why they
should care.  But because they understood before we made the big leap,
we were able decentralise our workflow as much as we needed.

If you do go via git-svn, I'd recommend you read `man git-rerere` and
set the config option "rerere.enabled" to "true" for all users.  I
needed to blow away a few messy merges to fix rookie mistakes, and
`git-rerere` would have made a painful experience much easier.

Even if you go straight into git, you might think about finding/writing
hooks to synchronise an SVN repository and a git repository.  There will
probably be a few people you can't switch right away - e.g. a sysadmin
that would need months to rewrite all his scripts, or a designer that
doesn't want to learn a different tool just for your team.  Providing a
semi-functional legacy interface for those people will let you raise the
pressure on them more gradually.

I forgot to mention education in my previous post, which was actually
one of the biggest problems during the move.  I was surprised how
everyone had such different learning styles - some wanted to learn the
theory then be left alone, some wanted to be told each solution at the
moment they faced the problem, some wanted to learn by watching how I
worked, etc.  The only real pattern seems to be that the busier people
are, the more they like to feel they're pulling information out of you,
and the less receptive they are when you push information at them.  I
muddled through by trying to give everyone more of whatever they each
reacted best to.

The biggest problem I had with teaching git to SVN users was something I
still have difficulty putting into words.  SVN users focus on branches
as the centre of their development history, and see commits as these
funny little things that punctuate the progress of their branches.  But
git users focus on commits (or even trees) as the centre of their
history, and see branches as one of many handy labels that track them.
The distinction is subtle, but it affects a lot of the expectations
people have.  For example, SVN users like to think of a commit as being
"on a branch", meaning that it marks an event in the lifetime of one SVN
directory.  To this day, I don't think I've really communicated why you
can only say a git commit is "reachable from the tip of zero or more
branches".

Because my team needed time to unlearn a lot of these SVN issues, I
didn't try to push much deep git tech at them early on.  A few months
into the move though, it's starting to seem like a better idea.  One of
my team-mates got me to start reading "Version Control with Git"
(http://oreilly.com/catalog/9780596520137) - from what I've seen so far,
I'd definitely recommend it to people that like book-learning and are
ready to learn git without bringing their old SVN baggage.  On the other
hand, you can cobble the same information together from various online
sources if you prefer (http://book.git-scm.com/ is a personal favourite).

	- Andrew Sayers

Re: What's the best way to make my company migrate to Git?

[Andrew Sayers]

On 23/05/10 10:11, Lin Mac wrote:
> My colleague shows amazing insterest on "git add -p".
> "see? you could decided what to add to the commit and what no to. you
> don't have to always clean the code before you commit...."
> With git-svn, he started to use git since then.

I had a similar experience - a colleague with a habit of making huge
commits happily cleaned up his act when he was shown this.  More
generally, it seems like everyone reacts to the list of git features
with "that one's weird, I don't care about that one, that one's
irritating, WHERE HAS THIS BEEN ALL MY LIFE!, don't care about that one,
that one doesn't make sense...".  A major part of selling people on git
is finding the one thing that they each immediately love.

	- Andrew

Re: What's the best way to make my company migrate to Git?

[Daniele Segato]

Hi David,
I'm quoting all your email with no cleaning here because I think you did
not included the git mailing list as a mistake.

Il giorno dom, 23/05/2010 alle 22.09 +0200, David Bainbridge ha scritto:
> Hi Daniele,
> 
> On 21 May 2010 16:55, Daniele Segato <daniele.bilug@gmail.com> wrote:
> > I work as a Developer (mainly Java and web applications) and I'd like
> > to introduce my company to the use of Git.
> 
> This is a trend that I am seeing in the company I work for too.
> 
> > There are, more or less, 30 developers working in different projects
> > from junior to senior developers.
> 
> > We use Subversion as versioning system.
> >
> > The developers are used to work with Eclipse (an open source IDE) that
> > happen to have a Subversion plugin and they all works on Windows
> > platform.
> > I'm the only one who work on a Linux box and use git-svn from command
> > line as a front end to Subversion.
> 
> So you are in a minority ... it's useful to recognise this. Others in
> your company may not share your views.

I KNOW other will not share my view. Another team leader with more
experience then me already told me that "moving to something different
of subversion is of no interest to him because he don't want to learn
something new"[1]. This happened during a random chit-chat when I
casually asked: "what would you think about moving from Subversion to
something more advanced?"
The topic dropped suddenly after it, I did not pushed it further :)

> > I already know of (some of) the advantage of using git, but I'm also
> > aware that it's not that easy to change other people mind on what they
> > used for years.
> 
> Not only that - it depends who decided to use Subversion and why. Was
> it a management decision, or was the decision made entirely by
> developers?

I think that the decision has been made a lot of time ago without any
particular reasons. Probably that just was the more diffused versioning
system, the one used and learned by almost all the developers around
here. (aka: you don't have to teach it to new employers, they usually
already know)

> Is Subversion used only during development or do you maintain the
> products in Subversion? In other words, is Subversion seen as a secure
> central repository for the company's intellectual property? If so,
> they may not take kindly to a DVCS unless it is deployed with some
> degree of centralization.

Both development and maintenance. Every developer signed an agreement to
not give any company sensitivity information away without the
authorization of the company itself, so I don't see any particular
difference in security between Git and Subversion. May be I missed the
point here anyway.

> Do your products have a short life time (less than a year) or do they
> have to be maintained over several years? If it is over several years
> then Git and Svn may also have to co-exist in the company for that
> time, and people may have to use both depending on what they are
> working on.

Again: both short and long life time projects.. I know they will have to
co-exist but I think that if the company get used to git will not go
back to subversion as I wouldn't unless given with no choice.

> Are there any security issues that need to be addressed? - especially
> if everyone is working on laptops and taking them home, or traveling
> with them.

Everybody work on laptop, but I don't think I get the issue here: be in
danger of someone stealing source code? Doesn't this have the same
security issue with subversion? (but the fact that with git you get all
the repository and not just a single version).

> I guess I am saying that you need to look at the extent to which the
> COMPANY is dependent on Subversion. This will affect your decision
> about who to talk to about migration - and who you will need to
> convince.

Usually in my company new technology comes from the developers
themselves, they have to promote and propose the idea themselves.
Managers don't care how you do thing technically. So if I really want to
introduce git I'll had to do it in my spare time: building up the
infrastructure to made migration easier as possible, be sure to be able
to handle all the issue that I can encounter and then begin to made my
team work with git.
After that I can show my manager that I increased the productivity and
that could made them decide to migrate the other teams too.

> All of which is aimed at item 4 in your list.
> 
> > 4. give my managers some reason to migrate/begin to use Git instead of
> > Subversion
> 
> Training, migration and so on will take time and therefore cost money.
> Yes, you can do it without management support but it will be a lot
> easier if you do have their support. Get this wrong and you may be
> seen by management as putting development at risk - and with only 30
> developers, they may see this as putting the company itself at risk.

I had to *start* it without the management support. And, to avoid the
risk of being seen as a risk I had to do this in my spare time. :)

> In the end the company has to ship products to make a profit, so
> focussing on that always helps :-) In small companies 'the management'
> may be the shareholders too!

Yes, that's the harder part.. I can see the benefit of using git for a
developer but I can't see the benefit for my manager.
Productivity is hard to quantify.

> This is an interesting topic that I guess affects more than a few of
> us that subscribe to this list.
> 
> Also, I must admit that I reacted to the way in which you expressed
> the question ... What's the best way to MAKE my company migrate to
> Git? This has a very evangelical tone to it, so I would tend to
> express this in other terms when discussing it in your company.
> 
> Answering your question is more about people than the tool itself.

Probably you are right, but I wrote here exactly to ask for advice on
the best way to propose git.
I know that the "evangelist" method will not lead me anyway within the
company, I'd like to have some suggestion on that :)

> 
> Hope this helps. And do keep us updated ... this is interesting!

I'll do.

> Regards
> 
> David Bainbridge


Thanks David for your suggestions.

Regards,
Daniele Segato

[1] a note: this may sound like "I don't care about new technology".
That's not exactly the case, you can read it like this: "I already have
a lot of thing to do (too much thing) and I can't add anything else
without going crazy".

Re: What's the best way to make my company migrate to Git?

[Daniele Segato]

On Sun, May 23, 2010 at 4:52 PM, Andrew Sayers
<andrew-git@pileofstuff.org> wrote:
> I agree that a lead developer moving a team from graphical SVN is a
> different problem.  I don't think git-gui does SVN, I couldn't work out
> how to make TortioseGit work with SVN, and I doubt EGit will like SVN
> very much.

EGit do not work with git-svn, it probably work just fine with "pure" git tough.
I've seen TortoiseGit, it work very well but I found it somewhat more
difficult then the command line:
probably because I don't know where to find the command i daily use on git.
I extensively use git grep and probably there isn't anything like it
in TortoiseGit.

> You're also right that git-svn has limitations with merging and
> rebasing.  Specifically, don't use them unless you know what you're
> doing - see `man git-svn` for more.  Git-svn is also less
> newbie-friendly than either git or svn on its own.

Yes, that's why I'd like to skip git-svn and go directly with git,
unless I know the people I'm teaching to can
handle it.

> Having said that, I'd still recommend you try moving a few developers to
> git during the lifetime of your current project.  In my experience,
> those developers most willing to try something new in the middle of a
> project are also the ones that want to get hacking right away on a new
> project.  Getting even one developer to start migrating now will be good
> practice for you, and will double the number of eyeballs looking at git
> issues later on.

Yeah, there is one developer tired of Subversion that asked me to
teach him git(-svn).
He's not in my team but I think it's a starting point :)

> Slowing down for less than a week is a very ambitious target - I think
> we had about 2 weeks of noticeably reduced productivity, even when I'd
> done a lot of work to spread the pain over several months.  Starting git
> with a new project might reduce that time a bit - for example, there's
> no chance of uncommitted work in an SVN checkout failing to make the
> switch.  But it can be more expensive in the long-run, because you have
> to make all of your architectural decisions based on what you can
> explain to SVN users on day one - for example, my team took about 2-3
> weeks to understand how a commit is different from a push, and why they
> should care.  But because they understood before we made the big leap,
> we were able decentralise our workflow as much as we needed.


Probably it will be a svn-like architecture from the beginning, I'll
not dare to move it any
further until I know that developers are ready to handle it properly :)
I'm not sure myself I can manage a workflow different from subversion
(1 main server and N developers
pushing to it) because I never did anything different.


> If you do go via git-svn, I'd recommend you read `man git-rerere` and
> set the config option "rerere.enabled" to "true" for all users.  I
> needed to blow away a few messy merges to fix rookie mistakes, and
> `git-rerere` would have made a painful experience much easier.

I did not know about this.. That's really interesting, I just enabled
it in my local repo.
Thanks for the hint!

> Even if you go straight into git, you might think about finding/writing
> hooks to synchronise an SVN repository and a git repository.  There will
> probably be a few people you can't switch right away - e.g. a sysadmin
> that would need months to rewrite all his scripts, or a designer that
> doesn't want to learn a different tool just for your team.  Providing a
> semi-functional legacy interface for those people will let you raise the
> pressure on them more gradually.

Sysadmins shouldn't be a problem, we don't have sysadmins here and if
the custumer
require us to use his own versioning system we can't push them to git,
so I think that wouldn't be
a proble for us. But that's a good point.

> I forgot to mention education in my previous post, which was actually
> one of the biggest problems during the move.  I was surprised how
> everyone had such different learning styles - some wanted to learn the
> theory then be left alone, some wanted to be told each solution at the
> moment they faced the problem, some wanted to learn by watching how I
> worked, etc.  The only real pattern seems to be that the busier people
> are, the more they like to feel they're pulling information out of you,
> and the less receptive they are when you push information at them.  I
> muddled through by trying to give everyone more of whatever they each
> reacted best to.

Thanks, I'll keep that in mind when I'll face the big switch.


> Because my team needed time to unlearn a lot of these SVN issues, I
> didn't try to push much deep git tech at them early on.  A few months
> into the move though, it's starting to seem like a better idea.  One of
> my team-mates got me to start reading "Version Control with Git"
> (http://oreilly.com/catalog/9780596520137) - from what I've seen so far,
> I'd definitely recommend it to people that like book-learning and are
> ready to learn git without bringing their old SVN baggage.  On the other
> hand, you can cobble the same information together from various online
> sources if you prefer (http://book.git-scm.com/ is a personal favourite).


Thanks about the book suggestion, I'll give them both a try!

Regards,
Daniele Segato

Re: What's the best way to make my company migrate to Git?

[Michael J Gruber]

Andrew Sayers venit, vidit, dixit 22.05.2010 12:52:
> Hi Daniele,
> 
> I'm a developer getting towards the end of introducing my company to 
> Git.  Here are some thoughts based on the (mis)steps I took.
> 
> 
> I found that advocating specific steps wasn't that effective - I just 
> came across as being pushy and hard to work with.  It was more effective 
> to politely show off what I could do with git-svn, and let people get 
> jealous enough to work the "how" out for themselves.  Here are some 
> examples:
> 
> I would quietly bisect a hard-to-fix bug, then say "if it's any help, 
> git tells me it was introduced by so-and-so in revision N".  Sometimes 
> it was no help, but sometimes it was enough to provoke the appropriate 
> "aha!" for the bug.
> 
> I would nonchalantly use as many git features as I could while showing 
> people my work.  So "here's the diff for my work... grr whitespace ... 
> hang on I'll add `-w`... anyway, these are the REAL differences...". The 
> fact it was all in glorious technicolour went without mention.
> 
> When we had a big merge that nobody was looking forward to, I said "let 
> me do it!  It'll give me a chance to practice my git-fu".
> 
> When I used svn on somebody else's command-line, I'd blame the mistakes 
> I made on being spoiled by Git.  So "I'll just do an `svn log`... argh 
> no!  Control-C!  Control-C!  Right, `svn log | less`... my bad, git 
> pipes to less automatically."
> 
> 
> Over the course of a few months, people became convinced that Git was 
> something that makes you more productive.  Our lead developer had a go 
> with git-svn for a while, before our boss decided we should all make the 
> switch.
> 
> I tried to make git-svn as painless as possible with some svn-like 
> aliases and a cheatsheet, which I'd be happy to upload if the list could 
> suggest a good place to put a PDF and some text.

Feel free to contribute to the Git Wiki maybe at

https://git.wiki.kernel.org/index.php/GitDocumentation

in the "User contributed Documentation" section.

Michael

Re: What's the best way to make my company migrate to Git?

[Andrew Sayers]

On 25/05/10 08:42, Michael J Gruber wrote:
> 
> Feel free to contribute to the Git Wiki maybe at
> 
> https://git.wiki.kernel.org/index.php/GitDocumentation
> 
> in the "User contributed Documentation" section.
> 
> Michael
> 

Thanks for the hint - this turned into rather more than just uploading a
PDF, and I've now finished a complete write-up here:

	https://git.wiki.kernel.org/index.php/SvnMigration

The "User contributed Documentation" section seems to be mostly off-wiki
links, so I added a link from "Documentation on this Wiki" - I hope
that's ok.

	- Andrew

Re: What's the best way to make my company migrate to Git?

[Michael J Gruber]

Andrew Sayers venit, vidit, dixit 31.05.2010 22:04:
> On 25/05/10 08:42, Michael J Gruber wrote:
>>
>> Feel free to contribute to the Git Wiki maybe at
>>
>> https://git.wiki.kernel.org/index.php/GitDocumentation
>>
>> in the "User contributed Documentation" section.
>>
>> Michael
>>
> 
> Thanks for the hint - this turned into rather more than just uploading a
> PDF, and I've now finished a complete write-up here:
> 
> 	https://git.wiki.kernel.org/index.php/SvnMigration

Thanks a lot for your work!

> 
> The "User contributed Documentation" section seems to be mostly off-wiki
> links, so I added a link from "Documentation on this Wiki" - I hope
> that's ok.

Absolutely. "User contributed" would have been the place for a (link to
the pdf), and "Doc. on" is the right place your new Wiki page.

Thanks again,
Michael

Re: What's the best way to make my company migrate to Git?

[Daniele Segato]

On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers
<andrew-git@pileofstuff.org> wrote:
> On 25/05/10 08:42, Michael J Gruber wrote:
>>
>> Feel free to contribute to the Git Wiki maybe at
>>
>> https://git.wiki.kernel.org/index.php/GitDocumentation
>>
>> in the "User contributed Documentation" section.
>>
>> Michael
>>
>
> Thanks for the hint - this turned into rather more than just uploading a
> PDF, and I've now finished a complete write-up here:
>
>        https://git.wiki.kernel.org/index.php/SvnMigration


That's a great job!

I want to point out some difficulties I encountered switching from
Subversion to Git-SVN.
I'd like to discuss them here before, eventually, contributing them to
that page.


= Empty directories =
Git do not track directories, it tracks content. That means you'll not
get/commit empty directory in your
working tree.
Sometimes empty directory may be needed by some fancy script or
external software you use with your
project (example, ANT).

Developers should be aware of this: if they really need to create an
empty directory they can both
create it through subversion both create a "dummy" file in the
directory and commit it, if that's an option.


= Subversion ignore =
You can't control subversion ignores from git-svn. And git-svn do not
automatically synchronize with the
subversion ignores. The team should be aware of these to avoid issues.


= Local patch =
Most subversion user keeps some modified files in their local checkout
never committing it remotely.
This may be handy for some situation where you want to enable some
debug-specific feature or whatever you need.
With Git, if the file is remotely tracked (with Subversion you'll say
"already committed") you can't keep a file like that:
it will prevent you from "pushing" files to the remote repository or
checking out other local/remote branches.
You'll had to "stash" your patch and re-apply it later.

= local/remote branches =
Git-svn branches "track" the remote branches by adding a string in
each commit you "git svn dcommit" on
subversion repository. You can have many local branches tracking the
same remote subversion branch.
To start to track a new remote branch you have to "git checkout -b
localBranchName remoteBranchName",
which is not very user friendly :)

You also can't create new Subversion branches or tags with git-svn,
you'll had to use subversion directly for that.



Feel free to correct me or better describe those issue with a
better/more friendly english.
Feel also free to add to this list.


Regards,
Daniele Segato

Re: What's the best way to make my company migrate to Git?

[Alexander Iljin]

Hello!

DS> You also can't create new Subversion branches or tags with git-svn,
DS> you'll had to use subversion directly for that.

  Another point: you can't contribute to branches via git-svn, you can
  only commit to trunk. It is easy to be confused if you've created a
  feature branch in Git. If you then want to git-svn dcommit a
  half-done work, you will mess up the trunk.


---=====---
 Alexander

Re: What's the best way to make my company migrate to Git?

[Erik Faye-Lund]

On Tue, Jun 1, 2010 at 6:00 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:
> On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers
> <andrew-git@pileofstuff.org> wrote:
>> On 25/05/10 08:42, Michael J Gruber wrote:
>>>
>>> Feel free to contribute to the Git Wiki maybe at
>>>
>>> https://git.wiki.kernel.org/index.php/GitDocumentation
>>>
>>> in the "User contributed Documentation" section.
>>>
>>> Michael
>>>
>>
>> Thanks for the hint - this turned into rather more than just uploading a
>> PDF, and I've now finished a complete write-up here:
>>
>>        https://git.wiki.kernel.org/index.php/SvnMigration
>
>
> That's a great job!
>
> I want to point out some difficulties I encountered switching from
> Subversion to Git-SVN.
> I'd like to discuss them here before, eventually, contributing them to
> that page.
>
>
> = Empty directories =
> Git do not track directories, it tracks content. That means you'll not
> get/commit empty directory in your
> working tree.
> Sometimes empty directory may be needed by some fancy script or
> external software you use with your
> project (example, ANT).
>
> Developers should be aware of this: if they really need to create an
> empty directory they can both
> create it through subversion both create a "dummy" file in the
> directory and commit it, if that's an option.
>

This has been solved in recent versions of git: git-svn creates the
empty directories when you check out. It might not be 100% robust (I'm
not saying it isn't robust, I'm saying I don't know if it is), but it
works for my setup.

> You also can't create new Subversion branches or tags with git-svn,
> you'll had to use subversion directly for that.
>

Incorrect. git-svn have sub-commands called 'branch' and 'tag' for this purpose.

-- 
Erik "kusma" Faye-Lund

Re: What's the best way to make my company migrate to Git?

[Daniele Segato]

On Tue, Jun 1, 2010 at 6:25 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>> = Empty directories =

> This has been solved in recent versions of git: git-svn creates the
> empty directories when you check out. It might not be 100% robust (I'm
> not saying it isn't robust, I'm saying I don't know if it is), but it
> works for my setup.

Oh, i see, i'm using an old version of git and I did not noticed this.

>> You also can't create new Subversion branches or tags with git-svn,
>> you'll had to use subversion directly for that.
>>
>
> Incorrect. git-svn have sub-commands called 'branch' and 'tag' for this purpose.

I wasn't aware of this command. it is strange I did not notice them before.
But thanks for the correction!

Regards,
Daniele Segato

Re: What's the best way to make my company migrate to Git?

[Daniele Segato]

2010/6/1 Alexander Iljin <ajsoft@yandex.ru>:
> Hello!
>
> DS> You also can't create new Subversion branches or tags with git-svn,

I've been corrected on this: git svn tag and git svn branch are there
for that purpose.

>  Another point: you can't contribute to branches via git-svn, you can
>  only commit to trunk. It is easy to be confused if you've created a
>  feature branch in Git. If you then want to git-svn dcommit a
>  half-done work, you will mess up the trunk.

that's not correct

You can contribute to any subversion branch, but you have to do it
with a local branch tracking the
remote one

say you are on "master" which track remote svn "trunk" and you want to
contribute to remote branch "v1.x"

you can do this:

git checkout -b myBranch-v-1-x v1.x

it will checkout the remote v1.x creating a new label "myBranch-v-1-x"
for tracking it.
you can then work on myBranch-v-1-x as usual, when you'll git svn
dcommit from there you'll commit on the remote v1.x branch.


but you have to be careful with cherry-picking.

if you want to cherry pick a comment on trunk to commit it on branch
v1.x you'll have to amend it removing the line:

git-svn-id: https://your-svn-url/repos/trunk@1234 a123123....

or you'll not be able to commit on the remote v1.x branch.

I created a local alias for cherry-picking an a safe way for subversion:

[from alias section in my .gitconfig]

cherry-pick-svn =  !GIT_EDITOR='sed -i /^git-svn-id:/d' git cherry-pick -e

which do a normal cherry-pick automatically editing the commit to
remove that line.

may be this could be added to the svn alias list?

Regards,
Daniele Segato

Re: What's the best way to make my company migrate to Git?

[Alexander Iljin]

Hello!

DS> You can contribute to any subversion branch, but you have to do it
DS> with a local branch tracking the
DS> remote one

DS> say you are on "master" which track remote svn "trunk" and you want to
DS> contribute to remote branch "v1.x"

DS> you can do this:

  Thank you for the correction. I branched off the master, and then
  worked on both master and the feature branch. When I tried to
  dcommit, I could either push one or the other set of changes,
  whichever was currently checked out in Git. Glad to know there IS a
  way to do this properly. Still, a possible point to make in the
  Wiki.

---=====---
 Alexander

Re: What's the best way to make my company migrate to Git?

[Andrew Sayers]

I certainly think a "Git Traps for the Unwary" section would go well at
the bottom of the page.  My life would have been much easier if I could
have shown people a page where they could find ways to fix the things
I'd wrongly dismissed as non-problems.

I definitely agree about empty directories - even with Erik's point
about git-svn handling these, it's an issue people will face when they
transfer to git proper.

I'd suggest discussing svn:ignore as part of the wider topic of git's
non-support of SVN properties.  There are probably SVN teams out there
with elaborate sets of properties to migrate, and svn:ignore is a nice
hook to hang that discussion on without sending everyone else to sleep.

I agree that local/remote branches are worth discussing in more detail,
although I'm not sure how to explain it in SVN-friendly terms beyond
"this will seem weird at first, but will make sense eventually".  In
fact this is definitely a trap for the unwary, because the move from
directory-branches to label-branches tripped our migration up when we
had to rewrite tools that expected a "trunk" directory that was
guaranteed to have mainline code.

I think it's also worth mentioning local/remote commits, as it's quite
easy for people to commit and forget to push.

Finally, I agree that stash is certainly worth a mention - I'd also
suggest explaining how it's useful with `git svn rebase` and with
switching branches.  So I'd recommend putting it after both of those
sections.


I hope to have some writing time available this weekend, though that
could easily not happen.  So if someone else wants to have a crack at
it, be my guest :)

	- Andrew

Re: What's the best way to make my company migrate to Git?

[Andreas Krey]

On Tue, 01 Jun 2010 22:12:49 +0000, Andrew Sayers wrote:
...
> I think it's also worth mentioning local/remote commits, as it's quite
> easy for people to commit and forget to push.

I found (for myself) 'gitk --all' making it lots easier to see the light
in these regards. (Missing such a thing for svn sorely.) Doing a fetch,
pressing F5 and seeing the remote branches move. Or diverge.

Andreas

Re: What's the best way to make my company migrate to Git?

[Michael J Gruber]

Daniele Segato venit, vidit, dixit 01.06.2010 18:00:
> On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers
> <andrew-git@pileofstuff.org> wrote:
>> On 25/05/10 08:42, Michael J Gruber wrote:
>>>
>>> Feel free to contribute to the Git Wiki maybe at
>>>
>>> https://git.wiki.kernel.org/index.php/GitDocumentation
>>>
>>> in the "User contributed Documentation" section.
>>>
>>> Michael
>>>
>>
>> Thanks for the hint - this turned into rather more than just uploading a
>> PDF, and I've now finished a complete write-up here:
>>
>>        https://git.wiki.kernel.org/index.php/SvnMigration
> 
> 
> That's a great job!
> 
> I want to point out some difficulties I encountered switching from
> Subversion to Git-SVN.
> I'd like to discuss them here before, eventually, contributing them to
> that page.

Andrew's main thrust is how to migrate a team, not how to migrate a code
base, and even less about the technical differences between svn and git.
And that makes it especially valuable.

I'd suggest not mixing these things. Andrew's page fills a gap about the
social aspects of the migration, and does so very well. He mentions very
few technical aspects, only those which you need to take into account
for planning out your team migration, i.e. relevant to advocacy, change
of philosophy, avoiding typical pitfalls.

There's already a score of pages about technical differences between git
and svn. So, please, add your technical aspects to those (or improve and
correct them), and/or link to corresponding or new pages from
SvnMigration under "See Also".

If you have additions to the migration aspects feel free to add them to
SvnMigration, of course. I know there's no sharp line but I don't want
to see a can of technical worms opened on that page :)

Cheers,
Michael

Re: What's the best way to make my company migrate to Git?

[Sylvain Rabot]

On Tue, Jun 1, 2010 at 18:00, Daniele Segato <daniele.bilug@gmail.com> wrote:
> On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers
> <andrew-git@pileofstuff.org> wrote:
>> On 25/05/10 08:42, Michael J Gruber wrote:
>>>
>>> Feel free to contribute to the Git Wiki maybe at
>>>
>>> https://git.wiki.kernel.org/index.php/GitDocumentation
>>>
>>> in the "User contributed Documentation" section.
>>>
>>> Michael
>>>
>>
>> Thanks for the hint - this turned into rather more than just uploading a
>> PDF, and I've now finished a complete write-up here:
>>
>>        https://git.wiki.kernel.org/index.php/SvnMigration
>
>
> That's a great job!
>
> I want to point out some difficulties I encountered switching from
> Subversion to Git-SVN.
> I'd like to discuss them here before, eventually, contributing them to
> that page.
>
>
> = Empty directories =
> Git do not track directories, it tracks content. That means you'll not
> get/commit empty directory in your
> working tree.
> Sometimes empty directory may be needed by some fancy script or
> external software you use with your
> project (example, ANT).
>
> Developers should be aware of this: if they really need to create an
> empty directory they can both
> create it through subversion both create a "dummy" file in the
> directory and commit it, if that's an option.
>
>
> = Subversion ignore =
> You can't control subversion ignores from git-svn. And git-svn do not
> automatically synchronize with the
> subversion ignores. The team should be aware of these to avoid issues.
>
>
> = Local patch =
> Most subversion user keeps some modified files in their local checkout
> never committing it remotely.
> This may be handy for some situation where you want to enable some
> debug-specific feature or whatever you need.
> With Git, if the file is remotely tracked (with Subversion you'll say
> "already committed") you can't keep a file like that:
> it will prevent you from "pushing" files to the remote repository or
> checking out other local/remote branches.
> You'll had to "stash" your patch and re-apply it later.

AFAIK you're not obliged to have a clean working tree to push.
If you want to keep patches on a branch you push regularly, creating a
new branch and committing on it is more appropriate, keeping the
patches as stash is not very handy.
Personally I only use stash when I'm on the middle of something and I
have to checkout another branch to check something.

>
> = local/remote branches =
> Git-svn branches "track" the remote branches by adding a string in
> each commit you "git svn dcommit" on
> subversion repository. You can have many local branches tracking the
> same remote subversion branch.
> To start to track a new remote branch you have to "git checkout -b
> localBranchName remoteBranchName",
> which is not very user friendly :)
>
> You also can't create new Subversion branches or tags with git-svn,
> you'll had to use subversion directly for that.
>
>
>
> Feel free to correct me or better describe those issue with a
> better/more friendly english.
> Feel also free to add to this list.
>
>
> Regards,
> Daniele Segato
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Sylvain

Re: What's the best way to make my company migrate to Git?

[Andrew Sayers]

On 02/06/10 08:15, Michael J Gruber wrote:
> 
> Andrew's main thrust is how to migrate a team, not how to migrate a code
> base, and even less about the technical differences between svn and git.
> And that makes it especially valuable.

I'm glad you like it, and I've now finished version 2.  I think I've
covered most of the points raised in this thread without getting too far
into technical issues that I agree belong on a different page.

As well as a few typographic upgrades, I've added some text to the "Git
as an SVN client" section - warnings for the issues that Daniele
mentioned, and explaining git issues to SVN users.  I remember now the
mental anguish I went through trying to explain what a local index is,
so I thought I'd save other people the bother :)

As promised, I've also added a "traps for the unwary" section, although
I'm quite tempted to make it a page on its own.  The intended audience
and writing style is necessarily quite different, and it awkwardly bulks
up the table of contents.  I'll probably leave it there unless it gets
any bigger or people think splitting it out is a particularly good idea.

One issue I haven't addressed is unpushed commits.  I want to write
something like "consider setting GIT_PS1_SHOWUNPUSHED to remind people
when they have committed but not yet pushed", so I'm going to see if I
can add support to git-completion.bash for such an option.

	- Andrew

Re: What's the best way to make my company migrate to Git?

[Steven Michalske]

Resent, HTML multipart got treated as spam......

On Jun 5, 2010, at 2:27 PM, Andrew Sayers wrote:

> I remember now the
> mental anguish I went through trying to explain what a local index is,
> so I thought I'd save other people the bother :)

I liked the idea that its an envelope, and you add changes to the open  
envelope.

Committing the changes are sealing the envelope and putting it on the  
pile of papers on your desk

A push is mailing the envelope.

Fetch is going to the mail box getting the envelopes and throwing the  
letters on the table, but not opening them.

Everyone knows envelopes!