Re: Question on GIT usage.

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Oct 31, 2005, 23:37 UTC
Message-ID: <Pine.LNX.4.64.0510311821410.25300@iabervon.org>
In-Reply-To: <Pine.LNX.4.64.0510311520190.27915@g5.osdl.org>

On Mon, 31 Oct 2005, Linus Torvalds wrote:

Show 11 quoted lines

> On Mon, 31 Oct 2005, Daniel Barkalow wrote:
> > 
> > The system will be unhappy if you commit to a branch that is checked out 
> > elsewhere (because the head of that branch will change out from under the 
> > checked out version), like having someone push to a repository with the 
> > branch checked out.
> 
> Well, the good news is that a "git checkout -f" in the other trees will do 
> the right thing (and only check out the files that have changed).
> 
> The bad news is that you need to remember to do that ;)

If we wanted to make this work reliably, we could have a "LAST_CHECKED_OUT" which has an actual hash (rather than being a link like HEAD is), and gets set by the checkout. Then it would always know what commit you have checked out, even if something causes HEAD to not match.

I personally just never have the same branch checked out twice, so the situation doesn't happen to me. It's easy enough to add additional branches.

Oh, that reminds me: is there a simple way to merge a branch with another local branch or remote branch that's already up-to-date? E.g., I've already fetched the latest git from kernel.org, built it, and installed it. Now I want to merge my development branch with that. Last time I was looking, I had to write the message for the merge myself, unlike "pull", which takes care of that.

Also, I have a repository on my server for one of my projects. I push from my workstation to the "mainline" branch, and I have "deploy" checked out (with some configuration changes that shouldn't propagate back). Then I merge "mainline" into "deploy", build, and install. Same thing; I have to write the "merge with mainline" argument myself.

	-Daniel
*This .sig left intentionally blank*