Pro tip: Sometimes it's easier to rewrite you're entire app rather than wrestle with git commands. /s
Oh Shit, Git?
141–150 of 275 posts
Re: Oh Shit, Git?
#142Reading these tips confirms that I'm too stoopid to use git.
Fortunately, I don't have to use git. So I just store work-in-progress as time-stamped files. Storage is cheap and plentiful. Can always diff, cherry pick, etc without confusing myself.
Re: Oh Shit, Git?
#143Earlier quoted context omitted.
The real "internal model" of git contains much more data/moving parts. There isn't one tree of commits, there are typically at least two: local and remote Branches are not just pointers to commits, but also possibly related to pointers in the other tree via tracking. Stash and index and the actual contents of the working directory are additional data that live outside the tree of commits. When op says "avoid git rese…
None of these seem to preclude a command to make an arbitrary branch point to an arbitrary commit without changing anything else.
You are looking for
git update-ref Re: Oh Shit, Git?
#144I’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.
Re: Oh Shit, Git?
#145I swear there used to be a choose your own adventure version of this where you could answer questions about what you did wrong and get a step-by-step "here's what to do" after.
Re: Oh Shit, Git?
#146I'm not a git user, but stuff like this really drives home the idea that "git commit" is meaningless, the only thing that matters is when your commits are pushed or merged. It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.
It seems painfully obvious to me that local and remote commits serve different purposes. Local commits are a way to create checkpoints when everything compiles and works and you can move on to the next step. That way you can stash your changes and go back to a working state when you screw things up. Then, before you push those changes, you reset them and split them into proper commits. That way the history is all nice and clean on the remote and it's not just a bunch of "wip"s.
Or you can just squash-merge your PRs and reap both benefits.
Re: Oh Shit, Git?
#147I’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 is the unquestioningly better tool right now. It's available, stable, battle-tested and it's actively supported. It's a case of "being the change you want to see". Just use it. Claims that it lost are counterproductive. The implicit deterrence from those statements is what is actively keeping Mercurial's adoption low.
Hosting is available at least from Sourcehut and heptapod.host.
I'm running a private Heptapod instance (Gitlab fork with direct Mercurial support). It just works.
Re: Oh Shit, Git?
#148Earlier quoted context omitted.
> 1. Always use `git switch` instead of `git checkout` Even harder: always use "git reset --hard". Basically don't use local branches. The correct workflow for almost every task these days is "all branches are remote". Fetch from remotes. Reset to whatever remote branch you want to work above. Do your work. Push back to a remote branch (usually a pull request branch in common usage) when you're done. If you need to m…
This sounds like the correct Git workflow if you think the correct VCS to use is SVN.
And that sounds like you failed to understand me. I didn't say "don't use branches". I said "all branches are remote". Pushing to a branch is communication with other human beings. Mixing your own private state into that is confusing and needless in 99% of situations (and the remaining 1% is isomorphic to "you're a maintainer curating branches for pushing to other people at a well-known location").
All branches are public.
Re: Oh Shit, Git?
#149I'm not a git user, but stuff like this really drives home the idea that "git commit" is meaningless, the only thing that matters is when your commits are pushed or merged. It's like saving a textfile. Do you write a little message every time you save a file? No that's silly. Just move on.
It seems painfully obvious to me that local and remote commits serve different purposes. Local commits are a way to create checkpoints when everything compiles and works and you can move on to the next step. That way you can stash your changes and go back to a working state when you screw things up. Then, before you push those changes, you reset them and split them into proper commits. That way the history is all nic…
Even better, `git merge --no-ff` your PRs and use `git log --first-parent` for the simplified "as-if-it-was-squashed" history.
Re: Oh Shit, Git?
#150Earlier quoted context omitted.
5. Teaching `git add .` as default to add changes to the staging area is not ideal. Show adding specific files instead has less room for subsequent "oh shit" and better.
True enough, but it does make for good practice with the index and splitting workflows later on when you need to clean it up. I think there's space for "git add ." as a didactic step. It maps cleanly to the most obvious way to understand a commit, as "here's what I've done". Bootstrapping from that to an understanding of "commits as communication with other developers" will naturally happen over time.
Is not very compatible with printlog-debugging. I'd rather encourage devs to prod around as they go if it benefits them, which causes grief for either them or reviewers in the end if they've internalized what you just said.
Explicitly adding internalizes a personal review process as inherent part of the push process, instead of something you attempt to force on top later.
It's better with a collaboration workflow that limits the span of time with expected discipline, imo.