<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi,<br>
    <br>
    nope using git is not an option. topgit might be, but it's even
    worse then quilt. If you don't like quilt, stgit might be what you
    are looking for. Unfortunately it is for local use only. If it were
    possible to use it server side it would certainly be an option.<br>
    Please understand that I'm not going into details why pure git is
    not an option. I tried it for a different project and failed and
    there are way more experienced people then me on the x2go team, who
    agree on this. If you can show us a project where it actually works
    using git, then we may continue this discussion, but I'm afraid
    until then it's a waste of developers time.<br>
    If this sounds rude, it's not against you, I just want to kill the
    discussion before it starts.<br>
    <br>
    Cheers<br>
    Morty<br>
    <br>
    <br>
    Am 19.05.2012 19:51, Mihai Moldovan schrieb:
    <blockquote cite="mid:4FB7DD8B.4070605@ionic.de" type="cite">
      <pre wrap="">Hi,

I'm wondering why you guys are using quilt for managing patches to the nx-libs
repository.

I see that the general purpose is to have the original nomachine source base
intact/unchanged to track changes easily.

However, quilt is a pain to use (i.e., omitting a patch in the series or
changing it), especially taking into consideration that git _already is_ a SCM.

Wouldn't it be easier to actually use multiple branches for that purpose?

[nomachine]--{3.5.0}------------{3.6.0 (future)}----...
                                \-->[x2go]-------\-->------------...

where [name] is a branch named "name", {name} is a tag named "name" and the
arrows denote merges.

Note that we don't want to merge x2go project changes back into the original
nomachine source, thus not merging the x2go branch into the nomachine branch.
However, we _want_ to merge new versions of nomachine's source into the x2go
branch at some point.

Also, this setup is very flexible. If, for instance, you decide to still support
the x2go nx 3.5.0 branch, even though nomachine nx 3.6.0 has been released,
simply branch off the x2go branch, like this:

[nomachine]--{3.5.0}------------{3.6.0 (future)}----...
                                \-->[x2go]-------\-->------------...
                                          \-->[x2go 3.5.0]--------...

Afterwards, the nomachine branch (tag 3.6.0) can then be merged into the x2go
branch and the x2go 3.5.0 life on happily ever after.

It is way easier to rebase a branch such as to not include a specific commit
(cherry-pick), than omit a patch in the quilt patch series.

Not sure if it's only me, but this quilt stuff is really messing with my work flow.

Please drop your thoughts in here.

Best regards,


Mihai

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
X2Go-Dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:X2Go-Dev@lists.berlios.de">X2Go-Dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/x2go-dev">https://lists.berlios.de/mailman/listinfo/x2go-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>