Re: [PATCH] git-send-pack: don't consider branch lagging behind as errors.

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 19, 2008, 18:33 UTC
Message-ID: <7vhcbpuvfb.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080619162801.GA2468@artemis.madism.org>

Pierre Habouzit <madcoder@debian.org> writes:

Show 33 quoted lines

> On Thu, Jun 19, 2008 at 03:11:10PM +0000, Jeff King wrote:
>> On Thu, Jun 19, 2008 at 03:52:00PM +0200, Pierre Habouzit wrote:
>> > >   - there is a possible danger with "git push -f", in that you force
>> > >     both rejected branches as well as stale branches. Junio and I
>> >   Well afaict this is a separate issue, as we're (with such a patch)
>> > only changing what gets printed on the console, not the internal
>> > behavior. So solving this second issue should not really be a
>> > precondition to the inclusion of such a patch.
>> 
>> It is a separate issue, but it is exacerbated by hiding stale refs.
>> Imagine:
>> 
>> $ git push
>> To /path/to/repo
>>    ! [rejected]        master -> master (non-fast forward)
>> 
>> $ git push -f
>> To /path/to/repo
>>    + 0abfa88...c1ed93b master -> master (forced update)
>>    + 0329485...3498576 stale_branch -> stale_branch (forced update)
>> 
>> I think that is a nasty surprise to spring on an unsuspecting user.
>> Another solution might be "-f" not pushing rewound branches, but then we
>> need a way to specify "no, really, push this rewound branch". Perhaps
>> "-f -f"?
>
>   Well then we could keep the [stalled] lines for now until this issue
> is resolved then, despite what the people at the beginning of the other
> thread complained about. My real issue is that I have my shell
> configured so that my prompt becomes inverted if the last command
> failed. So do many people I know, and well, git push for stalled
> references should just not generate an error. _this_ is my sole concern
> :)

There are two cases the push does not fast forward. The case where you are truly behind (aka "stale") and you and the pushed-to repository have diverged history. Reporting success when you did not push due to the latter is unacceptable. I personally rely on the fast-forward safety in my push-out scripts, but I do not think it is just me. The exit status from commands are designed to be used that way.

The issue of "many refs in the repo but I work only on a few" has already been resolved by being able to say "I push only the current branch" in the previous thread, I think, but I am too busy to go back to re-study the history, so could you kindly do that for us?

The thing is, the user asked to push certain refs, and some did not get updated. The user has the right to expect a failure indication from the command. If you choose to _ignore_ the failure, that is _your_ choice, like:

	$ git push || :

You might argue that the case where you are truly behind _could_ be ignored and pretend as if the user did not even _ask_ to push it (hence, return success without doing anything to that branch), but I am not convinced even that is a good idea.