{"thread":{"id":"8709","subject":"most commonly used git commands?","startedAt":"2007-06-25T06:40:17Z","lastAt":"2007-07-01T16:49:01Z","messageCount":26,"participants":["Michael S. Tsirkin","Junio C Hamano","Johannes Schindelin","Josh Triplett","Martin Langhoff","Alex Riesen","Johannes Sixt","Jan Hudec"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"45737","messageId":"20070625064017.GA2839@mellanox.co.il","threadId":"8709","inReplyTo":null,"subject":"most commonly used git commands?","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-06-25T06:40:17Z","receivedAt":"2007-06-25T06:40:17Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"I did this by mistake:\n\n$git fet linux-2.6\ngit: 'fet' is not a git-command\n\nThe most commonly used git commands are:\n add Add file contents to the changeset to be committed next\n apply Apply a patch on a git index file and a working tree\n(use 'git help -a' to get a list of all installed git commands)\n\nwhy does git say that add and apply are most commonly used git commands?\n\n-- \nMST\n"},{"id":"45740","messageId":"7vlke833wr.fsf@assigned-by-dhcp.pobox.com","threadId":"8709","inReplyTo":"20070625064017.GA2839@mellanox.co.il","subject":"Re: most commonly used git commands?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-25T07:10:44Z","receivedAt":"2007-06-25T07:10:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n> I did this by mistake:\n>\n> $git fet linux-2.6\n> git: 'fet' is not a git-command\n>\n> The most commonly used git commands are:\n> add Add file contents to the changeset to be committed next\n> apply Apply a patch on a git index file and a working tree\n> (use 'git help -a' to get a list of all installed git commands)\n>\n> why does git say that add and apply are most commonly used git commands?\n\nPerhaps they are most commonly used by the person who came up\nwith that list first ;-)?\n\nI think \"add\" deserves to be there, I am not sure \"apply\" is.\n"},{"id":"45741","messageId":"20070625071752.GB15343@mellanox.co.il","threadId":"8709","inReplyTo":"7vlke833wr.fsf@assigned-by-dhcp.pobox.com","subject":"Re: most commonly used git commands?","fromName":"Michael S. Tsirkin","fromEmail":"mst@dev.mellanox.co.il","sentAt":"2007-06-25T07:17:52Z","receivedAt":"2007-06-25T07:17:52Z","isPatch":false,"sender":{"key":"mst@kernel.org","avatar":null},"body":"> Quoting Junio C Hamano :\n> Subject: Re: most commonly used git commands?\n> \n> \"Michael S. Tsirkin\" writes:\n> \n> > I did this by mistake:\n> >\n> > $git fet linux-2.6\n> > git: 'fet' is not a git-command\n> >\n> > The most commonly used git commands are:\n> > add Add file contents to the changeset to be committed next\n> > apply Apply a patch on a git index file and a working tree\n> > (use 'git help -a' to get a list of all installed git commands)\n> >\n> > why does git say that add and apply are most commonly used git commands?\n> \n> Perhaps they are most commonly used by the person who came up\n> with that list first ;-)?\n> \n> I think \"add\" deserves to be there, I am not sure \"apply\" is.\n\ngit add is supposed to be rare, no?\nThat's why git commit lists file additions/removals ...\n\nMy list is typically\ngit checkout\ngit commit\ngit pull\ngit push\ngit rebase\ngit reset\ngit update-index\n\nMaybe it makes sense to take the list from\n\"Main porcelain commands\" section in git manual?\n\n-- \nMST\n"},{"id":"45746","messageId":"7vodj41nm6.fsf@assigned-by-dhcp.pobox.com","threadId":"8709","inReplyTo":"20070625071752.GB15343@mellanox.co.il","subject":"Re: most commonly used git commands?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-25T07:48:01Z","receivedAt":"2007-06-25T07:48:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael S. Tsirkin\" writes:\n\n>> Quoting Junio C Hamano :\n>> Perhaps they are most commonly used by the person who came up\n>> with that list first ;-)?\n>> \n>> I think \"add\" deserves to be there, I am not sure \"apply\" is.\n>\n> git add is supposed to be rare, no?\n> That's why git commit lists file additions/removals ...\n\nNo. You are talking in terms of pre-1.5 git. The semantics of\n\"git add\" has been clarified since then --- it adds contents,\nand is not about telling git that there are new files it did not\nknow so far.\n"},{"id":"45749","messageId":"Pine.LNX.4.64.0706250846200.4059@racer.site","threadId":"8709","inReplyTo":"20070625071752.GB15343@mellanox.co.il","subject":"Re: most commonly used git commands?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-25T07:51:15Z","receivedAt":"2007-06-25T07:51:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 25 Jun 2007, Michael S. Tsirkin wrote:\n\n> Quoting Junio C Hamano :\n>\n> > I think \"add\" deserves to be there, I am not sure \"apply\" is.\n> \n> git add is supposed to be rare, no?\n\nNo.\n\n> That's why git commit lists file additions/removals ...\n> \n> My list is typically\n> git checkout\n> git commit\n> git pull\n> git push\n> git rebase\n> git reset\n> git update-index\n\ngit update-index is really not user-friendly. That is why we have \"git \nadd\". It is commonly used as a porcelain _instead of_ update-index.\n\nFWIW your list is lacking log and diff, the two commands which are my top \ntwo. I do not use rebase all that often (before --interactive, that is). \nstatus, grep, mv, gc, show and branch are others I use quite often \n(although not as much as log and diff)\n\nCiao,\nDscho\n"},{"id":"45943","messageId":"468310D4.2070504@freedesktop.org","threadId":"8709","inReplyTo":"20070625064017.GA2839@mellanox.co.il","subject":"Re: most commonly used git commands?","fromName":"Josh Triplett","fromEmail":"josh@freedesktop.org","sentAt":"2007-06-28T01:37:24Z","receivedAt":"2007-06-28T01:37:24Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"Michael S. Tsirkin wrote:\n> I did this by mistake:\n> \n> $git fet linux-2.6\n> git: 'fet' is not a git-command\n> \n> The most commonly used git commands are:\n> add Add file contents to the changeset to be committed next\n> apply Apply a patch on a git index file and a working tree\n> (use 'git help -a' to get a list of all installed git commands)\n\nIt should have listed more than just those two...\n\n- Josh Triplett\n"},{"id":"45944","messageId":"46a038f90706271917j7abb4bddu21debafe3461c695@mail.gmail.com","threadId":"8709","inReplyTo":"7vodj41nm6.fsf@assigned-by-dhcp.pobox.com","subject":"Re: most commonly used git commands?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-06-28T02:17:32Z","receivedAt":"2007-06-28T02:17:32Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/25/07, Junio C Hamano wrote:\n> \"Michael S. Tsirkin\" writes:\n>\n> >> Quoting Junio C Hamano :\n> >> Perhaps they are most commonly used by the person who came up\n> >> with that list first ;-)?\n> >>\n> >> I think \"add\" deserves to be there, I am not sure \"apply\" is.\n> >\n> > git add is supposed to be rare, no?\n> > That's why git commit lists file additions/removals ...\n>\n> No. You are talking in terms of pre-1.5 git. The semantics of\n> \"git add\" has been clarified since then --- it adds contents,\n> and is not about telling git that there are new files it did not\n> know so far.\n\nIn other words - git-add is also a (semantically good) alias for\ngit-update-index.\n\nSo you \"add\" files to the next commit. Whether they are \"new\" to git\nor just changed it doesn't matter that much in that situation. And\ngit-commit will look at those files that have been \"added\".\n\nMakes things a whole lot easier to explain. I didn't understand it\ninitially, now I'm completely sold on the concept.\n\n\nm\n"},{"id":"45945","messageId":"46831D32.4090900@freedesktop.org","threadId":"8709","inReplyTo":"46a038f90706271917j7abb4bddu21debafe3461c695@mail.gmail.com","subject":"Re: most commonly used git commands?","fromName":"Josh Triplett","fromEmail":"josh@freedesktop.org","sentAt":"2007-06-28T02:30:10Z","receivedAt":"2007-06-28T02:30:10Z","isPatch":false,"sender":{"key":"josh@joshtriplett.org","avatar":"https://avatars.githubusercontent.com/u/162737?v=4"},"body":"Martin Langhoff wrote:\n> On 6/25/07, Junio C Hamano wrote:\n>> \"Michael S. Tsirkin\" writes:\n>>>> Quoting Junio C Hamano :\n>>>> Perhaps they are most commonly used by the person who came up\n>>>> with that list first ;-)?\n>>>>\n>>>> I think \"add\" deserves to be there, I am not sure \"apply\" is.\n>>> git add is supposed to be rare, no?\n>>> That's why git commit lists file additions/removals ...\n>> No. You are talking in terms of pre-1.5 git. The semantics of\n>> \"git add\" has been clarified since then --- it adds contents,\n>> and is not about telling git that there are new files it did not\n>> know so far.\n> \n> In other words - git-add is also a (semantically good) alias for\n> git-update-index.\n> \n> So you \"add\" files to the next commit. Whether they are \"new\" to git\n> or just changed it doesn't matter that much in that situation. And\n> git-commit will look at those files that have been \"added\".\n> \n> Makes things a whole lot easier to explain. I didn't understand it\n> initially, now I'm completely sold on the concept.\n\nAgreed; this change converted me from a \"git commit -a\" user to a big fan of\nthe index.\n\n- Josh Triplett\n\n"},{"id":"45961","messageId":"81b0412b0706280152g5cbd777y76757d9c608ea483@mail.gmail.com","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706250846200.4059@racer.site","subject":"Re: most commonly used git commands?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-28T08:52:49Z","receivedAt":"2007-06-28T08:52:49Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 6/25/07, Johannes Schindelin wrote:\n> git update-index is really not user-friendly. That is why we have \"git\n> add\". It is commonly used as a porcelain _instead of_ update-index.\n\nwhich reminds me: \"git-add\" lacks \"--chmod=[+-]x\".\n"},{"id":"45978","messageId":"Pine.LNX.4.64.0706281408280.4438@racer.site","threadId":"8709","inReplyTo":"81b0412b0706280152g5cbd777y76757d9c608ea483@mail.gmail.com","subject":"Re: most commonly used git commands?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-28T13:08:57Z","receivedAt":"2007-06-28T13:08:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 28 Jun 2007, Alex Riesen wrote:\n\n> On 6/25/07, Johannes Schindelin wrote:\n> > git update-index is really not user-friendly. That is why we have \"git\n> > add\". It is commonly used as a porcelain _instead of_ update-index.\n> \n> which reminds me: \"git-add\" lacks \"--chmod=[+-]x\".\n\n???\n\nDo you mean \"chmod a+x blub && git add blub\"?\n\nCiao,\nDscho\n"},{"id":"45983","messageId":"4683BDA5.996874EF@eudaptics.com","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706281408280.4438@racer.site","subject":"Re: most commonly used git commands?","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-28T13:54:45Z","receivedAt":"2007-06-28T13:54:45Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin wrote:\n> On Thu, 28 Jun 2007, Alex Riesen wrote:\n> > On 6/25/07, Johannes Schindelin wrote:\n> > > git update-index is really not user-friendly. That is why we have \"git\n> > > add\". It is commonly used as a porcelain _instead of_ update-index.\n> >\n> > which reminds me: \"git-add\" lacks \"--chmod=[+-]x\".\n> \n> ???\n> \n> Do you mean \"chmod a+x blub && git add blub\"?\n\nNo. It was meant as Alex said it. Windows (MinGW) doesn't understand\n\"chmod a+x blub\".\n\n-- Hannes\n"},{"id":"45979","messageId":"Pine.LNX.4.64.0706281506390.4438@racer.site","threadId":"8709","inReplyTo":"4683BDA5.996874EF@eudaptics.com","subject":"Re: most commonly used git commands?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-28T14:07:17Z","receivedAt":"2007-06-28T14:07:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\n\nOn Thu, 28 Jun 2007, Johannes Sixt wrote:\n\n> Johannes Schindelin wrote:\n> > On Thu, 28 Jun 2007, Alex Riesen wrote:\n> > > On 6/25/07, Johannes Schindelin wrote:\n> > > > git update-index is really not user-friendly. That is why we have \"git\n> > > > add\". It is commonly used as a porcelain _instead of_ update-index.\n> > >\n> > > which reminds me: \"git-add\" lacks \"--chmod=[+-]x\".\n> > \n> > ???\n> > \n> > Do you mean \"chmod a+x blub && git add blub\"?\n> \n> No. It was meant as Alex said it. Windows (MinGW) doesn't understand\n> \"chmod a+x blub\".\n\nYes, I suspected that. But I don't see a need for it on Windows (MinGW) to \nbegin with.\n\nCiao,\nDscho\n"},{"id":"45982","messageId":"4683C5D2.FDF4ED02@eudaptics.com","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706281506390.4438@racer.site","subject":"Re: most commonly used git commands?","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-28T14:29:38Z","receivedAt":"2007-06-28T14:29:38Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin wrote:\n> \n> On Thu, 28 Jun 2007, Johannes Sixt wrote:\n> > No. It was meant as Alex said it. Windows (MinGW) doesn't understand\n> > \"chmod a+x blub\".\n> \n> Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to\n> begin with.\n\nTrue for Windows-centered projects. But for cross-platform projects\n--chmod=+x is needed every now and then.\n\nAFAIAC, it's alright to fall back to update-index for those occasions,\neven though they are not that rare due to a deficiency of\nmerge-recursive: When it merges an executable file, it loses the +x bit,\neven if core.filemode=false!\n\n-- Hannes\n"},{"id":"45985","messageId":"4683CA7A.7F8070D7@eudaptics.com","threadId":"8709","inReplyTo":"4683C5D2.FDF4ED02@eudaptics.com","subject":"Re: most commonly used git commands?","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-28T14:49:30Z","receivedAt":"2007-06-28T14:49:30Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Sixt wrote:\n> AFAIAC, it's alright to fall back to update-index for those occasions,\n> even though they are not that rare due to a deficiency of\n> merge-recursive: When it merges an executable file, it loses the +x bit,\n> even if core.filemode=false!\n\nI take that back.\n\nThe deficiency is not in merge-recursive, but in 'git add'. The problem\nis that after a conflicted merge of an executable file 'git add' loses\nthe +x bit even if core.filemode=false.\n\n-- Hannes\n"},{"id":"45992","messageId":"Pine.LNX.4.64.0706281653260.4438@racer.site","threadId":"8709","inReplyTo":"4683CA7A.7F8070D7@eudaptics.com","subject":"[PATCH] git add: respect core.filemode even with unmerged entries in the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-28T17:02:21Z","receivedAt":"2007-06-28T17:02:21Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen a merge left unmerged entries, git add failed to pick up the\nfile mode from the index, when core.filemode == 0.\n\nNoticed by Johannes Sixt.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Thu, 28 Jun 2007, Johannes Sixt wrote:\n\n\t> Johannes Sixt wrote:\n\t> \n\t> The deficiency is not in merge-recursive, but in 'git add'. The \n\t> problem is that after a conflicted merge of an executable file \n\t> 'git add' loses the +x bit even if core.filemode=false.\n\n\tHow's that?\n\n read-cache.c | 6 ++++++\n t/t3700-add.sh | 14 ++++++++++++++\n 2 files changed, 20 insertions(+), 0 deletions(-)\n\ndiff --git a/read-cache.c b/read-cache.c\nindex 4362b11..a74e4a7 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -382,6 +382,12 @@ int add_file_to_index(struct index_state *istate, const char *path, int verbose)\n \t\tstruct cache_entry *ent;\n \t\tint pos = index_name_pos(istate, path, namelen);\n \n+\t\t/* might be unmerged */\n+\t\tif (pos < 0 && 1-pos < istate->cache_nr &&\n+\t\t\t\tnamelen == ce_namelen(istate->cache[1-pos]) &&\n+\t\t\t\t!memcmp(path, istate->cache[1-pos]->name,\n+\t\t\t\t\tnamelen))\n+\t\t\tpos = 1-pos;\n \t\tent = (0 <= pos) ? istate->cache[pos] : NULL;\n \t\tce->ce_mode = ce_mode_from_stat(ent, st.st_mode);\n \t}\ndiff --git a/t/t3700-add.sh b/t/t3700-add.sh\nindex ad8cc7d..d75970b 100755\n--- a/t/t3700-add.sh\n+++ b/t/t3700-add.sh\n@@ -110,4 +110,18 @@ test_expect_success 'check correct prefix detection' '\n \tgit add 1/2/a 1/3/b 1/2/c\n '\n \n+test_expect_success 'git add and filemode=0 with unmerged entries' '\n+\techo 1 > stage1 &&\n+\techo 2 > stage2 &&\n+\techo 3 > stage3 &&\n+\tfor s in 1 2 3\n+\tdo\n+\t\techo \"100755 $(git hash-object -w stage$s) $s\tfile\"\n+\tdone | git update-index --index-info &&\n+\tgit config core.filemode 0 &&\n+\techo new > file &&\n+\tgit add file &&\n+\tgit ls-files --stage | grep \"^100755 .* 0\tfile$\"\n+'\n+\n test_done\n-- \n1.5.2.2.3228.g16a27\n"},{"id":"46029","messageId":"4684AD41.9868C32F@eudaptics.com","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706281653260.4438@racer.site","subject":"Re: [PATCH] git add: respect core.filemode even with unmerged entriesin the index","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-29T06:57:05Z","receivedAt":"2007-06-29T06:57:05Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Johannes Schindelin wrote:\n> \n> When a merge left unmerged entries, git add failed to pick up the\n> file mode from the index, when core.filemode == 0.\n> \n> Noticed by Johannes Sixt.\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n> \n> On Thu, 28 Jun 2007, Johannes Sixt wrote:\n> \n> > Johannes Sixt wrote:\n> >\n> > The deficiency is not in merge-recursive, but in 'git add'. The\n> > problem is that after a conflicted merge of an executable file\n> > 'git add' loses the +x bit even if core.filemode=false.\n> \n> How's that?\n\nThat's fine, thanks.\n\nIt covers the most common case that all three stages are in the index.\nHowever, if only two stages are present, the file mode is still taken\nfrom the file instead of from the index. As that easy to solve (at least\nfor the unambiguous case)?\n\n-- Hannes\n"},{"id":"46036","messageId":"7vir97f98o.fsf@assigned-by-dhcp.pobox.com","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706281653260.4438@racer.site","subject":"Re: [PATCH] git add: respect core.filemode even with unmerged entries in the index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-29T08:36:07Z","receivedAt":"2007-06-29T08:36:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> diff --git a/read-cache.c b/read-cache.c\n> index 4362b11..a74e4a7 100644\n> --- a/read-cache.c\n> +++ b/read-cache.c\n> @@ -382,6 +382,12 @@ int add_file_to_index(struct index_state *istate, const char *path, int verbose)\n> \t\tstruct cache_entry *ent;\n> \t\tint pos = index_name_pos(istate, path, namelen);\n> \n> +\t\t/* might be unmerged */\n> +\t\tif (pos < 0 && 1-pos < istate->cache_nr &&\n> +\t\t\t\tnamelen == ce_namelen(istate->cache[1-pos]) &&\n> +\t\t\t\t!memcmp(path, istate->cache[1-pos]->name,\n> +\t\t\t\t\tnamelen))\n> +\t\t\tpos = 1-pos;\n> \t\tent = (0 <= pos) ? istate->cache[pos] : NULL;\n> \t\tce->ce_mode = ce_mode_from_stat(ent, st.st_mode);\n> \t}\n\nHmph.\n\n * Are you sure about (1-pos)?\n\n * I _think_ we would want to favor our stage (i.e. #2) when\n unmerged, over other stages. Perhaps like this:\n\n\tif (pos < 0) {\n \tint a_pos = -1, our_pos = -1;\n\t\tpos = -pos-1;\n\t\twhile ((pos < istate->cache_nr) &&\n\t\t\tnamelen == ce_namelen(istate->cache[pos]) &&\n\t\t\t!memcmp(path, istate->cache[pos]->name, namelen))\n\t\t\tif (a_pos < 0)\n \ta_pos = pos;\n if (ce_stage(istate->cache[pos]) == 2)\n \tour_pos = pos;\n\t\t\tpos++;\n }\n\t\tif (our_pos >= 0)\n \tpos = our_pos;\n\t\telse if (a_pos >= 0)\n \tpos = a_pos;\n\t\telse\n \tpos = -1;\n\t}\n\tent = (0 <= pos) ? istate->cache[pos] : NULL;\n\tce->ce_mode = ce_mode_from_stat(ent, st.st_mode);\n"},{"id":"46040","messageId":"Pine.LNX.4.64.0706291103470.4438@racer.site","threadId":"8709","inReplyTo":"7vir97f98o.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH] git add: respect core.filemode even with unmerged entries in the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-29T10:06:11Z","receivedAt":"2007-06-29T10:06:11Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 29 Jun 2007, Junio C Hamano wrote:\n\n> Hmph.\n> \n> * Are you sure about (1-pos)?\n> \n> * I _think_ we would want to favor our stage (i.e. #2)\n\nHmph back.\n\nI _thought_ that our stage is #1, not even bothering to check the \ndocumentation. But it seems that you are right.\n\nSo your code looks fine to me, except that I would move the whole \nget_index_entry_for_file_even_if_the_entry_is_unmerged(name, namelen) \ncode into its own function.\n\nWant me to prepare a patch? If so, I'll do it tonight, since I will be \noccupied the rest of the (working) day.\n\nCiao,\nDscho\n"},{"id":"46041","messageId":"Pine.LNX.4.64.0706291106190.4438@racer.site","threadId":"8709","inReplyTo":"4684AD41.9868C32F@eudaptics.com","subject":"Re: [PATCH] git add: respect core.filemode even with unmerged entriesin the index","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-29T10:07:00Z","receivedAt":"2007-06-29T10:07:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 29 Jun 2007, Johannes Sixt wrote:\n\n> However, if only two stages are present, the file mode is still taken \n> from the file instead of from the index. As that easy to solve (at least \n> for the unambiguous case)?\n\nIt might be related to the bug Junio found, i.e. that I assumed stage 1 to \nbe \"ours\".\n\nCiao,\nDscho\n"},{"id":"46042","messageId":"7v3b0bf4ea.fsf@assigned-by-dhcp.pobox.com","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706291106190.4438@racer.site","subject":"Re: [PATCH] git add: respect core.filemode even with unmerged entriesin the index","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-29T10:20:45Z","receivedAt":"2007-06-29T10:20:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 29 Jun 2007, Johannes Sixt wrote:\n>\n>> However, if only two stages are present, the file mode is still taken \n>> from the file instead of from the index. As that easy to solve (at least \n>> for the unambiguous case)?\n>\n> It might be related to the bug Junio found, i.e. that I assumed stage 1 to \n> be \"ours\".\n\nActually it is because (-1-pos) and (1-pos) are two apart. By\nstarting to scan from (1-pos), you are jumping directly to\neither the next path (in which case you do not pick it up), or\n\"their\" version (i.e. stage #3) iff there are three stages for\nthe path in question.\n\nI am all for refactoring the funny \"pick up an existing entry at\nany stage, but favor 0 then 2 then 1 and finally 3\" into a\nseparate function. It makes sense, although I do not offhand\nknow of a place that we can immediately reuse it (logically,\ndiff-files ought to do that, but I haven't checked).\n"},{"id":"46054","messageId":"Pine.LNX.4.64.0706291820200.4438@racer.site","threadId":"8709","inReplyTo":"7v3b0bf4ea.fsf@assigned-by-dhcp.pobox.com","subject":"[PATCH] git add: respect core.filemode with unmerged entries","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-29T17:32:46Z","receivedAt":"2007-06-29T17:32:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWhen a merge left unmerged entries, git add failed to pick up the\nfile mode from the index, when core.filemode == 0. If more than one\nunmerged entry is there, the order of stage preference is 2, 1, 3.\n\nNoticed by Johannes Sixt.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Fri, 29 Jun 2007, Junio C Hamano wrote:\n\n\t> Johannes Schindelin writes:\n\t> \n\t> > On Fri, 29 Jun 2007, Johannes Sixt wrote:\n\t> >\n\t> >> However, if only two stages are present, the file mode is \n\t> >> still taken from the file instead of from the index. As that \n\t> >> easy to solve (at least for the unambiguous case)?\n\t> >\n\t> > It might be related to the bug Junio found, i.e. that I assumed stage 1 to \n\t> > be \"ours\".\n\t> \n\t> Actually it is because (-1-pos) and (1-pos) are two apart.\n\n\tI congratulate myself. My first off-by-two bug.\n\n\t> I am all for refactoring the funny \"pick up an existing entry at\n\t> any stage, but favor 0 then 2 then 1 and finally 3\" into a\n\t> separate function. It makes sense, although I do not offhand\n\t> know of a place that we can immediately reuse it (logically,\n\t> diff-files ought to do that, but I haven't checked).\n\n\tMe neither. But at least I coded it (hopefully) correctly this \n\ttime, even accompied it by a test verifying that I got it right.\n\n read-cache.c | 30 +++++++++++++++++++++++++++++-\n t/t3700-add.sh | 26 ++++++++++++++++++++++++++\n 2 files changed, 55 insertions(+), 1 deletions(-)\n\ndiff --git a/read-cache.c b/read-cache.c\nindex 4362b11..a363f31 100644\n--- a/read-cache.c\n+++ b/read-cache.c\n@@ -350,6 +350,34 @@ int remove_file_from_index(struct index_state *istate, const char *path)\n \treturn 0;\n }\n \n+static int compare_name(struct cache_entry *ce, const char *path, int namelen)\n+{\n+\treturn namelen != ce_namelen(ce) || memcmp(path, ce->name, namelen);\n+}\n+\n+static int index_name_pos_also_unmerged(struct index_state *istate,\n+\tconst char *path, int namelen)\n+{\n+\tint pos = index_name_pos(istate, path, namelen);\n+\tstruct cache_entry *ce;\n+\n+\tif (pos >= 0)\n+\t\treturn pos;\n+\n+\t/* maybe unmerged? */\n+\tpos = -1 - pos;\n+\tif (pos >= istate->cache_nr ||\n+\t\t\tcompare_name((ce = istate->cache[pos]), path, namelen))\n+\t\treturn -1;\n+\n+\t/* order of preference: stage 2, 1, 3 */\n+\tif (ce_stage(ce) == 1 && pos + 1 < istate->cache_nr &&\n+\t\t\tce_stage((ce = istate->cache[pos + 1])) == 2 &&\n+\t\t\t!compare_name(ce, path, namelen))\n+\t\tpos++;\n+\treturn pos;\n+}\n+\n int add_file_to_index(struct index_state *istate, const char *path, int verbose)\n {\n \tint size, namelen;\n@@ -380,7 +408,7 @@ int add_file_to_index(struct index_state *istate, const char *path, int verbose)\n \t\t * from it, otherwise assume unexecutable regular file.\n \t\t */\n \t\tstruct cache_entry *ent;\n-\t\tint pos = index_name_pos(istate, path, namelen);\n+\t\tint pos = index_name_pos_also_unmerged(istate, path, namelen);\n \n \t\tent = (0 <= pos) ? istate->cache[pos] : NULL;\n \t\tce->ce_mode = ce_mode_from_stat(ent, st.st_mode);\ndiff --git a/t/t3700-add.sh b/t/t3700-add.sh\nindex ad8cc7d..0d80c6a 100755\n--- a/t/t3700-add.sh\n+++ b/t/t3700-add.sh\n@@ -110,4 +110,30 @@ test_expect_success 'check correct prefix detection' '\n \tgit add 1/2/a 1/3/b 1/2/c\n '\n \n+test_expect_success 'git add and filemode=0 with unmerged entries' '\n+\techo 1 > stage1 &&\n+\techo 2 > stage2 &&\n+\techo 3 > stage3 &&\n+\tfor s in 1 2 3\n+\tdo\n+\t\techo \"100755 $(git hash-object -w stage$s) $s\tfile\"\n+\tdone | git update-index --index-info &&\n+\tgit config core.filemode 0 &&\n+\techo new > file &&\n+\tgit add file &&\n+\tgit ls-files --stage | grep \"^100755 .* 0\tfile$\"\n+'\n+\n+test_expect_success 'git add and filemode=0 prefers stage 2 over stage 1' '\n+\tgit rm --cached -f file &&\n+\t(\n+\t\techo \"100644 $(git hash-object -w stage1) 1\tfile\"\n+\t\techo \"100755 $(git hash-object -w stage2) 2\tfile\"\n+\t) | git update-index --index-info &&\n+\tgit config core.filemode 0 &&\n+\techo new > file &&\n+\tgit add file &&\n+\tgit ls-files --stage | grep \"^100755 .* 0\tfile$\"\n+'\n+\n test_done\n-- \n1.5.2.2.3228.g16a27\n"},{"id":"46086","messageId":"20070630131428.GA2866@steel.home","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706281506390.4438@racer.site","subject":"Re: most commonly used git commands?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-30T13:14:28Z","receivedAt":"2007-06-30T13:14:28Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:\n> > No. It was meant as Alex said it. Windows (MinGW) doesn't understand\n> > \"chmod a+x blub\".\n> \n> Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to \n> begin with.\n> \n\nBut it is necessary on Windows (Cygwin): chmod(2) with mode set to\n0644 will happily take execute permission from an .com, .bat, .cmd,\n.pl, .exe or .dll file. Which means something different on Windows,\nbut results in unexpectedly (for a Windows user) looking errors. The\nusers there do not expect seeing an .exe-file but be not able to\nrun it.\n"},{"id":"46091","messageId":"Pine.LNX.4.64.0706301531050.4438@racer.site","threadId":"8709","inReplyTo":"20070630131428.GA2866@steel.home","subject":"Re: most commonly used git commands?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-30T14:31:48Z","receivedAt":"2007-06-30T14:31:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 30 Jun 2007, Alex Riesen wrote:\n\n> Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:\n> > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand\n> > > \"chmod a+x blub\".\n> > \n> > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to \n> > begin with.\n> > \n> \n> But it is necessary on Windows (Cygwin):\n\nI thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems \nwith chmod under my fingers.\n\nCiao,\nDscho\n"},{"id":"46132","messageId":"20070630223504.GB2703@steel.home","threadId":"8709","inReplyTo":"Pine.LNX.4.64.0706301531050.4438@racer.site","subject":"Re: most commonly used git commands?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-06-30T22:35:04Z","receivedAt":"2007-06-30T22:35:04Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Sat, Jun 30, 2007 16:31:48 +0200:\n> On Sat, 30 Jun 2007, Alex Riesen wrote:\n> > Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:\n> > > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand\n> > > > \"chmod a+x blub\".\n> > > \n> > > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to \n> > > begin with.\n> > > \n> > \n> > But it is necessary on Windows (Cygwin):\n> \n> I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems \n> with chmod under my fingers.\n> \n\nTry doing stat(2) on file.txt which contains \"#!/bin/sh\" in its first\nline and for which you have issued a chmod yet. Like a new file, or\nlike every file in a git-tracked directory after you did a fresh\ncheckout. Cygwin actually opens the files when doing stat(2), looks\ninside and tries to guess if they are executable.\n\nYou should have said: \"Cygwin _never_ had problems with chmod because\nit cannot and didn't make it work\". It is not just chmod, the other\nside, stat, matters as well.\n"},{"id":"46160","messageId":"20070701091645.GA26243@efreet.light.src","threadId":"8709","inReplyTo":"20070630223504.GB2703@steel.home","subject":"Re: most commonly used git commands?","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-07-01T09:16:46Z","receivedAt":"2007-07-01T09:16:46Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sun, Jul 01, 2007 at 00:35:04 +0200, Alex Riesen wrote:\n> Johannes Schindelin, Sat, Jun 30, 2007 16:31:48 +0200:\n> > On Sat, 30 Jun 2007, Alex Riesen wrote:\n> > > Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:\n> > > > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand\n> > > > > \"chmod a+x blub\".\n> > > > \n> > > > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to \n> > > > begin with.\n> > > > \n> > > \n> > > But it is necessary on Windows (Cygwin):\n> > \n> > I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems \n> > with chmod under my fingers.\n> > \n> \n> Try doing stat(2) on file.txt which contains \"#!/bin/sh\" in its first\n> line and for which you have issued a chmod yet. Like a new file, or\n> like every file in a git-tracked directory after you did a fresh\n> checkout. Cygwin actually opens the files when doing stat(2), looks\n> inside and tries to guess if they are executable.\n> \n> You should have said: \"Cygwin _never_ had problems with chmod because\n> it cannot and didn't make it work\". It is not just chmod, the other\n> side, stat, matters as well.\n\nI always had the impression, that cygwin actually *implements* chmod and does\nso using windows ACLs. And in ACL windows *do* support executable bit (I\ncopied some DLL with cygwin copy and it was NOT executable then). Of course\nthis only works on filesystems (NTFS, NTFS exported over CIFS) that support\nACLs. On FAT it might be doing something like you describe. Though it is\nmostly irrelevant for git, because git does not work on FAT (Cygwin only\nsupports posix rename on NTFS).\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"46182","messageId":"20070701164901.GB3661@steel.home","threadId":"8709","inReplyTo":"20070701091645.GA26243@efreet.light.src","subject":"Re: most commonly used git commands?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-07-01T16:49:01Z","receivedAt":"2007-07-01T16:49:01Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Jan Hudec, Sun, Jul 01, 2007 11:16:46 +0200:\n> On Sun, Jul 01, 2007 at 00:35:04 +0200, Alex Riesen wrote:\n> > Johannes Schindelin, Sat, Jun 30, 2007 16:31:48 +0200:\n> > > On Sat, 30 Jun 2007, Alex Riesen wrote:\n> > > > Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:\n> > > > > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand\n> > > > > > \"chmod a+x blub\".\n> > > > > \n> > > > > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to \n> > > > > begin with.\n> > > > > \n> > > > \n> > > > But it is necessary on Windows (Cygwin):\n> > > \n> > > I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems \n> > > with chmod under my fingers.\n> > > \n> > \n> > Try doing stat(2) on file.txt which contains \"#!/bin/sh\" in its first\n> > line and for which you have issued a chmod yet. Like a new file, or\n> > like every file in a git-tracked directory after you did a fresh\n> > checkout. Cygwin actually opens the files when doing stat(2), looks\n> > inside and tries to guess if they are executable.\n> > \n> > You should have said: \"Cygwin _never_ had problems with chmod because\n> > it cannot and didn't make it work\". It is not just chmod, the other\n> > side, stat, matters as well.\n> \n> I always had the impression, that cygwin actually *implements* chmod and does\n> so using windows ACLs. And in ACL windows *do* support executable bit (I\n\nWindows ACLs don't have exec bit in the UNIX sense.\n\n> copied some DLL with cygwin copy and it was NOT executable then). Of course\n> this only works on filesystems (NTFS, NTFS exported over CIFS) that support\n> ACLs. On FAT it might be doing something like you describe. Though it is\n> mostly irrelevant for git, because git does not work on FAT (Cygwin only\n> supports posix rename on NTFS).\n\nIt does not work on NTFS either. For all the same reason I described\nabove: Cygwin tries to be clever (and annoying) and looks into files.\nAnd no Windows program (like, for example, your editor of preference)\nwill call Cygwin's chmod just to set the permissions how Cygwin likes\nthem.\n"}]}