demerphq wrote:
> Consider you have A-B-C-D-E in your master repo. So presumably numbered 1..5.
>
> If i then make a trivial comment fix to A and then merge and push we
> end up with:
>
> A-B-C-D-E-G
> \ /
> F------+
>
> If i understand you right you will set F to 6 and G to 7. Thus youll
> end up with the problem that F is a descendent of A yet has a higher
> "version number" than E. You can repeat this process for ever.
>
> If this suits your needs then great.
Just like subversion :D
It helps by ordering commits by time, not by parents, and I don't need
repo access to figure it out that F is the latest bug/feature/fix.
Think about 2 sql servers, each has different versions of the same
stored procedure. Which one is newer, given that you don't have
the git repository on the production servers? I can't make any decision
on SHA1 only, and if they belong to the same branch ("prod")
I'm so out of luck. At the moment I'm saving SHA1, refs, author date,
comitter date and last subject. But it's easier for me to compare
revision numbers than dates. And don't forget that updating decisions
may be taken by people that have nothing to do with development.
Have a nice day,
A.
--
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