[_ikke_]

When 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]

"commits other people have access to"

That's authorization.

[_ikke_]

You said:

> anything accessible without any authorization.

Even if it does require authorization, it's considered public in regard to this discussion.

[dimino]

It's not public if the public can't read it (requires authorization).

Why is this a conversation?

[mbrameld]

Because 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]

That's not what public means, though, in any context.

[_ikke_]

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