{"thread":{"id":"3339","subject":"StGIT refreshes all added files - limitation of git-write-tree?","startedAt":"2006-02-15T04:42:08Z","lastAt":"2006-02-15T09:06:17Z","messageCount":4,"participants":["Pavel Roskin","Junio C Hamano","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"16186","messageId":"1139978528.28292.41.camel@dv","threadId":"3339","inReplyTo":null,"subject":"StGIT refreshes all added files - limitation of git-write-tree?","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-02-15T04:42:08Z","receivedAt":"2006-02-15T04:42:08Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"Hello!\n\nCurrent StGIT would refresh all added files on \"stg refresh\", even if\nthey are not specified on the command line. I believe the same is true\nfor removed files.\n\nThat's when it can hurt. I apply a large patch that modifies and adds\nseveral files. I want to split the patch into several StGIT patches by\nselecting which files belong to which patch. All files that need to be\nmodified are already modifies. It's natural that I add new files using\n\"stg add\" at this stage. To me, adding files looks very similar to\nmodifying them. However, then I create a patch by \"stg new\" and commit\n_some_ files to it using \"stg refresh\" with those files on the command\nline, I discover that _all_ added files have been refreshed.\n\nThe only workaround seems to be to add only those files that will be\nincluded in the current patch. The same should be true for renamed\nfiles.\n\nDebugging StGIT shows that it builds correct lists of the files to be\nincluded in the current patch (update_cache in git.py), but they are\nnever used. Instead, StGIT runs \"git-write-tree\" without arguments\n(commit in git.py). While StGIT is careful to only add user-specified\nmodified files to the directory cache, it does nothing to the added\nfiles, which are in the cache already.\n\nPurely StGIT way of handling this problem would be to remove added files\nfrom the directory cache if they are not being committed. The problem\nis, \"stg add\" uses the cache, so this would undo \"stg add\" on files\nunused in the current operation. Either StGIT should restore files in\nthe cache after the refresh, or there should be a separate StGIT cache\nthat \"stg add\" would work on. The former is potentially unreliable\n(what if refresh is interrupted), the later creates an extra layer,\nanother directory cache no less, this reducing usability of the pure git\ncommands.\n\nAnother approach would be to get rid of \"stg add\" and \"stg rm\" and use\n\"stg refresh --add\" and \"stg refresh --rm\" to add files to the current\npatch or to remove them. It does feel like removal of a useful feature,\nsince \"stg diff\" without arguments will no longer show added or removed\nfiles. Adding and removing files would be too immediate compared to\nmodifying them.\n\nWhat I really hope to hear is that there is or there will be a git based\nsolution. Either git-write-tree could be changed to only process files\nspecified on the command line, or there should be some other command\ndoing that.\n\nOr maybe git-write-tree and other utilities could be changed to work on\na copy of the index file? I would prefer not to move the\nactual .git/index away, but to make a copy for the current \"stg refresh\"\noperation.\n\n-- \nRegards,\nPavel Roskin\n"},{"id":"16188","messageId":"7vacctnnx4.fsf@assigned-by-dhcp.cox.net","threadId":"3339","inReplyTo":"1139978528.28292.41.camel@dv","subject":"Re: StGIT refreshes all added files - limitation of git-write-tree?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-15T06:20:23Z","receivedAt":"2006-02-15T06:20:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pavel Roskin writes:\n\n> Or maybe git-write-tree and other utilities could be changed to work on\n> a copy of the index file? I would prefer not to move the\n> actual .git/index away, but to make a copy for the current \"stg refresh\"\n> operation.\n\nThere is no need to change the core side. \n\n\tGIT_INDEX_FILE=temporary-index git-write-tree\n\nwould do the job. See the current round of git-commit and how\nit handles \"git commit --only these files\" case.\n"},{"id":"16190","messageId":"20060215062814.GA26632@spearce.org","threadId":"3339","inReplyTo":"1139978528.28292.41.camel@dv","subject":"Re: StGIT refreshes all added files - limitation of git-write-tree?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-02-15T06:28:14Z","receivedAt":"2006-02-15T06:28:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Pavel Roskin wrote:\n> Or maybe git-write-tree and other utilities could be changed to work on\n> a copy of the index file? I would prefer not to move the\n> actual .git/index away, but to make a copy for the current \"stg refresh\"\n> operation.\n\ngit-write-tree pays attention to the GIT_INDEX_FILE environment\nvariable; if this, GIT_DIR and GIT_OBJECT_DIRECTORY are set you can\nredirect git-write-tree to look at a different index. One way to\ncreate a tree from a mixture of your current index and the current\nHEAD's tree is to set GIT_INDEX_FILE to a temporary file name\n(which doesn't exist), use git-read-tree to load the current tree\nunmodified into that index, copy the modified records of interest\nfrom the current index to the temporary index, then git-write-tree\nfrom the temporary index. But now you need to update your current\nindex with the real SHA1s of the written files.\n\nSomewhat convoluted. I think that git-commit.sh and cg-commit.sh\nplay such games to do partial commits based on what the user has\npassed on the command line or modified in their editor (which is\nactually a rather cool feature of Cogito). I'm using a similar\ntrick in pg to load binary objects from a patch directory (for a\nspecific use case that I have). git-am.sh uses a similar trick\nto perform a 3 way merge if git-apply fails.\n\n-- \nShawn.\n"},{"id":"16199","messageId":"1139994377.5796.30.camel@dv","threadId":"3339","inReplyTo":"7vacctnnx4.fsf@assigned-by-dhcp.cox.net","subject":"Re: StGIT refreshes all added files - limitation of git-write-tree?","fromName":"Pavel Roskin","fromEmail":"proski@gnu.org","sentAt":"2006-02-15T09:06:17Z","receivedAt":"2006-02-15T09:06:17Z","isPatch":false,"sender":{"key":"proski@gnu.org","avatar":null},"body":"On Tue, 2006-02-14 at 22:20 -0800, Junio C Hamano wrote:\n> Pavel Roskin writes:\n> \n> > Or maybe git-write-tree and other utilities could be changed to work on\n> > a copy of the index file? I would prefer not to move the\n> > actual .git/index away, but to make a copy for the current \"stg refresh\"\n> > operation.\n> \n> There is no need to change the core side. \n> \n> \tGIT_INDEX_FILE=temporary-index git-write-tree\n> \n> would do the job. See the current round of git-commit and how\n> it handles \"git commit --only these files\" case.\n\nThank you! It's comforting to know that the issue is not unique to\nStGIT.\n\n-- \nRegards,\nPavel Roskin\n"}]}