On 07/21/2011 01:44 PM, Joerg Sonnenberger wrote:> On Thu, Jul 21, 2011 at 12:26:29PM +0100, Jay Foad wrote: >> On 21 July 2011 11:50, Joerg Sonnenberger<joerg at britannica.bec.de> wrote: >>> There is still the major regression with unreadable version numbers. >>> Given the amount of Bugzilla traffic with "Fixed in...", that's a >>> non-trivial issue. >> >> I wouldn't call that a major regression. For informal use you can >> quote 8 hex digits of the git commit name, which isn't *much* worse >> than a 6 digit decimal number. For more rigour, you can use a link to >> the llvm-commits message in the archive (people already frequently do >> this) or to the vcs-web interface. > > The problem is answering the question of "do I have it or not". Linear > version numbers are much nicer for that.Sure. So there will never be any way to get linear version numbers with git. The only way to understand if you have a revision is in your repository is to check with $ git log <hash> or $ git log and search for <hash> If you do not have a repository, you need to guess based on the time of commit and checkout or you need to use a web interface to the repository. I personally never missed the linear numbers. Using git to work with projects like cloog[1], isl[2], pluto[3], Polly, LLVM and clang I got used to search all the time in the history (as it is readily available even for offline use and it is extremely fast). As a result, looking up version numbers easily integrated into my work flow. Did you try to work with git and are you convinced this is a show stopper for you? Or are you looking for specific solutions beyond the ones I have suggested? Cheers Tobi [1] http://repo.or.cz/w/cloog.git [2] http://repo.or.cz/w/isl.git [3] http://repo.or.cz/w/pluto.git
On Thu, Jul 21, 2011 at 02:18:43PM +0200, Tobias Grosser wrote:> Did you try to work with git and are you convinced this is a show > stopper for you? Or are you looking for specific solutions beyond > the ones I have suggested?I had to work with git for a number of projects. It's a regression. It nothing that is a show stopper, but I don't really see the advantage of moving to git either. Joerg
> On Thu, Jul 21, 2011 at 02:18:43PM +0200, Tobias Grosser wrote: >> Did you try to work with git and are you convinced this is a show >> stopper for you? Or are you looking for specific solutions beyond >> the ones I have suggested? > > I had to work with git for a number of projects. It's a regression. > It nothing that is a show stopper, but I don't really see the advantage > of moving to git either.No? Comitting locally gives me a warm and fuzzy feeling. And, hey, branching and merging becomes a thing you actually want to do, not something that you don't want to do because of the hazzle. I'm pretty sure git will be a positive thing for llvm, although the transition is a slight pain. Getting rid of all those .svn directories isn't such a bad thing either, for my grepping tools, backup and whatnot.
On Jul 21, 2011, at 5:18 AM, Tobias Grosser wrote: On 07/21/2011 01:44 PM, Joerg Sonnenberger wrote: On Thu, Jul 21, 2011 at 12:26:29PM +0100, Jay Foad wrote: On 21 July 2011 11:50, Joerg Sonnenberger<joerg at britannica.bec.de<mailto:joerg at britannica.bec.de>> wrote: There is still the major regression with unreadable version numbers. ... The problem is answering the question of "do I have it or not". Linear version numbers are much nicer for that. Sure. So there will never be any way to get linear version numbers with git. ... The topic of generation numbers has come up again recently on the git lists and it looks like they might make it in (http://stackoverflow.com/questions/6702821/git-commit-generation-numbers). Of course this isn't exactly the same as svn because the numbers are only unique within a given branch, but it should still help. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110721/be40e8dc/attachment.html>
Alexander MacDonald <alexmac at adobe.com> writes:> The topic of generation numbers has come up again recently on the git > lists and it looks like they might make it in > (http://stackoverflow.com/questions/6702821/ > git-commit-generation-numbers). Of course this isn't exactly the same > as svn because the numbers are only unique within a given branch, but > it should still help.Not really. Generation numbers are discussed as a performance optimization, but they're not unique, even within what we usually call a "branch" (i.e. the set of commits reachable from the ref) : A --- B \ \ C --- D --- E <--- master Commits B and C will have the same generation numbers. I hardly see a context where they could be used by end users as commit identifiers. -- Matthieu Moy http://www-verimag.imag.fr/~moy/