[Libreoffice] Git tags: why not "3.3.4-rc2" instead of ""

Bjoern Michaelsen bjoern.michaelsen at canonical.com
Fri Aug 19 00:49:54 PDT 2011

On Thu, 18 Aug 2011 23:44:16 -0500
Norbert Thiebaud <nthiebaud at gmail.com>

> 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 \
git merge sdk_libreoffice- writer_libreoffice- ....
git checkout master -- .gitignore
git add -u .gitignore
git commit -m "merged tag libreoffice-"
git tag libreoffice-
git merge bootstrap_libreoffice- sdk_libreoffice- ....
git checkout master -- .gitignore
git add -u .gitignore
git commit -m "merged tag libreoffice-"
[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).




More information about the LibreOffice mailing list