StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
18859129
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
3
CommunityOwnedDate
CreationDate
2013-09-17T20:16:55.540
FavoriteCount
0
LastActivityDate
2017-12-07T18:24:41.853
LastEditDate
2017-12-07T18:24:41.853
LastEditorUserId
274502
OwnerUserId
274502
ParentId
1491001
PostTypeId
2
Score
6
ViewCount
0
LastEditorDisplayName
text
Body
As mentioned in the other answer comments, in practice each commit is unique and rewriting history will make new commits. You can think of it as cutting off the branches of a tree and then instantly growing new ones. They may even look the same but aren't. Yes, voodoo magic. In this analogy, reverting would be almost like supporting a falling branch with a log, so it will grow its way without falling down. That leads us to <a href="https://git-scm.com/book/en/v1/Git-Tools-Rewriting-History" rel="nofollow noreferrer">a couple good reasons to rewrite history</a>: <ul> <li>Slim down a private repository before going public: for instance, create a new local private branch, test, test, rewrite, push.</li> <li>Remove sensitive data from a private repo before going public.</li> </ul> Those already reveal what Greg already said: rewriting history <a href="https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#problems-With-rewriting-history" rel="nofollow noreferrer">will potentially screw up everyone</a> if the repository is public (pushed commits). Reason why I also advocate on avoid doing it at all costs even in private repos, just to keep the good habit: and so rewriting history should be avoided at all costs (this means to just give enough consideration before doing it: weight up the pros and cons!) And there is at least another philosophical and overlooked reason: rewritten history is data lost. True, a git history with <code>revert</code> might look messier than a <code>reset</code> one. But if properly written, all that "mess" can be hidden away in separated branches and still we can see precisely at what point a revert was done. And even with reasons or evidence as to why it was done. Back to the tree analogy, even if you do remove the supporting log, the reverted branch will show the sinuous growing curves, and it is beautiful!
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhat are the practical consequences of rewriting GIT history?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. UScregox
UserOwnerUserId
1. UScregox
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.