61–70 of 87 posts
Does this work even we keep pushing commits on a remote repository? We extensively use Github Pull Requests for code reviews and most of the time we squash our PRs into a single commit but I would love to have a way to merge into multiple smaller squashed commits (as OP did) instead of one big.
Editing git history makes sense in several cases: 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Editing git history makes less sen…
git rebase -i on a master with no changes. As a sole developer, I am pulled in two different directions when using git feature-branch style. I want to make sure I never lose my work so I check in frequently- any time I start a change that might ultimately fail, I commit my current code so I can recover it. But I also want a clean, concise and useful history. After reading this article I tried 'git rebase -i master' o…
Earlier quoted context omitted.
> I always twitch a bit when I see a 10-page blog post describing a "git workflow", with all sorts of complicated branching rules and heavy use of rebasing. That can make sense in certain specialized situations, but it shouldn't be considered a "best practice" that everybody needs to emulate. I tend to justify this based on a simple observation: writing clean code that is easy for others to understand is also hard. I…
How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?
Why would you want to understand what was going on? Maybe for fixing a bug, maybe for working out why a seemingly useless change was necessary, maybe to understand the context of a code review building on previously merged branches, or maybe just because you need to catch up on what happened while you were gone.
If that's not important to you, then don't bother, but it can be hard to understand what you're missing until you've tried both ways.
Editing git history makes sense in several cases: 1. Projects like the Linux kernel which use frequently use 'git bisect' to perform a binary search on the history of project (to find when a bug was introduced), or where the patch series tell a story to code reviewers. 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Editing git history makes less sen…
Do people actually look at the history a lot? After a pull request has been merged I rarely look at the history and I am really not interested in it. This is for a small team with around 5 people. In larger teams is it more important to see the history?
Earlier quoted context omitted.
> Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges? Afaik, git-bisect is aware of branches and merges. But there are two drawbacks to not rebasing/squashing: 1) the number of extra commits. Although bisecting is O(log N), it still adds up if it takes a long time to run the tests. 2) if there are any commits that don't build or have to be skipped (git bisect skip) b…
If true, the the whole claim that nonlinear histories break git-bisect is bunk.
I personally almost never rebase and/or squash, since I think that the information that gets lost (like: when was it started, what were mistakes along the lines) might be useful for future understanding of how the project work evolved over time, and what adjustments should/could be made to the development process. But I understand that a screen as shown in the article is not immensely usuful. But if it comes down on…
I think there are two perfectly acceptable schools of thought. One says that the history should be preserved exactly, because its important we keep a record of exactly what happened. The second says that its ok to rewrite history a little if that makes it more understandable. I think you would put yourself in the first, and that's ok. I would put myself in the second because at the end of the day I value understandin…
Earlier quoted context omitted.
How is it rewarding? No one ever sees the history, honestly. Writing good code results in working code the people build off of. Maintaining clean, linear git histories does.. what exactly?
No one ever sees the history? Really ? To me the need for checking history is extremely common. Many projects have multiple delivery, maintenance and other branches, patches need to be applied here and there. Bugs are found and the versions affected needs to be identified. Not maintaining a clean history would cause severe pain.
Do you automate it?
Or do you provide feedback by mail, IM, ... to the author when a commit mistake is detected?
Earlier quoted context omitted.
Why have a history then at all? The idea is not to squash history but make it reasonable chunks. Remove chaff so to speak while keeping the general history. A single feature is very rarely a reasonable chunk. (For example, see Linux kernel patch series per feature.) Otherwise you may lose the "why" unless code is extremely well commented and that never happens.
ok depends on the size of a feature I guess but usually I sit in a branch for 2-3 days before I finish the feature. Also what's the point of preserving the history of a branch that is used for the development of a requested feature ? For each commit before the final, the feature is incomplete, possibly not working at all.
Splitting per feature is indeed ok if it is small including effects on dependencies. But in my practice there are rarely small enough features - these map to something akin to user stories which have to be further broken down.