Theodore Ts'o <tytso@xxxxxxx> writes:
> On Wed, May 22, 2013 at 10:58:49AM -0700, Junio C Hamano wrote:
>> Theodore Ts'o <tytso@xxxxxxx> writes:
>>
>> > I was actually thinking that it might be interesting to have a
>> > branch.<branch>.rewindable, which would change the guilt defaults, and
>> > could also key changes in key git behavior which makes it less likely
>> > that a user shoots him or herself in the foot --- i.e., give warnings
>> > if he or she has modified the branch in such a way that
>> > remotes.origin.<branch> is no longer contained within the branch head.
>>
>> At least "rebase" can pay attention to it and might make the world a
>> better place.
>
> Yeah, rebase was the primary command I was thinking about. The other
> one would be "git commit --amend" after the branch had been pushed
> out.
It may or may not matter for the kernel folks, but let me pick your
brain while we are on this subject.
The "upstream" (your remotes.origin.<branch>) is that on top of
which you build your work. You clone from there to bootstrap
yourself, you add your work (which may include integrating the work
of your contributors, if you are a mid-tier maintainer/integrator
aka a lieutenant) on top of it, and arrange the result to reach the
"upstream" in some way.
For the simplest (and still widely used) workflow that employs a
central shared repository, the way to make the result to reach the
"upstream" is by directly pushing into it yourself. In that sense,
the word "upstream" and the traditional behaviour of "git push" that
pushes back to the 'origin' (or branch.<branch>.remote) to update
your "upstream" (or branch.<branch>.merge at 'origin') both make
perfect sense.
Also, if you are rebasing, @{u} refers to that place you integrate
with, i.e. your "upstream", in the central shared repository
workflow.
But in a triangular workflow, the way to make the result reach the
"upstream" is *not* by pushing there yourself. For developers at
the leaf level, it is to push to their own repository (often on
GitHub), which is different from where they (initially) clone from
in order to bootstrap themselves, and (subsequently) pull from in
order to keep them up-to-date. And then they request the published
work to be pulled by the "upstream".
Even in a triangular workflow, @{u} should still refer to the place
you integrate with, i.e. your "upstream", not to the place you push
to publish the result of your work.
This branch.<branch>.rewindable safety however cannot be tied to
@{u}. The bottom boundary you want to be warned when you cross is
the change you pushed out to your publishing repository, and it may
not have reached remotes.origin.<branch> yet.
We will be introducing remote.pushdefault configuration in the
upcoming 1.8.3 release, so that you can say:
[remote "origin"]
url = git://g.k.o/pub/scm/linux/kernel/git/torvalds/linux.git/
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "ext4"]
url = g.k.o:/pub/scm/linux/kernel/git/tytso/ext4.git/
fetch = +refs/heads/*:refs/remotes/ext4/*
[remote]
pushdefault = ext4
and hopefully it would let you do this:
git checkout master
... after working on it ...
git push
As remote.pushdefault is set to ext4, without any extra arguments,
the result will pushed to the "ext4" remote. If you are using the
traditional push.default=matching, it may also try to push out dev,
dev-next and other branches you may have in your local repository
and at k.org; if you are using push.default=simple or other "single
branch" modes like "current", "upstream", etc, it will only push out
your current branch (i.e. "master") to "ext4" remote.
You may however be using your local "master" branch for your
development, and pushing the result out to "dev". With only the
remote.pushdefault setting to push to ext4 (instead of origin), you
still would have to say
git push ext4 master:dev
There is another change discussed on the list recently to also let
you configure your local "master" branch to update "dev" in your
publishing repository. It may go like this:
[branch "master"]
push = refs/heads/dev
In any case, refs/remotes/ext4/dev would be the remote tracking
branch (not refs/remotes/origin/anything) that keeps track of what
you pushed out there the last time. And that would be what your new
safety based on "branch.master.rewindable = no" needs to check
against, not "refs/remotes/origin/master" which is your master@{u}.
--
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