git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lin Mac <mkl0301@gmail.com>
To: Andrew Sayers <andrew-git@pileofstuff.org>
Cc: Daniele Segato <daniele.bilug@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: What's the best way to make my company migrate to Git?
Date: Sun, 23 May 2010 17:12:28 +0800	[thread overview]
Message-ID: <AANLkTim8NfxY75tpHIEx1LMatWQ5P-LgCaNSeNp2KFa3@mail.gmail.com> (raw)
In-Reply-To: <4BF7B751.7050704@pileofstuff.org>

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

  parent reply	other threads:[~2010-05-23  9:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-21 14:55 What's the best way to make my company migrate to Git? Daniele Segato
2010-05-21 15:54 ` Jakub Narebski
2010-05-22 15:58   ` Daniele Segato
2010-05-22 16:06     ` Jakub Narebski
2010-05-22 18:26     ` Joshua Jensen
2010-05-22 10:52 ` Andrew Sayers
2010-05-22 15:52   ` Daniele Segato
2010-05-23 14:52     ` Andrew Sayers
2010-05-24 17:37       ` Daniele Segato
2010-05-23  9:12   ` Lin Mac [this message]
2010-05-23 15:06     ` Andrew Sayers
2010-05-25  7:42   ` Michael J Gruber
2010-05-31 20:04     ` Andrew Sayers
2010-06-01  6:28       ` Michael J Gruber
2010-06-01 16:00       ` Daniele Segato
2010-06-01 16:14         ` Alexander Iljin
2010-06-01 17:16           ` Daniele Segato
2010-06-01 17:45             ` Alexander Iljin
2010-06-01 16:25         ` Erik Faye-Lund
2010-06-01 16:36           ` Daniele Segato
2010-06-01 21:12         ` Andrew Sayers
2010-06-02  5:19           ` Andreas Krey
2010-06-02  7:15         ` Michael J Gruber
2010-06-05 21:27           ` Andrew Sayers
2010-06-06  8:19             ` Steven Michalske
2010-06-02 16:01         ` Sylvain Rabot
     [not found] ` <AANLkTilIihNTDPZ5NIKUzsPEZ2Gpusm-10FCBVifvNuw@mail.gmail.com>
2010-05-23 22:46   ` Daniele Segato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTim8NfxY75tpHIEx1LMatWQ5P-LgCaNSeNp2KFa3@mail.gmail.com \
    --to=mkl0301@gmail.com \
    --cc=andrew-git@pileofstuff.org \
    --cc=daniele.bilug@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).