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

411–420 of 435 posts

Re: Idiot Proof Git

#411

Post by idop »

P5fRxh5kUvp2th wrote: post #395
Dylan16807 wrote: post #347

Earlier quoted context omitted.

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.

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

As an independent contractor working with many different companies, unfortunately, virtually everybody.

Re: Idiot Proof Git

#412

Post by idop »

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

Most of what you said there isn't actually true. I don't doubt you believe what you're saying, I'm just pointing out it's not true. My favorite is how apparently rebasing causes developers to write better code. If you say so.

Thanks for pointing out my errors, I now see where I was wrong.

Re: Idiot Proof Git

#413

Post by idop »

copperx wrote: post #309
smaudet wrote: post #77

Earlier quoted context omitted.

Actually you're both wrong, its a change tool, not a development or a product release tool. "then use tags, that's what they're for" No they're not - that's definitely a useful way of using them, but they are just labels. Why is it useful to know this? Well, when you know your tool better (how it operates, not the porcelain or CLI), you have better insights and are able to use it better. You can manage Agile-style "f…

> Actually you're both wrong, its a change tool, not a development or a product release tool. It's funny that HN can't agree on what Git is.

If you ask me: a low-level SCM framework.

Re: Idiot Proof Git

#414

Post by ykonstant »

arcanemachiner wrote: post #362
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.

git undo -f

Should also support the gnu long-option, git undo --fuck-up

Re: Idiot Proof Git

#415

Post by chrisfinazzo »

Dylan16807 wrote: post #348
chrisfinazzo wrote: post #320

Earlier quoted context omitted.

I'm certainly aware of reflog and have (thankfully) only had occasion to use it once or twice that I can remember. To my original comment - having to force-push in order to resolve heads - is there a "correct" way to do this that doesn't feel gross?

You're going to have to explain your problem in more detail than "resolve a situation with multiple remote heads".

To explain, I'll borrow the solution that I first saw in a Fog Creek presentation from ages ago ("DVCS University")...

Essentially, if you have more than one person making changes to the same piece of code, the method for resolving them is:

1) Pull - gets their changes

2) Merge - puts their changes together with yours and you can reorganize them at that point.

Note, this was done with Mercurial which doesn't have the concept of a stage, so Pull feels like it has a slightly different meaning when you look at it that way. One [suggestion][1] for Git if you want to achieve the same effect - getting a Fast-Forward at the end - is to Rebase, then Merge last.

Part of me knew this, I simply forgot and wanted to get out of this particular hole.

[suggestion]: https://www.atlassian.com/git/tutorials/rewriting-history/gi...

Re: Idiot Proof Git

#416

Post by umvi »

chociej wrote: post #382
umvi wrote: post #265

Earlier quoted context omitted.

Without merge commits you can never have more than 1 long-lived branch because said long-lived branches will not have any common ancestors which makes pulling changes between them a nightmare (literally every file will be in conflict)... I like linear histories too, but if you have a production branch and a development branch you need merge commits between them.

I don't think either of those is necessarily true. I don't ever need to merge long lived branches if I don't want to. And I definitely don't ever merge my production branches with... anything. They are always just a fast-forward from another branch.

In my case I have 2 branches - production and development which map to different cloud environments. Pushing to development branch will run CI/CD to auto-deploy to development cloud, and pushing to production will run CI/CD to auto-deploy to production cloud. This particular software is also classified as a medical device under FDA which means there are regulations about what can be deployed to production and when. Hence, I cannot just fast forward production from another branch without first getting FDA approval. I can, however, cherry pick certain kinds of bug fixes into production without FDA approval, and then later (after FDA approval) merge the other approved changes into production as well. In this case fast forwarding isn't possible because of the cherry picks so we are using just normal merge commits.

Do you have a better git workflow in mind than what is described above?

Re: Idiot Proof Git

#417

Post by Dylan16807 »

chrisfinazzo wrote: post #415
Dylan16807 wrote: post #348

Earlier quoted context omitted.

You're going to have to explain your problem in more detail than "resolve a situation with multiple remote heads".

To explain, I'll borrow the solution that I first saw in a Fog Creek presentation from ages ago ("DVCS University")... Essentially, if you have more than one person making changes to the same piece of code, the method for resolving them is: 1) Pull - gets their changes 2) Merge - puts their changes together with yours and you can reorganize them at that point. Note, this was done with Mercurial which doesn't have the…

That's the start of a setup, but that's not enough information for me to figure out why you needed a force push.

I'm not going to demand you explain more, but if you want to explain more then I'll try to answer the question you had about whether there's a better method.

Also Pull is generally a shortcut for "Fetch then Merge", and just getting changes is Fetch.

Re: Idiot Proof Git

#418

Post by mixmastamyk »

chociej wrote: post #376
mixmastamyk wrote: post #305

Earlier quoted context omitted.

> 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…

> Pretty simple, folks are trying to get shit done. Not screw around with tools. I'm trying to get stuff done, not screw around with the Github UI. `git pull --rebase main` beats clicking around in a browser.

I use the cli as well, the clicks above refer to clicking the squash checkbox on a merge request in gitlab. This is 10x faster than hand-crafting an artisanal one to tell a story.

Re: Idiot Proof Git

#419

Post by mixmastamyk »

eru wrote: post #330
mixmastamyk wrote: post #255

Earlier quoted context omitted.

Until you make a mistake.

Why? That's what 'git reflog' is for. Or you mean that a mistake where you accidentally push to someone else's branch? The default model that public github uses is good for that: everyone works on their own fork of the repo, and makes pull requests to the shared repo. Nobody pushes directly to the shared repo.

Second. Github not an option for a lot/most work.

Re: Idiot Proof Git

#420

Post by cakoose »

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 undo" tool: https://github.com/arxanas/git-branchless/wiki/Command:-git-...
Post reply on HN