9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dave MacFarlane <driusan@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] git client-ish
Date: Sat,  3 Dec 2016 21:14:52 -0500	[thread overview]
Message-ID: <CAG2UyHpykpiCu0xVZeJee25coV-HdxXk1sgpQWTiyHkmAcGSjw@mail.gmail.com> (raw)
In-Reply-To: <10F39B2A-21CA-4A95-905D-9F89067A8BBD@gmail.com>

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 <newton688@gmail.com> 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 <driusan@gmail.com> 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



  reply	other threads:[~2016-12-04  2:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-03 19:20 Dave MacFarlane
2016-12-03 20:05 ` Bakul Shah
2016-12-04  1:12 ` Chris McGee
2016-12-04  2:14   ` Dave MacFarlane [this message]
2016-12-05 17:14   ` Dave MacFarlane
2016-12-05 18:49     ` Chris McGee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAG2UyHpykpiCu0xVZeJee25coV-HdxXk1sgpQWTiyHkmAcGSjw@mail.gmail.com \
    --to=driusan@gmail.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).