You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Paul Querna <pa...@querna.org> on 2010/01/05 02:17:36 UTC
git svn & merging
Common use case of git, merging a remote branch:
git remote add foo git://githubsareus.example.com/foo.git
git pull foo
git merge foo/master
Now, if you did a 'git svn dcommit', all of the commits done by the
remote 'foo', would be attributed to you, with no chance to edit the
log message, saying who contributed them.
It seems the only solution is to create a diff, apply the diff, and
create a new log message:
git remote add foo git://githubsareus.example.com/foo.git
git checkout -b foo-merge
git merge jmoe/master
git diff trunk foo-merge >foo.patch
# now apply .patch & set commit log as normal....
Is there a better way to handle this?
Specifically for libcloud, we have always used github, and still get
github pull requests from github users containing changes to libcloud.
Thanks,
Paul
Re: git svn & merging
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Mar 25, 2010 at 10:57 AM, Mark Struberg <st...@yahoo.de> wrote:
> There is for example no way to checkout 'old' OWB versions (before
> we became a TLP and got moved by gav)!
>
> I can still see the commit comments from the time before the move,
> but I cannot access the content.
See peg revisions: http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html
BR,
Jukka Zitting
Re: git svn & merging
Posted by Mark Struberg <st...@yahoo.de>.
git is not perfect and nor is SVN.
I e.g. still see a lot problems with the svn in general.
There is for example no way to checkout 'old' OWB versions (before we became a TLP and got moved by gav)!
I can still see the commit comments from the time before the move, but I cannot access the content.
LieGrue,
strub
--- Werner Punz <we...@gmail.com> schrieb am Do, 25.3.2010:
> Von: Werner Punz <we...@gmail.com>
> Betreff: Re: git svn & merging
> An: infrastructure-dev@apache.org
> Datum: Donnerstag, 25. März, 2010 10:29 Uhr
> Am 05.01.10 10:10, schrieb Mark
> Struberg:
> > The problem with dcommit is the time-span acausality
> which is possible with git.
> > Have you tried
> > git merge --squash?
> > This will package all the diffs from foo into a commit
> on top of your HEAD.
> > Maybe you can also do a manual git-rebase of the
> changes to your HEAD, but that would be much more work.
> >
> > In either way you will loose the trackback to foo :(
> >
> > LieGrue,
> > strub
> >
> Just my 2c git svn is more or less a semi working bridge,
> which bridges two systems almost non bridgable in their
> details.
> I have used git-svn for the last half year against Apache
> repos and I am still undecided whether it is worth it, on
> one hand I love
> the local commits which I then can sync into one dcommit
> against the server (which I would hate to lose) on the other
> hand git-svn has its fair share of problems
> (especially if you do more complicated stuff against the
> svn side+the sync time on the apache svn servers which need
> a commit delay period between two revision commits)
> and the lack of svn external support currently lets me
> rethink my usage strategy.
> Unfortunately HGs SVN support is even worse, and
> native support of HG or Git is probably out of scope for
> now (even if it would be supported many projects probably
> would not migrate)
>
> Kind of a sad situation of having those wonderful systems
> and not being able to use them to their full extent.
>
> Werner
>
>
>
__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
Re: git svn & merging
Posted by Werner Punz <we...@gmail.com>.
Am 05.01.10 10:10, schrieb Mark Struberg:
> The problem with dcommit is the time-span acausality which is possible with git.
> Have you tried
> git merge --squash?
> This will package all the diffs from foo into a commit on top of your HEAD.
> Maybe you can also do a manual git-rebase of the changes to your HEAD, but that would be much more work.
>
> In either way you will loose the trackback to foo :(
>
> LieGrue,
> strub
>
Just my 2c git svn is more or less a semi working bridge, which bridges
two systems almost non bridgable in their details.
I have used git-svn for the last half year against Apache repos and I am
still undecided whether it is worth it, on one hand I love
the local commits which I then can sync into one dcommit against the
server (which I would hate to lose) on the other hand git-svn has its
fair share of problems
(especially if you do more complicated stuff against the svn side+the
sync time on the apache svn servers which need a commit delay period
between two revision commits)
and the lack of svn external support currently lets me rethink my usage
strategy.
Unfortunately HGs SVN support is even worse, and
native support of HG or Git is probably out of scope for now (even if it
would be supported many projects probably would not migrate)
Kind of a sad situation of having those wonderful systems and not being
able to use them to their full extent.
Werner
Re: git svn & merging
Posted by Mark Struberg <st...@yahoo.de>.
The problem with dcommit is the time-span acausality which is possible with git.
Have you tried
git merge --squash?
This will package all the diffs from foo into a commit on top of your HEAD.
Maybe you can also do a manual git-rebase of the changes to your HEAD, but that would be much more work.
In either way you will loose the trackback to foo :(
LieGrue,
strub
--- On Tue, 1/5/10, Paul Querna <pa...@querna.org> wrote:
> From: Paul Querna <pa...@querna.org>
> Subject: git svn & merging
> To: infrastructure-dev@apache.org
> Date: Tuesday, January 5, 2010, 2:17 AM
> Common use case of git, merging a
> remote branch:
>
> git remote add foo
> git://githubsareus.example.com/foo.git
> git pull foo
> git merge foo/master
>
> Now, if you did a 'git svn dcommit', all of the commits
> done by the
> remote 'foo', would be attributed to you, with no chance to
> edit the
> log message, saying who contributed them.
>
> It seems the only solution is to create a diff, apply the
> diff, and
> create a new log message:
> git remote add foo
> git://githubsareus.example.com/foo.git
> git checkout -b foo-merge
> git merge jmoe/master
> git diff trunk foo-merge
> >foo.patch
> # now apply .patch & set
> commit log as normal....
>
> Is there a better way to handle this?
>
> Specifically for libcloud, we have always used github, and
> still get
> github pull requests from github users containing changes
> to libcloud.
>
> Thanks,
>
> Paul
>