{"thread":{"id":"1748","subject":"GIT 0.99.6","startedAt":"2005-09-08T00:08:31Z","lastAt":"2005-09-20T00:51:48Z","messageCount":28,"participants":["Junio C Hamano","Yasushi SHOJI","Petr Baudis","Linus Torvalds","Nigel Cunningham","Chris White","Anton Altaparmakov","Alan Chandler","Matthias Urlichs","Johannes Schindelin","Joachim B Haga","Pavel Machek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8178","messageId":"7vr7c02zgg.fsf@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":null,"subject":"GIT 0.99.6","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-08T00:08:31Z","receivedAt":"2005-09-08T00:08:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Highlights\n==========\n\n* Documentation is in much better shape.  Thanks everybody.\n\n* Two grave bugs in 'git fetch' were caught and fixed.  One is \"Fix\n  fetching of tags\", the other is \"Fix pulling into the same branch.\".\n\n* We have archimport (unfortunately undocumented yet), and\n  cvsimport is being improved.\n\n* Revert, rebase and cherry-pick are done using three-way merge,\n  not a straight patch application.\n\n* 'git commit' should be a bit easier to use than before in\n  initial commits and merge commits.\n\n* 'git applymbox' is a bit more accomodating and it should be\n  easier to handle MIME patches than before.\n\n* As usual, comes with more recent gitk.\n\nBetter merge algorithms and the infrastructure are being worked\non by Daniel and Fredrik; they are not in this release yet.\n\n\nWhat to expect after 0.99.6\n===========================\n\nThis is written in a form of to-do list for me, so if I say\n\"accept patch\", it means I do not currently plan to do that\nmyself.  People interested in seeing it materialize please take\na hint.  The latest copy of this document is found at \n\n    http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO\n\nTool Renames Plan\n-----------------\n\n - All non-binary commands will lose -script suffix in\n   $(bindir).  The source to git-foo will be either git-foo.sh\n   or git-foo.perl in the source tree, and the documentation\n   will be in Documentation/git-foo.txt.\n\n - The commands whose names have 'cache' to mean 'index file'\n   will get 'cache' in their names replaced with 'index'. For\n   git-fsck-cache and git-convert-cache, 'cache' will be\n   replaced with 'objects'.\n\n - The commit walkers will have 'pull' in their names replaced\n   with 'fetch'.  'git-ssh-push' will become 'git-ssh-upload'.\n\n - We continue to follow the convention to name the C source\n   file that contains the main program of 'git-foo' command\n   'foo.c'.  That means we will have 'fsck-objects.c', for\n   example.\n\n - At this moment, I am not planning to rename the symbols used\n   in programs, nor any library sources.  \"cache.h\" will stay\n   \"cache.h\", so does \"read-cache.c\".  \"struct cache_entry\"  and\n   \"ce_match_stat()\" will keep their names.  We _might_ want to\n   rename them in later rounds but not right now.\n\n - In 0.99.7, all renamed commands will have symbolic links in\n   $(bindir) so that old names continue to work.  These backward\n   compatible symlinks will not be present in documentation,\n   though.  Especially, the main documentation, git(7) will talk\n   about the new names.  Old environment names defined in\n   gitenv() will also be removed in this release.\n\n   Tentatively we aim to do this on Sep 17th.\n\n - In 0.99.8, we do not install these backward compatible\n   symbolic links in $(bindir) anymore.  The Makefile will have\n   a target to remove old symlinks from $(DESTDIR)$(bindir) you\n   can run manually to help you clean things up.\n\n   The timeframe for this is around Oct 1st, but I could be\n   talked into delaying the symlink removal if Porcelain people\n   find this schedule too tight.\n\n\nDocumentation\n-------------\n\n* Accept patches from people who actually have done CVS\n  migration and update the cvs-migration documentation.\n  Link the documentation from the main git.txt page.\n\n* Accept patches from people who were hit by shiny blue bat to\n  update the SubmittingPatches [ONGOING].\n\n* Talk about using rsync just once at the beginning when\n  initializing a remote repository so that local packs do not\n  need to be expanded.  I personally do not think we need tool\n  support for this (but see below about optimized cloning).\n\n* Maybe update tutorial with a toy project that involves two or\n  three developers..\n\n* Update tutorial to cover setting up repository hooks to do\n  common tasks.\n\n* Accept patches to finish missing docs.\n\n\nTechnical (heavier)\n-------------------\n\n* Tony Luck reported an unfortunate glitch in the 3-way merge.\n  Encourage discussions to come up with a not-so-expensive way\n  to catch the kind of ambiguities that led to his misery.\n  [Daniel's patch looks quite promising, so is the one from\n  Fredrik.]\n\n* HPA has two projects, klibc and klibc-kbuild, that have large\n  set of overlapping files in different paths (i.e. one has many\n  renames from the other).  There currently is no way for git to\n  help keep these two trees in sync, merging criss-cross between\n  them.  The merge logic should be able to take advantage of\n  rename/copy detection smarts git-diff-* family has.  Linus,\n  me, and Daniel outlined a smarter merge strategy for this.\n  Try them out.\n\n* To make it easier to experiment with different merge\n  strategies, make git-merge driver that will run merge backends\n  for the best merge [Outlined the idea; just do it].\n\n* We might want to optimize cloning with GIT native transport\n  not to explode the pack, and store it in objects/pack instead.\n  We would need a tool to generate an idx file out of a pack\n  file for this.  Also this itself may turn out to be a bad\n  idea, making the set of packs in repositories everybody has\n  different from each other.\n\n* Maybe a pack optimizer.  I am not convinced that packing all\n  objects into a single pack and removing all the existing panck\n  is the right way to go, since that would work against people\n  who already have those packs.\n\n* Maybe an Emacs VC backend.\n\n\nTechnical (milder)\n------------------\n\n* Tool renames [STARTED].\n\n* Have Daniel's read-tree graduate from \"pu\" after plugging leaks.\n\n* Implement a merge backend using Daniel's read-tree.\n\n* Accept Fredrik merge after renaming it (I want to name the\n  driver 'git merge').  Suggest where to place *.py stuff --\n  probably in $(share)/git-core/ and add Makefile entry for\n  installation.\n\n* Encourage concrete proposals to commit log message templates\n  we discussed some time ago.\n\n* Bug Martin for archimport script documentation.\n\n* More portability.  I dropped a SunOS patch on the floor by\n  somebody.\n\n* Accept patches to cause \"read-tree -u\" delete a directory when\n  it makes it empty.\n\n* Perhaps accept patches to introduce the concept of \"patch flow\n  expressed as ref mappings\" Josef has been advocating about.\n\n* Perhaps accept patches to do undo/redo.\n\n* Maybe grok PGP signed text/plain in applymbox as well.\n\n* Perhaps a tool to revert a single file to pre-modification\n  state?  git-cat-file blob `git-ls-files | grep foo` >foo or\n  git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should\n  the command be called?  git-revert is taken so is\n  git-checkout.\n\n* A tool to detect, show and prune already merged topic\n  branches.\n\n* Enhance \"git repack\" to not always use --all; this would be\n  handy if the repository contains wagging heads like \"pu\" in\n  git.git repository.\n\n* Internally split the project into non-doc and doc parts; add\n  an extra root for the doc part and merge from it; move the\n  internal doc source to a separate repository, like the +Meta\n  repository; experiment if this results in a reasonable\n  workflow, and document it in howto form if it does.\n\n* Option to limit rename detection for more than N paths.\n\n\nTechnical (trivial)\n-------------------\n\n* Perhaps \"git branch -d\" to delete a branch.\n\n* We would want test scripts for the relative directory path\n  stuff Linus has been working on.  So far, the following\n  commands should be usable with relative directory paths:\n\n    update-cache\n    ls-files\n    diff-files\n    diff-cache\n    diff-tree\n    rev-list\n    rev-parse\n\n* In a freashly created empty repository, `git fetch foo:bar`\n  works OK, but `git checkout bar` afterwards does not (missing\n  `.git/HEAD`).\n"},{"id":"8219","messageId":"7virxbtder.fsf@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"7vr7c02zgg.fsf@assigned-by-dhcp.cox.net","subject":"Tool renames and 'ls-files -t' output","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-08T22:14:52Z","receivedAt":"2005-09-08T22:14:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The \"master\" branch post 0.99.6 already has the renamed tools\nwith backward compatibility symlinks.  I'll be sending a\npatch to address an issue raised by some people separately to\nsee what the list thinks, and also will attempt to send out a\npatch for the Pasky and Catalin heads later this week.  Also\nI'll remove the ancient backward compatible environment variable\nnames from gitenv.c.\n\nThere were discussion on the tag 'git-ls-files -t' output uses.\nI got a feeling that we might want to change them to match what\nother tools give.  Here is the proposed changes:\n\t\n    Meaning\tCurrent\t\tUpdated\n\n    cached\tH\t\t.\n    unmerged\tM\t\tU\n    removed\tR\t\tD\n    other\t?\t\t?\n    killed\tK\t\tK\n    modified\tinfo unav.\tM\n\nI may also be tempted to rename 'tag_removed' variable there to\n'tag_deleted' for consistency.\n\nComments?\n"},{"id":"8225","messageId":"7vll27rr8w.fsf@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"7vr7c02zgg.fsf@assigned-by-dhcp.cox.net","subject":"[RFC/Patch] Tool rename fallout fix","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-09T00:58:55Z","receivedAt":"2005-09-09T00:58:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Immediately after I updated the \"master\" branch with the tool\nrenames, I got a complaint from somebody telling me that the\nthings do not work anymore without 'make install'.\n\nStrictly speaking, git has never worked fully without\ninstallation because 'git' wrapper looked for things in the same\ndirectory as it was in, which meant that 'git applymbox' would\nnot have worked anyway (it was coming from tools/applymbox until\nrecently), but on the other hand it certainly is nice if we can\nrun most of the things immediately after building but before\ninstalling.\n\nThis patch attempts to remedy it.  What is helped the most is\nthat test scripts do not have to special case the scripts\nanymore; obviously we do want to be able to run tests before\ninstalling.  A downside is that your working tree after a build\nhas a lot more files than before.\n\nAs a side effect, you can specify non-standard path your Perl is\ninstalled, and you can explicitly say \"#!/usr/local/bin/bash\".\n\nComments?\n\n\n---\ncd /opt/packrat/playpen/public/in-place/git/git.junio/\ngit diff HEAD\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -142,6 +142,13 @@ ifeq ($(shell uname -s),SunOS)\n \tPLATFORM_DEFINES += -DNO_GETDOMAINNAME=1\n endif\n \n+ifndef SHELL_PATH\n+\tSHELL_PATH = /bin/sh\n+endif\n+ifndef PERL_PATH\n+\tPERL_PATH = /usr/bin/perl\n+endif\n+\n ifndef NO_OPENSSL\n \tLIB_OBJS += epoch.o\n \tOPENSSL_LIBSSL = -lssl\n@@ -179,21 +186,32 @@ endif\n \n DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'\n \n-SCRIPTS = $(SCRIPT_SH) $(SCRIPT_PERL) gitk\n+SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \\\n+\t  $(patsubst %.perl,%,$(SCRIPT_PERL)) gitk\n \n ### Build rules\n \n-all: $(PROGRAMS) git.sh\n+all: $(PROGRAMS) $(SCRIPTS)\n \n all:\n \t$(MAKE) -C templates\n \n-git.sh: git.sh.in Makefile\n+git: git.sh Makefile\n \trm -f $@+ $@\n-\tsed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.in >$@+\n+\tsed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' <$@.sh >$@+\n \tchmod +x $@+\n \tmv $@+ $@\n \n+$(filter-out git,$(patsubst %.sh,%,$(SCRIPT_SH))) : % : %.sh\n+\trm -f $@\n+\tsed -e '1s|#!.*/sh|#!$(SHELL_PATH)|' $@.sh >$@\n+\tchmod +x $@\n+\n+$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl\n+\trm -f $@\n+\tsed -e '1s|#!.*perl|#!$(PERL_PATH)|' $@.perl >$@\n+\tchmod +x $@\n+\n %.o: %.c\n \t$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n %.o: %.S\n@@ -250,19 +268,8 @@ check:\n \n install: $(PROGRAMS) $(SCRIPTS)\n \t$(INSTALL) -m755 -d $(DESTDIR)$(bindir)\n-\t$(INSTALL) $(PROGRAMS) $(DESTDIR)$(bindir)\n-\t@for s in $(SCRIPTS); \\\n-\tdo \\\n-\t\tcase \"$$s\" in \\\n-\t\t*.*) \\\n-\t\t\te=`expr \"$$s\" : '\\(.*\\)\\.[^.]*$$'` ;; \\\n-\t\t*) \\\n-\t\t\te=\"$$s\" ;; \\\n-\t\tesac && \\\n-\t\techo \": install $$s $(DESTDIR)$(bindir)/$$e\" && \\\n-\t\t$(INSTALL) $$s $(DESTDIR)$(bindir)/$$e || exit; \\\n-\tdone\n-\t$(INSTALL) git-revert.sh $(DESTDIR)$(bindir)/git-cherry-pick\n+\t$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)$(bindir)\n+\t$(INSTALL) git-revert $(DESTDIR)$(bindir)/git-cherry-pick\n \tsh ./cmd-rename.sh $(DESTDIR)$(bindir)\n \t$(MAKE) -C templates install\n \n@@ -299,7 +306,8 @@ deb: dist\n \n clean:\n \trm -f *.o mozilla-sha1/*.o ppc/*.o $(PROGRAMS) $(LIB_FILE)\n-\trm -f git-core.spec git.sh\n+\trm -f $(filter-out gitk,$(SCRIPTS))\n+\trm -f git-core.spec\n \trm -rf $(GIT_TARNAME)\n \trm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz\n \trm -f git-core_$(GIT_VERSION)-*.deb git-core_$(GIT_VERSION)-*.dsc\ndiff --git a/git.sh.in b/git.sh\nsimilarity index 100%\nrename from git.sh.in\nrename to git.sh\ndiff --git a/t/t1005-read-tree-m-2way-emu23.sh b/t/t1005-read-tree-m-2way-emu23.sh\n--- a/t/t1005-read-tree-m-2way-emu23.sh\n+++ b/t/t1005-read-tree-m-2way-emu23.sh\n@@ -25,7 +25,7 @@ In the test, these paths are used:\n read_tree_twoway () {\n     git-read-tree --emu23 \"$1\" \"$2\" &&\n     git-ls-files --stage &&\n-    git-merge-index ../../git-merge-one-file.sh -a &&\n+    git-merge-index git-merge-one-file -a &&\n     git-ls-files --stage\n }\n \ndiff --git a/t/t3200-branch.sh b/t/t3200-branch.sh\n--- a/t/t3200-branch.sh\n+++ b/t/t3200-branch.sh\n@@ -13,12 +13,12 @@ handled.  Specifically, that a bogus bra\n test_expect_success \\\n     'prepare an trivial repository' \\\n     'echo Hello > A &&\n-     ../../git-update-index --add A &&\n-     ../../git-commit.sh -m \"Initial commit.\"'\n+     git-update-index --add A &&\n+     git-commit -m \"Initial commit.\"'\n \n test_expect_failure \\\n     'git branch --help should return error code' \\\n-    '../../git-branch.sh --help'\n+    'git-branch --help'\n \n test_expect_failure \\\n     'git branch --help should not have created a bogus branch' \\\ndiff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh\n--- a/t/t5400-send-pack.sh\n+++ b/t/t5400-send-pack.sh\n@@ -21,9 +21,9 @@ test_expect_success setup '\n \t    parent=$commit || return 1\n \tdone &&\n \techo \"$commit\" >.git/HEAD &&\n-\tgit-clone.sh -l ./. victim &&\n+\tgit-clone -l ./. victim &&\n \tcd victim &&\n-\tgit-log.sh &&\n+\tgit-log &&\n \tcd .. &&\n \techo $zero >.git/HEAD &&\n \tparent=$zero &&\n@@ -35,7 +35,7 @@ test_expect_success setup '\n \tdone &&\n \techo \"$commit\" >.git/HEAD &&\n \techo Rebase &&\n-\tgit-log.sh'\n+\tgit-log'\n \n test_expect_success \\\n         'pushing rewound head should not barf but require --force' ' \n"},{"id":"8231","messageId":"7virxalhqi.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"7virxbtder.fsf@assigned-by-dhcp.cox.net","subject":"Post 0.99.7 preperation patches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-09T09:20:53Z","receivedAt":"2005-09-09T09:20:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> The \"master\" branch post 0.99.6 already has the renamed tools\n> with backward compatibility symlinks.  I'll be sending a\n> patch to address an issue raised by some people separately to\n> see what the list thinks, and also will attempt to send out a\n> patch for the Pasky and Catalin heads later this week.\n\nI've prepared these and will be sending them out separately to\nyou two, hoping they would help you prepare for post 0.99.7\nchanges.  Note that 0.99.6 does not know about these new names,\nthe current \"master\" branch knows about both new and old names,\nso will 0.99.7, and in 0.99.8 the old names will be removed, if\nthings go as planned.\n\nHere is a small script that I used before auditing what it did\nto your trees by running 'git diff' on its result.\n\n------------\n#!/bin/sh\ngit-ls-files |\nxargs perl -i -p -e '\n\ts/git-merge-one-file-script/git-merge-one-file/g;\n\ts/git-count-objects-script/git-count-objects/g;\n\ts/git-format-patch-script/git-format-patch/g;\n\ts/git-parse-remote-script/git-parse-remote/g;\n\ts/git-request-pull-script/git-request-pull/g;\n\ts/git-cherry-pick-script/git-cherry-pick/g;\n\ts/git-archimport-script/git-archimport/g;\n\ts/git-send-email-script/git-send-email/g;\n\ts/git-verify-tag-script/git-verify-tag/g;\n\ts/git-cvsimport-script/git-cvsimport/g;\n\ts/git-ls-remote-script/git-ls-remote/g;\n\ts/git-checkout-script/git-checkout/g;\n\ts/git-sh-setup-script/git-sh-setup/g;\n\ts/git-octopus-script/git-octopus/g;\n\ts/git-resolve-script/git-resolve/g;\n\ts/git-checkout-cache/git-checkout-index/g;\n\ts/git-bisect-script/git-bisect/g;\n\ts/git-branch-script/git-branch/g;\n\ts/git-commit-script/git-commit/g;\n\ts/git-rebase-script/git-rebase/g;\n\ts/git-relink-script/git-relink/g;\n\ts/git-rename-script/git-rename/g;\n\ts/git-repack-script/git-repack/g;\n\ts/git-revert-script/git-revert/g;\n\ts/git-status-script/git-status/g;\n\ts/git-convert-cache/git-convert-objects/g;\n\ts/git-clone-script/git-clone/g;\n\ts/git-fetch-script/git-fetch/g;\n\ts/git-prune-script/git-prune/g;\n\ts/git-reset-script/git-reset/g;\n\ts/git-update-cache/git-update-index/g;\n\ts/git-diff-script/git-diff/g;\n\ts/git-pull-script/git-pull/g;\n\ts/git-push-script/git-push/g;\n\ts/git-merge-cache/git-merge-index/g;\n\ts/git-add-script/git-add/g;\n\ts/git-log-script/git-log/g;\n\ts/git-tag-script/git-tag/g;\n\ts/git-local-pull/git-local-fetch/g;\n\ts/git-diff-cache/git-diff-index/g;\n\ts/git-fsck-cache/git-fsck-objects/g;\n\ts/git-http-pull/git-http-fetch/g;\n\ts/git-ssh-pull/git-ssh-fetch/g;\n\ts/git-ssh-push/git-ssh-upload/g;\n'\ngit-update-cache --refresh\n"},{"id":"8264","messageId":"874q8s6q9w.wl@mail2.atmark-techno.com","threadId":"1748","inReplyTo":"7virxbtder.fsf@assigned-by-dhcp.cox.net","subject":"RFC: s/git-merge-base/git-find-common-ancestor/g","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2005-09-11T07:02:19Z","receivedAt":"2005-09-11T07:02:19Z","isPatch":false,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"At Thu, 08 Sep 2005 15:14:52 -0700,\nJunio C Hamano wrote:\n> \n> The \"master\" branch post 0.99.6 already has the renamed tools\n> with backward compatibility symlinks.  I'll be sending a\n> patch to address an issue raised by some people separately to\n> see what the list thinks, and also will attempt to send out a\n> patch for the Pasky and Catalin heads later this week.  Also\n> I'll remove the ancient backward compatible environment variable\n> names from gitenv.c.\n\neverything seems very consistent indeed, except one command:\n\n   git-merge-base\n\nI've already got used to it. but, at first, the name gave me the\nimpression that it merge the current branch with given base point.\n\nthe current documentation says:\n\n   Finds as good a common ancestor as possible for a merge\n\nso would it be better to rename it to:\n\n   git-find-common-ancestor\n\nThat's what the command does after all.\n--\n         yashi\n"},{"id":"8266","messageId":"7v64t8xddr.fsf@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"874q8s6q9w.wl@mail2.atmark-techno.com","subject":"Re: RFC: s/git-merge-base/git-find-common-ancestor/g","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-11T07:38:40Z","receivedAt":"2005-09-11T07:38:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yasushi SHOJI <yashi@atmark-techno.com> writes:\n\n> I've already got used to it. but, at first, the name gave me the\n> impression that it merge the current branch with given base point.\n>\n> the current documentation says:\n>\n>    Finds as good a common ancestor as possible for a merge\n>\n> so would it be better to rename it to:\n>\n>    git-find-common-ancestor\n>\n> That's what the command does after all.\n\nIt does not find just any common ancestor, but tries to find a\nset of common ancestors that are good to be used as merge bases.\nSo git-find-merge-base _might_ be an acceptable rename, but\ngit-find-common-ancestor certainly isn't.\n"},{"id":"8272","messageId":"87zmqk5768.wl@mail2.atmark-techno.com","threadId":"1748","inReplyTo":"7v64t8xddr.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Rename git-merge-base to git-find-merge-base","fromName":"Yasushi SHOJI","fromEmail":"yashi@atmark-techno.com","sentAt":"2005-09-11T08:40:15Z","receivedAt":"2005-09-11T08:40:15Z","isPatch":true,"sender":{"key":"yashi@atmark-techno.com","avatar":"https://gravatar.com/avatar/4817e8703ac4379935834d87453faa9d0c94b9dc19d83fcc54c67875eb133e59?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> Yasushi SHOJI <yashi@atmark-techno.com> writes:\n> \n> > I've already got used to it. but, at first, the name gave me the\n> > impression that it merge the current branch with given base point.\n> >\n> > the current documentation says:\n> >\n> >    Finds as good a common ancestor as possible for a merge\n> >\n> > so would it be better to rename it to:\n> >\n> >    git-find-common-ancestor\n> >\n> > That's what the command does after all.\n> \n> It does not find just any common ancestor, but tries to find a\n> set of common ancestors that are good to be used as merge bases.\n> So git-find-merge-base _might_ be an acceptable rename, but\n> git-find-common-ancestor certainly isn't.\n\nok.  it certainly does't find all common ancestors for given sha1s.\n\nhow about renaming the command to git-find-merge-base as you suggested\nand document what the merge base is?\n\nattached patch does the rename only.  haven't added \"merge base\" entry\nto Documentation/git-find-merge-base.txt.\n--\n       yashi\n\nRename git-merge-base to git-find-merge-base\n\nThe command is to _find_ merge base, not merge something with base.\nReflect what it does to its name.\n\nSigned-off-by: Yasushi SHOJI <yashi@atmark-techno.com>\n\n\n---\n\n .gitignore                            |    2 \n Documentation/git-find-merge-base.txt |   34 +++++++\n Documentation/git-merge-base.txt      |   34 -------\n Documentation/git-read-tree.txt       |    2 \n Documentation/git-show-branch.txt     |    2 \n Documentation/git.txt                 |    2 \n Makefile                              |    2 \n README                                |    2 \n find-merge-base.c                     |  171 +++++++++++++++++++++++++++++++++\n git-archimport.perl                   |    4 -\n git-fetch.sh                          |    2 \n git-merge-octopus.sh                  |    2 \n git-merge.sh                          |    2 \n git-octopus.sh                        |    2 \n git-resolve.sh                        |    4 -\n gitk                                  |    2 \n merge-base.c                          |  171 ---------------------------------\n t/t4100/t-apply-1.patch               |    2 \n t/t4100/t-apply-5.patch               |    2 \n templates/hooks--update               |    2 \n 20 files changed, 223 insertions(+), 223 deletions(-)\n create mode 100644 Documentation/git-find-merge-base.txt\n delete mode 100644 Documentation/git-merge-base.txt\n create mode 100644 find-merge-base.c\n delete mode 100644 merge-base.c\n\n2652b63c0dcd376f47e3985be26a3cef67c397c8\ndiff --git a/.gitignore b/.gitignore\n--- a/.gitignore\n+++ b/.gitignore\n@@ -42,7 +42,7 @@ git-ls-tree\n git-mailinfo\n git-mailsplit\n git-merge\n-git-merge-base\n+git-find-merge-base\n git-merge-fredrik\n git-merge-index\n git-merge-octopus\ndiff --git a/Documentation/git-find-merge-base.txt b/Documentation/git-find-merge-base.txt\nnew file mode 100644\n--- /dev/null\n+++ b/Documentation/git-find-merge-base.txt\n@@ -0,0 +1,34 @@\n+git-find-merge-base(1)\n+======================\n+v0.1, May 2005\n+\n+NAME\n+----\n+git-find-merge-base - Finds as good a common ancestor as possible for a merge\n+\n+\n+SYNOPSIS\n+--------\n+'git-find-merge-base' <commit> <commit>\n+\n+DESCRIPTION\n+-----------\n+\"git-find-merge-base\" finds as good a common ancestor as possible. Given a\n+selection of equally good common ancestors it should not be relied on\n+to decide in any particular way.\n+\n+The \"git-find-merge-base\" algorithm is still in flux - use the source...\n+\n+\n+Author\n+------\n+Written by Linus Torvalds <torvalds@osdl.org>\n+\n+Documentation\n+--------------\n+Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.\n+\n+GIT\n+---\n+Part of the link:git.html[git] suite\n+\ndiff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt\ndeleted file mode 100644\n--- a/Documentation/git-merge-base.txt\n+++ /dev/null\n@@ -1,34 +0,0 @@\n-git-merge-base(1)\n-=================\n-v0.1, May 2005\n-\n-NAME\n-----\n-git-merge-base - Finds as good a common ancestor as possible for a merge\n-\n-\n-SYNOPSIS\n---------\n-'git-merge-base' <commit> <commit>\n-\n-DESCRIPTION\n------------\n-\"git-merge-base\" finds as good a common ancestor as possible. Given a\n-selection of equally good common ancestors it should not be relied on\n-to decide in any particular way.\n-\n-The \"git-merge-base\" algorithm is still in flux - use the source...\n-\n-\n-Author\n-------\n-Written by Linus Torvalds <torvalds@osdl.org>\n-\n-Documentation\n---------------\n-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.\n-\n-GIT\n----\n-Part of the link:git.html[git] suite\n-\ndiff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt\n--- a/Documentation/git-read-tree.txt\n+++ b/Documentation/git-read-tree.txt\n@@ -239,7 +239,7 @@ some edits since.  Three-way merge makes\n added or modified cache entries since $JC, and if you haven't,\n then does the right thing.  So with the following sequence:\n \n-    $ git-read-tree -m -u `git-merge-base $JC $LT` $JC $LT\n+    $ git-read-tree -m -u `git-find-merge-base $JC $LT` $JC $LT\n     $ git-merge-index git-merge-one-file -a\n     $ echo \"Merge with Linus\" | \\\n       git-commit-tree `git-write-tree` -p $JC -p $LT\ndiff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt\n--- a/Documentation/git-show-branch.txt\n+++ b/Documentation/git-show-branch.txt\n@@ -38,7 +38,7 @@ OPTIONS\n \n --merge-base::\n \tInstead of showing the commit list, just act like the\n-\t'git-merge-base -a' command, except that it can accept\n+\t'git-find-merge-base -a' command, except that it can accept\n \tmore than two heads.\n \n --independent::\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -131,7 +131,7 @@ link:git-ls-files.html[git-ls-files]::\n link:git-ls-tree.html[git-ls-tree]::\n \tDisplays a tree object in human readable form\n \n-link:git-merge-base.html[git-merge-base]::\n+link:git-find-merge-base.html[git-find-merge-base]::\n \tFinds as good a common ancestor as possible for a merge\n \n link:git-rev-list.html[git-rev-list]::\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -98,7 +98,7 @@ PROGRAMS = \\\n \tgit-diff-helper git-diff-index git-diff-stages \\\n \tgit-diff-tree git-export git-fetch-pack git-fsck-objects \\\n \tgit-hash-object git-init-db \\\n-\tgit-local-fetch git-ls-files git-ls-tree git-merge-base \\\n+\tgit-local-fetch git-ls-files git-ls-tree git-find-merge-base \\\n \tgit-merge-index git-mktag git-pack-objects git-patch-id \\\n \tgit-peek-remote git-prune-packed git-read-tree \\\n \tgit-receive-pack git-rev-list git-rev-parse \\\ndiff --git a/README b/README\n--- a/README\n+++ b/README\n@@ -445,7 +445,7 @@ state of the directory (\"tree\" object) a\n To get the \"base\" for the merge, you first look up the common parent\n of two commits with\n \n-\t\tgit-merge-base <commit1> <commit2>\n+\t\tgit-find-merge-base <commit1> <commit2>\n \n which will return you the commit they are both based on.  You should\n now look up the \"tree\" objects of those commits, which you can easily\ndiff --git a/find-merge-base.c b/find-merge-base.c\nnew file mode 100644\n--- /dev/null\n+++ b/find-merge-base.c\n@@ -0,0 +1,171 @@\n+#include <stdlib.h>\n+#include \"cache.h\"\n+#include \"commit.h\"\n+\n+#define PARENT1 1\n+#define PARENT2 2\n+#define UNINTERESTING 4\n+\n+static struct commit *interesting(struct commit_list *list)\n+{\n+\twhile (list) {\n+\t\tstruct commit *commit = list->item;\n+\t\tlist = list->next;\n+\t\tif (commit->object.flags & UNINTERESTING)\n+\t\t\tcontinue;\n+\t\treturn commit;\n+\t}\n+\treturn NULL;\n+}\n+\n+/*\n+ * A pathological example of how this thing works.\n+ *\n+ * Suppose we had this commit graph, where chronologically\n+ * the timestamp on the commit are A <= B <= C <= D <= E <= F\n+ * and we are trying to figure out the merge base for E and F\n+ * commits.\n+ *\n+ *                  F\n+ *                 / \\\n+ *            E   A   D\n+ *             \\ /   /  \n+ *              B   /\n+ *               \\ /\n+ *                C\n+ *\n+ * First we push E and F to list to be processed.  E gets bit 1\n+ * and F gets bit 2.  The list becomes:\n+ *\n+ *     list=F(2) E(1), result=empty\n+ *\n+ * Then we pop F, the newest commit, from the list.  Its flag is 2.\n+ * We scan its parents, mark them reachable from the side that F is\n+ * reachable from, and push them to the list:\n+ *\n+ *     list=E(1) D(2) A(2), result=empty\n+ *\n+ * Next pop E and do the same.\n+ *\n+ *     list=D(2) B(1) A(2), result=empty\n+ *\n+ * Next pop D and do the same.\n+ *\n+ *     list=C(2) B(1) A(2), result=empty\n+ *\n+ * Next pop C and do the same.\n+ *\n+ *     list=B(1) A(2), result=empty\n+ *\n+ * Now it is B's turn.  We mark its parent, C, reachable from B's side,\n+ * and push it to the list:\n+ *\n+ *     list=C(3) A(2), result=empty\n+ *\n+ * Now pop C and notice it has flags==3.  It is placed on the result list,\n+ * and the list now contains:\n+ *\n+ *     list=A(2), result=C(3)\n+ *\n+ * We pop A and do the same.\n+ * \n+ *     list=B(3), result=C(3)\n+ *\n+ * Next, we pop B and something very interesting happens.  It has flags==3\n+ * so it is also placed on the result list, and its parents are marked\n+ * uninteresting, retroactively, and placed back on the list:\n+ *\n+ *    list=C(7), result=C(7) B(3)\n+ * \n+ * Now, list does not have any interesting commit.  So we find the newest\n+ * commit from the result list that is not marked uninteresting.  Which is\n+ * commit B.\n+ */\n+\n+static int show_all = 0;\n+\n+static int find_merge_base(struct commit *rev1, struct commit *rev2)\n+{\n+\tstruct commit_list *list = NULL;\n+\tstruct commit_list *result = NULL;\n+\n+\tif (rev1 == rev2) {\n+\t\tprintf(\"%s\\n\", sha1_to_hex(rev1->object.sha1));\n+\t\treturn 0;\n+\t}\n+\n+\tparse_commit(rev1);\n+\tparse_commit(rev2);\n+\n+\trev1->object.flags |= 1;\n+\trev2->object.flags |= 2;\n+\tinsert_by_date(rev1, &list);\n+\tinsert_by_date(rev2, &list);\n+\n+\twhile (interesting(list)) {\n+\t\tstruct commit *commit = list->item;\n+\t\tstruct commit_list *tmp = list, *parents;\n+\t\tint flags = commit->object.flags & 7;\n+\n+\t\tlist = list->next;\n+\t\tfree(tmp);\n+\t\tif (flags == 3) {\n+\t\t\tinsert_by_date(commit, &result);\n+\n+\t\t\t/* Mark parents of a found merge uninteresting */\n+\t\t\tflags |= UNINTERESTING;\n+\t\t}\n+\t\tparents = commit->parents;\n+\t\twhile (parents) {\n+\t\t\tstruct commit *p = parents->item;\n+\t\t\tparents = parents->next;\n+\t\t\tif ((p->object.flags & flags) == flags)\n+\t\t\t\tcontinue;\n+\t\t\tparse_commit(p);\n+\t\t\tp->object.flags |= flags;\n+\t\t\tinsert_by_date(p, &list);\n+\t\t}\n+\t}\n+\n+\tif (!result)\n+\t\treturn 1;\n+\n+\twhile (result) {\n+\t\tstruct commit *commit = result->item;\n+\t\tresult = result->next;\n+\t\tif (commit->object.flags & UNINTERESTING)\n+\t\t\tcontinue;\n+\t\tprintf(\"%s\\n\", sha1_to_hex(commit->object.sha1));\n+\t\tif (!show_all)\n+\t\t\treturn 0;\n+\t\tcommit->object.flags |= UNINTERESTING;\n+\t}\n+\treturn 0;\n+}\n+\n+static const char find_merge_base_usage[] =\n+\"git-find-merge-base [--all] <commit-id> <commit-id>\";\n+\n+int main(int argc, char **argv)\n+{\n+\tstruct commit *rev1, *rev2;\n+\tunsigned char rev1key[20], rev2key[20];\n+\n+\twhile (1 < argc && argv[1][0] == '-') {\n+\t\tchar *arg = argv[1];\n+\t\tif (!strcmp(arg, \"-a\") || !strcmp(arg, \"--all\"))\n+\t\t\tshow_all = 1;\n+\t\telse\n+\t\t\tusage(find_merge_base_usage);\n+\t\targc--; argv++;\n+\t}\n+\tif (argc != 3 ||\n+\t    get_sha1(argv[1], rev1key) ||\n+\t    get_sha1(argv[2], rev2key))\n+\t\tusage(find_merge_base_usage);\n+\trev1 = lookup_commit_reference(rev1key);\n+\trev2 = lookup_commit_reference(rev2key);\n+\tif (!rev1 || !rev2)\n+\t\treturn 1;\n+\treturn find_merge_base(rev1, rev2);\n+}\ndiff --git a/git-archimport.perl b/git-archimport.perl\n--- a/git-archimport.perl\n+++ b/git-archimport.perl\n@@ -640,7 +640,7 @@ sub find_parents {\n     #\n     # Identify what branches are merging into me\n     # and whether we are fully merged\n-    # git-merge-base <headsha> <headsha> should tell\n+    # git-find-merge-base <headsha> <headsha> should tell\n     # me what the base of the merge should be \n     #\n     my $ps = shift;\n@@ -674,7 +674,7 @@ sub find_parents {\n     # that branch.\n     #\n     foreach my $branch (keys %branches) {\n-\tmy $mergebase = `git-merge-base $branch $ps->{branch}`;\n+\tmy $mergebase = `git-find-merge-base $branch $ps->{branch}`;\n \tdie \"Cannot find merge base for $branch and $ps->{branch}\" if $?;\n \tchomp $mergebase;\n \ndiff --git a/git-fetch.sh b/git-fetch.sh\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -113,7 +113,7 @@ fast_forward_local () {\n \tif test -f \"$GIT_DIR/$1\"\n \tthen\n \t    local=$(git-rev-parse --verify \"$1^0\") &&\n-\t    mb=$(git-merge-base \"$local\" \"$2\") &&\n+\t    mb=$(git-find-merge-base \"$local\" \"$2\") &&\n \t    case \"$2,$mb\" in\n \t    $local,*)\n \t\techo >&2 \"* $1: same as $3\"\ndiff --git a/git-merge-octopus.sh b/git-merge-octopus.sh\n--- a/git-merge-octopus.sh\n+++ b/git-merge-octopus.sh\n@@ -42,7 +42,7 @@ CNT=1 ;# counting our head\n NON_FF_MERGE=0\n for SHA1 in $remotes\n do\n-\tcommon=$(git-merge-base $MRC $SHA1) ||\n+\tcommon=$(git-find-merge-base $MRC $SHA1) ||\n \t\tdie \"Unable to find common commit with $SHA1\"\n \n \tif test \"$common\" = $SHA1\ndiff --git a/git-merge.sh b/git-merge.sh\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -114,7 +114,7 @@ case \"$#,$common\" in\n \tup_to_date=t\n \tfor remote\n \tdo\n-\t\tcommon_one=$(git-merge-base $head $remote)\n+\t\tcommon_one=$(git-find-merge-base $head $remote)\n \t\tif test \"$common_one\" != \"$remote\"\n \t\tthen\n \t\t\tup_to_date=f\ndiff --git a/git-octopus.sh b/git-octopus.sh\n--- a/git-octopus.sh\n+++ b/git-octopus.sh\n@@ -33,7 +33,7 @@ CNT=1 ;# counting our head\n NON_FF_MERGE=0\n while read SHA1 REPO\n do\n-\tcommon=$(git-merge-base $MRC $SHA1) ||\n+\tcommon=$(git-find-merge-base $MRC $SHA1) ||\n \t\tdie \"Unable to find common commit with $SHA1 from $REPO\"\n \n \tif test \"$common\" = $SHA1\ndiff --git a/git-resolve.sh b/git-resolve.sh\n--- a/git-resolve.sh\n+++ b/git-resolve.sh\n@@ -31,7 +31,7 @@ dropheads\n echo $head > \"$GIT_DIR\"/ORIG_HEAD\n echo $merge > \"$GIT_DIR\"/LAST_MERGE\n \n-common=$(git-merge-base $head $merge)\n+common=$(git-find-merge-base $head $merge)\n if [ -z \"$common\" ]; then\n \tdie \"Unable to find common commit between\" $merge $head\n fi\n@@ -55,7 +55,7 @@ esac\n # Find an optimum merge base if there are more than one candidates.\n LF='\n '\n-common=$(git-merge-base -a $head $merge)\n+common=$(git-find-merge-base -a $head $merge)\n case \"$common\" in\n ?*\"$LF\"?*)\n \techo \"Trying to find the optimum merge base.\"\ndiff --git a/gitk b/gitk\n--- a/gitk\n+++ b/gitk\n@@ -2266,7 +2266,7 @@ proc findgca {ids} {\n \t    set gca $id\n \t} else {\n \t    if {[catch {\n-\t\tset gca [exec git-merge-base $gca $id]\n+\t\tset gca [exec git-find-merge-base $gca $id]\n \t    } err]} {\n \t\treturn {}\n \t    }\ndiff --git a/merge-base.c b/merge-base.c\ndeleted file mode 100644\n--- a/merge-base.c\n+++ /dev/null\n@@ -1,171 +0,0 @@\n-#include <stdlib.h>\n-#include \"cache.h\"\n-#include \"commit.h\"\n-\n-#define PARENT1 1\n-#define PARENT2 2\n-#define UNINTERESTING 4\n-\n-static struct commit *interesting(struct commit_list *list)\n-{\n-\twhile (list) {\n-\t\tstruct commit *commit = list->item;\n-\t\tlist = list->next;\n-\t\tif (commit->object.flags & UNINTERESTING)\n-\t\t\tcontinue;\n-\t\treturn commit;\n-\t}\n-\treturn NULL;\n-}\n-\n-/*\n- * A pathological example of how this thing works.\n- *\n- * Suppose we had this commit graph, where chronologically\n- * the timestamp on the commit are A <= B <= C <= D <= E <= F\n- * and we are trying to figure out the merge base for E and F\n- * commits.\n- *\n- *                  F\n- *                 / \\\n- *            E   A   D\n- *             \\ /   /  \n- *              B   /\n- *               \\ /\n- *                C\n- *\n- * First we push E and F to list to be processed.  E gets bit 1\n- * and F gets bit 2.  The list becomes:\n- *\n- *     list=F(2) E(1), result=empty\n- *\n- * Then we pop F, the newest commit, from the list.  Its flag is 2.\n- * We scan its parents, mark them reachable from the side that F is\n- * reachable from, and push them to the list:\n- *\n- *     list=E(1) D(2) A(2), result=empty\n- *\n- * Next pop E and do the same.\n- *\n- *     list=D(2) B(1) A(2), result=empty\n- *\n- * Next pop D and do the same.\n- *\n- *     list=C(2) B(1) A(2), result=empty\n- *\n- * Next pop C and do the same.\n- *\n- *     list=B(1) A(2), result=empty\n- *\n- * Now it is B's turn.  We mark its parent, C, reachable from B's side,\n- * and push it to the list:\n- *\n- *     list=C(3) A(2), result=empty\n- *\n- * Now pop C and notice it has flags==3.  It is placed on the result list,\n- * and the list now contains:\n- *\n- *     list=A(2), result=C(3)\n- *\n- * We pop A and do the same.\n- * \n- *     list=B(3), result=C(3)\n- *\n- * Next, we pop B and something very interesting happens.  It has flags==3\n- * so it is also placed on the result list, and its parents are marked\n- * uninteresting, retroactively, and placed back on the list:\n- *\n- *    list=C(7), result=C(7) B(3)\n- * \n- * Now, list does not have any interesting commit.  So we find the newest\n- * commit from the result list that is not marked uninteresting.  Which is\n- * commit B.\n- */\n-\n-static int show_all = 0;\n-\n-static int merge_base(struct commit *rev1, struct commit *rev2)\n-{\n-\tstruct commit_list *list = NULL;\n-\tstruct commit_list *result = NULL;\n-\n-\tif (rev1 == rev2) {\n-\t\tprintf(\"%s\\n\", sha1_to_hex(rev1->object.sha1));\n-\t\treturn 0;\n-\t}\n-\n-\tparse_commit(rev1);\n-\tparse_commit(rev2);\n-\n-\trev1->object.flags |= 1;\n-\trev2->object.flags |= 2;\n-\tinsert_by_date(rev1, &list);\n-\tinsert_by_date(rev2, &list);\n-\n-\twhile (interesting(list)) {\n-\t\tstruct commit *commit = list->item;\n-\t\tstruct commit_list *tmp = list, *parents;\n-\t\tint flags = commit->object.flags & 7;\n-\n-\t\tlist = list->next;\n-\t\tfree(tmp);\n-\t\tif (flags == 3) {\n-\t\t\tinsert_by_date(commit, &result);\n-\n-\t\t\t/* Mark parents of a found merge uninteresting */\n-\t\t\tflags |= UNINTERESTING;\n-\t\t}\n-\t\tparents = commit->parents;\n-\t\twhile (parents) {\n-\t\t\tstruct commit *p = parents->item;\n-\t\t\tparents = parents->next;\n-\t\t\tif ((p->object.flags & flags) == flags)\n-\t\t\t\tcontinue;\n-\t\t\tparse_commit(p);\n-\t\t\tp->object.flags |= flags;\n-\t\t\tinsert_by_date(p, &list);\n-\t\t}\n-\t}\n-\n-\tif (!result)\n-\t\treturn 1;\n-\n-\twhile (result) {\n-\t\tstruct commit *commit = result->item;\n-\t\tresult = result->next;\n-\t\tif (commit->object.flags & UNINTERESTING)\n-\t\t\tcontinue;\n-\t\tprintf(\"%s\\n\", sha1_to_hex(commit->object.sha1));\n-\t\tif (!show_all)\n-\t\t\treturn 0;\n-\t\tcommit->object.flags |= UNINTERESTING;\n-\t}\n-\treturn 0;\n-}\n-\n-static const char merge_base_usage[] =\n-\"git-merge-base [--all] <commit-id> <commit-id>\";\n-\n-int main(int argc, char **argv)\n-{\n-\tstruct commit *rev1, *rev2;\n-\tunsigned char rev1key[20], rev2key[20];\n-\n-\twhile (1 < argc && argv[1][0] == '-') {\n-\t\tchar *arg = argv[1];\n-\t\tif (!strcmp(arg, \"-a\") || !strcmp(arg, \"--all\"))\n-\t\t\tshow_all = 1;\n-\t\telse\n-\t\t\tusage(merge_base_usage);\n-\t\targc--; argv++;\n-\t}\n-\tif (argc != 3 ||\n-\t    get_sha1(argv[1], rev1key) ||\n-\t    get_sha1(argv[2], rev2key))\n-\t\tusage(merge_base_usage);\n-\trev1 = lookup_commit_reference(rev1key);\n-\trev2 = lookup_commit_reference(rev2key);\n-\tif (!rev1 || !rev2)\n-\t\treturn 1;\n-\treturn merge_base(rev1, rev2);\n-}\ndiff --git a/t/t4100/t-apply-1.patch b/t/t4100/t-apply-1.patch\n--- a/t/t4100/t-apply-1.patch\n+++ b/t/t4100/t-apply-1.patch\n@@ -92,7 +92,7 @@ diff --git a/Makefile b/Makefile\n +++ b/Makefile\n @@ -30,7 +30,7 @@ PROG=   git-update-cache git-diff-files \n  \tgit-checkout-cache git-diff-tree git-rev-tree git-ls-files \\\n- \tgit-check-files git-ls-tree git-merge-base git-merge-cache \\\n+ \tgit-check-files git-ls-tree git-find-merge-base git-merge-cache \\\n  \tgit-unpack-file git-export git-diff-cache git-convert-cache \\\n -\tgit-http-pull git-rpush git-rpull git-rev-list git-mktag \\\n +\tgit-http-pull git-ssh-push git-ssh-pull git-rev-list git-mktag \\\ndiff --git a/t/t4100/t-apply-5.patch b/t/t4100/t-apply-5.patch\n--- a/t/t4100/t-apply-5.patch\n+++ b/t/t4100/t-apply-5.patch\n@@ -202,7 +202,7 @@ diff a/Makefile b/Makefile\n +++ b/Makefile\n @@ -30,7 +30,7 @@ PROG=   git-update-cache git-diff-files \n  \tgit-checkout-cache git-diff-tree git-rev-tree git-ls-files \\\n- \tgit-check-files git-ls-tree git-merge-base git-merge-cache \\\n+ \tgit-check-files git-ls-tree git-find-merge-base git-merge-cache \\\n  \tgit-unpack-file git-export git-diff-cache git-convert-cache \\\n -\tgit-http-pull git-rpush git-rpull git-rev-list git-mktag \\\n +\tgit-http-pull git-ssh-push git-ssh-pull git-rev-list git-mktag \\\ndiff --git a/templates/hooks--update b/templates/hooks--update\n--- a/templates/hooks--update\n+++ b/templates/hooks--update\n@@ -15,7 +15,7 @@ then\n \techo \"Created a new ref, with the following commits:\"\n \tgit-rev-list --pretty \"$3\"\n else\n-\t$base=$(git-merge-base \"$2\" \"$3\")\n+\t$base=$(git-find-merge-base \"$2\" \"$3\")\n \tcase \"$base\" in\n \t\"$2\")\n \t\techo \"New commits:\"\n"},{"id":"8353","messageId":"20050912012639.GL15630@pasky.or.cz","threadId":"1748","inReplyTo":"7virxalhqi.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: Post 0.99.7 preperation patches","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-12T01:26:39Z","receivedAt":"2005-09-12T01:26:39Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Sep 09, 2005 at 11:20:53AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Junio C Hamano <junkio@cox.net> writes:\n> \n> > The \"master\" branch post 0.99.6 already has the renamed tools\n> > with backward compatibility symlinks.  I'll be sending a\n> > patch to address an issue raised by some people separately to\n> > see what the list thinks, and also will attempt to send out a\n> > patch for the Pasky and Catalin heads later this week.\n> \n> I've prepared these and will be sending them out separately to\n> you two, hoping they would help you prepare for post 0.99.7\n> changes.  Note that 0.99.6 does not know about these new names,\n> the current \"master\" branch knows about both new and old names,\n> so will 0.99.7, and in 0.99.8 the old names will be removed, if\n> things go as planned.\n> \n> Here is a small script that I used before auditing what it did\n> to your trees by running 'git diff' on its result.\n\nThanks for the notification. I will do an auxiliary release right\nafter 0.99.7 is released.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"8762","messageId":"7vek7n8x1a.fsf@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"7vr7c02zgg.fsf@assigned-by-dhcp.cox.net","subject":"No GIT 0.99.7 today","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-17T16:43:45Z","receivedAt":"2005-09-17T16:43:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was planning to do 0.99.7 today but I need to delay it for a\ncouple of days.  I am expected to be offline for most of today.\n"},{"id":"8815","messageId":"7vwtleyml5.fsf@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"7vr7c02zgg.fsf@assigned-by-dhcp.cox.net","subject":"[ANNOUNCE] GIT 0.99.7","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T23:37:10Z","receivedAt":"2005-09-18T23:37:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I am hoping that sending this out to the kernel list is not\nconsidered too much of useless spamming, but I promise I\nwouldn't do thit next time for 0.99.8, if I hear from somebody\nnot to.\n\nHere comes GIT 0.99.7\n\n--\n\nDone in 0.99.7\n==============\n\nOrganization\n~~~~~~~~~~~~\n\nSome commands and most scripts are renamed for consistency.\n\n  - We have an official standard terminology list [*1*].  To\n    match this, commands that operate on index files now have\n    'index' instead of 'cache' in their names, and ones that\n    download are called 'fetch' instead of 'pull'.\n\n  - We used to install most of the commands that happen to be\n    implemented as scripts as 'git-*-script', which was\n    cumbersome to remember and type unless you always used 'git'\n    wrapper.  They lost '-script' suffix from their names.\n\nFor now, we install synonyms as symbolic links so that old\nnames continue to work, but they are planned to be removed in\n0.99.8 (or later if there are enough objections on the list --\nso far I have heard none).\n\nAlso ancient environment variables [*2*] are not supported\nanymore.\n\n\nNew Features and Commands\n~~~~~~~~~~~~~~~~~~~~~~~~~\n\nDownloaders that are not fully git aware have been taught about\nthe mechanism to borrow objects from other repositories via\nobjects/info/alternates the server side may be using.  'git\nfetch' and 'git pull' commands over rsync and http transport\nshould be able to handle such repositories [*3*].\n\nPeople found interesting cases where the 'stupid' three-way\nmerge mechanism does the wrong thing without noticing.  We have\ntwo new merge algorithms by Daniel and Fredrik that attempt to\ndo better in such cases.  A new 'git merge' command has been\nintroduced to make it easier to experiment with and choose among\ndifferent merge strategies.  Note that 'git pull' still uses the\ntraditional three-way merge after downloading, but it is\nexpected to be switched to use 'git merge' sometime in the\nfuture.\n\nImporting from tla archives has been improved and documentated.\n\n'git branch' command acquired '-d' flag to delete a branch that\nhas already been merged into the current branch.\n\n'git bisect' command is easier to use by logging the earlier\ngood/bad choices and make it replayable.\n\n'git repack' has -a' flag to pack the whole repository into a\nsingle pack.\n\n'git grep' is a new command to run grep on files 'git' knows\nabout.\n\n\nFixes\n~~~~~\n\n* 'git-diff-*' commands used to mark copy/rename incorrectly\n  when an (A,B) => (B,C) rename was made.  We said the new B is\n  a copy of old A, not a rename of old A.\n\n* When the user exported CDPATH into environment, 'cd' took\n  scripts to unexpected places.  Unset it upfront to guard us.\n\n* 'git format-patch' knows about 'git cherry' and skips patches\n  already merged upstream.\n\n* hopefully plugged memory leak in diffcore-rename properly.\n\n* commit walkers incorrectly assumed having a commit means we\n  have the whole history leading up to it -- which is not true\n  if the previous download was interrupted.  As a safety\n  measure, we now only trust the commits that are pointed by the\n  existing refs.\n\n* 'git rev-list' uses a lot less memory.\n\n* The build should be a bit friendlier to Solaris and Darwin now.\n\n* 'git ssh-{push,pull}' are friendlier to tcsh.\n\n* http transport is nicer to caching proxies.\n\n* 'git daemon' port is registered with IANA.\n\n* Many documentation updates.\n\n\n[Footnotes]\n*1* http://www.kernel.org/pub/software/scm/git/docs/glossary.html\n\n*2* Ancient environment variable names: SHA1_FILE_DIRECTORIES\nAUTHOR_DATE AUTHOR_EMAIL AUTHOR_NAME COMMIT_AUTHOR_EMAIL\nCOMMIT_AUTHOR_NAME SHA1_FILE_DIRECTORY\n\n*3* But not grafts.\n"},{"id":"8816","messageId":"7vpsr6ymg3.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"7vwtleyml5.fsf@assigned-by-dhcp.cox.net","subject":"What to expect after GIT 0.99.7","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T23:40:12Z","receivedAt":"2005-09-18T23:40:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The GIT To-Do File\n==================\n\n  The latest copy of this document is found at \n\n    http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO\n\n\nTool Renames Plan\n=================\n\n - All non-binary commands will lose -script suffix in\n   $(bindir).  The source to git-foo will be either git-foo.sh\n   or git-foo.perl in the source tree, and the documentation\n   will be in Documentation/git-foo.txt.\n\n - The commands whose names have 'cache' to mean 'index file'\n   will get 'cache' in their names replaced with 'index'. For\n   git-fsck-cache and git-convert-cache, 'cache' will be\n   replaced with 'objects'.\n\n - The commit walkers will have 'pull' in their names replaced\n   with 'fetch'.  'git-ssh-push' will become 'git-ssh-upload'.\n\n - We continue to follow the convention to name the C source\n   file that contains the main program of 'git-foo' command\n   'foo.c'.  That means we will have 'fsck-objects.c', for\n   example.\n\n - At this moment, I am not planning to rename the symbols used\n   in programs, nor any library sources.  \"cache.h\" will stay\n   \"cache.h\", so does \"read-cache.c\".  \"struct cache_entry\"  and\n   \"ce_match_stat()\" will keep their names.  We _might_ want to\n   rename them in later rounds but not right now.\n\n - In 0.99.7, all renamed commands will have symbolic links in\n   $(bindir) so that old names continue to work.  These backward\n   compatible names will not appear in documentation.  The main\n   documentation, git(7) will talk about the new names but would\n   mention their old names as historical notes.  Old environment\n   names defined in gitenv() will also be removed in this release.\n\n - In 0.99.8, we do not install these backward compatible\n   symbolic links in $(bindir) anymore.  The Makefile will have\n   a target to remove old symlinks from $(DESTDIR)$(bindir) you\n   can run manually to help you clean things up.\n\n   The timeframe for this is around Oct 1st, but I could be\n   talked into delaying the symlink removal if Porcelain people\n   find this schedule too tight.\n\n\nWhat to expect after 0.99.7\n===========================\n\nThis is written in a form of to-do list for me, so if I say\n\"accept patch\", it means I do not currently plan to do that\nmyself.  People interested in seeing it materialize please take\na hint.\n\n\nDocumentation\n-------------\n\n* Accept patches from people who actually have done CVS\n  migration and update the cvs-migration documentation.\n  Link the documentation from the main git.txt page.\n\n* Accept patches from people who were hit by shiny blue bat to\n  update the SubmittingPatches.\n\n* Talk about using rsync just once at the beginning when\n  initializing a remote repository so that local packs do not\n  need to be expanded.  I personally do not think we need tool\n  support for this (but see below about optimized cloning).\n\n* Maybe update tutorial with a toy project that involves two or\n  three developers..\n\n* Update tutorial to cover setting up repository hooks to do\n  common tasks.\n\n* Accept patches to finish missing docs.\n\n\nTechnical (heavier)\n-------------------\n\n* Tony Luck reported an unfortunate glitch in the 3-way merge.\n  Encourage discussions to come up with a not-so-expensive way\n  to catch the kind of ambiguities that led to his misery.\n  [Deathmatch between Daniel's and Fredrik's ongoing.]\n\n* HPA has two projects, klibc and klibc-kbuild, that have large\n  set of overlapping files in different paths (i.e. one has many\n  renames from the other).  There currently is no way for git to\n  help keep these two trees in sync, merging criss-cross between\n  them.  The merge logic should be able to take advantage of\n  rename/copy detection smarts git-diff-* family has.  Linus,\n  me, and Daniel outlined a smarter merge strategy for this.\n  Try them out.\n\n* We might want to optimize cloning with GIT native transport\n  not to explode the pack, and store it in objects/pack instead.\n  We would need a tool to generate an idx file out of a pack\n  file for this.  Also this itself may turn out to be a bad\n  idea, making the set of packs in repositories everybody has\n  different from each other.\n\n* Libification.  There are many places \"run once\" mentality is\n  ingrained in the management of basic data structures, which\n  need to be fixed.\n\n* Maybe a pack optimizer.\n\n* Maybe an Emacs VC backend.\n\n\nTechnical (milder)\n------------------\n\n* The recent commit walker safety patch may be too cautious and\n  appears to take forever when cloning.  This may even be\n  infinitely looping in the code lifted from the old rev-list --\n  needs to be taken a look at [DONE INITIAL CUT].\n\n* Encourage concrete proposals to commit log message templates\n  we discussed some time ago.\n\n* Accept patches for more portability.\n\n  * strcasestr() in mailinfo.  We may need compat/strcasestr.c;\n    this is bugging OpenBSD folks.\n\n* Accept patches to cause \"read-tree -u\" delete a directory when\n  it makes it empty.\n\n* Perhaps accept patches to introduce the concept of \"patch flow\n  expressed as ref mappings\" Josef has been advocating about.\n\n* Perhaps accept patches to do undo/redo.\n\n* Perhaps accept patch to optionally allow '--fuzz' in\n  'git-apply'.\n\n* Allow 'git apply' to accept GNU diff 2.7 output that forgets\n  to say '\\No newline' if both input ends with incomplete\n  lines.\n\n* Maybe grok PGP signed text/plain in applymbox as well.\n\n* Perhaps a tool to revert a single file to pre-modification\n  state?  git-cat-file blob `git-ls-files | grep foo` >foo or\n  git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should\n  the command be called?  git-revert is taken so is\n  git-checkout.\n\n* Enhance \"git repack\" to not always use --all; this would be\n  handy if the repository contains wagging heads like \"pu\" in\n  git.git repository.\n\n* Internally split the project into non-doc and doc parts; add\n  an extra root for the doc part and merge from it; move the\n  internal doc source to a separate repository, like the +Meta\n  repository; experiment if this results in a reasonable\n  workflow, and document it in howto form if it does.\n\n* Make rebase restartable; instead of skipping what cannot be\n  automatically forward ported, leave the conflicts in the work\n  tree, have the user resolve it, and then restart from where it\n  left off.\n\n* Output full path in the \"git-rev-list --objects\" output, not\n  just the basename, and see the improved clustering results in\n  better packing [Tried, but did not work out well].\n\n* Remove obsolete commands [READY].\n\n* Option to limit rename detection for more than N paths [READY].\n\n* Option to show only status and name from diff [READY].\n\n\nTechnical (trivial)\n-------------------\n\n* 'git add --recursive'?\n\n* 'git merge-projects'?\n\n* 'git lost-and-found'?  Link dangling commits found by\n  fsck-objects under $GIT_DIR/refs/lost-found/.  Then\n  show-branch or gitk can be used to find any lost commit. [A\n  feeler patch sent out. Very underwhelming response X-<.]\n\n  Do not name it /lost+found/; that would probably confuse\n  things that mistake it a mount point (not our code but\n  somebody else's).\n\n* Add simple globbing rules to git-show-branch so that I can\n  say 'git show-branch --heads \"ko-*\"' (ko-master, ko-pu, and\n  ko-rc are in refs/tags/).\n\n* We would want test scripts for the relative directory path\n  stuff Linus has been working on.  So far, the following\n  commands should be usable with relative directory paths:\n\n    git-update-index\n    git-ls-files\n    git-diff-files\n    git-diff-index\n    git-diff-tree\n    git-rev-list\n    git-rev-parse\n\n* In a freashly created empty repository, `git fetch foo:bar`\n  works OK, but `git checkout bar` afterwards does not (missing\n  `.git/HEAD`).\n"},{"id":"8820","messageId":"20050919011428.GF22391@pasky.or.cz","threadId":"1748","inReplyTo":"7vwtleyml5.fsf@assigned-by-dhcp.cox.net","subject":"[ANNOUNCE] Cogito-0.15","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-19T01:14:28Z","receivedAt":"2005-09-19T01:14:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hello,\n\n  this is the release of Cogito-0.15. It fixes several minor bugs, and\nadds a feature or two. The most important thing though is that this\ndepends on Git-core-0.99.7 and uses the new command names. Everyone is\nencouraged to upgrade at least to this Cogito version in the next few\ndays, since the older Cogito versions likely won't work with the future\nGit-core releases.\n\n  To stay in sync with the Git terminology, Cogito also renames its\ncg-pull to cg-fetch. Since this is a major naming change (I'm not too\nhappy about it, personally), cg-pull will stay aliased to cg-fetch for\nat least one (likely two) next major Cogito releases (it also produces a\nwarning when invoked as cg-pull). In the more distant future, cg-pull\nwill slowly become the new name of cg-update, to make it confusing.\n\n  While at it, we also renamed the *-id scriptlets to cg-*-id. Other\nnotable stuff is cg-init respecting the ignore rules, and better UI for\ncg-add wrt. directories (including cg-add -r support).\n\n  Now let's see what the usual bug-right-after-release (major release,\nso a major bug?) will be this time.\n\n  Happy hacking,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"8821","messageId":"Pine.LNX.4.58.0509181829310.9106@g5.osdl.org","threadId":"1748","inReplyTo":"7vpsr6ymg3.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: What to expect after GIT 0.99.7","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-19T01:30:50Z","receivedAt":"2005-09-19T01:30:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 18 Sep 2005, Junio C Hamano wrote:\n> \n> * Accept patches for more portability.\n> \n>   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;\n>     this is bugging OpenBSD folks.\n\nMaybe something stupid like this?\n\nTotally untested, of course.\n\n\t\tLinus\n---\ndiff-tree 9b2d397a5d03514bdf3f545e459817c48579830f (from 727132834e6be48a93c1bd6458a29d474ce7d5d5)\nAuthor: Linus Torvalds <torvalds@g5.osdl.org>\nDate:   Sun Sep 18 18:29:07 2005 -0700\n\nAdd stupid 'strcasestr()' compat routine\n\nSigned-off-by: Linus Torvalds <torvalds@osdl.org>\n\n---\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -9,6 +9,8 @@\n # Define NO_CURL if you do not have curl installed.  git-http-pull is not\n # built, and you cannot use http:// and https:// transports.\n #\n+# Define NO_STRCASESTR if you don't have strcasestr.\n+#\n # Define PPC_SHA1 environment variable when running make to make use of\n # a bundled SHA1 routine optimized for PowerPC.\n #\n@@ -203,6 +205,10 @@ ifdef NEEDS_NSL\n \tLIBS += -lnsl\n \tSIMPLE_LIB += -lnsl\n endif\n+ifdef NO_STRCASESTR\n+\tDEFINES += -Dstrcasestr=gitstrcasestr\n+\tLIB_OBJS += compat/strcasestr.o\n+endif\n \n DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'\n \ndiff --git a/compat/strcasestr.c b/compat/strcasestr.c\nnew file mode 100644\n--- /dev/null\n+++ b/compat/strcasestr.c\n@@ -0,0 +1,22 @@\n+#include <string.h>\n+\n+char *gitstrcasestr(const char *haystack, const char *needle)\n+{\n+\tint nlen = strlen(needle);\n+\tint hlen = strlen(haystack) - nlen;\n+\tint i;\n+\n+\tfor (i = 0; i < hlen; i++) {\n+\t\tint j;\n+\t\tfor (j = 0; j < nlen; j++) {\n+\t\t\tunsigned char c1 = haystack[i+j];\n+\t\t\tunsigned char c2 = needle[j];\n+\t\t\tif (toupper(c1) != toupper(c2))\n+\t\t\t\tgoto next;\n+\t\t}\n+\t\treturn (char *) haystack + i;\n+\tnext:\n+\t\t;\n+\t}\n+\treturn NULL;\n+}\n"},{"id":"8822","messageId":"Pine.LNX.4.58.0509181902210.9106@g5.osdl.org","threadId":"1748","inReplyTo":"Pine.LNX.4.58.0509181829310.9106@g5.osdl.org","subject":"Re: What to expect after GIT 0.99.7","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-19T02:02:44Z","receivedAt":"2005-09-19T02:02:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 18 Sep 2005, Linus Torvalds wrote:\n> +++ b/compat/strcasestr.c\n> @@ -0,0 +1,22 @@\n> +#include <string.h>\n\nThat should be <ctype.h> of course.\n\n\t\tLinus\n"},{"id":"8824","messageId":"1127096641.9696.44.camel@localhost","threadId":"1748","inReplyTo":"7vwtleyml5.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.7","fromName":"Nigel Cunningham","fromEmail":"ncunningham@cyclades.com","sentAt":"2005-09-19T02:24:01Z","receivedAt":"2005-09-19T02:24:01Z","isPatch":false,"sender":{"key":"ncunningham@cyclades.com","avatar":null},"body":"Hi.\n\nOn Mon, 2005-09-19 at 09:37, Junio C Hamano wrote:\n> I am hoping that sending this out to the kernel list is not\n> considered too much of useless spamming, but I promise I\n> wouldn't do thit next time for 0.99.8, if I hear from somebody\n> not to.\n> \n> Here comes GIT 0.99.7\n\nCould you please include a url for anyone who might not know the\ncanonical address from which to download?\n\nRegards,\n\nNigel\n"},{"id":"8833","messageId":"Pine.LNX.4.60.0509190659160.30739@hermes-1.csi.cam.ac.uk","threadId":"1748","inReplyTo":"7vpsr6ymg3.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: What to expect after GIT 0.99.7","fromName":"Anton Altaparmakov","fromEmail":"aia21@cam.ac.uk","sentAt":"2005-09-19T06:02:34Z","receivedAt":"2005-09-19T06:02:34Z","isPatch":false,"sender":{"key":"aia21@cam.ac.uk","avatar":null},"body":"On Sun, 18 Sep 2005, Junio C Hamano wrote:\n[snip]\n> * Perhaps a tool to revert a single file to pre-modification\n>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or\n>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should\n>   the command be called?  git-revert is taken so is\n>   git-checkout.\n\nHow about git-clean?  (It cleans a \"dirty\" file...\"  IIRC that is what bk \nused to call it so at least some people should be familliar with its name \nthat way.)\n\nBest regards,\n\n\tAnton\n-- \nAnton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)\nUnix Support, Computing Service, University of Cambridge, CB2 3QH, UK\nLinux NTFS maintainer / IRC: #ntfs on irc.freenode.net\nWWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/\n"},{"id":"8835","messageId":"200509190721.57653.alan@chandlerfamily.org.uk","threadId":"1748","inReplyTo":"200509192102.03431.chriswhite@gentoo.org","subject":"Re: [ANNOUNCE] GIT 0.99.7","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2005-09-19T06:21:57Z","receivedAt":"2005-09-19T06:21:57Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Monday 19 Sep 2005 13:01, Chris White wrote:\n> On Monday 19 September 2005 11:24, Nigel Cunningham wrote:\n> > Could you please include a url for anyone who might not know the\n> > canonical address from which to download?\n>\n> http://www.kernel.org/pub/software/scm/git/\n>\n> > Regards,\n> >\n> > Nigel\n>\n> Chris White\n\nRight now there is no tar files, only an rpm\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"8838","messageId":"pan.2005.09.19.07.35.56.960375@smurf.noris.de","threadId":"1748","inReplyTo":"7vpsr6ymg3.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: What to expect after GIT 0.99.7","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-09-19T07:35:59Z","receivedAt":"2005-09-19T07:35:59Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Junio C Hamano wrote:\n\n> * Perhaps a tool to revert a single file to pre-modification\n>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or\n>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should\n>   the command be called?  git-revert is taken so is\n>   git-checkout.\n\ngit-checkout can be extended to accept filenames, which would have the\nadditional benefit of enabling me to get any revision, not just HEAD.\n\nSo can git-reset.\n\nI agree with Anton's \"git clean\"; with an optional -r <commit>\nargument, that would be a better solution.\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nBOFH excuse #396:\n\nMail server hit by UniSpammer.\n"},{"id":"8841","messageId":"7vwtldsbv2.fsf@assigned-by-dhcp.cox.net","threadId":"1748","inReplyTo":"pan.2005.09.19.07.35.56.960375@smurf.noris.de","subject":"Re: What to expect after GIT 0.99.7","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-19T08:25:21Z","receivedAt":"2005-09-19T08:25:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Urlichs <smurf@smurf.noris.de> writes:\n\n> Hi, Junio C Hamano wrote:\n>\n>> * Perhaps a tool to revert a single file to pre-modification\n>>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or\n>>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should\n>>   the command be called?  git-revert is taken so is\n>>   git-checkout.\n>\n> git-checkout can be extended to accept filenames, which would have the\n> additional benefit of enabling me to get any revision, not just HEAD.\n>\n> So can git-reset.\n>\n> I agree with Anton's \"git clean\"; with an optional -r <commit>\n> argument, that would be a better solution.\n\nIt probably is because I am BK untainted, but 'git clean' sounds\nas if it would do 'git-ls-files --others | xargs rm -f'.\n\nI used to do 'cvs update -p foo.c >foo.c', and extending\ngit-checkout may be familiar to cvs migrants.  The most\nroundabout way (albeit with perhaps least typing) is:\n\n    git-tar-tree HEAD | tar xf - foo.c\n\nI originally talked about reverting file(s) in the working tree,\nbut I wonder if reverting a cache (eh, index) entry to the state\nin a committed tree is useful.  read-tree with a pathspec to\noverwrite index entries for specified paths while leaving others\nintact.  We could think of it as undoing git-update-index.\n"},{"id":"8843","messageId":"20050919083650.GA22269@pasky.or.cz","threadId":"1748","inReplyTo":"7vwtldsbv2.fsf@assigned-by-dhcp.cox.net","subject":"Re: What to expect after GIT 0.99.7","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-19T08:36:50Z","receivedAt":"2005-09-19T08:36:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Sep 19, 2005 at 10:25:21AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Matthias Urlichs <smurf@smurf.noris.de> writes:\n> \n> > Hi, Junio C Hamano wrote:\n> >\n> >> * Perhaps a tool to revert a single file to pre-modification\n> >>   state?  git-cat-file blob `git-ls-files | grep foo` >foo or\n> >>   git-cat-file blob `git-ls-tree HEAD foo` >foo?  What should\n> >>   the command be called?  git-revert is taken so is\n> >>   git-checkout.\n> >\n> > git-checkout can be extended to accept filenames, which would have the\n> > additional benefit of enabling me to get any revision, not just HEAD.\n> >\n> > So can git-reset.\n> >\n> > I agree with Anton's \"git clean\"; with an optional -r <commit>\n> > argument, that would be a better solution.\n> \n> It probably is because I am BK untainted, but 'git clean' sounds\n> as if it would do 'git-ls-files --others | xargs rm -f'.\n\nFWIW, that's also what cg-clean does. It uses cg-restore -f filename to\nrestore files to the state of the last commit, but it's not like I'd be\nterribly happy about that.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"8844","messageId":"Pine.LNX.4.63.0509191152260.2519@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1748","inReplyTo":"Pine.LNX.4.58.0509181829310.9106@g5.osdl.org","subject":"Re: What to expect after GIT 0.99.7","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-09-19T09:56:01Z","receivedAt":"2005-09-19T09:56:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 18 Sep 2005, Linus Torvalds wrote:\n\n> On Sun, 18 Sep 2005, Junio C Hamano wrote:\n> > \n> > * Accept patches for more portability.\n> > \n> >   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;\n> >     this is bugging OpenBSD folks.\n> \n> Maybe something stupid like this?\n>\n> [...]\n\nI like it. Git does not need a complicated Boyer-Moore algorithm, because \nthat code path is not time critical.\n\nHowever, I would like it a bit more, if it returned (const char*). After \nall, we do not need to comply with wrong interface definitions.\n\nCiao,\nDscho\n"},{"id":"8827","messageId":"200509192102.03431.chriswhite@gentoo.org","threadId":"1748","inReplyTo":"1127096641.9696.44.camel@localhost","subject":"Re: [ANNOUNCE] GIT 0.99.7","fromName":"Chris White","fromEmail":"chriswhite@gentoo.org","sentAt":"2005-09-19T12:01:55Z","receivedAt":"2005-09-19T12:01:55Z","isPatch":false,"sender":{"key":"chriswhite@gentoo.org","avatar":null},"body":"On Monday 19 September 2005 11:24, Nigel Cunningham wrote:\n\n> Could you please include a url for anyone who might not know the\n> canonical address from which to download?\n\nhttp://www.kernel.org/pub/software/scm/git/\n\n> Regards,\n\n> Nigel\n\nChris White\n"},{"id":"8861","messageId":"85slw1rvne.fsf@riget.hn.org","threadId":"1748","inReplyTo":"Pine.LNX.4.58.0509181829310.9106@g5.osdl.org","subject":"Re: What to expect after GIT 0.99.7","fromName":"Joachim B Haga","fromEmail":"cjhaga@fys.uio.no","sentAt":"2005-09-19T14:15:33Z","receivedAt":"2005-09-19T14:15:33Z","isPatch":false,"sender":{"key":"cjhaga@fys.uio.no","avatar":null},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> >   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;\n> \n> Totally untested, of course.\n>\n> +\tint hlen = strlen(haystack) - nlen;\n\nint hlen = strlen(haystack) - nlen + 1;\n\n(otherwise you'll miss match at the end)\n\n-j.\n"},{"id":"8862","messageId":"Pine.LNX.4.58.0509190727110.9106@g5.osdl.org","threadId":"1748","inReplyTo":"7vwtldsbv2.fsf@assigned-by-dhcp.cox.net","subject":"Re: What to expect after GIT 0.99.7","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-19T14:34:33Z","receivedAt":"2005-09-19T14:34:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Sep 2005, Junio C Hamano wrote:\n> \n> I used to do 'cvs update -p foo.c >foo.c', and extending\n> git-checkout may be familiar to cvs migrants.  The most\n> roundabout way (albeit with perhaps least typing) is:\n> \n>     git-tar-tree HEAD | tar xf - foo.c\n\nUhh.\n\nI use\n\n\tgit-checkout-index -f -u foo.c\n\nwhich works fine. Of course, that doesn't help if you've updated the\nindex, but then I actually think it's fine to expose the index.\n\nNow, admittedly, we should probably make that easier to do.\n\nIf you want to reset to the HEAD state _and_ your index is stale, I'd just\nprecede it with a\n\n\tgit reset\n\nand be done. Yes, it will reset your whole index, not just that file, but \nhey, big deal. In practice it works fine.\n\n> I originally talked about reverting file(s) in the working tree,\n> but I wonder if reverting a cache (eh, index) entry to the state\n> in a committed tree is useful.  read-tree with a pathspec to\n> overwrite index entries for specified paths while leaving others\n> intact.  We could think of it as undoing git-update-index.\n\nYes, I think it would be useful to be able to read in just part of the\ntree.\n\n\t\tLinus\n"},{"id":"8870","messageId":"Pine.LNX.4.58.0509190803270.9106@g5.osdl.org","threadId":"1748","inReplyTo":"85slw1rvne.fsf@riget.hn.org","subject":"Re: What to expect after GIT 0.99.7","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-19T15:06:28Z","receivedAt":"2005-09-19T15:06:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Sep 2005, Joachim B Haga wrote:\n>\n> Linus Torvalds <torvalds@osdl.org> writes:\n> \n> > >   * strcasestr() in mailinfo.  We may need compat/strcasestr.c;\n> > \n> > Totally untested, of course.\n> >\n> > +\tint hlen = strlen(haystack) - nlen;\n> \n> int hlen = strlen(haystack) - nlen + 1;\n\nYeah. Duh.\n\n\t\tLinus\n"},{"id":"8917","messageId":"20050919231538.GA4074@elf.ucw.cz","threadId":"1748","inReplyTo":"20050919011428.GF22391@pasky.or.cz","subject":"Re: [ANNOUNCE] Cogito-0.15","fromName":"Pavel Machek","fromEmail":"pavel@suse.cz","sentAt":"2005-09-19T23:15:38Z","receivedAt":"2005-09-19T23:15:38Z","isPatch":false,"sender":{"key":"pavel@suse.cz","avatar":null},"body":"Hi!\n\n>   this is the release of Cogito-0.15. It fixes several minor bugs, and\n> adds a feature or two. The most important thing though is that this\n> depends on Git-core-0.99.7 and uses the new command names. Everyone is\n> encouraged to upgrade at least to this Cogito version in the next few\n> days, since the older Cogito versions likely won't work with the future\n> Git-core releases.\n> \n>   To stay in sync with the Git terminology, Cogito also renames its\n> cg-pull to cg-fetch. Since this is a major naming change (I'm not too\n> happy about it, personally), cg-pull will stay aliased to cg-fetch for\n> at least one (likely two) next major Cogito releases (it also produces a\n> warning when invoked as cg-pull). In the more distant future, cg-pull\n> will slowly become the new name of cg-update, to make it confusing.\n\nCould we keep at least the cg-update name? It is certainly not a\n*pull* because it does update local repository (and tree, too).\n\n\t\t\t\t\t\t\t\tPavel\n-- \nif you have sharp zaurus hardware you don't need... you know my address\n"},{"id":"8930","messageId":"20050920003515.GC13537@pasky.or.cz","threadId":"1748","inReplyTo":"20050919231538.GA4074@elf.ucw.cz","subject":"Re: [ANNOUNCE] Cogito-0.15","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-09-20T00:35:15Z","receivedAt":"2005-09-20T00:35:15Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Tue, Sep 20, 2005 at 01:15:38AM CEST, I got a letter\nwhere Pavel Machek <pavel@suse.cz> told me that...\n> Hi!\n\nHi,\n\n> >   this is the release of Cogito-0.15. It fixes several minor bugs, and\n> > adds a feature or two. The most important thing though is that this\n> > depends on Git-core-0.99.7 and uses the new command names. Everyone is\n> > encouraged to upgrade at least to this Cogito version in the next few\n> > days, since the older Cogito versions likely won't work with the future\n> > Git-core releases.\n> > \n> >   To stay in sync with the Git terminology, Cogito also renames its\n> > cg-pull to cg-fetch. Since this is a major naming change (I'm not too\n> > happy about it, personally), cg-pull will stay aliased to cg-fetch for\n> > at least one (likely two) next major Cogito releases (it also produces a\n> > warning when invoked as cg-pull). In the more distant future, cg-pull\n> > will slowly become the new name of cg-update, to make it confusing.\n> \n> Could we keep at least the cg-update name?\n\nyes, I want to retain it. I'm not 100% decided yet whether to actually\nuse the pull term for anything in Cogito. Previous usage reportedly\nconfused some, the new usage actually confuses me and apparently some\nother people. So I might just avoid the 'pull' term in the future\naltogether. Not decided yet, though, and opinions obviously welcomed.\n\n> It is certainly not a *pull* because it does update local repository\n> (and tree, too).\n\nAIUI, that's what makes it a pull for *cough* some people. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"8936","messageId":"Pine.LNX.4.58.0509191750480.2553@g5.osdl.org","threadId":"1748","inReplyTo":"20050919231538.GA4074@elf.ucw.cz","subject":"Re: [ANNOUNCE] Cogito-0.15","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-20T00:51:48Z","receivedAt":"2005-09-20T00:51:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Sep 2005, Pavel Machek wrote:\n> \n> Could we keep at least the cg-update name? It is certainly not a\n> *pull* because it does update local repository (and tree, too).\n\nThat _is_ what \"pull\" means.\n\n\"fetch\" is the one that only updates the history. A \"pull\" also does a\nmerge and updates the current branch _and_ the currently checked out tree.\n\n\t\tLinus\n"}]}