1. 64

“Got uses Git repositories to store versioned data. At present, Got supports local version control operations only. Git can be used for any functionality which has not yet been implemented in Got. It will always remain possible to work with both Got and Git on the same repository.”

  1.  

  2. 10

    I would say a subset of git is simple to use.

    I’m personally looking forward to pijul world domination. It absolutely is not ready today, but when it is…there will be no reason to use anything else besides for legacy reasons.

    1. 3

      pijul wouldn’t be appropriate here as it’s GPL’ed.

      1. 5

        Well, so is git. I don’t know what Stefan is doing, but unless he’s doing a clean-room reverse engineering of the git storage formats (and this isn’t easy; the packfiles in particular are not very well documented by git), his work is also likely to be derivative of git.

        1. 4

          Clean room reverse engineering is overkill in most jurisdictions, as reverse engineering for compatibility purposes is often expressly allowed. Reading the GPL source of git to understand its internals doesn’t necessarily taint any code that you write with its license.

          1. 6

            Are you a lawyer? Can I rely on your opinion to avoid legal risk?

            I think it would be reallllly weird for the git copyright holders to create a big stink over it (hell, most Linux copyright holders refuse to ascertain their copyleft), but I don’t know which jurisdictions you’re talking about and the FSF has told me, that when working on Octave, clean-room reverse engineering is what I should be doing.

            Different circumstances, of course, but still, if it could happen to Octave, it could happen with git.

            1. 10

              For virtually everything I needed to know but didn’t, I asked questions to both the current and former maintainers of libgit2 who are friends of mine.

              Copyleft (i.e. copyright) cannot protect ideas. I have read some Git code to figure out how pack files work because this isn’t documented anywhere else in sufficient detail. Not a single line of code was copied. Feel free to compare my pack parser to Git’s. You will find they’re not derived works of each other by any stretch of the imagination. They deal with the same on-disk format of course, so naturally they will parse identical inputs and (hopefully) produce identical outputs, like any Java API function in different JDK implementations ;-)

              I feel legally safe here and would feel confident to hire the gplviolations.org laywer again if needed (I have hired him before for unrelated stuff).

              1. 3

                The FSF lawyers made it very clear that we shouldn’t read Matlab code, but the situation there is different, with a much more hostile relationship. If you’re friends with the libgit devs, it seems unlikely they would ever complain.

                When the gloves come off, avoiding copyright violations isn’t just about making sure things look different. And even APIs are a bit uncertain right now with the Google v. Oracle case.

                1. 7

                  But.. “making things look different” is not what I did at all :-(

                  1. 2

                    I’m pretty sure it doesn’t matter since nobody is going to sue over this, but if you read the libgit code and you used structures, variable names, or anything else that looks like it could suggest that you read the libgit code, they could argue derivative work. I don’t know what you did. But if you read code, it’s hard to not unconsciously copy some of the structure of that code into your own work.

                    I mean, look at the current Katy Perry case. They successfully argued copyright infringement over some superficial similarities and the high probability that Katy Perry was familiar with the infringed work.

                    1. 3

                      I respect the decision of Git’s authors to release their code under GPL and I would never copy any code without keeping its licence intact.

                      To be frank, I think this line of thinking where free software projects could sue each other over copyleft/non-copyleft licencing after having read each other’s code is silly and dangerous. I would hope that FSF lawyers you are talking to wouldn’t support this.

                      The problem with Octave/Matlab you’re describing looks like a policital battle being faught with lawyers who are advising you as an Octave developer in that particular situation. I don’t see how this could possibly be related to my situation.

                      1. 3

                        The FSF has never sued anyone and I can’t imagine they would ever sue a free project that didn’t keep the copyleft terms – they would probably just argue that the copyleft terms apply regardless. The FSF has done all of its GPL compliance without ever going to court – and they do a lot of it. They talk to people until they come into compliance. Their goal is compliance, not any monetary damages.

                        This whole thing is quite academic. Again, you are almost certainly in the clear. Personally, if I relied on GPLed work to write software of my own, I feel morally obligated to make my own work copyleft, but if you feel no such compunction, I don’t think you need to do anything further.

                        The Octave/Matlab thing I describe relates to the nature of what has been tested in court before. We never gone to court over Octave, but if we ever do, we want to make sure we can win. Therefore, we do not read Matlab code, even though a lot of it is available.

              2. 2

                Are you a lawyer? Can I rely on your opinion to avoid legal risk?

                No.

                but I don’t know which jurisdictions you’re talking about

                EU and US are ones I’m aware of that permit RE for interoperability purposes.

                1. 2

                  To be honest even if they were a lawyer, one should not rely on internet discussion as legal advice or opinion. Lobsters may be informative but it is primarily discussion for entertainment. If you are genuinely concerned with legal risk you should seek proper legal counsel.

          2. 2

            Why is pijul not ready?

          3. 7

            I hope they get the UX right, git sure failed on that.

            But for simple, sane version control [0] fossil pretty much solves that problem. It doesn’t use Git, or use Unveil/Pledge, but it’s pretty safe and sane and is BSD(2-clause) licensed. It can import/export to Git, so one can interact with the git world if one chooses.

            0: https://www.fossil-scm.org

            Regardless, it will be interesting to see what comes of this, and what it means for longer-term OpenBSD sources.. will they move off of CVS someday?

            1. 29

              (Game of Trees author here)

              I haved used Fossil for some projects, mostly OpenBSD driver projects. Fossil is good for small projects and I have successfully used it to overlay local versioning for selected files on top of a CVS checkout, which not many VCS will do as painlessly as Fossil does. It is also the only well-known version control system I’m aware of with a licence that would be accepted into OpenBSD base (BSD-like, ISC preferred).

              But when I attempted a full conversion a few years ago, Fossil simply did not scale to the size of OpenBSD’s source tree. I did try to convert the OpenBSD repo from CVS via git to fossil (which was the officially recommended way of migrating from CVS to Fossil at the time, which is probably still the case today). I aborted Fossil’s import of git’s fast-export stream after several days(!) at which point it was done with history between 1995 and 2000, with at least 10 more years of history to go through. This was the performance I saw after I had already hacked Fossil to batch multiple commits into a single sqlite transaction, instead of using one sqlite transaction per commit (sqlite is not optimized to run many transactions per second, see https://sqlite.org/faq.html#q19).

              Fossil has its own particular design goals for its own particular niche (sqlite development with issue tracking and wiki tooling built-in).

              Got is meant for another niche (OpenBSD developers) and as such it is not meant to be a drop-in replacement for Git. At present it just provides a small but convenient subset of what Git can do on a local repo. It already serves my own OpenBSD development needs better than Fossil ever did.

              1. 3

                Thanks for the reply!

                It’s great that you tried Fossil. I haven’t ever tried it on a large repo. Sad that it couldn’t handle it very well. Days to import is definitely a bad sign for what every day use might be like. SQLite has ~ 20 years of history in it now, so I would guess it’s more just the size of the OpenBSD repo that’s the issue here, not really the history. OpenBSD despite being small in size for an OS, is way larger than SQLite.

                I wish you luck on the project! I might give it a try as a better way to interact with Git.

                1. 1

                  NetBSD has been doing conversion from CVS to Fossil since 2011, and it supposedly only took under 5 hours in 2011 to convert NetBSD CVS to Fossil, so, it’s not exactly clear why OpenBSD couldn’t be converted in several days.

                  In fact, NetBSD repository is known for having pretty crazy branching allowances, both for release engineering and for lots of user-initiated feature-branches, which are prohibited in OpenBSD, so, if anything, I’d expect the NetBSD repository to be far more complex and nuanced than OpenBSD as far as conversion needs are concerned.


                  https://2011.eurobsdcon.org/papers/sonnenberger/fossilizing.pdf
                  § 4.6 Performance

                  The run time for the conversion process on an Opteron 1389 (Quad-core, 3 GHz) with a RAID-1 of two 7200rpm SATA disks with 4GB memory is as following:

                  • CVS import — 34min
                  • Vendor branches — 4min
                  • Branch creation time — 24s
                  • Fossil import — 3h 56min

                  http://wiki.netbsd.org/mailing-lists/tech-repository/

                  We have a successful conversion from cvs to fossil since ~mid 2011, mostly thanks to the work of Jörg Sonnenberger.

                2. 6

                  It looks like a more CVS-ified Git, which I think allows the CVS metaphors (which may be more user-friendly depending on your experience) to coexist with a real Git repository. I’m liking what I’m seeing on the man page: https://gameoftrees.org/got.1.html

                  1. 2

                    ooh, I missed the man page. I agree, looks pretty nice.

                    1. 2

                      The got man page seems to be missing an easy way to apply a diff was created with got diff and send to the mailing list. At least I didn’t see anything in the example section about it.

                      Maybe they plan to defer to git am for that?
                      Everything implies this is still a work-in-progress, so maybe it just hasn’t be done yet.

                    2. 2

                      I hope they get the UX right, git sure failed on that.

                      What major gripes do you have with git’s UX?

                      1. 5

                        One could argue: is there any UX? :P

                        But really you generally need to understand all the inner workings of git to successfully use the git command line. Tools should make your life easier. git generally makes your life harder, until you expend the time and energy to really understand all of git. svn, hg, fossil, etc all generally make your life easier. Git was created to make Linus’s life easier, which I’m sure it does very well, but basically nobody has his level of problems when it comes to VCS. Most people would be better served with something semi-idiot proof like mercurial, fossil or svn.

                        There are tons of blogs and pages around that spam endlessly around the horribleness of git’s user experience. This is but one[0]:

                        0: https://stevebennett.me/2012/02/24/10-things-i-hate-about-git/

                        Also I’ll just add, when basically every developer conference has talks about how to survive with git in your life, and these talks have been going on for years, with no end in sight, I think it’s fair to say, git has failed UX.

                      2. 1

                        git sure failed on that

                        Of course it failed there as Linus created Git with bare minimum tooling and hoped that there will be other UI implemented by community. Instead it organically grew to what it is today and bazaar style development isn’t the best for UX. There were projects like Easy Git but these are long gone.

                        1. 3

                          I agree with your history. LOL on bazaar style being terrible on UX(I agree). Even Microsoft has failed at UX sometimes. One could argue that UX hasn’t really changed very much since Xerox PARC days. when the mouse and the “desktop metaphor” was created.

                          1. 2

                            UX on mobile is arguably new.

                          2. 1

                            TortoiseGit on Windows (and other Tortoise stuff for other repositories) is pretty cool.

                        2. 4

                          Why not join forces with opengit?

                          1. 9

                            Well, opengit describes itself as a clone of Git, which Got is not, so that’s probably why not.

                            1. 10

                              Farhan already has commit access to Got. But he hasn’t used it much yet.

                          2. 4

                            Along with the plan 9 adaptation (git as a filesystem, of course), git starts to become a rather universal storage format for versioned code.

                            I guess that you can always openrsync that got-created repository to get early remote support.

                            1. 4

                              We are aware of each other (we were bouncing ideas at the Ottawa hackathon).

                              I also have access to the GoT repository. I think that if I have time, I will be transplanting some code over between GoT and git9. We are ahead of each other in different areas (I started with the network protocol, @stsp started with local repository manipulation), so we can take ideas and code in both directions.

                              That said, the implementation style is very different, so it’s unlikely that the code can be directly shared.

                            2. 2

                              Oh good, maybe FreeBSD will end up using this too

                              1. 2

                                There was a time when lots of people wrote such git porcelain. I have not found a good list though.

                                Here is one which also lists a few others: https://people.gnome.org/~newren/eg/

                                1. 4

                                  This is not a git porcelain, it is an implementation of git plumbing. No git code here.

                                2. 2

                                  If you think of Git as a graph editing tool rather than a VCS, all operation makes sense.

                                  Now you might or might not want to think of the code base as a graph.

                                  1. 9

                                    The semantic operations make sense. The UI/UX exposed to do those operations does not. The confusion around git’s interface isn’t because it’s a graph editing tool. It’s because it uses inconsistent naming, inconsistent flags, and almost zero safety net.