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@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@xxxxxxxx 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@xxxxxxxxxxxx (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). > 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 hardcoded. > 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... > 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. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html