On 07/28/2012 01:05 PM, Darrell Anderson wrote: Thank you Darrell! I knew we nicked our own Achilles tendon when we went on the massive k->t rename. For graphics, etc. that are user seen it was a needed part of the normal progression of the desktop, but for unseen checks and items that do not conflict with kde4, we really need to think ahead and make sure we are not shooting ourselves in the foot. From a build system standpoint, accept for upstream changes, we should be able to build TDE 3.5.12, 3.5.13 and R14 without our naming system interjecting incompatibilities into the build. I'll play with this and see if I can't come up with and conditional or pre-processor type check on the version number to use the right kde-config or tde-config, because it just seems like something like that should be simple. I'll have to look, because I can't explain why 70% of the sru branch built and 30% failed based on this tde-config/kde-config issue. But I'm completely encouraged by how well 3.5.13 built. -- David C. Rankin, J.D.,P.E.

On 07/28/2012 07:31 PM, Slávek Banko wrote: No problem, It is working really good. It's just filling in the holes with the correct files :) Let me know if I can do anything to help you. -- David C. Rankin, J.D.,P.E.

On 29 Jul 2012, David C. Rankin outgrape: Do you have a dirty working tree with stuff in the admin and cmake directories? git will refuse to remove them in that case, to avoid losing your work (though the pointless warning looks like a git bug). Uh, not only did it work, it told you it worked. You can check out *any* commit at all as a new branch, including commits referenced by refs such as branches or tags. But if you check out a tag without creating a new branch off of it, git will warn you, as above, that if you commit at this point and then switch away, your commit is pointed to by nothing and thus will eventually be lost (not at once -- the reflog will point to it for a while, but reflogs are routinely expired by automated 'git gc' runs, so your commit will eventually vanish). (This state is called 'detached HEAD', because HEAD (which always points to your current checkout) is not pointing to the same place as the head of any branch, thus 'detached' from all branches.) -- NULL && (void)

On 30 Jul 2012, David C. Rankin outgrape: Normally one creates the new branch straight from the remote-tracking branch, like so: git branch v3.5.13-sru whatever-remote-name/v3.5.13-sru though if your branch has the same name on the local and remote ends, there is a shortcut: git checkout --track v3.5.13-sru (where '--track' means 'this branch remains associated with the remote-tracking branch, and pushes and pulls go to it or come from it by default). Personally, I never use this shortcut: branching and checking out are completely different operations, and it is not helpful to confuse the two. Also, 'git checkout --track BLAH' isn't actually much shorter than 'git branch BLAH remote/BLAH', and 'git branch' has the right defaults (i.e. making a tracking branch is automatic and you have to ask for the opposite). Also, the 'git checkout' shorthand tends to cause the misconception I see above in new users, that branches are some sort of concrete thing into which you check out code. It is not so. All a branch is is a name: a pointer to a commit which is moved onto any new commit you make on top of that one: the growing tip of some line of development. The name of the branch is completely evanescent: nobody else ever sees it (except perhaps in default commit messages when merging): in particular it doesn't get wired into commits like in Mercurial, or into the filesystem like in Subverison. This is actually very powerful, because it means branches are really free (not just 'free' in the Subversion sense of 'they don't cost much to create'). Want to create five hundred branches under script control and mess about with each one? Easy! Want to preserve your current state because you're about to do some history-rewriting or something and are scared of messing up? 'git branch a-backup-branch' and now nothing can disturb that backup (since git commits are tied to the *contents* of all their parents, history rewriting must necessarily create *new* commits, while a-backup-branch points to the old one, unaffected). Many of us old git hands do *all* our significant development on temporary branches ('feature branches' because they often track the addition of some feature), doing a 'git rebase' on those branches whenever we want to catch up with work on our development trunk (also a local branch, but one untouched except for jobs so small they can be done in one commit), then merging at the end (and because it's rebased, that merge is seamless and undetectable to outsiders). e.g. we do this master -> A -> B -> C \ temp-branch - my work -> more work Now some complete bastard comes along and does *other* work, imagine it. We pull into our trunk with a simple 'git pull', leaving us with this: master -> A -> B -> C -> D -> E \ temp-branch - my work -> more work Now, on the temp branch, when we decide we want to catch up with what other people have done (and make any necessary changes to our code), a simple 'git rebase master' gives us: master -> A -> B -> C -> D -> E \ temp-branch - my work -> more work (If there are any conflicts with the new work D and E, git stops in the middle of the rebase and lets us fix it. If we're scared that there will be a lot of conflicts and things might get too hairy to untangle, we can just use 'git branch temp-branch-backup' to make a backup branch of temp-branch before we rebase it, or make a backup branch and rebase *that* -- there is no difference between the two.) Now, when it comes time to merge, the 'merge' is utterly trivial. There's no change in the commit graph at all, just in a couple of labels: master -> A -> B -> C -> D -> E -> my work -> more work This is an *incredibly* powerful workflow, enormously better than the conventional workflow in other version control systems of working in master and coping with conflicts, or working on a branch and periodically merging from the master branch and *hoping* that things work out. -- NULL && (void)