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

Re: [RFC] Possible strategy cleanup for git add/remove/diff etc.

From
Junio C Hamano <junkio@cox.net>
Date
Apr 20, 2005, 06:07 UTC
Message-ID
<7voecakmlq.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<Pine.LNX.4.58.0504192102140.6467@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>> I'll immediately write a tool to diff the current working directory 
>> against a tree object, and hopefully that will just make pasky happy with 
>> this model too. 

The model you have always had is that there are three things the user needs to be aware of:

 * files in working tree -- this is what you touch with your
   editor and feed compilers with.
 * files in dircache -- update-cache copies from working
   tree to here, checkout-cache copies from here to working
   tree.
 * committed tree state -- write-tree + commit-tree copies from
   dircache to this state, read-tree copies from here to
   dircache.

The original message I started this thread with suggested that I wish if Cogito sugarcoating layer treated the dircache invisible to the user by keeping it virtually and lazily in sync with the working tree, as opposed to the way the current git-pasky does, which is to keep it in sync with the committed state.

But after thinking about it more, I changed my mind. With something like diff-cache available to the user, making aware of the three hierarchy to the user might be cleaner.

The workflow becomes:
 
 * Initial read-tree + checkout-cache -f -a; makes the three in
   sync.
 * Hack away.  Makes the working tree drift from dircache.
 * show-diff to see what's changed since your last "checkpoint".
   update-cache when happy.  Working tree is in sync with
   dircache which is the "staging area" for my half-baked but
   still good stuff.  Makes the dircache different from the
   committed.
 * Hack away more.  show-diff does not show your earlier changes
   anymore.  This is sometimes inconvenient when you want to see
   what you earlier changed but not committed.  Here comes the
   new shiny diff-cache to rescue.
 * When satisfied with all the changes diff-cache --cached
   shows, finally, say write-tree + commit-tree.  This makes all
   three in sync again.

I vaguely recall having heard about some SCM that distinguishes check-in and commit. Maybe this two-staged update-cache and write-tree + commit-tree workflow is similar to it?

Previous: Linus TorvaldsNext: Junio C Hamano
Message 9 of 10 in “"True" git merge in git-pasky”
  1. Petr BaudisApr 19, 2005
  2. bert hubertApr 19, 2005
  3. Petr BaudisApr 19, 2005
  4. Francois RomieuApr 19, 2005
  5. [RFC] Possible strategy cleanup for git add/remove/diff etc.Junio C Hamano, Apr 20, 2005
  6. Linus TorvaldsApr 20, 2005
  7. Junio C HamanoApr 20, 2005
  8. Linus TorvaldsApr 20, 2005
  9. Junio C HamanoApr 20, 2005
  10. Junio C HamanoApr 21, 2005

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.