On Mon, 19 Oct 2009, Norbert Preining wrote:
> Hi all,
>
> thanks everyone for the nice feedback!
>
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > It's possible as long as you don't think of the "version number" as a
> > property of the commit, but rather a property that some commits get by
> > virtue of having been at some time the commit that's what would be found
> > on that particular server at that particular time. Even though the history
>
> Right! That is a good point. In fact I don't care about (local) commits,
> but about the pushes to the central server.
>
> > of the *content* is non-linear, the sequence of values stored in
> > refs/heads/master on your central server is linear, local, and easy to
> > enumerate.
>
> That is exactely what I need.
>
> > Of course, when someone does a bunch of development in parallel with other
> > people, does a final merge, and pushes it back to the server, this only
> > increases the version by one, and only the final merge actually has a
>
> As it is now with svn, we have to live with that. The point is that we
> still would see many different commits pushed to the server, so
> git log would show the single items, but the "versioning sequence number"
> is only increased by one. That would be *absolutely*perfect* for me!
>
> > because the intermediate commits don't ever get packages created of them
> > to need to be compared to other packages.
>
> Right!
>
> Now my follow-up questions:
> - how would one access this "sequence" number on the server
There isn't currently anything built in that counts up like that; however,
it shouldn't be too hard to add something, because the reflog gets an
entry at the same times the sequence number would increase. In fact, you
could disable pruning the reflog, and use its length (in lines), except
that would get slow and git doesn't expect you to care about the complete
history there (in fact, you only care about the amount of history past
some point).
> - is there a way to determine at which of this "sequence" numbers a specific
> file has been changed last?
There isn't a built-in way, but you can find the current hash for a
filename with "git ls-tree -r <branch> <filename>", and find the hash as
of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
looking for the smallest N where they don't match. (And you probably
don't want to be a binary search or the like, because that might miss that
a file was most recently affected by having a change reverted; you'd want
to be sure to report the version that reverted the change, not the version
that introduced the content the later one returned to.
-Daniel
*This .sig left intentionally blank*
--
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