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

51–56 of 56 posts

Re: How I learned to love rebase

#51

Post by threedaymonk »

antris wrote: post #36
threedaymonk wrote: post #28

Earlier quoted context omitted.

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.

Re: How I learned to love rebase

#52

Post by threedaymonk »

shuzchen wrote: post #42
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 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 wh…

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!

Re: How I learned to love rebase

#53

Post by threedaymonk »

jarrighi wrote: post #41
sophacles wrote: post #15

Earlier quoted context omitted.

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?

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!

Re: How I learned to love rebase

#54

Post by aaronblohowiak »

snprbob86 wrote: post #48
aaronblohowiak wrote: post #45

Earlier quoted context omitted.

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

Interesting point, I will try to take this attitude and approach and see how I like it.

Re: How I learned to love rebase

#55

Post by antris »

threedaymonk wrote: post #51
antris wrote: post #36

Earlier quoted context omitted.

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.

Re: How I learned to love rebase

#56

Post by threedaymonk »

antris wrote: post #55
threedaymonk wrote: post #51

Earlier quoted context omitted.

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

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.

Post reply on HN