Before learning magit on emacs, this site saved my ass so many times. After learning magit on emacs, this site saved my ass so many times.
Oh Shit, Git?
201–210 of 275 posts
Re: Oh Shit, Git?
#202Earlier quoted context omitted.
> but not if it's checked out ...and for a good reason that should be apparent to anyone who understands git's model (HEAD points to a ref in this case, so if you suddenly change what that ref points to without updating the working tree you create an inconsistency). You can do that manually of course (with `git update-ref` or even a text editor), but then you get to clean up the mess yourself.
Couldn't head just detach without any consistency issue?
Theoretically it could, but that would be a rather surprising side effect. You could also check the new revision out and leave HEAD intact. Which one of those outcomes you would expect and why?
"error: ref in use by higher layers" makes much more sense to me in this case.
Re: Oh Shit, Git?
#203Earlier quoted context omitted.
Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth. It is its own footgun as well, but with git you can git init any directory you want and have a repo. Other than the learning curve of the not particularly well tuned CLI (and there are all sorts of graphica…
>Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth. Many years ago, SVN worked fine for me for single-user projects. I just made my own desktop be the server. But I wasn't publishing my code back then (it's not as if I would have have any effective way to t…
Around the period I might have adopted SVN I recall it was a huge pain, if not impossible, to install on a Windows desktop; I tried multiple times, failed at each attempt, and eventually gave up. I was also in some labs at the time where we weren't allowed RDP to personal machines or services, or the lab machines just weren't great at it, or both (depending on the exact type of lab class and how worried the professor was of plagiarism), and mostly only had access to dumb sftp systems during the labs. That's when I discovered and fell in love with darcs. Distributed source control is great. Source control that you can push changes to/from the dumbest file systems is a super power. (Just the other year, even, I was using git and a dumb folder share to move source control changes to and from a VM that was firewalled from any network traffic because it had to be.) I miss some of the smarts of darcs still somewhat regularly having adjusted to this timeline where git won handily, but I'm not going back to a centralized source control system and git is "good enough" most of the time.
Re: Oh Shit, Git?
#204We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.
What the average amount of time until something goes wrong that can't be fixed in the UI?
Re: Oh Shit, Git?
#205I’m pumped a search for hg+mercurial had hits in this thread. I am and will continue to be completely blown that hg lost the dvcs wars. It’s a better tool.
It's the slower tool.
Re: Oh Shit, Git?
#206This will feel very weird in April 2025, when we celebrate the 20th anniversary of git. I was there. And at some point I wondered if I should learn git, darcs, or bazaar, to replace SVN or CVS. Or did I try mercurial too ? I wonder if the "GitHub" effect has basically killed the need for a newcomer in the space of VCS. Maybe at some point, the yak is shaved enough ?
Any improvement will have to be git compatible at the very least, e.g. jj.
Re: Oh Shit, Git?
#207Some changes I would make: 1. Always use `git switch` instead of `git checkout` 2. Avoid `reset --hard` at all costs. So for the "accidentally committed something to master that should have been on a brand new branch" issue, I would do this instead: # create a new branch from the current state of master git branch some-new-branch-name # switch to the previous commit git switch -d HEAD~ # overwrite master branch to th…
What do you mean avoid "reset --hard"? Why or why is it not enough in practice? I use it quite often, along with "alias git-restore-file='git restore --source=HEAD --'". It seems to work.
Re: Oh Shit, Git?
#208Earlier quoted context omitted.
Rewriting these for jj users. I'm prefering long option names and full command names for clarity here, but all the commands have shortened aliases and all the option names have single-letter alternatives. `@` means "the current revision", `x+` means "the revision just after `x`", `x-` means "the revision just before `x`". 2. "Accidentally committed something to master that should have been on a brand new branch". Thi…
One thing I really appreciate is that you can run `jj new master` at _any_ time to drop what you're doing and start a new change. The way jj handles the working copy, conflicts, and visible heads means there's just no need to think about uncommitted changes, unfinished conflict resolution, detached head, etc.. So many things that would get in your way just can't happen.
I haven’t thought about it at all but you’re right. It’s surprising how nice it is that I can enter a repo and `jj new main` without needing to remember any context whatsoever.
My post was a pretty naked attempt to showcase how much less convoluted basic operations are in jj vs. git and hopefully drum up some interest. Hopefully someone bites.
Re: Oh Shit, Git?
#209We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.
What the average amount of time until something goes wrong that can't be fixed in the UI?
For me, once a year and I have to use the reflog. But using a GUI is so much faster and safer that I won't change. Mercurial and Jujutsu have good command-lines, why can't git do the same?
Re: Oh Shit, Git?
#210I’m pumped a search for hg+mercurial had hits in this thread. I am and will continue to be completely blown that hg lost the dvcs wars. It’s a better tool.
That sounds interesting. Does anyone have a GitHub link?