Re: push branch descriptions

"Pyeron, Jason J CTR (US)" [off-list ref] writes:

quoted

quoted

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).