From: Daniel Barkalow Date: Mon, 31 Oct 2005 23:37:48 GMT Subject: Re: Question on GIT usage. Message-ID: In-Reply-To: On Mon, 31 Oct 2005, Linus Torvalds wrote: > 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*