271–280 of 281 posts
Earlier quoted context omitted.
You can check out multiple branches in different directories from a single git repo. This saves me a lot of what used to be stashing.
I’d be interested to hear more about your workflow I’ve thought about doing similar things, but it just seems like too much overhead.
Earlier quoted context omitted.
In my career, it has already happened more than once. And definitely not deliberately. There are many ways this can happen accidentally. You could be trying to checkout a branch and tab complete your way into a folder name instead. You could be typing alt/esc + . with the intent of getting last argument of previous bash command, keyboard glitches and you end up with . instead. Just because it hasn’t happened to you y…
No question this design is questionable and I'm glad I learned about it before falling victim of it. I read that they introduced git-switch and git-restore as a way to avoid such pitfalls. But. I once messed up badly with something else once, makefiles. I was kind of overconfident and end up screwing myself by telling something to write its output to my source files by mixing up $ Fool me once, shame on the tool; foo…
Earlier quoted context omitted.
No question this design is questionable and I'm glad I learned about it before falling victim of it. I read that they introduced git-switch and git-restore as a way to avoid such pitfalls. But. I once messed up badly with something else once, makefiles. I was kind of overconfident and end up screwing myself by telling something to write its output to my source files by mixing up $ Fool me once, shame on the tool; foo…
[flagged]
Earlier quoted context omitted.
No. There are leaves that aren't heads (for example, after you delete a branch, the old commits just lie around until someone deliberately cleans them up), and there are heads that arent' leaves (for example if you branch a new feature branch from main. The feature branch brances off of main, so main is not a leaf anymore)
> The feature branch brances off of main, so main is not a leaf anymore) But "main" remains a "head" even though the feature branch "continues the graph" from it? So there must be a difference between "Adding a new commit" and "Branching a new commit". I think I got it now. Thanks
Earlier quoted context omitted.
Git commits always have a parent. Applying git patches to a repository without the parent is not going to work. The repository must have the parent commit. You might force it to work without that but it's going to create conflicts, complicate merging, etc. The reason is that a git patch is not merely a diff but an export of the actual commit objects and referred content (trees, blob diffs, hashes, etc.). Applying the…
> Applying git patches to a repository without the parent is not going to work. If that's the case (and I'm not saying it isn't - I really don't know), how does cherry-pick work? I know I can cherry-pick commits in the same repo from entirely separate commit chains, where the only common ancestor is either my local HEAD or some other commit way below both of us. Why would that not work for different repositories?
Earlier quoted context omitted.
When the workspace and the staging area aren’t in sync, the differences cannot be tested because the compiler doesn’t know how to deserialize the .git/index blob. The workspace is stored as normal source files, and committing those would be better.
That would remove a huge amount of flexibility from the commit process, though. git add -p (and its siblings) are a huge part of my workflow. I often work on multiple changes at once, but break them out into their own atomic commits with the ‘-p’ flag. What would be great is a simple way to have build/lint/etc. tools look at the staging area instead of the workspace.
Earlier quoted context omitted.
That would remove a huge amount of flexibility from the commit process, though. git add -p (and its siblings) are a huge part of my workflow. I often work on multiple changes at once, but break them out into their own atomic commits with the ‘-p’ flag. What would be great is a simple way to have build/lint/etc. tools look at the staging area instead of the workspace.
For what it’s worth, I didn’t have much trouble switching from “git add -p” for changes I want now to “git stash -p” for changes I want later.
Earlier quoted context omitted.
I have to serious ask. Of the people who have issues with using or understanding git, how many of them have actually read the docs? Git is by no means perfect but the development community is great and there is a massive focus on improving the project and making things more approachable and intuitive. And because of that, git actually has really solid, coherent documentation with easily digestible tutorials and guide…
Git makes version control roughly 10x more complicated than it needs to be. I can teach an artist or designer who has never heard of version control how to use Perforce in roughly 5 minutes. They will never blow off their leg and will likely never lose work. It will probably be a few months before they hit some edge case where they need help. Git requires building a non-trivial mental model. Then it requires memorizi…
I went to a short, semi-casual digitization symposium. It was a couple hours long with a handful of lightning talks and a keynote. All the presenters were researchers in the humanities versed in the subject matter of e.g. library science. I later learned that the university had recently introduced an "open source program office" that's supposed to be a resource for crossing the discipline divide. The idea is that the progress that the world of software development is making should leak into other disciplines to the extent that it can be helpful. There's a course in the School of Information taught by a programmer that tries to do something similar: people with domain expertise are supposed to take the course to pick up a little bit of programming and get exposure to Git to help with e.g. data science projects.
In thinking about how the material would hypothetically be presented to these folks, I realized that the humanities folks in particular were uniquely positioned to be able to grok Git the best—almost certainly better at grasping the underlying fundamentals than, say, a group of freshman programmers with no experience with version control, Git or otherwise. Programmers lack the foundation and interest in the underlying discipline.
Earlier quoted context omitted.
> Applying git patches to a repository without the parent is not going to work. If that's the case (and I'm not saying it isn't - I really don't know), how does cherry-pick work? I know I can cherry-pick commits in the same repo from entirely separate commit chains, where the only common ancestor is either my local HEAD or some other commit way below both of us. Why would that not work for different repositories?
It still uses the notion of a common parent to merge a single commit. Works as long as there are no conflicts. As to why that would or would not work, I refer to the git internals section of the Git book. Great stuff. But they are not performing any dark magic here.