On Thu, 18 Aug 2011 23:44:16 -0500
Norbert Thiebaud <nthieb...@gmail.com>
wrote:
> 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)
Merging the "last tag"+"all repo tags" should leave you with
non-leaf-tags, e.g. you do:
git checkout -b libreoffice_3.3.0 \
bootstrap_libreoffice-3.3.0.2
git merge sdk_libreoffice-3.3.0.2 writer_libreoffice-3.3.0.2 ....
git checkout master -- .gitignore
git add -u .gitignore
git commit -m "merged tag libreoffice-3.3.0.2"
git tag libreoffice-3.3.0.2
git merge bootstrap_libreoffice-3.3.0.3 sdk_libreoffice-3.3.0.3 ....
git checkout master -- .gitignore
git add -u .gitignore
git commit -m "merged tag libreoffice-3.3.0.3"
[repeat for each tag on 3.3.0]
[repeat all for each branch]
The tagbranch (do we actually have tags on master after the last
release branchoff?) for master should be merged to master with:
git checkout master
git merge feature/mastertags
There should be no conflicts on the last merge, since all commits on
the branch are already on master and the .gitignore is a
null-diff and it gets rid of the dangling head. In the end we would
have our release branches and master again.
That way you could also do a:
git log libreoffice_3.3.0.2..libreoffice_3.3.0.3
and similar things and get sensible results (over all repos).
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
