| 207 | } |
| 208 | |
| 209 | static void last_modified_diff(struct diff_queue_struct *q, |
| 210 | struct diff_options *opt UNUSED, void *cbdata) |
| 211 | { |
| 212 | struct last_modified_callback_data *data = cbdata; |
| 213 | |
| 214 | for (int i = 0; i < q->nr; i++) { |
| 215 | struct diff_filepair *p = q->queue[i]; |
| 216 | switch (p->status) { |
| 217 | case DIFF_STATUS_DELETED: |
| 218 | /* |
| 219 | * There's no point in feeding a deletion, as it could |
| 220 | * not have resulted in our current state, which |
| 221 | * actually has the file. |
| 222 | */ |
| 223 | break; |
| 224 | |
| 225 | default: |
| 226 | /* |
| 227 | * Otherwise, we care only that we somehow arrived at |
| 228 | * a final oid state. Note that this covers some |
| 229 | * potentially controversial areas, including: |
| 230 | * |
| 231 | * 1. A rename or copy will be found, as it is the |
| 232 | * first time the content has arrived at the given |
| 233 | * path. |
| 234 | * |
| 235 | * 2. Even a non-content modification like a mode or |
| 236 | * type change will trigger it. |
| 237 | * |
| 238 | * We take the inclusive approach for now, and find |
| 239 | * anything which impacts the path. Options to tweak |
| 240 | * the behavior (e.g., to "--follow" the content across |
| 241 | * renames) can come later. |
| 242 | */ |
| 243 | mark_path(p->two->path, &p->two->oid, data); |
| 244 | break; |
| 245 | } |
| 246 | } |
| 247 | } |
| 248 | |
| 249 | static void pass_to_parent(struct bitmap *c, |
| 250 | struct bitmap *p, |
nothing calls this directly
no test coverage detected