Re: [PATCH] branch: optionally setup branch.*.merge from upstream local branches

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

 



Hi,

On Mon, 18 Feb 2008, Jay Soffian wrote:

> On Feb 18, 2008 7:14 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> 
> > On Mon, 18 Feb 2008, Jay Soffian wrote:
> >
> > > -static int branch_track = 1;
> > > +static enum branch_track branch_track = BRANCH_TRACK_FALSE;
> >
> > That is a clear regression.
> 
> Perhaps. It's consistent with builtin-checkout.c though (which was 
> initializing it to 0). Who to believe?

Well, in the way _you_ implemented it, it is a clear regression, since 
_your_ patch changes the 1 to a 0.

> > Personally, I have no problem with typing "git merge <branch>" in your 
> > workflow.  I would even avoid saying "git pull" for obviously-local 
> > branches, because I would have forgotten which branch it tracked 
> > originally.
> 
> Um, well, apply this patch, set branch.autosetupmerge=always and then 
> branch.*.merge will tell you which branch it tracked originally. :-)

That's what I meant.  Rather than _looking it up_, and then saying "git 
pull", I'd do "git merge <branch>" _directly_.  One command.  Not two.

> Aside, then how do you figure out the upstream branch is if you've 
> forgotten?

Well, that's easy.  I would look at the output of "git show-branch --all".

But then, I usually do not care too much which branch I branched off, but 
which branch to merge with/rebase on.

Ciao,
Dscho

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

  Powered by Linux