On Fri, 2005-04-15 at 00:42 +0200, Petr Baudis wrote: > Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter > where Martin Schlemmer <[EMAIL PROTECTED]> told me that... > > (PS, can you check the fact that your mail client keeps on adding a 'Re: > > ' ...) > > Hmm. I guess my ancient reply_regexp > "^((\\[|\\()([^B]|B([^u]|u([^g]|g([^ ]|AnTiMaTcH))))[^]]+(\\]|\\)))?[ > \t]*((re([\\[0-9\\]+])*|aw):[ \t]*)?" is broken... ;-) > > > On Thu, 2005-04-14 at 11:11 +0200, Petr Baudis wrote: > > > 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. > > > > > > > Right, afterwards I thought I did add it to the wrong place. > > So, could you please do something with it? :-) > > > > 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. > > > > > > > No, you do not understand. If you actually change the mode, it will > > show. What now happens, is that say I track the 'linus' branch, then > > untrack, and then track 'pasky' again, the Patches will be applied, but > > not the mode changes which are stored in the cache ... Let me show you: > > > > ----- > > $ ls -l $(./show-diff -s | cut -d: -f1) > ..directroy listing with no 'x' bit.. > > ----- > > > > (Note no 'x' bit ...) > > > > And that is _after_ doing: > > > > $ git track linus; git track > > > > So basically the modes that are stored in the cache are not applied ... > > Although, yes, I prob should add the relevant code to checkout-cache. > > This should be fixed now, BTW. git apply didn't correctly apply the > mode changes, but now it should. Several bugs prevented it to, in fact. > ;-) >
Yep, I saw - thought you scrapped this, so mailed a new patch (or was
busy doing the touch ups to the email when this came in.
> > > > 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.
> > >
> >
> > Does it really matter? It is more just to get the patch prefix right,
> > and I did it as it went nicely with the printed:
> >
> > ----
> > show-diff.c: a531ca4078525d1c8dcf84aae0bfa89fed6e5d96
> > ----
> >
> > for example ...
>
> Yes, it matters, and I don't care how nicely it wents with what you
> print before.
>
hah ;p
> Either print there some nonsense which is clear not to be a tree ID, or
> (much more preferably) print the real tree ID there. If some tool ever
> uses it (e.g. to help resolve conflicts, perhaps even actually doing a
> real merge based on the patch), you just confused it.
>
Ok, understood. Do you think it will be scripted? If not I guess we
can just do labels like:
--- committed/
+++ uncommitted/
?
> Also, do you think you could separate this patch from the other
> (--update-modes) patch? (If we actually still need the --update-modes
> patch after git apply was fixed.)
>
Yeah, already split it out locally, just waiting on above response ...
Thanks,
--
Martin Schlemmer
signature.asc
Description: This is a digitally signed message part
