From: Junio C Hamano <gitster@pobox.com>
To: "Pyeron\, Jason J CTR \(US\)" <jason.j.pyeron.ctr@mail.mil>
Cc: git <git@vger.kernel.org>
Subject: Re: push branch descriptions
Date: Wed, 14 Nov 2012 09:58:27 -0800 [thread overview]
Message-ID: <7vbof0awxo.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537AABCCA@umechphj.easf.csd.disa.mil> (Jason J. Pyeron's message of "Wed, 14 Nov 2012 17:21:03 +0000")
"Pyeron, Jason J CTR (US)" <jason.j.pyeron.ctr@mail.mil> writes:
>> > Imagine the project creates a branch "magic" to enhance its system
>> > with magic words. The description for the "magic" branch in the
>> > project may say "support magic words" or something.
>> >
>> > You and your friend are tasked to add a handful of magic words,
>> > e.g. "xyzzy", "frotz" and "nitfol". You may start your work like so
>> > on your "magic-xyzzy" branch:
>> >
>> > $ git clone git://example.com/zork.git/
>> > $ git checkout -b magic-xyzzy -t origin/magic
>
> And here the branch description should copy from origin/magic.
I doubt it should. The purpose of the "magic" branch at the remote
in my example were to "support magic words" (without limiting which
magic words the project wants to support) and that is what the
description over there may say, while the purpose of the local
"magic-xyzzy" branch you create in order to add the support for
"xyzzy" magic is just one small subtask of it.
That is what I meant by "the inherently local nature of the branches
and branch descriptions". Git as a distributed system works well
exactly because what each repository has is inherently local, and
people can do whatever they want in their own repositories, while
allowing collaboration among participants by pulling and pushing
histories that share compatible (note: not necessarily "identical")
goals. "support magic words" being a superset of "add xyzzy magic"
is an example of this principle. They have different goals (and
that is why propagating the description of your "magic-xyzzy" to the
project global "magic" is a wrong thing to do), but from the point
of view of the project global "magic" branch, what your "magic-xyzzy"
branch wanted to do is compatible with its larger goal (and that is
why merging to "magic" from "magic-xyzzy" is a good thing, while
merging the other way is frowned upon in general).
prev parent reply other threads:[~2012-11-14 17:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-14 7:20 push branch descriptions Angelo Borsotti
2012-11-14 10:33 ` Ramkumar Ramachandra
2012-11-14 13:52 ` Michael J Gruber
2012-11-14 13:57 ` Junio C Hamano
2012-11-14 14:51 ` Angelo Borsotti
2012-11-14 17:21 ` Pyeron, Jason J CTR (US)
2012-11-14 17:58 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vbof0awxo.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jason.j.pyeron.ctr@mail.mil \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox