On Thu, Aug 18, 2011 at 5:40 PM, Bjoern Michaelsen <bjoern.michael...@canonical.com> wrote: > Hi Michael, > > On Thu, 18 Aug 2011 20:40:13 +0100 > Michael Meeks <michael.me...@novell.com> > wrote: > >> It looks like yet-another bikeshed to me :-) > > Indeed. > >> I'd be more concerned that git tag -l on the 'core' repo has dozens >> of tags for the same version: artwork_libreoffice-3.4.0.2 >> base_libreoffice-3.4.0.2 etc. personally ;-) suggestions for cleaning >> that up much appreciated. > > While you are clearly hijacking this thread ;) the solution should be > rather simply: merge all the repo-tags for each tag and tag that joined > commit. After creating those tags, all the separate tags could be > removed for readability proposes.
by doing that you would be creating new commits completely out of order of the history... essentially creating a cactus on top of n old repos history with a bunch of leaf-tags. (that is dead-end 18 commit branch just to merge them all -- since at least .gitignore conflict, that make octopus merge problematic -- with the tag at the end of it... without any connection to the tag before or after it) All in all, a lot of work that will just add lots of ugliness to the already hairy history for... not having so many tags ? these tag are very easy to grep out of existences... right no there are no 'useful' tag on core, but when there is, git tag | grep libreoffice will give you the interesting ones. The benefit of these tags (in core) is not so much to be able the check out what _was_ version 3.3.2 for instance... but to have some markers when browsing the history of a given module... and locate the branch point to the 3.3, 3.4 etc branches for each old repos... Norbert _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
