Re: Tool renames? was Re: First stab at glossary
I said: I'll draw up a strawman tonight unless somebody else does it first. 1. Say 'index' when you are tempted to say 'cache'. git-checkout-cache git-checkout-index git-convert-cache git-convert-index git-diff-cache git-diff-index git-fsck-cache git-fsck-index git-merge-cache git-merge-index git-update-cachegit-update-index 2. The act of combining two or more heads is called 'merging'; fetching immediately followed by merging is called 'pulling'. git-resolve-script git-merge-script The commit walkers are called *-pull, but this is probably confusing. They are not pulling. git-http-pull git-http-walk git-local-pull git-local-walk git-ssh-pullgit-ssh-walk 3. Non-binaries are called '*-scripts'. In earlier discussions some people seem to like the distinction between *-script and others; I did not particularly like it, but I am throwing this in for discussion. git-applymbox git-applymbox-script git-applypatch git-applypatch-script git-cherry git-cherry-script git-shortloggit-shortlog-script git-whatchanged git-whatchanged-script 4. To be removed shortly. git-clone-dumb-http should be folded into git-clone-script - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PROBLEM] Checkout from cloned repository does not work
Hi Junio, On Fri, 2005-09-02 at 11:13 -0700, Junio C Hamano wrote: You would need 'chmod +x git-test.git/hooks/post-update' here if you are allowing people to pull over http from this repository. Aah, thanks! That fixed it for me. On Fri, 2005-09-02 at 11:13 -0700, Junio C Hamano wrote: The problem is that 'git clone' does not support cloning over http from servers that are not properly prepared. This 'git clone' exited with non-zero status with an error message, didn't it? I double checked that -- no, it does not print out an error. I copied the exact output in the original mail. On Fri, 2005-09-02 at 11:13 -0700, Junio C Hamano wrote: +[NOTE] +If you plan to publish this repository to be accessed over http, +you should do `chmod +x my-git.git/hooks/post-update` at this +point. How about must do chmod before pushing anything to this repository? I think I tried chmod at some point but always did it too late (i.e. after the initial push). Pekka - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
This is a simplified scenario of klibc vs klibc-kbuild HPA had trouble with, to help us think of a way to solve this interesting merge problem. #1 - #3 - #5 - #7 // / #0 - #2 - #4 - #6 There are two lines of developments. #0-#2 renames F to G and introduces K. #0-#1 keeps F as F and does not introduce K. At commit #3, #2 is merged into #1. The changes made to the file contents of F between #0 and #2 are appreciated, but the renaming of F to G and introduction of K were not. So commit #3 has the resulting merge contents in F and does not have file K. This _might_ be different from what we traditionally consider a 'merge', but from the use case point of view it is a valid thing one would want to do. Commit #4 is a continued development from #2; changes are made to G, and K has further changes. Commit #5 similarly is a continued development from #3; its changes are in F and K does not exist. We are about to merge #6 into #5 to create #7. We should be able to take advantage of what the user did when the merge #3 was made; namely, we should be able to infer that the line of development that flows #0 .. #3 .. #7 prefers to keep F as F, and does not want the newly introduced K. We should be able to tell it by looking at what the merge #3 did. Now, how can we use git to figure that out? First, given our current head (#5) and the other head we are about to merge (#6), we need a way to tell if we merged from them before (i.e. the existence of #3) and if so the latest of such merge (i.e. #3). The merge base between #5 and #6 is #2. We can look at commits between us (#5) and the merge base (#2), find a merge (#3), which has two parents. One of the parents is #2 which is reachable from #6, and the other is #1 which is not reachable from #6 but is reachable from #5. Can we say that this reliably tells us that #2 is on their side and #1 is on our side? Does the fact that #3 is the commit topologically closest to #5 tell us that #3 is the one we want to look deeper? This is still handwaving, but assuming the answers to these questions are yes, we have found that the 'previous' merge is #3, that #1 is its parent on our side, and that #2 is its parent on their side. Then we can ask 'diff-tree -M #2 #3' to see what `tree structure` changes we do _not_ want from their line of development, while slurping the contents changes from them. When making the tree to put at #7, just like I outlined to my previous message to HPA, we can first create a tree that is a derivative of #6 with only the structural changes detected between #2 and #3 (which are 'rename from G to F' and 'removal of K') applied. Similarly, we make another derivative, this time of #2, with only the structural changes to adjust it to 'our' tree (again, 'rename from G to F' and 'removal of K'). Then we can run 3-way git-read-tree like this: git-read-tree -m -u '#2-adjusted' '#5' '#6-adjusted' The last part, using the structurally adjusted tree as the merge-base tree, is what I forgot to do in the previous message to HPA. Hmm. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
On Sat, Sep 03, 2005 at 01:25:50AM -0700, Junio C Hamano wrote: Junio C Hamano [EMAIL PROTECTED] writes: H. Peter Anvin [EMAIL PROTECTED] writes: I currently have two klibc trees, I cloned them to take a look. You_do_ seem to have a lot of renames. Well, I think I understand how your trees ancestry looks like, but still haven't come up with a good problem definition. I am sorry that this message is not a solution for your problem but would end up to be just my rambling and thinking aloud. The ancestry looks like this: #4-#5---#7 #0: 1.0.14 released, next version is 1.0.15 / / 5691e96ebfccd21a1f75d3518dd55a96b311d1aa /---#1-#3---#6 #1: Explain why execvpe/execlpe work the way they do. // /1d774a8cbd8e8b90759491591987cb509122bd78 #0-#2 #2: 1.1 released, next version is 1.1.1 3a41b60f6730077db3f04cf2874c96a0e53da453 #3: Merge of #2 into #1 7ab38d71de2964129cf1d5bc4e071d103e807a0d #4: socketcalls aren't always *.S files; they can... f52be163e684fc3840e557ecf242270926136b67 #5: Merge of #3 into #4 2e2a79d62a96b6b0d4bc93697fe77cd3030cdfd9 #6: Warnings cleanup f5260f8737517f19a03ee906cd64dfc9930221cd #7: Remove obsoleted files from merge 59709a172ee58c9d529a8c4b6f5cf53460629cb3 and you are trying to merge #6 into #7 (or #7 into #6). #6 does not have usr/kinit and nfsmount at the top; #7 has nfsmount under usr/kinit/. Hi Junio. Ican expalin some of the background for this particular merge. At about one month ago I cloned the current klibc.git tree and started doing the necessary modifications needed to introduce kbuild - the build system used in the kernel. Futhermore we decided to move files around so they fit the directory structure planned to be used in the kernel - when we at one point in the future merged with mainline. While I were modifying the build system the development continued and a few files saw some updates in the official klibc tree. So what we want to do in this case is: - Merge the kbuild changes into the official tree without loosing the changes made to renamed files. On purpose I did not modify any of the renamed files so the klibc-kbuild tree contains renames only for these. If it would be possible to merge: libs/klibc/klibc.git and libs/klibc/sam/klibc-kbuild.git using the above rules it would be perfect. Then a few of the patches from libs/klibc/klibc-kbuild.git would have to be applied again, but thats doable. Anyway my view on it. Since Peter is the one doing the merge he may have better ideas. Sam - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
On Sat, Sep 03, 2005 at 11:46:53AM -0700, Junio C Hamano wrote: [lots of good stuff] I obviously misunderstood the complexity of this merge case. Thank you for the explanation. - Fredrik - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
Sam Ravnborg [EMAIL PROTECTED] writes: As explained in another mail what we want to do is actually to transpose the changes made to F to the now renamed file G. So we end up with G containing the modifications made to F. Also we want to include the new file K. Thanks for the clarification. But the principles are the same. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moved files and merges
Martin Langhoff wrote: Probably should be hacked into cg-merge. When the merge reports a file is missing, what happens? Does it leave a .rej file or anything? The error message is: MERGE ERROR: nfsmount/mount.c: Not handling case 3225ecdf8d172cda2a6ea5276af0d3edc566a0e7 - - c02da9e576a525a2a49da930107ed3936a45b6e1 MERGE ERROR: nfsmount/sunrpc.c: Not handling case 037e33e84ebcee4e097a009439c1bab7143ef92d - - e2fe5f8b728b5235010ed317e759222179dcd45c Conflicts during merge. Do cg-commit after resolving them. -hpa - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
