Carl Worth wrote: [cut] By the way, you can get new layout with old git using --use-separate-remote option to git clone (which is present I think from around Jun 2006). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Much improved, IMHO. As an added bonus, I think it creates some feedback that lets a user know when they have mistakenly used 'git checkout' to switch heads when they meant to restore a file. I still wish there was some other language for detaching to a commit specified by a remote tracking branch; it just seems wrong to say "you are not on any branch" right after the user requests to checkout a branch (admittedly not one of their local branches, but for a user merely poking through the reposit...

OK, so let's not lie about it, then. But that doesn't mean we can't explain further. What about: $ git checkout origin/pu Detached your HEAD (based on remote origin/pu) -- you are not on any branch ... Except that I think the line is getting a bit long. But the point is to explain _why_ we're detached (you could even put a different note for tags). If a user already knows that 'git checkout v1.4.4.4' is going to put him in a detached state, then he doesn't really care about the message one wa...

You can on host C pull from host S, and on host C push to host S. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

There is new (untested and not complete) command git-remote for that. Although the fact that clone copies all branches and tags (I don't think there is a way to clone only subset of branches), and that fetch is multi branch might be deterrent enough (unless one use one branch per repo). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

You can checkout a tag, not a remote tracking branch! -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Have you read further? git-bisect could (and probably should) use detached HEAD instead of special 'bisect' branch. Doing bisection can be hard work (checking if commit is good or bad might take time) and we don't want to lose it. Besides, history has finite length, and you could get to the state not only via "git checkout", but also via "git reset --hard". Reflog for detached HEAD would help in this. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Not really. I had some thought when I did it, but can't recall what it was. Perhaps I wanted to verify that the data I was reading from git-diff wasn't That patch didn't apply here, not even Lets try the old uuencode format. (this is my patch once again wrapped by uuencode). -- robin

I only had a very quick glance, but one "problem" is that vc-annotate assumes that what you want to do is to run an annotate/blame command and show the output in another buffer. My solution is a minor-mode that shows the blame directly in the edit buffer, and I'm not sure how easy it would be to convince vc that this is what I want. And I need a way to turn it off again, and maybe some local key bindings when it is active. This all points to the fact that a minor mode is really the thing to use....

I think you (and others in the thread) are forgetting that moving to a particular state by resetting can create a state that you may want to keep a pointer to, but you do not have any existing ref. That's one of the reasons why we do not merely check if the detached HEAD is not reachable from any of the existing refs when coming back. Instead, we check and warn if the detached HEAD does not exactly match one of the existing refs. Imagine "git bisect" did not exist, or was not powerful enough, ...

If you mean grep 'git checkout|git reset' perhaps. After checking out a specific commit (because the user was told about the commit out-of-band, say, via e-mail), the user can still I do not think anybody is arguing that particular checkout is dangerous. The warning message is about the fact that your HEAD is now detached, which might not have been what you intended (and you will later get a real warning when you do a really dangerous thing, which is "to come back and lose your point"). - ...

"Do you find this useful" is a loaded question. I do it all the time with git-rebase, so the need to remove a botched commit from the history and rebuild the remainder is certainly there, meaning "what your patch does IS useful". I do it all the time with git-rebase, so I personally do not need a new tool to do this, meaning "your patch is not useful to me". When I find master~8 and master~9 to be undesirable, I would do: $ git rebase --onto master~10 master~8 which rebuilds master~7 a...

That may be well when no patch depends on the one you kill. In that case, it surely requires some work to handfix things. I'd suggest to use stgit to prepare commits before publication. Even if you don't feel the need for it in everyday life, you can have a one-shot use for this particular problem, by turning your latest commits into an stgit stack, use stgit facilities to handle posible conflicts, and turn them into commits again: The nominal case goes: stg init stg uncommit -n <n...

I like this much better. Though I wonder in Carl's case if we can do even better, since the user is checking out a tracking branch. Does it really make sense to say "you are not on ANY branch"? Maybe instead: -- >8 -- git-checkout: note use of remote tracking branch when making detached warning --- Carl, can you comment? Does this require more explanation about why it matters that you're on a remote tracking branch? git-checkout.sh | 10 +++++++++- 1 files changed, 9 insertions(+), 1 ...

Sure, but that is a very subtle distinction that I doubt will make sense to git newbies. Having them check out what they consider to be a branch (and which is, in fact, a line of development -- just not one that you have locally marked as a head) and responding with "you are not on ANY branch" is a little off-putting. Is there some text we can use that makes more sense in all situations? I think part of the "scariness" of the message is that git-checkout does not _usually_ produce output. I won...

Do you use new enough version of git, one which has git-blame --incremental? -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

Probably you forgot to use the latest version :-) See my mail with the subject line "git-blame.el". -- David Kågedal -

Hi, Ah yes, I don't use gitk all that often, and I did not realize that there was a search bar. Still, I think Mike's patch is too verbose, i.e. it is not minimal enough ;-) Ciao, Dscho -

I saved the elisp code in a file .emacs.d/git-blame.el, and loaded it with M-x load-file. Then I visited git/cache.h, and typed M-x git-blame-mode, but the background colours did not change. What did I forget to do? Regards, Peter -

The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many sub...

I will resend tonight when I get access to an account where I can control _________________________________________________________________ Get live scores and news about your team: Add the Live.com Football Page http://www.live.com/?addtemplate=football -

The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many ...

The current gitk is completely broken on Windows using the current Active State Tcl/Tk release as well: the display is very similar to what is shown on cygwin. The basic problem seems to be that Tk's geometry manager is buggy, on all platforms, not just cygwin. I found many variations of the gitk layout that broke on Linux in similar ways to the breakage on cygwin on my way to creating this patch (including ones that worked on Cygwin/Windows but not on Linux). So, arguments to the effect of "get...

And what is the purpose of such an artificial annoyance that no one will turn on on purpose? You have to _realize_ that there is nothing wrong with such commits. Merely having a config option to prohibit them not only is senseless There is a balance problem there. Too large a message might be annoying but a too short one might not convey enough information not to be yet more confusing. Nicolas -

You should have also something like below: * refs/remotes/origin/master: fast forward to branch 'master' of git://source/project $ git diff --summary 1732a1f..73a2acc $ git diff --summary ORIG_HEAD..HEAD Or, if you want to see the log instead: $ git log 1732a1f..73a2acc $ git log origin/master By the way, you get summary automatically when doing pull, on merge (but not on fast-forward, I think). -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -