Re: [Openvpn-devel] FreeBSD funny in the code

[Bernhard Schmidt]

On 01.03.2010 22:59, David Sommerseth wrote:


Could you please have a look at git://git.birkenwald.de/openvpn.git
test-rebase branch? The history of gert-ipv6 was starting to look a bit
weird (duplicate commits with the same content), to I rebased it on your
bugfix2.1 branch (and dropped the duplicate commits in the process). No
difference in the content whatsoever and the history looks much better,
but I'm not exactly sure whether this is the right thing to do.



I tried to both merge and rebase both your gert-ipv6 branch and the
test-rebase branch from the allmerged branch.  That was quite an
interesting experience.

The test-rebase branch gave most problems.  Both rebase and merge got
painful.  While with the gert-ipv6 gave only (expected, though) issues
with rebase.  Merging in gert-ipv6 was more or less painless.


Yeah ... I'm still having a hard time to wrap my head around the gory 
git details, but I think rebasing was a bad idea to begin with. 
Especially in the other direction (you rebasing on gerts tree) :-)


As far as I understand it rebasing works by rolling back your local tree 
to the point you branched from the upstream tree (recording all changes 
in the progress), fast-forwarding to the HEAD of the upstream (at this 
point local = upstream) and then reapplying all your local changes. This 
fits perfectly in a model where you maintain a feature branch upstream 
has not yet seen. By doing that you guarantee that your feature branch 
is always a set of patches on top of the current upstream HEAD 
(guaranteed to merge without conflicts when pulled into upstream), thus 
making any conflicts that evolve during continued upstream development 
entirely the feature branch's problem to solve.


When I rebased gert-ipv6 on bugfix2.1 I essentially dropped the old 
changesets and recreated new ones (with different ids). So when you try 
to merge that rebased tree your git sees new commits and tries to merge 
them on the tree already containing the changes. Which is something git 
can only detect (already applied and so on) if that part of the code has 
not been touched with subsequent changesets.


As far as I can see it, the only point where rebasing would be useful is 
to rebase allmerged on bugfix2.1 and bugfix2.1 on master. But I don't 
know how much this will break. :-)


Bernhard

Re: [Openvpn-devel] FreeBSD funny in the code

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/03/10 22:41, Bernhard Schmidt wrote:
> Hi David,
> 
>>> It doesn't make a difference at the moment (since the patch came from
>>> feat_ipv6_payload in the first place), but what's the general wish for
>>> the future? What to rebase on?
>>
>> To be very honest, I'm very uncertain about what's best.  Because it
>> will a lot of changes in multiple branches.  But as I'm able now to keep
>> the bugfix2.1 branch pretty clean with only bugfixes, I begin to lean
>> towards that you should consider to rebase on that branch.
> 
> Could you please have a look at git://git.birkenwald.de/openvpn.git
> test-rebase branch? The history of gert-ipv6 was starting to look a bit
> weird (duplicate commits with the same content), to I rebased it on your
> bugfix2.1 branch (and dropped the duplicate commits in the process). No
> difference in the content whatsoever and the history looks much better,
> but I'm not exactly sure whether this is the right thing to do.
> 

I tried to both merge and rebase both your gert-ipv6 branch and the
test-rebase branch from the allmerged branch.  That was quite an
interesting experience.

The test-rebase branch gave most problems.  Both rebase and merge got
painful.  While with the gert-ipv6 gave only (expected, though) issues
with rebase.  Merging in gert-ipv6 was more or less painless.

The only conflict was the title string in options.c, which will always
be a conflict area when merging in multiple feature branches.  But this
conflict is really trivial, and I'm not worried about that one.

I will try to ask some kernel guys about such situation what they would
recommend.

Regarding to the "duplicated commits", I believe that's what's happens
especially when cherry-picks are involved.  Not sure how bad Gerts
history was though.  But you might get an idea when using git log
- --graph ... then you see better which branch each commits belongs to.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuMOK0ACgkQDC186MBRfrqiXACfVUnAITzSpEJCM74dgrVfCQPY
PJ8An0NbhiMdxIUkZCrmRr7+SlLlN3Rs
=d7ys
-END PGP SIGNATURE-

Re: [Openvpn-devel] FreeBSD funny in the code

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/03/10 22:09, Bernhard Schmidt wrote:
> David Sommerseth  wrote:
> 
> Hi David,
> 
>>> David, could you please pull my branch from Berni, and move that patch
>>> to wherever bugfixes/code cleanups go?  It should merge easily into 
>>> all branches.
>>
>> Pushed and pulled.  I've only put your extra commit into the bugfix2.1
>> branch (as a cherry-pick), and merged it into allmerged.
>>
>> At some point, you might consider to pull in the bugfix2.1 branch into
>> your feat_ipv6_payload branch, just to get in those bug fixes.
> 
> Hm, I thought we (Gert :-) ) were supposed to develop on top of master?
> I don't have any preference either way, but as soon as we merge
> bugfix2.1 into feat_ipv6_payload all those commits are there.

Yes, true.

> It doesn't make a difference at the moment (since the patch came from
> feat_ipv6_payload in the first place), but what's the general wish for
> the future? What to rebase on?

To be very honest, I'm very uncertain about what's best.  Because it
will a lot of changes in multiple branches.  But as I'm able now to keep
the bugfix2.1 branch pretty clean with only bugfixes, I begin to lean
towards that you should consider to rebase on that branch.

The master branch should only contain James stuff (plus some files
useful for my SVN pulls), while merging in bugfix2.1 may help avoid
merge conflicts.  As Gerts commit in regards to the bug fix he sent in
was in the middle of his ipv6 commits, I had to cherry-pick it to get it
into a proper branch.  This causes the commit history to be kind of
interesting, but messy.  I want to try to avoid this, to be honest.

Anyway, if you merge in bugfix2.1 on the way, that would potentially
remove possible conflicts in future merges when I merge all branches
into allmerged.  And bugfix2.1 will contain more or less important
fixes, and fixes only, which really should be considered to go into
James stable tree.  I will consequently merge master and bugfix2.1 first
into allmerged, then the feature branches with changes in random order.
 So in that perspective, all feature branches will start on the
bugfix2.1 code.

I don't want to see feature branches getting merged without agreeing on
closing one of them down for good, though.

I am not sure what is the best approach in the very end, and I am open
for advices and others experiences as well.


kind regards,

David Sommerseth


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuMMKEACgkQDC186MBRfrrN3ACeOik4kFVc25Rku2VV+ukJpiD6
ItAAn07VIXG4U3MDjQult33YqKRrSlyC
=N6X0
-END PGP SIGNATURE-

Re: [Openvpn-devel] FreeBSD funny in the code

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/10 23:14, Gert Doering wrote:
> Hi,
> 
> On Sun, Feb 28, 2010 at 04:37:45PM +0100, David Sommerseth wrote:
>> On 28/02/10 16:10, Eric F Crist wrote:
>>> ACK,
>>>
>>> It's not you, that's duplicate code.
>>
>> ACK.  I this is indeed duplicated.
> 
> Thanks.  I have committed this to my branch (because I'm too tired right 
> now to get branching right) as dd66b12647852e3f1267be70b0fb3b11deedf377
> 
> David, could you please pull my branch from Berni, and move that patch
> to wherever bugfixes/code cleanups go?  It should merge easily into 
> all branches.

Pushed and pulled.  I've only put your extra commit into the bugfix2.1
branch (as a cherry-pick), and merged it into allmerged.

At some point, you might consider to pull in the bugfix2.1 branch into
your feat_ipv6_payload branch, just to get in those bug fixes.

> (As a side note: there is new IPv6 related code in my branch, of course,
> so please pull that to feat_ipv6_payload as well :-) - mostly code cleanups,
> and Win32 preparations)

Done!

A crash course for branching:

  git checkout -b  

Branch point can be a commit ID, a tag name or another branch name.
It's that easy :)  This will also "move" you over to the new

If you want to branch without "moving" over to the newly created branch,
you can use:

   git branch  []

If you don't provide branch point, it will branch at your last commit in
the branch you are at when doing this.

To push a new branch ... git push  .



kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuK9KwACgkQDC186MBRfroEnwCfdDZ2buGz50TAjUuZyp0hb0SG
4KMAoJQX0eKkhXFF7sfjMrXUG1c+MTJ4
=QWB7
-END PGP SIGNATURE-

Re: [Openvpn-devel] FreeBSD funny in the code

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/10 16:10, Eric F Crist wrote:
> ACK,
> 
> It's not you, that's duplicate code.
> 

ACK.  I this is indeed duplicated.


David S.

> On Feb 28, 2010, at 09:05:46, Gert Doering wrote:
> 
>> Hi,
>>
>> tun.c contains this code, in the 
>>
>> #elif defined(TARGET_FREEBSD)||defined(TARGET_DRAGONFLY)
>>
>> part of do_ifconfig() (about line 983 in the IPv6 payload branch):
>>
>> - snip 
>>  else { 
>>if (tt->topology == TOP_SUBNET)
>>argv_printf (,
>>  "%s %s %s netmask %s mtu %d up",
>>  IFCONFIG_PATH,
>>  actual, 
>>  ifconfig_local,
>>  ifconfig_remote_netmask,
>>  tun_mtu
>>  );
>>else
>>argv_printf (,
>>  "%s %s %s netmask %s mtu %d up",
>>  IFCONFIG_PATH,
>>  actual,
>>  ifconfig_local,
>>  ifconfig_remote_netmask,
>>  tun_mtu
>>  );
>>  }   
>> - snip 
>>
>> Is it just me needing new glasses, or is this twice the very same code,
>> with a little bit of different indentation?
>>
>> If other people see this too, I'll send in a patch that drops the 
>> duplicate bits.  The tun.c code is still hard enough to read...
>>
>> gert
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkuKjckACgkQDC186MBRfrqFfQCfdlWA8m9F37wbqwY/mfd8I2VQ
t08An2o6k1Gyp8+7i61d2iPc+OfM1SCj
=u8Uw
-END PGP SIGNATURE-