Re: [PATCH 15/16] checkout: add new options to support narrow checkout

[Jakub Narebski <jnareb@gmail.com>]

[I don't see mails I am replying to on GMane interface to git mailing
 list, so threads might be broken. Strange... Perhaps too long lines
 were cause of rejection by anti-SPAM vger filter?]

On Mon, 15 Sep 2008, Duy Nguyen wrote:
> On 09/15/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:

> > > +Narrow works by applying your rules to the index, marking which
> > > +file you need and which file you need not. Modified/Unmerged
> > > +files cannot be marked unneeded. Unnecessary files will be
> > > +removed from working directory.  Note that after this step,
> > > +removed files can still be added to working directory when they
> > > +are needed by any git command. For example, when you have a merge
> > > +conflict, conflicted files will be checked out on working
> > > +directory and will no longer be marked "unneeded".
> > 
> > This paragraph I think need some more love...
> > 
> > So the "checkout rules" are meant to mark which paths are "wanted"
> > or "needed", and we would like to have in the checkout, and which
> > files are "unwanted" or "not needed" ("unneeded"?) and we want to
> > not have them present in working directory; something akin to accept
> > and deny rules, isn't it?
> 
> Yes. But rules will be gone, only the results remain. I don't
> save/reuse rules. 

Ah. I understand. The options are only to select which files to check-out
(which are "wanted"), and which we do not want and mark with "no-checkout"
bit ("unwanted").
 
> > What are the rules, does all files except those marked explicitely
> > as needed are unneeded, or do you have to first mark all files as
> > unneeded?
> > 
> > How would the following table look like:
> > 
> >   working directory  || needed       | not needed    |
> >   ----------------------------------------------------
> >   file is absent     || checkout     | no change     |
> >   file is present    || no change    | removed       |
> >   file is modified   || conflict     | conflict?     |
> 
> Looks better than my description. Though it would be "no change" for
> "file is modified/needed" case. There should be another line for
> unmerged entries.  

Now I am not sure about the line with 'file is modified', because even
in simple full checkout case there are different situations dealing with
checking out of index (and '-f' option), and switching to other branch
(and '-m' option).
 
Doesn't unmerged simply mean ignore "no-checkout" bit?

> > > +
> > > +New files after merges will always be "needed". You can also
> > > +apply rules when switching branches to avoid unwanted new files.
> > 
> > Does it mean that if merge brings some new files, then those
> > files would be "needed" (without "no checkout" bit)?

And as far as I understand the same for simple checkout, and for "2-way
merge" checkout.

> Yes.

Perhaps: new entries appearing in index have "no-checkout" bit unset
(cleared).  Or perhaps in addition, as clarification.

> > What does it mean this sentence about switching branches:
> > how does partial/sparse/narrow checkout rules change when
> > switching to other branch (which, like 'html' and 'todo'
> > branches in git repository, can be completely unrelated)?
> 
> Recall above I say rules are not saved. When you switch branches,
> files that are needed will still be and stay in workdir. New files
> will always appear in workdir ("needed"). If two branches are
> completely unrelated, all files will be new so you get full workdir.   

Thanks. Now I understand: new entries in index are always with
"no-checkout" bit unset, regardless how they got there.
  
> > > +Narrow spec will be used to specify how you want to narrow your
> > > +checkout. It is a list of pathspecs separated by colons. Each
> > > +patchspec specifies what files should be checked out on working
> > > +directory. Pathspec can contain wildcards and is relative to
> > > +current working directory. Usually asterisk (*) does not match
> > > +slashes. If a pathspec is prefixed by a plus sign (+), then
> > > +any asterisk will match anything, even slashes.
> > 
> > First, does this mean that you can specify paths containing colons
> > (':') only using --add-path and --remove-path, or does it mean that
> > you cannot specify paths containg colon ':' (which should be rare)
> > at all as checkout limiter / checkout narrowing rule?
> 
> You cannot do othat explicitly unfortunately. You can work-around using
> wildcard though. 

Couldn't you simply escape ':', i.e. write for example Git\:\:Tag.3pm,
or Eichten_PRD21\:313,1980_erratum.tex, or \:0.log, or perhaps
kmail/jnareb@gmail.com\:@pop.gmail.com\:995, or even something like
Mail/inbox/cur/1194202360.32296.mprnq\:2,S, in the same way like you
can escape other special characters, for example wildcard characters
like '\*' for '*' and '\?' for '?', and of course '\\' for '\'?
 
> > Second, wouldn't it be better to use '**' to match also '/'?
> > Changing meaning of '*' using per-path flag seems a bit bad.
> 
> It would be better. But I don't see any way but duplicating fnmatch()
> implementation and modify it to support '**' so I made a compromise.
> Will make another patch for '**' support and see how bloat the code
> will be.   

Well, the alternative would be to tell in commit message _why_ you
choose that (for implementation reasons), and perhaps give an example.

BTW. does '+' prefixed pathspec means that '?' can match '/', directory
separator?
 
-- 
Jakub Narebski
Poland