3 ms·

Whether a branch is private and therefore can be rebased has nothing to do with whether there's a copy of it on the server. I push my work-in-progress to the se

by gruseom 15y ago

Whether a branch is private and therefore can be rebased has nothing to do with whether there's a copy of it on the server. I push my work-in-progress to the server often for backup purposes anyway. If I want to rebase, I just push -f. I can't think of why that would be a problem, but if someone objected to push -f on a private branch, I'd just make a new branch with a new name and push that. And if that were a problem, I'd just find another server to push -f to and only ever commit to master on the official server. But these are silly workarounds. Why make things harder than they need to be?

andrew311 15y ago
This is true. If the assumption is that it's a private branch, then other people shouldn't care if you push -f because no one else should be using it. Sometimes there are cases where people want to pull a private branch because they are working on something that is in the same code path but will be deployed after the private branch is integrated and deployed. They want to work off the newest code and avoid a larger merge to their private branch later. Would rebasing that private branch make their life harder? If so, one could always stage changes in a feature branch at stable points for them. Thoughts? Basically, my understanding is that push -f can be a hassle for others to pull if they made commits to the same branch already. You're totally right that if it's truly a private branch, though, this should be irrelevant.
- gruseom 15y ago
  If someone wants to work off my private stuff I would tell them "sure, but be careful cause I'm push -f'ing" (after all, it's usually pretty easy to fix) and give them a heads-up when I do. If that weren't acceptable, I'd add a tag like "stable" to my branch, tell them to use it only up to that tag, and move the tag forward as the work progresses. If that weren't acceptable I'd make a branch instead of a tag and tell them to use that.
  - andrew311 15y ago
    Thanks! Excellent advice.

by gruseom 15y ago

andrew311 15y ago

This is true. If the assumption is that it's a private branch, then other people shouldn't care if you push -f because no one else should be using it. Sometimes there are cases where people want to pull a private branch because they are working on something that is in the same code path but will be deployed after the private branch is integrated and deployed. They want to work off the newest code and avoid a larger merge to their private branch later. Would rebasing that private branch make their life harder? If so, one could always stage changes in a feature branch at stable points for them. Thoughts? Basically, my understanding is that push -f can be a hassle for others to pull if they made commits to the same branch already. You're totally right that if it's truly a private branch, though, this should be irrelevant.

gruseom 15y ago
If someone wants to work off my private stuff I would tell them "sure, but be careful cause I'm push -f'ing" (after all, it's usually pretty easy to fix) and give them a heads-up when I do. If that weren't acceptable, I'd add a tag like "stable" to my branch, tell them to use it only up to that tag, and move the tag forward as the work progresses. If that weren't acceptable I'd make a branch instead of a tag and tell them to use that.
- andrew311 15y ago
  Thanks! Excellent advice.