Re: branch.pu.forcefetch
- From
- Pavel Roskin <proski@gnu.org>
- Date
- Dec 29, 2006, 03:34 UTC
- Message-ID
- <1167363263.15189.79.camel@dv>
- In-Reply-To
- <7v8xgrsabr.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-12-28 at 18:30 -0800, Junio C Hamano wrote:
Show 9 quoted lines
> Pavel Roskin <proski@gnu.org> writes: > > >> Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"? > > > > Yes, I'm talking about that line. And I don't like that I have to use a > > magic token "refs/heads/pu" that doesn't correspond to a real file to > > make it possible to keep git up-to-date. > > I think we misunderstood each other.
I just didn't notice that your question used a different line. I was talking about
fetch = +refs/heads/pu:refs/remotes/origin/pu
Show 9 quoted lines
> That line is inconsistent > with what your config has, which is the separate-remote layout, > which I did not know you were using. In separate-remote layout, > you don't have refs/heads/pu so if we do not do the patches you > are agreeing to, you would want to have something like: > > [remote "origin"] > fetch = +refs/heads/pu:refs/remotes/origin/pu > fetch = refs/heads/*:refs/remotes/origin/*
I get it now. "refs/heads/pu" must be the path on the remote side.
The whole thing remains pretty hairy for my taste, but it looks like we are going to untangle it step-by-step.
Show 6 quoted lines
> Turning it off by default was not a wise thing to do in general > for a long time, because rewound/rebased tip loses information, > and we did not have reflog enabled by default. Your message > raised this issue to attention of the list, and I suggested two > patches out of it, both of which I think are sane things to do. > If the list agrees, we can turn it off by default now.
Just a random idea - if fast-forward fails, save the original head somewhere under refs as a backup. It's like "patch" saving *.orig files if there is any doubt that the patch was applied cleanly.
But I'm fine with reflog too.
-- Regards, Pavel Roskin