Alex Riesen <raa.lkml@xxxxxxxxx> writes:
> Also, make "git commit -a" work with modifications of subproject HEADs.
>
> ---
>
> This one works with update-index --remove (which is what git-commit -a
> uses). It is ugly. I tried to keep the "F -> D/F" behaviour of
> update-index. Still have to check if "F -> Subproject" works.
>
> builtin-update-index.c | 45 +++++++++++++++++++++++++--------------------
> 1 files changed, 25 insertions(+), 20 deletions(-)
>
> diff --git a/builtin-update-index.c b/builtin-update-index.c
> index eba756d..d075d50 100644
> --- a/builtin-update-index.c
> +++ b/builtin-update-index.c
> @@ -62,7 +62,7 @@ static int mark_valid(const char *path)
>
> static int process_file(const char *path)
> {
> - int size, namelen, option, status;
> + int size, namelen = -1, option, status;
> struct cache_entry *ce;
> struct stat st;
>
> @@ -73,7 +73,7 @@ static int process_file(const char *path)
> */
> cache_tree_invalidate_path(active_cache_tree, path);
>
> + if (!status && S_ISDIR(st.st_mode)) {
> /* When we used to have "path" and now we want to add
> * "path/file", we need a way to remove "path" before
> * being able to add "path/file". However,
> @@ -82,27 +82,32 @@ static int process_file(const char *path)
> * friendly, especially since we can do the opposite
> * case just fine without --force-remove.
> */
> + namelen = strlen(path);
> + int pos = cache_name_pos(path, namelen);
> + if (0 <= pos && S_ISREG(ntohl(active_cache[pos]->ce_mode)) &&
> + allow_remove) {
> + if (remove_file_from_cache(path))
> + return error("%s: cannot remove from the index", path);
> + else
> + return 0;
> + }
> + }
If I used to have a symlink S and now the filesystem has a file
S/F which I am running "update-index --add --remove" on, what
happens?
If I have a subproject at path P, and mistakenly try to add path
P/F with "update-index --add --remove P/F", it should be
refused, shouldn't it?
-
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