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

71–80 of 435 posts

Re: Idiot Proof Git

#71

Post by Cthulhu_ »

andrewvc wrote: post #31

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

Rebase is fine as long as it's your own unshared work. The alternative is https://xkcd.com/1296/

Re: Idiot Proof Git

#73

Post by jaimehrubiks »

stblack wrote: post #38

I might be mistaken but this post is basically describing git-friendly which I've used for years, is 100% flawless, and you'd need to pry from my cold, dead hands. https://github.com/git-friendly/git-friendly

OP's post describe the exact command git would use, and explains why, which is great for learning purposes as well.

Re: Idiot Proof Git

#75

Post by vultour »

fs111 wrote: post #51
alexb_ wrote: post #48

What's the deal with squashing commits anyways? I'm genuinely asking, because I've only worked with "squash everything before you put it up for review" but have never really figured out why past "it's what we've always done".

fix typo yet another typo test fix aaah, why is this test failing? merge foobar/narf revert foo foo Is just not a good history to preserve

Boggles my mind how so many people in this thread are against rebasing. Have they never needed to remove these commits? I do that pretty much daily, especially when troubleshooting something in a CI pipeline.

Re: Idiot Proof Git

#76

Post by Noumenon72 »

js2 wrote: post #69
ok_dad wrote: post #18

--force-with-lease can be a footgun. It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. 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 --force-with-lease will happily blow-away anything on remote that might not be…

From https://git-scm.com/docs/git-push A general note on safety: supplying this option without an expected value, i.e. as --force-with-lease or --force-with-lease= interacts very badly with anything that implicitly runs git fetch on the remote to be pushed to in the background, e.g. git fetch origin on your repository in a cronjob. The protection it offers over --force is ensuring that subsequent changes your work wa…

The existence of such a complicated workaround mainly serves as an official confirmation that you should just turn off auto fetch or not use force-with-lease. I use PyCharm's Update Project to fetch all branches at once on demand, so I will always get anyone's changes to my branch at the same time I fetch.

Re: Idiot Proof Git

#77

Post by smaudet »

dec0dedab0de wrote: post #36
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…

The log should track the product's evolution, not the developers' activities. Git is a development tool, not a product release tool. If you want to see the product evolution you could filter to just merge commits, or just merge commits in a specific format. If you want to keep track of releases specifically, then use tags, that's what they're for. I suppose you could make a separate branch/repo where every commit = a…

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 "features" with nothing but hashes and tags, no branches necessary. Branches are actually somewhat antithetical to distributed development, they're a useful concept, but that's all they are.

I do tend to agree though, re-base is superior to merge, in a product setting. If you want to track a feature set, having the set of commits which represents that feature set is better than a litany of nonsense tangled up in twelve feature "roots" (branches which have been merged together).

In a "do what I want" setting, rebase and merge are about equal, though. If I want to work on 3 features independently, I'd like to be able to easily see both features in parallel. I also would like to squash my features to single commits, and rebase them into feature branches where I can then merge/rebase/whatever those into my final "product" branch.

Re: Idiot Proof Git

#78

Post by dec0dedab0de »

idop wrote: post #52
dec0dedab0de wrote: post #36

Earlier quoted context omitted.

The log should track the product's evolution, not the developers' activities. Git is a development tool, not a product release tool. If you want to see the product evolution you could filter to just merge commits, or just merge commits in a specific format. If you want to keep track of releases specifically, then use tags, that's what they're for. I suppose you could make a separate branch/repo where every commit = a…

At the end of the day everything depends on the organization. In a hectic startup where requirements change on an hourly basis and releases are made several times a day, I would absolutely insist on keeping the log linear and as clear as possible. Tags are important, of course, but they're not that useful for analyzing a repository. When I say "the evolution of the product" I really mean "the "evolution of the code".…

When I say "the evolution of the product" I really mean "the "evolution of the code". When a small feature branch with 5 commits - four of which say "wip" and the last one says "added color support" - gets merged as is, and all relevant information is held hostage by whatever Git platform the company is using this week and not inside the repository itself, the log is not useful to me regardless of any strategy.

Yes, it can be annoying if your developers are committing nonsense, but then just tell them to not do that, or to rebase locally before pushing.

If you find yourself troubleshooting a bunch of nonsense commits, you can just do a diff to the merge commit, and it will show you all the changes. But you also have the option of figuring out exactly which commit caused the problem, and seeing it in context. If I see an error in the middle of a bunch of commits that look like "trying x with y." Then I know that this is a tricky problem, and the developer was lucky to get it to work at all. If it is in the middle of a standard looking commit, then the developer didn't struggle with this. So maybe they didn't put enough effort into it, or maybe it is a rare corner case.

When I'm troubleshooting other peoples problems, every bit of information helps. Especially when the developer who introduced the problems is no longer with the company. Squashing commits removes some of that information, without providing anything that I can't approximate by using merge commits in logging/diffs.

Re: Idiot Proof Git

#79

Post by skrtskrt »

blowski wrote: post #55
eru wrote: post #50

Earlier quoted context omitted.

Yes, but it's still better than --force under most circumstances.

Why use force at all, on a default command?

my flow is (on my-branch with no one else's commits)

* push some commits up to my remote branch

* git fetch

* git rebase master/main to get the latest stuff

* add changes on my-branch that use new stuff from master/main

* git push --force-with-lease to my remote branch - this fails if you don't use some version of force since my most recent commit is based on a commit (from master) not on the remote branch

Re: Idiot Proof Git

#80

Post by wruza »

thesuitonym wrote: post #7

I'm reminded of the saying, "if you make something idiot proof, someone will make a better idiot."

This is misleading. There are all sorts of "idiots" on a bell curve already and making something easier simply widens the stripe of effectiveness. It is a good thing because you now have more "idiots" who could do the job just fine.
Post reply on HN