StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
19108438
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2013-10-01T05:10:13.523
FavoriteCount
0
LastActivityDate
2013-10-02T15:53:10.613
LastEditDate
2017-05-23T12:28:30.743
LastEditorUserId
-1
OwnerUserId
1256452
ParentId
19084880
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
OK, let's tackle a different "reasonably precise" definition based on the question-edit. Given: <ul> <li>merge commit <code>M</code></li> <li>with final tree <code>T</code> containing files <code>f1</code>, <code>f2</code>, ..., <code>fn</code></li> <li>and immediate parents <code>p1</code>, <code>p2</code>, ..., <code>pn</code></li> </ul> you want—regardless of additional possible ancestry1—all files <code>fi</code> where, given any two different parents <code>pa</code> and <code>pb</code>, <code>fi</code> was "modified" in both <code>pa</code> and <code>pb</code>. The definition of "modified" here is that for a commit <code>p</code> and file <code>f</code>, <code>p</code> itself has one single parent, <code>p^</code> (so <code>p</code> is neither a merge nor a root commit), and <code>p:f</code> (file <code>f</code> in commit <code>p</code>) differs from <code>p^:f</code> (possibly to the point of not even existing in <code>p^</code>). This suggests the following obvious (and totally un-optimized) algorithm for finding all files <code>fi</code> in tree <code>T</code> that meet this constraint: <pre><code># set M = merge commit ID and P to its complete list of parents # (see previous scripts for how to achieve that) for f in $(git ls-tree -r $M); do found=false twice=false for p in $P; do $twice && continue # already announced if modified_in $p $f; then $found && twice=true || found=true fi $twice && echo $f # announce if found twice done done </code></pre> where <code>modified_in</code> is defined as: <pre><code>modified_in() { local p=$1 p_hat=$1^ path="$2" assert_single_parent $p # optional: verify neither root commit nor merge # (if you want to do this, it would be more efficient to do it once # outside the "for f in ..." loop) test ! -z "$(git diff-tree -r --diff-filter=AM $p_hat $p -- "$path")" } </code></pre> Here the <code>git diff-tree</code> command will output a line like: <pre><code>:100644 100644 <sha1_in_p^> <sha1_in_p> M c </code></pre> for a file modified between <code>$p_hat</code> and <code>$p</code> (the <code>sha1</code> values being the blob SHA-1s), and: <pre><code>:000000 100644 <null_sha1> <sha1_in_p> A fgh </code></pre> for a file added there. The <code>--diff-filter=AM</code> ensures no output for a removal (otherwise you would get an <code>R</code> here) and the <code>-- "$path"</code> limits the checking to just the given file-name-path. I am pretty sure (but have not tested) that you need not worry about <code>C</code> and <code>R</code> (copy-edit and rename) and since these are commit tree diffs, not index diffs, <code>U</code> (unmerged) cannot occur. So we just need to run <code>git diff-tree</code> with that filter, and test whether the command prints anything. (To make this [probably much] more efficient, run all possible <code>git diff-tree</code> commands once, without specifying paths, on all "interesting" parents, saving their outputs, then cross-correlate all the files listed. Those that occur twice or more are your candidates. But that's much harder in <code>sh</code> script: you'll need something like <code>awk</code> here.) [Edit: no, you don't need <code>awk</code> after all, <code>sort | uniq -d</code> will do the trick. See <a href="https://stackoverflow.com/a/19139966/1256452">jthill's new answer</a>, which implements the much-more-efficient version of a slightly different interpretation of the question, maybe closer to the real intent, which I admit I still find confusing.] <hr> 1That is, if the commit graph looks something like this, for instance: <pre><code>A -- B -- C -- D -- M -- .. \-- E -- F --/ </code></pre> you only care about changes made in <code>D</code> and <code>F</code> with respect to <code>M</code>, not changes made in <code>C</code> and <code>E</code> as well. If you do care, you may want to diff commit <code>M</code> against, e.g., temporary trees made by squashing together C-and-D, and E-and-F, respectively; or do pairwise comparisons all the way back, or some such. Basically, you will need to list revs between the merge-base (commit <code>B</code>, here) and the merge itself (<code>M</code>), and then figure out how you want to handle them.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POhow to get a list of merged files in git?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USCommunity
UserOwnerUserId
1. UStorek
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.