7 ms·
But some of us use git-rebase every day perfectly fine and never lose information. Yes, you must be careful. No, you should never use it on public commits. I w
by tanderson92 10y ago
But some of us use git-rebase every day perfectly fine and never lose information. Yes, you must be careful. No, you should never use it on public commits.
I wouldn't recommend it to others as I don't trust them to read the man page and understand what git-rebase does. Those of us who use git-rebase also know how to recover the refs since before they are GCed, though I've never had to do that.
It's dangerous to pronounce certain powerful features of a system as off limits for day to day private use. That's a different pronouncement than a decision not to share "why everyone should use git-rebase often".
- rralian 10y agoAnd we use git-rebase commonly on public commits without concern. Everyone uses git differently.
- K0nserv 10y agoI think this depends on your definition of public? For me public means "in stable branches". I sure hope you aren't rebasing master
- dimino 10y agoThat's a weird definition of 'public'; for most folks, I imagine 'public' to mean anything accessible without any authorization.
- _ikke_ 10y agoWhen people talk about public commits it means commits other people have access too, and more specific, were able to commit on top. Authorization has nothing to do with it. In practice it means anything you have pushed. An exception can be made for topic branches, especially in a pull-request workflow. These branches could be rebased / amended to update the final result, even after they have been pushed already.
- dimino 10y ago"commits other people have access to" That's authorization.
- _ikke_ 10y agoYou said: > anything accessible without any authorization. Even if it does require authorization, it's considered public in regard to this discussion.
- dimino 10y agoIt's not public if the public can't read it (requires authorization). Why is this a conversation?
- mbrameld 10y agoBecause you've applied a different definition of public that doesn't fit the context. Public in the context in which it was used in this thread regarding git commits simply means commits you have pushed to a repo that another developer can access even if authorization is required to access it.
- dimino 10y agoThat's not what public means, though, in any context.
- _ikke_ 10y agoWhat we are talking about is whether or not you should rewrite public history. The technical reason is based on the fact if others have access to this history or not. It does not matter if you pushed it to a private repository where some other people still have access to; they might have fetched that history and committed on, which causes unexpected results when you rewrite such a branch. I tend to use published history / commits for this reason to make it less confusing.
- K0nserv 10y agoYeah maybe public isn't a good term for it, I usually use the term stable. So any pushed commits are indeed public, but they are only stable when they reach a stable branch. This means that if I am working on a branch I may remove, add, amend, reorder commits even after I've pushed them. If you constrain rebasing only to unpushed(not public) commits then you instead end up discouraging pushing code to the remote.
- weaksauce 10y agoIf you are planning on doing some tricky rebase with possible problems you can just create a branch before you rebase on the old head. delete the branch when you know the rebase is successful. Then you don't have to deal with the reflog at all.