Re: [jgit-dev] faster ref-updates where the update-type is known to be n

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Mon, Aug 26, 2013 at 9:00 AM, Roberto Tyley <roberto.tyley@xxxxxxxxx> wrote:
> On 26 August 2013 16:33, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
>
>> > Although this isn't current behaviour, perhaps setting the
>> > ReceiveCommand
>> > update-type to UPDATE_NONFASTFORWARD before calling
>> > BatchRefUpdate.execute()
>> > should be enough to tell JGit that I know the update type, and don't
>> > want
>> > JGit to calculate it?
>>
>> There isn't a clean way to do this sort of update, but there should
>> be. It is completely reasonable for a calling application to say it
>> has already vetted the update and just wants it to proceed, provided
>> the reference still exactly matches the expected old SHA-1 (if
>> supplied).
>>
>> I thought it bypasses if the update-type is already set to
>> UPDATE_NONFASTFORWARD as you suggest, as we only run the check when
>> the type is the default of UPDATE.
>
>
> I did try this, while one call to isMergedInto() is avoided, the other one
> still occurs in RefUpdate.updateImpl(), where there is no guard:
>
> https://github.com/eclipse/jgit/blob/9b26e4bff/org.eclipse.jgit/src/org/eclipse/jgit/lib/RefUpdate.java#L624
>
> (it's also currently a bit fiddly as an external user to set the
> ReceiveCommand up in the correct state to do this, as
> ReceiveCommand.setType() is not public and the 4-arg constructor does not
> set status to Result.NOT_ATTEMPTED...  so you must call
> setResult(NOT_ATTEMPTED) manually before executing the command- obviously,
> trivial to fix).

This set result thing sounds like a bug?

> I'd be happy to contribute a change to make the behaviour of RefUpdate match
> what we've described above.

Relevant change(s) would be appreciated. :-)