Page MenuHomeNicheWork Phabricator

MABS: Remote rename "loses" current fetch and results in a forced update
Open, LowPublic

Description

Following example:

$ git remote rename origin home
$ git fetch home
Searching revisions...
No previous mediawiki revision found.
... fetching from beginning.
Fetching & writing export data by revs...
Listing pages on remote wiki...
1 pages found.
1/3: Revision #1 of Main_Page
2/3: Revision #2 of Main_Page
3/3: Revision #3 of Main_Page
From mediawiki::http://home.localdomain
 + ecc150b...1b7bbea master     -> home/master  (forced update)

Event Timeline

hexmode created this task.Aug 7 2019, 1:31 PM
hexmode triaged this task as Normal priority.

This looks like the same thing I mentioned in this comment. Example:

$ git commit -m "test edit" Main_Page.mw 
[master 7b07d1f] test edit
 1 file changed, 1 insertion(+)
$ git push origin 
Last local mediawiki revision found is 3.
Getting last revision id on tracked pages...
Listing pages on remote wiki...
1 pages found.
Last remote revision found is 0.
Computing path from local to remote ...
Pushed file: 2a46810cacd2f46535f54e92f2378d620ab37154 - Main_Page
To mediawiki::http://home.localdomain
 * [new branch]      master -> master

So remote was fine (except for Last remote revision found is 0 since it should store that from the initial clone).

And fetching works:

$ git fetch
Searching revisions...
Last local mediawiki revision found is 4.
... fetching from here.
Fetching & writing export data by revs...
Listing pages on remote wiki...
1 pages found.

Though it seems like it should just look for highest rev and get any new revs than the one it has.

Maybe changing fetch strategy works to do that.

hexmode shifted this object from the Restricted Space space to the S3 Public NicheWork space.Sep 16 2019, 9:35 AM
hexmode changed the visibility from "All Users" to "Public (No Login Required)".
hexmode lowered the priority of this task from Normal to Low.Sep 16 2019, 9:56 AM