I think that I'm the one who previously strongly objected to doing so. I now remove my objections, I think that git has both matured enough and has succeeded in "winning" the distributed VCS war.
-Chris
Based on this comment, and some conversations on the IRC channel, I’d like to offer to work on such a conversion. I think there are a lot of sticky details to work out, but I think it will be very positive move. I’m going to start working on a rough plan for how to do the conversion, and what the final system should look like.
Any key things people want to see in it? Any key concerns? As soon as I have something written up I’ll post it here.
Key things I’m currently thinking about after a brief brainstorm:
- Post-commit triggers need to be ported and kept useful
- Special attention to ensure that the existing code review / commit email system continues to be effective
- Provide individual git repositories for each LLVM project, along with meta repositories that use submodules to layout common development trees (e.g. Clang in tools/clang)
- Post-commit triggers need to be ported and kept useful
- Special attention to ensure that the existing code review / commit email
system continues to be effective
As an aside: Would it be possible/practical for the PR/bug numbers to
be written in a consistent format in checkin descriptions such that
the commit email machinery hyperlinks to the actual bug, perhaps? (I
haven't looked at the bug tracking system in detail - I hope it gets
some kind of link to details about which checkin/revision number fixes
a bug, too. So that you can go from revisions/checkins to bugs and
bugs to revisions again)
I’ve wanted this feature sooo many times that… yea, if I do this, I’ll probably look into implementing it.
Still, I’d leave that and any other features as future work. =] I’m just trying to see if there is general support for this effort in the community, and get a plan of action together for tackling it.
- Keep the buildbot machinery working.
- Add a Webinterface like cgit or gitweb.
Cheers
Tobi
P.S. Let me know if you need any help
Cheers
Tobi
Hi Chandler
Key things I'm currently thinking about after a brief brainstorm:
- Post-commit triggers need to be ported and kept useful
- Special attention to ensure that the existing code review / commit email
system continues to be effective
- Provide individual git repositories for each LLVM project, along with meta
repositories that use submodules to layout common development trees (e.g.
Clang in tools/clang)
One more inportant things: the policy of tagging / branching in the
main repo. As you might seen, right now the stuff is not pretty much
git'ish in the svn repository, so duiring mirroring the tricky part
was to ignore "almost everything, but no too much".
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.
Joerg
I think that I'm the one who previously strongly objected to doing
so. I now remove my objections, I think that git has both matured
enough and has succeeded in "winning" the distributed VCS war.Based on this comment, and some conversations on the IRC channel, I'd
like to offer to work on such a conversion. I think there are a lot of
sticky details to work out, but I think it will be very positive move.
I'm going to start working on a rough plan for how to do the conversion,
and what the final system should look like.
Probably a tasteless suggestion, but... google code supports git now and it works great.
(hides)
LLVM is far from the first project to switch from SVN to git. How have
others handled this issue?
Alex
What about solving this with a post receive hook?
As soon as a commit contains something like "Bug 1222" the relevant git commit is automatically added to Bugzilla and a link to the git web repository is added.
We may even improve this, by automatically closing bug reports if we have "Fixes #1222" or something.
I also personally just copy/past the revision numbers, so I do not really care how long they are. Even with 6 digits copy/paste is for me faster, than remembering them and retyping them.
Cheers
Tobi
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.
Jay.
The problem is answering the question of "do I have it or not". Linear
version numbers are much nicer for that.
Joerg
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] Public Git Hosting - cloog.git/summary
[2] Public Git Hosting - isl.git/summary
[3] Public Git Hosting - pluto.git/summary
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
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.
Good evening, Chris and guys!
IMHO, we would not need to turn toward Git so early.
Subversion's "linear and numbered" revisions would be meaningful in
common cases yet.
Anyway, it must be happier if we could work with Git, too.
May I propose;
- "Official" repositories, for committers to push their commits via
ssh public key.
- Buildbots for committers to check their branches before they would
commit to trunk(master).
(I am planning to arrange such a "try" buildbots personally.
As guys know, Git (git-svn) would be essential for developer who has
many tweaks and improvements.
(for git newbies, ask google "git topic branch")
and who has some platforms to check on his changes.
It must be happier if developers could work together on branches easily.
Cons. Git is not aware of LF/CRLF. Windows and DOS developers shall be
required to LF-tolerant (and they should not push unnecessary CRLF
files any more)
Happy hacking guys! ...Takumi
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.
Joerg Sonnenberger <joerg@britannica.bec.de> writes:
The problem is answering the question of "do I have it or not". Linear
version numbers are much nicer for that.
In the presence of branches, the version number alone doesn't answer
this question, because the commit may be more recent than your HEAD, but
in another branch.
git branch --contains <sha1>, on the other hand, will tell you.
Alexander MacDonald <alexmac@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
(Git Commit Generation Numbers - Stack Overflow
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.
Of course, this doesn't actually help if you've cherry-picked commits
over to your branch (e.g. because it's a release branch).
I agree with Joerg; it's a serious regression, but not a show-stopper.
John.