git Status Update?

Have we made any progress on a potential git conversion? AFAIK the only
outstanding technical issue is the monotonic revision number question.
Personally, I have no nead for them but others have expressed
reservation about losing them.

Can we have a discussion about that to identify the core tasks currently
needing monotnic revision numbers and how they might be accomplished
under git? Otherwise I fear we will be forever stuck in the waiting
game.

I also know that there is a time/resource issue in actually making the
transition. Some group of people needs to do the work. Has there been
any progress in identifying who those people are? Any volunteers? I'll
put my name in the hat to do whatever mundane work I can do to help the
process along. All assuming we actually make the transition, of course.

                            -Dave

Have we made any progress on a potential git conversion? AFAIK the only
outstanding technical issue is the monotonic revision number question.
Personally, I have no nead for them but others have expressed
reservation about losing them.

There are very decent solutions to the monotonic revnum issue (git describe, hooks/tagging), so that shouldn't hold back the transition. I suppose it's merely a manpower thing now, and the fact that Subversion unfortunately works "well enough" for the majority of peeps.

FlyLanguage <flylanguage@gmail.com> writes:

Have we made any progress on a potential git conversion? AFAIK the only
outstanding technical issue is the monotonic revision number question.
Personally, I have no nead for them but others have expressed
reservation about losing them.

There are very decent solutions to the monotonic revnum issue (git
describe, hooks/tagging), so that shouldn't hold back the transition.

That's what we need to have a discussion about. If those things will
work for people, great. If not, we have some stuff to figure out.

I suppose it's merely a manpower thing now

I'm not assuming that given the volume of e-mail around this.

and the fact that Subversion unfortunately works "well enough" for the
majority of peeps.

Is that really true? I've heard of a lot of LLVM developers using git
but it all seems very opaque right now. That's why I hope to get people
talking so we can find out where everyone is and go from there.

                              -Dave

That's what we need to have a discussion about. If those things will
work for people, great. If not, we have some stuff to figure out.

Agreed. Hopefully core peeps will chime in.

I suppose it's merely a manpower thing now

I'm not assuming that given the volume of e-mail around this.

Sending mail is cheap. Switching to git completely isn't.

and the fact that Subversion unfortunately works "well enough" for the
majority of peeps.

Is that really true? I've heard of a lot of LLVM developers using git
but it all seems very opaque right now. That's why I hope to get people
talking so we can find out where everyone is and go from there.

Yet, there's surprisingly little complaint about Subversion around here, which is kinda unfortunate :slight_smile:

I know you're being facetious, but why is it unfortunate? SVN serves our workflow very well. The versioning system should get out of the way of development; it shouldn't "pull focus." SVN doesn't require you to spend a lot of time learning it and adapting to its way of doing things. (The learning curve for SVN was small for me. My initial (and subsequent) experiences with git are that it's very, very complex. And it gets in the way of most things I want to do. I still don't know what a "ref" or "object" is.)

-bw

Is that really true? I've heard of a lot of LLVM developers using git
but it all seems very opaque right now. That's why I hope to get people
talking so we can find out where everyone is and go from there.

Yet, there's surprisingly little complaint about Subversion around here,
which is kinda unfortunate :slight_smile:

I know you're being facetious, but why is it unfortunate?

Because you're missing so much.

> I still don't know what a "ref" or "object" is.)

Fortunately, that's about the only thing in a git repository, so there's not much more to learn :slight_smile:

I am not very familiar with GIT so I have a question:
Let's say I don't fork and I work 1 patch at the time. Then what are
the advantages of GIT over svn?

FlyLanguage <flylanguage@gmail.com> writes:

I still don't know what a "ref" or "object" is.)

Fortunately, that's about the only thing in a git repository, so
there's not much more to learn :slight_smile:

And you don't need to learn it at all.

                              -Dave

I am not very familiar with GIT so I have a question:
Let's say I don't fork and I work 1 patch at the time. Then what are
the advantages of GIT over svn?

Other than being able to work locally wrt. committing and diffing, probably none.

Is that really true? I've heard of a lot of LLVM developers using git
but it all seems very opaque right now. That's why I hope to get people
talking so we can find out where everyone is and go from there.

Yet, there's surprisingly little complaint about Subversion around here,
which is kinda unfortunate :slight_smile:

I know you're being facetious, but why is it unfortunate?

Because you're missing so much.

I read Dave's document. It lists (rather complex) ways to use it, but it doesn't list why any of them are needed for our workflow. That would go more towards convincing me that it's a good thing.

> I still don't know what a "ref" or "object" is.)

Fortunately, that's about the only thing in a git repository, so there's not much more to learn :slight_smile:

That doesn't tell me anything. And unfortunately they are used in many git commands.

-bw

Yet, there's surprisingly little complaint about Subversion around here,
which is kinda unfortunate :slight_smile:

I know you're being facetious, but why is it unfortunate?

Because you're missing so much.

I read Dave's document. It lists (rather complex) ways to use it, but it doesn't list why any of them are needed for our workflow. That would go more towards convincing me that it's a good thing.

Yes, it more complex than svn. No doubt. I'm personally very happy with the svn-git bridge - my only wish is it was updated more often.

I still don't know what a "ref" or "object" is.)

Fortunately, that's about the only thing in a git repository, so
there's not much more to learn :slight_smile:

And you don't need to learn it at all.

I agree, though the man pages is a hard read if you don't grok ref's and objects.

Just in case you want to know more about objects and refs, you can read the first sections of the chapter 9 of the free "Pro git" online book.

http://progit.org/book/ch9-0.html

This chapter is about git internal, so it may look a little complex and scary, but it is really helpful to understand how git works.

-- Jean-Daniel

Yes, it more complex than svn. No doubt. I'm personally very happy with
the svn-git bridge - my only wish is it was updated more often.

The mirror is updated in the svn post-commit hook. How much often do
you want it updated? :wink:

Great! Since when? (haven't been TOT for a while)

SVN doesn’t require you to spend a lot of time learning it and adapting to its way of doing things. (The learning curve for SVN was small for me.

Git also doesn’t require you to spend a lot of time learning it and adapting to its way of doing things, if all you want to do is use the subset set of functionality that SVN provides. If you’re using Git to talk to a central repository and simply force all your pulls from that central repository to ‘rebase’ your changes so that they appear after what you pull down (this can be done by setting branch.autosetuprebase or branch.,rebase), your daily workflow is almost identical to SVN (checkin is split into two steps 1. commit locally, and 2. push to the central repo).

My initial (and subsequent) experiences with git are that it’s very, very complex. And it gets in the way of most things I want to do. I still don’t know what a “ref” or “object” is.)

This very short page explains these things relatively well. http://eagain.net/articles/git-for-computer-scientists/

The reality is that Git isn’t complex at all, although the man pages might make it look that way because most commands have many sub-options that can be used to achieve very specific behavior. The reality is that you can ignore 90% of most man pages, especially if you all you want to is have an SVN-like workflow.

I’ve heard this “SVN works great for my workflow” argument before (in fact recently), and if I go back 15 years I heard the “I don’t need SCM/VCS - my workflow of manually copying around back-ups works just fine.” from people working on small projects on their own. The reality is that I am skeptical that there is any good way to explain how much of a benefit you can get from Git or other DSCMs - it’s one of those things you have to experience for yourself to understand. I know that as I use Git more and more, I appreciate it more and more. I invested a little time up front and it has paid off many times over. I have found that my workflow has evolved with that appreciation. One of the key benefits of Git is that it allows you to separate check-pointing your work from publishing it, making it easy to make many small changes and back out of some/all of them trivially. It makes it trivial to separate out changes into different lines of development as well (bug fixes vs. feature A vs. feature B) without having to pull up an editor and copy changes across separate checkouts of a repository - it actually makes supporting the small-patches philosophy of LLVM reviews much simpler than with SVN, which turns doing these things into manual and error prone tedium.

Mark

More options.
Even if you don't need a different workflow, you have a better chance for any future workflow needs with git.

Also, git allows you to redact the version history. You can remove irrelevant old revisions - those that were awfully broken, or too embarrassing to allow to exist, or whatever. (It also allows you to merge the comments of the removed commits into the follow-up commit.)

The ability to commit offline. Work on your code in places that have no Internet access, committing away at will.
The commits will be synched with the public repository.

git preserves the history of each line of code, even as code is moved from one file to another.
With svn, refactoring means you lose the history of the code that moves to another file. If code moved files several times, reconstructing its history and the commit comment for each change can become cumbersome.

Just to name those points that have been most prominently debated in public.

Regards,
Jo

I wouldn't start with that presentation. It explains far too many of the gory details, you'd risk overlooking the forest because the trees are in the way.

For a concise bird's eye view of git internals, look at http://en.wikipedia.org/wiki/Git_(software)#Implementation .

A data model containing just four object types shouldn't scare anybody.
Particularly not anybody who knows about NFA->DFA conversion, LALR parsing, SSA, or register allocation.

Regards,
Jo

I am not very familiar with GIT so I have a question:
Let's say I don't fork and I work 1 patch at the time. Then what are
the advantages of GIT over svn?

No intent to start a flame war of any kind, but here is what I can come up with in two minutes based on my personal experience with both :

1. Speed. git diff r1 r2 works locally, svn diff r1 r2 talks to the server, more important for people far away from the servers.

2. git bisect to investigate regressions. That alone is worth a lot.

3. Ability to work in subteams and exchange patches efficiently before submitting the result to the larger community.

4. Ability to do commits at any time, no need for a network connection.

5. Ability to do "private" commits, e.g. your fix just works, but you realized there may be a better way, so you can save what you had and try something else.

6. Private branches / changes, e.g. added debug messages to help you understand this or that part of LLVM.

7. Confidence that the code you download from llvm.org has not been tampered with. kernel.org has recently been hacked, yet the Linux community knows there is no risk the Linux kernel code was changed, because *everybody* has an SHA1 hash of *every file* for *every version*.

8. A merge that (in my experience) is much smarter in hairy cases, e.g. detecting conflicts in subprojects.

9. Guaranteed continued access to the history of the project, even if llvm.org were to disappear (whether network glitch or asteroid)

10. Folks are switching from svn to git in droves, not the other way round.

Regards
Christophe

Francois Pichet <pichet2000@gmail.com> writes:

Because you're missing so much.

I am not very familiar with GIT so I have a question:
Let's say I don't fork and I work 1 patch at the time. Then what are
the advantages of GIT over svn?

Yes, the previous response was a bit too pithy.

You _do_ want to fork with git, in the sense of cloning a repository and
creating local branches. It requires a small shift in development
mindset but that shift will keep things much more organized, IME.

Here's a set of notes I've collected over the last year as I've
experienced using git in a production environment:

Places git can improve svn process