{"thread":{"id":"29393","subject":"[PATCH] git-add: allow --ignore-missing always, not just in dry run","startedAt":"2012-01-18T21:52:24Z","lastAt":"2012-02-07T04:39:09Z","messageCount":10,"participants":["Dieter Plaetinck","Junio C Hamano","Thomas Rast","Mike Gant"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"182743","messageId":"1326923544-8287-1-git-send-email-dieter@plaetinck.be","threadId":"29393","inReplyTo":null,"subject":"[PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Dieter Plaetinck","fromEmail":"dieter@plaetinck.be","sentAt":"2012-01-18T21:52:24Z","receivedAt":"2012-01-18T21:52:24Z","isPatch":true,"sender":{"key":"dieter@plaetinck.be","avatar":"https://gravatar.com/avatar/3391e243a22d40c1a778329d30ab844c6e915b2a324ed8167ce86352e36894e5?d=mp&s=160"},"body":"There is no need to restrict use of --ignore-missing to dry runs,\nit can be useful to ignore missing files during normal operation as\nwell.\n\nSigned-off-by: Dieter Plaetinck <dieter@plaetinck.be>\n---\n Documentation/git-add.txt |    9 +++++----\n builtin/add.c             |    4 +---\n 2 files changed, 6 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-add.txt b/Documentation/git-add.txt\nindex 9c1d395..c6fae9f 100644\n--- a/Documentation/git-add.txt\n+++ b/Documentation/git-add.txt\n@@ -138,10 +138,11 @@ subdirectories.\n \ttrue to make this the default behaviour.\n \n --ignore-missing::\n-\tThis option can only be used together with --dry-run. By using\n-\tthis option the user can check if any of the given files would\n-\tbe ignored, no matter if they are already present in the work\n-\ttree or not.\n+\tIf some files could not be added because they are missing,\n+\tdo not raise any error but continue adding the others.\n+\tBy using this option with --dry-run the user can check if\n+\tany of the given files would be ignored,\n+\tno matter if they are already present in the work tree or not.\n \n \\--::\n \tThis option can be used to separate command-line options from\ndiff --git a/builtin/add.c b/builtin/add.c\nindex 1c42900..e702714 100644\n--- a/builtin/add.c\n+++ b/builtin/add.c\n@@ -326,7 +326,7 @@ static struct option builtin_add_options[] = {\n \tOPT_BOOLEAN('A', \"all\", &addremove, \"add changes from all tracked and untracked files\"),\n \tOPT_BOOLEAN( 0 , \"refresh\", &refresh_only, \"don't add, only refresh the index\"),\n \tOPT_BOOLEAN( 0 , \"ignore-errors\", &ignore_add_errors, \"just skip files which cannot be added because of errors\"),\n-\tOPT_BOOLEAN( 0 , \"ignore-missing\", &ignore_missing, \"check if - even missing - files are ignored in dry run\"),\n+\tOPT_BOOLEAN( 0 , \"ignore-missing\", &ignore_missing, \"just skip files which do not exist\"),\n \tOPT_END(),\n };\n \n@@ -388,8 +388,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)\n \n \tif (addremove && take_worktree_changes)\n \t\tdie(_(\"-A and -u are mutually incompatible\"));\n-\tif (!show_only && ignore_missing)\n-\t\tdie(_(\"Option --ignore-missing can only be used together with --dry-run\"));\n \tif ((addremove || take_worktree_changes) && !argc) {\n \t\tstatic const char *here[2] = { \".\", NULL };\n \t\targc = 1;\n-- \n1.7.8.3\n"},{"id":"182751","messageId":"7vobu0liwj.fsf@alter.siamese.dyndns.org","threadId":"29393","inReplyTo":"1326923544-8287-1-git-send-email-dieter@plaetinck.be","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-18T22:56:12Z","receivedAt":"2012-01-18T22:56:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dieter Plaetinck <dieter@plaetinck.be> writes:\n\n> There is no need to restrict use of --ignore-missing to dry runs,\n> it can be useful to ignore missing files during normal operation as\n> well.\n>\n> Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>\n\nSorry, but for this kind of change, we would want to see a justification\nthat is much better than that. The default around here is not to change an\nestablished behaviour without a good reason.\n\nHave you dug into the list archive to see _why_ we decided not to allow\nthis option in the real run in the first place? You would need to find \"By\nletting the command ignore missing paths, the user can get into X and Y\nsituations and we would want to avoid it. We however need to give users a\nway to see if there is something missing, hence we add it when we are\nunder dry-run option.\" and refute that previous justification, arguing why\nX and Y is something we should _not_ be worrying about, to make a good\ncase for this change.\n\nIn this particular case, my gut feeling is that this might a change in the\ngood direction (but I strongly suspect that I am not recalling the real\nreason why we didn't allow it when we introduced this option).\n\nIf somebody is writing a script using \"git add\" (which is not recommended\nto begin with), it is tempting to say 'git add $list_of_possible_files' in\nsuch a script when the script _knows_ that the list it is giving to \"git\nadd\" may contain a path that does not exist, and wants to ignore missing\nones.\n\nBut then the script could easily filter what does not exist before\ncompiling such a list, so that is not a very strong reason to advocate\nit.\n"},{"id":"182783","messageId":"20120119115216.2773a02f@plaetinck.be","threadId":"29393","inReplyTo":"7vobu0liwj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Dieter Plaetinck","fromEmail":"dieter@plaetinck.be","sentAt":"2012-01-19T10:52:16Z","receivedAt":"2012-01-19T10:52:16Z","isPatch":true,"sender":{"key":"dieter@plaetinck.be","avatar":"https://gravatar.com/avatar/3391e243a22d40c1a778329d30ab844c6e915b2a324ed8167ce86352e36894e5?d=mp&s=160"},"body":"On Wed, 18 Jan 2012 14:56:12 -0800\nJunio C Hamano <gitster@pobox.com> wrote:\n\n> Dieter Plaetinck <dieter@plaetinck.be> writes:\n> \n> > There is no need to restrict use of --ignore-missing to dry runs,\n> > it can be useful to ignore missing files during normal operation as\n> > well.\n> >\n> > Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>\n> \n> Sorry, but for this kind of change, we would want to see a\n> justification that is much better than that. The default around here\n> is not to change an established behaviour without a good reason.\n\nHello Junio, thanks for your quick and elaborate response.\n \n> Have you dug into the list archive to see _why_ we decided not to\n> allow this option in the real run in the first place?\n\nActually I did, before submitting this patch.\nFrom what I could find, the original patch [1] only cared about having this\nfeature available in dry run, and came with this \"only in dry run\" restriction,\nmerely because it was the only use case considered.\nI couldn't find any evidence of this restriction actually being needed nor\nany discussion of this matter. I added Jens to this mail, as he wrote\nthe original patch.\n\n> You would need\n> to find \"By letting the command ignore missing paths, the user can\n> get into X and Y situations and we would want to avoid it. We however\n> need to give users a way to see if there is something missing, hence\n> we add it when we are under dry-run option.\" and refute that previous\n> justification, arguing why X and Y is something we should _not_ be\n> worrying about, to make a good case for this change.\n\nYes, ignoring missing files can lead to files not actually being added, if they are missing.\nBut that's why this is an optional flag to needs to explicitly passed.\nThe flag is clear about what it does, so if users enable it, I don't see the problem?\n\n> If somebody is writing a script using \"git add\" (which is not\n> recommended to begin with), it is tempting to say 'git add\n> $list_of_possible_files' in such a script when the script _knows_\n> that the list it is giving to \"git add\" may contain a path that does\n> not exist, and wants to ignore missing ones.\n> \n> But then the script could easily filter what does not exist before\n> compiling such a list, so that is not a very strong reason to advocate\n> it.\n\nThe use case is as follows:\nI'm working on a tool [2] which runs in the background, and automatically synchronizes file/directory trees,\nby using inotify events, and synchronizing changes in the working tree to the\nindex automatically, committing automatically and push/pulling automatically.\nBasically for when you want to version a tree with git, but without needing to manually\ncommit all the time. (useful for a directory with notes as text files, for example)\nthe problem is, you can have a constant stream of inotify events (if files are being\nedited/deleted/(re)created all the time), and at the point where my tool decides to automatically commit the changes it just saw,\nmore changes (deletes, renames, readding a file that was just deleted, ..) can happen around the same time.\nSo basically, if this tool needs to check which files still/no-longer exist before calling git-add,\nthat's vulnerable to race conditions.\nThe only real solution against race conditions is to deal with (ignore) missing files right at the point where git\nadds them to the index.\n\nBut if \"git add\" is not the right way, please let me know the alternative.\nFrom what I can find \"git add --all --ignore-missing <file>\" (with my patch for allowing ignore-missing without dry run) would be the most appropriate,\nthis would never accidentially modify the working tree (as \"git rm\" for a deleted file could, if the file gets readded at the same point\nwhere we call git), and it would gracefully handle changes we didn't see yet (such as new/modified files disappearing again)\n\nthanks again for the feedback,\nDieter\n\n[1] http://kerneltrap.org/mailarchive/git/2010/7/9/34077\n[2] https://gitorious.org/search?q=dvcs-autosync\n"},{"id":"182784","messageId":"8762g87y4q.fsf@thomas.inf.ethz.ch","threadId":"29393","inReplyTo":"7vobu0liwj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-19T11:03:17Z","receivedAt":"2012-01-19T11:03:17Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"[dropped Dieter as this really goes off on an internal tangent]\n\nJunio C Hamano <gitster@pobox.com> writes:\n\n> If somebody is writing a script using \"git add\" (which is not recommended\n> to begin with)\n\nCan we still stick to that stance?  Our tests are increasingly using\n'git add' instead of 'git update-index --add':\n\n  $ git grep 'git[ -]add' t/ | wc -l\n  1540\n  $ git grep 'git[ -]update-index --add' t/ | wc -l\n  269\n  $ git grep 'git[ -]update-index --add' v1.6.0 t/ | wc -l\n  251\n  $ git grep 'git[ -]add' v1.6.0 t/ | wc -l\n  705\n\nSo while git(1) still says git-add is porcelain (and thus not to be used\nfor scripting), it has mostly superseded 'git update-index --add' in new\nscript usage even within git.git.  I suspect the same goes for things\nlike git-rm, git-commit, etc.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"182799","messageId":"7v8vl3jzst.fsf@alter.siamese.dyndns.org","threadId":"29393","inReplyTo":"8762g87y4q.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-19T18:46:26Z","receivedAt":"2012-01-19T18:46:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n> [dropped Dieter as this really goes off on an internal tangent]\n>\n> Junio C Hamano <gitster@pobox.com> writes:\n>\n>> If somebody is writing a script using \"git add\" (which is not recommended\n>> to begin with)\n>\n> Can we still stick to that stance?  Our tests are increasingly using\n> 'git add' instead of 'git update-index --add':\n>\n>   $ git grep 'git[ -]add' t/ | wc -l\n>   1540\n>   $ git grep 'git[ -]update-index --add' t/ | wc -l\n>   269\n>   $ git grep 'git[ -]update-index --add' v1.6.0 t/ | wc -l\n>   251\n>   $ git grep 'git[ -]add' v1.6.0 t/ | wc -l\n>   705\n\nStop being silly.\n\nHave you actually looked at these usage?  Some of them are genuinely\ntesting if \"git add\" works correctly, so it is out of the scope of this\ndiscussion, but others that could be \"git update-index\" are feeding the\npaths known to the script to exist (and we want 'git add' to error out\nif that is not the case).\n\nMore generally, scripts in t/ directories are \"scripts\", but it is totally\ndifferent from the kind of \"user facing script that behaves as if it is a\ncomplete command, taking its own command line arguments, passing them\nthrough to the underlying plumbing commands\".\n"},{"id":"182812","messageId":"7vk44nidtb.fsf@alter.siamese.dyndns.org","threadId":"29393","inReplyTo":"20120119115216.2773a02f@plaetinck.be","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-19T21:26:40Z","receivedAt":"2012-01-19T21:26:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dieter Plaetinck <dieter@plaetinck.be> writes:\n\n> So basically, if this tool needs to check which files still/no-longer\n> exist before calling git-add, that's vulnerable to race conditions.\n\nI do not think you are solving the real problem in your script even if you\nallowed \"add --ignore-missing\".\n\nI suspect you are making things even worse by using \"--ignore-missing\" in\nyour script. If a user is actively updating the files in the filesystem,\nat least \"git add\" without \"--ignore-missing\" would catch the case where\nyou _thought_ the user modified but still has the file, but in reality the\nfurther updates in the working tree removed the file, which is a clear\nindication that the rate you are processing the notify stream is slower\nthan the activity generated by the user and allows you to notice that you\nmay be better off waiting a bit until things calm down before running your\nautomated commit.\n\nAlso, with or without \"--ignore-missing\", I think we have safety valves to\ncause \"git add\" fail if the file being added is updated while git is\nworking on it (i.e. we read and compute the object name, and then store it\ncompressed, and check the hash of what is stored matches the object name\nwe computed earlier, which would fail if the file is updated in the middle\nat the right time).\n\nThis means that the \"--ignore-missing\" option will _not_ eliminate all\ncases where \"git add\" may detect an error and fails. In other words, your\nscript needs to deal with error return from \"git add\" anyway even if we\napplied your patch and you used \"--ignore-missing\" in your script.\n\nI have to say that the basic premise of your script is simply broken, and\nI am afraid that it is unfixable without an atomic snapshot support from\nthe underlying filesystem (i.e. take a snapshot, run 'git add' on it, and\nthen release the snapshot).\n\nHaving said all that, I do agree to the view that it is OK to let it\nhappen if the user explicitly asks a typo'ed pathspec on the command line\nto be ignored for interactive use cases, and for that reason alone, I am\nnot fundamentally opposed to allowing the use of --ignore-missing outside\nthe --dry-run context.\n\nThanks.\n"},{"id":"182850","messageId":"87mx9icz28.fsf@thomas.inf.ethz.ch","threadId":"29393","inReplyTo":"7v8vl3jzst.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-20T12:56:31Z","receivedAt":"2012-01-20T12:56:31Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Thomas Rast <trast@student.ethz.ch> writes:\n>\n>>   $ git grep 'git[ -]add' t/ | wc -l\n>>   1540\n>>   $ git grep 'git[ -]update-index --add' t/ | wc -l\n>>   269\n>>   $ git grep 'git[ -]update-index --add' v1.6.0 t/ | wc -l\n>>   251\n>>   $ git grep 'git[ -]add' v1.6.0 t/ | wc -l\n>>   705\n>\n> Stop being silly.\n>\n> Have you actually looked at these usage?  Some of them are genuinely\n> testing if \"git add\" works correctly, so it is out of the scope of this\n> discussion, but others that could be \"git update-index\" are feeding the\n> paths known to the script to exist (and we want 'git add' to error out\n> if that is not the case).\n\nI'm sorry if I sound silly, that was totally not the point.  I also\nadmit that I did not look at the usages at all.  I merely wanted to\npoint out that the understanding in the git community *itself* has\nevolved to use git-add instead of git update-index --add in its own\nscripting.  Admittedly the statistics are even more striking than I\ncould possibly hope for.\n\nSo I am challenging the notion that git-add is not recommended for use\nin scripts, which is how I understood your parenthetical remark\n\n} If somebody is writing a script using \"git add\" (which is not recommended\n} to begin with)\n\nWe're no longer following that advice ourselves, how can we expect users\nto adhere to it?\n\n> More generally, scripts in t/ directories are \"scripts\", but it is totally\n> different from the kind of \"user facing script that behaves as if it is a\n> complete command, taking its own command line arguments, passing them\n> through to the underlying plumbing commands\".\n\nI don't understand what distinction you are trying to make here.  Maybe\nmy mental model of the plumbing/porcelain separation (which is mostly\nabout interface stability) is wrong?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"182862","messageId":"7vobtyfe06.fsf@alter.siamese.dyndns.org","threadId":"29393","inReplyTo":"87mx9icz28.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-20T18:03:05Z","receivedAt":"2012-01-20T18:03:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n>> More generally, scripts in t/ directories are \"scripts\", but it is totally\n>> different from the kind of \"user facing script that behaves as if it is a\n>> complete command, taking its own command line arguments, passing them\n>> through to the underlying plumbing commands\".\n>\n> I don't understand what distinction you are trying to make here.  Maybe\n> my mental model of the plumbing/porcelain separation (which is mostly\n> about interface stability) is wrong?\n\nWhat's so hard to understand that these tests are very different from\nend-user scripts?\n\nWe could have shipped you a written instruction to type these commands\nfrom your shell and made you responsible for running them every time we\nrelease a new version. That would have been more true to the intent of\nthese test scripts. The test being implemented as scripts is merely a\nsubstitute for hiring one Thomas Rast as a test engineer to type them from\nthe terminal ;-).\n\nUser-facing scripts (Porcelain enhancements) people write are in a totally\ndifferent boat. They take input and have code to make their own decision\nwhat kind of arguments and inputs to feed to their underlying building\nblocks. They may even parse output from the commands they invoke to base\ntheir decision that affects what happens next. Our tests start from a\nknown state (i.e. empty trash directory), take input from neither command\nline, human interaction nor the filesystem content of the day, that affect\nthe input to the commands they drive.\n\nTo put it another way, if you have a cron job that does\n\n    cd $HOME/diary && git add MyDiary.txt\n\nthat is perfectly fine. You are letting the machine do the typing for you\nevery hour, instead of having you type these yourself. It is even OK if\nthe filename was derived from `date` or something, i.e.\n\n    N=$(date +'%Y-%m-%d').txt &&\n    if test -f \"$N\"\n    then\n\tgit add \"$N\"\n    fi\n\nWhat is not OK is to attempt parsing from Porcelain output to decide what\nto do next. \"git branch | sed -ne 's/^\\* //p'\" is a typical example.\n\nOur tests are different for another important reason you seem to be\nmissing. The tests we ship are tied very closely with the version of Git\nthey are testing. Even parsing the command output is acceptable for our\ntests for this reason (obviously that is the only way to make sure that we\nare issuing an appropriate error, warning, or advice message to the end\nuser). End-user scripts do not have that property.\n\nAnd the biggest thing you should consider is that 99% of users are too\nbusy to bother thinking for themselves and instead prefer to be handed\ndown a concise recipe to follow blindly. You could include \"in this, that,\nand that other situation, it is OK to use Porcelain command\" to the\nrecipe, but doing so defeats the whole purpose of having a recipe to begin\nwith, by making the readers responsible for thinking for themselves again.\nThat is why we just give a concise \"Do not use Porcelain commands in your\nscripts as their behaviour is subject to change.\"\n"},{"id":"182865","messageId":"20120120191451.6dac25dd@plaetinck.be","threadId":"29393","inReplyTo":"7vk44nidtb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Dieter Plaetinck","fromEmail":"dieter@plaetinck.be","sentAt":"2012-01-20T18:14:51Z","receivedAt":"2012-01-20T18:14:51Z","isPatch":true,"sender":{"key":"dieter@plaetinck.be","avatar":"https://gravatar.com/avatar/3391e243a22d40c1a778329d30ab844c6e915b2a324ed8167ce86352e36894e5?d=mp&s=160"},"body":"On Thu, 19 Jan 2012 13:26:40 -0800\nJunio C Hamano <gitster@pobox.com> wrote:\n\n> Dieter Plaetinck <dieter@plaetinck.be> writes:\n> \n> > So basically, if this tool needs to check which files\n> > still/no-longer exist before calling git-add, that's vulnerable to\n> > race conditions.\n> \n> I do not think you are solving the real problem in your script even\n> if you allowed \"add --ignore-missing\".\n> \n> I suspect you are making things even worse by using\n> \"--ignore-missing\" in your script. If a user is actively updating the\n> files in the filesystem, at least \"git add\" without\n> \"--ignore-missing\" would catch the case where you _thought_ the user\n> modified but still has the file, but in reality the further updates\n> in the working tree removed the file, which is a clear indication\n> that the rate you are processing the notify stream is slower than the\n> activity generated by the user and allows you to notice that you may\n> be better off waiting a bit until things calm down before running\n> your automated commit.\n\nI don't understand what you mean. if this happened:\n1) modify file\n2) modify file\n3) remove file\nbut my script tries to git add --ignore-missing, when 3) already happened\nbut the script only sees event 2)\nthen it will not fail, then catch the 3rd event, then do a git rm.\nif however, i don't enable ignore-missing, there's a failure on the git add.\nI guess what you're saying is \"better to get an error, interpret it as `this may not be a \"real\" error`, just continue\"\n\n> \n> Also, with or without \"--ignore-missing\", I think we have safety\n> valves to cause \"git add\" fail if the file being added is updated\n> while git is working on it (i.e. we read and compute the object name,\n> and then store it compressed, and check the hash of what is stored\n> matches the object name we computed earlier, which would fail if the\n> file is updated in the middle at the right time).\n> \n> This means that the \"--ignore-missing\" option will _not_ eliminate all\n> cases where \"git add\" may detect an error and fails. In other words,\n> your script needs to deal with error return from \"git add\" anyway\n> even if we applied your patch and you used \"--ignore-missing\" in your\n> script.\n> \n> I have to say that the basic premise of your script is simply broken,\n> and I am afraid that it is unfixable without an atomic snapshot\n> support from the underlying filesystem (i.e. take a snapshot, run\n> 'git add' on it, and then release the snapshot).\n\nI assumed that `git add` works atomically. (as in: if you git add a file and\nmodify that file at the same time, either the old or the new version will be added\nto the index, but always successfully).\nIf I understand this correctly, `git add` can only be successful if at least the file\nremains untouched while the git command runs.\nThis means I should change my entire approach and be aware that git may return failures when the user is changing files while we are adding to the index. \nMaybe I should do something like:\nonce >0 inotify events happened,\n* run git status, for each file in git status, if we've seen events, try to add file to the index.\nif the above fails, wait a few seconds, then try again. if failures persist a few times in a row, only then we can be reasonbly sure something is really wrong.\n\nbut there will always be the case where a file gets deleted and (re)added, there is always the risk for races:\n1) my script runs \"git rm\" after seeing a \"delete\" event but the file has been added in the meanwhile... git removes the file => bad\n2) my script runs \"git add\" after seeing a new/changed file but the file has been removed in the meanwhile... git gives an error.\nand in the latter case you can't just apply the \"just retry\" trick I mentioned above because the next event is delete, which would trigger a \"git rm\",\npotentially causing unrecoverable data loss as described in 1).\n\none example of such things happening in real life is vim which creates (and removes) tmp files called `4913`.\nWe could just add such filenames to gitignore,\nbut that seems like a bit of a burden which shouldn't be needed.\n\nTo avoid the risks mentioned above and the \"file can be altered during git add command\",\nwhat i'm really looking for is a way to, for a given file (file for which I've seen inotify events):\nsynchronize changes of that file to the index even if the file was unknown to git, or doesn't exist anymore;\nand do that in an atomic way (or: i'll just retry a few times until it fails consistently, but removal race conditions can lead to data loss)\n\nI tried `git update-index` as you suggested but couldn't have it behave like that.\nAnd something like `git add --all` can still cause a file removal when it shouldn't, and lead to uncoverable data loss on race conditions.\n\nSorry for the long mail, I tried to keep it as minimal as possible.\n\nthanks!\nDieter\n"},{"id":"184092","messageId":"20120207043909.GA16349@gantsfort.com","threadId":"29393","inReplyTo":"1326923544-8287-1-git-send-email-dieter@plaetinck.be","subject":"Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run","fromName":"Mike Gant","fromEmail":"mwgant@gmail.com","sentAt":"2012-02-07T04:39:09Z","receivedAt":"2012-02-07T04:39:09Z","isPatch":true,"sender":{"key":"mwgant@gmail.com","avatar":null},"body":"On Wed, Jan 18, 2012 at 10:52:24PM +0100, Dieter Plaetinck wrote:\n> There is no need to restrict use of --ignore-missing to dry runs,\n> it can be useful to ignore missing files during normal operation as\n> well.\n\nFWIW I would be in favor of this change and I was going to submit a\npatch, too. My use case is different, though. I create branches that\nwill never be merged to the mainline because they have files added that\nI don't want in master. The files added to these branches can vary. In\nmy script to create the branch, I want the largest possible set of these\nfiles as the argument to 'git add' but if not all exist it's okay. I\nrealize I can write my script to only add the files that exist but I'm\nlazy ;) and the --ignore-missing option would be easier.\n\nMike\n"}]}