How I learned to love rebase

http://www.pyladies.com/blog/how-I-learned-to-love-rebase/

by roguelynn • 13 years ago

34 54 13 years ago

GilbertErik3• 13 years ago

Sorry to nag, but I haven't yet brought myself to make it past the first paragraph. Maybe it looks elegant or classy on someone else's screen, but I had to go re-enable Evernote Clearly just to be able to read it. Am I the only one?

corresation• 13 years ago

Chrome 25 on Windows here and the same problem -- the font has extraordinarily poor hinting (or Chrome is malfunctioning), leading to critical elements of the text being discarded at that size.

GilbertErik3• 13 years ago

https://docs.google.com/file/d/0B_sHgQoVOruvTmJjdHlWUTk4dGM/...

Ya know what. It looks fine in Firefox, but that font looks like garbage rendered in Chrome. I don't know if it's the font-family or the font-size, but something's making me want to scratch my eyes out or make me want to kill my screen with fire.

It's probably an unfair generalization to assume that all female Python developers don't use Chrome.

mimiflynn2• 13 years ago

You're right, it is unfair to generalize that all female Python developers don't use Chrome. Wonder if it looks better on a Mac in Chrome; it looks terrible in Chrome on Windows.

MBCook• 13 years ago

Wow. I'm on Safari in OS X and it doesn't look anything like that. No wonder you guys are having trouble reading it.

http://imgur.com/TAQBRcV

I'd rather it just be left at default, but at least it's readable.

mimiflynn2• 13 years ago

Same here, can barely read it so I sent it to Pocket to read later.

ineedtosleep• 13 years ago

Chrome and thin fonts don't mix well. That said, I still don't understand why people use thin fonts for body copy. It reduces readability so much (even on FF where the rendering is fine).

jakub_g• 13 years ago

Curiously for me it's garbage in Firefox 19 and normal (except kind of gray-on-gray) in Opera 12 and Chrome 25.

nightpool• 13 years ago

Not just Chrome: It's pretty terrible on older Firefoxes too. Firefox 16 here, and while it's not as bad as Chrome, its not very great either.

DoggettCK• 13 years ago

The content of the article was great, but I had to remove the font-family style from the body tag with Firebug due to the way Firefox was handling aliasing on the font.

Aside from that minor nitpick, I learned something new and valuable, so it's worth reading if you don't already know about git rebase.

krelian• 13 years ago

Chrome's Windows font rendering rears it's ugly head again. While the fault here is entirely with Chrome I still don't understand how so many people (and even some high profile projects/organizations) choose to use those web fonts which are unreadable in Chrome.

Jenk• 13 years ago

http://i.imgur.com/XcqHLyE.png

Was about to post the same complaint :)

sophacles• 13 years ago

Sorry to rant, but I haven't yet brought myself to understand this position. Maybe it makes sense to designers or snobs but I have go calm down for a while just be able to reply. Am I the only person who thinks that ignoring good content to complain about formatting choices is vacuous at best?

parsnips• 13 years ago

yes, probably.

Wilya• 13 years ago

We need a "hide comments complaining about font" userscript.

Seriously, it's the third perfectly fine article I read today where a quite high voted comment (with tons of children comments) is "I hate to be that guy, but your text has bad kerning on [some precise browser version].

(on the other hand, this one might be justified. Just checked on Chrome, and all the 't's miss their bars. It might qualify as unreadable. My (and your) point still stands for 99% of the other such complaints, though)

swanson• 13 years ago

Take a look at some of the screencaps below (or mine here: http://i.imgur.com/XpVhDMx.png Chrome/Win7) - this isn't the typical "omg don't use dark gray on light gray". The "t" and "l" are in distinguishable, so it is pretty hard for me to actually read.

I'm sure it looks fine in the authors browser/OS of choice, but it is not usable in mine - regardless of the merits of the content.

Wilduck• 13 years ago

> Am I the only person who thinks that ignoring good content to complain about formatting choices is vacuous at best?

No, you're not. I would much rather read high quality discussion about the content at hand. However, I'm reading using Chrome on Windows 7, and I literally had to open the developer console and change the font to be able to read the article. Like others have mentioned, it wasn't just hard to read, some of the characters were actually indistinguishable.

When readability gets that bad, I think it make sense for the topic to show up in these comment threads. Maybe someone will be around to fix the issue. Maybe others will learn about what happens when you don't test a site in different browsers.

jarrighi• 13 years ago

It is good to be alerted that the font isn't rendering properly on Windows Chrome, though. I think most of the PyLadies who use Chrome are on Mac or Linux, and the current design of the site is relatively new. Now we know we need to fix this.

lloeki• 13 years ago

Here the glyphs are rendered fine, but the kerning is really bad.

lucian1900• 13 years ago

Indeed. Completely unreadable on both Chrome and Firefox, on Ubuntu. Had to use ireader.

throwawayG9• 13 years ago

I only use Firefox and Liferea (when I find a good RSS to add), so I had to close this article because it was unreadable (I don't have other software to "fix" blogs, like the other commenters).

I don't see anything wrong with complaining about this. It's feedback for the author. Would you not complain if someone posted an invisible article, to which you need to apply some trick to make it appear? Would you not want to know why potential readers/subscribers are bouncing?

Another thing I usually hate in these blogs: small fonts. But at least I can just do ctrl+, so I never complain about that. But still hate it.

speg• 13 years ago

I like to `merge --squash` when I bring it back into master to keep things real tidy.

pkteison• 13 years ago

Can somebody try to explain what considerations go into picking between merge and rebase, or when rebase is a better option? The example here "you've branched that file and made some changes. Meanwhile, someone else has modified that same file on the master branch..." says 'merge' to me, and I'm not sure what consideration goes into the decision that rebase is the right tool instead. I've tried to google a bit, and read some posts on it on stack overflow, and it still just doesn't click for me.

newishuser• 13 years ago

You rebase to clean up your own, non-shared, local commit history. That is it. As soon as your commits are shared you can no longer rebase them or feel the wrath. If you don't care about cleaning up your local history, before you share it, then don't rebase.

A merge creates a new commit that doesn't effect history so it's always safe to merge.

base698• 13 years ago

My simple rule is if I'm on my feature branch that no one else is working off of, then I rebase. If I am working on a shared feature branch I merge.

Another good use case for plain merge is to play Dr. Frankenstein, combining many feature branches not yet in the main line to give an impromptu demo or see how the automated tests are shaking out.

jmount• 13 years ago

So there is no possibility that if it is rendering poorly in a particular browser it may be the browser's fault instead of the website? Good article, please shut up about the fonts.

j_s• 13 years ago

  > It's possible to be careful about rebasing code, say by duplicating the master 
  > branch and rebasing your code on that new version to see if you accidentally 
  > destroy the world before trying to rebase within the actual master.

Is it possible to ask 'What would you do if I rebased' without a test branch?

threedaymonk6• 13 years ago

You can always do "git rebase --abort" if you're stuck in the middle of a rebase, or, if you've rebased and don't like it, "git reflog" to find the previous state followed by "git reset --hard <hash>" to get back to where you were.

neebz• 13 years ago

Unfortunately rebase doesn't fit well with our team workflow (team is geographically distributed). we use branches and commits to check which user is on which task. everyone pushes code at the end of the day even if it's incomplete. Pushing code prevents rebase usage.

Rebase is really good especially when you are contributing in open source repositories but our experience has been limited in our private repositories.

threedaymonk6• 13 years ago

In your scenario, it sounds like you'd be better served by pushing the incomplete work to temporary branches. At least, if I were working with you, I'd rather have working code in master than a bunch of "git commit -am Hometime" dumps.

antris3• 13 years ago

Even better is avoiding shared branches and just rebasing locally, merging to master whenever a task is complete.

antris3• 13 years ago

> we use branches and commits to check which user is on which task. everyone pushes code at the end of the day even if it's incomplete

I think your fundamental problem is trying to use git for task management. There's better software for doing that, e.g. Trello.

michaelmior• 13 years ago

I occasionally do the same thing, but as long as I know no one else is working off the code I push, I still feel comfortable rebasing after pushing.

shuzchen• 13 years ago

I personally don't subscribe to the "you should never rebase commits that you have pushed to a public repository" tenant. For me it's more "you should never rebase commits that you have pushed to a repository other people use".

That is, your personal WIP branches are fine, so long as you're the only person that pushes/pulls from it. These WIP branches should be labeled in such a way that the team knows at a glance which are WIP.

This also means your team members need to get used to doing a `git push -f`, as well as making sure their push.default is configured to "current".

threedaymonk6• 13 years ago

Rather than normalising the rather risky behaviour of "push -f"ing all the time, I think it's probably better to treat WIP branches as linear and refrain from reorganising/reordering/squashing until you're ready to merge them into a shared branch.

I'm with you on the push.default = current, though. I'd forgotten that wasn't standard, I've had it in my .gitconfig so long. I can't see why you'd want anything else!

jlatt• 13 years ago

I do not understand why these metaphorical articles persist. They do not help anyone understand the procedure, which is simple:

    - Walk the commit tree backwards to the specified rebase point, writing each commit as a temporary diff file.
    - Set the current working space to the rebase target commit/hash/tag like `git reset --hard $commit`.
    - Apply each diff file in forwards order (that's the reverse of the  way diffs were generated in the first step).

Rebase is just a good shorthand for moving sequences of commits and (potentially interactively) resolving conflicts along the way.

enoch_r2• 13 years ago

    git reflog

Before I learned that command, I'd seen git as a backup tool with some scary options for manipulating history that I didn't want to touch for fear they'd blow up on me. After learning about git reflog, I finally understood that this was like being scared of pressing backspace on the keyboard. Yes, it can erase commits you really really needed--but all you need to do to get them back is:

    git reflog

(to find the commit hash you want to get back to), then

    git reset --hard ${old commit hash}

to get to it.

Now, without any reason to fear experimentation, I can use git like it's meant to be used. I can edit my local history without fear, then push it to the remote repo.

(One reason to still stay slightly cautious--some git commands run garbage collection automatically, and garbage collection will destroy any disconnected commits. Running "git config --global gc.auto 0" will fix this--I prefer to manage the garbage collection myself anyway, personally.)

tmhedberg• 13 years ago

Automatic garbage collection won't destroy any unreachable objects less than 2 weeks old. This is the default time window; you can override it via the `gc.pruneexpire` config option.

Given this grace period, disabling AGC altogether is probably overkill, but there is nothing wrong with that, if it's really what you prefer.

enoch_r2• 13 years ago

I hadn't realized--thanks for the tip!

snprbob863• 13 years ago

I don't understand why anyone considers rebase to be scary. It's really quite simple:

Primarily, rebase is a tool for modifying patches. Patches are as much about communication as they are about modifying code.

You edit your emails before you send them, so why not your patches? You proof read your edited emails before you send them, so why wouldn't you test rebased patches?

There are plenty of reasons to use rebase and as many advanced use cases as there are git enthusiasts. However, it's not "rewriting history" because you've always got reflog and cryptographically secure version hashes. It's not any more scary to rebase than it is to "undo" and subsequently "redo" in your text editor. The only caveat is that you shouldn't rebase code on branches that you've shared publicly for the exact same reasons that you shouldn't publish version 3.2.1 and then re-publish it with a bug fix without calling it version 3.2.2.

alinajaf2• 13 years ago

> The only caveat is that you shouldn't rebase code on branches that you've shared publicly for the exact same reasons that you shouldn't publish version 3.2.1 and then re-publish it with a bug fix without calling it version 3.2.2.

<rant>

When one is on a development team that doesn't really understand how rebase (or git for that matter) works and are suitably trigger happy with `git pull --rebase`, this itty bitty caveat makes origin a minefield when working with branches.

In that situation, one would honestly wish one were using svn instead. Then at least one could use git-svn locally and treat trunk as origin/master, which is what ones team really wants.

</rant>

snprbob863• 13 years ago

This is where smaller code projects with clearer dependencies come in to play. You can designate maintainers, integrators, reviewers, etc on a per-project/per-boundary basis. This means that failure to understand rebase has severely localized effects. As a bonus, you'll get better factored code backed by developers with an enhanced sense of ownership.

aaronblohowiak2• 13 years ago

>it's not "rewriting history" because you've always got reflog and cryptographically secure version hashes

To avoid having to go to the reflog, you can follow this simple procedure: branch before rebase. Then when you're comfortable, just change the branch to point at the new ref. This is the rename(2) approach to rebasing :D

snprbob863• 13 years ago

> To avoid having to go to the reflog

Why should I avoid having to go to the reflog?

I've met a few folks that, upon learning about reflog, think that every time they run `git reflog` they are admitting that they made a mistake or have otherwise failed to accomplish some task with Git. It's not a failure to need reflog; even if it was, you shouldn't have such an aversion to failure. I frequently run reflog to re-orient myself just like I do with `git log` or `git status`.

How I learned to love rebase

Related Stories