Re: recent change in git.git/master broke my repos

From: Karl Hasselström <kha@treskal.com>
Date: Oct 26, 2007, 07:39 UTC
Message-ID: <20071026073955.GB11286@diana.vm.bytemark.co.uk>
In-Reply-To: <alpine.LFD.0.9999.0710251344220.22100@xanadu.home>

On 2007-10-25 13:46:04 -0400, Nicolas Pitre wrote:

Show 13 quoted lines

> On Thu, 25 Oct 2007, Karl Hasselström wrote:
>
> > On 2007-10-25 07:32:36 -0700, Randal L. Schwartz wrote:
> >
> > > And when are we gonna get "fast forward only" for git-merge?
> >
> > I'd like that too. For cases when I know I don't have to do a
> > merge, and want git to yell at me if I'm mistaken. For example, in
> > a repository that tracks an upstream so I can build the latest
> > version, but where I don't normally do any development.
>
> Isn't that called a remote branch that gets updated with "git
> fetch'?

Sure, I could use a detached HEAD instead of a local branch. However, that'll still not warn me that merging in another branch won't be a fast-forward.

> You can even trick Git into not using the refs/remotes/ namespace
> for them if you wish.

I'm not sure what'll happen if git fetch tries to update a branch that I've made local changes to, but I don't imagine it's anything productive. If not forced it'll fail, and if forced it'll lose my local commits. The former might actually be sort of what I want (git complains when I have local commits), but I'm rather fond of the refs/remotes/ stuff, so this solution sounds like a hack to me. What I really want is an "extra careful" merge that is guaranteed to do nothing but a fast-forward if it succeeds.

As is, it's a two-line shell script, though, so it isn't that important.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle