31–40 of 87 posts
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…
is there a site that shows an animation for each git command?
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…
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 depen…
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…
Say we work together. Why would you want to see my 5 solutions to a problem in `master`, of which 4 actually never really ran in production? I do commit often, things that I try and later throw away are in the history. Once rebased and squashed, only final solution is in `master` history.
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…
Say we work together. Why would you want to see my 5 solutions to a problem in `master`, of which 4 actually never really ran in production? I do commit often, things that I try and later throw away are in the history. Once rebased and squashed, only final solution is in `master` history.
but the history showed that it was tried (and perhaps the commit message can have a short note on why it wasn't selected).
without the git history, you'd have to rely on human memory to know this. Or a separately maintained documentation (which, lets face it, is never going to get updated).
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.
I think a lot of people don't bother with rebasing because they either don't know how to do it, or they are scared of the idea of a version control system not explicitly saying what they've done to accomplish the latest version of their code. Once you get even a small understanding of it, there are plenty of places you can use it. For example, in the past month I've used it to: 1. Rewrite the history on a coding test…
Just a note on your nr1: I don't think rebase back-dates the CommitDate, does it? There are two dates on any commit: AuthorDate and CommitDate. Try git log --format=fuller. E.g.: Author: ... AuthorDate: Wed Aug 2 11:02:03 2017 +0100 Commit: ... CommitDate: Wed Aug 9 12:08:52 2017 +0100 This is a commit I originally created last week, but rebased onto my current branch just now. To change the CommitDate, you have to g…
In order to do no.1; perform your rebase, and then change the dates with filter-branch. I have a couple of helper functions for both for resetting to commit or author dates [1], use at your own risk! :)
[1] https://gist.github.com/dm/aad8e34a5ee6b542a0bc788375b548ed
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…
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.
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…
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.