61–70 of 273 posts
And here is something to take the garbage quality of Git manpages with some humor https://git-man-page-generator.lokaltog.net/ "git-eliminate-head eliminates all downstream heads for a few forward-ported non-counted downstream indices, and you must log a few histories and run git-pioneer-object --pose-file instead. [...]"
Earlier quoted context omitted.
Yeah this would be great. I started working on adding support for .d/* in addition to a couple of years ago, that got to a proof-of-concept stage, but some of the long tail is hard to handle so I dropped it, but it could be finished. There was also a disagreement about what the semantics should be, e.g pre-receive.d/* hooks failing on the first one that failed in glob() order or not, which has implications for whethe…
Glob() is (iirc) not sorted in any way on macos. I would prefer alphanumerical sort by name as it is stable across OSs. Parallelization is optimization so I think «make it right, then make it fast» is sound advice.
In any case, even if glob() wasn't portable it's easy to provide an API compatibility layer that's just readdir() + qsort(). That part would be trivial, and might perhaps be needed due to collation issues in the sort.
Doing it in parallel (preferably in a random order) isn't just an optimization, but would ensure that there isn't an implicit dependency on whatever iterative interface we'd first ship with.
1. http://pubs.opengroup.org/onlinepubs/009695299/functions/glo...
2. https://developer.apple.com/library/archive/documentation/Sy...
I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2
When I was first learning git, I found an online visualizer like this [0] that really helped make make concrete the ideas of git history being a graph, and what different operations did on that graph. There was still obviously the issue of memorizing the commands, but at least I knew what the commands were doing on a deeper level. [0] https://learngitbranching.js.org/
I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2
That's a lot of reading for a tool that should be making life easier.
I disagree with this idea. The best way to learn git is to read the git book, in this order: chapters 1, 10, 2, 3, and the rest at your discretion. This way teaches you about the internals first, and if you understand the internals the rest of git is pretty intuitive. https://git-scm.com/book/en/v2
Earlier quoted context omitted.
> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…
Git’s workflow wouldn’t even be sane without the staging area. This is what allows you to fix mistakes and make your work presentable for remotes.
Earlier quoted context omitted.
So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…
I use it quite a lot, especially with `git add -p` to stage only parts of a file for an atomic commit.
Let's say you were commissioned to create a landscape painting. It'll be a big payday if you get it right and its due in 30 days.
Because you know you can make mistakes, you make a photo copy of your work every day and make a stack of them neatly on your desk. This photo copier is really high quality as copies are made at the molecular level.
On day 16, you find yourself working on the mountains in the picture. You sneeze and Oh no! You got paint all over your work. But since you have your copy pile, you just make another copy of day 15 and keep going.
But lets say you think its a lot and want a friend to work on the painting too. Just allow her to copy your latest photocopy and you both are off to the races!
Git seems complex but when you bring it down to a practical, non technical level, beginners pick it up faster :)