[9fans] git client-ish
I mentioned in another thread that I had started working on a pure go git client a while ago, then abandoned it, which gave me an itch to pick it up again. I've finally implemented enough that it can bootstrap its own development, and theoretically be used on Plan 9, but then I realized I don't currently have any machines with all of Plan 9, Go, and a network connection to test it on. Would someone who has all of the above kindly try compiling it on Plan 9 and let me know if there's any problems? It's at https://github.com/driusan/go-git.You'll need the 9legacy git rc hack for Go to bootstrap it.. You should be able to: go-git init go-git clone* go-git fetch* go-git add file (from the root of the working directory only) go-git checkout file (same) go-git commit -m 'message' go-git status go-git merge (fast-forward only) go-git push works over https to GitLab, but not GitHub (GitHub responds with "200 OK" and no body but doesn't update the references, so I opened a ticket to see if I can get more information from them about why it doesn't work.. you also need to run as "go-git push localbranchname", which isn't the standard git command line.. ) The happy paths for a few other git plumbing commands are implemented. The code's not very well written (I didn't know much about git internals or Go when I started, and mostly just wanted to hack something together that works at first), but if anyone wants to contribute, you can try to email me a patch using ape/diff in some kind of format that I can apply under DragonFlyBSD and commit under your name until whatever the issue with GitHub is is resolved.. * large repositories will likely crash because the Go zlib implementation is greedy on the underlying io.Reader, and the hack that I added to rewind to the end of the last compressed block when reading packfiles isn't 100% accurate. - Dave
Re: [9fans] git client-ish
> On Dec 3, 2016, at 11:20 AM, Dave MacFarlane wrote: > > I mentioned in another thread that I had started working on a pure go > git client a while ago, then abandoned it, which gave me an itch to > pick it up again. I've finally implemented enough that it can > bootstrap its own development, and theoretically be used on Plan 9, > but then I realized I don't currently have any machines with all of > Plan 9, Go, and a network connection to test it on. > > Would someone who has all of the above kindly try compiling it on Plan > 9 and let me know if there's any problems? It's at > https://github.com/driusan/go-git.You'll need the 9legacy git rc hack > for Go to bootstrap it.. > > You should be able to: > go-git init > go-git clone* > go-git fetch* > go-git add file (from the root of the working directory only) > go-git checkout file (same) > go-git commit -m 'message' > go-git status > go-git merge (fast-forward only) > go-git push works over https to GitLab, but not GitHub (GitHub > responds with "200 OK" and no body but doesn't update the references, > so I opened a ticket to see if I can get more information from them > about why it doesn't work.. you also need to run as "go-git push > localbranchname", which isn't the standard git command line.. ) > > The happy paths for a few other git plumbing commands are implemented. > > The code's not very well written (I didn't know much about git > internals or Go when I started, and mostly just wanted to hack > something together that works at first), but if anyone wants to > contribute, you can try to email me a patch using ape/diff in some > kind of format that I can apply under DragonFlyBSD and commit under > your name until whatever the issue with GitHub is is resolved.. > > * large repositories will likely crash because the Go zlib > implementation is greedy on the underlying io.Reader, and the hack > that I added to rewind to the end of the last compressed block when > reading packfiles isn't 100% accurate. > > - Dave >
Re: [9fans] git client-ish
Thanks for the tool. I managed to get it working on plan9front/386 Go 1.8 beta1 with a network connection. I will probably try it soon on plan9/arm. Initially, it did not compile. Here are the quick fixes that I needed to make. 1) There is no syscall.Stat_t on plan9, instead the stat.Sys() returns a syscall.Dir index.go:AddFile(): I changed stat to be fstat.Sys().(*syscall.Dir) csec = stat.Mtime (This is how APE maps ctimes) cnano = uint64(0) (There does not seem to be any nanosecond precision on mtimes in plan9) uint32(stat.Qid.Path) (Roughly equivalent to inode numbers) uint32(0) (GID’s are strings in plan9) uint32(0) (UID’s are strings) I assume that you want the library to be platform neutral so these should probably be abstracted. 2) Compile error sha1.go:GetTree() Sha1FromString(commit.Tree.Id.String()) The tests seem to be passing. I will try more rigorous tests. If the github bug gets fixed then I can submit pull requests. Cheers, Chris > On Dec 3, 2016, at 2:20 PM, Dave MacFarlane wrote: > > I mentioned in another thread that I had started working on a pure go > git client a while ago, then abandoned it, which gave me an itch to > pick it up again. I've finally implemented enough that it can > bootstrap its own development, and theoretically be used on Plan 9, > but then I realized I don't currently have any machines with all of > Plan 9, Go, and a network connection to test it on. > > Would someone who has all of the above kindly try compiling it on Plan > 9 and let me know if there's any problems? It's at > https://github.com/driusan/go-git.You'll need the 9legacy git rc hack > for Go to bootstrap it.. > > You should be able to: > go-git init > go-git clone* > go-git fetch* > go-git add file (from the root of the working directory only) > go-git checkout file (same) > go-git commit -m 'message' > go-git status > go-git merge (fast-forward only) > go-git push works over https to GitLab, but not GitHub (GitHub > responds with "200 OK" and no body but doesn't update the references, > so I opened a ticket to see if I can get more information from them > about why it doesn't work.. you also need to run as "go-git push > localbranchname", which isn't the standard git command line.. ) > > The happy paths for a few other git plumbing commands are implemented. > > The code's not very well written (I didn't know much about git > internals or Go when I started, and mostly just wanted to hack > something together that works at first), but if anyone wants to > contribute, you can try to email me a patch using ape/diff in some > kind of format that I can apply under DragonFlyBSD and commit under > your name until whatever the issue with GitHub is is resolved.. > > * large repositories will likely crash because the Go zlib > implementation is greedy on the underlying io.Reader, and the hack > that I added to rewind to the end of the last compressed block when > reading packfiles isn't 100% accurate. > > - Dave >
Re: [9fans] git client-ish
Yeah, someone already pointed out those two problems off-list. There should be a fix committed. It turns out that none of the stat(3) information that git dumps into the index is really required (just the mtime and size, which you can get from the os.FileInfo), so the best cross-platform fix is probably to just set the things you had to change to 0. The Go syscall package also seems to do some weird things like using different field names in its Fstat struct on different platforms, so is best avoided. The sha1 thing is just because I forgot to commit something. (and I'm not sure that "tests" is appropriate to pluralize in this context. There's only one, and it's.. not rigorous.) On Sat, Dec 3, 2016 at 8:12 PM, Chris McGee wrote: > Thanks for the tool. > > I managed to get it working on plan9front/386 Go 1.8 beta1 with a network > connection. I will probably try it soon on plan9/arm. > > Initially, it did not compile. Here are the quick fixes that I needed to > make. > > 1) There is no syscall.Stat_t on plan9, instead the stat.Sys() returns a > syscall.Dir > > index.go:AddFile(): > I changed stat to be fstat.Sys().(*syscall.Dir) > csec = stat.Mtime (This is how APE maps ctimes) > cnano = uint64(0) (There does not seem to be any nanosecond precision on > mtimes in plan9) > uint32(stat.Qid.Path) (Roughly equivalent to inode numbers) > uint32(0) (GID’s are strings in plan9) > uint32(0) (UID’s are strings) > I assume that you want the library to be platform neutral so these should > probably be abstracted. > > 2) Compile error > > sha1.go:GetTree() > Sha1FromString(commit.Tree.Id.String()) > > The tests seem to be passing. I will try more rigorous tests. If the github > bug gets fixed then I can submit pull requests. > > Cheers, > Chris > > On Dec 3, 2016, at 2:20 PM, Dave MacFarlane wrote: > > I mentioned in another thread that I had started working on a pure go > git client a while ago, then abandoned it, which gave me an itch to > pick it up again. I've finally implemented enough that it can > bootstrap its own development, and theoretically be used on Plan 9, > but then I realized I don't currently have any machines with all of > Plan 9, Go, and a network connection to test it on. > > Would someone who has all of the above kindly try compiling it on Plan > 9 and let me know if there's any problems? It's at > https://github.com/driusan/go-git.You'll need the 9legacy git rc hack > for Go to bootstrap it.. > > You should be able to: > go-git init > go-git clone* > go-git fetch* > go-git add file (from the root of the working directory only) > go-git checkout file (same) > go-git commit -m 'message' > go-git status > go-git merge (fast-forward only) > go-git push works over https to GitLab, but not GitHub (GitHub > responds with "200 OK" and no body but doesn't update the references, > so I opened a ticket to see if I can get more information from them > about why it doesn't work.. you also need to run as "go-git push > localbranchname", which isn't the standard git command line.. ) > > The happy paths for a few other git plumbing commands are implemented. > > The code's not very well written (I didn't know much about git > internals or Go when I started, and mostly just wanted to hack > something together that works at first), but if anyone wants to > contribute, you can try to email me a patch using ape/diff in some > kind of format that I can apply under DragonFlyBSD and commit under > your name until whatever the issue with GitHub is is resolved.. > > * large repositories will likely crash because the Go zlib > implementation is greedy on the underlying io.Reader, and the hack > that I added to rewind to the end of the last compressed block when > reading packfiles isn't 100% accurate. > > - Dave > > -- - Dave