Hi,

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. 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. If this sounds rude, it's not against you, I just want to kill the discussion before it starts.

Cheers Morty

Am 19.05.2012 19:51, Mihai Moldovan schrieb:

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

---

X2Go-Dev mailing list X2Go-Dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev

Hi Mihai,

On Sa 19 Mai 2012 19:51:07 CEST Mihai Moldovan wrote:

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

Currently, we do not consider us as upstream for NX, only as a
redistributor. So, keeping track of NX upstream is one reason for
combining git+quilt.

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

We had that before (for x2goagent and libxcomp* when they were still
separate code trees) and it was very difficult to keep track of _our_
changes and _NoMachine_ changes. With quilt this is now very very easy.

We also had the case that many patches needed an update after
NoMachine bumped an NX upstream release. So what happens then is that
you have NoMachine upstream, then commit X2Go changes to your branch,
merge from upstream again and then patch your own patches if a
follow-up upstream release breaks your changes. It becomes very hard
then to keep track of your changes, esp. with so many patches as we
currently have for NX. Note that they also stack on top of each other...

The current approach is the easiest and the cleanest approach we have
ever had for maintaining NX / X2Go agent. But that's my personal view
only.

Greets, Mike

--

DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...