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

401–410 of 435 posts

Re: Idiot Proof Git

#401

Post by seba_dos1 »

MetaWhirledPeas wrote: post #277
OkayPhysicist wrote: post #213

Earlier quoted context omitted.

Not the person you replied to, but what a rebase is is taking a series of commits you made to one place, and replaying them on top of another commit. So you make your PR, then branch off of that commit, and continue doing the normal edit-commit workflow on that new branch. Then, when you the PR gets merged, you git rebase -i (master/main/whatever branch your PR was being pulled into). You'll be presented with all you…

This is an excellent explanation, thank you. Still, I have questions. When I have topic checked out then run "git rebase -i main" does it first do fetch (or whatever) to make sure main's latest commit history is represented? Or is it up to me to do that first? The rebase concept is sound, but the semantics are a bit daunting. git rebase -i main This sounds like an operation is being performed on main. Terrifying! And…

> It's like using an aircraft cockpit to control the television!

It's not a television though. It's a set of tools used to manipulate a tree-like data structure that you're using to store your versions and reconcile changes across multiple trees. Once you approach it with that in mind and can imagine the high level data structure in your head, using it becomes almost as natural as using a hammer for a nail.

Rebasing is nothing more than changing the location a pointer ("branch") points at and then moving some nodes from one tree branch to another (in exactly the same way cherry picking works). It's really simple to visualize, you just need to have that tree in your mind already.

Re: Idiot Proof Git

#402

Post by danpalmer »

hinkley wrote: post #34
danpalmer wrote: post #2

Big fan of Git style guides in teams. We had one at Thread. It was common for engineers to come in and find we didn't do rebasing and find it weird, but we took the opinion that history should be exactly what you actually did, not some clean and idealised version of what you wish you had done. There are advantages and disadvantages to this, but having a defined approach was the most important aspect. Also the fact th…

Telling people not to rebase and having code that was never rebased are two very different things. Have you asked former employees if they rebased when nobody was looking? If you haven’t then you have no reliable data on what happens. When people set ridiculous absolute rules, what develops is an underground of people who don’t follow the rules and in some cases get a thrill from subverting the dystopia.

To clarify, this wasn't an enforced hard-rule, but instead just a written down style guide. Style guides can always be broken for good reason, but it's the sort of thing that a code reviewer might comment on or discourage. Generally rebasing before opening a PR was considered to be fine.

Re: Idiot Proof Git

#403

Post by forgotpwd16 »

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 :-).

The Humane Interface, a book on UIs by J. Raskin, talks about the importance of undo/redo.

Re: Idiot Proof Git

#404

Post by daneel_w »

Shacklz wrote: post #386
daneel_w wrote: post #209

Earlier quoted context omitted.

You have misunderstood. It's not a case of not knowing more about Git and its toolset. It's about our underlying workflow, letting us do version control of our software with simple means instead of throwing everything at it. It's easy to throw a hammer, mallet, pein and a club all at once on a nail, but that doesn't mean it's necessary or helpful.

> letting us do version control of our software with simple means instead of throwing everything at it VCS is a pretty difficult topic, and it's not like git is the only tool out there (let alone the very first). Multiple people potentially working on the same file in conflicting ways is always going to be something that cannot just magically be made simple. After all, if there are no conflicts, "rebase" is literally…

I don't understand what it is you want to communicate. The reason we mostly get away with minimal interaction with version control is because we plan our work to avoid (or at least minimize) multiple ongoing efforts in one and the same part of the platform - for reasons that are entirely unrelated to version control itself, not because someone on the team doesn't know how to resolve merge conflicts with Git.

Re: Idiot Proof Git

#405

Post by chopin »

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.

Besides a wrong push, the reflog gives you all that albeit not very intuitive. I admit that I often put tags at the current stage before trying anything advanced in order to find the last known good state easier.

Undoing a wrong push involves so many corner cases that it would be hard to implement. Where I work we are using gerrit and the default project setup doesn't allow direct pushes. Than it's only abandoning a change.

When I started working with git I came from Perforce and CVS. I had the complete wrong mental model in my head because of this which got me trouble understanding why things where not working as expected especially when pushing to remote.

Re: Idiot Proof Git

#406

Post by forgotpwd16 »

diffeomorphism wrote: post #377
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.

What do you mean by idempotent? Clicking undo two times and going back only one step sounds confusing.

Less confusing than undo/redo on Emacs. Wanna redo? Just undo your undo after breaking your undo sequence. You broke your undo sequence and want to resume undoing but not redo? Just `M-x undo-only`. What if then only the reverse and just want to redo? Just `Mx undo-redo`. Also keep in mind that if you have some region selected undo only applies to the region rather the file. Unless you use C-/ which always operates on the buffer.

It's without doubt powerful. But hell it's confusing.

Re: Idiot Proof Git

#407

Post by pydry »

P5fRxh5kUvp2th wrote: post #312
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…

It's flat out amazing how often people want to complicate git. My current company, everyone is in love with git flow. I pointed out the person who originally created it literally wrote a blog post explaining why it was designed for very specific needs that most projects don't have, and yet ... I constantly see people doing presentations on how this is all supposed to work. And why? You can get away with very simple f…

People love bikeshedding.

Git is also somewhat symbolic: you're a "real" programmer if you use it and not if you don't. I guess an advanced use of git makes you "realer". I think there's an element of "tidiness" to it as well.

It's definitely cultural more than technical. More tabs vs spaces rather than static vs. dynamic typing.

Re: Idiot Proof Git

#408

Post by diffeomorphism »

forgotpwd16 wrote: post #406
diffeomorphism wrote: post #377

Earlier quoted context omitted.

What do you mean by idempotent? Clicking undo two times and going back only one step sounds confusing.

Less confusing than undo/redo on Emacs. Wanna redo? Just undo your undo after breaking your undo sequence. You broke your undo sequence and want to resume undoing but not redo? Just `M-x undo-only`. What if then only the reverse and just want to redo? Just `Mx undo-redo`. Also keep in mind that if you have some region selected undo only applies to the region rather the file. Unless you use C-/ which always operates o…

> emacs

I found undo-tree incredibly intuitive.

Re: Idiot Proof Git

#409

Post by krinchan »

tremon wrote: post #294
krinchan wrote: post #183

Earlier quoted context omitted.

git add .; and git commit --amend --no-edit; git push origin --force Rarely, I have to do pipeline work on repositories. You'd normally see twenty "Fix Jankins Issue" commits on the main branch because of some nonsense that only happens when you deploy UAT or whatever. Once I learned this little gem, this is also how I manage my feature branches mostly. But also my employer's fleet of laptops has been aging and I've…

git add . We have had multiple security incidents because some developer left a credential file inside the local git clone (no, not all tooling supports out-of-tree stored credentials). Blind 'git add .' is the first thing I teach my developers not to do.

You don't use .gitignore? All our projects use dotenv for local credentials with a .gitignore that covers build, log, and any *.env file.

Sounds like you need better tooling, tbh.

Re: Idiot Proof Git

#410

Post by diffeomorphism »

Xelbair wrote: post #397
diffeomorphism wrote: post #384

Earlier quoted context omitted.

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.

Being idempotent does not help much with invertibility, e.g. zeroing out a file is idempotent.

In any case, the above post makes sense if you just delete the word.

Post reply on HN