www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: doing some Git work
Date Mon, 02 Mar 2009 18:06:31 GMT
El lun, 02-03-2009 a las 14:34 +0100, Grzegorz Kossakowski escribió:
> Steve Loughran pisze:
> > 
> > I need some help moving my work onto Git
> > 
> > 1. I am doing some big hadoop changes (
> > https://issues.apache.org/jira/browse/HADOOP-3628  ) and regularly
> > updating against SVN_HEAD, publishing revised patches, etc.
> > 
> > 2. I have commit rights, but the team is very strict about patching, and
> > none of this stuff is under SCM yet. Partly that is because my employers
> > -HP- are still doing some paperwork to tell me its ok to commit it
> > 
> > 3. I'd like to move it to Git so I can publish my defacto branch and
> > work on from >1 machine
> > 
> > 4. I do still intend to get everything checked in; this is just a way of
> > me working better until that date, and for easier access to others
> > 
> > How should I go about git-ifying it?
> 
> Hi Steve,
> 
> I believe that Git will help in your situation. Have a look at GitAtApache[1], especially
section called "Git for Apache
> committers".
> 
> Once you clone Hadoop repository you should create and checkout a new local branch using:
> git checkout -b myBigChanges
> 
> and start work there. If you need to pull new changes from svn call:
> git pull
> 
> This will update your master branch. Then you have to either rebase your myBigChanges
branch (if it wasn't published) or
> merge master into myBigChanges if it was already published.
> 

One nice thing of git is that it is designed so that it is easy to turn
a sequence of git commits into a series of patches, and the other way
around.

The good thing of using git to maintain changes on top of the official
repository is that you can keep focused commits. One, or a set of
commits per logical change. Later, when you have the paperwork done, you
can apply separate, auditable changes on top of HEAD, and have more
debatable changes waiting while the more agreeable ones get into svn
soon.

This can also be done with tools like kilt, etc. but git has a good UI
for managing the kind of processes where some of your commits are
integrated while other one are still waiting, and keep your branch
rebased or merged with the current commits...

When I'm doing sensitive merges/rebases on top of a project, I tend to
keep both a set of "git-format-patch" commits and repositories as
backup, so that I can repair any error. Typically errors can always be
repaired by "rewinding" to a known good commit, and re-applying whatever
went wrong, in the right way...

The "git-format-patch" set of commits is the minimum information that
allows to do a manual merge on top of subversion or posting to jira, in
case all else fails. :)

Regards
Santiago

> I hope that helps.
> 
> [1] http://wiki.apache.org/general/GitAtApache
> 


Mime
View raw message