[flagged]
The git history command
201–210 of 330 posts
Re: The git history command
#202Earlier quoted context omitted.
Because people actually use Git instead of whatever you mean.
This is irrelevant to the topic. I didn't ask why git was widely used. I didn't say git was useless. Again, there were version controls before git came out.
I think the point was that a lot of people are confused by git because a lot of people use it. Meaning that the other software where people don’t complain would get the same amount of complaints if it had as many users as git has.
Re: The git history command
#203Earlier quoted context omitted.
Ok but the final outcome, most of the time, is a linear graph unless you're maintaining extremely long-lived branches for some reason. Setting practices so that linear graph will be easy to understand in history is still a good idea, no? I'm not religious about squash-merge on master but when I look at master's history, I'd expect each individual commit to have a good message and be releasable.
A linear graph doesn't do any developer in the team except Github (which isn't a developer in this context) any good because they have to pull down the graph at some point and when they have to fix something, although they will be able to track the blame to some commit in the middle of the graph, when they fix it and merge it it has to be squashed again (by hard or soft enforcement), which like I said negates much of…
> the value that Git provides -- branching (not just ephemeral branching for your local convenience).
I think this is the disconnect. I could see big libraries maintaining branches for each major release and I understand why linux does it. But if I'm maintaining FooService at work then I actually do just want a linear graph of all the commits that have been in production, in commit order.
Re: The git history command
#204Earlier quoted context omitted.
> Let's not start to bend reality just to back up some narrative because after reading a N hours documentation everything is OK. If you expect everything to be as easy as pie without needing to make a little effort to read a bit of documentation, then perhaps the problem is not the product but the fact that you are in the wrong industry, or the wrong role within that industry, for you. Have you considered a managemen…
You conveniently cherry picked the least relevant part of my message. No one said everything should be easy as pie. There are other software similar to git that have not such reputation. Version control is not new.
> There are other software similar to git that have not such reputation. Version control is not new.
Yes, there are alternatives that aren't used by anyone except dedicated fans. If they had the wide user base that git enjoyed you'd hear just as many complaints about them.
Re: The git history command
#205> scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze `git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.
You don't even need to set a safety tag like that anywhere in git, the reflog does that for you automatically.
Re: The git history command
#206I don't get all the effort people spend in perfectly curating git history. No one is ever going back and reading individual commits. Just squash everything before merging and call it a day.
I’m with you, but it’s obviously a sensitive topic for a lot of folks, based on the replies. Some people’s brains are just wired differently, I guess. I rarely look at history, other than git blame. For me, history does not need to be granular at all. The replies make it sound like curating git history is the job, rather than shipping solutions to customers’ problems. I guess, if it helps you ship faster / better, more power to you.
Re: The git history command
#207Earlier quoted context omitted.
I once root-caused a revenue-losing bug that had the entire rest of my team stumped with ten minutes of git-bisect. It only worked that well because the team had all internalized my advice to write small, coherent commits, so the bisect landed on a ten-line change. I strongly dislike the recent trend towards squashing every branch into a single monster commit.
Most people who squash things have never used git bisect, cannot solve a merge conflict and when there is one will just delete the directory and clone everything again. I've worked with such people. They can go on like this for an entire lifetime.
For me (I know you used most, not all). A PR is an atomic thing. Either one bug or one feature. Commits inside it are mostly time snapshots, and fixing formatting and linting errors. If I where to properly present the PR, it will also have been a single commit.
Re: The git history command
#208Earlier quoted context omitted.
> Otherwise when you use git blame to get the context of why a line of code was changed, all you see is a useless "fixup" message Isn't this solved if you squash the commits when merging the PR? I personally don't care that much about the commits inside a PR, the are just temporary because when a PR is merged they are squashed and you only get one commit for the whole feature on the main branches
> if you squash the commits when merging the PR? You tidy up and rebase before making a PR. Anything else is really disrespectful of your reviewer's time. That is also how all the larger open source projects operate. > you only get one commit for the whole feature If you are doing one logical commit per PR, you are doing way too many PRs. Alternatively you don't have a working review process.
Yes, often you have separate logical changes that should still be reviewed together.
Re: The git history command
#209Earlier quoted context omitted.
> No one is ever going back and reading individual commits. I violently disagree with this. At a minimum, when I review PRs I look at the commit history to understand what's up. If the path that was taken to commit this is full of "oops" and "fix" messages, it's an immediate reject for me. The commits tell the story and it's a kindness to your human reviewers to not make them work harder to understand the point you'r…
You sound pleasant to work with. I bet your coworkers route around you when they can, and when they can't they cherry pick from their working branch to deliver monolithic commits while rolling their eyes.
No, he sounds like a professional with standards.
Re: The git history command
#210Earlier quoted context omitted.
You sound pleasant to work with. I bet your coworkers route around you when they can, and when they can't they cherry pick from their working branch to deliver monolithic commits while rolling their eyes.
No, he sounds like a professional with standards.
A professional with standards who wasn't also unpleasant would put the time in to review the content of the commits with a request to clean up the history. Someone who looks at the history, thinks to themselves "not how I like it" and just auto-rejects the entire PR without any further thought is just a bad coworker.