[Dev] [RFC] Splitting abslibre.git into branches
Andreas Grapentin
andreas at grapentin.org
Wed May 24 05:02:54 GMT 2017
On Tue, May 23, 2017 at 11:04:49PM -0400, Luke Shumaker wrote:
> > what would be the benefits of the proposed change?
>
> For one, grabbing packages from AUR without losing history or the
> ability to merge.
you can do that (arguably more cleanly) with git submodules. (I agree
that the submodule api of git is suboptimal)
> Oh, and the tedium of mirroring changes between related packages could
> be reduced to a simple `git merge`. Copying changes from `bbswitch`
> to `bbswitch-lts` and such would suddenly be less painful.
I agree that this is a good point, although I don't see an obvious point
that would prohibit the same functionality if applied to directories.
After sleeping on it, I have a couple more concerns:
- what if someone works on separate packages at the same time because
the build takes a long time? I do this quite often when building
iceweasel et.al. would I need to hop branches? what about changes?
stash them? meh.
- it would become difficult to find certain packages - take for example
libre/kipi-plugins. it is built in the directory libre/digikam. I can
easily find that out with a grep over abslibre, but how would I find
the right branch? The mapping from package to branch is non-obvious.
- I have a couple of scripts operating on all packages, like checking
for latest upstream version, making sure all arches are up to date
with the pkgbuild, etc. I could rewrite these to work on branches
instead, but that might not work if I have feature branches locally.
- would every branch be a package? so we couldn't push feature
branches? this might not be a big issue, but it would attach heavy
semantic load to git branches that is not necessarily expected and
could cause issues in the long term. (related to #3)
All that being said, while I agree that there are benefits to the
proposed change, I am still voting for keeping all the information of
abslibre accessible as directory structure. Please **PLEASE** don't hide
information from me on a file system level, unless ultimately necessary.
git is a great tool, but not a good replacement for a file system.
And if you plan on introducing a tool that pulls separate packages from
the repository, that makes working on the file system level possible
again, then please think carefully whether the benefits of the changes
you have in mind warrant the creation of this tool, the broken workflows
of your collaborators, the learning curve introduced, and the numerous
issues that I expect will pop up with this in the future. Maybe the time
invested here would be more useful elsewhere :)
-A
--
------------------------------------------------------------------------------
my GPG Public Key: https://files.grapentin.org/.gpg/public.key
------------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20170524/2640cd84/attachment.sig>
More information about the Dev
mailing list