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

391–400 of 435 posts

Re: Idiot Proof Git

#391

Post by cnity »

gardenhedge wrote: post #281
cnity wrote: post #158

Earlier quoted context omitted.

If the employer I worked for started micro-managing the way I use my tools (that affects nobody else) I would consider leaving, honestly. If I rebase on a branch that hadn't been shared with someone else, why does it matter what my boss or team thinks about that approach? Code styles are one thing, what I type into my terminal is another.

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?

Re: Idiot Proof Git

#392

Post by [deleted] »

theptip wrote: post #191
danwee wrote: post #130

Git commit crafting (and rebase to achieve it) is overrated. If you care about crafting beautiful series of commits so that the future readers understands what's going on: don't. Context is more useful to find out why something changed. Example: - you build feature F that is touching N files and M lines of code - you craft your git commits so that each of them is atomic and "understandable" on its own - now if I want…

I think you are arguing against an extreme version of the practice. Normal advice is to shoot for 100-200 lines in a commit, not split that into ten commits that each change 15 lines. If someone is splitting 100-line commits into 10-line commits, I would advise not doing that. However the direction that people normally err (IME) is submitting 500-2000-line commits which conflate multiple atomic changes. I would also…

[deleted]

Re: Idiot Proof Git

#393

Post by erik_seaberg »

FPGAhacker wrote: post #22
ok_dad wrote: post #12

Earlier quoted context omitted.

It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. Like --force, but can help to prevent overwriting other people's changes when they push in between you fetching. It doesn't always work, particularly if you have a tool which continuously fetches remote, like an IDE configured to do so such as VSCode. In that case, you will have fetched the other person's changes, and --f…

Oof, thanks for that warning. So it will blow away changes you haven’t merged (only fetched)? I guess git can’t tell the he difference between “not merged yet” and “don’t want to merge, please destroy”

The changes still exist in the repo’s reflog (for 30 days by default), but they might not be reachable from the ref’s new tip commit.

Re: Idiot Proof Git

#394

Post by hoseja »

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.

You can also `revert` which, while staying in history, needs no warning.

Re: Idiot Proof Git

#395

Post by P5fRxh5kUvp2th »

Dylan16807 wrote: post #347
P5fRxh5kUvp2th wrote: post #314

Earlier quoted context omitted.

"Why doesn't git bisect work?" "well, it landed on this rebased commit that's huge. I guess it was a kind of useful, just not as useful as we'd like".

But if the alternative is that it's ten commits and most of them don't work anyway, the bisect takes longer to give you the same lousy information.

That's not the alternative, who develops like that?

It's like the first time I saw the essay calling ORM's the "vietnam of the software industry". I remember reading it and wondering who the hell would use ORM's in that manner?

Apparently a lot of people, but if you're using rebase because you don't know how to create commits that build and are functional then I submit the issue is with you.

Re: Idiot Proof Git

#396

Post by est »

diffeomorphism wrote: post #384
est wrote: post #380

Earlier quoted context omitted.

> What do you mean by idempotent? 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…

https://www.merriam-webster.com/dictionary/idempotent idempotent means that doing it twice gives the same result as doing it once. So it seems you meant a different word?

Yes I mean undo would always restore the git to a previous state no matter what kind of commands you typed (best effort). It's perfectly symmetrical forward and backward operation which will guarantee restore to the same repo result whether you misstep git once or multiple times.

Is there a better word to describe this? I am an ESL speaker.

Re: Idiot Proof Git

#397

Post by Xelbair »

diffeomorphism wrote: post #384
est wrote: post #380

Earlier quoted context omitted.

> What do you mean by idempotent? 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…

https://www.merriam-webster.com/dictionary/idempotent idempotent means that doing it twice gives the same result as doing it once. So it seems you meant a different word?

I suppose they meant that (most) git commands should be idempotent, and therefore easily reversible.

Re: Idiot Proof Git

#398

Post by alanhaha »

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.

While it may not be accurate, but for "idempotent", did you mean "invertible"?

Re: Idiot Proof Git

#399

Post by seba_dos1 »

Dylan16807 wrote: post #351
seba_dos1 wrote: post #303

Earlier quoted context omitted.

--amend is conceptually nothing else than interactive rebase to squash the last two commits together.

Conceptually that's not really a rebase, because you're using the same base. If you never push the original commit, --amend is the same as staging things repeatedly for safety but only hitting the "commit" button later in the day.

Ha, "conceptually" is perhaps a wrong word. What I meant is that you end up doing the exact same operation, just via a shortcut in the UI.

It's the exact same operation I use interactive rebase for most often in my everyday work, just limited to a single commit (HEAD).

Re: Idiot Proof Git

#400

Post by seba_dos1 »

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.

git is already an undo mechanism itself. Commits are immutable. `git reflog` provides an undo log for pretty much every operation on the repository. `git push` shows the previous state of the branch which you can use to easily undo what you just did on the remote.

The only part that isn't easily undo-able is the index and working dir, but that's kinda the point of having an index in the first place. If you overwrite or delete a file without staging it in git, or unstage and then change it, git isn't going to magically restore it with an undo command. And that's fine.

Post reply on HN