How I learned to love rebase
pyladies.com
pyladies.com
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)
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.
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.
I know everyone opts for fancy, though!
Was about to post the same complaint :)
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 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.
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.
I'd rather it just be left at default, but at least it's readable.
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.)
Given this grace period, disabling AGC altogether is probably overkill, but there is nothing wrong with that, if it's really what you prefer.
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.
<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>
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
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`.
A merge creates a new commit that doesn't effect history so it's always safe to 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.
- 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 really good especially when you are contributing in open source repositories but our experience has been limited in our private repositories.
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.
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.
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".
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 think your fundamental problem is trying to use git for task management. There's better software for doing that, e.g. Trello.
> 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.