Topic on Talk:Download from Git/Flow

Best practice for maintaining a local fork?

5
Maiden taiwan (talkcontribs)

I manage a MediaWiki site that is basically the REL1_39 branch plus LocalSettings.php and a few extensions I wrote myself. What is the best practice for maintaining this kind of set up with Git, so I can easily update the core MediaWiki software without disturbing my custom files?

I thought maybe I could create a local Git branch named mine that's based on origin/REL1_39 and add my files. I would never commit this branch to Gerrit -- it just stays on my local host. Then, when MediaWiki is updated to (say) 1.40, I'd just git merge origin/REL1_40 into my mine branch. But when I tried this locally, I got many merge conflicts.

Or, I could maintain my private files (LocalSettings.php etc.) in a separate local Git repository, and then at deployment time, combine the MediaWiki core files and my repository on our production server. But writing scripts to deploy files from 2 separate Git repositories feels a little hacky.

Is there a better way? Thank you very much.

Tacsipacsi (talkcontribs)

If you got merge conflicts when doing git merge origin/REL1_40, it means that your own modifications touched parts of the code that changed between 1.39 and 1.40. I don’t think there’s an automated way to resolve those conflicts, no matter if you use a different branch, a different repo or something else – programs can’t read your mind to figure out what you wanted to do. A branch in the same repo is IMO the best solution exactly because of the conflicts: the conflicts highlight what cannot be merged automatically (and do so well before deployment, so the manual merging doesn’t cause downtime).

However, if you touched only LocalSettings.php and added extensions, there should be no conflicts: LocalSettings.php is ignored in Git, and extensions have their own directories. (Unless you happened to have chosen names that haven’t been in 1.39 but are in 1.40: in that case, simply rename your own extension.) So the question is: what else did you modify in MediaWiki core, and could those modifications either be submitted to Gerrit so that you don’t have conflicts in the future, or be reverted because the official version of MediaWiki now provides you what you need?

Maiden taiwan (talkcontribs)

Thanks @Tacsipacsi! I actually didn't modify anything in MediaWiki core. Here's what happens with a simple merge of the kind I described.

$ git clone https://gerrit.wikimedia.org/r/mediawiki/core.git

$ cd core

$ git switch REL1_39

$ git switch -c foobar

$ git merge origin/REL1_40

This give me tons of merge conflicts.

CONFLICT (add/add): Merge conflict in .gitmodules

CONFLICT (content): Merge conflict in autoload.php

CONFLICT (content): Merge conflict in composer.json

etc.

What am I doing wrong?

Tacsipacsi (talkcontribs)

I see. I didn’t realize what you effectively try to do is merging 1.40.3 into 1.39.7. Since they have independent history since 1.39 got branched, conflicts are actually not surprising. If you indeed don’t touch anything except for LocalSettings.php and your custom extensions, maybe the best solution is not to maintain your own branch of MediaWiki:

  • Maintain extensions separately, one repo per extension. This is also how extensions are maintained on Gerrit.
  • Maintain LocalSettings.php in yet another repo.
  • Create a deployment script that deploys the extensions (this could go in the same repo as LocalSettings.php). Two possibilities:
    • Simply cd extensions && git clone ../../custom-extensions/extension-name
    • git submodule add ../../custom-extensions/extension-name extensions/extension-name && git submodule update (this helps with later updates, but makes the working tree dirty)
  • Make sure LocalSettings.php is kept up to date, for example by copying it with the above script, or by symlinking it.

P.S. Please note that I’m just one person. This is how I’d do it, but it may not be the best solution.

Maiden taiwan (talkcontribs)
Reply to "Best practice for maintaining a local fork?"