181–190 of 248 posts
When you have a command so confusing that you need an entire website dedicated to a single command, and still need to warn against using it, then perhaps you've got the UX wrong.
I generally prefer transparent systems to those that try to figure out what I really want to do.
Weird they don't talk of the `git commit --fixup=` command. And then `--autosquash` when rebasing.
Is --fixup the same as --amend?
Earlier quoted context omitted.
Yes, it is lying. You can mitigate most of the damage if it is convincing enough (for example, go through B' and C' and make sure everything still makes sense at each point), but realistically nobody is going to do that, because it's pretty inefficient way to spend your time. And even then, you're still removing context (unless you're just fixing a typo). > I'm advocating that you use rebase to improve the quality of…
I really don't understand why you are choosing to use the word "lying". Us mere humans make mistakes all the time. Typos, omissions, false starts, and so on. What is the value of throwing that raw set of events at a reviewer or complicating the understanding of the changes when viewed in retrospect from the future? What is the reason you call curating the work into a more polished form "lying"? Why do you think the t…
You can do it in a way that isn't harmful (as I mentioned earlier), but good luck getting a team to actually stick to that. It also doesn't help that pretty much no tooling encourages doing it properly.
Earlier quoted context omitted.
What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge. But maybe you use your history for something else that I haven't considered.
can't you do similar by tagging? and then later just diffing against them?
Earlier quoted context omitted.
What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge. But maybe you use your history for something else that I haven't considered.
While I like the idea of rearranging commits to convey a nice (but "not how it originally happened") development sequence, I think in practice this matters less than (say) good commit messages, or the difference between merging and rebasing. (--fixup type commits aside). Practical benefits from not squashing history: - Can bisect to find bug introduction. - Can annotate/praise/blame to find who/when some change was m…
Earlier quoted context omitted.
+1. Interactive rebase to squash your feature branch, then ff merge into master/mainline. Years ago when I was just reading about git instead of using it, I saw sentiments along the lines of "always use feature branches and merge them so your thoughts and process can still be looked at later". In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own…
> In the last ~5 years or so I've worked professionally, I've not once wished I could reference intermediate commits in my own code or someone else's. I've found that ambiguities and clarifications can and are caught during the code review process. One command I often use is git blame which allows me to find the commit that's associated with a particular line of code. Then I can look at the commit message and the dif…
When I look back at the history, I'm only interested in seeing the changes that actually made it through, not every intermediate alley and dead end in between. If those dead ends are significant discoveries/results, I document them elsewhere.
Earlier quoted context omitted.
Git is really a toolkit for version control. Linus (or some other Git proponents?) distinguishes between "plumbing" and "porcelain": the infrastructure and the UI. Linus wouldn't claim to be a brilliant designer of user interfaces. It's totally conceivable that somebody could come along and develop a new way of talking about Git's functionality, implemented by a new "porcelain". Changing the vocabulary, creating a mo…
Unfortunately, none of the porcelains caught on, because all of the power users use plain git.
Earlier quoted context omitted.
It's not 'editing' the raw history files, but you're still presenting a false history to your coworkers. To me there are essentially two kinds of rebases: - Summarizing history: squashing "implemented subfeature A.A" and "implemented subfeature A.B" into "implemented feature A" - Rewriting history: moving commits around, changing the base commit, and so on In my opinion summarizing history is acceptable, you're makin…
Or you could just rebase component2 when you learn that component1 has been updated on master: * F: (master) Merge branch 'component2' |\ | * E: (component2) Implemented component 2 (now with updated component1) |/ * C: (master) Refactored component 1's API | * A: (master) Base So we've lost B and D from your example, but who cares about those commits?
Earlier quoted context omitted.
> Force pushing branches is what you do when you have pushed a branch that you expect to modify. Why would you do that? Because that's how Github and Bitbucket have taught people to conduct PR's. I thought that Github and Bitbucket encouraged people to push up additional commits to fix issues in their PR. So, a typical PR will end up with a commit history like: Implement a feature method Add calls to new feature meth…
Almost no projects I've worked on that use GitHub ask people to push fixup commits. In fact, maintainers (like me) often have to ask people to squash their commits into reasonable chunks.
Earlier quoted context omitted.
Git is really a toolkit for version control. Linus (or some other Git proponents?) distinguishes between "plumbing" and "porcelain": the infrastructure and the UI. Linus wouldn't claim to be a brilliant designer of user interfaces. It's totally conceivable that somebody could come along and develop a new way of talking about Git's functionality, implemented by a new "porcelain". Changing the vocabulary, creating a mo…
Unfortunately, none of the porcelains caught on, because all of the power users use plain git.