Nothing is idiot proof, as people greatly underestimate the destructive power of a motivated idiot. =)
Idiot Proof Git
91–100 of 435 posts
Re: Idiot Proof Git
#92Just learn Git. It's really not that bad. Don't _ever_ make someone use Rebase without their understanding of what that really means.
Re: Idiot Proof Git
#93Earlier quoted context omitted.
My point wasn't that this strategy was the right one, but that having a clear strategy is more important. I personally prefer a more rebase-heavy approach, but what we had worked very well for us.
Oh definitely, a clear and enforced strategy and conventions are more important than anything.
Boundaries are equally important - a set of expectations in context is fine, letting people know there is a world outside your little ego-bubble is also important, them knowing how and when to live in both is valuable.
Re: Idiot Proof Git
#94Earlier quoted context omitted.
Why use force at all, on a default command?
my flow is (on my-branch with no one else's commits) * push some commits up to my remote branch * git fetch * git rebase master/main to get the latest stuff * add changes on my-branch that use new stuff from master/main * git push --force-with-lease to my remote branch - this fails if you don't use some version of force since my most recent commit is based on a commit (from master) not on the remote branch
I don’t get why everybody wants to rebase their topic branches. Just use merge, come on. If you want a „clean“ commit history on main/master do a squashed merge into main at the end.
This way we never had to force anything on the remote.
Re: Idiot Proof Git
#95This doesn't make git any easier. The synced and update commands are redundant. If you have
[pull]
rebase = true
Re: Idiot Proof Git
#96Just learn Git. It's really not that bad. Don't _ever_ make someone use Rebase without their understanding of what that really means.
It is worth the investment to learn advanced Git if you're a software engineer. Start by reading the Chacon book cover to cover. It is a major tool you use every work day, so it's important to understand it.
Re: Idiot Proof Git
#97Rebase should never be used. Or, if it is used, it should be treated as a dangerous thing to do that’s well outside the norm. Most of the arguments in favor of rebase are by people fanatical about having a git history organized just so. It’s not worth the headache and effort. PRs are a better unit of work than commits in practice. Configure GitHub or whatever you use to squash merge only and you’ll be good. Since mov…
So you're the one making me code-review 10000-line PRs because you just dumped your WIP branch — with three PRs' worth of code, plus formatting changes — directly into a PR, rather than factoring apart said WIP branch either during or after the fact.
The designed unit of a (distributed) git workflow is a patch — i.e. a locally rebase-squashed set of cherry-picked commits from development branches, with `git reset --soft` + `git add -p` (or even `git format-patch` + manual editing) used to prune the patch to a minimal size. Everything you do in your local repo should be with the intention of producing readable patches for code review (whether that patch is then done via PR or mailing list.) It's not about creating a pretty history (retroactive); it's about making it easy on the people who will discuss and reformulate your changes, one at a time, before accepting them upstream.
To be clear, you can do whatever you want when your git workflow isn't distributed (i.e. if you're committing to only your own private projects, not proposing changes to other people's projects.) But if your workflow isn't distributed, then why be opinionated about git? You can simplify your life at that point by using something with central-repo-oriented semantics, e.g. Subversion. There's no rebasing in Subversion. :)
Re: Idiot Proof Git
#98Earlier quoted context omitted.
At the end of the day everything depends on the organization. In a hectic startup where requirements change on an hourly basis and releases are made several times a day, I would absolutely insist on keeping the log linear and as clear as possible. Tags are important, of course, but they're not that useful for analyzing a repository. When I say "the evolution of the product" I really mean "the "evolution of the code".…
When I say "the evolution of the product" I really mean "the "evolution of the code". When a small feature branch with 5 commits - four of which say "wip" and the last one says "added color support" - gets merged as is, and all relevant information is held hostage by whatever Git platform the company is using this week and not inside the repository itself, the log is not useful to me regardless of any strategy. Yes,…
To be clear, what I'm advocating for is that feature branches get rebased regularly by the developer until PR-time and a clean merge into the mainline. I usually recommend squashing to one commit but do not insist.
I can definitely see how those intermediate commits can provide more information, but there's a tradeoff. More often than not, they do not provide me much value, and instead give me bloat, so I prefer to keep things simple.
Telling developers not to do something is like telling a kid not to push that red button. The average developer chooses what's easiest _right now_ and thinks it's someone else's job to fix the mess at PR time. And they're afraid, because that one time five years ago they ran a rebase without knowing what it does, and lost some code without knowing it's actually right there in the reflog, and since then they are deathly afraid of Git. I know how to use log and diff and all the others quite well, but most don't. So I'm trying to make things easier on everyone in the long term, not the short term.
Re: Idiot Proof Git
#99Just learn Git. It's really not that bad. Don't _ever_ make someone use Rebase without their understanding of what that really means.
Git like Regular Expressions I've "just learned" half a dozen times already but then forget everything and have to "just learn Git" top-to-bottom again and again.
It really is a shame, Git has a great under-the-hood design (excluding poor binary file support), and such a terrible interface/UX that seemingly can never be outright replaced, so we're stuck with a good tool surrounded by needless confusion forever.
Re: Idiot Proof Git
#100Rebase should never be used. Or, if it is used, it should be treated as a dangerous thing to do that’s well outside the norm. Most of the arguments in favor of rebase are by people fanatical about having a git history organized just so. It’s not worth the headache and effort. PRs are a better unit of work than commits in practice. Configure GitHub or whatever you use to squash merge only and you’ll be good. Since mov…
How do you lose data from a rebase?