StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
3766219
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2010-09-22T04:04:46.837
FavoriteCount
0
LastActivityDate
2010-09-22T04:14:10.267
LastEditDate
2010-09-22T04:14:10.267
LastEditorUserId
193688
OwnerUserId
193688
ParentId
3720882
PostTypeId
2
Score
2
ViewCount
0
LastEditorDisplayName
text
Body
<code>git rebase</code> is working correctly. It is protecting your untracked file from being destroyed while visiting a commit that wants to write out a file with that same pathname. There does not seem to be a way to retry just the most recent step of the rebase. Usually when a rebase pauses, it will leave conflicts in the index. But in this case, it can not flag this problem in the index because doing so would convert your untracked file into a tracked file. This is probably a bit of a rough spot in the UI of <code>git rebase</code>. You could dig into the directory it uses to store its internal state (<code>.git/rebase-apply</code>) and manually apply the “current” patch, but aborting and restart is probably easier (but maybe not faster if you are in the middle of rebasing a very long series). <hr> If the addition of <code>bar.txt</code> is considered a mistake, then you might consider using <code>git rebase -i</code> to tease apart and drop the addition and removal of <code>bar.txt</code> since you are rewriting history anyway. You will still run into the conflict, but the methods below can also be applied with <code>git rebase -i</code>. The script at the end would have to be split into two parts (“setup <code>temp/</code>” and “incorporate rebase result” since an interactive rebase will usually require multiple commands between those two sections. <hr> Move the conflicting file aside temporarily and redo the rebase. <pre><code>mv bar.txt +bar.txt git rebase --abort git rebase master </code></pre> If you expect many such conflicting files then you might consider doing your rebase in a separate clone where you can be certain that you will not have any untracked files. Perhaps the trickiest part is checking that your untracked files do not conflict with the result of the rebase (the <code>git checkout rebased-topic</code> accomplishes this; it aborts if the untracked files conflict with the rebase result). <pre><code>: "Note: will destroy : * 'rebased-topic' branch : * 'temp' directory" ( set -x && : '*** Clearing temp/' && rm -rf temp/ && : '*** Making sure we have topic checked out' && git checkout topic : '*** Cloning into temp/' && git clone . temp && : '*** Rebasing topic onto master in temp/ clone' && ( cd temp && git rebase origin/master ) && : '*** Fetching rebase result from topic/ into local rebased-topic branch' && git fetch -f temp topic:rebased-topic && : '*** Checking rebased-topic for conflicts with untracked files' && git checkout rebased-topic && : '*** Resetting topic to tip of rebased-topic' && git branch -f topic rebased-topic && : '*** Returning to topic branch' && git checkout topic && : '*** Deleting rebased-topic branch' && git branch -d rebased-topic && : '*** Deleting temp/' && rm -rf temp/ ) </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POgit rebase, "would be overwritten", and "No changes - did you forget to use 'git add'?"
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USChris Johnsen
UserOwnerUserId
1. USChris Johnsen
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. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COIn my situation, the only reason the file is untracked is because of the rebase rewind. Shouldn't rewind delete files that weren't tracked in earlier commits? There would be no data loss.
 singulars
 PostPostId
 PO
 UserUserId
 USShannon
2. CO@rehevkor5: I am not sure of the details of your situations, but if (for example) you have sequential commits A, B, C, and D where only the last one has the file `frob` (i.e. it was initially added in D and nowhere else), then Git *will* (temporarily) remove `frob` while rewinding to rebase D onto some other base (e.g. a modified B). The situation of this question is a bit more complicated; if you have some specific situation in mind, you might want to open a new question with the details.
 singulars
 PostPostId
 PO
 UserUserId
 USChris Johnsen

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.