git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH v3 8/8] --sparse for porcelains

From
Sskillzero@gmail.com <skillzero@gmail.com>
Date
Aug 18, 2009, 00:23 UTC
Message-ID
<2729632a0908171723n1c70798bp3169c813d5734c70@mail.gmail.com>
In-Reply-To
<alpine.DEB.1.00.0908180111340.8306@pacific.mpi-cbg.de>

On Mon, Aug 17, 2009 at 4:16 PM, Johannes Schindelin<Johannes.Schindelin@gmx.de> wrote:

Show 31 quoted lines
> Hi,
>
> On Mon, 17 Aug 2009, skillzero@gmail.com wrote:
>
>> On Mon, Aug 17, 2009 at 3:02 PM, Johannes
>> Schindelin<Johannes.Schindelin@gmx.de> wrote:
>>
>> > And here comes the problem: if something is treated untracked because
>> > it was outside of the sparse checkout, then I want it to be treated as
>> > untracked _even if_ I happened to broaden the checkout by editing
>> > .git/info/sparse.  The file did not just magically become subject to
>> > overwriting just because I edited .git/info/sparse (which could be a
>> > simple mistake).
>>
>> Maybe I'm misunderstanding what you're saying, but why would you want a
>> file that's become part of the checkout by editing .git/info/sparse to
>> still be treated as untracked?
>>
>> If I have a file on that's excluded via .git/info/sparse then I edit
>> .git/info/sparse to include it and switch to a branch that doesn't have
>> that file, I'd expect that file to be deleted from the working copy if
>> the content matches what's in the repository. If it's modified then I'd
>> expect the branch switch to fail (like it would without a sparse
>> checkout).
>
> First things first: with sparse checkout, you should not check out
> _anything_ outside of the focus of the sparse checkout.
>
> So I contend that you would only end up with a sparse'd-out file
> that was formerly tracked if you did something wrong.  That should not
> happen.

I was thinking if you copied the file there manually and changed .git/info/sparse to include it. I would expect git checkout, git status, etc. to act as just as if I had never excluded it via .git/info/sparse, similar to .gitignore and .git/info/exclude.

Show 7 quoted lines
> The thing is: we need a way to determine quickly and without any
> ambiguity whether a file is tracked, assumed unchanged, or sparse'd-out
> (which Nguyễn calls no-checkout).
>
> And if we change .git/info/sparse, that state _must not_ change.  We did
> not touch the file by editing .git/info/sparse, so the state must be
> unchanged.

I don't know enough to have an opinion on assume-unchanged vs no-checkout, but if you edit .git/info/sparse it seems like it should affect whether git cares about a file or not. If a file previously had the no-checkout bit and you change .git/info/sparse to include the file, the next time you do something with git, I would expect it to start caring about that path. For example, I can edit .gitignore and .git/info/exclude and it notices the next time I use git without having to do anything special.

Previous: Jakub NarebskiNext: Junio C Hamano
Message 39 of 53 in “Sparse checkout”
  1. 0/8 Sparse checkoutNguyễn Thái Ngọc Duy, Aug 11, 2009
  2. 1/8 Prevent diff machinery from examining assume-unchanged entries on worktreeNguyễn Thái Ngọc Duy, Aug 11, 2009
  3. 2/8 Avoid writing to buffer in add_excludes_from_file_1()Nguyễn Thái Ngọc Duy, Aug 11, 2009
  4. 3/8 Read .gitignore from index if it is assume-unchangedNguyễn Thái Ngọc Duy, Aug 11, 2009
  5. 4/8 excluded_1(): support exclude "directories" in indexNguyễn Thái Ngọc Duy, Aug 11, 2009
  6. 5/8 dir.c: export excluded_1() and add_excludes_from_file_1()Nguyễn Thái Ngọc Duy, Aug 11, 2009
  7. 6/8 unpack-trees.c: generalize verify_* functionsNguyễn Thái Ngọc Duy, Aug 11, 2009
  8. 7/8 Support sparse checkout in unpack_trees() and read-treeNguyễn Thái Ngọc Duy, Aug 11, 2009
  9. 8/8 --sparse for porcelainsNguyễn Thái Ngọc Duy, Aug 11, 2009
  10. Junio C HamanoAug 12, 2009
  11. Nguyen Thai Ngoc DuyAug 12, 2009
  12. Nguyen Thai Ngoc DuyAug 13, 2009
  13. Jakub NarebskiAug 13, 2009
  14. Nguyen Thai Ngoc DuyAug 13, 2009
  15. Jakub NarebskiAug 14, 2009
  16. Junio C HamanoAug 15, 2009
  17. Jakub NarebskiAug 15, 2009
  18. Johannes SchindelinAug 16, 2009
  19. Johannes SchindelinAug 17, 2009
  20. Nguyen Thai Ngoc DuyAug 17, 2009
  21. Johannes SchindelinAug 17, 2009
  22. Nguyen Thai Ngoc DuyAug 17, 2009
  23. Johannes SchindelinAug 17, 2009
  24. Nguyen Thai Ngoc DuyAug 17, 2009
  25. Junio C HamanoAug 17, 2009
  26. Nguyen Thai Ngoc DuyAug 17, 2009
  27. Johannes SchindelinAug 17, 2009
  28. Junio C HamanoAug 17, 2009
  29. Johannes SchindelinAug 17, 2009
  30. skillzero@gmail.comAug 17, 2009
  31. Johannes SchindelinAug 17, 2009
  32. Jakub NarebskiAug 18, 2009
  33. skillzero@gmail.comAug 18, 2009
  34. Nguyen Thai Ngoc DuyAug 18, 2009
  35. git find (was: [RFC PATCH v3 8/8] --sparse for porcelains)Jakub Narebski, Aug 18, 2009
  36. Nguyen Thai Ngoc DuyAug 18, 2009
  37. Jakub NarebskiAug 18, 2009
  38. Jakub NarebskiAug 18, 2009
  39. skillzero@gmail.comAug 18, 2009
  40. Junio C HamanoAug 17, 2009
  41. Johannes SchindelinAug 17, 2009
  42. Jakub NarebskiAug 17, 2009
  43. Johannes SixtAug 12, 2009
  44. Nguyen Thai Ngoc DuyAug 12, 2009
  45. Raja R HarinathAug 12, 2009
  46. Johannes SixtAug 13, 2009
  47. skillzero@gmail.comAug 11, 2009
  48. Jakub NarebskiAug 11, 2009
  49. skillzero@gmail.comAug 11, 2009
  50. Nguyen Thai Ngoc DuyAug 12, 2009
  51. skillzero@gmail.comAug 12, 2009
  52. Junio C HamanoAug 12, 2009
  53. Nguyen Thai Ngoc DuyAug 13, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.