Just learn Git. It's really not that bad. Don't _ever_ make someone use Rebase without their understanding of what that really means.
[deleted]
Idiot Proof Git
111–120 of 435 posts
Re: Idiot Proof Git
#112Rebase 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…
[deleted]
Re: Idiot Proof Git
#113.gitconfig:
[alias]
add-commit = !git add -A && git commit
function save ()
{
git add-commit -m "$*" && git push
}
$ save This is a commit message
Also:
alias mkpr='git push && gh pr create -d -f -B develop | grep https | xargs printf -- '%s/files' | xargs open'
Merge upstream changes from develop:
alias mduc='CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD) && git checkout develop && git pull && git pull --tags && git checkout ${CURRENT_BRANCH} && git merge develop'
Re: Idiot Proof Git
#114Earlier quoted context omitted.
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.
I rebase on my topic branches because then my edits are neatly stacked on top of the other branch, so I can re-arrange things more easily. Why would I want a weird commit with a bunch of work I didn't do on the topic just smooshed into the middle of my well-crafted series of commits?
Re: Idiot Proof Git
#115Earlier quoted context omitted.
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.
Why would you have to force anything with rebase? you rebase your feature branch against main to rewind it on top of it and clean up history so you can do a clean fast forward merge. Squashing is bad for anything non trivial, you want small independent commits: easy to review, easy to revert, easy to blame if something goes wrong.
Re: Idiot Proof Git
#116Rebase 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 --s…
If you regularly need to review 10000 lines of code per PR your dev workflow is seriously broken. It‘s got nothing to do with git and its implementation‘s complexity.
Sometimes features do require large changes. But usually you can break a feature into different parts (e.g. database, backend, frontend) and merge them in separately.
Re: Idiot Proof Git
#117[deleted]
Doesn't happen ime. I understand how it works (more or less) and still struggle with its CLI. It was created by aliens with photographic memory and non-associative thinking.
Maybe you can point to a git test/quiz that doesn't ask stupid trivialities 9 times out of 10? In case I have to "understand" it more, would be nice to pass some informal certification at least.
Re: Idiot Proof Git
#118It is an unforgivable crime that Mercurial has been muscled out of the consciousness. It's so much better, on literally every level. Implicit branching + the ability to truly divorce the repo's state from the actual files on the disk (in a simple way, I'm sure you can do the same with git, but it's going to involve a lot of subcommands and flags) are simply too good. Every time I have to use git, I feel like I'm fighting it. I end up coming up with a command that has ten flags and a subcommand that I've never heard of until just now. And when I try to ask people who know better, they agree it's the best way to do it.
Re: Idiot Proof Git
#119Pretty cool idea. Something I really want is a version of `git amend` that takes a commit hash, so I can amend my changes to any commit, not just the last one without having to start an interactive rebase.
You could create an alias doing something like a "git commit --fixup " and then a "git rebase --autosquash ~".
Re: Idiot Proof Git
#120Rebase 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?
A rebase creates new commits from old commits semi-automatically. Git then has no permanent record of the old commits, and even if you want to get back to them right away it requires some delicate git surgery.
This is why you can't generally share work using a rebase workflow.
It is not a big deal in practice in most every case, but in a version control system it is a little bit odd that rolling back such a fundamental operation isn't a first class feature.