Re: [PATCH 2/2] format-patch: introduce format.defaultTo

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

 



On Mon, Jan 6, 2014 at 5:54 PM, Ramkumar Ramachandra <artagnon@xxxxxxxxx> wrote:
> John Szakmeister wrote:
>> Then where does it get pushed?  Do you always specify where to save your work?
>>
>> FWIW, I think the idea of treating @{u} as the eventual recipient of
>> your changes is good, but then it seems like Git is lacking the
>> "publish my changes to this other branch" concept.
>>
>> Am I missing something?  If there is something other than @{u} to
>> represent this latter concept, I think `git push` should default to
>> that instead.  But, at least with my current knowledge, that doesn't
>> exist--without explicitly saying so--or treating @{u} as that branch.
>> If there's a better way to do this, I'd love to hear it!
>
> That's why we invented remote.pushdefault and branch.*.pushremote. When you say
>
>   $ git push
>
> it automatically goes to the right remote instead of going to the
> place you fetched from. You can read up on how push.default interacts
> with this setting too, although I always recommend push.default =
> current.

This was the piece that I was missing.  I remember when
remote.pushdefault was added, but questioned its usefulness because it
just changes the remote that a branch is pushed to, not necessarily
the name.  I somehow missed the 'current' option for 'push.default'...
which is surprising since I seem to spend an incredible amount of time
looking at the git-config man page.  I guess it's not a good idea to
set 'push.default' to 'upstream' in this triangle workflow then,
otherwise the branch name being pushed to will be 'branch.*.merge'.
Is that correct?  I just want to make sure I understand what's
happening here.

Given this new found knowledge, I'm not sure it makes sense for `git
status` to show me the status against the upstream vs. the publish
location.  The latter makes a little more sense to me, though I see
the usefulness of either one.

Thanks for taking the time to explain this.  I'm going to have to
spend some more time with this configuration and see what the sticking
points are.

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