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

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

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Aug 17, 2009, 13:35 UTC
Message-ID
<alpine.DEB.1.00.0908171524150.4991@intel-tinevez-2-302>
In-Reply-To
<fcaeb9bf0908170549w26b008bdhe67f113a58ecb4eb@mail.gmail.com>
Hi,
On Mon, 17 Aug 2009, Nguyen Thai Ngoc Duy wrote:
Show 19 quoted lines
> On Mon, Aug 17, 2009 at 4:08 PM, Johannes
> Schindelin<Johannes.Schindelin@gmx.de> wrote:
> > Turns out that somebody on IRC had a problem that requires to have 
> > sparse'd out files which _do_ have working directory copies.
> >
> > So just having the assume-changed bit may not be enough.
> >
> > The scenario is this: the repository contains a file that users are 
> > supposed to change, but not commit to (only the super-intelligent 
> > inventor of this scenario is allowed to).  As this repository is 
> > originally a subversion one, there is no problem: people just do not 
> > switch branches.
> >
> > But this guy uses git-svn, so he does switch branches, and to avoid 
> > committing the file by mistake, he marked it assume-unchanged.
> 
> Hmm.. never thought of this use before. If he does not want to commit by 
> mistake, should he add to-be-committed changes to index and do "git 
> commit" without "-a" (even better, do "git diff --cached" first)?

You probably agree that this would be a _very_ fragile setup. Very easy to make mistakes.

But we try to get away from that, don't we? Git had a reputation to be easy fsck up for long enough.

Show 5 quoted lines
> > Only that a branch switch overwrites the local changes.
> 
> I don't think branch switch overwrites changes in this case. Whenever
> Git is to touch worktree files, it ignores assumed-unchanged bit and
> does lstat() to make sure worktree files are up to date.
Well, it does there, thankyouverymuch.

The problem of course is that the other branch has an ancient version of that file (which should _not_ overwrite the current, modified version!), i.e. "git diff HEAD..other -- file" does not come empty.

As 'file' is assume-unchanged, zinnnng, the file gets "updated".
Show 5 quoted lines
> > I suggested the use of the sparse feature, and mark this file (and 
> > this file alone) as sparse'd-out.
> 
> Sparse checkout only removes a file if its assume-unchanged bit
> changes from 0 to 1.
The problem is not removing, but overwriting.

And in this respect, 'assume-unchanged' is a very different beast from 'sparse'. I am growing more and more convinced that you cannot just reuse the assume-unchanged bit.

Show 10 quoted lines
> If it's already 1, it does not care whether there is a corresponding 
> file in worktree. So something like this should work:
> 
> git checkout my-branch
> git update-index --assume-unchanged that-special-file
> echo that-special-file > .git/info/sparse
> # edit that-special-file
> git commit -a
> # do whatever you want, git pull/checkout/read-tree... won't touch
> that-special-file because it's assume-unchanged already

... except if you changed .git/info/sparse and a formerly sparse'd-out file is overwritten by "pull". Not good.

> Anyway I would not recommend this. the versions of that-special-file in 
> worktree and and in index will diverse. When you unmark assume-unchanged 
> (be it sparse checkout or plain assume-unchanged), you may have already 
> forgot what changes you made to this file and "git diff" would not help.

My point is that we should take the current implementation as Dictated By The Dear Lord, but change it if the limitation is too severe.

And I do contend that 'assume-unchanged' is dissimilar enough from 'sparse' to merit a change.

Show 5 quoted lines
> > Is this an intended usage scenario?  Then we cannot reuse the 
> > assume-changed bit [*1*].
> 
> It'd be great if people tell us all the scenarios they have. My use 
> could be too limited.

The use case I would have is where a collaborator wants to work only on one subdirectory and the top-level directory. All other subdirectories are of no interest to him.

Another use case: documentation. I do not have that use case yet, but I know about people who do. Specifying what you _want_ to have checked out is much more straight-forward here than the opposite.

Ciao, Dscho

Previous: Nguyen Thai Ngoc DuyNext: Nguyen Thai Ngoc Duy
Message 21 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.