Re: [Denemo-devel] Release 1.1

[Éloi Rivard]

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 <address@hidden>

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 - address@hidden
       
« On perd plus à être indécis qu'à se tromper. »