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

41–50 of 56 posts

Re: How I learned to love rebase

#41

Post by jarrighi »

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?

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.

Re: How I learned to love rebase

#42

Post by shuzchen »

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

Re: How I learned to love rebase

#43

Post by alinajaf »

snprbob86 wrote: post #39

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

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

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.

Re: How I learned to love rebase

#44

Post by tmhedberg »

enoch_r wrote: post #38

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…

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.

Re: How I learned to love rebase

#45

Post by aaronblohowiak »

snprbob86 wrote: post #39

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

>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

Re: How I learned to love rebase

#46

Post by throwawayG9 »

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?

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.

Re: How I learned to love rebase

#47

Post by snprbob86 »

alinajaf wrote: post #43
snprbob86 wrote: post #39

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

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

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.

Re: How I learned to love rebase

#48

Post by snprbob86 »

aaronblohowiak wrote: post #45
snprbob86 wrote: post #39

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

>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-orient myself just like I do with `git log` or `git status`.

Re: How I learned to love rebase

#49

Post by enoch_r »

tmhedberg wrote: post #44
enoch_r wrote: post #38

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…

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.

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

Re: How I learned to love rebase

#50

Post by alinajaf »

snprbob86 wrote: post #47
alinajaf wrote: post #43

Earlier quoted context omitted.

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

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.
Post reply on HN