StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
2960751
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
8
CommunityOwnedDate
CreationDate
2010-06-02T19:03:07.577
FavoriteCount
0
LastActivityDate
2014-08-30T05:47:17.863
LastEditDate
2017-05-23T12:18:08.593
LastEditorUserId
-1
OwnerUserId
6309
ParentId
2959443
PostTypeId
2
Score
214
ViewCount
0
LastEditorDisplayName
text
Body
That seems consistent with what a rebase does. <ul> <li><a href="http://git-scm.com/docs/git-svn" rel="noreferrer"><code>git svn rebase</code></a> will fetches revisions from the SVN parent of the current HEAD and rebases the current (uncommitted to SVN) work against it.</li> <li><a href="http://git-scm.com/docs/git-rebase" rel="noreferrer"><code>git rebase</code></a> does mention: Note that a rebase merge works by replaying each commit from the working branch on top of the <code><upstream></code> branch. Because of this, when a merge conflict happens: <ul> <li>the side reported as ours is the so-far rebased series, starting with <code><upstream></code>,</li> <li>and theirs is the working branch. In other words, the sides are swapped.</li> </ul></li> </ul> <blockquote> git rebase replays each commit from the working branch on top of the <code><upstream></code> branch. </blockquote> If you reconcile both definitions: <ul> <li>the commits coming from SVN are the ones on top of which local Git commits are replayed. They are part of the "so-far rebased series", and are referenced as "our" (in your case, the <code>test.txt</code> file with <code>bar</code> content)</li> <li>the working branch (containing Git commits unknown to SVN, in your case, the <code>test.txt</code> file with <code>baz</code> content) is "their", and each of those local Git commits are being replayed.</li> </ul> In other words, SVN or not: <ul> <li>the "<code><upstream></code>" branch (on top of which anything is replayed, and which is part of the so far rebased commits") is "ours".</li> <li>what is being replayed (the working branch) is "theirs".</li> </ul> <hr> Good <a href="https://stackoverflow.com/questions/25576415/what-is-the-precise-meaning-of-ours-and-theirs-in-git-especially-in-referen/25576672#comment39946814_25576672">mnemonic tip</a> by <a href="https://stackoverflow.com/users/811519/commatoast">CommaToast</a>: <blockquote> whatever HEAD's pointing to is "ours" </blockquote> (and the first thing a <code>git rebase upstream</code> does it to checkout the <code>upstream</code> branch on top of which you want to rebase: HEAD refers to <code>upstream</code> -- <code>ours</code> now.) <hr> The confusion is likely coming from the role of the working branch in a classic <a href="http://www.kernel.org/pub/software/scm/git/docs/git-merge.html" rel="noreferrer"><code>git merge</code></a>. When you are merging: <ul> <li>the "working branch" is the one containing what is "so far merged", and is considered as "our", </li> <li>while the other commit represent what is being -- not replayed but -- merge on top of the working branch, and considered as "their".</li> </ul> As the <code>git rebase</code> man page mentions, a merge during a rebase means the side are swapped. <hr> Another way to say the same thing is to consider that: <ul> <li>what we have on the checked out branch is 'ours',</li> <li>what we had (and is being merged or replayed) is 'theirs'.</li> </ul> <hr> On a merge: <pre><code>x--x--x--x--x(*) <- current branch B ('*'=HEAD) \ \ \--y--y--y <- other branch to merge </code></pre> , we don't change the current branch 'B', so what we have is still what we were working on (and we merge from another branch) <pre><code>x--x--x--x--x---------o(*) MERGE, still on branch B \ ^ / \ ours / \ / --y--y--y--/ ^ their </code></pre> <hr> But on a rebase, we switch side because the first thing a rebase does is to checkout the upstream branch! (to replay the current commits on top of it) <pre><code>x--x--x--x--x(*) <- current branch B \ \ \--y--y--y <- upstream branch </code></pre> A <code>git rebase upstream</code> will first change <code>HEAD</code> of B to the upstream branch <code>HEAD</code> (hence the switch of 'ours' and 'theirs' compared to the previous "current" working branch.) <pre><code>x--x--x--x--x <- former "current" branch, new "theirs" \ \ \--y--y--y(*) <- upstream branch with B reset on it, new "ours", to replay x's on it </code></pre> , and then the rebase will replay 'their' commits on the new 'our' B branch: <pre><code>x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs \ \ \--y--y--y--x'--x'--x'(*) <- branch B with HEAD updated ("ours") ^ | upstream branch </code></pre> <hr> The only extra step with <code>git svn rebase</code> is that a svn "fetch" is performed first on the Git remote branch representing SVN commits. You have initially: <pre><code>x--x--x--x--x(*) <- current branch B, "ours" for now. \ \ \--y--y--y <- SVN tracking branch, "theirs for now" </code></pre> , you first update the SVN tracking branch with new commits coming from SVN <pre><code>x--x--x--x--x(*) <- current branch B, still "ours", not for long \ \ \--y--y--y--y'--y' <- SVN tracking branch updated </code></pre> , then you switch the current branch to the SVN side (which becomes "ours") <pre><code>x--x--x--x--x <- for "B", now "their" during the rebase \ \ \--y--y--y--y'--y'(*) <- SVN tracking branch updated, and branch B: now "ours" (this is "what we now have") </code></pre> , before replaying the commits you were working on (but which are now "theirs" during that rebase) <pre><code>x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs \ \ \--y--y--y--y'--y'--x'--x'--x'(*) <- branch B with HEAD updated ("ours") ^ | upstream SVN tracking branch </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhy is the meaning of “ours” and “theirs” reversed with git-svn
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. USVonC
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POWhy is the meaning of “ours” and “theirs” reversed with git-svn
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUndeletion
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

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.