Re: Dangers of working on a tracking branch

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

 



On Fri, Feb 16, 2007 at 09:27:45AM -0600, Bill Lear wrote:

> Ok, fair enough, but then I guess I'm back to my original question:
> how can I give a concrete demonstration to our developers that this is
> a bad thing?

I think it will always work with the example you gave, because you are
simultaneously fetching into the tracking branch (which fails) and
merging from FETCH_HEAD (which succeeds) into that same tracking branch.

At best, though, the tracking branch you have is pointless (since you
immediately overwrite it anyway).  The point of a tracking branch
generally is to allow you to do operations against your peer's idea of
the branch (e.g., diffing against upstream's version of "topic"). But
you can't do that, because "topic" always contains your topic, not
upstream's. In effect, your pull becomes one without a tracking branch
at all.

This will also get you on a push, where there is no merging at all, just
a fast-forward (or failure). IIRC, you ran into problems before because
you were trying to push into your public repo from your private, but the
two had divergent branches. So I think to illustrate the problem you had
before, you actually need an intermediate repo which has you fetch from
and push to.

-Peff
-
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]