271–280 of 330 posts
> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze `git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.
You can't get simpler than that.
Earlier quoted context omitted.
My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentia…
Ok but the final outcome, most of the time, is a linear graph unless you're maintaining extremely long-lived branches for some reason. Setting practices so that linear graph will be easy to understand in history is still a good idea, no? I'm not religious about squash-merge on master but when I look at master's history, I'd expect each individual commit to have a good message and be releasable.
This is because of bisect. Bisecting broken commits doesn't work. Every commit should build.
In either case you should still rebase -i your branch as necessary to make it look clean when standing on its own.
is there a way to use it with lazygit? unfortunately I'm addicted atp, and "autorebase branches" is exactly what I was missing the entire time
I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.
> The UI of git - for better or worse - directly reflects its internals. I disagree. For example, we have, from “git checkout —help”: git checkout has two main modes: 1. Switch branches, with git checkout 2. Restore a different version of a file The first variant never loses changes you made that aren’t in git yet, the second is explicitly designed to revert them. How does that directly reflects git internals? (And o…
I've been doing regular significant re-writes to my local Git commit history with relative ease for over a decade even without this new Git command. I'm convinced that a big part of people often finding Git and rebase difficult is a user interface issue, having to know all the correct command line options and having to make your own mental model of what's happening and what you want to do, all makes it difficult to g…
(but I'm still really confused why VC++6 had some menu option that would create a folder-like shell object and open it in a file-open dialog instead of just using a listview like everyone else. It was some kind of "add component to project" wizard, and I'd always try to find that fake folder in My Computer while the dialog was open)
Earlier quoted context omitted.
> What's up with the fix commits? They shouldn't show up in the commit history. In a PR, you merge them in the commit that they actually fix. Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message that is worse than having nothing. Anyone can do better than a fixup commit. And doing metter means merging them into the actual commits that are fixe…
Hence GP's advice, > Just squash everything before merging and call it a day.
Earlier quoted context omitted.
[flagged]
You just did though… Maybe try and explain in more than one-sentence quips why you think git deserves its reputation? Otherwise you’re just coming off as a bit of a troll. Have a nice day.
But, his point is objective, so he doesn't need to provide subjective proof to you.
Do lots of people find git confusing? Yes. It is a very common view.
Therefore, based only on observed evidence, we can pretty confidently say that git is confusing. Is it as confusing as something else, or as confusing as the reputation? We can't tell, because those are subjective opinions.
The statement "it isn't as confusing as people think" is pretty meaningless here, because you can only judge from your own frame of reference. If it wasn't as confusing as people think, why do they think it is confusing? Are they all stupid?
Earlier quoted context omitted.
Depends what the git history is supposed to show. Personally, I prefer people to leave their mistakes and reversions - though I'd require more description messages than "oops" or "fix", something that explained why it was being reverted or swapped out would be the minimum. Sometimes you try things one way and they don't work out, so you go in a different direction. Capturing why this happened and when can go a long w…
One part of me wishes for multiple levels of logical commits. When using GH we essentially have one level. The PR is the like a roll-up commit and then we have the component commits it consists of. It would be nice to be able to say this commit consists of N component commits. Then users can expand or collapse the commits depending on what level of detail they want. So user A who likes to keep a record of how they ac…