[21:23] <tjaalton> bryce: the latest change in xorg-server touched mi/mipointer.c directly?
[21:23] <tjaalton> also, there probably are more changes uploaded in the queue, but not pushed to git?
[21:26] <bryce> tjaalton: not on my end; everything's pushed that I added
[21:26] <bryce> (afaik - caveat that I'm still a klutz at git)
[21:30] <bryce> hmm, I did the mi/mipointer.c change as a patch, not directly to the code.  Are you seeing differently?
[21:30] <tjaalton> no, looking at gitweb
[21:30] <tjaalton> and that's the only commit pushed
[21:30] <tjaalton> (since the patch by kees)
[21:31] <tjaalton> hum, I mean "yes, seeing differently"
[21:32] <bryce> hmm, everything is committed to my git tree, and git push origin ubuntu says it's all up there
[21:32] <bryce> bryce@chideok:~/src/xorg-server/xorg-server-ubuntu-git$ git diff
[21:32] <bryce> bryce@chideok:~/src/xorg-server/xorg-server-ubuntu-git$ git status
[21:32] <bryce> # Not currently on any branch.
[21:32] <bryce> nothing to commit (working directory clean)
[21:32] <bryce> bryce@chideok:~/src/xorg-server/xorg-server-ubuntu-git$ git commit -a
[21:32] <bryce> # Not currently on any branch.
[21:32] <bryce> nothing to commit (working directory clean)
[21:32] <bryce> bryce@chideok:~/src/xorg-server/xorg-server-ubuntu-git$ git push origin ubuntu
[21:32] <bryce> Everything up-to-date
[21:32] <bryce> is git tricking me?
[21:33] <tjaalton> you are not on a branch
[21:33] <tjaalton> always checkout your local branch first, then work on it and push
[21:33] <tjaalton> git checkout -b ubuntu origin/ubuntu
[21:33] <bryce> bryce@chideok:~/src/xorg-server/xorg-server-ubuntu-git$ git checkout -b ubuntu origin/ubuntu
[21:33] <bryce> fatal: git checkout: branch ubuntu already exists
[21:34] <tjaalton> so 'git checkout ubuntu'
[21:34] <bryce> hrm, that's my working branch that I developed the patch on
[21:35] <bryce> that's not what I wanted to commit
[21:35] <tjaalton> heh
[21:35] <bryce> so you're telling me all the work I did in git since then is lost
[21:35] <tjaalton> git checkout -b workingbranch origin/upstream-experimental ?-)
[21:35] <bryce> bleah, why are we using git again?
[21:35] <bryce> hrm
[21:36] <tjaalton> maybe you have a branch where they are
[21:36] <bryce> nope
[21:36] <tjaalton> no way to pull stuff from git -> bzr
[21:36] <tjaalton> and upstream is using git, debian too
[21:36] <hyperair> yes there is
[21:36] <hyperair> bzr-fast-export
[21:37] <hyperair> it's a script someone gave me
[21:37] <hyperair> bzr-fast-export /path/to/bzr | git-fast-import
[21:37] <bryce> well I don't pull stuff from git anyway; I use git show <blah> > blah.patch and then include that
[21:37] <tjaalton> well, I'm pretty sure it only messes things up
[21:37] <hyperair> oh wait. git -> bzr
[21:37] <hyperair> bzr-fast-export only does bzr -> git 
[21:37] <hyperair> =p
[21:38] <tjaalton> I'm not sure why it allows to commit if you're not on a branch though
[21:39] <tjaalton> and just working with a source package means no collaboration, within ubuntu or with debian
[21:39] <bryce> here I was thinking, "Gee I'm actually seeing some usefulness from git for once, being able to do my work in git while we're in freeze, without uploading until the changes have been reviewed/tested"
[21:40] <tjaalton> well, I don't know how you ended up in origin/ubuntu :)
[21:40] <hyperair> lol
[21:40] <bryce> tjaalton: well that may be true, but from my perspective it doubles the amount of time it takes to do simple stuff, and triples the number of command sequences I have to memorize ;-)
[21:40] <hyperair> probably git checkout origin/ubuntu
[21:41] <hyperair> bryce: in the hands of an experienced git user, it works blazingly fast compared to other SCMs
[21:41] <hyperair> and skipping the tutorial doesn't work, as i've learnt the hard way
[21:41] <RAOF> hyperair: Apparently the launchpad team is turning on the bzr-git support, so there'll soon be bzr mirrors of git trees.
[21:42] <tjaalton> don't know how the different style commit-id's are going to work
[21:43] <hyperair> RAOF: cool. but one bzr branch per git branch? 
[21:43] <RAOF> hyperair: No idea.
[21:43] <hyperair> tjaalton: copy paste lol
[21:43] <tjaalton> bryce: well, it's only ~6 you need (add, commit, push, checkout, diff, show)
[21:43] <hyperair> tjaalton: oh regarding bzr-git eh..
[21:43] <hyperair> bzr will probably renumber
[21:43] <hyperair> like how it does svn
[21:43] <RAOF> pull, reset, ... ;)
[21:43] <tjaalton> reset, yes
[21:44] <tjaalton> and pull of course hehe
[21:44] <bryce> tjaalton: and branch, log, pull, reset
[21:44] <tjaalton> so 10
[21:44] <bryce> but the hard part is remembering all the bits after the command
[21:44] <tjaalton> still, it's the same with every VCS
[21:44] <bryce> like origin ubuntu sometimes vs origin/ubuntu other times
[21:44]  * RAOF finds the hard part is remembering that sometimes reset is revert, and sometimes checkout is revert.
[21:44] <tjaalton> just push origin, if you haven't touched debian-*
[21:44] <hyperair> bryce: origin/ubuntu = branch. origin = remote nickname, ubuntu = remote branch
[21:45] <bryce> and all the options like -a for commit, -f for add if it's a patch, etc.
[21:45] <hyperair> RAOF: no, reset and checkout do different things
[21:45] <RAOF> hyperair: Except that they don't.
[21:45] <hyperair> bryce: -a if you don't want to stage. -f i have never used
[21:45] <hyperair> RAOF: yes they do
[21:45] <RAOF> hyperair: reset is "revert the whole tree", checkout is "revert this file".
[21:45] <hyperair> RAOF: not necessarily
[21:45] <hyperair> RAOF: checkout is reset --hard
[21:45] <hyperair> =p
[21:45] <bryce> hyperair: you don't need to explain what they mean, obviously I know else I wouldn't be rattling them all off!  ;-)
[21:45] <hyperair> but for just this file
[21:46] <hyperair> but reset can be used on individual files, you just don't get the effect of --hard
[21:46] <hyperair> bryce: right.
[21:46] <RAOF> Which brings us to the index... ;)
[21:46] <bryce> hyperair: although the fact that you see the need to explain them sort of proves my point ;-) ;-)
[21:46] <tjaalton> reset is very useful, I use it all the time when I mess things up..
[21:46] <hyperair> yeah the staging thing is what sets git apart from others in terms of workflow =\
[21:46] <hyperair> tjaalton: same here
[21:46] <RAOF> Right.  It'd be even better if there was an actual 'revert', which did what you wanted.
[21:47] <RAOF> "make $file (or working tree if no file is specified) the same as the last commit".
[21:47] <tjaalton> git revert?
[21:47] <bryce> anyway --> lunch.  bbiab
[21:48] <RAOF> tjaalton: No, that reverts a commit :)
[21:48] <tjaalton> oh right, didn't read enough :)
[21:48] <tormod> git reset --hard "reverts"
[21:48] <tjaalton> yep
[21:48] <RAOF> Only the whole tree.
[21:48] <RAOF> If you want to revert a file, it's "git checkout refspec filename", IIRC.
[21:49] <RAOF> Where refspec is HEAD.
[21:49] <RAOF> Possibly there needs to be some -- in there, too :)
[21:49] <hyperair> RAOF: git co HEAD -- file
[21:50] <RAOF> hyperair: OK.  You do need the -- in there.
[21:50] <hyperair> heheh
[21:50] <hyperair> checkout is one hell of a command
[21:50] <hyperair> it changes branches, creates branches, and reverts stuff
[21:50] <hyperair> oh don't forget git stash
[21:50] <RAOF> Yup.  It should be 3 commands, obviously :)
[21:51] <hyperair> heh yeah
[21:51] <hyperair> so do you feel like making an alternative git?
[21:51] <RAOF> No.  The bzr team already has.
[21:51] <hyperair> one that responds to different commands, and does what you think it should? ;)
[21:51] <hyperair> when bzr achieves multiple branches in one directory, i'll agree with you =\
[21:51] <tjaalton> it doesn't?
[21:52] <hyperair> no it doesn't
[21:52] <tjaalton> huh
[21:52] <hyperair> each branch is a directory of its own
[21:52] <hyperair> bzr branch dir1 dir2
[21:52] <hyperair> and there you go, you get two branches
[21:52] <RAOF> I actually like that, but I can see why others don't.
[21:52] <hyperair> dir2 is the branch of dir1
[21:52] <hyperair> i liked it too, at first
[21:52] <RAOF> It makes it more obvious how to actually get a branch :)
[21:52] <hyperair> in fact, i was apalled when i found out git had all branches in one directory
[21:53] <hyperair> but then, eventually
[21:53] <hyperair> i had so damn many branches, i needed to store them all in one directory
[21:53] <tjaalton> I never used any other VCS before git.. so maybe it was easier to grok because of that
[21:53] <RAOF> "bzr cbranch" can get you approximately that behaviour, but it's not quite the same.e
[21:54] <hyperair> and because i had so many duplicate copies of the same thing, i ran out of disk space.
[21:54] <RAOF> Again, cbranch.
[21:54] <RAOF> But yeah.  Sometimes it's useful to have all the branches hidden in a single directory.
[21:57] <hyperair> not just that
[21:57] <hyperair> branches mostly have a lot of similar data
[21:57] <hyperair> well i suppose a bzr init-repo and dumping all the branches there would work
[21:58] <hyperair> but actually after bzr kept spewing out exceptions about godknowswhatRoot not being compatible with godknowswhat rich root pack godknows what else, i gave up
[21:58] <hyperair> and git has _never_ spit out an exception with as cryptic a message as that
[21:58] <hyperair> oh yeah, i also lost the capability to merge my branches
[21:58] <hyperair> for some reason or other
[21:59] <RAOF> Heh.  Cryptic in the eye of the beholder, obviously.
[22:04] <hyperair> but of course
[22:05] <hyperair> but hey, git has never complained about a repository or branch not being compatible with another
[22:05] <RAOF> Right.  bzr repository formats need to stop shifting.
[22:05] <hyperair> i mean hey if you want to have so many different types of repositories/branches, at least make them compatible
[22:05] <hyperair> the user shouldn't need to see these kind of cryptic messages
[22:06] <hyperair> they're not even google-able for the love of god
[22:06] <RAOF> They are, mostly.  But rich-root has to be incompatible with non-rich-root, because non-rich-root stores less information.
[22:06] <hyperair> then _warn_ me, and ask whether to proceed or not!
[22:07] <hyperair> i'd like to be notified that there will be loss of data, _what_ data, then maybe i can decide whether i still need this data or not
[22:07] <hyperair> i don't even know what's lost between rich-root and non-rich-root
[23:50] <eric> yo