Re: git and bzr

[Joseph Wakeling <joseph.wakeling@webdrake.net>]

Thanks to everyone for your very detailed responses. :-)

On the subject of blame and pulling patches from unrelated branches,

Jakub Narebski wrote:
> In git repository can have unrelated branches. So you can fetch unrelated
> repository into your repository, and merge/cherry-pick from there
> if needed.

Sean wrote:
> The Git cherry-pick command lets you grab specific commits from
> other branches in your repo.  But cherry-pick works at the commit
> level, there is no easy way to grab a single function for instance
> and merge just its history into another branch.

Linus Torvalds wrote:
> 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.

So ... if I understand correctly, I can get patches from somewhere else,
but in the branch history, I will not be able to tell the difference
from having simply newly created them?

With regards to git blame/pickaxe/annotate, the idea of tracking *code*
rather than files was one thing that really excited me when I read about
it in the earlier discussion, and is probably the main reason I'm trying
out git.  I'd like to understand this properly so is there a simple
exercise I can do to demonstrate its capabilities?  I tried an
experiment where I created one file with two lines, then cut one of the
lines, pasted it into a new file, and committed both changes at the same
time.  But git blame -C on the second file just gives me the
time/date/sha1 of its creation, and no indication that the line was
taken from elsewhere.

Back to the more basic queries ... one more difference I've observed
from bzr, after playing around for a while, involves the commands to
undo changes and commits.  It looks like git reset combines the
capabilities of both bzr uncommit and bzr revert: I can undo changes
since the last commit by resetting to HEAD, and I can undo commits by
resetting to HEAD^ or earlier.

Some things here I'm not quite sure about:
(1) the difference between git reset --soft and git reset --mixed,
probably because I don't understand the way the index works, the
difference between changed, updated and committed.
(2) How to remove changes made to an individual file since the last commit.

Last, could someone explain the git merge command?  git pull seems to do
many things which I would need to use bzr merge for---I can "pull"
between branches which have diverged, for example.  I don't understand
quite what git merge does that's different, and when to use one or the
other.

Many thanks again to everyone,