[haiku-development] Re: merge branch

  • From: Niels Reedijk <niels.reedijk@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Thu, 20 May 2010 00:06:41 +0200

Hey,

On 19 May 2010 19:36, Andreas Färber <andreas.faerber@xxxxxx> wrote:
> Am 19.05.2010 um 18:33 schrieb Niels Reedijk:
>
>> On 19 May 2010 17:01, Andreas Färber <andreas.faerber@xxxxxx> wrote:
>>>
>>> Am 18.05.2010 um 11:09 schrieb Niels Reedijk:
>>>
>>>> My next developer-tools project is going to be an hg<->svn bridge. I
>>>> hope to deliver a proof-of-concept soon (which would then also be
>>>> useful for a git<->svn bridge). The difference from hgsvn and
>>>> hgsubversion is that it is all done server-side, meaning the end user
>>>> does not have to bother with the logistics that it all involves.
>>>
>>> Is there really a need to do this for git?
>>
>> Yes there is. All solutions depend on a personal git <-> svn
>> connection.
>
>> This means that everybody is creating his own unique
>> repository, with unique changeset ids.
>
> Changeset hashes will be identical if the changes and commit messages(?) are
> identical. That is, the SVN server needs to be the same since it is
> mentioned in the commit message.
>
> So iiuc the only "uniqueness" arises if I use svn://svn.berlios.de and a
> committer uses svn+ssh://user@xxxxxxxxxxxxxxxx (or a local SVN mirror). Then
> r12345 will have different hashes - but since no one seemed to like hashes
> here... ;-)

I didn't know that. I am unable to wrap my head around the logic of
free-floating changesets and whether that would work with git-svn: I
actually doubt it as it says (in the Caveats section):

"For the sake of simplicity and interoperating with a less-capable
system (SVN), it is recommended that all git svn users clone, fetch
and dcommit directly from the SVN server, and avoid all git
clone/pull/merge/push operations between git repositories and
branches."

Having said that, I cannot rule out that my method has the same caveats.

>> That means that between git
>> trees the changesets cannot be exchanged, which takes away one of the
>> advantages of a distributed system.
>
> In which way "cannot be exchanged"? I doubt that git-am cares as long as the
> patch applies, I'm pretty sure I've used it successfully even with local
> patches applied (so different base hash). And git-rebase should work fine,
> ignoring duplicate changes.

Again from the Caveats:

" The recommended method of exchanging code between git branches and
users is git format-patch and git am, or just 'dcommit'ing to the SVN
repository."

So yes, you can exchange patches, but no pulling/pushing.

N>

Other related posts: