4 ms·

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 his

by ekidd 9y ago

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 sense in other circumstances: 1. When dealing with less sophisticated git users who don't understand git's data model. About 90% of git nightmares begin when a novice git user tries to rebase something. 2. When it adds a whole layer of unnecessary process for zero payoff. If your developers all work in short-lived branches with clean histories, then just go ahead and merge normally without forcing everybody to jump through a bunch of hoops to beautify a history that nobody ever looks at anyway. Git was designed to handle branches. 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.

jlebrech 9y ago
is there a site that shows an animation for each git command?
- striking 9y ago
  Yep! http://learngitbranching.js.org/ http://learngitbranching.js.org/
- branja 9y ago
  Not animations, but git-scm.com is excellent
- Vinnl 9y ago
  Here's one for the most basic ones, except staging: https://agripongit.vincenttunru.com/ https://agripongit.vincenttunru.com/ (Disclaimer: I made that :)
nothrabannosir 9y ago
Resolving conflicts through a merge or a rebase is a different style (all-in-one vs piece-meal), and I find both have their uses in different contexts. Sometimes, a big merge with tons of conflicts is too daunting, where a patch-by-patch conflict resolution is more palatable. Other times, you're doing busy work on tons of patches which would be far more efficient just doing once on a big merge. But, again, this depends on the situation, the code, the history, the patches, etc. It's just a useful tool to keep in mind come merge time.
- branja 9y ago
  You can do both. Squash your working branch to a single commit, then rebase. That way you still get a clean view of just the changes introduced in the branch, and don't have to resolve merge conflicts every step of the rebase.
burntsushi 9y ago
> 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. If you could write a document that teaches others how to write clean code, what would it contain? How long would it be? How complex would it be? I'm betting you've built up a repertoire of wisdom on writing easy to read code, and I'm betting that document would be quite long, especially if you furnished it with examples. I think it's the same for commit history. If you're rebasing, then you're probably trying to shoot for a clean history that other humans can understand. Maintaining a clean history can be just as hard (and just as rewarding) as maintaining clean code.
- kobeya 9y ago
  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?
  - burntsushi 9y ago
    Uh, I read commit history all the time. (My initial comment assumes you believe the idea that a clean history is useful, because that's the context of ekidd's comment. So I really don't feel like debating that particular point, if that's what you're getting at. It's been re-litigated hundreds of times.)
  - mikegerwitz 9y ago
    > No one ever sees the history, honestly. Then you wouldn't see value in rewriting. Unless you're not reading the history because it's a pain to read because it's messy. I use `git blame` relatively frequently to understand the rationale and history behind the code I'm working on, or to track down bugs. Of course, this also requires writing decent commit messages---something that I encourage developers to do so that those maintaining their code in the future have some direction. Commit messages are a bit different than software documentation, not a substitute. I bisect looking for bugs, where a clean history with small commits _that actually build_ is essential to quickly finding a bug. That can even be automated if you can create a script that can run a test suite or some other test to check for success. This becomes increasingly important the more code and complexity you're dealing with. There are other cases where I look at history, but those are significant examples.
kobeya 9y ago
> 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. This seems like an instance of adapting development practices to bad tooling, whereas we could be fixing the tool itself. Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges? That would resolve this sticking point. > 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Then tell them to go away and come back with a cleaned up PR.
- exDM69 9y ago
  > 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) because of other reasons, the number of steps to bisect increases. It's a good idea to ensure that any commit that goes to master branch will pass all tests or at least compile. Failure to do so will make git-bisect a lot less useful.
  - kobeya 9y ago
    If true, the the whole claim that nonlinear histories break git-bisect is bunk.
    - JoshTriplett 9y ago
      Non-linear histories work just fine with git-bisect. What breaks git-bisect are histories where every commit doesn't work; for instance, if you have one commit that breaks something, and a second commit that fixes it, git-bisect won't work well.
      - AstralStorm 9y ago
maxxxxx 9y ago
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?
- branja 9y ago
  I work as lead dev on a 5 year old web app I took over from a previous dev and his team of subcontractors about a year ago. It's very helpful to see into the past when there's no way to just ask the previous dev.
- james-skemp 9y ago
  I work in a University setting where we have student's working in our various projects. While some stay with us for a number of years, some are with us for a semester or two. Even with full-time staff, in the almost 6 years I've been here the rest of the dev and design staff completely changed (and grew). In my opinion, if you're not using history/blame your code is relatively new, or you're the only one touching code. Or you have regular code reviews (paired programming, whatever). Seven years at my last job was just full-time staff, but we had the same issues, once a version control system was actually implemented.
- Vinnl 9y ago
  Even if not at the history directly, commit messages are associated with the lines they edit. This provides great granular documentation: https://vincenttunru.com/assets/img/Commits-are-documentation/annotations.png https://vincenttunru.com/assets/img/Commits-are-documentatio... (From my blog post about why history matters: https://vincenttunru.com/Spend-effort-on-your-Git-commits/ https://vincenttunru.com/Spend-effort-on-your-Git-commits/ )

by ekidd 9y ago

jlebrech 9y ago

is there a site that shows an animation for each git command?

striking 9y ago
Yep! http://learngitbranching.js.org/ http://learngitbranching.js.org/
branja 9y ago
Not animations, but git-scm.com is excellent
Vinnl 9y ago
Here's one for the most basic ones, except staging: https://agripongit.vincenttunru.com/ https://agripongit.vincenttunru.com/ (Disclaimer: I made that :)

nothrabannosir 9y ago

Resolving conflicts through a merge or a rebase is a different style (all-in-one vs piece-meal), and I find both have their uses in different contexts. Sometimes, a big merge with tons of conflicts is too daunting, where a patch-by-patch conflict resolution is more palatable. Other times, you're doing busy work on tons of patches which would be far more efficient just doing once on a big merge. But, again, this depends on the situation, the code, the history, the patches, etc. It's just a useful tool to keep in mind come merge time.

branja 9y ago
You can do both. Squash your working branch to a single commit, then rebase. That way you still get a clean view of just the changes introduced in the branch, and don't have to resolve merge conflicts every step of the rebase.

burntsushi 9y ago

> 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. If you could write a document that teaches others how to write clean code, what would it contain? How long would it be? How complex would it be? I'm betting you've built up a repertoire of wisdom on writing easy to read code, and I'm betting that document would be quite long, especially if you furnished it with examples. I think it's the same for commit history. If you're rebasing, then you're probably trying to shoot for a clean history that other humans can understand. Maintaining a clean history can be just as hard (and just as rewarding) as maintaining clean code.

kobeya 9y ago
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?
- burntsushi 9y ago
  Uh, I read commit history all the time. (My initial comment assumes you believe the idea that a clean history is useful, because that's the context of ekidd's comment. So I really don't feel like debating that particular point, if that's what you're getting at. It's been re-litigated hundreds of times.)
- mikegerwitz 9y ago
  > No one ever sees the history, honestly. Then you wouldn't see value in rewriting. Unless you're not reading the history because it's a pain to read because it's messy. I use `git blame` relatively frequently to understand the rationale and history behind the code I'm working on, or to track down bugs. Of course, this also requires writing decent commit messages---something that I encourage developers to do so that those maintaining their code in the future have some direction. Commit messages are a bit different than software documentation, not a substitute. I bisect looking for bugs, where a clean history with small commits _that actually build_ is essential to quickly finding a bug. That can even be automated if you can create a script that can run a test suite or some other test to check for success. This becomes increasingly important the more code and complexity you're dealing with. There are other cases where I look at history, but those are significant examples.

kobeya 9y ago

> 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. This seems like an instance of adapting development practices to bad tooling, whereas we could be fixing the tool itself. Shouldn't there simply be a "tree aware" git-bisect that can intelligently handle branches and merges? That would resolve this sticking point. > 2. Open source projects, where some contributors have terrible git habits that the maintainers don't want to merge. Then tell them to go away and come back with a cleaned up PR.

exDM69 9y ago
> 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) because of other reasons, the number of steps to bisect increases. It's a good idea to ensure that any commit that goes to master branch will pass all tests or at least compile. Failure to do so will make git-bisect a lot less useful.
- kobeya 9y ago
  If true, the the whole claim that nonlinear histories break git-bisect is bunk.
  - JoshTriplett 9y ago
    Non-linear histories work just fine with git-bisect. What breaks git-bisect are histories where every commit doesn't work; for instance, if you have one commit that breaks something, and a second commit that fixes it, git-bisect won't work well.
    - AstralStorm 9y ago

maxxxxx 9y ago

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?

branja 9y ago
I work as lead dev on a 5 year old web app I took over from a previous dev and his team of subcontractors about a year ago. It's very helpful to see into the past when there's no way to just ask the previous dev.
james-skemp 9y ago
I work in a University setting where we have student's working in our various projects. While some stay with us for a number of years, some are with us for a semester or two. Even with full-time staff, in the almost 6 years I've been here the rest of the dev and design staff completely changed (and grew). In my opinion, if you're not using history/blame your code is relatively new, or you're the only one touching code. Or you have regular code reviews (paired programming, whatever). Seven years at my last job was just full-time staff, but we had the same issues, once a version control system was actually implemented.
Vinnl 9y ago
Even if not at the history directly, commit messages are associated with the lines they edit. This provides great granular documentation: https://vincenttunru.com/assets/img/Commits-are-documentation/annotations.png https://vincenttunru.com/assets/img/Commits-are-documentatio... (From my blog post about why history matters: https://vincenttunru.com/Spend-effort-on-your-Git-commits/ https://vincenttunru.com/Spend-effort-on-your-Git-commits/ )