The docs just say to sort by C locale (byte-order sorting). Easy. Except git was sometimes rejecting my packfiles as being bogus per its fsck code, saying my trees were misordered.
TURNS OUT THERE'S AN UNDOCUMENTED RULE: you need to append an implicit forward slash to directory tree entry names before you sort them.
That forward slash is not encoded in the tree object, nor is the type of the entry. You just put the 20 byte SHA1 hash, which is to either a blob or a hash (or a commit for submodules).
So you can have one directory with directory "testing" and file "testing.md" and it'll sort differently than a directory with two files "testing" and "testing.md".
You can see a repro at https://gist.github.com/bradfitz/4751c58b07b57ff303cbfec3e39...
(So to verify whether a tree object is formatted correctly, you need to have the blobs of all the entries in the tree, at least one level)
The way I found out was that Github kept rejecting my push, because as I later discovered, my git history was invalid precisely due to entries being sorted improperly due to the forward slash requirement. I could have solved this with the real git, but the point was to use my tool exclusively for version control from inception, so I just deleted the .git folder. So, my git history appears to begin near the end of the whole cycle. But I did manage to learn a lot, both about git and about the language I implemented it in.
But... git doesn't really store directories, does it?
Turns out that Git does somewhat store dirs (in form of trees). See https://git-scm.com/book/en/v2/Git-Internals-Git-Objects (section "Tree Objects").
To understand op's repro look at the last two lines (objects in the tree) in each of their command outputs, not the files shown in the first few lines.
What I think op means is that the `testing` tree pointed in their first example is sorted after `testing.md` even though it's only called `testing` because it's being sorted as `testing/` and `/` is > `.` bytewise.
I'm not at a computer right now but it would be nice to test it with files named `testing.` and `testing0` since they are adjacent bytewise and would show the implicit forward slash more clearly with the tree object sitting between them.
This makes me wonder why Git can't just store an empty tree for empty dirs.
EDIT: did the Gist https://gist.github.com/alvaro-cuesta/bd0234e3e1a66819c7e9e9...
Notice the `git cat-file -p HEAD^{tree}` outputs.
tl;dr: it can (see my other comment) and the empty tree is hardcoded. But since the index works with file paths and blobs, having no file means that there's no entry in the index
You can run `git commit --allow-empty` with an empty index and the root tree will be the empty tree:
$ git init
$ git commit --allow-empty -m foo
$ git rev-parse @^{tree}
4b825dc642cb6eb9a060e54bf8d69288fbee4904
$ git init
$ git commit-tree -m foo 4b825dc642cb6eb9a060e54bf8d69288fbee4904
$ tree .git/objects # you'll see that there's no file for the empty tree
Projects like gitoxide have been in development for years now.
I know JJ used to use Git2 for a lot of network operations like pushing and pulling, but ran into too many issues with SSH handling that they've since switched to directly invoking the Git binary for those operations.
Heck, had my PS1 return an error this week after I created a separate working dir for a repo and cd'd into it. Did you know .git can be a normal file? I didn't when I wrote my PS1.
I think Github and most big Git hosts use it
(gitoxide is a similar project but in Rust, it's not ready for the big time either, though it keeps on getting better!)
While new functionality can be implemented on top of this stable base. It doesn't surprise me that it's hard to re-implement all of git, including the network protocols, but that's a different thing than the core
This thread has some good info about the core, including the tree encoding issue brought up by bradfitz, but it still seems to be approximately true ... e.g. perhaps compared to hg
I also remember that JGit is a very complete re-implementation of git, done by a git core dev, and used in Android infrastructure, etc. This was well over 10 years ago at this point, maybe 15
Failing to find a write-up, but there was this lobster thread[0] where someone from GitLab reported they had to do the same owing to some discrepancies vs the binary -where all of the real development happens.
If you like this, I also recommend "Write Yourself a Git", where you build a minimal git implementation using python: https://wyag.thb.lt/
Please, consider making the layout better for us old coders whose eyes are going, or for hi res displays
(The much-less-well-known mobile double-tap-on-text gesture [it zooms-to-fit whatever element you tapped on to the width of the viewport] was also ported to desktop browsers. Though, on desktop with a touchpad, it's a two-finger double-tap — which I don't think anyone would ever even think to try.)
But also, under further investigation — and unlike with pinch-to-zoom — desktop support for the two-finger double-tap gesture seems to be specific to macOS. (Which is weird, because Chrome has support for arbitrary multitouch gesture processing to enable the JS multitouch API. So you'd think Chrome's support for "the multitouch gestures the OS expects" would be built on top of that generic multitouch recognizer [and therefore working everywhere that recognizer works], instead of expecting the OS to pre-recognize specific gestures and translate them to specific OS input events.)
On my Ubuntu laptop in Chrome, I couldn’t find a way to make it work - even tapping the touchscreen didn’t work. But I’m not using the stock Ubuntu GUI, so it could be that (LXqt+XMonad).
I'm very confused, can you clarify what makes this different from the gesture that highlights text?
Edit: it appears that "request desktop site" makes it fit the viewport, whereas using the mobile view it's I guess already fitting the viewport so it highlights the text. The strange thing is in the desktop view, if I pinch zoom after fitting the viewport and do it again, it zooms out, whereas the mobile view still highlights the text. Which kinda makes sense, since mobile view it's fairly likely that you zoomed in to highlight the text more accurately, though it's weird that it's so inconsistent.
This would help with large binary assets without having to deal with the mess that is LFS, as long as the assets were uncompressed.
Ahhhhahahaha… “user friendly”. When compared to coding the repo by hand, I guess.
I asked a few git hosting providers, and they all said they had private APIs developed internally for the purpose.
Absolutely NOT going there again.
* points at numerous scars and trauma
[span style="--0:#E1E4E8;--1:#24292E"] [/span]
Anyways, I started on Mercurial, and I think it has a better UX, but technically I now prefer Git. The success of Mercurial over Git surprised me a little because of that, Git is not an easy version control system to get into, at least when compared to Mercurial, it shouldn't help adoption, but I guess it is just because some big names decided on Git.
Mercurial and Git use the same fundamental principles, and one is not really better than the other, just details.
git was created to scratch an itch (actually a bit of a roiling boil, that needed a serious amount of soothing ointment and as it turns out: a compiler, some source code and quite a lot of effort). ... anyway the history of it is well documented.
FFS: git was called git because a Finnish bloke with English as a second, but well used, tongue had learned what a "git" is and it seemed appropriate. Bear in mind that Mr T was deeply in his shouty phase at that point in time.
Artisanal git sounds all kinds of wrong 8) Its just a tool to do a job and I suggest you use it in the same way as the XKCD comic mandates (that is the official manual, despite what you might think)
The Conclusion is spot on - great article.