Yes, this is correct. I am waiting to do so until I get an official sign-off that the new packages work better than the old ones (i.e. users are reporting that the new packages do not crash, etc.). Honestly I'm not sure how to do this in anything resembling a sane manner in GIT. I was considering distribution of the large patch file as an update to the existing 3.5.13 sources, but comments and discussion are definitely welcome on this subject! Tim

I know that. :-) The problem is "How do I apply patches to an existing tagged branch to create a new tagged branch that is completely independent of the main development branch". Tim

On 2 May 2012, Robert Xu spake thusly: Yep. More generally, while you have a tag checked out, that 'detached HEAD' git talks about *is* a branch. It's a transient one that doesn't have a name, but if you look in 'git branch' while you're there, you'll see you still appear in there (even if as '(no branch)'). You can even commit, but unless you assign that branch a permanent name via 'git branch' it'll disappear when you move away from it in history: only 'git log -g' can recover it, and in the end it would expire from there, get garbage collected, and be gone. -- NULL && (void)

On 2 May 2012, Timothy Pearson uttered the following: I thought you did, hence my confusion :) Branches aren't tagged in git, so the concept of 'tagged branch' is meaningless. I can't figure out what it might mean, even, which probably means I have been fully assimilated into the git monster and will never be seen again a sane man. (Maybe it's a mercurial concept from its weird world of branches whose names are hardwired into commits and stuff like that. I've never wrapped my head properly around mercurial.) ... but something like git branch patched-branch git checkout patched-branch [apply and commit the patches however you wish] should be all you need. Changes to one branch cannot mess up another in git -- since changing old commits without changing their SHA1 hashes is impossible, you need have no fear that e.g. tree rewrites or rebases on one branch will foul up the other: all they'll do is lead to the branches having a merge base further back than they did before (or, in the case of whole-history tree rewrites, not having any commits in common at all anymore). I guess it all depends what you mean by 'completely independent' though. -- NULL && (void)

On 2 May 2012, Slávek Banko told this: All branches in git have this property: in fact every single commit has this property, since all a branch is is a name (git parlance: a reference, or 'ref') pointing to a commit which can move forward to point at it's child if you hang a new commit off it. (CVS's branches are, well, I'm not sure there *is* a conceptual model for them other than 'we tried to make per-file RCS branching into something per-repository and it nearly worked', which isn't much of a model.) Even better for patch tracking is 'git rebase', because it solves a perennial problem trying to use branches to track changes that apply to one release when the next one comes out. Say you have a tree with a release, and you have a branch with patches based on that that you applied: - A - release 1.0 - B - C - D (trunk) \ -- patch -- patch -- patch (patch-branch) Now a release 2.0 comes out... but you don't want to throw all those patches away, or run around reapplying them and damaging the history. So your tree currently looks like this: - A - release 1.0 - B - C - D - release 2.0 (trunk) \ -- patch -- patch -- patch (patch-branch) In this situation, git rebase trunk patch-branch will rewrite the patch-branch so it depends on the head of 'trunk' (if you want to rebase on some earlier commit in 'trunk', you can make a temporary branch at the appropriate point in 'trunk' and rebase off that). This converts the history to look like this: - A - release 1.0 - B - C - D - release 2.0 (trunk) \ -- patch -- patch -- patch (patch-branch) If git finds conflicts while doing this -- patches that applied to release 1.0 that no longer applied to release 2.0 for some reason other than their being applied to upstream -- it'll stop you halfway, with all patches up to the conflicting patch applied and the conflicting one in a merge-conflict state, and let you fix the problem, resolve the merge conflict as usual (hack the files shown as conflicting by 'git status', 'git add' and 'git commit'), then 'git rebase --continue' or 'git rebase --abort' if you want to give up). But note that while this is often thought of as changing the history of the patch-branch, it really isn't. Commits in git are pretty much immutable[1], so what it actually does is creates a *new* patch-branch with rewritten commits on it derived from the commits on the old branch, and gives it the same name as the old branch had. The old branch no longer has a name, but is still visible in e.g. 'git log -g' until garbage-collected in a few weeks time. (The existence of commands like this that can generate whole branches'-worth of garbage at once is one reason why garbage collection is so important in git's design, though it happens so automatically these days that you can mostly ignore it.) Big caveat here, though: if anyone else was doing work on the tip of the patch-branch and you push your rewritten branch, all their work is gone unless they take special and annoying measures to preserve it -- and indeed git warns you of this by forcing you to push with 'git push -f' to emphasise to you that you might be about to spoil someone's day. So in general either one never rebases public branches, or one advertises that 'this branch is regularly rebased' and people take care not to base work on it directly. (Git's own 'pu' branch, and the linux-next tree, are examples of the latter). One thing you *can* do if you want to rebase a branch full of changes against release 1.0 to changes against release 2.0 without messing up other people is git branch patch-branch-2 patch-branch git rebase trunk patch-branch-2 and now the branch that got rebased (the patch branch for release 2.0) has a new name, and the old branch still exists, the same as ever; so the newly-named patch-branch-2 can be pushed without any worry about messing people up who happen to be playing with the patches against release 1.0 on the original patch-branch. I also commend to you 'git rebase -i', which is a simply stunning way of reshuffling, merging, fixing up and magically manipulating commits before pushing them. Again, to play with this stuff on a branch, make a new branch out of it and play on that: the old branch will be quite safe from your history-defiling experiments. Most of this stuff is thoroughly git-specific magic. I know of no other version control system that has anything really like 'git rebase': Mercurial is trying but has a long way to go to catch up. (I'd say that Mercurial's advantage these days lies in a much nicer little language for selecting changes to do things to, beside which git's looks rather like white noise.) [1] 'pretty much' because if someone breaks SHA-1's security badly enough, they'll not be immutable anymore -- NULL && (void)

On Thursday 03 of May 2012 23:51:44 Francois Andriot wrote: At the beginning I was not planning to incorporate TQT repairs. But then just when such repairs have helped solve various tricky bugs, so I decided to incorporate them. The reactions of users of my PPA can assume that the boundaries that I set not cause regressions. As I mentioned in earlier mails, I have limited the inclusion of the following patches: -- Remove additional unneeded tq method conversions -- Rename obsolete tq methods to standard names -- Rename a few stragglers -- Fix inadvertent "TQ" changes If we agree on that, I would incorporate referred patches into all the other packages that are not yet included in the update. However it would require more time, so I prefer leaving it up to potential further update. I understand. For debian and ubuntu's patches are not yet substantial. The fact that I have some integrated and some are not, has a simple explanation - some patches were in GIT after I released the update. :) Yes, I thought about them several times. When we think about it both equally, so it probably will be a good idea :) We will wait for GIT branch or incorporate it again each in yourself? Slavek --

On Saturday 05 of May 2012 18:51:51 Francois Andriot wrote: Ha, interesting. When applying patches on Debian probably allowed more fuzzy because it applied without a hitch. But I will fix the patch to go without applying the part 5dcbbbba... corrected patch attached :) Slavek --

On Saturday 05 of May 2012 19:40:47 Francois Andriot wrote: Patch bp003 for kdiff3 depends on the patch bp036 for kdebase. It should compile kdiff3 after compiling updated kdebase. Slavek --

Hey just a word ; I don't think it's too smart to have distribution specific coding in the start file. I think that would be better to keep patched in. For example this leads to legacy code when a distribution is no longer included, then you end up with lots of extraneous checks that aren't really doing anything. That is my opinion. This is just a general principle, if something is actually broken (eg there is a incorrect path) it is often because things have been hardcoded a long time ago for a single distribution or method that has changed or outdated. I think it's best to keep distribution specific patches in our git repository tde-packaging, that was it _is_ available for anyone else to see and use, and pull in to their sources, but it's not muddying up the main tree. Calvin

This is a good solution Calvin

Dne čt 3. května 2012 Francois Andriot napsal(a): François, you have in the drawer next handy updates appropriate for 3.5.13? :) It's just if I have to wait to publish the next prepared update... I got to expose my current set of patches? (yet unpublished packages) Very good work. Slávek --

Dne čt 10. května 2012 François Andriot napsal(a): Thank you. All I had already incorporated. Furthermore: c4050cef 2cc2e3a2 15b9ce53 and fb4308f0 e8e118e2 I'll start uploading the next update. In doing so, I also publish the current set of patches. Slavek --