Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git: Using Advanced Rebase Features for a Clean Repository

mtyurt.net

Post reply on HN
Print view View original

11–20 of 87 posts

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

#11

Post by radiospiel »

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 how to present git history information to users, maybe an additional aproach would be to come up with a better presentation layer (that, for example, could hide merge commits, "squashes" branches, etc.

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

#12

Post by joshschreuder »

therealmarv wrote: post #10

keeping a clean commit log or even strong commit rules is something which I only see as barrier for improving existing code... just thinking of code improvements by PRs which got rejected by bigger projects because the commit history was not "clean enough". History is not always good or pretty in real life... it should be the same on git commits.

To some extent I agree, enforcing it at a project level seems like bikeshedding and not necessarily that useful. On the other hand, like walking people through your house, it's nice to tidy up first to give people a good experience, and the same applies to walking through the history of your change too IMO

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

#13

Post by therealmarv »

joshschreuder wrote: post #12
therealmarv wrote: post #10

keeping a clean commit log or even strong commit rules is something which I only see as barrier for improving existing code... just thinking of code improvements by PRs which got rejected by bigger projects because the commit history was not "clean enough". History is not always good or pretty in real life... it should be the same on git commits.

To some extent I agree, enforcing it at a project level seems like bikeshedding and not necessarily that useful. On the other hand, like walking people through your house, it's nice to tidy up first to give people a good experience, and the same applies to walking through the history of your change too IMO

Even software with good and beautiful git histories can be ugly as hell (seen it all) and a good and beautiful house can have some really bad ugly history ;)

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

#14

Post by splike »

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 understanding over precision in git histories. I'm of the opinion that one cares about the commit I made to correct a missing semicolon.

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

#15

Post by UK-AL »

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…

The thing is I commit very frequently, and a lot of the commits don't really make much sense by themselves. Often with stuff that's just plain wrong or confusing inbetween.

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

#16

Post by hdhzy »

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…

The usual rule of thumb is not to modify (e.g rebase) published commits. So it's perfectly fine to adjust local commits before they go into centralized repo - from the point of view of an external observer the history is never destructively modified. This rule can be extended to topic branches or user owned branches with the caveat that others should not base their work upon the topic branch.

Also remember git push --force-with-lease!

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

#17

Post by CJefferson »

git-pull wrote: post #9

No one's perfect with this stuff. If you don't believe me, clone git itself ($ git clone https://github.com/git/git ) and open up the repo in tig(1) https://github.com/jonas/tig To be honest, I only in the past 2 years even bothered to view ($ git log --graph). Regardless of --graph getting wide now and then, I always visualize my git history as a straight line. Also, sometimes having a non-linear history is inevitab…

Just one small thing, I have found a few times git rebase breaking git bisect.

Git rebase can create large sequences of commits which no-one has ever checked out, and often don't build -- after a git rebase most people check their new head builds and passes tests, but I've never seen anyone bother check their new history works.

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

#18

Post by ekidd »

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.

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

#19

Post by jlebrech »

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?

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

#20

Post by mugsie »

This is the type of workflow you get when using something like gerrit.

because gerrit forces every change to be a single commit, you have to rebase, which ensures that the history is nice and linear.

I know there is some people who prefer the "git-flow" style history graph (and I was one of those people) - but there is a lot of advantages to a clean history.

And, yes gerrit can be painful at first, but is a lot better with something like git-review[0], or repo[1]

0 - https://docs.openstack.org/infra/git-review/

1 - https://source.android.com/source/using-repo

Post reply on HN