Comments for Mark McLoughlin http://blogs.gnome.org/markmc Just another GNOME Blogs weblog Sun, 12 Oct 2008 11:54:00 +0000 http://wordpress.org/?v=2.6.2 Comment on Git Workflow by Emanuele aina http://blogs.gnome.org/markmc/2008/05/07/git-workflow/#comment-52 Emanuele aina Wed, 14 May 2008 20:47:10 +0000 http://blogs.gnome.org/markmc/2008/05/07/git-workflow/#comment-52 In the monotone/hg/git history model, rebasing is a intrinsically a "break the world event", as it rewrites the history while it should be immutable. Adding metadata will probably make the whole model a bit messy and a lot less reliable. Only darcs got this right. The problem with darcs was that it got everything else wrong... :( In the monotone/hg/git history model, rebasing is a intrinsically a “break the world event”, as it rewrites the history while it should be immutable.

Adding metadata will probably make the whole model a bit messy and a lot less reliable.

Only darcs got this right. The problem with darcs was that it got everything else wrong… :(

]]> Comment on Git Workflow by markmc http://blogs.gnome.org/markmc/2008/05/07/git-workflow/#comment-51 markmc Wed, 07 May 2008 14:49:04 +0000 http://blogs.gnome.org/markmc/2008/05/07/git-workflow/#comment-51 Clearly, the true answer to “xyz aspect of git kind of blows” is "you're clearly just too stupid to understand how awesome git is" :-) I was mostly replying to the "ChangeLog workflow is wrong" bit - i.e. the git log should should suffice as a ChangeLog and you can clean up your commits to give a nice log before pushing to the upstream repo. Don't get me wrong, though - figuring out how to make git slightly less insanely difficult to learn is worth doing, but encouraging a slightly different workflow should be a part of that, IMHO Some quick comments on the other sections: - "no way I'm keeping all my stuff locally" - sounds to me like you want to keep your own personal backup repo on a server and push regularily to that, not necessarily push all your work-in-progress stuff upstream. Looking at the "git-push" manpage and the "git-remote" manpage, I bet you could set things up so you could just do "git-push backup" - e.g. [remote "backup"] url = ssh://hp@gnome.org/git/foo refspec = * It'd be cool if this was easier, but the difference with git is that you probably don't want to push everything upstream this way, you just want to backup to another git repo somewhere. - "Deleting a remote branch" ... "surprising syntax" - notting recently found that syntax by accident, and we had a fun half hour restoring his branch again :-) - "--force" and "screwing things up" - I think git-push --force is mainly there so that you can push a "rebased" tree ... i.e. because you've rewritten history, the head you're pushing isn't an ancestor of the remote head, so it's not a fast-forward push. The kernel guys are constantly getting into a flap about people using rebase too much, e.g. on public trees that a bunch of other people have based their work on. I reckon they'll figure out one of these days how to make it so that some metadata is retained during rebasing so that rebasing isn't such a "break the world event" ... and then --force wouldn't be needed to push a rebased tree. Clearly, the true answer to “xyz aspect of git kind of blows” is “you’re clearly just too stupid to understand how awesome git is” :-)

I was mostly replying to the “ChangeLog workflow is wrong” bit - i.e. the git log should should suffice as a ChangeLog and you can clean up your commits to give a nice log before pushing to the upstream repo.

Don’t get me wrong, though - figuring out how to make git slightly less insanely difficult to learn is worth doing, but encouraging a slightly different workflow should be a part of that, IMHO

Some quick comments on the other sections:

- “no way I’m keeping all my stuff locally” - sounds to me like you want to keep
your own personal backup repo on a server and push regularily to that, not
necessarily push all your work-in-progress stuff upstream. Looking at the
“git-push” manpage and the “git-remote” manpage, I bet you could set things
up so you could just do “git-push backup” - e.g.

[remote "backup"]
url = ssh://hp@gnome.org/git/foo
refspec = *

It’d be cool if this was easier, but the difference with git is that you probably
don’t want to push everything upstream this way, you just want to backup to
another git repo somewhere.

- “Deleting a remote branch” … “surprising syntax” - notting recently found
that syntax by accident, and we had a fun half hour restoring his branch
again :-)

- “–force” and “screwing things up” - I think git-push –force is mainly there
so that you can push a “rebased” tree … i.e. because you’ve rewritten history,
the head you’re pushing isn’t an ancestor of the remote head, so it’s not a
fast-forward push.

The kernel guys are constantly getting into a flap about people using rebase
too much, e.g. on public trees that a bunch of other people have based their
work on. I reckon they’ll figure out one of these days how to make it so that
some metadata is retained during rebasing so that rebasing isn’t such a
“break the world event” … and then –force wouldn’t be needed to push a
rebased tree.

]]> Comment on Git Workflow by Havoc http://blogs.gnome.org/markmc/2008/05/07/git-workflow/#comment-50 Havoc Wed, 07 May 2008 13:31:25 +0000 http://blogs.gnome.org/markmc/2008/05/07/git-workflow/#comment-50 Maybe not parsing what you're saying, but I don't see how ability to do cool patch massage makes any of the problems in my post go away... shouldn't these cool features be *in addition* to also working well in the ways I describe in my post? What's wrong with expecting git to also be good at the stuff I'm talking about there? I have never understood how "oh, but it does this other cool thing" is an answer to "xyz aspect of git kind of blows" ;-) I do definitely enjoy the ability to do the after-the-fact commit rearrangement. Maybe not parsing what you’re saying, but I don’t see how ability to do cool patch massage makes any of the problems in my post go away… shouldn’t these cool features be *in addition* to also working well in the ways I describe in my post? What’s wrong with expecting git to also be good at the stuff I’m talking about there?

I have never understood how “oh, but it does this other cool thing” is an answer to “xyz aspect of git kind of blows” ;-)

I do definitely enjoy the ability to do the after-the-fact commit rearrangement.

]]> Comment on Dublin Marathon by Rory http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-47 Rory Sun, 11 Nov 2007 02:40:05 +0000 http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-47 Hope you enjoyed the first marathon. First means there will be more. I've run marathons for over 20 years and now ultras. All this is much better than sitting on the couch watching TV. Rory aka "the Running_man" Meehan Hope you enjoyed the first marathon. First means there will be more. I’ve run marathons for over 20 years and now ultras. All this is much better than sitting on the couch watching TV.
Rory aka “the Running_man” Meehan

]]> Comment on Dublin Marathon by David Bonney http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-46 David Bonney Mon, 05 Nov 2007 09:21:49 +0000 http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-46 Mark is your action photo on mybestmarathon.com Mark is your action photo on mybestmarathon.com

]]> Comment on Dublin Marathon by knipknap http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-45 knipknap Tue, 30 Oct 2007 21:54:09 +0000 http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-45 Congratulations! I also ran my first (ultra)marathon three days ago. If you are anything like me, your ability to walk be be severely restricted in the next couple of days :-). Congratulations! I also ran my first (ultra)marathon three days ago. If you are anything like me, your ability to walk be be severely restricted in the next couple of days :-).

]]> Comment on Dublin Marathon by Calum http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-44 Calum Tue, 30 Oct 2007 18:56:15 +0000 http://blogs.gnome.org/markmc/2007/10/30/dublin-marathon/#comment-44 Well done. My father-in-law was running it as well... we just stood and watched though :) Well done. My father-in-law was running it as well… we just stood and watched though :)

]]> Comment on GNOME SVN and jhbuild by andre http://blogs.gnome.org/markmc/2007/01/02/gnome-svn-and-jhbuild/#comment-43 andre Tue, 30 Nov 1999 00:00:00 +0000 http://blogs.gnome.org/markmc/2007/01/02/gnome-svn-and-jhbuild/#comment-43 thanks a lot, saves me some time :-) thanks a lot, saves me some time :-)

]]> Comment on GNOME SVN and jhbuild by Marko Anastasov http://blogs.gnome.org/markmc/2007/01/02/gnome-svn-and-jhbuild/#comment-42 Marko Anastasov Tue, 30 Nov 1999 00:00:00 +0000 http://blogs.gnome.org/markmc/2007/01/02/gnome-svn-and-jhbuild/#comment-42 Thanks, that's useful information :) . Thanks, that’s useful information :) .

]]> Comment on Xen and X Pointer Issues by Pete Zaitcev http://blogs.gnome.org/markmc/2006/09/29/xen-and-x-pointer-issues/#comment-41 Pete Zaitcev Tue, 30 Nov 1999 00:00:00 +0000 http://blogs.gnome.org/markmc/2006/09/29/xen-and-x-pointer-issues/#comment-41 Yeah, ``xset m 1/1'' worked like a charm for me. However, there's a question of the initial position, so you have to press the pointer against the VNC window borders a few times before host and guest cursors align. Also, Dan Berrange reported that xset didn't work for him, he still gets a scaled motion for some reason. No, I do not think that he ran xset on the host instead of guest, so it's very mysterious.<br/> Yeah, “xset m 1/1” worked like a charm for me. However, there’s a question of the initial position, so you have to press the pointer against the VNC window borders a few times before host and guest cursors align. Also, Dan Berrange reported that xset didn’t work for him, he still gets a scaled motion for some reason. No, I do not think that he ran xset on the host instead of guest, so it’s very mysterious.

]]>