How I learned to love rebase(pyladies.com)
pyladies.com
How I learned to love rebase
http://www.pyladies.com/blog/how-I-learned-to-love-rebase/
9 comments
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?
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?
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)
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)
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.
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.
> 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.
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.
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.
There probably ought to be some general principle of web design here: don't get fancy with stuff you can't support. If you don't have a wide range of devices for browser testing, that's OK: just stick to the standard fonts that work everywhere. If you are going to get fancy, do it right, and test exhaustively.
I know everyone opts for fancy, though!
I know everyone opts for fancy, though!
yes, probably.
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.
http://i.imgur.com/XcqHLyE.png
Was about to post the same complaint :)
Was about to post the same complaint :)
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.
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.
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.
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.
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.
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.
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.
http://imgur.com/TAQBRcV
I'd rather it just be left at default, but at least it's readable.
Could this be a Windows-only issue? I found that it was unreadable on Firefox 19, Opera 12.02 and Chrome on Windows 7.
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.
It's a shame because Quicksand looks like a great Sans Serif font. I hope that the immediate repulsion I felt when I opened this article doesn't detract from people reading the great gentle introduction to using rebase.
It's just a normal unreadable article in Chrome on OSX. On Chrome on Windows something's broken.
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).
Here the glyphs are rendered fine, but the kerning is really bad.
Same here, can barely read it so I sent it to Pocket to read later.
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.
Indeed. Completely unreadable on both Chrome and Firefox, on Ubuntu. Had to use ireader.
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.
git reflog
git reflog
git reset --hard ${old commit hash}
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.)
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.
Given this grace period, disabling AGC altogether is probably overkill, but there is nothing wrong with that, if it's really what you prefer.
I hadn't realized--thanks for the tip!
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.
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.
> 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>
<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>
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.
Or you know, you could just spend a few hours learning about how a tool you're probably going to be using for over a decade works.
>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
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
> 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`.
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`.
Interesting point, I will try to take this attitude and approach and see how I like it.
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.
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.
A merge creates a new commit that doesn't effect history so it's always safe to merge.
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.
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.
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).
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.
Rebase is really good especially when you are contributing in open source repositories but our experience has been limited in our private repositories.
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.
Even better is avoiding shared branches and just rebasing locally, merging to master whenever a task is complete.
I frequently push work-in-progress branches as insurance. If my SSD dies, or I get mugged on the way home, I'll still have the code tomorrow.
There's two possible answers:
1. Your are not merging to master often enough. If you split your tasks and use environment flagging effectively, there's no reason why you wouldn't want to merge to master on a daily basis.
2. If you absolutely need to diverge from master so much that you have many days of work sitting on your hard drive, you should be pushing to a non-shared repository in that case, or use other form of backup.
1. Your are not merging to master often enough. If you split your tasks and use environment flagging effectively, there's no reason why you wouldn't want to merge to master on a daily basis.
2. If you absolutely need to diverge from master so much that you have many days of work sitting on your hard drive, you should be pushing to a non-shared repository in that case, or use other form of backup.
Generally, I'm merging to master frequently (several times an hour). Things like upgrading Rails can be multi-day odysseys, however (even though there's sometimes an opportunity to make compatibility changes in master).
However, I don't see WIP branches as a problem, and certainly not one that justifies setting up additional repositories or backup systems just to avoid. If I'm working for someone else, it's not my place to set up shadow repositories all over the place, either.
However, I don't see WIP branches as a problem, and certainly not one that justifies setting up additional repositories or backup systems just to avoid. If I'm working for someone else, it's not my place to set up shadow repositories all over the place, either.
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".
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".
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!
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!
> 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.
I think your fundamental problem is trying to use git for task management. There's better software for doing that, e.g. Trello.
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.
[deleted]
> 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.
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.
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.
I like to `merge --squash` when I bring it back into master to keep things real tidy.