That's how having dozens of tabs open at the same time makes me feel. Kinda.
Yah. Sucks to be me.
Wednesday, 31 October 2012
Saturday, 13 October 2012
Git-Svn - a noob's journey, Week 1-2
I've wanted to try out Git for quite a while. Maybe it's just me, the
type of person who wants to know every frigging thing about something
before actually going ahead and doing it, but I've been trying to get
my head around the whole DVCS thing, and still not completely happy
with what I knew. So I kept on reading, mostly blog posts because the
official sources were not that readable, frankly. Problem with blog
posts is that obviously they don't cover everything, and seemed to
raise a lot of corner cases that I didn't feel I understood enough.
That and we used Subversion for our source control at work. So I
didn't see the point. Then I found out about GIt-Svn, which seems to
me the best of both worlds, at least in theory. These are just some
observations and maybe tips for people who want to give git-svn a try.
* OMG. I LOVE the stash functionality. The ability to move your
current working changes into temporary storage, without the
"commitment" of making branches is much welcome.
* git svn rebase means more frequent updates to your working copy,
minimising the chance your changes stray too far from what everyone is
doing.
* I think in the long term, I just need to think about branches in a
new way, since 1. branches can be local, so no one sees the
embarrassing things you're doing; and 2. working in branches means you
can get the latest and greatest code from svn synced to master without
having it cause you any worry about conflicts, etc.
* I had the mistaken idea that if you were using git-svn, that you
couldn't merge from branches. This wasn't the complete picture. Turns
out it's merging between SVN branches in your git repository that you
shouldn't do (see:
http://stackoverflow.com/questions/2693771/git-svn-merge-2-svn-branches)
If you just make a local branch, don't create it remotely in SVN, do
your changes there instead of on "master" (equivalent to svn trunk),
then merge changes back to trunk - that's completely okay.
* Somehow, I lost my changes, even after stashing them. If you make a
stash, don't pop them (ie, apply them and remove from the saved
stashes). I was doing an svn rebase, so stashed the working changes
first. Then the rebase got a conflict, which I then tried to merge. My
merge didn't seem to work, and I saw a post of a similar problem that
said to just do "git rebase --skip". Then my stash wasn't around
anymore! This took me a couple of tries to sort out. Also learned
about "git fsck", which probably would have helped me instead of me
having to manually recreate my changes.
* Don't forget that any commits you make are only local. No one will
see them until you do "git svn dcommit". I knew this would happen to
me eventually. I broke the build doing this, after sending out an
email saying "Yeah, I've fixed the build." then going home. I can also
very easily imagine this happening at a great scale if we ever adopt
it at our workplace.
Please keep in mind that the information here may or may not be
entirely correct. Corrections, comments and advise from more
experienced users are welcome.
TODO: update with list of helpful URLs for git-svn
type of person who wants to know every frigging thing about something
before actually going ahead and doing it, but I've been trying to get
my head around the whole DVCS thing, and still not completely happy
with what I knew. So I kept on reading, mostly blog posts because the
official sources were not that readable, frankly. Problem with blog
posts is that obviously they don't cover everything, and seemed to
raise a lot of corner cases that I didn't feel I understood enough.
That and we used Subversion for our source control at work. So I
didn't see the point. Then I found out about GIt-Svn, which seems to
me the best of both worlds, at least in theory. These are just some
observations and maybe tips for people who want to give git-svn a try.
* OMG. I LOVE the stash functionality. The ability to move your
current working changes into temporary storage, without the
"commitment" of making branches is much welcome.
* git svn rebase means more frequent updates to your working copy,
minimising the chance your changes stray too far from what everyone is
doing.
* I think in the long term, I just need to think about branches in a
new way, since 1. branches can be local, so no one sees the
embarrassing things you're doing; and 2. working in branches means you
can get the latest and greatest code from svn synced to master without
having it cause you any worry about conflicts, etc.
* I had the mistaken idea that if you were using git-svn, that you
couldn't merge from branches. This wasn't the complete picture. Turns
out it's merging between SVN branches in your git repository that you
shouldn't do (see:
http://stackoverflow.com/questions/2693771/git-svn-merge-2-svn-branches)
If you just make a local branch, don't create it remotely in SVN, do
your changes there instead of on "master" (equivalent to svn trunk),
then merge changes back to trunk - that's completely okay.
* Somehow, I lost my changes, even after stashing them. If you make a
stash, don't pop them (ie, apply them and remove from the saved
stashes). I was doing an svn rebase, so stashed the working changes
first. Then the rebase got a conflict, which I then tried to merge. My
merge didn't seem to work, and I saw a post of a similar problem that
said to just do "git rebase --skip". Then my stash wasn't around
anymore! This took me a couple of tries to sort out. Also learned
about "git fsck", which probably would have helped me instead of me
having to manually recreate my changes.
* Don't forget that any commits you make are only local. No one will
see them until you do "git svn dcommit". I knew this would happen to
me eventually. I broke the build doing this, after sending out an
email saying "Yeah, I've fixed the build." then going home. I can also
very easily imagine this happening at a great scale if we ever adopt
it at our workplace.
Please keep in mind that the information here may or may not be
entirely correct. Corrections, comments and advise from more
experienced users are welcome.
TODO: update with list of helpful URLs for git-svn
Friday, 12 October 2012
Say my name, say my name
Oh boy, this post about "Taking on an English name" hits the spot. Having been given a slightly non-standard name by my parents, I've had my name mangled quite a number of ways. But I understand why it gets mangled. It's different, it's unusual! I geddit. And a lot of people are *not* used to reading phonetically, unaware of other names because they don't friggin read enough or know about the world, or just plain can't spell even if the letters are in front of them.
But here's the thing: instead of giving up, and getting a new name, why not try TEACHING people how to say your name? Educate them, and teach them to make new sounds with phonemes. Teach them how to make sounds they never thought could be done with letter combinations!
In the end, for me, it's all about respect. Respecting other people's cultures to learn their name. Pay attention to how they say it, because "correct" is always defined by the owner of the name. (even those normal-but-misspelt names like Jazzmyn)
To some it might be trivial, but to me if you can't be arsed getting someone's name right, what more when it comes to other things that actually require a bit more effort?
Your name matters. The more you teach people, the easier it becomes both for that person and other people who have "strange" names. Do it. Do it for little Zbignew and Raghavendra.
But here's the thing: instead of giving up, and getting a new name, why not try TEACHING people how to say your name? Educate them, and teach them to make new sounds with phonemes. Teach them how to make sounds they never thought could be done with letter combinations!
In the end, for me, it's all about respect. Respecting other people's cultures to learn their name. Pay attention to how they say it, because "correct" is always defined by the owner of the name. (even those normal-but-misspelt names like Jazzmyn)
To some it might be trivial, but to me if you can't be arsed getting someone's name right, what more when it comes to other things that actually require a bit more effort?
Your name matters. The more you teach people, the easier it becomes both for that person and other people who have "strange" names. Do it. Do it for little Zbignew and Raghavendra.
Subscribe to:
Posts (Atom)