Linus Torvalds wrote:

>Ok, this is nicer than gitk, with the parents showing up in the commit
>message and thus easy to go to. You might add children too: it's not
>something git itself knows about intrisically, but since you've already 
>built the graph, at least you see what children are part of that graph..

I don't know if this is what you mean, but if you right click on a free 
lane (i.e. not a bullet but a vertical line) on the graph you should see a
pop-up with selectable childs and parent.

> - Any chance of having a git archive of qgit? I realize that sourceforge 
>   doesn't have git archives, but (a) maybe you can ask and (b) maybe 
>   there are alternate places you could put it. It's just sad having to 
>   download tar-balls.

I will try to proceed from (a) to, eventually, (b).

> - The qgit graph is not as pretty as the gitk one. Any chance of making 
>   the bullets a bit smaller, and having an option to not do the
>   "jump-over-bumps"?

Ok, I will try to use straight horizontal lines instead of jump-over-bumps. If
this seems not enough clear I will add an option to switch visualization.

> - the "file annotation" window is nice, but it _really_ shouldn't do line
>   wrapping. If you make the window narrower, you'll see it wrap and look 
>   horrible.. Are all text windows always wrapped in QT?

No, just a setting. Not a problem to set "No wrap" behaviour. I will set this
also in diff viewer window.

> - You edit the commit comments heavily, and have no options to unedit. 
>   For example, I need the emails in the sign-offs if I ever cut-and-paste 
>   to an email client when I sent a "hey, this commit broke so-and-so.."

You discover a real bug ;-). I never intended to modify commit comments in any 

> - the "format a patch to be sent as email" thing says "at least two 
>   revisions needed" when you only have one. Why? One of my more common 
>   cases is that I send one commit as a patch, and now I do
>       git-diff-tree -p --pretty [commit-id] > ~/diff
>   and then just send that. A single commit _does_ describe a valid patch, 
>   after all.

The logic here is to specify a range. As example if you have following commits


and you select B and E then 3 patches will be created: 
     patch_1(diff between D-E)
     patch_2(diff between C-D)
     patch_3(diff between B-C) 

So you need at least 2 selected revs. Put in other words, the base is always 


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to