Please trim the replied mails a bit, snipping old and irrelevant parts.
This is insane. :-)
Dear diary, on Thu, Apr 14, 2005 at 10:38:25AM CEST, I got a letter
where Martin Schlemmer <[EMAIL PROTECTED]> told me that...
..snip..
> Normalize show-diff output, add --update-modes target to update-cache,
> and make sure we only show real changes after changing the tracked
> branch, as well as update the file modes according to the cache.
I'm lost. Why do you do --update-modes? That makes no sense to me.
You introduce them to the cache out-of-order w.r.t. commits, that means
in the normal git usage they are already unrevertable.
What are you trying to do? Mode changes _are_ real changes. You _don't_
want to silence them. What you want is to even show them more explicitly
in show-diff.
The --refreshes are fine.
> Signed-off-by: Martin Schlemmer <[EMAIL PROTECTED]>
>
> gitcancel.sh: ec58f7444a42cd3cbaae919fc68c70a3866420c0
> --- ec58f7444a42cd3cbaae919fc68c70a3866420c0/gitcancel.sh
> +++ uncommitted/gitcancel.sh
> @@ -12,7 +12,8 @@
>
> # FIXME: Does not revert mode changes!
>
> -show-diff | patch -p0 -R
> +show-diff | patch -p1 -R
> rm -f .git/add-queue .git/rm-queue .git/merged
>
> -update-cache --refresh
> +# --update-modes need to be before --refresh
> +update-cache --update-modes --refresh
Here, e.g., you should do the very opposite - change the modes back to
how are they in the cache.
> show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> --- a531ca4078525d1c8dcf84aae0bfa89fed6e5d96/show-diff.c
> +++ uncommitted/show-diff.c
> @@ -5,13 +5,18 @@
> */
> #include "cache.h"
>
> -static void show_differences(char *name,
> +static void show_differences(struct cache_entry *ce,
> void *old_contents, unsigned long long old_size)
> {
> static char cmd[1000];
> + static char sha1[41];
> + int n;
> FILE *f;
>
> - snprintf(cmd, sizeof(cmd), "diff -L %s -u -N - %s", name, name);
> + for (n = 0; n < 20; n++)
> + snprintf(&(sha1[n*2]), 3, "%02x", ce->sha1[n]);
> + snprintf(cmd, sizeof(cmd), "diff -L %s/%s -L uncommitted/%s -u -N -
> %s",
> + sha1, ce->name, ce->name, ce->name);
The "directory" sha1 is the sha1 of the tree, not of the particular
file - that one is in the "attributes" list (parentheses after the
filename), together with mode.
> f = popen(cmd, "w");
> if (old_size)
> fwrite(old_contents, old_size, 1, f);
> @@ -99,7 +104,7 @@
> continue;
>
> new = read_sha1_file(ce->sha1, type, &size);
> - show_differences(ce->name, new, size);
> + show_differences(ce, new, size);
> free(new);
> }
> return 0;
> update-cache.c: 62d0a6c41560d40863c44599355af10d9e089312
> --- 62d0a6c41560d40863c44599355af10d9e089312/update-cache.c
> +++ uncommitted/update-cache.c
> @@ -210,6 +210,39 @@
> }
> }
>
> +static struct cache_entry *update_file_mode(struct cache_entry *ce)
> +{
> + struct stat st;
> + int changed;
> +
> + if (stat(ce->name, &st) < 0)
> + return NULL;
> +
> + changed = cache_match_stat(ce, &st);
> + if (!changed)
> + return ce;
> +
> + if (changed & MODE_CHANGED)
> + if (chmod(ce->name, ce->st_mode))
> + return NULL;
> +
> + return ce;
> +}
> +
> +static void update_modes(void)
> +{
> + int i;
> +
> + for (i = 0; i < active_nr; i++) {
> + struct cache_entry *ce = active_cache[i];
> +
> + if (!update_file_mode(ce)) {
> + printf("%s: needs update\n", ce->name);
> + continue;
> + }
> + }
> +}
> +
> /*
> * We fundamentally don't like some paths: we don't want
> * dot or dot-dot anywhere, and in fact, we don't even want
Oh. So you are actually doing the _opposite_! But that's very wrong too.
update-cache is for the direction tree -> index. For the opposite
direction, you should use checkout-cache.
> @@ -282,6 +315,10 @@
> refresh_cache();
> continue;
> }
> + if (!strcmp(path, "--update-modes")) {
> + update_modes();
> + continue;
> + }
> die("unknown option %s", path);
> }
> if (!verify_path(path)) {
>
>
> --
> Martin Schlemmer
>
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
