Re: Documentation about "push.default=upstream" is confusing

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

 



Ingo Rohloff <lundril@xxxxxx> writes:

> To handle that I setup several remote tracking branches called:
>   repo1_master   (tracks repo1/master)
>   repo2_master   (tracks repo2/master)
>   reap3_master   (tracks repo3/master)
>
> Now without "push.default=upstream" I would have to either always explicitly
> do something like:
>   git push repo1 repo1_master:master
>   git push repo2 repo2_master:master

If you think about your interaction with people who are only looking
at "repo1" alone, you _are_ using a centralized workflow.  You are
not the only one who update their 'master'; other people push there
to update that 'master' and you pull it in to keep you up to date
and further build your changes on top.  Such an interaction with
other people by using repo1 as the shared meeting point is well
served by the push-to-upstream mechanism, and that kind of
interaction is called "centralized workflow".  The illustration from
you is running one centralized workflow with each of the three
repositories.

The de-centralized workflow the message hints (but does not talk
about) is different.  It is not uncommon to pull from one place and
then to push the result out to your own publishing branch
(e.g. clone from anna, fetch to keep up to date with her, work on
it, publish to your repository to tell her to fetch from you), and
push-to-upstream is not very well suited for that topology.  You may
clone her "for-bob" branch, but you do not push it back to her
repository to update her "for-bob" branch.
--
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]