Re: branch.pu.forcefetch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Pavel Roskin <proski@xxxxxxx> 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.  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/*

In other words, "path does not correspond to a real file"
problem does not exist.  If you tell git to track 'pu' at
refs/remotes/origin/pu, it will use that path -- so that path
has a corresponding real file.

> Unfortunately, updating the current branch fails because pu is not
> fast-forwarding.  Why fail if I'm not even on pu?

Your being not on 'pu' does not have anything to do with it.  In
fact, you do not even want to be _on_ any of your tracking
branches.  In the separate-remote layout, you cannot even be on
remotes/origin/pu branch.

What you are seeing is fetch's safety feature that stops and
notifies you the situation when the remote rewinds/rebases the
branch you are tracking with tracking branches.  We have had it
turned on by default for a long time, and you have it turned on
in your config because that is the default.  If you do not want
to use that feature (and for git.git, you certainly don't), just
turn it off.  When you know you do not want to use a feature,
you do not have to.

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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]