[arch-devops] Switch wiki git repo from tarball based updates to git merges?
Hi, AFAICT, our wiki repo has been created with an extracted tarball and updated by just extracting the new tarballs on top of it and committing the result. Due to that we've once lost a change (a2bbd243c85ea0e425ee3e8c380aba9f254cee61) when an update had been commited (7c2a4c95e1d96bc56d00fd133fa537acc1346f5b). I've noticed that we have this open pull request[1] and since the Vector skin is part of the upstream tarball I'm worried that if I were to apply the change, it would again be lost with the next update. [1] https://github.com/archlinux/archwiki/pull/18 I've thus prepared a local branch where I merged our repo with the upstream repo. That means that we can update by merging the upstream tags and thus git can track our changes we get merge conflicts when necessary. The only issue I see with this setup is that we also pull in upstream tags, but those obviously refer to the upstream versions which do not include our changes and thus won't work. We could disable tag fetching, but this has to be done each time someone configures the upstream repo in their local clone and it can't be done automatically. We could either ship a small script that configures the remote correctly, but it has to be executed manually by the user, or we just live with the tags and prefix our own tags with 'archwiki-' or similar in the future. We could also stay with the tarball update method, but I think that's unnecessarily complicated and error prone. Thoughts? Florian
Hi, Le 03/11/2018 à 16:48, Florian Pritz via arch-devops a écrit :
Hi,
AFAICT, our wiki repo has been created with an extracted tarball and updated by just extracting the new tarballs on top of it and committing the result. Due to that we've once lost a change (a2bbd243c85ea0e425ee3e8c380aba9f254cee61) when an update had been commited (7c2a4c95e1d96bc56d00fd133fa537acc1346f5b). I've noticed that we have this open pull request[1] and since the Vector skin is part of the upstream tarball I'm worried that if I were to apply the change, it would again be lost with the next update.
[1] https://github.com/archlinux/archwiki/pull/18
I've thus prepared a local branch where I merged our repo with the upstream repo. That means that we can update by merging the upstream tags and thus git can track our changes we get merge conflicts when necessary.
The only issue I see with this setup is that we also pull in upstream tags, but those obviously refer to the upstream versions which do not include our changes and thus won't work. We could disable tag fetching, but this has to be done each time someone configures the upstream repo in their local clone and it can't be done automatically. We could either ship a small script that configures the remote correctly, but it has to be executed manually by the user, or we just live with the tags and prefix our own tags with 'archwiki-' or similar in the future.
We could also stay with the tarball update method, but I think that's unnecessarily complicated and error prone.
Thoughts?
How many changes do we have? Do we need to re-apply them on top each time? If so, wouldn’t it be easier to have a `arch` branch with our changes that we rebase atop upstream releases? Or you don’t like that workflow because we loose part of the history? Regards, Bruno
On Sun, Nov 04, 2018 at 08:07:15PM +0100, Bruno Pagani via arch-devops
How many changes do we have? Do we need to re-apply them on top each time? If so, wouldn’t it be easier to have a `arch` branch with our changes that we rebase atop upstream releases? Or you don’t like that workflow because we loose part of the history?
Right now we don't have any changes, except for that one open PR on github[1]. Pierre also posted there that he wants stuff like this to be merged upstream which is actually a good idea, so yeah, I'm leaning towards keeping things as they are since it worked fine so far. [1] https://github.com/archlinux/archwiki/pull/18 Florian
participants (2)
-
Bruno Pagani
-
Florian Pritz