On Tue, 28 Nov 2006, Joseph Wakeling wrote:
quoted text
>
> 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@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:

	[user]
		name = My Name Goes Here
		email = myemail@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@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 
different repositories).

quoted text
> 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. 

quoted text
> 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).

quoted text
> 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 
hardcoded.

quoted text
> 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 [1.4.4.1] 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.

However...

quoted text
> 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.

quoted text
> 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.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html