Re: Remove need to untrack before tracking new branch

> Dear diary, on Thu, Apr 14, 2005 at 11:40:09AM CEST, I got a letter
> where Martin Schlemmer <azarah@nosferatu.za.org> 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.
> ;-)
> 

> > > > 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.
> 

> 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.
>