Git as a version control system?
Hi all, I was wondering if we should be moving to git as our version control system. I really like the fact that git's repository is stored on the local disk. It also appears that git makes it easier for developers to contribute patches. Could anybody confirm or care to share their experiences with git? Is there anyone against using git? BR -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
I really value tool support; the Maven & Subversion combination has really only just reached maturity on Eclipse with Subversive and M2Eclipse integrating properly and allowing you to check a Maven project out from Subversion and have M2Eclipse sort out your classpath and project structure for you with no further input. This (for me at least) dramatically reduces the barrier to entry and makes me vastly more inclined to pull down a project and have a look under the hood, and maybe get involved. An admittedly cursory check of the net suggests that git does not integrate so well with M2Eclipse (there's no mention of it on the M2Eclipse site or wiki). On 6 Aug 2009, at 20:04, Ceki Gulcu wrote:
Hi all,
I was wondering if we should be moving to git as our version control system.
I really like the fact that git's repository is stored on the local disk. It also appears that git makes it easier for developers to contribute patches. Could anybody confirm or care to share their experiences with git? Is there anyone against using git?
BR
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
Hi Robert, While I agree that tool support around git is still lacking, given its rising popularity, tool support will eventually follow. From what I know, it is possible to keep an SVN repository synchronized with a git repository. Thus, during a transitional period (which may last several years), we could publicize both an SVN and a git repository. My question is then whether moving to git is worth the trouble and whether it will encourage contributions by making it easier for developers to contribute. From a strictly personal point of view, the fact that git works in disconnected mode is a killer feature. Robert Elliot wrote:
I really value tool support; the Maven & Subversion combination has really only just reached maturity on Eclipse with Subversive and M2Eclipse integrating properly and allowing you to check a Maven project out from Subversion and have M2Eclipse sort out your classpath and project structure for you with no further input. This (for me at least) dramatically reduces the barrier to entry and makes me vastly more inclined to pull down a project and have a look under the hood, and maybe get involved. An admittedly cursory check of the net suggests that git does not integrate so well with M2Eclipse (there's no mention of it on the M2Eclipse site or wiki).
On 6 Aug 2009, at 20:04, Ceki Gulcu wrote:
Hi all,
I was wondering if we should be moving to git as our version control system.
I really like the fact that git's repository is stored on the local disk. It also appears that git makes it easier for developers to contribute patches. Could anybody confirm or care to share their experiences with git? Is there anyone against using git?
BR
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu skrev:
My question is then whether moving to git is worth the trouble and whether it will encourage contributions by making it easier for developers to contribute. From a strictly personal point of view, the fact that git works in disconnected mode is a killer feature.
Since you are the project leader, and the primary committer, I believe you should do whatever you think allows you to be more efficient while still allowing others to provide patches. I agree with Robert that good tooling is essential. Sun have chosen Mercurial due to its distributed feature so Netbeans will have good Mercurial support. Since git is written by Thorvalds who apparently do have zero interest in the Java community, I believe the tooling will be at best mediocre. In my experience changing source repository platform is similar to changing operating system. Not something you do everyday. (and we still use CVS at work, since the benefits of good tools strongly overshadow the deficiencies of CVS ... for us!). -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
On 07.08.2009, at 10:30, Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
My question is then whether moving to git is worth the trouble and whether it will encourage contributions by making it easier for developers to contribute. From a strictly personal point of view, the fact that git works in disconnected mode is a killer feature.
Since you are the project leader, and the primary committer, I believe you should do whatever you think allows you to be more efficient while still allowing others to provide patches.
I agree with Robert that good tooling is essential.
There is a Java implementation of git available at http:// www.jgit.org/ so I guess tooling (Maven, Eclipse) is really just a question of time. The current IDEA is already supporting git. I've never used GIT beside checking out a repository but I have only heard praise from people that are using it regularly. For Windows, http://code.google.com/p/tortoisegit/ seems to do a pretty good job. For Mac OS X there's a tool called GitX http://gitx.frim.nl/ but I haven't tried it yet. Looks promising. You can find a seemingly very good book on GIT at http://progit.org/book/ - reading it is still pretty high on my TODO list. I'd like to encourage that you give it a try - that way I have to do the same ;) Joern.
Joern Huxhorn skrev:
On 07.08.2009, at 10:30, Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
My question is then whether moving to git is worth the trouble and whether it will encourage contributions by making it easier for developers to contribute. From a strictly personal point of view, the fact that git works in disconnected mode is a killer feature.
Since you are the project leader, and the primary committer, I believe you should do whatever you think allows you to be more efficient while still allowing others to provide patches.
I agree with Robert that good tooling is essential.
There is a Java implementation of git available at http://www.jgit.org/ so I guess tooling (Maven, Eclipse) is really just a question of time. The current IDEA is already supporting git.
I've never used GIT beside checking out a repository but I have only heard praise from people that are using it regularly. For Windows, http://code.google.com/p/tortoisegit/ seems to do a pretty good job. For Mac OS X there's a tool called GitX http://gitx.frim.nl/ but I haven't tried it yet. Looks promising.
You can find a seemingly very good book on GIT at http://progit.org/book/ - reading it is still pretty high on my TODO list.
I'd like to encourage that you give it a try - that way I have to do the same ;)
He he, pacing yourself through pacing others. I have never used GIT either, but the reputation of Linus Thorvalds alone makes it considerable. Personally I do not have any preferences, and I believe the most important factor is making Ceki as productive as possible. I just say that this is very important software and it is a non-trivial task to change, so it should not be taken lightly. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
On 07.08.2009, at 12:48, Thorbjoern Ravn Andersen wrote:
Joern Huxhorn skrev:
On 07.08.2009, at 10:30, Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
My question is then whether moving to git is worth the trouble and whether it will encourage contributions by making it easier for developers to contribute. From a strictly personal point of view, the fact that git works in disconnected mode is a killer feature.
Since you are the project leader, and the primary committer, I believe you should do whatever you think allows you to be more efficient while still allowing others to provide patches.
I agree with Robert that good tooling is essential.
There is a Java implementation of git available at http://www.jgit.org/ so I guess tooling (Maven, Eclipse) is really just a question of time. The current IDEA is already supporting git.
I've never used GIT beside checking out a repository but I have only heard praise from people that are using it regularly. For Windows, http://code.google.com/p/tortoisegit/ seems to do a pretty good job. For Mac OS X there's a tool called GitX http://gitx.frim.nl/ but I haven't tried it yet. Looks promising.
You can find a seemingly very good book on GIT at http://progit.org/book/ - reading it is still pretty high on my TODO list.
I'd like to encourage that you give it a try - that way I have to do the same ;)
He he, pacing yourself through pacing others.
Yep :)
I have never used GIT either, but the reputation of Linus Thorvalds alone makes it considerable. Personally I do not have any preferences, and I believe the most important factor is making Ceki as productive as possible. I just say that this is very important software and it is a non-trivial task to change, so it should not be taken lightly.
I absolutely agree. However, Ceki can try it out locally and will still be able to use SVN side-by-side. A co-worker in my company is using it that way. We have SVN as our main repository and he is working on local GIT repositories that are committed to SVN when he thinks his code is ready. It *has* some very nice features, I must admit... e.g. Stashing http://progit.org/book/ch6-3.html Joern.
Joern Huxhorn skrev:
However, Ceki can try it out locally and will still be able to use SVN side-by-side. A co-worker in my company is using it that way. We have SVN as our main repository and he is working on local GIT repositories that are committed to SVN when he thinks his code is ready. Are you saying that git can resynchronize back to subversion? *THAT* is an interesting feature.
Could you let us know the experiences of your cow-orker? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
On 07.08.2009, at 13:55, Thorbjoern Ravn Andersen wrote:
Joern Huxhorn skrev:
However, Ceki can try it out locally and will still be able to use SVN side-by-side. A co-worker in my company is using it that way. We have SVN as our main repository and he is working on local GIT repositories that are committed to SVN when he thinks his code is ready. Are you saying that git can resynchronize back to subversion? *THAT* is an interesting feature.
Could you let us know the experiences of your cow-orker?
This is described here: http://progit.org/book/ch8-1.html Concerning experience: he said that it is mostly painless but it can get a bit ugly if merging is needed on the SVN side. GIT seems to perform much better in that discipline... This is also described in the above link. Joern.
Thorbjoern Ravn Andersen wrote:
Ceki Gulcu skrev:
My question is then whether moving to git is worth the trouble and whether it will encourage contributions by making it easier for developers to contribute. From a strictly personal point of view, the fact that git works in disconnected mode is a killer feature.
Since you are the project leader, and the primary committer, I believe you should do whatever you think allows you to be more efficient while still allowing others to provide patches.
Although I find git's disconnected mode of operation valuable, I'm also risk-averse and afraid of new things. So I am looking for reasons to tip the balance in favor of git so as to overcome my fears. Facilitated collaboration would be an important justification in my mind. It appears that git encourages (by making very easy) project forks and to publicize the forked results. I can somehow imagine why this would encourage contributions but would also like to hear from others.
I agree with Robert that good tooling is essential.
Sun have chosen Mercurial due to its distributed feature so Netbeans will have good Mercurial support. Since git is written by Thorvalds who apparently do have zero interest in the Java community, I believe the tooling will be at best mediocre.
Git has attracted developers beyond Linus. So his disinterest in Java should not play a major role. As for Sun, they have not been very apt at collaborating with others outside Sun. While this may change in the future, Sun has surprisingly little influence in the tools that the average Java developer uses. The mere fact that people still talk about git speaks volumes about the quality of git because Linus is an awful advocate for git. The git presentation he gave at Google is embarrassingly inappropriate. See http://www.youtube.com/watch?v=4XpnKHJAok8
In my experience changing source repository platform is similar to changing operating system. Not something you do everyday.
Once a decade maybe. :-)
(and we still use CVS at work, since the benefits of good tools strongly overshadow the deficiencies of CVS ... for us!).
Interesting point. I guess a similar reasoning applies to migrating from log4j to logback. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu skrev:
Since you are the project leader, and the primary committer, I believe you should do whatever you think allows you to be more efficient while still allowing others to provide patches.
Although I find git's disconnected mode of operation valuable, I'm also risk-averse and afraid of new things. So I am looking for reasons to tip the balance in favor of git so as to overcome my fears. Facilitated collaboration would be an important justification in my mind. It appears that git encourages (by making very easy) project forks and to publicize the forked results. I can somehow imagine why this would encourage contributions but would also like to hear from others.
I think you should set your goals straight. A low threshold is important for others to switch from users of distribution jars to tweaking source and build the resulting jars themselves, so the amount of pain needed to go through should be minimal. A good example is Glassfish 2 which is close to impossible to get to build as the supported build environment is arcane and hard to set up. If you want to have another source repository system, so be it, and just do it, since you appear to basically have convinced yourself :D If you want to encourage more collaboration and contributions, I believe this is not primarily a technical issue, but more a question of community building. This has proven to be very hard. Linus and Apache have done so. Sun have failed for most of their open source products. For logback it appears that there are around 10 active individuals on the developer list.
The mere fact that people still talk about git speaks volumes about the quality of git because Linus is an awful advocate for git. The git presentation he gave at Google is embarrassingly inappropriate. See http://www.youtube.com/watch?v=4XpnKHJAok8
I will give it a look sometime later - for now I accept your word for it.
In my experience changing source repository platform is similar to changing operating system. Not something you do everyday.
Once a decade maybe. :-) Yes. No need to hurry the issue. Personally I would not change unless there was a killer feature which made a LOT of difference.
At work our primary problem with CVS is the inability to rename files and keep the history. The rest is minor things. That alone is not enough to warrant switching, but we have considered more than once to switch to Subversion.
(and we still use CVS at work, since the benefits of good tools strongly overshadow the deficiencies of CVS ... for us!).
Interesting point. I guess a similar reasoning applies to migrating from log4j to logback.
No. Those things are very different. The logging platform is "just" a component of applications, which happen to throw stuff to disk - most people stay with the default appenders etc. [1] The source repository is the "operating system" of the source code, and changing that influences the work of all developers. We have not fully switched from log4j to logback, but we switched to slf4j to solve the usual log4j + commons logging problem while keeping log4j. After figuring out that log4j is essentially in maintainance mode after the logback fork, and that jdk14 logging is basically frozen (plus hard to configure externally), we decided that for now we use logback as the logging platform. So, the abstraction quality of slf4j is the primary reason why switching logging platforms is a lesser pain than switching source repositories :) [1] Our situation is not quite typical. Our production platform does not allow for debuggers or profilers, and most issues are frequently not reproducable in test. Hence I am investigating using logging as a forensic tool and less a "all is well" tool. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
If you want to encourage more collaboration and contributions, I believe this is not primarily a technical issue, but more a question of community building. This has proven to be very hard. Linus and Apache have done so. Sun have failed for most of their open source products. For logback it appears that there are around 10 active individuals on the developer list.
Maybe not 10. I believe that any number of participants equal to or higher than 2 is already a good beginning. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu skrev:
If you want to encourage more collaboration and contributions, I believe this is not primarily a technical issue, but more a question of community building. This has proven to be very hard. Linus and Apache have done so. Sun have failed for most of their open source products. For logback it appears that there are around 10 active individuals on the developer list.
Maybe not 10. I believe that any number of participants equal to or higher than 2 is already a good beginning.
Well, as far as I know you have Robert and Jörn who is actively submitting code patches. So you have your good beginning :) Regarding how to encourage newcomers to submit code, I do not have any immediate suggestions. Others? Jörn, have you received submissions for Lilith? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
I've glanced at git but never used it. I've read that it is more complicated than SVN because it works very differently. I have enough interest in logback that I'd probably do what it takes to get access to the source but I imagine there are others who wouldn't if setting it up is more difficult than just installing a bit of software. I'm not 100% sure what the real benefit would be. Ultimately the code needs to be committed back to logback. How would using git make it easier? Would we be able to commit somewhere that would allow you to commit stuff to the "real" repository? Ralph On Aug 7, 2009, at 6:54 AM, Ceki Gulcu wrote:
If you want to encourage more collaboration and contributions, I believe this is not primarily a technical issue, but more a question of community building. This has proven to be very hard. Linus and Apache have done so. Sun have failed for most of their open source products. For logback it appears that there are around 10 active individuals on the developer list.
Maybe not 10. I believe that any number of participants equal to or higher than 2 is already a good beginning.
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
Ralph Goers wrote:
I've glanced at git but never used it. I've read that it is more complicated than SVN because it works very differently. I have enough interest in logback that I'd probably do what it takes to get access to the source but I imagine there are others who wouldn't if setting it up is more difficult than just installing a bit of software.
My impression is that some time in the future, git will be added to the list of software that any os developer will be required to know, similar to CVS or SVN today. Time will tell. Anyway, for "legacy developers", we could continue to export into an SVN repo.
I'm not 100% sure what the real benefit would be. Ultimately the code needs to be committed back to logback. How would using git make it easier? Would we be able to commit somewhere that would allow you to commit stuff to the "real" repository?
That's an excellent question. If git is better at merging and creating forks is easy, Alice could fork logback, work on our branch for a few days or even a few weeks, committing many changes to her forked repository. She could later publicize her repository for others to study. If her changes are deemed interesting, they could be imported back into the "official" logback repository. This is similar to the workflow that would take place on the SVN, except that Alice would not be able to commit her changes locally and nor would she be able to publicize her repository. She would be constrained to patch files. The difference is admittedly subtle but subtle differences sometimes can make all the difference (but most often they don't).
Ralph -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
Ceki Gulcu skrev:
That's an excellent question. If git is better at merging and creating forks is easy, Alice could fork logback, work on our branch for a few days or even a few weeks, committing many changes to her forked repository. She could later publicize her repository for others to study. If her changes are deemed interesting, they could be imported back into the "official" logback repository. This is similar to the workflow that would take place on the SVN, except that Alice would not be able to commit her changes locally and nor would she be able to publicize her repository. She would be constrained to patch files.
Ceki, I believe you are so fascinated with the technical capabilities of git, that you may be a bit blinded. What you describe is what a full blown committer would do, not a contributor who would have to undergo peer review before changes was accepted. In such a scenario changes would happen to be small and atomic to allow acceptance/rejection on an individual basis instead of a large monolith of code changes. You may remember that Apple built their Safari browser with the KHTML component from KDE, and their changes was contributed in huge chunks instead of with collaboration between the teams. This did not work well. See e.g. The bitter failure named "safari and khtml" -- http://www.kdedevelopers.org/node/1002 I believe for collaboration to work well, you should avoid forks as much as possible, so your scenario will actually be counterproductive as the technology gets in the way. But again, as I have said before, you are the leader of this project and can choose to do whatever you want. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
On Aug 7, 2009, at 7:55 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
I'm not 100% sure what the real benefit would be. Ultimately the code needs to be committed back to logback. How would using git make it easier? Would we be able to commit somewhere that would allow you to commit stuff to the "real" repository?
That's an excellent question. If git is better at merging and creating forks is easy, Alice could fork logback, work on our branch for a few days or even a few weeks, committing many changes to her forked repository. She could later publicize her repository for others to study. If her changes are deemed interesting, they could be imported back into the "official" logback repository. This is similar to the workflow that would take place on the SVN, except that Alice would not be able to commit her changes locally and nor would she be able to publicize her repository. She would be constrained to patch files.
This is the part I don't get. First, I doubt too many people would be publishing their repositories, at least for the world to see. I could see doing it in my organization where I may need to create my own changes until they are incorporated into the main code base, but frankly I want that to happen as quickly as possible (and you have been very good about that).
What does "imported back into the official logback repository" mean? You aren't going to get access to my repository because it would be behind firewalls. I was under the impression git made it possible to push stuff somewhere where you would be able to pick and choose what you want.
Supposedly this forking and merging is supposed to be the main advantage of git, yet I've never gotten anyone to sufficiently explain it so that my feeble mind can actually grasp what the work flow looks like.
Ralph
Ralph Goers wrote:
Supposedly this forking and merging is supposed to be the main advantage of git, yet I've never gotten anyone to sufficiently explain it so that my feeble mind can actually grasp what the work flow looks like.
Here is an attempt at explaining the workflow: http://blog.discursive.com/2009/08/couchdb4j-is-case-in-point-for-git-and.ht...
Ralph
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
On Aug 7, 2009, at 10:17 AM, Ceki Gulcu wrote:
Ralph Goers wrote:
Supposedly this forking and merging is supposed to be the main advantage of git, yet I've never gotten anyone to sufficiently explain it so that my feeble mind can actually grasp what the work flow looks like.
Here is an attempt at explaining the workflow: http://blog.discursive.com/2009/08/couchdb4j-is-case-in-point-for-git-and.ht...
The only thing in that post that makes it "different" is that the workarea where he did the patch is in a public location instead of on his local disk. Since IntelliJ keeps a local history of all my edits even the version control aspects of creating the new repository don't add much value. Since the blog entry doesn't discuss how his changes made it back into the "real" repository I still don't know what advantages this brings. The disadvantage is that there is now a new repo with forked code that apparently isn't going to be merged back into the mainline since he "didn't have to stop and figure out community dynamics" and "if the person who maintains the original project finds my changes interesting, he or she can pull them into his own". Does git automatically point you to every forked repository and magically tell you what they are trying to do there? I'm not saying git might not be a good thing. I just don't understand how it is really supposed to work so all these wonderful benefits everyone talks about actually happen. Ralph
Ralph Goers wrote:
Ceki wrote: Here is an attempt at explaining the workflow: http://blog.discursive.com/2009/08/couchdb4j-is-case-in-point-for-git-and.ht...
The only thing in that post that makes it "different" is that the workarea where he did the patch is in a public location instead of on his local disk.
Yes but that's not the whole story.
Since IntelliJ keeps a local history of all my edits even the version control aspects of creating the new repository don't add much value.
In Eclipse, unless I am mistaken, the local history extends to the current Eclipse session. The local history functionality offered by an IDE is simply no match to the functionality offered by a fully-fledged version control system. Dot. (I wrote Dot instead of Period because the latter is devoid of any humor.)
Since the blog entry doesn't discuss how his changes made it back into the "real" repository I still don't know what advantages this brings.
No immediate advantage but read on.
The disadvantage is that there is now a new repo with forked code that apparently isn't going to be merged back into the mainline since he "didn't have to stop and figure out community dynamics" and "if the person who maintains the original project finds my changes interesting, he or she can pull them into his own". Does git automatically point you to every forked repository and magically tell you what they are trying to do there?
Good question. The answer can be found at http://github.com/mbreese/couchdb4j/tree/master , the the original tree that Tim forked. If you click on the icon with the 3 branches, you'll be taken to http://github.com/mbreese/couchdb4j/network where you can actually see Tom's changes. In light of the above, Tim's statement about "if the person who maintains the original project finds my changes interesting, he or she can pull them into his own" makes a lot of sense. I also like the fact that his motivation was limited to personal utility (scratching his own itch) but the end result is potentially increased community/global utility. Also note that he has 5 distinct commits each of which is separately available from github. As a project maintainer, I find it much more convenient to look at smaller chunks of changes instead of one big patch. The fact that one can easily follow his changes is quite appealing and should facilitate the integration of his changes into the main tree.
I'm not saying git might not be a good thing. I just don't understand how it is really supposed to work so all these wonderful benefits everyone talks about actually happen.
I was also wondering if git was merely the hype-du-jour. This critical discussion indicates that there is some added value in git. Adopting git will not increase the IQ of contributors nor of the project maintainer, but it will make interaction between various participants a bit easier. Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
I suppose I don't really see the version control system as the major problem in the situation where you have some personal requirement that you could solve by forking an open source project. If I wanted to fork say logback and use my fork in a production system I would see the major problems as: 1) Having somewhere reliable to make the binary available in the long term, when I'm no longer on the project - does the organisation have a stable and long lasting Maven repository that's in everyone's settings.xml? Or am I going to have to force everyone to build it themselves and install it into their local Maven repository? Because obviously the Maven central repository can't possibly be polluted with forks of every library by every man and his dog. I would be worried that one day someone would be trying to build the project and swearing because the pom requires logback-classic-my-custom-version-1.0.0.jar and it's nowhere to be found. 2) Ease of upgrade - will I be making it a nightmare if they ever want to upgrade to a later version of logback? After all, some critical security risk or unusual but to them disastrous bug might make it absolutely vital for them to do so, and then they have to worry about merging the changes somehow in a way that keeps everything working properly... ouch. 3) Developer knowledge - am I going to be making all the web based reference material if not actually useless, at least so suspect that future developers on the project no longer trust anything they read about it on the web and waste considerable time verifying it? Am I going to confuse the hell out of the guy who thought he "knew" logback but now finds I've made several subtle but important changes? By forking you change the position of the any project that uses the fork of the library from one of client (albeit community supported) of the software to that of developer/maintainer of the software, which is a big and potentially very expensive decision. Those are the reasons I wouldn't fork even when there are areas I might like to - using an "official" version just makes life so much easier in the long term. Having said all of which, it's just occurred to me that the one major benefit of the Git approach as outlined in that link is that it fulfils the requirement of many non-GPL open source licenses immediately - the changes are available to the whole world, and at no maintenance cost to the forker - the fork is available via the repository maintained by the primary development team. That's certainly a big win. Anyway, if the plan was to maintain subversion alongside it until Git had comparable tool support that would remove my main concern immediately. Rob On 7 Aug 2009, at 18:17, Ceki Gulcu wrote:
Ralph Goers wrote:
Supposedly this forking and merging is supposed to be the main advantage of git, yet I've never gotten anyone to sufficiently explain it so that my feeble mind can actually grasp what the work flow looks like.
Here is an attempt at explaining the workflow: http://blog.discursive.com/2009/08/couchdb4j-is-case-in-point-for-git-and.ht...
Ralph
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ logback-dev mailing list logback-dev@qos.ch http://qos.ch/mailman/listinfo/logback-dev
Ceki Gulcu skrev den 07-08-2009 16:55:
My impression is that some time in the future, git will be added to the list of software that any os developer will be required to know, similar to CVS or SVN today. Time will tell. Anyway, for "legacy developers", we could continue to export into an SVN repo.
Hi Ceki. We - at my work - have reached the point where we need to replace CVS with something better, so I am basically going through the same thoughts that you are. Did you reach a decision on migrating to git? If so, when? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
Thorbjørn Ravn Andersen wrote:
Ceki Gulcu skrev den 07-08-2009 16:55:
My impression is that some time in the future, git will be added to the list of software that any os developer will be required to know, similar to CVS or SVN today. Time will tell. Anyway, for "legacy developers", we could continue to export into an SVN repo.
Hi Ceki.
We - at my work - have reached the point where we need to replace CVS with something better, so I am basically going through the same thoughts that you are.
Did you reach a decision on migrating to git? If so, when?
Hello, I really like git and am glad to have migrated. It has several features that stand out: - local repo The git repo is local which means that you can work for days without an internet connection. A killer feature if there is one. - Blazingly fast. Sometimes, Git completes an operation so quickly that I re-execute it just to make sure that my command was executed. - Distributed Git allows you to coordinate your work with several repos As far as I am concerned, Git is just a better SVN. Cheers, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
On Sep 22, 2009, at 2:57 AM, Ceki Gulcu wrote:
As far as I am concerned, Git is just a better SVN.
The part I don't like really has nothing to do with Git. Where some of us used to have commit rights to the master repo for SLF4J now, as far as I can tell, only you do. That's true of logback as well. While that may be great for you it kind of sucks for the rest of the world. With SVN you were sort of forced into at least providing some commit rights since it really sucked not to have any place to commit code. Ralph
participants (6)
-
Ceki Gulcu -
Joern Huxhorn -
Ralph Goers -
Robert Elliot -
Thorbjoern Ravn Andersen -
Thorbjørn Ravn Andersen