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

Re: [RFC] Zit (v2): the git-based single file content tracker

From
Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date
Oct 24, 2008, 07:14 UTC
Message-ID
<cb7bb73a0810240014o2209194dodc4a6fe3b754b04f@mail.gmail.com>
In-Reply-To
<alpine.DEB.1.10.0810232314490.20238@asgard.lang.hm>
On Fri, Oct 24, 2008 at 8:21 AM,  <david@lang.hm> wrote:
Show 31 quoted lines
> On Thu, 23 Oct 2008, Giuseppe Bilotta wrote:
>
>> I decided to give the simpler GIT_DIR approach another go.
>>
>> The reworked Zit ( git://git.oblomov.eu/zit ) works by creating
>> .file.git/ to track file's history. .file.git/info/excludes is
>> initialized to the very strong '*' pattern to ensure that things such
>> as git status etc only consider the actually tracked file.
>>
>> The obvious advantage over the previous implementation is that we
>> don't rely on fragile and non-portable hardlinks. The disadvantage
>> is that something really bad can happen if a command fails to obey
>> GIT_DIR or GIT_WORK_TREE correctly.
>
> this is a very interesting approach.
>
> the thought that hit me as I finidhed reading this thread is that we are
> very close to having the full continum of file/repository combinations
>
> 1. everything in the dir is part of one repository (the normal git case)
>
> 2. some of all of the individual files in a dir is it's own repository (the
> zit case)
>
> 3. the in-between case where you can have multiple repositories that can
> have multiple files in them.
>
> how hard would it be to extend zit to support case #3?
>
> offhand I can see it complicating the task of figuring out which repository
> to use for a file, but what else?

I haven't tried this yet, but I think it should be possible without much problems. The important thing to keep in mind is that the second parameter to zit (for all commands but zit init) 'only' identifies the repository, and the filename parameter is NOT passed to git. The only exceptions are zit add and git commit, and I'm having second thoughts on add. Anyway, you can always use the 'raw' version of a command to guarantee that only GIT_DIR and GIT_WORK_TREE are set, thus:

$ zit rawadd somefile -f someotherfile

will force-add someotherfile to somefile's repo. (Force adding is required because of the blanket exclude.) Of course, it would be interesting adding to zit the capability to do

$ zit diff someotherfile

to make it guess that it should use somefile's repo. This is possible with some symlinks for the git repos, probably.

I'll have a look into it.
-- 
Giuseppe "Oblomov" Bilotta
Previous: david@lang.hmNext: Jakub Narebski
Message 13 of 38 in “[RFC] Zit: the git-based single file content tracker”
  1. Giuseppe BilottaOct 23, 2008
  2. Felipe Oliveira CarvalhoOct 23, 2008
  3. Nguyen Thai Ngoc DuyOct 23, 2008
  4. Giuseppe BilottaOct 23, 2008
  5. Nguyen Thai Ngoc DuyOct 23, 2008
  6. Giuseppe BilottaOct 23, 2008
  7. Johannes SixtOct 23, 2008
  8. Giuseppe BilottaOct 23, 2008
  9. Johannes SchindelinOct 24, 2008
  10. Giuseppe BilottaOct 24, 2008
  11. [RFC] Zit (v2): the git-based single file content trackerGiuseppe Bilotta, Oct 23, 2008
  12. david@lang.hmOct 24, 2008
  13. Giuseppe BilottaOct 24, 2008
  14. Jakub NarebskiOct 24, 2008
  15. Giuseppe BilottaOct 24, 2008
  16. Jakub NarebskiOct 26, 2008
  17. Giuseppe BilottaOct 26, 2008
  18. Jakub NarebskiOct 26, 2008
  19. Giuseppe BilottaOct 26, 2008
  20. Jean-Luc HerrenOct 23, 2008
  21. Giuseppe BilottaOct 24, 2008
  22. Jakub NarebskiOct 24, 2008
  23. Giuseppe BilottaOct 24, 2008
  24. Jakub NarebskiOct 24, 2008
  25. Giuseppe BilottaOct 24, 2008
  26. Junio C HamanoOct 24, 2008
  27. david@lang.hmOct 24, 2008
  28. Giuseppe BilottaOct 24, 2008
  29. david@lang.hmOct 24, 2008
  30. Giuseppe BilottaOct 24, 2008
  31. david@lang.hmOct 24, 2008
  32. Giuseppe BilottaOct 24, 2008
  33. Jakub NarebskiOct 24, 2008
  34. Giuseppe BilottaOct 25, 2008
  35. Jakub NarebskiOct 25, 2008
  36. Giuseppe BilottaOct 25, 2008
  37. david@lang.hmOct 24, 2008
  38. Giuseppe BilottaOct 24, 2008

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.