Re: [PATCH 15/16] checkout: add new options to support narrow checkout
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Sep 15, 2008, 10:40 UTC
- Message-ID
- <200809151240.54495.jnareb@gmail.com>
- In-Reply-To
- <48cdde2837b2d_12d73fc6eb2c355c27876@app02.zenbe.com.tmail>
[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:
Show 19 quoted lines
> > > +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").
Show 15 quoted lines
> > 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?
Show 6 quoted lines
> > > + > > > +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.
Show 9 quoted lines
> > 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.
Show 15 quoted lines
> > > +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 '\'?
Show 7 quoted lines
> > 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