Re: Creating something like increasing revision numbers

Norbert Preining <preining@logic.at> writes:

No, it is not subversion at all. Don't say "I know" until you really know. Anybody who thinks that is not distributed does not understand distributedness of git.

Distributedness does _not_ come from not having a central shared repository, nor not using more than one branch.

Distrubutedness comes the moment any and all of your people can make their commits _locally_. And the fundamental lack of "increasing global version number" is one implication of the distributedness.

Suppose you and Alice collaborate that way. You make the initial commit, that is pushed to the central shared repository, and alice clones.

    norb$ git commit -m 'first one'
    norb$ git push
    alice$ git clone $central

Now Norb and Alice share that the 'first one' is the current and only commit at the tip of their history. The central repository also shares that notion. You work and produce a few commits.

    norb$ edit; git commit -a -m 'second norb'
    norb$ edit; git commit -a -m 'third norb'
    norb$ edit; git commit -a -m 'fourth norb'

while Alice does the same.
    
    alice$ edit; git commit -a -m 'second alice'
    alice$ edit; git commit -a -m 'third alice'

You happened to push first:

    norb$ git push

You and the central repository shares the view of the history in which the mapping between "revision sequence number" and commits looks like:

    1. first one
    2. second norb
    3. third norb
    4. fourth norb

Imagine what view of the history Alice has at this point and think for a while. Recall Alice hasn't pulled from the central repository since she cloned. There are two possible things you may want to do.

 #1 Some sequential number is given but that is useless as global
    identifier.

    1. first one
    2. second alice
    3. third alice

 #2 Do not give such sequential number locally; the central repository is
    the _only_ place that assigns such a number.  '?' stands for
    'unnumbered'

    1. first one
    ?. second alice
    ?. third alice

Then Alice fetches from the central and integrates her history with it. She can do one of two things. "pull" to create a non-linear history by merging, or "pull --rebase" to keep the history linear.

Since you are imitating subversion, you may choose the latter route to rebase, and now the linearlized history would become:

    1. first one
    2. second norb
    3. third norb
    4. fourth norb
    ?. second alice
    ?. third alice

Alice's two commits may stay unnumbered (if you chose #2---no local versions), or changes from 2/3 to 5/6 (if you chose #1).

If you instead use merges, then there won't be 'sequence' number you can usefully compare anymore.

                    1 first one
                   /|
  second alice    2 2     second norb
                  | |
                  | 3     third norb
                  | |
   third alice    3 4     fourth norb
                  |/
   fourth alice   5

Scheme #1 inherently cannot give you stable and unique numbers in a distributed environment where you can commit locally without talking to the central "number naming authority". By rebasing, you can keep the long-term numbering unique (by renaming some new ones), but rebase has its own downsides besides the name of the commit.

Scheme #2 is a way to get some stablility; give the authority of numbering to the central repository and commits that haven't hit the central repository are left unnumbered. But that is generally not very useful for your purpose of giving incrementing version number for building (the developers would want to build for testing before finally committing to publish the result to the central place).

Running describe using one tag on the 'initial' would give you a rough equivalent of #1 (i.e. you get tentative numbers on the local commits), both in the case you rebase (i.e. your numbers change) and you merge (i.e. you can have more than one "second" commits and numbers are not unique), which would be the best compromise you can get.