Git: Using Advanced Rebase Features for a Clean Repository • Hacker News Board

Re: Git: Using Advanced Rebase Features for a Clean Repository

#81

Post by lomnakkus » Wed, Aug 09, 2017, 10:11 PM UTC

lolive wrote: post #69

Zitrax wrote: post #47

Earlier quoted context omitted.

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.

How do you enforce a commit policy in your projects? Do you automate it? Or do you provide feedback by mail, IM, ... to the author when a commit mistake is detected?

Review-before-merge, maybe?

Obviously, for any old arbitrary project, there's going to be limits to what you can ask your contributors to conform to before they just leave, but we're discussing "Best Practices"[1] here.

I think these articles are useful because they spread the knowledge of "How To Be A Good Contributor"... for free.

[1] Ugh. Not a term I like, but really this is almost always(!) the best way to do it.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#82

Post by fulafel » Thu, Aug 10, 2017, 5:14 AM UTC

splike wrote: post #14

radiospiel wrote: post #11

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…

Maybe we need another layer of abstraction, maybe recorded as merge commits, that would present the summarized history.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#83

Post by Vinnl » Thu, Aug 10, 2017, 5:26 AM UTC

maxxxxx wrote: post #62

ekidd wrote: post #18

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?

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-documentatio...

(From my blog post about why history matters: https://vincenttunru.com/Spend-effort-on-your-Git-commits/ )

Re: Git: Using Advanced Rebase Features for a Clean Repository

#84

Post by Vinnl » Thu, Aug 10, 2017, 5:28 AM UTC

jlebrech wrote: post #19

ekidd wrote: post #18

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?

Here's one for the most basic ones, except staging: https://agripongit.vincenttunru.com/

(Disclaimer: I made that :)

Re: Git: Using Advanced Rebase Features for a Clean Repository

#85

Post by Vinnl » Thu, Aug 10, 2017, 5:30 AM UTC

EnderMB wrote: post #23

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…

> 3. Saving time for pull requests. I tend to commit early and often, and when I'm in "the zone" on a fairly chunky bit of work that can mean quite a few commits! When it comes to peer review, some people like to do it by commit, rather than the finished output, so to help these guys out I squash commits where possible, since we use our pull requests to illustrate the problem we're solving anyway. I think an untarnished history is important, but sometimes a PR audit trail is more useful than what you'd get from pure commits.

I think this is the most important one. Your commits are documentation for people reading your code, so whatever helps them is good.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#86

Post by lomnakkus » Thu, Aug 10, 2017, 6:38 AM UTC

radiospiel wrote: post #11

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 really don't need to see all your false starts at a solution to the problem. I don't mean that in a patronizing way, it's just that it is truly irrelevant when I'm digging through commit history.

Question: Do you have a problem with rebase-before-push?

Regardless, there's a happy medium here: Just commit whenever you feel like it, then rebase, squash or whatever just before you're reasonably(!) confident in your approach... and push. Obviously you don't want to force-push, so at the point that you're "reasonably confident" you're committed. If you need to retrace your steps, you just do that through normal "git revert" or whatever.

The point of the above being: This way of working preserves the useful parts of history and you still avoid the absurd noise of seeing everybody's "I changed a thing" commits and non-compiling-commits as well.

Re: Git: Using Advanced Rebase Features for a Clean Repository

#87

Post by Walkman » Fri, Aug 11, 2017, 3:46 PM UTC

For God's sake, DON'T TEACH IF YOU DON'T UNDERSTAND YOURSELF what's happening.

"Commit C's revision number has changed." - NO IT DID NOT. The original commit (f4ba6b) is still there, it still points to B, but a totally new commit has been created with a different content. To avoid confusion, it's better to name it C'. C is now a dangling commit (has no branch or tag pointing to it, and will eventually be garbage collected).