17 comments on "A data model for Git (and other docs updates)"
If you have a Mastodon or Fediverse account, you can reply to this post to leave a comment.
Optionally, set the Mastodon server for "Reply" links:
If you have a Mastodon or Fediverse account, you can reply to this post to leave a comment.
Optionally, set the Mastodon server for "Reply" links:
@b0rk Thanks a lot for the hard work! 🥰🥰
@b0rk I love your work, Julia! You are an inspiration.
(Been using git for 18? years. Subversion ams CVS before that)
@b0rk This is awesome, Julia. Thank you! I've not read the Git docs much over the years because they contain so much jargon. Your changes will help a *ton.*
@b0rk thanks for the shoutout :) :) :) and thanks even more for your contributions!!!
@nasamuffin really don't know if I could have done it without your help ❤ ❤
@b0rk Great work. This reads well and I am very happy to see progress on improving these docs in general. The Git docs tend to drive me mad and sometimes I even end up reading Git's code instead to find the answers I need.
I noticed that the distinction between author and committer is left somewhat unclear. Perhaps this was done on purpose? Could the difference even be described succinctly? I believe some git operations care about the difference while some other operations do not :flan_think:
@stsp yeah! I left it unclear because I don't fully understand the difference between author and committer, I don't know which Git operations care about it. I believe that `git rebase` will change the committer (but not the author)
@b0rk @stsp As far as I understand, author and committer are mostly relevant for projects, where change requests are approved and finally added by maintainers.
"The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit — you as the author, and the core member as the committer."
https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History
@b0rk thanks for working on this, it's great to see work on improving docs for such a well used tool.
I saw your email thread viewer used jwzthreading, and just in case it comes in handy - long ago I also wrote something using that, and there is a bug in that library that loops forever with some threads that end up having cycles. The original repo never got the fix, but I see there's a version at https://github.com/FreeDiscovery/jwzthreading that handles the case I found correctly.
@b0rk Near the end of the git-push page, under ``git push origin +dev:master'', the second diagram looks wrong to me.
@b0rk did you do this out of your own interest? Or do you have some kind of funding to do this work?
@ddbeck I funded all my own work on it, I took a break from doing normal Wizard Zines work for a bit
the experience made me curious about the open source docs funding landscape though, i’m going to watch the talk i saw on your site about resources
@b0rk thanks for explaining! Erin and I kinda glossed over where to get money in our talk. Google's Season of Docs was the only docs-specific funding program that I knew of, but it has sadly ended. Docs funding seems to come through weird one-off sources, or attached to new development work. I ought to write more about this phenomenon.
@ddbeck I’d love to read that, I was sad to hear Season of Docs ended
@b0rk thank you for doing this work. ❤️
@b0rk yes to more good docs! git becomes very easy once one "gets" the data model -- the tricky task becomes to figure out appropriate command to run to do something
@b0rk Thanks for the work of improving fundamental documentation for what is such an essential and widely used tool. I hope the work is not "thankless".