Safe is not a good word for rebase.
It's a tool, and a fairly sharp double-edged one at that.
Use with care.
Rebase Is Safe
11–20 of 28 posts
Re: Rebase Is Safe
#12Earlier quoted context omitted.
Because it's awesome to alter history and push your changes when working with other people! Yay!
This is why people don't like rebase, but if you just tell people "never start a rebase farther back than master" the problem magically goes away. Tada!
I'd add that it's only a problem as team size grows. If the only other people who might be affected are sitting nearby, I can say "has anyone pushed since " and happily push -f my rebase in most cases.
Re: Rebase Is Safe
#13I 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.
> I simply don't buy this "cleaner" (and incorrect) history argument.
Incorrect how? Incorrect in that it doesn't reflect the exact way that history was constructed locally? Spoiler: it rarely does. Every —amend, every usage of a queue (MQ, Quilt, …), every patchbomb sent to a mailing list means the history recorded won't exactly reflect the way it was created. And that's for the better: history should be crafted for sense, not for useless historical correctness.
Re: Rebase Is Safe
#14Earlier quoted context omitted.
Because it's awesome to alter history and push your changes when working with other people! Yay!
This is why people don't like rebase, but if you just tell people "never start a rebase farther back than master" the problem magically goes away. Tada!
It's even simpler and more general than this: don't rewrite public history. There, you're done.
Re: Rebase Is Safe
#15tell me again why we NEED rebase?
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"
git rebase -i origin/master
Now that feature can be published for review. I happen to have setup gerrit for this purpose, but for git.git, you'd use format-patch and you'd email the patches, and that works well too. Each patch needs to be small enough that your reviewers aren't overwhelmed by it. (Smaller commits also help later on if someone has to git blame your code, or if they have to deal with conflicts when merging with your code.)
Rebase is also how you'd incorporate feedback to your patch series. Typically I'll put the correction on-top of my patch series, then squash it into place with rebase -i.
Finally, once your feature is done/done:
git fetch
git checkout master
git reset --hard origin/master # I use master only for integration
git merge --no-ff feature
git push origin master
$0.02.
Re: Rebase Is Safe
#16tell me again why we NEED rebase?
To track a remote SVN repository. To edit commits earlier in history when you need to correct minor bugs/CR comments/commit descriptions. Edited to add: squashing lots of tiny safety commits into a commit with an entire feature in it.
The svn issue seems under-appreciated. In my experience, far and away, the best way to merge subversion branches is to pull them in with git-svn, rebase, and push back to subversion. I've done this more than once for projects that I'm only tangentially involved with.
Re: Rebase Is Safe
#17tell me again why we NEED rebase?
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 look super-nice when I publish it to the world!" Fair enough. Then edit your meta-history since that is what the VCS will send. Right now, you can already do this in GIT by creating a specific branch and pushing only IT. Can't you? So why rebase
Re: Rebase Is Safe
#18tell me again why we NEED rebase?
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.
Re: Rebase Is Safe
#19Earlier 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…
There's More Than One Way To Do It. Some people find rebase more convenient, some people cherry-pick commits onto another branch, or squash merge them into another branch and merge that into master. Or whatever. Git is fast and powerful in part because it's really stupid. Building another layer of "meta-history" into git would complicate things immensely.
Re: Rebase Is Safe
#20Earlier 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.
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 chance to look at it.