www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Lyubimov <dlie...@gmail.com>
Subject Re: Current use of GitHub
Date Mon, 04 Apr 2011 21:19:31 GMT
the idea is to work with 2 branches: your svn trunk branch and the
issue branch.

You only apply changes and commit to issue branch (in your case it
seems to be feature1). You enable github collaboration by
syncing it up with remote github branch (and set your local branch to
track it for convenience. Assuming you've been on your svn trunk
branch when
you started your sequence, you've done it here just that :

> git remote add github git@github.com....
> git branch feature1
> git checkout feature1

Now you can collaborate on feature1 branch in github with other people
via fork/pull requests as usual.

> //do some work locally, committing to local git.
> git svn rebase // pull in other changes from apache

are you still on feature1 branch? if yes, you don't want to do svn
rebases to it. You should only do it to your svn trunk branch (which
you presumably haven't even pushed to github -- but you may if you
That's the problem, i think svn rebase will override your job.

> git push -u github //I don't remember the exact command I used, but it did get my local
changes to a github branch named feature1

here is the sequence i am proposing:

suppose you are on your svn branch that you instantiated via cloning
apache git and then running git svn init ... per that apache wiki you

do this :

git remote add github git@github...
git checkout -b feature1 // this is equivalent to git branch + git
checkout steps you did

git push -u github  // push feature1 branch marker to gtihub.

now you can collaborate on feature1.
E.g. try to change something locally . To propagate your change to github, do

git commit -a -m "my feature1 change"
git push (pushes commit to github. Since you already set the github
tracking for your local feature1 branch, you can use default form to
push without more params while on the branch).

Now your trunk diverged from both local and github's copies of 'feature1'.

Suppose you or someone else did a series of commits on feature1 in
github's vesion of feature1 and you now wish to commit it back to svn
so, what you want to do is this:

git checkout feature1 (-- on local feature1)
git pull (-- make sure your local feature1 branch grabbed all the
changes in the github branch 'feature1'

-- now merge to the local trunk branch squashing the feature1 commit
history into 1 commit:
git checkout trunk
git svn rebase (-- make sure local trunk branch is up to date, an
git-svn equivalent of 'git pull', sort of)

-- this is important part
git merge feature1 --squash

this will leave your local branch with all cumulative changs of
feature1 applied onto local tree but not comitting them.
It may optionally say you have conflicts, if so, run 'git mergetool'
to resolve manually.

git commit -a -m "feature1 patch" -- this will create a single commit
in your local trunk branch and that's exactly what is going to be
pushed into svn.

you can double-check the diff at this point to see exactly what you
have applied by running
git log -p -1

to replicate that commit to svn, just run
git svn dcommit

(they recommend to run 'git svn dcommit --no-rebase for european users
because of delay in replicating between svn hosts, and run rebase
separately several seconds after).

> I now can't push my local changes to the same feature1 github branch.  My theory about
why is that I've reordered history on my local git compared to the existing github branch.
 I have no way to verify this :-).  I guess I could create a new github branch every time
I push???

most likely because you've run some svn rebases, you history on
feature1 can't be fast-forwarded to the github's without rewriting it.
Don run git-svn on your feature 1 branch ever.

> thanks
> david jencks

>>> -----
>>> git svn rebase is a major pain.  I don't really understand why but it looks
to me like I have to keep resolving the same merge conflicts.  I'm also not completely convinced
that all my local work gets preserved through the merge conflict resolution.
>>> I used to use svn branches for ongoing work but with the svn version that tracks
merges I've given up on this because of the enormous volume of noise in an svn merge commit.
>>> thanks
>>> david jencks
>>> On Apr 3, 2011, at 10:17 PM, David Blevins wrote:
>>>> I know a few of us use Git for Apache work.  Feel encouraged to lend some
feedback to infra.
>>>> -David
>>>> Begin forwarded message:
>>>>> Resent-From: <dblevins@visi.com>
>>>>> From: "Gav..." <gavin@16degrees.com.au>
>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>> To: <infrastructure-dev@apache.org>
>>>>> Subject: Current use of GitHub
>>>>> Reply-To: infrastructure-dev@apache.org
>>>>> I'm trying to understand the _current_ workflows of those ASF committers
>>>>> using Git and how the ASF GitHub mirrors tie into that - if at all.
>>>>> A fair few projects requested ASF git mirrors and also requested mirrors
>>>>> that on GitHub (that 2nd request is now standard with the 1st)
>>>>> So far , from projects I've browsed on GitHub, I see a few forks here
>>>>> there and a few Pull requests here and there.
>>>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull
>>>>> those pull requests into the Apache/$project repo mirror, so
>>>>> how are committers applying those pull requests? Are they pulling them
>>>>> their own copies of the mirror, converting them into a patch
>>>>> that svn understands and then applying, if so, how? If not, how else?
>>>>> Also, apart from Github, how else are Git only users providing patches
>>>>> projects, which patch programs are in use, and of those which
>>>>> are most used by those projects/committers that need to apply them.
>>>>> For those of you that are committers and have direct access to svn, but
>>>>> preferring to use Git before then committing your work to svn,
>>>>> what is your workflow and tools used (whether or not it involves GitHub)
>>>>> No deviating into what could happen or what would be a good idea please
>>>>> this is just a survey on what people are currently actually
>>>>> doing to incorporate Git into their workflows and how we then get those
>>>>> applied.
>>>>> Thanks
>>>>> Gav...

View raw message