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

How I learned to love rebase

pyladies.com

Post reply on HN
Print view View original

31–40 of 56 posts

Re: How I learned to love rebase

#31

Post by Wilduck »

sophacles wrote: post #15
GilbertErik wrote: post #2

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?

> 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.

Re: How I learned to love rebase

#32

Post by [deleted] »

neebz wrote: post #25

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.

[deleted]

Re: How I learned to love rebase

#33

Post by antris »

neebz wrote: post #25

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.

> 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.

Re: How I learned to love rebase

#34

Post by kevinthew »

jakub_g wrote: post #13
ineedtosleep wrote: post #7

Earlier quoted context omitted.

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).

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

Completely garbage to me as well. Chrome 25 on Windows. Looks like hieroglyphs.

Re: How I learned to love rebase

#35

Post by jlatt »

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.

Re: How I learned to love rebase

#36

Post by antris »

threedaymonk wrote: post #28
neebz wrote: post #25

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.

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.

Re: How I learned to love rebase

#37

Post by michaelmior »

neebz wrote: post #25

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.

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.

Re: How I learned to love rebase

#38

Post by enoch_r » 

    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.)

Re: How I learned to love rebase

#39

Post by snprbob86 »

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.

Re: How I learned to love rebase

#40

Post by base698 »

pkteison wrote: post #20

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 r…

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.

Post reply on HN