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

Rebase Is Safe

blog.extracheese.org

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Rebase Is Safe

#21

Post by garybernhardt »

EGreg wrote: post #18
zrail wrote: post #6

Earlier quoted context omitted.

I commit a lot. A lot a lot. Sometimes those commits don't actually work for some reason. For example, when I leave for the day and I'm in the middle of a task, I like to leave a failing test so I have something to pick up on immediately when I get in for work in the morning. I fairly often commit this state. When it comes time for me to publish my changes, I very much do not want those unpublishable intermediary sta…

When you publish something to the world, don't you want to take a minute to make sure it's good? You do this when pushing to production, right? Well, then why not take the same care and simply create a new branch with only the "clean" commits, and then push that branch? I don't see a need for rebase. Don't rewrite your existing history, make a new branch to push to others! Like "tags" in svn.

You can just create a new branch before you start the rebase, which achieves exactly the effect you ask for. Rebase is how you "create a new branch with only the clean commits".

But, most of us don't bother copying before rebasing. The reflog makes that pointless from a safety perspective and, without the safety need, there's not much reason to copy before rebasing.

Re: Rebase Is Safe

#22

Post by zrail »

EGreg wrote: post #18
zrail wrote: post #6

Earlier quoted context omitted.

I commit a lot. A lot a lot. Sometimes those commits don't actually work for some reason. For example, when I leave for the day and I'm in the middle of a task, I like to leave a failing test so I have something to pick up on immediately when I get in for work in the morning. I fairly often commit this state. When it comes time for me to publish my changes, I very much do not want those unpublishable intermediary sta…

When you publish something to the world, don't you want to take a minute to make sure it's good? You do this when pushing to production, right? Well, then why not take the same care and simply create a new branch with only the "clean" commits, and then push that branch? I don't see a need for rebase. Don't rewrite your existing history, make a new branch to push to others! Like "tags" in svn.

Also, I almost always work on topic branches and do my rebasing there. This may be a crucial point that others have missed. Personally I don't rebase on master.

Re: Rebase Is Safe

#23

Post by EGreg »

zrail wrote: post #20
EGreg wrote: post #18

Earlier quoted context omitted.

When you publish something to the world, don't you want to take a minute to make sure it's good? You do this when pushing to production, right? Well, then why not take the same care and simply create a new branch with only the "clean" commits, and then push that branch? I don't see a need for rebase. Don't rewrite your existing history, make a new branch to push to others! Like "tags" in svn.

It's not like there are clean independent commits just floating around in there with the junk. It's the amalgamation of the junk that produces the clean commits, thus the need for rebase. As someone else in this thread talked about, being able to tweak my commit history has changed the way I've approached coding. I commit often because I know I'll be able to go back and rewrite history before other people have a chan…

I'm just asking, why can't you make a new branch and merge-commit every 3rd commit to it, with a better message? It would preserve the philosophical "involatility" of history.

Re: Rebase Is Safe

#24

Post by zrail »

EGreg wrote: post #23
zrail wrote: post #20

Earlier quoted context omitted.

It's not like there are clean independent commits just floating around in there with the junk. It's the amalgamation of the junk that produces the clean commits, thus the need for rebase. As someone else in this thread talked about, being able to tweak my commit history has changed the way I've approached coding. I commit often because I know I'll be able to go back and rewrite history before other people have a chan…

I'm just asking, why can't you make a new branch and merge-commit every 3rd commit to it, with a better message? It would preserve the philosophical "involatility" of history.

Ok, so the philosophical "involatility" is preserved, sure, but that's rather a large amount of work to do to preserve unworkable deadends and silly commit messages and broken builds and the like.

Also, it introduces a huge non-linear mess into the commit history that can be hard to untangle. Just looking at topic branches in a normal tree with gitk can be hard. Can you imagine looking at topic branches and these junk branches at the same time?

Re: Rebase Is Safe

#25

Post by __david__ »

EGreg wrote: post #18
zrail wrote: post #6

Earlier quoted context omitted.

I commit a lot. A lot a lot. Sometimes those commits don't actually work for some reason. For example, when I leave for the day and I'm in the middle of a task, I like to leave a failing test so I have something to pick up on immediately when I get in for work in the morning. I fairly often commit this state. When it comes time for me to publish my changes, I very much do not want those unpublishable intermediary sta…

When you publish something to the world, don't you want to take a minute to make sure it's good? You do this when pushing to production, right? Well, then why not take the same care and simply create a new branch with only the "clean" commits, and then push that branch? I don't see a need for rebase. Don't rewrite your existing history, make a new branch to push to others! Like "tags" in svn.

This is the difference between distributed VCSes and centralized ones like svn.

When I create a change/feature it usually ends up being separated into multiple commits--usually some generic feature change somewhere followed by the specific changes for whatever I'm doing. In the centralized world I'd just work in my directory for a week and then go through and parse out the changes and check them in (generic first, then specific).

With git I can check them in early but not push them. They exist as living breathing patches while I work on it. I'll amend and rebase them like crazy. After everything is tested and working I push the set up to the main repo so others can get at them.

The important thing is that you don't amend/rebase the main repo. That is messing with history and is annoying to anyone who already grabbed the original changes. But messing with your local repo isn't rewriting history--it's not history yet. It's a set of changes that are still in progress.

Re: Rebase Is Safe

#26

Post by __david__ »

zrail wrote: post #22
EGreg wrote: post #18

Earlier quoted context omitted.

When you publish something to the world, don't you want to take a minute to make sure it's good? You do this when pushing to production, right? Well, then why not take the same care and simply create a new branch with only the "clean" commits, and then push that branch? I don't see a need for rebase. Don't rewrite your existing history, make a new branch to push to others! Like "tags" in svn.

Also, I almost always work on topic branches and do my rebasing there. This may be a crucial point that others have missed. Personally I don't rebase on master.

Why not? The end result is exactly the same. You have a little branch of your work and then when you pull next time it gets merged back in. You can even create a named branch for it after the fact by sticking the hash into .git/refs/heads.

Re: Rebase Is Safe

#27

Post by __david__ »

EGreg wrote: post #17
js2 wrote: post #15

Earlier quoted context omitted.

For the same reason you refactor code, it is often useful to refactor your commit history _before_ you publish it. And just because you use rebase, doesn't mean you don't also merge. I often use git like this: git checkout -b feature origin/master while not done with feature: edit, save, commit -am "added blah" My commits are so small that I can write the entire commit message on the command-line. When feature is don…

IMHO, a version control system shouldn't provide facilities for people to edit the history, but instead, to edit meta-information about the history. What git needs is probably a meta-history that gets aggregated during pushes. But if you wanted to see all of your own warts, you should be able to, for the philosophical reason that a VCS isn't supposed to let you "cheat". "But," you say, "I want to prepare my patch to…

I think what people with your opinion are missing is that in a VCS without rebase/amend capabilities all that happens is people like me commit way less often. That is, I get everything working and fully tested and only then start checking in my code. With git I can commit almost immediately, before everything is tested and working. It allows me to start organizing the patches early and keep them up to date as I finish doing the task at hand. In that sense it is not rewriting history. I'm creating history. I don't push my code to the central repo until it's done and after that it doesn't get rebased.

Should I start committing every single version of the code I've ever saved so I can see all my false starts and typos? Maybe but there's not a lot of good information to be had there.

Re: Rebase Is Safe

#28

Post by rlpb »

dfox wrote: post #3

I simply don't see how this effort to use rebase instead of every merge helps anything. While there are valid uses for rebase I simply don't buy this "cleaner" (and incorrect) history argument.

It all depends on what you use git for. git is a great tool for revision control, but it is also a great tool for managing your own work, where it becomes closer to being an editor function than a revision control tool.

When I wrote an essay at school, I was taught to write a draft first, and sometimes a second draft. I typically wasn't expected to hand the drafts in.

When I write code in an editor, I don't save a history of every keystroke, yet I do commit often. In a way, I formalise the undo function of my editor slightly, but it becomes logical-change centric rather than keystroke-centric.

If you treat git as a tool to develop your own work as well as to manage the project revision history, then it makes perfect sense to draw the line somewhere. For work before that line (eg. experimental commits or reworking a patch for upstream submission), use rebase. For things on the other side of the line, use merge. Ruling out one side of this line entirely is just counter-productive.

Another example: git was written for open source projects. It is typically expected in these environments that patch submissions are coherent and complete. Nobody wants to see the mistakes that you correct and then fixed; they want to see patches that make sense and are easy to review. Rebasing is great for this.

Post reply on HN