I have an unattended script which performs automated merges into
several destination branches.
As the repo is fairly large, I'd like not to have to checkout each
destination branch, nor have multiple workdirs.
So my approach is to create a temporary, empty, workdir, using
symlinks to point to the parent repo per git new-workdir.
I then invoke merge-recursive directly inside the temporary workdir.
The question is whether this is safe to do, or whether merge-recursive
expects a fully populated working tree that matches the index. My easy
test cases seem to work correctly, but I'm concerned that I sometimes
get:
Skipped /some/file (merged same as existing)
error: addinfo_cache failed for path '/some/file'
Skipped some/other_file (merged same as existing)
error: addinfo_cache failed for path 'some/other_file'
Which seems to be from this code in merge-recursive.cc:
if (mfi.clean && !df_conflict_remains &&
sha_eq(mfi.sha, a_sha) && mfi.mode == a_mode) {
int path_renamed_outside_HEAD;
output(o, 3, "Skipped %s (merged same as existing)", path);
/*
* The content merge resulted in the same file contents we
* already had. We can return early if those file contents
* are recorded at the correct path (which may not be true
* if the merge involves a rename).
*/
path_renamed_outside_HEAD = !path2 || !strcmp(path, path2);
if (!path_renamed_outside_HEAD) {
add_cacheinfo(mfi.mode, mfi.sha, path,
0 /*stage*/, 1 /*refresh*/, 0 /*options*/);
return mfi.clean;
}
(Peff, hope you don't mind me cc'ing you directly. I seem to recall
you're saying github is doing something like this but I couldn't find
that email.)
j.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html