A git tag points on one commit, no matter on which branch it is (master or anything else). Branches to points to one commit, not a "set", but the difference is that when you append a new commit, the branch points to the newer commit. When you consider a commit, you also consider its parents, that is what we feel we deal with "sets" of commits.
Since you don't seem very cumfortable with tags: I can propose you another workflow: - We put our daily work on a new branch called 'develop' for instance, instead of master, as it is commonly done on FOSS projects. - When a release is imminent, we merge 'incoming' into 'master' - We send potfiles to translaters - We add translated po files in 'master' - When the release is out, we set a tag on the very last commit. Does it seem better to you ? 2013/11/21 Richard Shann <[email protected]> > On Thu, 2013-11-21 at 09:03 -0600, Jeremiah Benham wrote: > > I am thinking this because it does not seem possible to commit and > > push to a tag like you can branches. You can only updated where the > > tag points in git masters history. Correct? > > From what Eloi said in response to a similar notion I put to him, this > is not the correct model. A git tag is a thing that points > simultaneously to a number of commits (e.g. all the ones up to a certain > point on the master branch plus a few others). > > I trust the maintainer page gives the incantations for adding a commit > to the bunch that a tag refers to etc. > > Below is the bit of the email in which I suggested this model of what a > tag is: > > Instead > > "You can see a tag like a token that you put on commits you want." > > implies that it is a name for the tree resulting from a set of commits > > applied in the order they happened. > > > > Richard > > -- Éloi Rivard - [email protected] « On perd plus à être indécis qu'à se tromper. »
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
