On 2013-12-09 23.10, Junio C Hamano wrote:
> Torsten Bögershausen <tbo...@web.de> writes:
>> The old log-line looked like this:
>>  + 9d498b0...8598732 master -> master (forced update)
>> And the new one like this:
>>    9d498b0..8598732  master -> master
>> - Loosen the grep pattern by not demanding "(forced update)"
> Hmm, what is the reason for the change the output?  The output this
> piece is testing is the result of this:
>       git push origin master:retsam
>       echo "change changed" > path2 &&
>       git commit -a -m path2 --amend &&
>       # push master too; this ensures there is at least one '"'push'"' 
> command to
>       # the remote helper and triggers interaction with the helper.
>       test_must_fail git push -v origin +master master:retsam >output 2>&1'
> This is run inside test_repo_clone, which has /smart/test_repo.git
> as its origin, which in turn has 'master' branch (and nothing else).
> It
>  - pushes master to another branch retsam;
>  - amends its 'master';
>  - attempts to push the updated master to force-update master, and
>    also retsam without forcing.  The latter needs to be forced to
>    succeed, and that is why we expect it to fail.
> If the output from the push process says
>   + 9d498b0...8598732 master -> master (forced update)
>   ! [rejected]        master -> retsam (non-fast-forward)
>   error: failed to push some refs to '../test_repo_copy/'
> I think that is a good thing to do, no?  After all, that is what we
> show with Git native transports.
> Is this patch merely matching a test to a broken behaviour of some
> sort?  Puzzled...
Thanks for the analysis: I thing the patch isn't the way to go.
The regression in t5541 was introduced in f9e3c6bebb89de12.
Which was a cleanup to previous commits:
"transport-helper: add 'force' to 'export' helpers"
So reverting f9e3c6bebb89de fixes t5541, but breaks

Felipe, could you have a look, please ?


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to