Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Idiot Proof Git

softwaredoug.com

Post reply on HN
Print view View original

421–430 of 435 posts

Re: Idiot Proof Git

#421

Post by xorcist »

Aleksdev wrote: post #366
est wrote: post #356

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.

Map that bad boy to ctrl + z in terminal and now your talking business!

Call git every time you background a process? How would that make sense?

Re: Idiot Proof Git

#422

Post by user3939382 »

horsawlarway wrote: post #223
user3939382 wrote: post #113

.gitconfig: [alias] add-commit = !git add -A && git commit .bash_profile: function save () { git add-commit -m "$*" && git push } Use like: $ save This is a commit message This adds changed files to a commit with this message and pushes it to remote. Also: alias mkpr='git push && gh pr create -d -f -B develop | grep https | xargs printf -- '%s/files' | xargs open' Open a PR from current branch based on develop and op…

Commit accepts the -A flag. You can simplify it to just function save () { git commit -am "$*" && git push }

You can. I have it separate for the purpose of composition, sometimes I do 'gac Foo' which stands for 'git add commit' and I push later.

Re: Idiot Proof Git

#423

Post by stephen_g »

jononor wrote: post #389
stephen_g wrote: post #359

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.

If the result of the undo is that the remote branch (say main) is back at the point where it was just before, then that is actually a kind of change one could allow? As it does not rewrite history, just reset to previous point in time. But to really support this well, I think git would need a git commit object which means "reset to previous state".

The issue is if somebody else has pulled the remote branch and then you remove the commit, suddenly their branch and yours doesn't match. And then they can't push without massaging it.

I hate revert commits but often you have to do them if you make a mistake because usually force pushes will be disabled on master for that reason.

Re: Idiot Proof Git

#424

Post by stephen_g »

est wrote: post #374
stephen_g wrote: post #359

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.

> since you often aren't allowed to rewrite history on the remote 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.

Assuming your remote allows you to force push. Also you need to specify where to reset to because 'git reset --hard' will just reset you to HEAD, so you actually need to do 'git reset --hard HEAD~' (usually I don't use --hard for this either because often there's some work I want to keep from the commit).

Re: Idiot Proof Git

#425

Post by veilrap »

throwaw20221107 wrote: post #298
corytheboyd wrote: post #269

Aliases don't make git easier to understand, they make one specific git command require typing fewer characters to run. I am not against making aliases, but just saying, if you don't have an understanding of the commands they run, you'll still one day be in a state you don't know how to fix, and THAT is when people "lose their code" etc. You use git every day, it's worth learning and understanding. You don't need to…

The only reason people lose code is because 1. they didn't read this one diagram: https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-... 2. And then they run `reset --hard`

I'm mostly with you, except, `git reset --hard` is relatively easy to recover from. `git reflog` generally can fix most `git reset --hard` commands.

On the other hand. `git checkout .` with unstaged changes tends to be the most common way I've seen people lose code via git.

Re: Idiot Proof Git

#426

Post by jcon321 »

pierrebai wrote: post #245
jcon321 wrote: post #222

Idiot proof git is handled by protecting ALL branches and requiring a merge/pull request. Not a fan of aliases unless created and used personally. I'm a tech lead for 2 large scale web projects. Rarely will I traverse git log for anything besides the last few commits. If I ever wanted to see the history of something I would just lookup the merge/pull request, or look at the blame on individual files or lines within t…

I fail to see what anything you state has to do with rebasing. Rebasing ensures all commits from a feature branch are contiguous. Rebasing + squash ensures the main branch is not polluted with a myriad of useless intermediate commits no one is interested in. It also allows combining multiple commit message into a more coherent explanation of what changed instead of multiple tid-bits.

I fail to see your misunderstanding of what I stated. Rebasing is all about a pretty git-log, a pretty git-log is all about looking up why/what something changed. Everything I stated is about why you don't need a pretty git-log to know why/what something changed... Hope you don't talk to people at your day job like that.

Squashing commits of a feature branch via rebase is not the same thing as rebasing a local feature branch with the intended remote target.

Anyways, squashing is almost worse. Imagine doing a git blame on a line only to see a large commit of x amount of other changes with a summary about the global feature instead of an individualized commit referencing the line changed more closely. I am interested in those myriad of useless intermediate commits as you put it.

Re: Idiot Proof Git

#427

Post by throwaw20221107 »

cdaven wrote: post #365
throwaw20221107 wrote: post #292

Modern Git workflow is very simple on its own: 1. Your codebase has a `main` branch which is write-protected 2. Devs submit changes to `main` from their own branches using PRs 3. Devs can do whatever the fuck they want on their own branch 4. PRs are merged one at a time 5. When merge happens a dev's PR is squashed into one commit that gets appended to `main` 6. If next dev wants to merge their PR with a conflicting c…

When picking a git workflow, you should start with your system's and your team's requirements in mind. Don't just copy git-flow or GitHub's simplified version. Not every team or system uses pull/merge requests at all. Some do pull requests to the development branch, and to master when releasing a new version. In some teams, code review is the bottleneck, and a developer may have to create a new branch from a PR to ke…

>merging a sequence of PRs from same branch is bad if you squash

For me in this scenario, merging `main` w/ squash commit back into PR2 branch after PR1 gets merged works here.

As an aside — if code review is the bottleneck, it's probably not a huge investment to do some git fenangling to get the above to merge cleanly.

But I don't see how this use case is a dealbreaker or even specific to squash...? Won't you have to incorporate/merge other devs' changes to `main` back into PR2 anyhow, regardless of whether PR1 was a squash, rebase, or full history?

Re: Idiot Proof Git

#428

Post by gardenhedge »

cnity wrote: post #391
gardenhedge wrote: post #281

Earlier quoted context omitted.

When you commit you're sharing with your team and future team. I think it's fair to have a set of agreed guidelines around that. What if you wanted to put all your commit messages as "cnity did it"?

It's simple: I wouldn't do that. Do we need guidelines to not delete repositories too?

Yes of course

Re: Idiot Proof Git

#429

Post by rapind »

zenogantner wrote: post #390
rapind wrote: post #357

Earlier quoted context omitted.

> In this way, we can safely learn git via trial & errors. Thinking about this and I realize it could be beneficial in a lot of software. No one RTFMs anymore, and giving them the ability to trial and error makes sense. I know I appreciate it (pushing buttons to see what happens), but I’m not sure how common this approach is in general.

Being able to undo an action is is actually a general usability principle that has been around at least since the 1980s :-).

Fair enough, I should have been clearer. I’m thinking about extending it to CRUD apps for example. I haven’t personally seen any do that, and it might get really involved due to dependencies, integrations, etc.

Re: Idiot Proof Git

#430

Post by CBarkleyU »

mibollma wrote: post #288
idop wrote: post #10

Earlier quoted context omitted.

Obviously what works for you works for you, but I respectfully disagree with everything you said. The "history should be exactly what you did" argument - which many people make - is really funny to me because a pull/merge-only strategy only preserves the _wrong_ history. As a tech lead, for example, I absolutely do not care one bit about the date of a commit, or when the developer started working on it, or what was t…

I disagree with both of you :). Personally I prefer to squash to one commit per ticket but on a team level I don't care about a consistent way. I've found that the history rarely doesn't matter at all to me. Finding out who modified a specific code section (git blame) is usually good enough.

In the hopes someone will see this: Why isnt this the standard? I've never been in the position of coordinating multiple engineers, but when I look at my colleagues code I never ever once cared about their individual commits. What am I missing?
Post reply on HN