You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by "Gav..." <ga...@16degrees.com.au> on 2011/04/03 08:45:10 UTC
Current use of GitHub
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 of
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 and
there and a few Pull requests here and there.
That is where it gets fuzzy for me. Obviously, no-one can actually pull in
those pull requests into the Apache/$project repo mirror, so
how are committers applying those pull requests? Are they pulling them into
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 to
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 are
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 yet,
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...
Re: Current use of GitHub
Posted by Owen O'Malley <ow...@gmail.com>.
I use git extensively for Apache projects. The workflows depend on the
situation, but are complex enough that I need to explain the setup
often. I don't currently GitHub for much related to Apache projects.
I have a Yahoo machine that pulls down changes from the Apache git
mirrors. Most of the Yahoo devs working on Apache projects sync their
git repositories with that Yahoo machine, although some of the more
advanced users also sync directly with the Apache git repositories.
For reviewing and writing patches, git allows a single local
repository to easily context switch between them. Patches are rebased
to reflect external changes. When the patches are done, they are
uploaded to jira and committed to subversion.
The internal repository supports both internal branches and continuous
integration jobs that don't depend on connectivity to Apache
subversion.
-- Owen
Re: Current use of GitHub
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Apr 3, 2011 at 2:45 AM, Gav... <ga...@16degrees.com.au> wrote:
> 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 of
> 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 and
> there and a few Pull requests here and there.
> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
> those pull requests into the Apache/$project repo mirror, so
> how are committers applying those pull requests? Are they pulling them into
> 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 to
> 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 are
> 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 yet,
> 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...
>
>
>
Currently my Git workflow is entirely divorced from SVN. All of my
coding is done using Git clones and when I need to commit something to
SVN it always comes via `patch -p1 < something.patch` regardless if I
wrote it or it's a patch from Jira. I learned pretty quick to check
the top of the patch to see if it needs -p0 vs -p1. Though come to
think of it, I can't remember the last time I saw an SVN diff attached
in Jira.
As to pull requests, pretty much the only thing that committers can't
do is close them (or get notified about their creation). Even with my
non-ASF projects I still have to pull the submitters changes down,
apply them and then push back to the central repo. There's nothing an
ASF committer needs other than having a properly configured git-svn.
Fwd: Current use of GitHub
Posted by David Jencks <da...@yahoo.com>.
Not sure if all the heavy git users are on infrastructure-dev...
david jencks
Begin forwarded message:
> From: David Blevins <da...@gmail.com>
> Date: April 3, 2011 10:17:01 PM PDT
> To: dev@geronimo.apache.org
> Subject: Fwd: Current use of GitHub
> Reply-To: dev@geronimo.apache.org
>
> 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: <db...@visi.com>
>> From: "Gav..." <ga...@16degrees.com.au>
>> Date: April 2, 2011 11:45:10 PM PDT
>> To: <in...@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 of
>> 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 and
>> there and a few Pull requests here and there.
>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>> those pull requests into the Apache/$project repo mirror, so
>> how are committers applying those pull requests? Are they pulling them into
>> 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 to
>> 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 are
>> 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 yet,
>> 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...
>>
>>
>>
>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
> git push -f github feature_name
I believe that syntax of pull+history overwrite. with pull, you need to use
git push github +feature_name:feature_name
And yes, it will make you heretic :)
-d
On Mon, Apr 4, 2011 at 2:17 PM, Paul Davis <pa...@gmail.com> wrote:
>> //do some work locally, committing to local git.
>>
>> git svn rebase // pull in other changes from apache
>> 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
>>
>> //do some more work locally, committing to local git.
>> //no one else changed the github branch AFAICT
>>
>> git svn rebase // pull in more apache changes, resolving merge conflicts
>>
>> 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???
>>
>
> David,
>
> Bottom line is that this is because when you rebase, you've changed
> the history of your branch. Since you did the first rebase before you
> pushed, this is fine, when you do the second rebase, it changes the
> commits you did locally before, which causes your local branch history
> to diverge from the branch at your GitHub remote.
>
> Think of the commit pattern like such:
>
> SN commit N from svn
> LNM local commit N, version M
>
> // do some work locally
>
> S0 -> L10 -> L20
>
> git svn rebase
>
> S0 -> S1 -> S2 -> L11 -> L21
>
> git push github feature_name
>
> # GitHub now has L31 as the head for branch feature_name
>
> // more local work
>
> S0 -> S1 -> S2 -> L11 -> L21 -> L30
>
> git svn rebase
>
> S0 -> S1 -> S2 -> S3 -> L12 -> L22 -> L31
>
> // Now you can't push
>
> this is because your local branch has L31 as the head, and the GitHub
> branch is still L30. This is what's referred to a non fast forward
> push. You'll notice that both branches have commit S2 as the most
> recent commit in common.
>
> Now is the part where I write something that gets me branded as a heretic.
>
> To fix this, just do:
>
> $ git push -f github feature_name
>
> This will forcefully overwrite your remote branch so that it points at L31.
>
>
> Most people will tell you to never rebase something that has been
> pushed publicly. Generally that's true. For instance, you should never
> ever rebase your stable branches (master, version branches etc) that
> people might be using to develop against. On the other hand, if I have
> a public tracking branch of some wip, I'll rebase at will, treating it
> solely as a way for people to keep an eye on what I'm hacking on.
>
>
> I'll note that the alternative to this work flow is to svn rebase a
> local checkout of trunk, and then merge that into your feature branch.
> This will ensure that you'll always have fast forward updates when you
> push to GitHub. On the other hand, when you go to extract the work
> from your feature branch it can become much more difficult if you want
> to do anything more complicated than a single patch.
>
Re: Current use of GitHub
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Apr 4, 2011 at 5:50 PM, David Jencks <da...@yahoo.com> wrote:
> Hi Paul,
>
> IIUC your "heretical" suggestion is about the same as creating a new github branch every time I want to push my local branch, except the github branches all happen to have the same name so you can only see the most recent one? I didn't know how to make them end up with the same name :-) ... this looks like my best option so far.
>
Roughly speaking. Just remember that the social aspect to keep
everyone informed that the branch will be changing and to not develop
code on it without close collaboration.
Re: Current use of GitHub
Posted by Mark Struberg <st...@yahoo.de>.
I personally barely use dcommit, but frequently use git locally to create a patch which I attach to jira later. Git is just soooo much quicker at checkout + blame than svn that it easily pays off. Especially if you are not so deep into the code and need to grab through historical versions and commit messages of the code.
I do not use git for projects I'm committer on though.
But I have seen a few people making use of git-clone for grabbing our projects.
LieGrue,
strub
--- On Tue, 4/5/11, Kristian Rosenvold <kr...@gmail.com> wrote:
> From: Kristian Rosenvold <kr...@gmail.com>
> Subject: Re: Current use of GitHub
> To: infrastructure-dev@apache.org
> Date: Tuesday, April 5, 2011, 9:19 AM
> ti., 05.04.2011 kl. 10.08 +0200,
> skrev Jukka Zitting:
> > Hi,
> >
> > On Tue, Apr 5, 2011 at 8:28 AM, Kristian Rosenvold
> > <kr...@gmail.com>
> wrote:
> > > *All* git-svn based workflows involve rebasing
> (rewriting history). By
> > > standard git wisdom that makes your workflow
> single-user unless you have
> > > quite advanced git users.
> >
> > I any case I would recommend git-svn users to use the
> svn repository
> > for collaboration. If you have a commit that can be
> shared, just do a
> > git svn dcommit and everyone is happy ..
> >
>
> As long as we're svn-backed, that should certainly be the
> official
> recommendation. This does not mean that's how things happen
> in real
> life ;)
>
> I frequently use git/github to collaborate with myself at
> different
> computers, so I push/rebase/reset when I move from my
> laptop to my home
> office to my office. Sometimes code can be in shambles, not
> even
> compiling (I can switch dev computers in 30 seconds in this
> manner). Git
> users simply end up using their servers for far more
> use-cases than svn
> users, and I wouldn't dream of dcommitting anything that
> doesn't even
> compile.
>
> And we already have several examples where asf committers
> choose to
> collaborate in git/github branches only to dcommit when
> done. I'm not
> sure it matters in this context, it just creates larger svn
> commits;
> there may be other concerns about this.
>
> I understand the original query as requesting insight into
> the current
> usages of the mirrors, and there may be several reasons for
> that. From a
> technical perspective I think the current integration is
> reasonably
> state-of-the-art when it comes to git<->svn
> integration, which
> unfortunately says a lot about the orthogonality of these
> two SCM's
> (although I sometimes suspect there'd be ways to make
> git-svn better).
> There may be some provenance issues that could be addressed
> wrt the git
> forks; maybe something like crawling github looking for
> git-commits that
> are children of "official" apache sha1's (and persist it
> somewhere)
> could be an idea.
>
> Even with all their limitations, the forks provide great
> value to git
> users. The biggest shame is that you really need to be a
> *good* git user
> to get a smooth experience, it's not much for git-beginners
> who really
> should start their learning with "proper" git.
>
> Kristian
>
>
>
Re: Current use of GitHub
Posted by Kristian Rosenvold <kr...@gmail.com>.
ti., 05.04.2011 kl. 10.08 +0200, skrev Jukka Zitting:
> Hi,
>
> On Tue, Apr 5, 2011 at 8:28 AM, Kristian Rosenvold
> <kr...@gmail.com> wrote:
> > *All* git-svn based workflows involve rebasing (rewriting history). By
> > standard git wisdom that makes your workflow single-user unless you have
> > quite advanced git users.
>
> I any case I would recommend git-svn users to use the svn repository
> for collaboration. If you have a commit that can be shared, just do a
> git svn dcommit and everyone is happy ..
>
As long as we're svn-backed, that should certainly be the official
recommendation. This does not mean that's how things happen in real
life ;)
I frequently use git/github to collaborate with myself at different
computers, so I push/rebase/reset when I move from my laptop to my home
office to my office. Sometimes code can be in shambles, not even
compiling (I can switch dev computers in 30 seconds in this manner). Git
users simply end up using their servers for far more use-cases than svn
users, and I wouldn't dream of dcommitting anything that doesn't even
compile.
And we already have several examples where asf committers choose to
collaborate in git/github branches only to dcommit when done. I'm not
sure it matters in this context, it just creates larger svn commits;
there may be other concerns about this.
I understand the original query as requesting insight into the current
usages of the mirrors, and there may be several reasons for that. From a
technical perspective I think the current integration is reasonably
state-of-the-art when it comes to git<->svn integration, which
unfortunately says a lot about the orthogonality of these two SCM's
(although I sometimes suspect there'd be ways to make git-svn better).
There may be some provenance issues that could be addressed wrt the git
forks; maybe something like crawling github looking for git-commits that
are children of "official" apache sha1's (and persist it somewhere)
could be an idea.
Even with all their limitations, the forks provide great value to git
users. The biggest shame is that you really need to be a *good* git user
to get a smooth experience, it's not much for git-beginners who really
should start their learning with "proper" git.
Kristian
Re: Current use of GitHub
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Apr 5, 2011 at 8:28 AM, Kristian Rosenvold
<kr...@gmail.com> wrote:
> *All* git-svn based workflows involve rebasing (rewriting history). By
> standard git wisdom that makes your workflow single-user unless you have
> quite advanced git users.
I any case I would recommend git-svn users to use the svn repository
for collaboration. If you have a commit that can be shared, just do a
git svn dcommit and everyone is happy.
BR,
Jukka Zitting
Re: Current use of GitHub
Posted by Kristian Rosenvold <kr...@gmail.com>.
*All* git-svn based workflows involve rebasing (rewriting history). By
standard git wisdom that makes your workflow single-user unless you have
quite advanced git users.
There are several strategies for collaboration even in this scenario,
but all of them only caters for "known" collaborators; in a small
group of people you can decide to work git-only on a branch that
*stays* anchored at a specific svn version for the scope of the
collaboration. Or you can have one person in the group run git rerere
and have her do all the update-merges from svn trunk (but still stay on
a separate branch for the scope of the collaboration). This person
(and only her!) should be able to do a rebase & squash at the end of the
collaboration effort and commit back to svn.
Most people are aware that git creates SHA1 hashes for each commit.
But git also creates SHA1 hashes of the *diff content* used in diff
based operations such as rebase, which means that you can actually
safely move an unmodified diff around in history and expect other users
to be able to recover from it (at least strong git users;). This is the
reason squashing is even more frowned upon, when you squash you also
change the SHA1 of the diff, meaning it becomes much harder
(impossible?) to follow rebases. But still, we squash when committing
to svn.
But given the way we tag our svn commits with jira references,
it's generally possible for an informed git-svn user to understand
the rebases/squashes going on. But it's definitely not for the
git beginners and IMO it's a bit of a half-perverted git workflow that
makes git look bad.
But these are the constraints of working with svn-backed git and I have
no indication they will go away. The only real "solution" to this
problem is ditching svn as backing store, something I truely hope
will be done in due time, but I suppose that's a different discussion.
Github does a good git-backed svn ;)
Kristian
Re: Current use of GitHub
Posted by David Jencks <da...@yahoo.com>.
Hi Paul,
IIUC your "heretical" suggestion is about the same as creating a new github branch every time I want to push my local branch, except the github branches all happen to have the same name so you can only see the most recent one? I didn't know how to make them end up with the same name :-) ... this looks like my best option so far.
many thanks!
david jencks
On Apr 4, 2011, at 2:17 PM, Paul Davis wrote:
>> //do some work locally, committing to local git.
>>
>> git svn rebase // pull in other changes from apache
>> 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
>>
>> //do some more work locally, committing to local git.
>> //no one else changed the github branch AFAICT
>>
>> git svn rebase // pull in more apache changes, resolving merge conflicts
>>
>> 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???
>>
>
> David,
>
> Bottom line is that this is because when you rebase, you've changed
> the history of your branch. Since you did the first rebase before you
> pushed, this is fine, when you do the second rebase, it changes the
> commits you did locally before, which causes your local branch history
> to diverge from the branch at your GitHub remote.
>
> Think of the commit pattern like such:
>
> SN commit N from svn
> LNM local commit N, version M
>
> // do some work locally
>
> S0 -> L10 -> L20
>
> git svn rebase
>
> S0 -> S1 -> S2 -> L11 -> L21
>
> git push github feature_name
>
> # GitHub now has L31 as the head for branch feature_name
>
> // more local work
>
> S0 -> S1 -> S2 -> L11 -> L21 -> L30
>
> git svn rebase
>
> S0 -> S1 -> S2 -> S3 -> L12 -> L22 -> L31
>
> // Now you can't push
>
> this is because your local branch has L31 as the head, and the GitHub
> branch is still L30. This is what's referred to a non fast forward
> push. You'll notice that both branches have commit S2 as the most
> recent commit in common.
>
> Now is the part where I write something that gets me branded as a heretic.
>
> To fix this, just do:
>
> $ git push -f github feature_name
>
> This will forcefully overwrite your remote branch so that it points at L31.
>
>
> Most people will tell you to never rebase something that has been
> pushed publicly. Generally that's true. For instance, you should never
> ever rebase your stable branches (master, version branches etc) that
> people might be using to develop against. On the other hand, if I have
> a public tracking branch of some wip, I'll rebase at will, treating it
> solely as a way for people to keep an eye on what I'm hacking on.
>
>
> I'll note that the alternative to this work flow is to svn rebase a
> local checkout of trunk, and then merge that into your feature branch.
> This will ensure that you'll always have fast forward updates when you
> push to GitHub. On the other hand, when you go to extract the work
> from your feature branch it can become much more difficult if you want
> to do anything more complicated than a single patch.
Re: Current use of GitHub
Posted by Paul Davis <pa...@gmail.com>.
> //do some work locally, committing to local git.
>
> git svn rebase // pull in other changes from apache
> 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
>
> //do some more work locally, committing to local git.
> //no one else changed the github branch AFAICT
>
> git svn rebase // pull in more apache changes, resolving merge conflicts
>
> 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???
>
David,
Bottom line is that this is because when you rebase, you've changed
the history of your branch. Since you did the first rebase before you
pushed, this is fine, when you do the second rebase, it changes the
commits you did locally before, which causes your local branch history
to diverge from the branch at your GitHub remote.
Think of the commit pattern like such:
SN commit N from svn
LNM local commit N, version M
// do some work locally
S0 -> L10 -> L20
git svn rebase
S0 -> S1 -> S2 -> L11 -> L21
git push github feature_name
# GitHub now has L31 as the head for branch feature_name
// more local work
S0 -> S1 -> S2 -> L11 -> L21 -> L30
git svn rebase
S0 -> S1 -> S2 -> S3 -> L12 -> L22 -> L31
// Now you can't push
this is because your local branch has L31 as the head, and the GitHub
branch is still L30. This is what's referred to a non fast forward
push. You'll notice that both branches have commit S2 as the most
recent commit in common.
Now is the part where I write something that gets me branded as a heretic.
To fix this, just do:
$ git push -f github feature_name
This will forcefully overwrite your remote branch so that it points at L31.
Most people will tell you to never rebase something that has been
pushed publicly. Generally that's true. For instance, you should never
ever rebase your stable branches (master, version branches etc) that
people might be using to develop against. On the other hand, if I have
a public tracking branch of some wip, I'll rebase at will, treating it
solely as a way for people to keep an eye on what I'm hacking on.
I'll note that the alternative to this work flow is to svn rebase a
local checkout of trunk, and then merge that into your feature branch.
This will ensure that you'll always have fast forward updates when you
push to GitHub. On the other hand, when you go to extract the work
from your feature branch it can become much more difficult if you want
to do anything more complicated than a single patch.
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
Just posted somewhat hasty write-up on my approach:
http://weatheringthrutechdays.blogspot.com/2011/04/git-github-and-committing-to-asf-svn.html
seems to work so far.
On Mon, Apr 4, 2011 at 3:04 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
> PS since you use 3-way git merge from svn trunk branch onto feature1,
> git should memorize the merges you already resolved and your base for
> 3base merge should be updated as a result so should not continuously
> resolve conflicts you've already done.
>
> The only nasty thing that may pop up continuously in my experience in
> git is renaming/moving conflicts, i did not quite get a good handle on
> those one. Since git does not 'memorize' the fact of moving, but only
> 'detects' them, sometimes they just keep popping up but that doesn't
> have anything to do with svn integration.:(
>
> -d
>
> On Mon, Apr 4, 2011 at 2:56 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
>> On Mon, Apr 4, 2011 at 2:47 PM, David Jencks <da...@yahoo.com> wrote:
>>> Hi Dmitriy,
>>>
>>> Everything you say makes sense, but IIUC the workflow you propose does not allow me to bring the svn changes at apache into my local feature1 branch. IIUC the svn changes are only pulled into my local master and I'll have to resolve all the merge conflicts at once right before I dcommit to svn. Unfortunately this doesn't work for me for large-scale refactorings where I need to keep current with svn changes over the several weeks I'm working.
>>
>>
>> David, that's easy: keep your svn trunk up-to-date by running 'git svn
>> rebase' on it. Since you presumably haven't committed any changes onto
>> trunk that you haven't pushed to svn, there should be no conflicts.
>>
>> Once you sync'd up your local trunk branch with svn , just merge it
>> into feature 1 using your regular git merge and then push it up to
>> github.
>>
>> I.e. on trunk
>> git checkout trunk
>> git svn rebase
>>
>> on feature 1:
>> git checkout feature1
>> git pull (-- make sure you are in sync with remote github if needed)
>>
>> git merge trunk (-- now your svn commit history is locally on feature1)
>> git push (-- fast-forward remote github feature1 history to include
>> svn commits now)
>>
>> The merging and collaboration is really no specific to svn
>> integration. The only thing that specific to svn integration is how
>> you set up your trunk for svn rebases and how you squash feature1
>> commit history onto it before pushing into svn (but even that is just
>> a git feature).
>>
>>
>>
>>
>>>
>>> I think that between your and Paul's responses my theory about why I can't keep my github branch up to date (due to git svn rebase) is correct :-)
>>>
>>> many thanks!
>>> david jencks
>>>
>>> On Apr 4, 2011, at 2:19 PM, Dmitriy Lyubimov wrote:
>>>
>>>> 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
>>>> want.)
>>>> 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
>>>> mentioned.
>>>>
>>>> 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: <db...@visi.com>
>>>>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>>>>> To: <in...@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 of
>>>>>>>>> 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 and
>>>>>>>>> there and a few Pull requests here and there.
>>>>>>>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>>>>>>>> those pull requests into the Apache/$project repo mirror, so
>>>>>>>>> how are committers applying those pull requests? Are they pulling them into
>>>>>>>>> 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 to
>>>>>>>>> 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 are
>>>>>>>>> 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 yet,
>>>>>>>>> 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...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
PS since you use 3-way git merge from svn trunk branch onto feature1,
git should memorize the merges you already resolved and your base for
3base merge should be updated as a result so should not continuously
resolve conflicts you've already done.
The only nasty thing that may pop up continuously in my experience in
git is renaming/moving conflicts, i did not quite get a good handle on
those one. Since git does not 'memorize' the fact of moving, but only
'detects' them, sometimes they just keep popping up but that doesn't
have anything to do with svn integration.:(
-d
On Mon, Apr 4, 2011 at 2:56 PM, Dmitriy Lyubimov <dl...@gmail.com> wrote:
> On Mon, Apr 4, 2011 at 2:47 PM, David Jencks <da...@yahoo.com> wrote:
>> Hi Dmitriy,
>>
>> Everything you say makes sense, but IIUC the workflow you propose does not allow me to bring the svn changes at apache into my local feature1 branch. IIUC the svn changes are only pulled into my local master and I'll have to resolve all the merge conflicts at once right before I dcommit to svn. Unfortunately this doesn't work for me for large-scale refactorings where I need to keep current with svn changes over the several weeks I'm working.
>
>
> David, that's easy: keep your svn trunk up-to-date by running 'git svn
> rebase' on it. Since you presumably haven't committed any changes onto
> trunk that you haven't pushed to svn, there should be no conflicts.
>
> Once you sync'd up your local trunk branch with svn , just merge it
> into feature 1 using your regular git merge and then push it up to
> github.
>
> I.e. on trunk
> git checkout trunk
> git svn rebase
>
> on feature 1:
> git checkout feature1
> git pull (-- make sure you are in sync with remote github if needed)
>
> git merge trunk (-- now your svn commit history is locally on feature1)
> git push (-- fast-forward remote github feature1 history to include
> svn commits now)
>
> The merging and collaboration is really no specific to svn
> integration. The only thing that specific to svn integration is how
> you set up your trunk for svn rebases and how you squash feature1
> commit history onto it before pushing into svn (but even that is just
> a git feature).
>
>
>
>
>>
>> I think that between your and Paul's responses my theory about why I can't keep my github branch up to date (due to git svn rebase) is correct :-)
>>
>> many thanks!
>> david jencks
>>
>> On Apr 4, 2011, at 2:19 PM, Dmitriy Lyubimov wrote:
>>
>>> 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
>>> want.)
>>> 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
>>> mentioned.
>>>
>>> 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: <db...@visi.com>
>>>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>>>> To: <in...@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 of
>>>>>>>> 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 and
>>>>>>>> there and a few Pull requests here and there.
>>>>>>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>>>>>>> those pull requests into the Apache/$project repo mirror, so
>>>>>>>> how are committers applying those pull requests? Are they pulling them into
>>>>>>>> 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 to
>>>>>>>> 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 are
>>>>>>>> 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 yet,
>>>>>>>> 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...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
On Mon, Apr 4, 2011 at 2:47 PM, David Jencks <da...@yahoo.com> wrote:
> Hi Dmitriy,
>
> Everything you say makes sense, but IIUC the workflow you propose does not allow me to bring the svn changes at apache into my local feature1 branch. IIUC the svn changes are only pulled into my local master and I'll have to resolve all the merge conflicts at once right before I dcommit to svn. Unfortunately this doesn't work for me for large-scale refactorings where I need to keep current with svn changes over the several weeks I'm working.
David, that's easy: keep your svn trunk up-to-date by running 'git svn
rebase' on it. Since you presumably haven't committed any changes onto
trunk that you haven't pushed to svn, there should be no conflicts.
Once you sync'd up your local trunk branch with svn , just merge it
into feature 1 using your regular git merge and then push it up to
github.
I.e. on trunk
git checkout trunk
git svn rebase
on feature 1:
git checkout feature1
git pull (-- make sure you are in sync with remote github if needed)
git merge trunk (-- now your svn commit history is locally on feature1)
git push (-- fast-forward remote github feature1 history to include
svn commits now)
The merging and collaboration is really no specific to svn
integration. The only thing that specific to svn integration is how
you set up your trunk for svn rebases and how you squash feature1
commit history onto it before pushing into svn (but even that is just
a git feature).
>
> I think that between your and Paul's responses my theory about why I can't keep my github branch up to date (due to git svn rebase) is correct :-)
>
> many thanks!
> david jencks
>
> On Apr 4, 2011, at 2:19 PM, Dmitriy Lyubimov wrote:
>
>> 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
>> want.)
>> 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
>> mentioned.
>>
>> 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: <db...@visi.com>
>>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>>> To: <in...@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 of
>>>>>>> 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 and
>>>>>>> there and a few Pull requests here and there.
>>>>>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>>>>>> those pull requests into the Apache/$project repo mirror, so
>>>>>>> how are committers applying those pull requests? Are they pulling them into
>>>>>>> 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 to
>>>>>>> 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 are
>>>>>>> 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 yet,
>>>>>>> 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...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Current use of GitHub
Posted by David Jencks <da...@yahoo.com>.
Hi Dmitriy,
Everything you say makes sense, but IIUC the workflow you propose does not allow me to bring the svn changes at apache into my local feature1 branch. IIUC the svn changes are only pulled into my local master and I'll have to resolve all the merge conflicts at once right before I dcommit to svn. Unfortunately this doesn't work for me for large-scale refactorings where I need to keep current with svn changes over the several weeks I'm working.
I think that between your and Paul's responses my theory about why I can't keep my github branch up to date (due to git svn rebase) is correct :-)
many thanks!
david jencks
On Apr 4, 2011, at 2:19 PM, Dmitriy Lyubimov wrote:
> 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
> want.)
> 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
> mentioned.
>
> 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: <db...@visi.com>
>>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>>> To: <in...@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 of
>>>>>> 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 and
>>>>>> there and a few Pull requests here and there.
>>>>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>>>>> those pull requests into the Apache/$project repo mirror, so
>>>>>> how are committers applying those pull requests? Are they pulling them into
>>>>>> 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 to
>>>>>> 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 are
>>>>>> 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 yet,
>>>>>> 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...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
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
want.)
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
mentioned.
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: <db...@visi.com>
>>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>>> To: <in...@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 of
>>>>> 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 and
>>>>> there and a few Pull requests here and there.
>>>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>>>> those pull requests into the Apache/$project repo mirror, so
>>>>> how are committers applying those pull requests? Are they pulling them into
>>>>> 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 to
>>>>> 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 are
>>>>> 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 yet,
>>>>> 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...
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>
>
Re: Current use of GitHub
Posted by David Jencks <da...@yahoo.com>.
On Apr 4, 2011, at 10:15 AM, Dmitriy Lyubimov wrote:
>> At the moment I have given up on providing a publicly accessible look into what I'm doing until I commit to svn. AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch. If I'm missing something I'd love to know how to make this work.
>>
>
> Yes you can do it
>
> just add github remote.
>
> say you are on a trunk and your 'origin' points to apache git.
> then
>
> git remote add github git@github.com:<your-user>/<your-github-repo>
>
> and then you can push your branches to github e.g.
> git push github trunk:trunk
>
> What i usually do is i create issues branches locally and set them
> track the branch in github (since i never can push them into ASF) such
> as
>
> git checkout -b MAHOUT-555 (creates local brunch based on current
> branch, such as trunk)
> git push -u github MAHOUT-555:MAHOUT-555
>
> now the issue branch is set up to track github's brunch
> so you've done something there (or somebody done something there) then
> assuming you want to commit it by merging -- you can merge directly to
> github branch by
>
> git fetch github (fetch latest github branch snapshots)
> git checkout trunk (-- make sure we are on local trunk)
> git svn rebase (-- rewind trunk to latest in svn)
>
> git merge --squash github/MAHOUT-555 (-- merge github branch changes
> but don't commit and squash history so it looks like a single commit )
>
> //... resolve conflicts if necessary
> git commit -m "MAHOUT-555" (--format squashed history as single commit)
>
> git svn dcommit (-- push into svn) .
>
> ...
> now you have squashed issue commited to your local trunk
Hi Dmitriy,
I'm not sure how this relates to what I have been trying. I'm definitely a git newbie so might be missing a lot....
here's what I think I tried, from a local git repo that matches apache svn and a github branch:
git remote add github git@github.com....
git branch feature1
git checkout feature1
//do some work locally, committing to local git.
git svn rebase // pull in other changes from apache
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
//do some more work locally, committing to local git.
//no one else changed the github branch AFAICT
git svn rebase // pull in more apache changes, resolving merge conflicts
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???
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: <db...@visi.com>
>>>> From: "Gav..." <ga...@16degrees.com.au>
>>>> Date: April 2, 2011 11:45:10 PM PDT
>>>> To: <in...@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 of
>>>> 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 and
>>>> there and a few Pull requests here and there.
>>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>>> those pull requests into the Apache/$project repo mirror, so
>>>> how are committers applying those pull requests? Are they pulling them into
>>>> 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 to
>>>> 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 are
>>>> 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 yet,
>>>> 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...
>>>>
>>>>
>>>>
>>>
>>
>>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
> At the moment I have given up on providing a publicly accessible look into what I'm doing until I commit to svn. AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch. If I'm missing something I'd love to know how to make this work.
>
Yes you can do it
just add github remote.
say you are on a trunk and your 'origin' points to apache git.
then
git remote add github git@github.com:<your-user>/<your-github-repo>
and then you can push your branches to github e.g.
git push github trunk:trunk
What i usually do is i create issues branches locally and set them
track the branch in github (since i never can push them into ASF) such
as
git checkout -b MAHOUT-555 (creates local brunch based on current
branch, such as trunk)
git push -u github MAHOUT-555:MAHOUT-555
now the issue branch is set up to track github's brunch
so you've done something there (or somebody done something there) then
assuming you want to commit it by merging -- you can merge directly to
github branch by
git fetch github (fetch latest github branch snapshots)
git checkout trunk (-- make sure we are on local trunk)
git svn rebase (-- rewind trunk to latest in svn)
git merge --squash github/MAHOUT-555 (-- merge github branch changes
but don't commit and squash history so it looks like a single commit )
//... resolve conflicts if necessary
git commit -m "MAHOUT-555" (--format squashed history as single commit)
git svn dcommit (-- push into svn) .
...
now you have squashed issue commited to your local trunk
>
> -----
>
> 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: <db...@visi.com>
>>> From: "Gav..." <ga...@16degrees.com.au>
>>> Date: April 2, 2011 11:45:10 PM PDT
>>> To: <in...@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 of
>>> 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 and
>>> there and a few Pull requests here and there.
>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>> those pull requests into the Apache/$project repo mirror, so
>>> how are committers applying those pull requests? Are they pulling them into
>>> 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 to
>>> 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 are
>>> 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 yet,
>>> 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...
>>>
>>>
>>>
>>
>
>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@gmail.com>.
Also, if you keep resolving same conflicts during svn rebase, i think
something isn't right. I so far did not incur that so much . But my
github use is fairly recent (no more than several months). Although i
have been using git in general (and git-svn in particular) for several
years now.
On Mon, Apr 4, 2011 at 10:01 AM, David Jencks <da...@yahoo.com> wrote:
> I've been using git for all my non-trivial apache work for several months now. I've only used it for projects I'm a committer on.
>
> At the moment I have given up on providing a publicly accessible look into what I'm doing until I commit to svn. AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch. If I'm missing something I'd love to know how to make this work.
>
> so..
>
> I start by cloning the apache git mirror (following the instructions at http://wiki.apache.org/general/GitAtApache)
>
> I keep one or more branches locally for the different bits of the project I'm working on.
>
> Periodically I do git svn rebase to pull in svn commits
>
> If there are enough changes that I'm worried about "my house burned down" I do git bundle ** and put the result on people.apache.org
>
> When I'm ready I do git svn dcommit
>
> -----
>
> 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: <db...@visi.com>
>>> From: "Gav..." <ga...@16degrees.com.au>
>>> Date: April 2, 2011 11:45:10 PM PDT
>>> To: <in...@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 of
>>> 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 and
>>> there and a few Pull requests here and there.
>>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>>> those pull requests into the Apache/$project repo mirror, so
>>> how are committers applying those pull requests? Are they pulling them into
>>> 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 to
>>> 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 are
>>> 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 yet,
>>> 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...
>>>
>>>
>>>
>>
>
>
Re: Current use of GitHub
Posted by David Jencks <da...@yahoo.com>.
I've been using git for all my non-trivial apache work for several months now. I've only used it for projects I'm a committer on.
At the moment I have given up on providing a publicly accessible look into what I'm doing until I commit to svn. AFAICT github is useless for any project undergoing development since as soon as you do git svn rebase locally to pull in svn commits you can no longer push your changes to an existing github branch. If I'm missing something I'd love to know how to make this work.
so..
I start by cloning the apache git mirror (following the instructions at http://wiki.apache.org/general/GitAtApache)
I keep one or more branches locally for the different bits of the project I'm working on.
Periodically I do git svn rebase to pull in svn commits
If there are enough changes that I'm worried about "my house burned down" I do git bundle ** and put the result on people.apache.org
When I'm ready I do git svn dcommit
-----
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: <db...@visi.com>
>> From: "Gav..." <ga...@16degrees.com.au>
>> Date: April 2, 2011 11:45:10 PM PDT
>> To: <in...@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 of
>> 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 and
>> there and a few Pull requests here and there.
>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>> those pull requests into the Apache/$project repo mirror, so
>> how are committers applying those pull requests? Are they pulling them into
>> 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 to
>> 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 are
>> 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 yet,
>> 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...
>>
>>
>>
>
Re: Current use of GitHub
Posted by Steve Loughran <st...@apache.org>.
On 15/04/11 07:52, Guillaume Nodet wrote:
> Since the git mirrors are available at the ASF, I'm now exclusively
> using git-svn
> unless I need to do a release in which case
> I need to revert back to svn for maven to be able to do the release.
> For branches and patches, it's easy to add remote a git remote repository to
> your local repo pointing to a fork, so that you can cherry-pick or merge from a
> fork on github and then svn dcommit into the svn tree at the ASF.
> Git really consider the git-svn branch as a real branch, so there's no
> problem here.
>
> Also, in Karaf for example, we're maintaining bug fix branches. Those
> are stored
> in svn as real branches, but also available in git-svn as git branches, so that
> cherry-picking and backporting fixes is way easier than using pure svn.
>
> However, not having a pure git master repository has some limitations,
> mostly the fact
> that we can't really use a branch-per-bug workflow such as the one described at
> http://nvie.com/posts/a-successful-git-branching-model/
> Being able to support that would be a big win for us.
the MRUnit test tool -moved from Hadoop/contrib to incubation- are
interested in using Git if it were hosted locally, as a precursor to
seeing how well it works for Hadoop development in general, initially
for code (and letting reviewers merge in branches published to github),
playing with Gerrit as and when its possible.
Is there any experimental git "repository" in apache they could start with?
Re: Current use of GitHub
Posted by Guillaume Nodet <gn...@gmail.com>.
Since the git mirrors are available at the ASF, I'm now exclusively
using git-svn
unless I need to do a release in which case
I need to revert back to svn for maven to be able to do the release.
For branches and patches, it's easy to add remote a git remote repository to
your local repo pointing to a fork, so that you can cherry-pick or merge from a
fork on github and then svn dcommit into the svn tree at the ASF.
Git really consider the git-svn branch as a real branch, so there's no
problem here.
Also, in Karaf for example, we're maintaining bug fix branches. Those
are stored
in svn as real branches, but also available in git-svn as git branches, so that
cherry-picking and backporting fixes is way easier than using pure svn.
However, not having a pure git master repository has some limitations,
mostly the fact
that we can't really use a branch-per-bug workflow such as the one described at
http://nvie.com/posts/a-successful-git-branching-model/
Being able to support that would be a big win for us.
On Mon, Apr 4, 2011 at 07:17, David Blevins <da...@gmail.com> 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: <db...@visi.com>
>> From: "Gav..." <ga...@16degrees.com.au>
>> Date: April 2, 2011 11:45:10 PM PDT
>> To: <in...@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 of
>> 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 and
>> there and a few Pull requests here and there.
>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>> those pull requests into the Apache/$project repo mirror, so
>> how are committers applying those pull requests? Are they pulling them into
>> 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 to
>> 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 are
>> 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 yet,
>> 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...
>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/
Fwd: Current use of GitHub
Posted by David Blevins <da...@gmail.com>.
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: <db...@visi.com>
> From: "Gav..." <ga...@16degrees.com.au>
> Date: April 2, 2011 11:45:10 PM PDT
> To: <in...@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 of
> 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 and
> there and a few Pull requests here and there.
> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
> those pull requests into the Apache/$project repo mirror, so
> how are committers applying those pull requests? Are they pulling them into
> 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 to
> 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 are
> 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 yet,
> 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...
>
>
>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@apache.org>.
Thanks! No, i did not see this page yet. That's why hash doesn't
match. Thanks a bunch.
On Mon, Apr 4, 2011 at 2:33 AM, Jukka Zitting <ju...@gmail.com> wrote:
> Hi,
>
> On Sun, Apr 3, 2011 at 10:01 AM, Dmitriy Lyubimov <dl...@apache.org> wrote:
>> ps -- so obviously it would help if ASF git mirrors had the same
>> history trees as git-svn trees. Then anything derived from ASF git
>> would be directly mergeable for commit. I am not sure why current ASF
>> git commit hashes do not match what i get in git-svn but it would have
>> been great if they did (or perhaps i have a wrong version of git-svn?)
>
> Did you follow the "Git for Apache committers" instructions from [1]?
> If you do, then your git svn dcommit should produce the same commit
> hashes as the ones created by git.apache.org. The important bit is
> having an up to date svn.authorsfile configured.
>
> [1] http://wiki.apache.org/general/GitAtApache
>
> BR,
>
> Jukka Zitting
>
Re: Current use of GitHub
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, Apr 3, 2011 at 10:01 AM, Dmitriy Lyubimov <dl...@apache.org> wrote:
> ps -- so obviously it would help if ASF git mirrors had the same
> history trees as git-svn trees. Then anything derived from ASF git
> would be directly mergeable for commit. I am not sure why current ASF
> git commit hashes do not match what i get in git-svn but it would have
> been great if they did (or perhaps i have a wrong version of git-svn?)
Did you follow the "Git for Apache committers" instructions from [1]?
If you do, then your git svn dcommit should produce the same commit
hashes as the ones created by git.apache.org. The important bit is
having an up to date svn.authorsfile configured.
[1] http://wiki.apache.org/general/GitAtApache
BR,
Jukka Zitting
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@apache.org>.
ps -- so obviously it would help if ASF git mirrors had the same
history trees as git-svn trees. Then anything derived from ASF git
would be directly mergeable for commit. I am not sure why current ASF
git commit hashes do not match what i get in git-svn but it would have
been great if they did (or perhaps i have a wrong version of git-svn?)
On Sun, Apr 3, 2011 at 12:51 AM, Dmitriy Lyubimov <dl...@apache.org> wrote:
> I am using github.
>
> But there are different scenarious here.
>
> Scenario #1: you fork ASF git (or github mirror) and create private
> branches to work. Then you create a patch and apply as usuall (using
> patch -p1) to your git-svn branch. from there you could then use
> git-svn dcommit.
>
> The problem with that approach is that you can't merge into git-svn
> branch as it happens that git-svn actually creates different hashes in
> commit tree than apache's git mirror. So those histories cannot be
> 3-way merged and commits can't be squashed as it would naturally occur
> . In addition, since there's a delay between git mirror and actual
> snapshot, there's always a danger that somebody commits and git
> doesn't see it and your patch would go stale until you can merge it
> properly when new commit finally goes thru git replica.
>
> So it's unnatural. so i switched to
> Scenario 2:
> instead of forking apache git, i push my git-svn branch directly into
> github and then follow everything i said in scenario #2 except i can
> now merge-squash directly into git-svn branch after work is done and i
> can rebase my git-svn snapshot at any moment. I still have to publish
> git diff to jira so others can review it though.
>
> If several people need to work on the same issue then they can do pull
> requests to my issues and then i would be able to incorporate their
> work into final squash-merge and git-svn dcommit. Although to tell you
> the truth I never collaborated on the same patch with anyone yet. Our
> project is fairly too sparsely populated for that so far.
>
> -dmitriy
>
> On Sat, Apr 2, 2011 at 11:45 PM, Gav... <ga...@16degrees.com.au> wrote:
>> 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 of
>> 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 and
>> there and a few Pull requests here and there.
>> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
>> those pull requests into the Apache/$project repo mirror, so
>> how are committers applying those pull requests? Are they pulling them into
>> 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 to
>> 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 are
>> 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 yet,
>> 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...
>>
>>
>>
>
Re: Current use of GitHub
Posted by Dmitriy Lyubimov <dl...@apache.org>.
I am using github.
But there are different scenarious here.
Scenario #1: you fork ASF git (or github mirror) and create private
branches to work. Then you create a patch and apply as usuall (using
patch -p1) to your git-svn branch. from there you could then use
git-svn dcommit.
The problem with that approach is that you can't merge into git-svn
branch as it happens that git-svn actually creates different hashes in
commit tree than apache's git mirror. So those histories cannot be
3-way merged and commits can't be squashed as it would naturally occur
. In addition, since there's a delay between git mirror and actual
snapshot, there's always a danger that somebody commits and git
doesn't see it and your patch would go stale until you can merge it
properly when new commit finally goes thru git replica.
So it's unnatural. so i switched to
Scenario 2:
instead of forking apache git, i push my git-svn branch directly into
github and then follow everything i said in scenario #2 except i can
now merge-squash directly into git-svn branch after work is done and i
can rebase my git-svn snapshot at any moment. I still have to publish
git diff to jira so others can review it though.
If several people need to work on the same issue then they can do pull
requests to my issues and then i would be able to incorporate their
work into final squash-merge and git-svn dcommit. Although to tell you
the truth I never collaborated on the same patch with anyone yet. Our
project is fairly too sparsely populated for that so far.
-dmitriy
On Sat, Apr 2, 2011 at 11:45 PM, Gav... <ga...@16degrees.com.au> wrote:
> 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 of
> 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 and
> there and a few Pull requests here and there.
> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
> those pull requests into the Apache/$project repo mirror, so
> how are committers applying those pull requests? Are they pulling them into
> 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 to
> 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 are
> 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 yet,
> 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...
>
>
>
Re: Current use of GitHub
Posted by Kristian Rosenvold <kr...@gmail.com>.
Being in Europe, the QoS of the european mirror does not
seen good enough for proper git-svn operation. What's even worse,
it seems like recent versions of git (1.7.1 in my case)
can get permanently lost over git-svn when the rebase fails,
so I've started using this workflow:
I use a "full" git workflow as if svn does not exist,
and I push to my personal github clone at will. I do not
make any attempts at keeping my local clone in synch
with svn, but I pull from asf git. I rebase branches in my
own git repo and on github "at will".
Instead I keep a temporary clone of svn
(git svn clone -rHEAD https://svn.apache.org/repos/asf/maven/surefire/trunk)
I then just add my own github repo as a remote to the temporary
clone, cherry pick from there and dcommit back. I delete this
clone whenever I feel like it.
I'm talking about https://github.com/apache/maven-surefire/network
here. Note that I intentionally sent the "network" link instead of the
front page
link. If you scroll along the network graph you'll see that
I keep a large number of branches representing open
issues I have done some amount of work on. At least one
of my non-committer collaborators knows to go
searching for test-cases I might have made for
some open issue there; exposing partially
completed work is one of the great features
github adds.
I have picked a couple of one-line fixes straight
off the network graph view, but generally
it goes by jira+patch.
From a general provenance/mailing list perspective I
think the discussion at
https://github.com/mrenouf/maven-surefire/commit/44b9a7a1f1b03fde343b133d451899c1e2430b3d
is quite interesting. Using tools like github invariably
leads to discussions about code happening in/near the code.
Since the user in question can rebase/remove
this commit, I think there might be a case for
aggregating these things into a more persistent record somewhere.
> Also, apart from Github, how else are Git only users providing patches to
> projects, which patch programs are in use, and of those which
> are most used by those projects/committers that need to apply them.
It seems to me git users use git diff.
I generally use git-apply for *all* patches I receive,
because it seems to be much more tolerant than "patch".
At the least sign of trouble I just create a new git branch
at around the date the patch was submitted in history
and rebase it to head. Works like a charm and no more
stale patches.
Kristian
Re: Current use of GitHub
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Kulp wrote on Sun, Apr 03, 2011 at 09:01:22 -0400:
> > Also, apart from Github, how else are Git only users providing patches to
> > projects, which patch programs are in use, and of those which
> > are most used by those projects/committers that need to apply them.
>
> You can just use "git diff" to produce a patch just like svn diff and attach
> it to a JIRA. The main difference is that there is an extra directory so
> when you apply, you need "patch -p1" instead of -p0. Not a big deal really.
This isn't "current use", but:
svn 1.7 will have an 'svn patch' command that knows how to parse git diffs.
(it understands the a/,b/ prefix, file addition/renaming, etc)
Daniel
(been reading about git this weekend)
Re: Current use of GitHub
Posted by Daniel Kulp <dk...@apache.org>.
I blogged a little about my use of git-svn a couple years ago:
http://www.dankulp.com/blog/?p=117
It's been 2 years, but I think it still applies.
But onto your questions.....
On Sunday 03 April 2011 2:45:10 AM Gav... wrote:
> 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 of
> 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 and
> there and a few Pull requests here and there.
> That is where it gets fuzzy for me. Obviously, no-one can actually pull in
> those pull requests into the Apache/$project repo mirror, so
> how are committers applying those pull requests? Are they pulling them into
> their own copies of the mirror, converting them into a patch
> that svn understands and then applying, if so, how? If not, how else?
I have a "clone" of the Apache mirror and do "git pulls" from there and
generally my development branches and such track the "trunk" branch from
there. Thus, "git svn dcommit" commmits any changes on those branches back
to Apache SVN.
For stuff coming from other git repos (like GitHub), you can add the other
repo as a remote (git remote add ....) and then create local branches that
track those branches as well. In general, I would create a local branch that
tracks the remote branch, do a review, maybe offer suggestions via email on
dev list, do additional pulls to pull in the suggested changes, etc... When
ready, I'll create a new branch that tracks the ASF trunk and merge the other
branch onto it. Usually, I'll use --squash to squash it down to a single
commit so it would act like a single "patch" instead of a bunch of individual
commits, but that's kind of optional.
> Also, apart from Github, how else are Git only users providing patches to
> projects, which patch programs are in use, and of those which
> are most used by those projects/committers that need to apply them.
You can just use "git diff" to produce a patch just like svn diff and attach
it to a JIRA. The main difference is that there is an extra directory so
when you apply, you need "patch -p1" instead of -p0. Not a big deal really.
> For those of you that are committers and have direct access to svn, but are
> preferring to use Git before then committing your work to svn,
> what is your workflow and tools used (whether or not it involves GitHub)
Pretty much "git pull" periodically to pull changes from the ASF mirrors.
"git branch fooFeature origin/trunk" to create a branch to work on and "git
checkout fooFeature" to start working on the branch. "git commit" to commit
changes and "git svn dcommit" to push them back to svn trunk.
Dan
>
> No deviating into what could happen or what would be a good idea please
> yet, 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...
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com