Norbert Preining <preining@xxxxxxxx> writes:
> On So, 18 Okt 2009, Johan Herland wrote:
>> A global, increasing version number ala SVN is fundamentally impossible in
>> any distributed version control system (like Git).
>
> Yes, agreed.
>
> The point is that I do not actually need the "distributed" part of git.
> I want one central repository and all collaborators commit to that.
> Yes, that is subversion, I know.
>
> We have no branches, no tags, nothing of that. Only trunk.
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html