git and bzr
torvalds at osdl.org
Tue Nov 28 02:57:03 GMT 2006
On Tue, 28 Nov 2006, Joseph Wakeling wrote:
> First off a really dumb one: how do I identify myself to git, i.e. give
> it a name and email address? Currently it uses my system identity,
> My Name <username at computer.(none)>. I haven't found any equivalent of
> the bzr whoami command.
Depending on whether you like editing config files by hand or not, you
would either just edit your ~/.gitconfig file and add a section like:
name = My Name Goes Here
email = myemail at work.com
or you would use "git repo-config" to do it for you. Personally, I find it
easier to just edit the .gitconfig file directly, since the config file
syntax is actually rather pleasant, but if you want to do it with a git
command, you'd do
git repo-config --global user.name "Joseph Wakeling"
git repo-config --global user.email joseph.wakeling at webdrake.net
(where the "--global" just tells repo-config to use the user-global
~/.gitconfig file - you can also do this on a per-repository basis in the
repository .git/config file if you want to have different identities for
> Now to more serious business. One of the main operational differences I
> see as a new user is that bzr defaults to setting up branches in
> different locations, whereas git by default creates a repository where
> branches are different versions of the directory contents and switching
> branches *changes* the directory contents. bzr branch seems to be
> closer to git-clone than git-branch (N.B. I have never used bzr repos so
> might not be making a fair comparison).
You can do either, it's almost purely a matter of taste.
Using a local branch and switching between them in place has some
advantages once you get used to it: most notably you can trivially use git
commands that work on data from different branches at the same time. So
with that kind of setup it's very natural to do things like "show me
everything that is in branch 'x', but _not_ in branch 'y'", and once you
get used to that, you really appreaciate it.
But at the same time, if you want to actually keep several branches
checked out at the same time, and prefer to work on them that way, just
use "git clone" to create the other branch instead. It really is just a
matter of taste.
I suspect that most people tend to end up using the "multiple branches in
the same directory and switching between them" approach after a time, but
that's really just an unsubstantiated feeling, and it certainly isn't
something that git forces on you.
> With this in mind, is there any significance to the "master" branch (is
> it intended e.g. to indicate a git repository's "stable" version
> according to the owner?), or is this just a convenient default name?
> Could I delete or rename it? Using bzr I would normally give the
> central branch(*) the name of the project.
It's just a convenient default name, and it has no real meaning otherwise.
Feel free to rename it any way you want (just make sure to edit HEAD to
point to the new name is you rename it by hand).
> Any other useful comments that can be made to a bzr user about working
> with this difference, positive or negative aspects of it?
There should be no difference, although since everybody seems to use
"master" by default, the documentation is probably geared towards it, and
who knows, maybe you'll hit a bug that nobody else noticed just because
everybody else had a "master" branch, and some silly script had it
> Next question ... one of the reasons I started seriously thinking about
> git was that in the VCS comparison discussion, it was noted that git is
> a lot more flexible than bzr in terms of how it can track data (e.g. the
> git pickaxe command, although I understand that's not in the released
> version [184.108.40.206] yet?).
pickaxe wasn't in the released version back when the discussions were
raging, but it's there now. Except it's really called "git blame" these
days (and "git annotate") since it's taken over both of those duties.
> A frustration with bzr is that pulling or
> merging patches from another branch or repo requires them to share the
> same HEAD. Is this a requirement in git or can I say, "Hey, I like that
> particular function in project XXX, I'm going to pull that individual
> bit of code and its development history into project YYY"?
... it's not _quite_ that smart. It will only look for sources to new
functions from existing sources in the tree that preceded the commit that
added the function, so it will _not_ see it coming from another branch or
another project entirely.
So when you ask for code annotations (use the "-C" flag to see code moved
across from other files), it will still limit itself to just a particular
input set, and not go gallivating over all possible branches and projects
you might have in your repository.
It wouldn't be theoretically impossible to do, but it would be
prohibitively expensive (where do you draw the line for what to look at).
So git won't do quite what you ask for.
> Last off (for now, I'm sure I'll think of more): is there any easy (or
> difficult) way to effectively import version history from a bzr
> repository, and vice versa?
There's a "archimport", but I assume bzr has long since broken
compatibility with arch (and/or just extended things so much as to not be
importable with that any more), regardless of any origin. But it might be
a good starting point, at least.
More information about the bazaar