On Tue, Mar 10, 2015 at 11:00 PM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
>
> OK, replace that Gerrit-specific push syntax with:
>
> git send-email
>
> :)
Heh don't be too defensive; I was merely pulling your leg.
>> ... But I am not sure what the definition of
>> unusual should be. In a non-Gerrit central repository workflow, the
>> rule might be "HEAD must not be reachable from @{upstream}"
>> (otherwise you are rewriting what you got from elsewhere), or it may
>> be "HEAD must not be reachable from @{publish}'s remote tracking
>> branch", or perhaps both, as these two could be different in
>> triangular workflow.
>>
>> But I am not sure what the sensible rules are when the user prepares
>> the commit, planning to push it to a ref like refs/for/master that
>> does not have a counterpart on our side.
>
> True.
With a more concrete example, I'd imagine you have something like
this to wok on branch "master"
[remote "origin"]
url = ...
pushurl = ...
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/*:refs/for/*
[branch "master"]
merge = refs/heads/master
Even though we cannot prevent the user from rewriting what _he_
already pushed out to refs/for/master (as we do not have the record
of what the last thing we pushed there and its history via a reflog),
we could at least detect when he attempts to rewrite what he
obtained directly from the upstream by noticing where origin/master
is. If HEAD is _at_ that commit, or its ancestor, then he is trying to
rewrite what he got from elsewhere.
It would catch your original "commit --amend -m 'my first'" scenario.
Run is_ancestor(HEAD, @{upstream}) we can notice. That may be
better than nothing, but I do not offhand know if that is sufficient.
> Another way users get into a bind is they pull someone else's branch
> (so they can build on top of her work), then `git commit --amend -a`
> by mistake instead of making a new commit.
One thing we already do is to give an extra "Author: " line in the
comment when the user edits the log message, so that it is clear
that what is being edited is not their own work but hers. We obviously
can add the extra warning, when the is_ancestor() thing triggers, to
say YOU ARE REWRITING PUBLISHED HISTORY in blinking red
bold letters there.
But the symptom indicates that they are not reading these warning
comment. Perhaps it is necessary to introduce a training wheel mode
where you cannot use "--amend" and "-m" options from the command
line until you ask nicely to override it?
--
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