Re: [PATCH] git push --track

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

 



Rudolf Polzer <divVerent@xxxxxxxxxxxxx> writes:

> On Thu, Jan 14, 2010 at 09:27:26AM +0800, Tay Ray Chuan wrote:
>> before I put up my comments on the patch, I wonder if git-push is the
>> best place to add this feature, as git-push usually deals with
>> "pushing" data to another repo.
>> 
>> I think git-branch would be a better place to do this.
>
> I think git-branch can already do this: after pushing, you can do git
> branch -f --track origin/mybranch.
>
> But the goal of this is to postponing the decision to track to the push time,
> and adding as little as possible extra commands/options to do this.

Thinking about this again (when was the last time we discussed it?), I
like the "git branch -f" suggestion (modulo one small nit).  

Yes, "push --track" lets you postpone the decision; branching, working on
it, pushing it out _and_ _then_ using your "branch -f" trick will let you
postpone the decision even further.  And it doesn't add --track to the UI.

The small nit is that "branch -f --track me origin/me" will happily
overwrite "me", even when your "me" is not up to date with "origin/me",
losing commits.

Perhaps we could teach "branch --track me origin/me" (i.e. no "-f") not to
barf even when "me" exists, as long as "me" is a subset of "origin/me",
and treat it as a request to re-configure the upstream information for the
existing branch "me" and at the same time fast-forward it to "origin/me"?
--
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]