{"thread":{"id":"842","subject":"[PATCH] Documentation: describe git extended diff headers.","startedAt":"2005-06-05T21:39:49Z","lastAt":"2005-06-08T09:08:54Z","messageCount":25,"participants":["Junio C Hamano","Linus Torvalds","Thomas Glanzmann","McMullan, Jason"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"4610","messageId":"7voeak1o0q.fsf@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":null,"subject":"[PATCH] Documentation: describe git extended diff headers.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-05T21:39:49Z","receivedAt":"2005-06-05T21:39:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The documentation failed to describe \"diff --git\" extended diff\nheaders, so add some.\n\nSigned-off-by: Junio C Hamano \n---\n\n Documentation/diff-format.txt | 36 +++++++++++++++++++++++++++++++++++-\n 1 files changed, 35 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt\n--- a/Documentation/diff-format.txt\n+++ b/Documentation/diff-format.txt\n@@ -52,7 +52,7 @@ Generating patches with -p\n --------------------------\n \n When \"git-diff-cache\", \"git-diff-tree\", or \"git-diff-files\" are run\n-with a '-p' option, they do not produce the output described above\n+with a '-p' option, they do not produce the output described above;\n instead they produce a patch file.\n \n The patch generation can be customized at two levels. This\n@@ -98,3 +98,37 @@ temporary file --- it is removed when 'G\n \n For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1\n parameter, .\n+\n+\n+Git specific extention to diff format\n+-------------------------------------\n+\n+What -p option produces is slightly different from the\n+traditional diff format.\n+\n+ (1) It is preceeded with a \"git diff\" header, that looks like\n+ this:\n+\n+ diff --git a/file1 b/file2\n+\n+ The a/ and b/ filenames are the same unless rename/copy is\n+ involved. Especially, even for a creation or a deletion,\n+ /dev/null is _not_ used in place of a/ or b/ filename.\n+\n+ When rename/copy is involved, file1 and file2 shows the\n+ name of the source file of the rename/copy and the name of\n+ the file that rename/copy produces, respectively.\n+\n+ (2) It is followed by extended header lines that are one or\n+ more of:\n+\n+ old mode \n+ new mode \n+ deleted file mode \n+ new file mode \n+ copy from \n+ copy to \n+ rename from \n+ rename to \n+ similarity index \n+ dissimilarity index \n------------\n\n"},{"id":"4611","messageId":"Pine.LNX.4.58.0506051509490.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"7voeak1o0q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: describe git extended diff headers.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-05T22:11:26Z","receivedAt":"2005-06-05T22:11:26Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Jun 2005, Junio C Hamano wrote:\n>\n> The documentation failed to describe \"diff --git\" extended diff\n> headers, so add some.\n\nYou document the \"rename\" header as being \"rename from/to\", which is \nsensible, but doesn't match reality. diff.c has \"rename old/new\". I found \nthat out the hard way when doing git-apply ;)\n\nI'd almost prefer fixing diff.c (and now apply.c). Comments?\n\n\t\tLinus\n"},{"id":"4612","messageId":"7vekbg1lw9.fsf_-_@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506051509490.1876@ppc970.osdl.org","subject":"[PATCH] Fix diff.c to match rename extended header to the document.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-05T22:25:42Z","receivedAt":"2005-06-05T22:25:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> On Sun, 5 Jun 2005, Junio C Hamano wrote:\n>> \n>> The documentation failed to describe \"diff --git\" extended diff\n>> headers, so add some.\n\nLT> You document the \"rename\" header as being \"rename from/to\", which is \nLT> sensible, but doesn't match reality. diff.c has \"rename old/new\". I found \nLT> that out the hard way when doing git-apply ;)\n\nLT> I'd almost prefer fixing diff.c (and now apply.c). Comments?\n\nYes, sir ;-).\n\n------------\nThis matches the git extended header to what is documented.\nThere is no need to touch git-external-diff-script since it gets\nthe string generated here and simply spits it out.\n\nSigned-off-by: Junio C Hamano \n---\ncd /opt/packrat/playpen/public/in-place/git/git.junio/\njit-diff\n# - linus: git-apply: fix rename header parsing\n# + (working tree)\ndiff --git a/diff.c b/diff.c\n--- a/diff.c\n+++ b/diff.c\n@@ -786,8 +786,8 @@ static void diff_flush_patch(struct diff\n \tcase 'R':\n \t\tsprintf(msg_,\n \t\t\t\"similarity index %d%%\\n\"\n-\t\t\t\"rename old %s\\n\"\n-\t\t\t\"rename new %s\",\n+\t\t\t\"rename from %s\\n\"\n+\t\t\t\"rename to %s\",\n \t\t\t(int)(0.5 + p->score * 100.0/MAX_SCORE),\n \t\t\tp->one->path, p->two->path);\n \t\tmsg = msg_;\n\nCompilation finished at Sun Jun 5 15:23:44\n\n"},{"id":"4613","messageId":"7v8y1o1ltn.fsf_-_@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506051509490.1876@ppc970.osdl.org","subject":"[PATCH] Fix apply.c to match rename extended header to the document.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-05T22:27:16Z","receivedAt":"2005-06-05T22:27:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This matches the git extended header git-apply expects to what\nis documented.\n\nSigned-off-by: Junio C Hamano \n---\n# - linus: git-apply: fix rename header parsing\n# + (working tree)\ndiff --git a/apply.c b/apply.c\n--- a/apply.c\n+++ b/apply.c\n@@ -435,8 +435,8 @@ static int parse_git_header(char *line, \n \t\t\t{ \"new file mode \", gitdiff_newfile },\n \t\t\t{ \"copy from \", gitdiff_copysrc },\n \t\t\t{ \"copy to \", gitdiff_copydst },\n-\t\t\t{ \"rename old \", gitdiff_renamesrc },\n-\t\t\t{ \"rename new \", gitdiff_renamedst },\n+\t\t\t{ \"rename from \", gitdiff_renamesrc },\n+\t\t\t{ \"rename to \", gitdiff_renamedst },\n \t\t\t{ \"similarity index \", gitdiff_similarity },\n \t\t\t{ \"dissimilarity index \", gitdiff_dissimilarity },\n \t\t\t{ \"\", gitdiff_unrecognized },\n\n"},{"id":"4614","messageId":"Pine.LNX.4.58.0506051532440.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"7v8y1o1ltn.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Fix apply.c to match rename extended header to the document.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-05T22:33:20Z","receivedAt":"2005-06-05T22:33:20Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Jun 2005, Junio C Hamano wrote:\n>\n> This matches the git extended header git-apply expects to what\n> is documented.\n\nWell you also need to fix the tests. \n\nI did it all, and pushed out. And I left git-apply accepting the old \nformat, at least for a while.\n\n\t\tLinus\n"},{"id":"4617","messageId":"7vk6l8xue5.fsf_-_@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506051509490.1876@ppc970.osdl.org","subject":"Last mile for 1.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-05T23:21:06Z","receivedAt":"2005-06-05T23:21:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> You document the \"rename\" header as being \"rename from/to\", which is \nLT> sensible, but doesn't match reality. diff.c has \"rename old/new\". I found \nLT> that out the hard way when doing git-apply ;)\n\nThe document was cut & paste from the version of apply.c before\nyou found it out \"the hard way\", so of course its wording is\nsensible ;-) Anyway, I think we settled this part.\n\nThere are still some remaining issues before 1.0. The ones I\npersonally would want to see merged and/or addressed are:\n\n - git-ssh-push documentation updates from Dan Barkalow, which\n he mentions in *1*. I am the primarily guilty one about\n \"other people seem to have missed it\".\n\n - \"-w heads/master heads/master\" extension to the pull family,\n again from Dan, mentioned in the same message.\n\n - \"--merge-order\" extension to the git-rev-list, from Jon\n Seymour, last posted as *2*. I have not tried it on\n something big (like linux-2.6 repository) and cannot vouch\n for its correctness myself, but I find what it claims to do\n quite sensible and attractive.\n\n - Tutorials you have been working on. I'd appreciate it if my\n earlier \"what about cvs annotate\" example *3* finds its home\n somewhere in that document ;-).\n\n - \"What happens when a merge goes wrong\" helper script Jeff\n wanted to have in *4*.\n\n - Documentation from Jason McMullan for more commands, reminded\n by Petr Baudis in *5*.\n\n[References]\n\n*1* \n\n*2* <20050605134733.3123.qmail@blackcubes.dyndns.org>\n\n*3* <7vll5s35pd.fsf@assigned-by-dhcp.cox.net>\n\n*4* <42A181C1.3010902@pobox.com>\n\n*5* <20050605204739.GR17462@pasky.ji.cz>\n\n"},{"id":"4619","messageId":"7vzmu4weod.fsf@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"7vk6l8xue5.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: Last mile for 1.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-05T23:45:54Z","receivedAt":"2005-06-05T23:45:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I did not mention git-sync by Jason McMullan on my list of \"what\nI want to have in 1.0\", but that was not because I object to the\nidea of having a sync mechanism that knows and takes advantage\nof how GIT works. Quite the contrary.\n\nI would like to see such a GIT specific smart sync mechanism\nsome day. git-http-pull lets us use a dumb server and cannot\nassume server-side smarts, git-local-pull operates in an\nenvironment where latency does not matter, but git-ssh-pull and\ngit-sync are solutions for the real network environment where\nlatency matters, and having a smart sync mechanism is a big win.\n\nI just do not feel, judging from its current protocol command\nset, it offers enough improvements over what git-ssh-push/pull\npairs already give us; I'd be happy to be corrected, of course,\nif this is a misconception.\n\n"},{"id":"4622","messageId":"Pine.LNX.4.58.0506051658100.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"7vk6l8xue5.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: Last mile for 1.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-06T00:02:41Z","receivedAt":"2005-06-06T00:02:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Jun 2005, Junio C Hamano wrote:\n> \n> - Tutorials you have been working on. I'd appreciate it if my\n> earlier \"what about cvs annotate\" example *3* finds its home\n> somewhere in that document ;-).\n\nMy main dislike about that was that I don't think -S is \"better\" than\nannotate as you claim - I think it's different and can be better in many\ncircumstances, but I don't like the notion of telling a new user \"you\ndon't want annotate, pickaxe is better\".\n\nLet's just be upfront about some things being missing, and suggest\nalternatives. A lot of times, just \"git-whatchanged -p filename\" ends up\nbeing sufficient, at other times -S might be.\n\nFinally, please send it as a patch, that way the authorship etc stuff gets \ndone right.\n\n> - \"What happens when a merge goes wrong\" helper script Jeff\n> wanted to have in *4*.\n\nDoes anybody have any suggestions? Preferably with a reasonable \ntest-case, so that people can try it out.. Maybe just leaving the merge \nfailures where they are?\n\n\t\tLinus\n"},{"id":"4624","messageId":"7vekbgwbw1.fsf_-_@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506051658100.1876@ppc970.osdl.org","subject":"[PATCH] git-whatchanged vs \"cvs annotate\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-06T00:46:06Z","receivedAt":"2005-06-06T00:46:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> Let's just be upfront about some things being missing, and suggest\nLT> alternatives.\n\nI agree that being honest is good. Something like this?\n------------\nThis adds a section to talk about \"cvs annotate\".\n\nSigned-off-by: Junio C Hamano \n---\n\n Documentation/cvs-migration.txt | 105 +++++++++++++++++++++++++++++++++++++++\n 1 files changed, 105 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/cvs-migration.txt\n@@ -0,0 +1,105 @@\n+CVS annotate.\n+\n+The core GIT itself does not have a \"cvs annotate\" equivalent.\n+It has something that you may want to use when you would use\n+\"cvs annotate\".\n+\n+Let's step back a bit and think about the reason why you would\n+want to do \"cvs annotate a-file.c\" to begin with.\n+\n+You would use \"cvs annotate\" on a file when you have trouble\n+with a function (or even a single \"if\" statement in a function)\n+that happens to be defined in the file, which does not do what\n+you want it to do. And you would want to find out why it was\n+written that way, because you are about to modify it to suit\n+your needs, and at the same time you do not want to break its\n+current callers. For that, you are trying to find out why the\n+original author did things that way in the original context.\n+\n+Many times, it may be enough to see the commit log messages of\n+commits that touch the file in question, possibly along with the\n+patches themselves, like this:\n+\n+\t$ git-whatchanged -p a-file.c\n+\n+This will show log messages and patches for each commit that\n+touches a-file.\n+\n+This, however, may not be very useful when this file has many\n+modifications that are not related to the piece of code you are\n+interested in. You would see many log messages and patches that\n+do not have anything to do with the piece of code you are\n+interested in. As an example, assuming that you have this piece\n+code that you are interested in in the HEAD version:\n+\n+\tif (frotz) {\n+\t\tnitfol();\n+\t}\n+\n+you would use git-rev-list and git-diff-tree like this:\n+\n+\t$ git-rev-list HEAD |\n+\t git-diff-tree --stdin -v -p -S'if (frotz) {\n+\t\tnitfol();\n+\t}'\n+\n+We have already talked about the \"--stdin\" form of git-diff-tree\n+command that reads the list of commits and compares each commit\n+with its parents. The git-whatchanged command internally runs\n+the equivalent of the above command, and can be used like this:\n+\n+\t$ git-whatchanged -p -S'if (frotz) {\n+\t\tnitfol();\n+\t}'\n+\n+When the -S option is used, git-diff-tree command outputs\n+differences between two commits only if one tree has the\n+specified string in a file and the corresponding file in the\n+other tree does not. The above example looks for a commit that\n+has the \"if\" statement in it in a file, but its parent commit\n+does not have it in the same shape in the corresponding file (or\n+the other way around, where the parent has it and the commit\n+does not), and the differences between them are shown, along\n+with the commit message (thanks to the -v flag). It does not\n+show anything for commits that do not touch this \"if\" statement.\n+\n+Also, in the original context, the same statement might have\n+appeared at first in a different file and later the file was\n+renamed to \"a-file.c\". CVS annotate would not help you to go\n+back across such a rename, but GIT would still help you in such\n+a situation. For that, you can give the -C flag to\n+git-diff-tree, like this:\n+\n+\t$ git-whatchanged -p -C -S'if (frotz) {\n+\t\tnitfol();\n+\t}'\n+\n+When the -C flag is used, file renames and copies are followed.\n+So if the \"if\" statement in question happens to be in \"a-file.c\"\n+in the current HEAD commit, even if the file was originally\n+called \"o-file.c\" and then renamed in an earlier commit, or if\n+the file was created by copying an existing \"o-file.c\" in an\n+earlier commit, you will not lose track. If the \"if\" statement\n+did not change across such rename or copy, then the commit that\n+does rename or copy would not show in the output, and if the\n+\"if\" statement was modified while the file was still called\n+\"o-file.c\", it would find the commit that changed the statement\n+when it was in \"o-file.c\".\n+\n+[ BTW, the current versions of \"git-diff-tree -C\" is not eager\n+ enough to find copies, and it will miss the fact that a-file.c\n+ was created by copying o-file.c unless o-file.c was somehow\n+ changed in the same commit.]\n+\n+You can use the --pickaxe-all flag in addition to the -S flag.\n+This causes the differences from all the files contained in\n+those two commits, not just the differences between the files\n+that contain this changed \"if\" statement:\n+\n+\t$ git-whatchanged -p -C -S'if (frotz) {\n+\t\tnitfol();\n+\t}' --pickaxe-all\n+\n+[ Side note. This option is called \"--pickaxe-all\" because -S\n+ option is internally called \"pickaxe\", a tool for software\n+ archaeologists.]\n------------\n\n"},{"id":"4628","messageId":"20050606054356.GB3669@cip.informatik.uni-erlangen.de","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506051658100.1876@ppc970.osdl.org","subject":"Re: Last mile for 1.0","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-06-06T05:43:56Z","receivedAt":"2005-06-06T05:43:56Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> > - \"What happens when a merge goes wrong\" helper script Jeff\n> > wanted to have in *4*.\n\n> Does anybody have any suggestions? Preferably with a reasonable \n> test-case, so that people can try it out.. Maybe just leaving the merge \n> failures where they are?\n\nI think the simplest and effectivies way to handle this is the\nfollowing: Add a flag to the current merge script which indicates that\non conflicts the user will be dropped to a shell per conflict to solve:\n\n\t- Checkout filename.LOCAL, filename.REMOTE, filename.GCA (with\n\t sanitychecks of course (eg not overwriting existing files)\n\t- Run merga -A on them and maybe wiggle and write the product in\n\t filename\n\t- If the user resolves the conflict drop him a note to\n\t 'update-cache' the resolved conflict and exit the subshell.\n\nI also have at the moment a very nice perl merge script which works with\nmultiple heads, duplicates and stuff. Maybe I should write this down in\nbash.\n\nThe above approach worked out very good at least for me. I often had to\nresolve 'simple' conflicts when pulling in upstream changes from Linus\nrepo.\n\n\tThomas\n"},{"id":"4630","messageId":"Pine.LNX.4.58.0506052300350.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"20050606054356.GB3669@cip.informatik.uni-erlangen.de","subject":"Re: Last mile for 1.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-06T06:13:11Z","receivedAt":"2005-06-06T06:13:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 6 Jun 2005, Thomas Glanzmann wrote:\n> \n> I think the simplest and effectivies way to handle this is the\n> following: Add a flag to the current merge script which indicates that\n> on conflicts the user will be dropped to a shell per conflict to solve:\n\nWell, there was actually a much more fundamental problem, which is that \nthe merge script depended on being able to do\n\n\tgit-checkout-cache -f -u -a\n\nwhich in turn obviously meant that _whatever_ it did, it would end up \noverwriting any dirty state in the working tree.\n\nAnd you can't remove the git-checkout-cache, because after the merge we've \nlost the original state anyway, so there's no way to know whether whatever \nyou had in the working directory was dirty or not.\n\nSo I've actually been working now to make the very low-level git-read-tree \nDo The Right Thing (tm), and I think I'm getting there. It basically \ndepends on \"git-read-tree\" noticing when the state is dirty enough that we \ncan't safely do the merge, and then for the safe cases it can actually \nupdate anything it merged properly. As a result, there's never any need \nfor git-checkout-cache, and the only thing that needs updating in the \nworking directory is the stuff that we end up merging by hand _outside_ of \ngit-read-tree.\n\nThere's two cases: fast-forward and a real merge. And the thing is, to do \neven just the fast-forward safely, it actually needs to know what the base \ntree was (otherwise it can only tell that the file was up-to-date in the \nindex, but it can't know whether the index actually matched the original \nHEAD..). So now the fast-forward case is actually a two-way merge:\n\n\tgit-read-tree -u -m HEAD NEW_HEAD\n\nwhere \"-u\" stands for \"update\", and tells read-tree that it should check \nout the files it merges up. \n\nAnd now git-read-tree also tries to be very careful: if one of the files \nthat needs to be updated is already dirty, or it doesn't match the \noriginal HEAD, then git-read-tree will just exit with an error and not do \nanything at all.\n\nBut for a file that wasn't touched at all by the merge, we can leave it\ndirty in the index, since whatever dirty index state was valid before the\nmerge is obviously valid after it too. So now you can have dirty state in \nyour tree, and merges will complain only if it matters to them.\n\nSame goes for the (much more complex) three-way merge, of course. There\nthe rules are a bit more complicated, and I'll have to double-check this\nthing, but it all looks like even if the current state might be buggy, the \nbasic _notion_ looks fine.\n\nSo now we have a one-way merge for \"just update to this tree\", a two-way \nmerge for \"update from this tree to that tree\", and a three-way merge for \n\"merge these two trees with that third tree as a base\".\n\nBy now, I'd really like to have some test-cases. Things like \"file dirty \nin working directory, removed by merge\" would be good.\n\nAnd the \"git-merge-one-file-script\" thing needs to be updated to keep the\ntree updated as it merges things by hand, since it can't depend on the\ngit-checkout-cache fixing things up any more. Anybody?\n\n\t\t\tLinus\n"},{"id":"4631","messageId":"7vpsv0uh5d.fsf@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506052300350.1876@ppc970.osdl.org","subject":"Re: Last mile for 1.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-06T06:35:26Z","receivedAt":"2005-06-06T06:35:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> And the \"git-merge-one-file-script\" thing needs to be updated to keep the\nLT> tree updated as it merges things by hand, since it can't depend on the\nLT> git-checkout-cache fixing things up any more. Anybody?\n\nI'd love to bite. One problem I have been having for the last\n30 minutes or so is that t1000 test (merge from h*ll) does not\nshow that read-tree resolving even the trivial ones anymore, and\nI do not know if you want make it that the responsibility of\ngit-merge-one-file-script, or if it is just an oversight.\n\nI might have leave that to Europeans, though, due to timezone\ndifferences ;-).\n\n"},{"id":"4632","messageId":"Pine.LNX.4.58.0506052341330.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"7vpsv0uh5d.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile for 1.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-06T06:44:52Z","receivedAt":"2005-06-06T06:44:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Jun 2005, Junio C Hamano wrote:\n> >>>>> \"LT\" == Linus Torvalds writes:\n> \n> LT> And the \"git-merge-one-file-script\" thing needs to be updated to keep the\n> LT> tree updated as it merges things by hand, since it can't depend on the\n> LT> git-checkout-cache fixing things up any more. Anybody?\n> \n> I'd love to bite. One problem I have been having for the last\n> 30 minutes or so is that t1000 test (merge from h*ll) does not\n> show that read-tree resolving even the trivial ones anymore, and\n> I do not know if you want make it that the responsibility of\n> git-merge-one-file-script, or if it is just an oversight.\n\nIt was just two really stupid bugs, both due to me trying to make the \nthree different merge loops look a bit more like each other, and that had \nbroken the three-way case in two different ways.\n\nShould be fixed, as soon as the mirroring pushes out the last off-by-one \nfix.\n\n\t\t\tLinus\n"},{"id":"4633","messageId":"20050606064456.GC3669@cip.informatik.uni-erlangen.de","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506052300350.1876@ppc970.osdl.org","subject":"Re: Last mile for 1.0","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-06-06T06:44:56Z","receivedAt":"2005-06-06T06:44:56Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> Well, there was actually a much more fundamental problem, which is that \n> the merge script depended on being able to do\n\n> \tgit-checkout-cache -f -u -a\n\n> which in turn obviously meant that _whatever_ it did, it would end up \n> overwriting any dirty state in the working tree.\n\ntrue. But I don't see the problem. Just ensure that there are no\nuncommitted data and no dirty files before proceeding with the merge by\ncalling:\n\ngit-diff-files -z -r (but ignore the deleted)\ngit-diff-cache -r --cached HEAD\n\n> And you can't remove the git-checkout-cache, because after the merge we've \n> lost the original state anyway, so there's no way to know whether whatever \n> you had in the working directory was dirty or not.\n\n> So I've actually been working now to make the very low-level git-read-tree \n> Do The Right Thing (tm), and I think I'm getting there. It basically \n> depends on \"git-read-tree\" noticing when the state is dirty enough that we \n> can't safely do the merge, and then for the safe cases it can actually \n> update anything it merged properly. As a result, there's never any need \n> for git-checkout-cache, and the only thing that needs updating in the \n> working directory is the stuff that we end up merging by hand _outside_ of \n> git-read-tree.\n\n> There's two cases: fast-forward and a real merge. And the thing is, to do \n> even just the fast-forward safely, it actually needs to know what the base \n> tree was (otherwise it can only tell that the file was up-to-date in the \n> index, but it can't know whether the index actually matched the original \n> HEAD..). So now the fast-forward case is actually a two-way merge:\n\n> \tgit-read-tree -u -m HEAD NEW_HEAD\n\n> where \"-u\" stands for \"update\", and tells read-tree that it should check \n> out the files it merges up. \n\n> And now git-read-tree also tries to be very careful: if one of the files \n> that needs to be updated is already dirty, or it doesn't match the \n> original HEAD, then git-read-tree will just exit with an error and not do \n> anything at all.\n\nNow I see your point. And a cmp-and-xchg HEAD would be useful here, too. What\nif a user tries to shoot himself in the head by pull from two trees\nsimultaneous?\n\n> But for a file that wasn't touched at all by the merge, we can leave it\n> dirty in the index, since whatever dirty index state was valid before the\n> merge is obviously valid after it too. So now you can have dirty state in \n> your tree, and merges will complain only if it matters to them.\n\nNice to have. :-)\n\n> ...\n\n> And the \"git-merge-one-file-script\" thing needs to be updated to keep the\n> tree updated as it merges things by hand, since it can't depend on the\n> git-checkout-cache fixing things up any more. Anybody?\n\nI can't follow you there. AFAIK it retrieves all his files from\ngit-merge-cache and just calls git-update-cache to update the index.\n\n\tThomas\n"},{"id":"4634","messageId":"7vis0sugp7.fsf@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506052300350.1876@ppc970.osdl.org","subject":"Re: Last mile for 1.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-06T06:45:08Z","receivedAt":"2005-06-06T06:45:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> By now, I'd really like to have some test-cases. Things like \"file dirty \nLT> in working directory, removed by merge\" would be good.\n\nIs test 44 in t1000 (the first one in t1000 after the lib-\nread-tree-m-3way prepares the test trees) good enough? Or do\nyou want more specific tests to make sure the logic catches\nindividual cases right?\n\n\n"},{"id":"4635","messageId":"Pine.LNX.4.58.0506052351470.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"20050606064456.GC3669@cip.informatik.uni-erlangen.de","subject":"Re: Last mile for 1.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-06T06:57:07Z","receivedAt":"2005-06-06T06:57:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 6 Jun 2005, Thomas Glanzmann wrote:\n> \n> true. But I don't see the problem. Just ensure that there are no\n> uncommitted data and no dirty files before proceeding with the merge by\n> calling:\n\nThe thing is, I historically _often_ have uncommitted data, and it's been \none of the biggest bummers for me that a merge of a totally unrelated \nthing will crap all over my debugging patch..\n\n> > And now git-read-tree also tries to be very careful: if one of the files \n> > that needs to be updated is already dirty, or it doesn't match the \n> > original HEAD, then git-read-tree will just exit with an error and not do \n> > anything at all.\n> \n> Now I see your point. And a cmp-and-xchg HEAD would be useful here, too. What\n> if a user tries to shoot himself in the head by pull from two trees\n> simultaneous?\n\nIf he uses the same index file, he'll be protected by the index lock. \n\n> > And the \"git-merge-one-file-script\" thing needs to be updated to keep the\n> > tree updated as it merges things by hand, since it can't depend on the\n> > git-checkout-cache fixing things up any more. Anybody?\n> \n> I can't follow you there. AFAIK it retrieves all his files from\n> git-merge-cache and just calls git-update-cache to update the index.\n\nNot exactly. It updates the index directly, without necessarily updating \nthe working directory. For example:\n\n\t\"$1..\" | \"$1.$1\" | \"$1$1.\")\n\t echo \"Removing $4\"\n\t exec git-update-cache --force-remove \"$4\" ;;\n\nit _says_ \"removing $4\", but it never actually does so, so the working \ndirectory still has the file ;)\n\nSame goes with added files or even updated files, where it uses\n\"--cacheinfo\" to update the cache without even touching the working\ndirectory.\n\nAnyway, git-resovle-script needs to be made to use \"git-merge-cache -o\" \ntoo, methinks. And it needs a test-case or two.\n\n\t\tLinus\n"},{"id":"4637","messageId":"20050606070131.GD3669@cip.informatik.uni-erlangen.de","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506052351470.1876@ppc970.osdl.org","subject":"Re: Last mile for 1.0","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-06-06T07:01:31Z","receivedAt":"2005-06-06T07:01:31Z","isPatch":false,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> The thing is, I historically _often_ have uncommitted data, and it's been \n> one of the biggest bummers for me that a merge of a totally unrelated \n> thing will crap all over my debugging patch..\n\ngot the point. I useally work like that, too. But I never did it with a\ndistributed SCM just with CVS.\n\n> If he uses the same index file, he'll be protected by the index lock. \n\nI see.\n\n> Not exactly. It updates the index directly, without necessarily updating \n> the working directory. For example:\n\n> \t\"$1..\" | \"$1.$1\" | \"$1$1.\")\n> \t echo \"Removing $4\"\n> \t exec git-update-cache --force-remove \"$4\" ;;\n\n> it _says_ \"removing $4\", but it never actually does so, so the working \n> directory still has the file ;)\n\n> Same goes with added files or even updated files, where it uses\n> \"--cacheinfo\" to update the cache without even touching the working\n> directory.\n\nNow I see your point.\n\n> Anyway, git-resovle-script needs to be made to use \"git-merge-cache\n> -o\" too, methinks. And it needs a test-case or two.\n\nYes, it does. In my merge script in perl it already does that. :-)\n\n\tThomas\n"},{"id":"4636","messageId":"Pine.LNX.4.58.0506052358330.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"7vis0sugp7.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile for 1.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-06T07:03:09Z","receivedAt":"2005-06-06T07:03:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Jun 2005, Junio C Hamano wrote:\n> \n> Is test 44 in t1000 (the first one in t1000 after the lib-\n> read-tree-m-3way prepares the test trees) good enough? Or do\n> you want more specific tests to make sure the logic catches\n> individual cases right?\n\nI was more thinking of all the individual cases, and also the 2-way merge\nissue (which _should_ be a lot easier, but hey, I had tons of bugs there\ntoo).\n\nFor example, what should happen if you do a merge and you have a file in\nthe index that isn't mentioned by any of the trees involved. I consider \nthat a failure, since the merge will remove the file, and since it wasn't \ncommitted, it's now a \"data lost\" issue. But did I actually get it right? \nI have no idea.\n\n\t\t\tLinus\n"},{"id":"4638","messageId":"7vekbgufra.fsf@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506052351470.1876@ppc970.osdl.org","subject":"Re: Last mile for 1.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-06T07:05:29Z","receivedAt":"2005-06-06T07:05:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> Not exactly. It updates the index directly, without necessarily updating \nLT> the working directory. For example:\n\nLT> \t\"$1..\" | \"$1.$1\" | \"$1$1.\")\nLT> \t echo \"Removing $4\"\nLT> \t exec git-update-cache --force-remove \"$4\" ;;\n\nLT> it _says_ \"removing $4\", but it never actually does so, so the working \nLT> directory still has the file ;)\n\nYes, this was done from your explicit request not to touch the\nworking directory while it works AFAICR. At least back then,\nnot touching the working tree was the _requirement_.\n\nSo is \"the new merge world order\" you mentioned in the log\nmessage now require (and assume) the work tree more-or-less\nmatches the first head being merged?\n\n"},{"id":"4641","messageId":"1118064550.8970.29.camel@jmcmullan.timesys","threadId":"842","inReplyTo":"7vzmu4weod.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile for 1.0","fromName":"McMullan, Jason","fromEmail":"jason.mcmullan@timesys.com","sentAt":"2005-06-06T13:29:09Z","receivedAt":"2005-06-06T13:29:09Z","isPatch":false,"sender":{"key":"jason.mcmullan@timesys.com","avatar":null},"body":"On Sun, 2005-06-05 at 16:45 -0700, Junio C Hamano wrote:\n> I did not mention git-sync by Jason McMullan on my list of \"what\n> I want to have in 1.0\", but that was not because I object to the\n> idea of having a sync mechanism that knows and takes advantage\n> of how GIT works. Quite the contrary.\n> \n> [snip snip]\n>\n> I just do not feel, judging from its current protocol command\n> set, it offers enough improvements over what git-ssh-push/pull\n> pairs already give us; I'd be happy to be corrected, of course,\n> if this is a misconception.\n\nOh, I definitely agree. git-sync is *not* 1.0 material. The protocol\nand feature set are still being worked on, and git-ssh-* may even\nbe a better fix than git-sync for many scenarios.\n\nWhat I *do* want to get into git 1.0 is a merge of git-sync's \nverify-before-write update semantics into pull.c. I should be\nable to get that to you before tomorrow.\n\n-- \nJason McMullan \nTimeSys Corporation\n\n"},{"id":"4643","messageId":"Pine.LNX.4.58.0506060730510.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"7vekbgufra.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile for 1.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-06T14:37:56Z","receivedAt":"2005-06-06T14:37:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 6 Jun 2005, Junio C Hamano wrote:\n> \n> Yes, this was done from your explicit request not to touch the\n> working directory while it works AFAICR. At least back then,\n> not touching the working tree was the _requirement_.\n\nYes. Now that read-tree verifies that the working directory is clean (at\nleast for any non-identity files), it's a non-issue.\n\n> So is \"the new merge world order\" you mentioned in the log\n> message now require (and assume) the work tree more-or-less\n> matches the first head being merged?\n\nWell, without \"-u\" you should see the old \"order doesn't matter\" case, but\nyes, the theory is that the three trees are for\nthe three-way case, and for the two-way one.\n\nYou can get the old behaviour by using\n\n\tgit-read-tree -m \n\tgit-read-tree -m \n\nwhere the first read-tree ends up just makign sure that the index file \nmatches the current head (use \"-u\" or not as you like).\n\n(Side note: the actual read-tree phase should be totally agnostic about \nwhether the current tree is the first, second or third of the trees, since \nit will happily say \"oh, we saw this exact directory entry in _one_ of the \ntrees, so we know it hasn't gotten lost\". So for now, order still is left \nto the final user, but I don't think you should depend on that).\n\n\t\tLinus\n"},{"id":"4644","messageId":"Pine.LNX.4.58.0506060738170.1876@ppc970.osdl.org","threadId":"842","inReplyTo":"7vacm4ufnl.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile for 1.0","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-06-06T14:47:52Z","receivedAt":"2005-06-06T14:47:52Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n[ git list added back in, since I migth as well explain the thinking here ]\n\nOn Mon, 6 Jun 2005, Junio C Hamano wrote:\n>\n> I've sent you a reply in another thread, but I really think you\n> need to make this \"new merge world order\" a bit more explicit.\n> My understanding of your (earlier) wish was that you wanted the\n> merge not to touch and look at any work tree material, but it\n> appears to me that this round you actually expect the work tree\n> be populated and more-or-less match the first head being merged.\n\nActually, no. I expect the old _index_ to be at least not _more_ populated \nthan the trees I merge. That's not a working tree issue, that's a \"we \ndon't want to drop information from the index\".\n\nAnd yes, if you use \"-u\", it will populate the working tree too, but \nthat's really totally unimportant from the algorithm itself.\n\nBut you can very much do everything in-index as before, if you want to. A \npure index merge would be done usually in a new temporary index file, \nsomething like\n\n rm -f .git/tmp_index\n GIT_INDEX_FILE=.git/tmp_index git-read-tree -m \n\nand the new changes don't change that.\n\nHOWEVER, it's all set up to be very clever indeed. My immediate goal is to \nmake the current git-resolve-script be more easily usable, and that \nimplies that it has to work in the current working directory and resolve \nconflicts there. I still think that the _long-term_ plan is to make sure \nthat we don't do that, and the new thing actually supports that too.\n\nFor example, notice how I lifted all the \"checkout\" code from the \ncheckout-cache thing? Including very much the code that supports \n\"--prefix\"? I didn't add the command line, but imagine just adding that, \nwhich updates \"state.base_dir\", and doing\n\n\tmkdir -p MERGE_DIR/.git\n\tcp .git/index MERGE_DIR/.git/index\n\tGIT_INDEX_FILE=MERGE_DIR/.git/index git-read-tree -u --prefix=MERGE_DIR/ \n\nand voila, you're basically now 75% of the way to where I wanted the thing\nto be in a separate directory.\n\nSo I've given up on the separate directory for 1.0 - because it's clearly \nnot going to happen - but I've not given up on the basic idea.\n\n\t\t\tLinus\n"},{"id":"4684","messageId":"7vzmu1ec7w.fsf_-_@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"Pine.LNX.4.58.0506070808180.2286@ppc970.osdl.org","subject":"3-way read-tree case matrix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-08T03:53:07Z","receivedAt":"2005-06-08T03:53:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> I did. It looks fine, although I'd like to point out that even the\nLT> three-way merge _does_ mix in the original state for the case where the\nLT> merge was trivially resolved...\n\nThanks. I have another request for sanity checking.\n\nI am not sure if salvaging a dirty tree in a 3-way merge (as\nopposed to just downright refusing) would have as much practical\nvalue as the 2-tree fast-forward case, but here is a proposed\ncase matrix for the 3-way merge.\n\n\"git-diff-tree -m O H M\"\n\n O H M result index requirements\n------------------------------------------------------------------\n 1 missing missing missing - must not exist.\n -----------------------------------------------------------------\n 2 missing missing exists take M must match M if exists.\n -----------------------------------------------------------------\n 3 missing exists missing remove must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 4 missing exists exists no merge must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 5 exists missing missing no merge must not exist.\n -----------------------------------------------------------------\n 6 exists missing O==M remove must not exist.\n -----------------------------------------------------------------\n 7 exists missing O!=M no merge must not exist.\n -----------------------------------------------------------------\n 8 exists O==H missing remove must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 9 exists O!=H missing no merge must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 10 exists O!=H O!=M no merge must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 11 exists O!=H O==M take H must match H, if exists.\n -----------------------------------------------------------------\n 12 exists O==H O!=M take M if exists, must either (1)\n \t\t\t\t\t match H and be up-to-date,\n or (2) match M.\n -----------------------------------------------------------------\n 13 exists O==H O==M take M must match H if exists.\n------------------------------------------------------------------\n\nIn all \"take H\" or \"take M\" cases, if the original index matches\nwhat is taken, I would reuse it, and keep it dirty if it is.\n\nThe goal is, \"(1) do not clobber the current index; (2) arrive\nat the same result as in the case started with an empty index;\n(3) favor success over failure as long as (1) and (2) are\nsatisfied\".\n\n"},{"id":"4686","messageId":"7v7jh5ct1b.fsf@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"7vzmu1ec7w.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: 3-way read-tree case matrix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-08T05:32:48Z","receivedAt":"2005-06-08T05:32:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I suspect my mailer dropped your response on the floor when it\npolled my ISP at around 21:27 my time. I found its log\nmentioning your address but no message in my mailbox.\n\nSince the last message I sent you, I updated read-tree.c to\nmatch the proposed behaviour, and I found a couple of problems\nwith it by running the 3-way merge test we already have. I am\nattaching a revised one. I have not finished a new test suite\nthat runs on a populated index file yet, which is what I plan to\ndo next.\n\nThere is one thing that the proposed table changes from the\ntraditional 3-way merge semantics. I think this is a sensible\nchange.\n\n - #2 and #3 (I botched #3 in the earlier one I sent you);\n traditionally we left = and\n = cases to the script policy; we\n could salvage a (potentially dirty) cache entry if we say we\n pick the one created in only one branch.\n\nEarlier I botched = case in the table; we\nshould collapse to H/M if H==M; this is now handled differently\nfrom H!=O,M!=O,H!=M case (case #10) as case #11 in the updated\ntable.\n\n------------\n\n\"git-diff-tree -m O H M\"\n\n O H M result index requirements\n------------------------------------------------------------------\n 1 missing missing missing - must not exist.\n -----------------------------------------------------------------\n 2 missing missing exists take M must match M, if exists.\n -----------------------------------------------------------------\n 3 missing exists missing take H must match H, if exists.\n -----------------------------------------------------------------\n 4 missing exists exists no merge must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 5 exists missing missing no merge must not exist.\n -----------------------------------------------------------------\n 6 exists missing O==M remove must not exist.\n -----------------------------------------------------------------\n 7 exists missing O!=M no merge must not exist.\n -----------------------------------------------------------------\n 8 exists O==H missing remove must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 9 exists O!=H missing no merge must match H and be\n\t\t\t\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 10 exists O!=H O!=M no merge must match H and be\n\t\t M!=H\t\t up-to-date, if exists.\n -----------------------------------------------------------------\n 11 exists O!=H O!=M take H\t must match H, if exists.\n\t\t M==H\n -----------------------------------------------------------------\n 12 exists O!=H O==M take H must match H, if exists.\n -----------------------------------------------------------------\n 13 exists O==H O!=M take M if exists, must either (1)\n \t\t\t\t\t match H and be up-to-date,\n or (2) match M.\n -----------------------------------------------------------------\n 14 exists O==H O==M take M must match H if exists.\n------------------------------------------------------------------\n\nIn all \"take H\" or \"take M\" cases, if the original index matches\nwhat is taken, I would reuse it, and keep it dirty if it is.\n\nThe goal is, \"(a) do not clobber the current index; (b) arrive\nat the same result as in the case started with an empty index;\n(c) favor success over failure as long as (a) and (b) are\nsatisfied.\"\n\n"},{"id":"4692","messageId":"7vwtp5b4gp.fsf_-_@assigned-by-dhcp.cox.net","threadId":"842","inReplyTo":"7v7jh5ct1b.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Tests: read-tree -m test updates.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-08T09:08:54Z","receivedAt":"2005-06-08T09:08:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This updates t1000 (basic 3-way merge test) to check the merge\nresults for both successful cases (earlier one checked the\nresult for only one of them). Also fixes typos in t1002 that\nbroke '&&' chain, potentially missing a test failure before the\nchain got broken.\n\nSigned-off-by: Junio C Hamano \n---\n\n t/t1000-read-tree-m-3way.sh | 58 ++++++++++++++++++++---------------------\n t/t1002-read-tree-m-u-2way.sh | 4 +--\n 2 files changed, 30 insertions(+), 32 deletions(-)\n\ndiff --git a/t/t1000-read-tree-m-3way.sh b/t/t1000-read-tree-m-3way.sh\n--- a/t/t1000-read-tree-m-3way.sh\n+++ b/t/t1000-read-tree-m-3way.sh\n@@ -77,34 +77,6 @@ In addition:\n ################################################################\n # Try merging and showing the various diffs\n \n-# The tree is dirty at this point.\n-test_expect_failure \\\n- '3-way merge with git-read-tree -m' \\\n- \"git-read-tree -m $tree_O $tree_A $tree_B\"\n-\n-# This is done on an empty work directory, which is the normal\n-# merge person behaviour.\n-test_expect_success \\\n- '3-way merge with git-read-tree -m' \\\n- \"rm -fr [NDMALTS][NDMALTSF] Z &&\n- rm .git/index &&\n- git-read-tree -m $tree_O $tree_A $tree_B\"\n-\n-# This starts out with the first head, which is the normal\n-# patch submitter behaviour.\n-test_expect_success \\\n- '3-way merge with git-read-tree -m' \\\n- \"git-read-tree $tree_A &&\n- git-checkout-cache -f -u -a &&\n- git-read-tree -m $tree_O $tree_A $tree_B\"\n-\n-_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n-_x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n-test_expect_success \\\n- 'git-ls-files --stage of the merge result' \\\n- 'git-ls-files --stage >current- &&\n- sed -e \"s/ $_x40 / X /\" current'\n-\n cat >expected <<\\EOF\n 100644 X 2\tAA\n 100644 X 3\tAA\n@@ -154,8 +126,34 @@ cat >expected <<\\EOF\n 100644 X 0\tZ/NN\n EOF\n \n+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n+_x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n+\n+# The tree is dirty at this point.\n+test_expect_failure \\\n+ '3-way merge with git-read-tree -m, dirty cache' \\\n+ \"git-read-tree -m $tree_O $tree_A $tree_B\"\n+\n+# This is done on an empty work directory, which is the normal\n+# merge person behaviour.\n+test_expect_success \\\n+ '3-way merge with git-read-tree -m, empty cache' \\\n+ \"rm -fr [NDMALTS][NDMALTSF] Z &&\n+ rm .git/index &&\n+ git-read-tree -m $tree_O $tree_A $tree_B &&\n+ git-ls-files --stage |\n+ sed -e 's/ $_x40 / X /' >current &&\n+ diff -u expected current\"\n+\n+# This starts out with the first head, which is the normal\n+# patch submitter behaviour.\n test_expect_success \\\n- 'validate merge result' \\\n- 'diff current expected'\n+ '3-way merge with git-read-tree -m, match H' \\\n+ \"git-read-tree $tree_A &&\n+ git-checkout-cache -f -u -a &&\n+ git-read-tree -m $tree_O $tree_A $tree_B &&\n+ git-ls-files --stage |\n+ sed -e 's/ $_x40 / X /' >current &&\n+ diff -u expected current\"\n \n test_done\ndiff --git a/t/t1002-read-tree-m-u-2way.sh b/t/t1002-read-tree-m-u-2way.sh\n--- a/t/t1002-read-tree-m-u-2way.sh\n+++ b/t/t1002-read-tree-m-u-2way.sh\n@@ -93,7 +93,7 @@ test_expect_success \\\n compare_change 5diff.out expected &&\n check_cache_at yomin dirty &&\n sha1sum -c M.sha1 &&\n- : dirty index should have prevented -u from checking it out.\n+ : dirty index should have prevented -u from checking it out. &&\n echo yomin yomin >yomin1 &&\n diff yomin yomin1 &&\n rm -f yomin1'\n@@ -122,7 +122,7 @@ test_expect_success \\\n diff --unified=0 M.out 7.out &&\n check_cache_at frotz dirty &&\n if sha1sum -c M.sha1; then false; else :; fi &&\n- : dirty index should have prevented -u from checking it out.\n+ : dirty index should have prevented -u from checking it out. &&\n echo frotz frotz >frotz1 &&\n diff frotz frotz1 &&\n rm -f frotz1'\n------------\n\n"}]}