this post was submitted on 14 Dec 2023
70 points (93.8% liked)
Programming
17443 readers
245 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
@mac Related: Why the SQLite team uses Fossil instead of Git https://sqlite.org/whynotgit.html
I am always doubtful when people say that accessing information inside git is hard. I totally agree that defaults in git can be improved (and they are,
git restore
andgit switch
are a much better alternative togit checkout
that I no longer use). So let’s review the section “A Few Reasons Why SQLite Does Not Use Git”:git log --graph --oneline --author-date-order --since=1week
Make it an alias if you use it often. Alias is what helps you create your own good default (until everyone uses the same alias and in that case it should be part of the base set of commands).
git log --graph --oneline --all --ancestry-path ${commit}~..
Likewise you could consider making it an alias if you use it often. Aliases can also be used as a post-it to help you remember what are the command that you find useful but you only use once in a blue moon!
I may agree about that one. For reference, this is what the article says:
If
git fetch
was run automatically every so often, as well asgit push
(of course in a personal branch), then this model could be simplified asAnd integrating your changes (merging/rebasing) should probably be exclusively done using a PR-like mechanism.
I’m skeptical about the usefulness of this. But since git was my first real vcs (10 years ago), it may just be that I have not used a workflow that took advantaged of persistant branches. I assume that
git annotate
could be a solution here.That’s absolutely true but I’m not sure it’s a real issue. Given how many strategies there are for CI/CD (and none is the definitive winner yet) I do think that being able to select the right option for you/your team/your org is probably a good idea.
I highly disagree about that xkcd comics. Git is compatible will all workflows so you have to use a subset of all the commands. Of course you will have more commands that you never use if a software is usable for all the workflow that you don’t use. But you need about 15 commands to do stuff, 30 to be fluent, and some more to be able to help anyone. Compared to any other complex software that I use I really don’t think that it’s an unreasonably high count. That being said I totally agree that git from 10+ years ago was more complex and we should correctly teach what is needed to junior. HTML/css/js is a nightmare of complexity but it doesn’t stop 15 years old kid with no mentoring to build cool stuff because you don’t need to know everything to be able to do most of the things you may think of, just a good minimal set of tools. And people should definitively take the time to learn git, and stop using outdated guide. Anything that don’t use
git switch
,git restore
andgit rebase --interactive
and presents you have to inspect the history in length (git log --graph
or any graphical interface that show the history in a graph,git show
, and more generally than you can filter the history in any way you want, being by author, date, folder, file type, …) is definitively not a good guide.To sum-up, I think that from this presentation fossil seems more opinionated than git which means that it will be simpler as long as your workflow exactly matches the expected workflow whereas using git requires to curate its list of commands to select only the one useful for yours.
I am in a perpetual wonderland of git confusion, but this was a good read. And maybe I now have a pathway to enlightenment.
If you try to learn git one command at a time on the fly, git is HARD. If you take the time to understand its internal data structure it's much, much easier to learn. Unfortunalely most people try to do the former because it works well (or better) for most tasks.
I can't recommand enough the git parable.
Thanks. I guess it's the perpetual problem of learning something new. Instead of starting at the beginning, we trick ourselves into thinking that we can skip the fundamentals. Then we have difficulty and think that the problem is one of complexity or just over our heads instead of our approach.
In fairness, sometimes it is useful to get hands on experience with a system before you dig into its fundamentals so that you have a reference point that helps you absorb the information.
https://learngitbranching.js.org Is a very accessible browser game that I found useful on my Git journey to start to grasp the underlying structures and operations such as rebase.