371–380 of 435 posts
Git's interface is like the 'find' UNIX command: it makes complex things possible, but does nothing to make common ones easy. 99% of times I want to find a file in the current directory or below: find . -name foo -print Can you spot the 3 obvious arguments that find shouldn't require me to type? Similarly, if so many users add -a to their git commands, why is this relegated to such an ugly flag?
find -name fooRebase 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…
Earlier quoted context omitted.
Disagree. No one maintains change logs in their repos most times, so a linear git history where you rebase existing branches on top of their base branches allows for a clean commit history on new features to be merged in which can then be squashed down for a linear commit history on the trunk branches. Then you can use things like bisect, and just... ya know, read through your change log when you need to. Shoot, you…
I think you misunderstood my post, if you squash merge as I suggested your main branch is linear as with a rebase. Your PRs and the the working branches behind them should just use merged however. Come merge time the diff is turned into a single commit
IMHO the single most important idiot proof of git should be a universal "undo" command. - Committed wrong? Undo - Switched to wrong branch? Undo - Pushed wrong? Undo - Merged wrong? Undo - Wrong reset? Undo There should be a "idempotent" undo for every action in git. If not, warn the user for possible outcomes. In this way, we can safely learn git via trial & errors.
That's not a bad idea. Pushed wrong is pretty hard to recover from (since you often aren't allowed to rewrite history on the remote), so I don't think there could be an easy 'undo' action for that, but the other ones could potentially be done.
For dev branches it's easy, `git reset --hard` on local then `git push -f` again. This command combination is not that intuitive for beginners.
I agree this action is sometimes hard to recover e.g. on protected branch, so a warning must be given to the user.
Lack of any real competition may be an issue there.
Earlier quoted context omitted.
> Since moving to this workflow I’ve had zero issues losing data due to a confusing git situation. Nobody who understands git will ever lose data, because once committed you can never lose it (it's in the reflog). Indeed, even just adding a file means you will never lose it, although it's not as convenient as having an actual commit. So yeah, you kind of revealed the anti-rebase case quite tellingly there. It's for p…
> A big one being that it's not actually stored in git, so if you ever migrate from github to gitlab or some other system, that context is gone. Request is committed to the repo on acceptance. Closed are typically useless. > What's your fear of rebasing if you're going to do the equivalent... The system takes care of the details without incidental complexity or errors. > This is a very confusing and nonsensical ideol…
I'm trying to get stuff done, not screw around with the Github UI. `git pull --rebase main` beats clicking around in a browser.
IMHO the single most important idiot proof of git should be a universal "undo" command. - Committed wrong? Undo - Switched to wrong branch? Undo - Pushed wrong? Undo - Merged wrong? Undo - Wrong reset? Undo There should be a "idempotent" undo for every action in git. If not, warn the user for possible outcomes. In this way, we can safely learn git via trial & errors.
Earlier quoted context omitted.
That's not a bad idea. Pushed wrong is pretty hard to recover from (since you often aren't allowed to rewrite history on the remote), so I don't think there could be an easy 'undo' action for that, but the other ones could potentially be done.
git undo -f
I feel like the fact that we have these incessant conversations about how to use git just show that the interface is inherently broken. New programmers always struggle with git. The naming of the commands is bizarre and confusing. The docs are overbearing and a lot of the time the fact that it's powerful in weird edge cases is seen to trump all of its flaws. That said I haven't seen anything better or even close to i…
Works with git repos (w/hg-git extension). Designed for humans. Sanity provoking. Gets out of your way, as a good SCM tool should.
IMHO the single most important idiot proof of git should be a universal "undo" command. - Committed wrong? Undo - Switched to wrong branch? Undo - Pushed wrong? Undo - Merged wrong? Undo - Wrong reset? Undo There should be a "idempotent" undo for every action in git. If not, warn the user for possible outcomes. In this way, we can safely learn git via trial & errors.
What do you mean by idempotent? Clicking undo two times and going back only one step sounds confusing.
For every git command, provide a way to undo the previous command, if possible.
For example, `git checkout -b abc`, a `git undo` would execute `git branch -D abc`.
This is just an example, I know you can find many problems and with this approach and edge cases when it doesn't work, but we can make life easier for beginners in most cases.
> Clicking undo two times and going back only one step
Huh? I never meant that. Click undo two times would go back two steps, naturally.
But of course, there are some actions that can't undo, so give user a warning or something.