{"thread":{"id":"10420","subject":"What's cooking in git/spearce.git (topics)","startedAt":"2007-10-22T06:32:22Z","lastAt":"2008-01-22T08:47:44Z","messageCount":168,"participants":["Shawn O. Pearce","Jeff King","Pierre Habouzit","Steffen Prohaska","Junio C Hamano","Linus Torvalds","David Symonds","Scott Parish","Andreas Ericsson","Jakub Narebski","Geert Bosch","Mike Hommey","Theodore Tso","Melchior FRANZ","Johan Herland","Brian Downing","Bill Lear","Jonas Fonseca","Petr Baudis","Miles Bader","Wincent Colaiuta","Johannes Schindelin","Björn Steinbrink","Kristian Høgsberg","Alex Riesen","Nicolas Pitre","J. Bruce Fields","Jan Hudec","David Kastrup","Eric Wong","Johannes Sixt","Miklos Vajna","Peter Baumann"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"56824","messageId":"20071022063222.GS14735@spearce.org","threadId":"10420","inReplyTo":null,"subject":"What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-22T06:32:22Z","receivedAt":"2007-10-22T06:32:22Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* cc/skip (Mon Oct 22 07:49:39 2007 +0200) 9 commits\n - Bisect: add a \"bisect replay\" test case.\n - Bisect: add \"bisect skip\" to the documentation.\n - Bisect: factorise \"bisect_{bad,good,skip}\" into \"bisect_state\".\n - Bisect: factorise some logging into \"bisect_write\".\n - Bisect: factorise \"bisect_write_*\" functions.\n - Bisect: implement \"bisect skip\" to mark untestable revisions.\n - Bisect: fix some white spaces and empty lines breakages.\n - rev-list documentation: add \"--bisect-all\".\n - rev-list: implement --bisect-all\n\nRecently updated to use \"skip\". I haven't had a chance to look at\nthis series so it just parked in pu for now.\n\n* ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit\n + gitweb: Provide title attributes for abbreviated author names.\n\n* lt/rename (Sun Oct 21 16:59:03 2007 -0700) 2 commits\n - Linear-time/space rename logic (exact renames only)\n - Split out \"exact content match\" phase of rename detection\n\nt4001-diff-rename.sh failed while running tests on pu. I'm pretty\nsure its this topic from Linus. Need to look at it further.\n\n* js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit\n - execv_git_cmd(): also try PATH if everything else fails.\n\nI raised a concern about GIT_EXEC_PATH=\"\" making $PATH search before\nthe compiled in path, which is certainly new behavior and I don't\nthink its quite what was intended. Parked in pu until I hear back.\n\n* sp/help-exit0 (Sun Oct 21 14:47:45 2007 -0700) 1 commit\n . \"git help\" and \"git help -a\" shouldn't exit(1) unless they error\n\nBreaks things because \"git\" (no arguments) no exits successful,\nwhich is less than ideal. Only \"git help\" and \"git help branch\"\nshould be exiting successful.\n\n* ja/shorthelp (Sun Oct 21 01:41:41 2007 +0300) 1 commit\n + On error, do not list all commands, but point to --help option\n\nThis I like. We'll see what the list thinks while using next. :)\n\n* db/fetch-pack (Sat Oct 20 16:03:49 2007 -0400) 60 commits\n + Define compat version of mkdtemp for systems lacking it\n + Avoid scary errors about tagged trees/blobs during git-fetch\n + fetch: if not fetching from default remote, ignore default merge\n + Support 'push --dry-run' for http transport\n + Support 'push --dry-run' for rsync transport\n + Fix 'push --all branch...' error handling\n + Fix compilation when NO_CURL is defined\n + Added a test for fetching remote tags when there is not tags.\n + Fix a crash in ls-remote when refspec expands into nothing\n ... and many many more ...\n\nI think this is just about ready to graduate to master. I haven't\nseen any major problems with it since the recent fixes were put in.\nI'd like to see it move over soon as a number of other topics\nare based upon the tip of this topic rather than master itself.\nBut obviously code quality is more important than topic organization.\n\n* js/forkexec (Fri Oct 19 21:48:06 2007 +0200) 74 commits\n + Use the asyncronous function infrastructure to run the content\n filter.\n + Avoid a dup2(2) in apply_filter() - start_command() can do it for\n us.\n + t0021-conversion.sh: Test that the clean filter really cleans\n content.\n + upload-pack: Run rev-list in an asynchronous function.\n + upload-pack: Move the revision walker into a separate function.\n + Use the asyncronous function infrastructure in builtin-fetch-\n pack.c.\n + Add infrastructure to run a function asynchronously.\n + upload-pack: Use start_command() to run pack-objects in\n create_pack_file().\n + Have start_command() create a pipe to read the stderr of the\n child.\n + Use start_comand() in builtin-fetch-pack.c instead of explicit\n fork/exec.\n + Use run_command() to spawn external diff programs instead of\n fork/exec.\n + Use start_command() to run content filters instead of explicit\n fork/exec.\n + Use start_command() in git_connect() instead of explicit\n fork/exec.\n + Change git_connect() to return a struct child_process instead of a\n pid_t.\n ... db/fetch-pack begins here ...\n\nThis looked sane to me and makes it easier for the MinGW port.\nPlus its an overal reduction in code, reusing the run-command\nframework to avoid lots of ugly pipe() and dup2() calls. Its\nparked in next for a while to get some testing but is probably\nfine to move to master in the near future.\n\n* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit\n - Better support AFS hardlinking across object directories\n\nI'd rather rewrite this by putting the temporary files directly into\ntheir final object directory, then hardlinking within that directory.\nThis should work on Coda and AFS, leaving only the FAT filesystem\nas the odd-duck that needs to use rename(). But maybe I'm just\nbeing really paranoid about not allowing an object to be replaced.\n\n* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 62 commits\n - park\n - git-fetch: mega-terse fetch output\n ... db/fetch-pack begins here ...\n\nMuch discussion on the list about this topic. I think we may have\ncome to an agreement about what the output should look like, but\nthis topic doesn't implement that output format. Someone needs to\neither update this topic or rewrite it. Starting from Jeff King's\npatch makes things a lot easier.\n\n* np/progress (Fri Oct 19 01:01:40 2007 -0400) 9 commits\n + Stop displaying \"Pack pack-$ID created.\" during git-gc\n + Teach prune-packed to use the standard progress meter\n + Change 'Deltifying objects' to 'Compressing objects'\n + fix for more minor memory leaks\n + fix const issues with some functions\n + pack-objects.c: fix some global variable abuse and memory leaks\n + pack-objects: no delta possible with only one object in the list\n + cope with multiple line breaks within sideband progress messages\n + more compact progress display\n\nI really like the new progress display that Nico implemented here,\nand also the terser and more user friendly output from git-repack.\nNeeds more time for testing, but its pretty obvious code changes\nand should be able to graduate to master in the near future.\n\n* sp/mergetool (Thu Oct 18 12:25:34 2007 +0200) 3 commits\n + mergetool: avoid misleading message \"Resetting to default...\"\n + mergetool: add support for ECMerge\n + mergetool: use path to mergetool in config var\n mergetool..path\n\nProbably fine for master as-is. I personally don't use mergetool so\nI'd appreciate an Ack from someone who does that these are working\nwell for them.\n\n* jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits\n + t5516: test update of local refs on push\n + send-pack: don't update tracking refs on error\n\nThis probably should graduate to master soon. It just delays\nupdating the tracking refs until after we've made sure all refs\nwere updated. I'll give it a few more days and then likely kick\nit over to master.\n\n* js/rebase (Wed Oct 17 10:31:35 2007 +0100) 1 commit\n + Fixing path quoting in git-rebase\n\nSimple change, but rebase is a key tool. I'll probably give this\na few more days and then kick it over.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\nWaiting to hear if we're doing anything further with this. it was\noriginally created to help \"git stash\" perform a pop, but nobody\nhas come forth with a patch for git-stash that uses this feature.\nI'd like to have a real use for it that actually tests this code\nin a more production setting before it merges to master.\n\n* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit\n - Add color support to git-add--interactive\n\nI'm just parking this here in case anyone wants to pick this up and\ncontinue it further. I described on list to the original author\na number of problems with why this isn't in next yet; the author\nsaid they will need a little bit of time before they can address\nthat list.\n\n* ph/parseopt (Mon Oct 15 23:06:02 2007 +0200) 22 commits\n - Make builtin-pack-refs.c use parse_options.\n - Make builtin-name-rev.c use parse_options.\n - Make builtin-count-objects.c use parse_options.\n - Make builtin-fsck.c use parse_options.\n - Update manpages to reflect new short and long option aliases\n - Make builtin-for-each-ref.c use parse-opts.\n - Make builtin-symbolic-ref.c use parse_options.\n - Make builtin-update-ref.c use parse_options\n - Make builtin-revert.c use parse_options.\n - Make builtin-describe.c use parse_options\n - Make builtin-branch.c use parse_options.\n - Make builtin-mv.c use parse-options\n - Make builtin-rm.c use parse_options.\n - Port builtin-add.c to use the new option parser.\n - parse-options: allow callbacks to take no arguments at all.\n - parse-options: Allow abbreviated options when unambiguous\n - Add shortcuts for very often used options.\n - parse-options: make some arguments optional, add callbacks.\n - Rework make_usage to print the usage message immediately\n - Add tests for parse-options.c\n - parse-options: be able to generate usages automatically\n - Add a simple option parser.\n\nThere's actually a few other commits (3?) missing from the above\nlist that are safely parked away in my tree. I'm most of the way\nthrough reviewing these and have made a few bug fixes and style\nnit corrections in the earlier parts of the series. I'm going to\ntry and finish working through this series tomorrow and then will\nprobably merge it to next.\n\nThe other 3 commits are hanging off to the side as 2 of them are\nfor the top of db/fetch-pack (to port builtin-fetch and friends\nto the new option parser) and the 3rd is a somewhat questionable\nchange due to needing to rename a \"-h\" to a \"-H\". I just got\ntired of rebasing these 3 other commits onto the respective topics.\nI'm waiting for the core option parser (above) to freeze on a commit\nSHA-1 before I deal with these again.\n\n* sp/push-refspec (Sun Oct 14 10:54:45 2007 +0200) 6 commits\n - push, send-pack: use same rules as git-rev-parse to resolve\n refspecs\n - add ref_cmp_full_short() comparing full ref name with a short name\n - push, send-pack: support pushing HEAD to real ref name\n - rev-parse: teach \"git rev-parse --symbolic\" to print the full ref\n name\n - add get_sha1_with_real_ref() returning full name of ref on demand\n - push, send-pack: fix test if remote branch exists for colon-less\n refspec\n\nI've briefly looked at this series and there's reasons why its not\nin next yet. Its actually something that I'm interested in seeing\nfixed as the current behavior of how git-push matches refs on the\nremote side is just plain nuts. I'll look at it further after I\nget ph/parseopt and cc/skip into next.\n\n* jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit\n - git-diff: complain about >=8 consecutive spaces in initial indent\n* jc/nu (Mon Oct 1 19:35:12 2007 -0700) 2 commits\n - PARK a bit more work\n - (PARK) WIP\n\nI inherited these from Junio. No change.\n\n* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits\n + Export rerere() and launch_editor().\n + Introduce entry point add_interactive and add_files_to_cache\n + Enable wt-status to run against non-standard index file.\n + Enable wt-status output to a given FILE pointer.\n\nWaiting on ph/parseopt (above) and other stuff for builtin-commit.\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\nAlso inherited from Junio. No change.\n\n* js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n + rebase: allow starting from a dirty tree.\n + stash: implement \"stash create\"\n\nI actually had the \"dirty work tree stash in rebase\" thing trip on\nme recently and I got a little pissed off about it. The behavior\nwas not what I expected, nor what I wanted, at that particular point\nin time. Actually I wanted git-rebase to stop and *not* attempt\nthe rebase because of the dirty work tree. So I'm not feeling the\n\"auto stash\" love right now.\n\n-- \nShawn.\n"},{"id":"56830","messageId":"20071022065948.GB2737@coredump.intra.peff.net","threadId":"10420","inReplyTo":"20071022063222.GS14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-22T06:59:48Z","receivedAt":"2007-10-22T06:59:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 22, 2007 at 02:32:22AM -0400, Shawn O. Pearce wrote:\n\n> * jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 62 commits\n> - park\n> - git-fetch: mega-terse fetch output\n> ... db/fetch-pack begins here ...\n> \n> Much discussion on the list about this topic. I think we may have\n> come to an agreement about what the output should look like, but\n> this topic doesn't implement that output format. Someone needs to\n> either update this topic or rewrite it. Starting from Jeff King's\n> patch makes things a lot easier.\n\nI will eventually get around to rewriting this (it seems the list\ncomments have died down), but it is much more interesting to play with\nLinus' rename stuff tonight. :) If somebody else wants to take a stab,\nplease go ahead.\n\n-Peff\n"},{"id":"56832","messageId":"20071022071644.GA7290@coredump.intra.peff.net","threadId":"10420","inReplyTo":"20071022063222.GS14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-22T07:16:44Z","receivedAt":"2007-10-22T07:16:44Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 22, 2007 at 02:32:22AM -0400, Shawn O. Pearce wrote:\n\n> * lt/rename (Sun Oct 21 16:59:03 2007 -0700) 2 commits\n> - Linear-time/space rename logic (exact renames only)\n> - Split out \"exact content match\" phase of rename detection\n> \n> t4001-diff-rename.sh failed while running tests on pu. I'm pretty\n> sure its this topic from Linus. Need to look at it further.\n\nHrm, the problem is that it's not favoring basenames anymore. But I\nthink it is because the loop in find_identical_files is inside out. For\nevery source file, it picks the best destination file. But I think we\nwant to do the opposite: for every destination file, pick the best\nsource file. Otherwise, if a non-basename source file is connected with\na particular destination file, we no longer try that destination file\nagain.\n\nPatch is below (please just squash with the one from Linus).\n\ndiff --git a/diffcore-rename.c b/diffcore-rename.c\nindex 05d39db..8881818 100644\n--- a/diffcore-rename.c\n+++ b/diffcore-rename.c\n@@ -252,17 +252,18 @@ static int find_identical_files(struct file_similarity *src,\n {\n \tint renames = 0;\n \tdo {\n-\t\tstruct diff_filespec *one = src->filespec;\n+\t\tstruct diff_filespec *one = dst->filespec;\n \t\tstruct file_similarity *p, *best;\n \t\tint i = 100;\n \n \t\tbest = NULL;\n-\t\tfor (p = dst; p; p = p->next) {\n+\t\tfor (p = src; p; p = p->next) {\n \t\t\tstruct diff_filespec *two = p->filespec;\n \n-\t\t\t/* Already picked as a destination? */\n+\t\t\t/* Already picked as a source? */\n \t\t\tif (!p->src_dst)\n \t\t\t\tcontinue;\n+\n \t\t\t/* False hash collission? */\n \t\t\tif (hashcmp(one->sha1, two->sha1))\n \t\t\t\tcontinue;\n@@ -276,10 +277,10 @@ static int find_identical_files(struct file_similarity *src,\n \t\t}\n \t\tif (best) {\n \t\t\tbest->src_dst = 0;\n-\t\t\trecord_rename_pair(best->index, src->index, MAX_SCORE);\n+\t\t\trecord_rename_pair(dst->index, best->index, MAX_SCORE);\n \t\t\trenames++;\n \t\t}\n-\t} while ((src = src->next) != NULL);\n+\t} while ((dst = dst->next) != NULL);\n \treturn renames;\n }\n \n"},{"id":"56834","messageId":"20071022072450.GB32763@artemis.corp","threadId":"10420","inReplyTo":"20071022063222.GS14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-10-22T07:24:50Z","receivedAt":"2007-10-22T07:24:50Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Oct 22, 2007 at 06:32:22AM +0000, Shawn O. Pearce wrote:\n> * ph/parseopt (Mon Oct 15 23:06:02 2007 +0200) 22 commits\n> - Make builtin-pack-refs.c use parse_options.\n> - Make builtin-name-rev.c use parse_options.\n> - Make builtin-count-objects.c use parse_options.\n> - Make builtin-fsck.c use parse_options.\n> - Update manpages to reflect new short and long option aliases\n> - Make builtin-for-each-ref.c use parse-opts.\n> - Make builtin-symbolic-ref.c use parse_options.\n> - Make builtin-update-ref.c use parse_options\n> - Make builtin-revert.c use parse_options.\n> - Make builtin-describe.c use parse_options\n> - Make builtin-branch.c use parse_options.\n> - Make builtin-mv.c use parse-options\n> - Make builtin-rm.c use parse_options.\n> - Port builtin-add.c to use the new option parser.\n> - parse-options: allow callbacks to take no arguments at all.\n> - parse-options: Allow abbreviated options when unambiguous\n> - Add shortcuts for very often used options.\n> - parse-options: make some arguments optional, add callbacks.\n> - Rework make_usage to print the usage message immediately\n> - Add tests for parse-options.c\n> - parse-options: be able to generate usages automatically\n> - Add a simple option parser.\n>\n> There's actually a few other commits (3?) missing from the above\n> list that are safely parked away in my tree. I'm most of the way\n> through reviewing these and have made a few bug fixes and style\n> nit corrections in the earlier parts of the series. I'm going to\n> try and finish working through this series tomorrow and then will\n> probably merge it to next.\n\n\n> The other 3 commits are hanging off to the side as 2 of them are\n> for the top of db/fetch-pack (to port builtin-fetch and friends\n> to the new option parser) and the 3rd is a somewhat questionable\n> change due to needing to rename a \"-h\" to a \"-H\". I just got\n> tired of rebasing these 3 other commits onto the respective topics.\n> I'm waiting for the core option parser (above) to freeze on a commit\n> SHA-1 before I deal with these again.\n\n You also can ask me to resubmit them when the first round of parseopt\nis merged. I'm actually waiting for that before I work on it again\n(that's not the sole reason, $work ate my time as well, so I'm not\npressuring ;P) and I can send those again when things are more ready for\nthem.\n\n Like I said to you on IRC, I intend to hack a way to ask parse-options\nto dump its options in a machine parseable way, to help {z,ba}sh\ncompletions authors. And obviously I intend to migrate even more\nbuiltins :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"56891","messageId":"C711793E-BBA0-4AB5-84A7-D37555F80676@zib.de","threadId":"10420","inReplyTo":"20071022063222.GS14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-22T15:27:17Z","receivedAt":"2007-10-22T15:27:17Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 22, 2007, at 8:32 AM, Shawn O. Pearce wrote:\n\n> * sp/push-refspec (Sun Oct 14 10:54:45 2007 +0200) 6 commits\n> - push, send-pack: use same rules as git-rev-parse to resolve\n> refspecs\n> - add ref_cmp_full_short() comparing full ref name with a short name\n> - push, send-pack: support pushing HEAD to real ref name\n> - rev-parse: teach \"git rev-parse --symbolic\" to print the full ref\n> name\n> - add get_sha1_with_real_ref() returning full name of ref on demand\n> - push, send-pack: fix test if remote branch exists for colon-less\n> refspec\n>\n> I've briefly looked at this series and there's reasons why its not\n> in next yet.\n\nIt's not ready for next. Especially the last patch in the list\nchanges the existing behaviour in a way that might be unexpected\nby longtime git users. And maybe we even need for the 1.6 cycle\nbefore we can change the behaviour of git push.\n\n\n> Its actually something that I'm interested in seeing\n> fixed as the current behavior of how git-push matches refs on the\n> remote side is just plain nuts. I'll look at it further after I\n> get ph/parseopt and cc/skip into next.\n\nI planned to draw a conclusion from the discussion in\n\nhttp://marc.info/?l=git&m=119286893014690&w=2\n\nand send an updated proposal based on what I learnt. But\nunfortunately I didn't have time yet.\n\nMy impression now is that the details of the behaviour of \"git\npush\" are hard to understand and should be made more explicit.\n\nRelated tasks are currently encoded in the refspecs, but the\ndetails are not always obvious right away:\n- creation of new branches on the remote side.\n- deletion of branches on the remote side.\n- pushing of branches matching on local and remote side.\n- pushing local branches explicitly to a different ref on the remote.\n- save newbies from pushing to 'non-standard' location, that\n is only push to heads and tags.\n- but also allow to push to funny refs if you force git to\n do this.\n\nAll this is related to the topic above, although its maybe too much\nto be solved at once.\n\n\tSteffen\n"},{"id":"56936","messageId":"7vy7du8vv7.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"20071022063222.GS14735@spearce.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-23T01:26:04Z","receivedAt":"2007-10-23T01:26:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks for keeping the git list running smoothly while I was away.\n\nI've pulled the four integration branches from you, and split\nout the topic branches out of next and pu so that I can take a\nlook at them individually. I haven't looked at the actual\nchanges yet (but I do not have to, as long as I can trust\ncapable others), and only skimmed the list messages (about 2200\nof them since I left).\n\ngit.git at k.org and alt-git.git at repo.or.cz should be in sync\nwith you now. I'll take a look at the recent changes after\ngrabbing some sleep ;-)\n"},{"id":"56942","messageId":"alpine.LFD.0.999.0710221930330.30120@woody.linux-foundation.org","threadId":"10420","inReplyTo":"20071022071644.GA7290@coredump.intra.peff.net","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-23T02:32:02Z","receivedAt":"2007-10-23T02:32:02Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nSorry, I missed this while being busy hacking and not reading email ;)\n\nOn Mon, 22 Oct 2007, Jeff King wrote:\n> \n> Patch is below (please just squash with the one from Linus).\n\nYour patch is better than what used to be there, but\n\n> -\t\t\t/* Already picked as a destination? */\n> +\t\t\t/* Already picked as a source? */\n> \t\t\tif (!p->src_dst)\n> \t\t\t\tcontinue;\n\nthe above is wrong, the whole thing should be dropped (we *want* to be \nable to re-use sources).\n\nAnyway, the set of fixes I sent out earlier included fixing that stupid \nloop as one of the things.\n\n\t\tLinus\n"},{"id":"56943","messageId":"20071023033454.GW14735@spearce.org","threadId":"10420","inReplyTo":"7vy7du8vv7.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-23T03:34:54Z","receivedAt":"2007-10-23T03:34:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Thanks for keeping the git list running smoothly while I was away.\n\nFunny thing. There's this tool called \"git\" that makes it really\neasy to fork a project, apply patches straight from email, and\nrepublish it for others to read and work on top of. You should\ncheck it out sometime. :-)\n \n> I've pulled the four integration branches from you, and split\n> out the topic branches out of next and pu so that I can take a\n> look at them individually. I haven't looked at the actual\n> changes yet (but I do not have to, as long as I can trust\n> capable others), and only skimmed the list messages (about 2200\n> of them since I left).\n> \n> git.git at k.org and alt-git.git at repo.or.cz should be in sync\n> with you now. I'll take a look at the recent changes after\n> grabbing some sleep ;-)\n\nWe're glad to have you back. Or should I say _I'm_ glad to have\nyou back. Never underestimate a man until you've at least walked\na week in his shoes. :-)\n\nMost of the patches that happened while you were away were merged\nor parked into my git/spearce.git work (in large part thanks\nto Lars Hjemli's work during the first week you were offline).\nSo hopefully you can just pickup from \"recent history\" (e.g. today\nforward) and if we missed anything really interesting authors can\nrepost once you've had a chance to get caught up.\n\n-- \nShawn.\n"},{"id":"56944","messageId":"20071023034830.GA28280@coredump.intra.peff.net","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0710221930330.30120@woody.linux-foundation.org","subject":"Re: What's cooking in git/spearce.git (topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-23T03:48:30Z","receivedAt":"2007-10-23T03:48:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Oct 22, 2007 at 07:32:02PM -0700, Linus Torvalds wrote:\n\n> Your patch is better than what used to be there, but\n> \n> > -\t\t\t/* Already picked as a destination? */\n> > +\t\t\t/* Already picked as a source? */\n> > \t\t\tif (!p->src_dst)\n> > \t\t\t\tcontinue;\n> \n> the above is wrong, the whole thing should be dropped (we *want* to be \n> able to re-use sources).\n\nOops, you're right. I'm not sure what I was thinking.\n\n> Anyway, the set of fixes I sent out earlier included fixing that stupid \n> loop as one of the things.\n\nLooks like you have made some real progress. I'll try to review your\npatch tonight, and hopefully make some progress on the inexact case.\n\n-Peff\n"},{"id":"57078","messageId":"7vzly84qwf.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"20071022063222.GS14735@spearce.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-10-24T12:51:28Z","receivedAt":"2007-10-24T12:51:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thanks to Shawn who was a terrific interim maintainer while I\nwas away, there are quite a few new topics in 'pu'. The ones in\n'next' look safe enough to me, and may graduate to 'master' by\nthe end of the month. We'll see.\n\nHere are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* cc/skip (Mon Oct 22 07:49:39 2007 +0200) 9 commits\n - Bisect: add a \"bisect replay\" test case.\n - Bisect: add \"bisect skip\" to the documentation.\n - Bisect: refactor \"bisect_{bad,good,skip}\" into \"bisect_state\".\n - Bisect: refactor some logging into \"bisect_write\".\n - Bisect: refactor \"bisect_write_*\" functions.\n - Bisect: implement \"bisect skip\" to mark untestable revisions.\n - Bisect: fix some white spaces and empty lines breakages.\n - rev-list documentation: add \"--bisect-all\".\n - rev-list: implement --bisect-all\n\nStill \"just parked\" as Shawn described, but three patches were\nreplaced and as a result the series has a single liner fix since\nthe last \"What's cooking\".\n\n* ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit\n + gitweb: Provide title attributes for abbreviated author names.\n\n* lt/rename (Mon Oct 22 10:29:16 2007 -0700) 2 commits\n - Linear-time/space rename logic (exact renames only)\n - Split out \"exact content match\" phase of rename detection\n\nThe tip commit has been replaced with a new one (actually,\nsquash of a few commits) since Shawn's announcement and now\nt4001 passes.\n\n* js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit\n - execv_git_cmd(): also try PATH if everything else fails.\n\nI do not quite get why this is needed; need to go back to the\ndiscussion myself. On the other hand, I found the alternative\napproach suggested on the list very interesting (i.e. instead of\n\"also try\", just letting exec*p use PATH, relying on the fact\nthat we do prepend-to-path anyway). What happened to it? Was\nthere a downside?\n\n* ja/shorthelp (Sun Oct 21 01:41:41 2007 +0300) 1 commit\n + On error, do not list all commands, but point to --help option\n\nShawn says he likes this, and I tend to agree.\n\n* db/fetch-pack (Sat Oct 20 16:03:49 2007 -0400) 60 commits\n + Define compat version of mkdtemp for systems lacking it\n + Avoid scary errors about tagged trees/blobs during git-fetch\n + fetch: if not fetching from default remote, ignore default merge\n + Support 'push --dry-run' for http transport\n + Support 'push --dry-run' for rsync transport\n + Fix 'push --all branch...' error handling\n + Fix compilation when NO_CURL is defined\n + Added a test for fetching remote tags when there is not tags.\n + Fix a crash in ls-remote when refspec expands into nothing\n ...\n\nThis has been cooking forever in git timescale. Judging from\nthe type of fixes going in, I can see people are using this in\nproduction and the topic is not terribly broken.\n\n* js/forkexec (Fri Oct 19 21:48:06 2007 +0200) 74 commits\n + Use the asyncronous function infrastructure to run the content\n filter.\n + Avoid a dup2(2) in apply_filter() - start_command() can do it for\n us.\n + t0021-conversion.sh: Test that the clean filter really cleans\n content.\n + upload-pack: Run rev-list in an asynchronous function.\n + upload-pack: Move the revision walker into a separate function.\n + Use the asyncronous function infrastructure in builtin-fetch-\n pack.c.\n + Add infrastructure to run a function asynchronously.\n + upload-pack: Use start_command() to run pack-objects in\n create_pack_file().\n + Have start_command() create a pipe to read the stderr of the\n child.\n + Use start_comand() in builtin-fetch-pack.c instead of explicit\n fork/exec.\n + Use run_command() to spawn external diff programs instead of\n fork/exec.\n + Use start_command() to run content filters instead of explicit\n fork/exec.\n + Use start_command() in git_connect() instead of explicit\n fork/exec.\n + Change git_connect() to return a struct child_process instead of a\n pid_t.\n\nGave a cursory look at a few of the patches but they all looked\nfine.\n\n* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit\n - Better support AFS hardlinking across object directories\n\nI share Shawn's concern of breaking the \"never replace existing\nobject\" security. Will probably drop this patch in the current\nshape.\n\n* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 62 commits\n - park\n - git-fetch: mega-terse fetch output\n\nHaven't caught up with the output format discussion. Hopefully\nsomebody will implement the list concensus and resend a\nreplacement patch, at which time I can drop these two before\nlooking at these two patches ;-).\n\n* np/progress (Fri Oct 19 01:01:40 2007 -0400) 9 commits\n + Stop displaying \"Pack pack-$ID created.\" during git-gc\n + Teach prune-packed to use the standard progress meter\n + Change 'Deltifying objects' to 'Compressing objects'\n + fix for more minor memory leaks\n + fix const issues with some functions\n + pack-objects.c: fix some global variable abuse and memory leaks\n + pack-objects: no delta possible with only one object in the list\n + cope with multiple line breaks within sideband progress messages\n + more compact progress display\n\n\"Compressing objects\" caught my eye, but it all makes sense.\n\n* sp/mergetool (Thu Oct 18 12:25:34 2007 +0200) 3 commits\n + mergetool: avoid misleading message \"Resetting to default...\"\n + mergetool: add support for ECMerge\n + mergetool: use path to mergetool in config var\n mergetool..path\n\n* jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits\n + t5516: test update of local refs on push\n + send-pack: don't update tracking refs on error\n\n* js/rebase (Wed Oct 17 10:31:35 2007 +0100) 1 commit\n + Fixing path quoting in git-rebase\n\nI have a feeling that this should have forked off of 'maint'.\nThe change looks obvious and trivial, so perhaps after getting a\ntestcase (hint, hint) merge to 'master' and then cherry-pick to\n'maint' as well.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\nObviously this was meant for git-stash, but I am not sure if\nallowing to drop reflog entries in the middle is a good idea in\ngeneral. If we are going to change the UI and the end-user view\nfor stash _anyway_, we may be better off reimplementing stash as\nseparate, numbered and/or named refs (e.g. refs/stash/stash-$n).\n\n* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n + rebase: allow starting from a dirty tree.\n + stash: implement \"stash create\"\n\nAs I already said earlier, I do not think unstashing always on\ntop of rebased state is the right thing to do anyway, we would\nwant to change the behaviour of the tip one, but the question is\nhow.\n\n* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit\n - Add color support to git-add--interactive\n\n* jc/revert-merge (Tue Oct 23 13:33:26 2007 -0700) 1 commit\n - revert/cherry-pick: work on merge commits as well\n\nAllowing to revert/cherry-pick a merge commit. I got my first\nexposure to the new option parser because I had to adjust to the\nnew \"--mainline\" option. The option is supposed to take positive\ninteger as a value but I left it as a generic OPT_INTEGER for\nnow and as a result you may get funny error messages if you give\nnonsense input.\n\n* ph/parseopt (Mon Oct 15 23:06:02 2007 +0200) 22 commits\n - Make builtin-pack-refs.c use parse_options.\n - Make builtin-name-rev.c use parse_options.\n - Make builtin-count-objects.c use parse_options.\n - Make builtin-fsck.c use parse_options.\n - Update manpages to reflect new short and long option aliases\n - Make builtin-for-each-ref.c use parse-opts.\n - Make builtin-symbolic-ref.c use parse_options.\n - Make builtin-update-ref.c use parse_options\n - Make builtin-revert.c use parse_options.\n - Make builtin-describe.c use parse_options\n - Make builtin-branch.c use parse_options.\n - Make builtin-mv.c use parse-options\n - Make builtin-rm.c use parse_options.\n - Port builtin-add.c to use the new option parser.\n - parse-options: allow callbacks to take no arguments at all.\n - parse-options: Allow abbreviated options when unambiguous\n - Add shortcuts for very often used options.\n - parse-options: make some arguments optional, add callbacks.\n - Rework make_usage to print the usage message immediately\n - Add tests for parse-options.c\n - parse-options: be able to generate usages automatically\n - Add a simple option parser.\n\n* sp/push-refspec (Sun Oct 14 10:54:45 2007 +0200) 6 commits\n - push, send-pack: use same rules as git-rev-parse to resolve\n refspecs\n - add ref_cmp_full_short() comparing full ref name with a short name\n - push, send-pack: support pushing HEAD to real ref name\n - rev-parse: teach \"git rev-parse --symbolic\" to print the full ref\n name\n - add get_sha1_with_real_ref() returning full name of ref on demand\n - push, send-pack: fix test if remote branch exists for colon-less\n refspec\n\n* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits\n + Export rerere() and launch_editor().\n + Introduce entry point add_interactive and add_files_to_cache\n + Enable wt-status to run against non-standard index file.\n + Enable wt-status output to a given FILE pointer.\n\n* jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit\n - git-diff: complain about >=8 consecutive spaces in initial indent\n* jc/nu (Mon Oct 1 19:35:12 2007 -0700) 2 commits\n - PARK a bit more work\n - (PARK) WIP\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n"},{"id":"57080","messageId":"ee77f5c20710240609p19086fach8767f0d49a1d381@mail.gmail.com","threadId":"10420","inReplyTo":"7vzly84qwf.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-10-24T13:09:16Z","receivedAt":"2007-10-24T13:09:16Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On 10/24/07, Junio C Hamano wrote:\n>\n> * ds/gitweb (Mon Oct 22 10:28:03 2007 +1000) 1 commit\n> + gitweb: Provide title attributes for abbreviated author names.\n\nI was hoping you could include my other two related patches on top of\nthat one, since they clean it up somewhat.\n\n\nDave.\n"},{"id":"57084","messageId":"20071024160852.GA759@srparish.net","threadId":"10420","inReplyTo":"7vzly84qwf.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Scott Parish","fromEmail":"srp@srparish.net","sentAt":"2007-10-24T16:08:52Z","receivedAt":"2007-10-24T16:08:52Z","isPatch":false,"sender":{"key":"srp@srparish.net","avatar":"https://gravatar.com/avatar/870e5b6fc4f710cf4db5684bd9af7f2cee5734b3dab3209b13e00cf64f6c9f0e?d=mp&s=160"},"body":"On Wed, Oct 24, 2007 at 05:51:28AM -0700, Junio C Hamano wrote:\n\n> * js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit\n> - execv_git_cmd(): also try PATH if everything else fails.\n> \n> I do not quite get why this is needed; need to go back to the\n> discussion myself. On the other hand, I found the alternative\n> approach suggested on the list very interesting (i.e. instead of\n> \"also try\", just letting exec*p use PATH, relying on the fact\n> that we do prepend-to-path anyway). What happened to it? Was\n> there a downside?\n\nThe main downside that was raised was MingW compatibility, but\nSchindelin and Sixt both said that it could wait until further\nwork is done porting to MingW.\n\nShould i resend my string of patches? I've seen people numbering\ntheir patches, should i do that as well?\n\nThanks\nsRp\n\n-- \nScott Parish\nhttp://srparish.net/\n"},{"id":"57089","messageId":"471F8EA0.9030902@op5.se","threadId":"10420","inReplyTo":"20071024160852.GA759@srparish.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-24T18:27:44Z","receivedAt":"2007-10-24T18:27:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Scott Parish wrote:\n> On Wed, Oct 24, 2007 at 05:51:28AM -0700, Junio C Hamano wrote:\n> \n>> * js/PATH (Sun Oct 21 22:59:01 2007 +0100) 1 commit\n>> - execv_git_cmd(): also try PATH if everything else fails.\n>>\n>> I do not quite get why this is needed; need to go back to the\n>> discussion myself. On the other hand, I found the alternative\n>> approach suggested on the list very interesting (i.e. instead of\n>> \"also try\", just letting exec*p use PATH, relying on the fact\n>> that we do prepend-to-path anyway). What happened to it? Was\n>> there a downside?\n> \n> The main downside that was raised was MingW compatibility, but\n> Schindelin and Sixt both said that it could wait until further\n> work is done porting to MingW.\n> \n> Should i resend my string of patches? I've seen people numbering\n> their patches, should i do that as well?\n> \n\n'git format-patch -n' will do it for you. I take it you've found\nout about git-send-email already?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57120","messageId":"20071025003533.GD759@srparish.net","threadId":"10420","inReplyTo":"471F8EA0.9030902@op5.se","subject":"Re: What's cooking in git.git (topics)","fromName":"Scott Parish","fromEmail":"srp@srparish.net","sentAt":"2007-10-25T00:35:33Z","receivedAt":"2007-10-25T00:35:33Z","isPatch":false,"sender":{"key":"srp@srparish.net","avatar":"https://gravatar.com/avatar/870e5b6fc4f710cf4db5684bd9af7f2cee5734b3dab3209b13e00cf64f6c9f0e?d=mp&s=160"},"body":"On Wed, Oct 24, 2007 at 08:27:44PM +0200, Andreas Ericsson wrote:\n\n> > Should i resend my string of patches? I've seen people numbering\n> > their patches, should i do that as well?\n> \n> 'git format-patch -n' will do it for you. I take it you've found\n> out about git-send-email already?\n\nI actually hadn't seen either of those. Thanks!\n\nsRp\n\n-- \nScott Parish\nhttp://srparish.net/\n"},{"id":"57784","messageId":"7vmytycykt.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vzly84qwf.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-01T05:41:06Z","receivedAt":"2007-11-01T05:41:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\nI think it is time to plan freezing for 1.5.4 and this list is a\ngood place to start.\n\n* js/forkexec (Fri Oct 19 21:48:06 2007 +0200) 14 commits\n + Use the asyncronous function infrastructure to run the content\n filter.\n + Avoid a dup2(2) in apply_filter() - start_command() can do it for\n us.\n + t0021-conversion.sh: Test that the clean filter really cleans\n content.\n + upload-pack: Run rev-list in an asynchronous function.\n + upload-pack: Move the revision walker into a separate function.\n + Use the asyncronous function infrastructure in builtin-fetch-\n pack.c.\n + Add infrastructure to run a function asynchronously.\n + upload-pack: Use start_command() to run pack-objects in\n create_pack_file().\n + Have start_command() create a pipe to read the stderr of the\n child.\n + Use start_comand() in builtin-fetch-pack.c instead of explicit\n fork/exec.\n + Use run_command() to spawn external diff programs instead of\n fork/exec.\n + Use start_command() to run content filters instead of explicit\n fork/exec.\n + Use start_command() in git_connect() instead of explicit\n fork/exec.\n + Change git_connect() to return a struct child_process instead of a\n pid_t.\n\nI haven't seen anything wrong with this series and we haven't\nheard breakages from people on 'next' who have been running with\nthis for the past ten days. Will merge to 'master'.\n\n* db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits\n - Use built-in send-pack.\n - Build-in send-pack, with an API for other programs to call.\n - Build-in peek-remote, using transport infrastructure.\n - Miscellaneous const changes and utilities\n\nWill be in 'next' soon after reviewing it again; hopefully in\n'master' before 1.5.4.\n\n* ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits\n + Fixed a command line option type for builtin-fsck.c\n + Make builtin-pack-refs.c use parse_options.\n + Make builtin-name-rev.c use parse_options.\n + Make builtin-count-objects.c use parse_options.\n + Make builtin-fsck.c use parse_options.\n + Update manpages to reflect new short and long option aliases\n + Make builtin-for-each-ref.c use parse-opts.\n + Make builtin-symbolic-ref.c use parse_options.\n + Make builtin-update-ref.c use parse_options\n + Make builtin-revert.c use parse_options.\n + Make builtin-describe.c use parse_options\n + Make builtin-branch.c use parse_options.\n + Make builtin-mv.c use parse-options\n + Make builtin-rm.c use parse_options.\n + Port builtin-add.c to use the new option parser.\n + parse-options: allow callbacks to take no arguments at all.\n + parse-options: Allow abbreviated options when unambiguous\n + Add shortcuts for very often used options.\n + parse-options: make some arguments optional, add callbacks.\n + Rework make_usage to print the usage message immediately\n + Add tests for parse-options.c\n + parse-options: be able to generate usages automatically\n + Add a simple option parser.\n\nIt appears 1.5.4 will be, to a certain extent, a \"Let's clean up\nthe internal implementation\" release. This series should become\npart of it. Hopefully will merge to 'master' soon, but I\nhaven't looked this series very closely yet.\n\n* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits\n + Export rerere() and launch_editor().\n + Introduce entry point add_interactive and add_files_to_cache\n + Enable wt-status to run against non-standard index file.\n + Enable wt-status output to a given FILE pointer.\n\nThese four alone do not change anything user visible, as the\nfinal goal of this series which is \"git-commit in C\" is not here\nyet. But with the other topics touching internal API left and\nright that is understandable. Will merge to 'master'.\n\n* sp/help (Sat Oct 27 01:36:55 2007 -0700) 7 commits\n + shell should call the new setup_path() to setup $PATH\n + include $PATH in generating list of commands for \"help -a\"\n + use only the $PATH for exec'ing git commands\n + list_commands(): simplify code by using chdir()\n + \"current_exec_path\" is a misleading name, use \"argv_exec_path\"\n + remove unused/unneeded \"pattern\" argument of list_commands\n + \"git\" returns 1; \"git help\" and \"git help -a\" return 0\n\nWill merge to 'master'.\n\n* sp/mergetool (Thu Oct 18 12:25:34 2007 +0200) 3 commits\n + mergetool: avoid misleading message \"Resetting to default...\"\n + mergetool: add support for ECMerge\n + mergetool: use path to mergetool in config var\n mergetool..path\n\nWill merge to 'master'.\n\n* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n + rebase: allow starting from a dirty tree.\n + stash: implement \"stash create\"\n\nWill revert at least the latter one, but perhaps both, from\n'next'. The traditional behaviour of refusing to work in a\ndirty tree is much safer, as the tool cannot decide where to\nunstash for you.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\nThis by itself is not useful; will stay in 'next' until it is\nused by selective clearing of stash or something else.\n\n* jc/revert-merge (Tue Oct 23 13:33:26 2007 -0700) 1 commit\n + revert/cherry-pick: work on merge commits as well\n\nThis allows cherry-pick and revert to act on a merge commit if\nyou specify which parent to pick the changes from. I think it\nwould probably be handy when the need arises, but I suspect such\na need is felt only occasionally. I haven't heard any comment\non the list since it was posted. I am somewhat tempted to merge\nthis, but I am not in a hurry.\n\n* np/progress (Wed Oct 31 23:57:04 2007 -0400) 17 commits\n . Show total transferred as part of throughput progress display\n - add throughput display to git-push\n - add some copyright notice to the progress display code\n - add throughput display to index-pack\n - add throughput to progress display\n - relax usage of the progress API\n - make struct progress an opaque type\n - prune-packed: don't call display_progress() for every file\n + Stop displaying \"Pack pack-$ID created.\" during git-gc\n + Teach prune-packed to use the standard progress meter\n + Change 'Deltifying objects' to 'Compressing objects'\n + fix for more minor memory leaks\n + fix const issues with some functions\n + pack-objects.c: fix some global variable abuse and memory leaks\n + pack-objects: no delta possible with only one object in the list\n + cope with multiple line breaks within sideband progress messages\n + more compact progress display\n\nThis would give us a good usability enhancement. Will merge the\nfirst half to 'master', cook the rest in 'next' and aim to merge\nthe whole thing before 1.5.4.\n\n* jc/format-patch-encoding (Wed Oct 31 14:55:17 2007 -0700) 1 commit\n - format-patch -s: add MIME encoding header if signer's name\n requires so\n\nTopic appeared today. I think this is a safe and sane\nfix to a real problem. Needs cherry-pick to 'maint'.\n\n* jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit\n - git-diff: complain about >=8 consecutive spaces in initial indent\n\nThis is a counterpart of an earlier patch from J. Bruce Fields\nto change \"git-apply --whitespace\" to make SP{8,} at the\nbeginning of line a whitespace error.\n\nPersonally, I am in favor of the stricter check, but I had to\nreject the \"git-apply\" patch because there was no way to disable\nthe additional check without disabling the existing check for\ntrailing whitespaces. We probably would want to revisit that\none (perhaps with a new option and/or config to selectively\nenable different kinds of whitespace check).\n\n* dz/color-addi (Tue Oct 16 21:42:23 2007 -0400) 1 commit\n - Add color support to git-add--interactive\n\nI am not a big fan of color, and Shawn's \"What's cooking\"\nmentioned issues with the implementation. Will not merge to\n'next'.\n\n* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 6 commits\n - push: teach push to pass --verbose option to transport layer\n - push: teach push to accept --verbose option\n - push: use same rules as git-rev-parse to resolve refspecs\n - add ref_abbrev_matches_full_with_rev_parse_rules() comparing\n abbrev with full ref name\n - rename ref_matches_abbrev() to\n ref_abbrev_matches_full_with_fetch_rules()\n - push: support pushing HEAD to real branch name\n\nI have been meaning to review these again and merge to 'next'\nbut it seems I've been spending more time discussing the ones I\ndid not even pick up for 'pu'. Will try to find time to do so.\n\n* jk/terse-fetch (Fri Oct 19 03:40:57 2007 -0400) 2 commits\n - park\n - git-fetch: mega-terse fetch output\n\nNo change ;-)\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n\nI was hoping that I can work on this series while in Japan, but\nattending funeral and helping others to deal with the fallout\nsucked all my energy and time. This is still a wip and not\nprogressing.\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\nMy pet project to unify the pathspec handling between tree-diff\nfamily and ls-files family (one side only knows \"in this\ndirectory\" match, and the other knows how to handle fnmatch\nglobs as well). Stalled.\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n . handle renames using similarity engine\n . introduce generic similarity library\n . change hash table calling conventions\n\nAiming for a worthy goal, but not merged to 'pu' yet.\n\n* tf/afs (Fri Oct 19 07:38:16 2007 -0500) 1 commit\n . Better support AFS hardlinking across object directories\n\nWill drop from topic queue. This is labelled as \"AFS hack\", but\nit hacks around a problem AFS has by breaking the safety we had\nfrom very early days of git for everybody else.\n"},{"id":"57799","messageId":"fgcbjr$3pc$1@ger.gmane.org","threadId":"10420","inReplyTo":"7vmytycykt.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-01T11:02:46Z","receivedAt":"2007-11-01T11:02:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n>  + rebase: allow starting from a dirty tree.\n>  + stash: implement \"stash create\"\n> \n> Will revert at least the latter one, but perhaps both, from\n> 'next'.  The traditional behaviour of refusing to work in a\n> dirty tree is much safer, as the tool cannot decide where to\n> unstash for you.\n\nOne of frequently requested features is ability to rebase and merge\nin a dirty tree (CVS-like). Perhaps we should advocate git-stash better,\ne.g. in error message for git-rebase / git-merge / git-pull when in dirty\nstate.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"57846","messageId":"alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org","threadId":"10420","inReplyTo":"7vmytycykt.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-01T18:33:13Z","receivedAt":"2007-11-01T18:33:13Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 31 Oct 2007, Junio C Hamano wrote:\n> \n> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits\n> + ...\n> \n> It appears 1.5.4 will be, to a certain extent, a \"Let's clean up\n> the internal implementation\" release. This series should become\n> part of it. Hopefully will merge to 'master' soon, but I\n> haven't looked this series very closely yet.\n\nI certainly think this should go in, but it does make one deficiency \npainfully clear: the remaining shell scripts end up having all the old \nflags behaviour.\n\nSo while you can combine flags for *most* programs, you still won't \nbe able to say things like\n\n\tgit clean -qdx\n\njust because that's still a shellscript, and doing any fancy argument \nparsing in shell is just painful.\n\nIs somebody still working on doing the shell->C conversion?\n\n\t\tLinus\n"},{"id":"57847","messageId":"916BE4AD-5BD9-48E6-8026-B1AC7387E28D@adacore.com","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Geert Bosch","fromEmail":"bosch@adacore.com","sentAt":"2007-11-01T19:19:50Z","receivedAt":"2007-11-01T19:19:50Z","isPatch":false,"sender":{"key":"bosch@adacore.com","avatar":null},"body":"On Nov 1, 2007, at 14:33, Linus Torvalds wrote:\n> I certainly think this should go in, but it does make one deficiency\n> painfully clear: the remaining shell scripts end up having all the old\n> flags behaviour.\n>\n> So while you can combine flags for *most* programs, you still won't\n> be able to say things like\n>\n> \tgit clean -qdx\n>\n> just because that's still a shellscript, and doing any fancy argument\n> parsing in shell is just painful.\n>\n> Is somebody still working on doing the shell->C conversion?\n\n\nThis is by far the most dangerous command we have at this stage,\nand just too easy to execute by accident. While I now have found\nout that it is possible to set clean.requireForce to disarm the\ncommand, that's the wrong way around. Only experienced users set\nit, and the mere existence of the config item indicates people\ndo get hosed (and lose data) as a result of the poor semantics.\n\nI often type \"make clean\" as well many \"git xyz\" commands\nduring development, and so it happens that at times, I type\n\"git clean\" by accident.\n\nSo, I propose *not* converting git clean to a C builtin,\nbut instead adding --untracked and --ignored options to\ngit-rm.\n\nThis fixes two usability issues:\n 1. data loss due to command typo\n 2. too many git commands\n\nThose who care about \"git clean\" can setup an alias\nto make git clean equal to \"git rm --untracked\"\n\n -Geert\n\nPS. No patch yet, but I wanted to prevent others from spending\n time on builtin git-clean.\n"},{"id":"57854","messageId":"7v4pg5btis.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"916BE4AD-5BD9-48E6-8026-B1AC7387E28D@adacore.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-01T20:27:55Z","receivedAt":"2007-11-01T20:27:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Geert Bosch writes:\n\n> I often type \"make clean\" as well many \"git xyz\" commands\n> during development, and so it happens that at times, I type\n> \"git clean\" by accident.\n\nHappened to me once. I hate that command.\n\n> So, I propose *not* converting git clean to a C builtin,\n> but instead adding --untracked and --ignored options to\n> git-rm.\n\nI think what you are trying to do is to deprecate or remove \"git\nclean\".\n\nI do not know where \"git clean\" came from. I am suspecting that\nit was to give counterparts to some other SCMs, but do not know\nwhich ones. Some people wanted to have it --- so you need to\nconvince them that it is a bad idea first. Adding an equivalent\noptions to \"git rm\" alone does not solve that issue.\n"},{"id":"57859","messageId":"20071101204755.GA15842@glandium.org","threadId":"10420","inReplyTo":"7v4pg5btis.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-11-01T20:47:55Z","receivedAt":"2007-11-01T20:47:55Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:\n> Geert Bosch writes:\n> \n> > I often type \"make clean\" as well many \"git xyz\" commands\n> > during development, and so it happens that at times, I type\n> > \"git clean\" by accident.\n> \n> Happened to me once. I hate that command.\n\nSpeaking of hateful commands, git stash clear is one of them.\nI tend to type git stash clean, which creates a \"clean\" stash...\n \n> > So, I propose *not* converting git clean to a C builtin,\n> > but instead adding --untracked and --ignored options to\n> > git-rm.\n> \n> I think what you are trying to do is to deprecate or remove \"git\n> clean\".\n> \n> I do not know where \"git clean\" came from. I am suspecting that\n> it was to give counterparts to some other SCMs, but do not know\n> which ones. Some people wanted to have it --- so you need to\n> convince them that it is a bad idea first. Adding an equivalent\n> options to \"git rm\" alone does not solve that issue.\n\nWell, they could add an alias, then ;)\n\nMike\n"},{"id":"57860","messageId":"7vr6j9adlt.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"fgcbjr$3pc$1@ger.gmane.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-01T20:57:02Z","receivedAt":"2007-11-01T20:57:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> * jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n>>  + rebase: allow starting from a dirty tree.\n>>  + stash: implement \"stash create\"\n>> \n>> Will revert at least the latter one, but perhaps both, from\n>> 'next'.  The traditional behaviour of refusing to work in a\n>> dirty tree is much safer, as the tool cannot decide where to\n>> unstash for you.\n>\n> One of frequently requested features is ability to rebase and merge\n> in a dirty tree (CVS-like). Perhaps we should advocate git-stash better,\n> e.g. in error message for git-rebase / git-merge / git-pull when in dirty\n> state.\n\nI am of two minds about that. Suggesting to \"stash first, do\nyour thing and unstash\" certainly is helpful than not\nsuggesting. But wanting to do things in a dirty state, only\nbecause CVS did not allow you to do anything else, is a bad\ninertia on the user's side in the first place, and that\nhelpfulness would actively _encourage_ to keep that bad inertia,\ninstead of educating the users to think in git-way.\n"},{"id":"57867","messageId":"DB2DC59C-8580-4AFE-860F-6E7C4A47499E@adacore.com","threadId":"10420","inReplyTo":"7v4pg5btis.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Geert Bosch","fromEmail":"bosch@adacore.com","sentAt":"2007-11-01T21:17:17Z","receivedAt":"2007-11-01T21:17:17Z","isPatch":false,"sender":{"key":"bosch@adacore.com","avatar":null},"body":"\nOn Nov 1, 2007, at 16:27, Junio C Hamano wrote:\n> Geert Bosch writes:\n>> I often type \"make clean\" as well many \"git xyz\" commands\n>> during development, and so it happens that at times, I type\n>> \"git clean\" by accident.\n>\n> Happened to me once. I hate that command.\n>\n>> So, I propose *not* converting git clean to a C builtin,\n>> but instead adding --untracked and --ignored options to\n>> git-rm.\n>\n> I think what you are trying to do is to deprecate or remove \"git\n> clean\".\n\nYes, and in the meantime I'd like to discourage people\nfrom spending time and effort to upgrade it to first\nclass built-in status.\n\n -Geert\n"},{"id":"57868","messageId":"20071101211848.GG2387@thunk.org","threadId":"10420","inReplyTo":"7v4pg5btis.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-11-01T21:18:48Z","receivedAt":"2007-11-01T21:18:48Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:\n> I think what you are trying to do is to deprecate or remove \"git\n> clean\".\n> \n> I do not know where \"git clean\" came from. I am suspecting that\n> it was to give counterparts to some other SCMs, but do not know\n> which ones. Some people wanted to have it --- so you need to\n> convince them that it is a bad idea first. Adding an equivalent\n> options to \"git rm\" alone does not solve that issue.\n\nThere's this great SCM tool called git that we can use to investigate\nthe history of changes.... :-)\n\nLooks like it came from Cogito's cg-clean. No one else has it as far\nas I know, and I agree with others that it's a really not such a great\nidea. Fortunately most of the damage can be mitigated with \"git\nconfig --global clean.requireForce true\", but the newbies won't know\nto do that. \n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"57869","messageId":"7vhck5acj4.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"20071101204755.GA15842@glandium.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-01T21:20:15Z","receivedAt":"2007-11-01T21:20:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:\n> ...\n>> I do not know where \"git clean\" came from. I am suspecting that\n>> it was to give counterparts to some other SCMs, but do not know\n>> which ones. Some people wanted to have it --- so you need to\n>> convince them that it is a bad idea first. Adding an equivalent\n>> options to \"git rm\" alone does not solve that issue.\n>\n> Well, they could add an alias, then ;)\n\nWhy do people talk about forcing different behaviour on existing\nusers before proving that the new behaviour is good for\neverybody, including existing ones?\n\nI am personally very much in favor of removing \"git clean\", but\nhaving many people on the list saying loudly that it is a bad\ncommand is not good enough justification, as people who are\ncontent with the status quo tend to be silent.\n\nThe steps I think is sensible to transition to that goal would\nbe:\n\n - Change clean.requireForce to default to 'true' in the next\n (or one after) version of git, to make 'clean' even safer.\n See if anybody complains (I do not expect any).\n\n - Implement the same functionarity as a new option to \"git rm\",\n which is already in C.\n\n - Do \"git clean\" in C, but sharing the code with \"git rm\"\n implementation above.\n\n - Discuss deprecation and removal of redundant commands. Ship\n a version of git with deprecation and future removal notice.\n Outline how to achieve the same thing as the deprecated\n command used to do (or give convincing argument why what the\n deprecated command used to do was a bad thing and do not\n offer an alternative).\n\n - Wait for a while (6 months to 1 year) and then remove them.\n"},{"id":"57870","messageId":"200711012226.20441@rk-nord.at","threadId":"10420","inReplyTo":"20071101211848.GG2387@thunk.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Melchior FRANZ","fromEmail":"mfranz@aon.at","sentAt":"2007-11-01T21:26:19Z","receivedAt":"2007-11-01T21:26:19Z","isPatch":false,"sender":{"key":"mfranz@aon.at","avatar":null},"body":"* Theodore Tso -- Thursday 01 November 2007:\n> Looks like it came from Cogito's cg-clean. No one else has it as far\n> as I know, [...]\n\nNot built-in. But there are cvs-clean and svn-clean scripts\nfloating around (and part of KDE), which can be quite useful.\nThe svn-clean script prompts the user with the number of files\nit is about to delete, and asks for confirmation.\n\nm.\n"},{"id":"57875","messageId":"200711012232.57286.johan@herland.net","threadId":"10420","inReplyTo":"7v4pg5btis.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2007-11-01T21:32:56Z","receivedAt":"2007-11-01T21:32:56Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Thursday 01 November 2007, Junio C Hamano wrote:\n> Geert Bosch writes:\n> \n> > I often type \"make clean\" as well many \"git xyz\" commands\n> > during development, and so it happens that at times, I type\n> > \"git clean\" by accident.\n> \n> Happened to me once. I hate that command.\n> \n> > So, I propose *not* converting git clean to a C builtin,\n> > but instead adding --untracked and --ignored options to\n> > git-rm.\n> \n> I think what you are trying to do is to deprecate or remove \"git\n> clean\".\n> \n> I do not know where \"git clean\" came from. I am suspecting that\n> it was to give counterparts to some other SCMs, but do not know\n> which ones. Some people wanted to have it --- so you need to\n> convince them that it is a bad idea first. Adding an equivalent\n> options to \"git rm\" alone does not solve that issue.\n\nWhat about making \"git clean\" _stash_ your changes instead of deleting them \n(so that you can undo the clean)? Preferably they should be stashed \nsomewhere _other_ than where \"git stash\" does its thing. \"git clean\" could \neven delete the stash immediately, but keep the reflog around so that \nthe \"clean\" at least could be undone within 30 days (or whatever is the \ncurrent default).\n\nThoughts?\n\n\nHave fun! :)\n\n...Johan\n\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"57878","messageId":"20071101214131.GF4099@lavos.net","threadId":"10420","inReplyTo":"7vmytycykt.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2007-11-01T21:41:31Z","receivedAt":"2007-11-01T21:41:31Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:\n> * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit\n> - git-diff: complain about >=8 consecutive spaces in initial indent\n> \n> This is a counterpart of an earlier patch from J. Bruce Fields\n> to change \"git-apply --whitespace\" to make SP{8,} at the\n> beginning of line a whitespace error.\n> \n> Personally, I am in favor of the stricter check, but I had to\n> reject the \"git-apply\" patch because there was no way to disable\n> the additional check without disabling the existing check for\n> trailing whitespaces. We probably would want to revisit that\n> one (perhaps with a new option and/or config to selectively\n> enable different kinds of whitespace check).\n\nJust to throw in my two cents, I would be strongly opposed to this\ngoing in without some form of configuration to make it work for\nspaces-only-indent projects. I appreciate having whitespace checking,\nand I think trailing whitespace and tabs-following-spaces are obviously\nbad enough that they should always be flagged. But flagging leading\nspaces makes a legitimate and common coding style yield incredibly\nobnoxious-looking diffs.\n\nI don't want to get into another stupid holy war about the superiority\nof indent styles (the last one was quite enough, thank you), but there\nare real projects out there that have a spaces-only-indent policy and\nuse Git, and this change as is isn't good for them.\n\n-bcd\n"},{"id":"57879","messageId":"20071101214257.GB7161@artemis.corp","threadId":"10420","inReplyTo":"7v4pg5btis.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-01T21:42:57Z","receivedAt":"2007-11-01T21:42:57Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote:\n> Geert Bosch writes:\n> \n> > I often type \"make clean\" as well many \"git xyz\" commands\n> > during development, and so it happens that at times, I type\n> > \"git clean\" by accident.\n> \n> Happened to me once. I hate that command.\n> \n> > So, I propose *not* converting git clean to a C builtin,\n> > but instead adding --untracked and --ignored options to\n> > git-rm.\n> \n> I think what you are trying to do is to deprecate or remove \"git\n> clean\".\n> \n> I do not know where \"git clean\" came from. I am suspecting that\n> it was to give counterparts to some other SCMs, but do not know\n> which ones. Some people wanted to have it --- so you need to\n> convince them that it is a bad idea first. Adding an equivalent\n> options to \"git rm\" alone does not solve that issue.\n\n FWIW I do use git clean a _lot_. I don't mind if it's doable from\nanother kind of command, but I do use git clean and even git clean -x a\nlot, because it achives cleansing my repository faster (and sometimes\nfaster) than a `make distclean` would do.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"57880","messageId":"20071101214450.GC7161@artemis.corp","threadId":"10420","inReplyTo":"20071101204755.GA15842@glandium.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-01T21:44:50Z","receivedAt":"2007-11-01T21:44:50Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Nov 01, 2007 at 08:47:55PM +0000, Mike Hommey wrote:\n> On Thu, Nov 01, 2007 at 01:27:55PM -0700, Junio C Hamano wrote:\n> > Geert Bosch writes:\n> > \n> > > I often type \"make clean\" as well many \"git xyz\" commands\n> > > during development, and so it happens that at times, I type\n> > > \"git clean\" by accident.\n> > \n> > Happened to me once. I hate that command.\n> \n> Speaking of hateful commands, git stash clear is one of them.\n> I tend to type git stash clean, which creates a \"clean\" stash...\n\n I agree, the most itching issue is that usually, this action in git is\ncalled `prune'. So it's inconsistant. I would have much prefered that\ngit stash would take its actions as options so that if you mistakenly\ntype a wrong command, the options parsers sees that and fails.\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"57881","messageId":"20071101214623.GD7161@artemis.corp","threadId":"10420","inReplyTo":"20071101214131.GF4099@lavos.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-01T21:46:23Z","receivedAt":"2007-11-01T21:46:23Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Nov 01, 2007 at 09:41:31PM +0000, Brian Downing wrote:\n> On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:\n> > * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit\n> > - git-diff: complain about >=8 consecutive spaces in initial indent\n> > \n> > This is a counterpart of an earlier patch from J. Bruce Fields\n> > to change \"git-apply --whitespace\" to make SP{8,} at the\n> > beginning of line a whitespace error.\n> > \n> > Personally, I am in favor of the stricter check, but I had to\n> > reject the \"git-apply\" patch because there was no way to disable\n> > the additional check without disabling the existing check for\n> > trailing whitespaces. We probably would want to revisit that\n> > one (perhaps with a new option and/or config to selectively\n> > enable different kinds of whitespace check).\n\n> I don't want to get into another stupid holy war about the superiority\n> of indent styles (the last one was quite enough, thank you), but there\n> are real projects out there that have a spaces-only-indent policy and\n> use Git, and this change as is isn't good for them.\n\n Seconded.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"57883","messageId":"7v8x5hab3d.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"200711012232.57286.johan@herland.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-01T21:51:18Z","receivedAt":"2007-11-01T21:51:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> What about making \"git clean\" _stash_ your changes instead of deleting them \n> (so that you can undo the clean)? Preferably they should be stashed \n> somewhere _other_ than where \"git stash\" does its thing. \"git clean\" could \n> even delete the stash immediately, but keep the reflog around so that \n> the \"clean\" at least could be undone within 30 days (or whatever is the \n> current default).\n>\n> Thoughts?\n\nUnthoughts. That does not mesh with the way how world works.\n\n\"git clean\" is about things that git usually do not care about\n(i.e. things not in .gitignore, or even in .gitignore when -x is\ngiven). Everything else including \"git stash\" is all about what\ngit cares about (i.e. tracked paths).\n"},{"id":"57884","messageId":"20071101215738.GE7161@artemis.corp","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-01T21:57:38Z","receivedAt":"2007-11-01T21:57:38Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Thu, Nov 01, 2007 at 06:33:13PM +0000, Linus Torvalds wrote:\n> \n> \n> On Wed, 31 Oct 2007, Junio C Hamano wrote:\n> > \n> > * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits\n> > + ...\n> > \n> > It appears 1.5.4 will be, to a certain extent, a \"Let's clean up\n> > the internal implementation\" release. This series should become\n> > part of it. Hopefully will merge to 'master' soon, but I\n> > haven't looked this series very closely yet.\n> \n> I certainly think this should go in, but it does make one deficiency \n> painfully clear: the remaining shell scripts end up having all the old \n> flags behaviour.\n\n Those are not the only commands with issues: not all builtins are\nmigrated on the new option parser, and those with recursive options (I\nmean the ones that use diff options e.g.) are not migrated yet either,\nbecause the option parser does not supports a mechanism to deal with\nthem.\n\n The issue is not to let parse_option recurse into anoter option\nstructure, it's that if you do so, you want to express the address of\nthe \"options\" to patch in a relative and not absolute way, and I've not\ndecided myself mind about a way to do that yet.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"57885","messageId":"alpine.LFD.0.999.0711011459490.3342@woody.linux-foundation.org","threadId":"10420","inReplyTo":"7v8x5hab3d.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-01T22:05:44Z","receivedAt":"2007-11-01T22:05:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 1 Nov 2007, Junio C Hamano wrote:\n> \n> \"git clean\" is about things that git usually do not care about\n> (i.e. things not in .gitignore, or even in .gitignore when -x is\n> given). Everything else including \"git stash\" is all about what\n> git cares about (i.e. tracked paths).\n\nRight. I *love* \"git clean\". Real men have everything they care about \ntracked by git, and thus by definition \"git clean\" is the safest operation \npossible. I don't understand how anybody can call it \"unsafe\".\n\nI just wish it was quiet by default - right now it takes a _loong_ time to \nclean out your crud just because it scrolls forever talking about all \nthose girly files you don't want to keep - and that it had -x and -d on by \ndefault, so that us *real* men wouldn't have to type so much.\n\nBut making it accept combined options, so that you can do \"git clean -xdq\" \nwould certainly already be a huge improvement.\n\nBut yeah, I guess we could make the \"clean.Imagirlyman\" option (or however \nthe \"please-don't-hurt-me-by-default\" option is spelled) the default. That \nway I'd just feel *extra* manly for immediately disabling it, and laughing \nat you wimps.\n\n\t\t\tLinus\n"},{"id":"57888","messageId":"18218.21166.697179.422630@lisa.zopyra.com","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011459490.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-11-01T22:26:54Z","receivedAt":"2007-11-01T22:26:54Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Thursday, November 1, 2007 at 15:05:44 (-0700) Linus Torvalds writes:\n>...\n>But yeah, I guess we could make the \"clean.Imagirlyman\" option (or however \n>the \"please-don't-hurt-me-by-default\" option is spelled) the default. That \n>way I'd just feel *extra* manly for immediately disabling it, and laughing \n>at you wimps.\n\nPrecisely my sentiments.\n\n\nBill\n"},{"id":"57895","messageId":"7vwst17f7k.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011459490.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-01T22:50:39Z","receivedAt":"2007-11-01T22:50:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> But yeah, I guess we could make the \"clean.Imagirlyman\" option (or however \n> the \"please-don't-hurt-me-by-default\" option is spelled) the default. That \n> way I'd just feel *extra* manly for immediately disabling it, and laughing \n> at you wimps.\n\nThat makes me a girly man, I would guess, as I just suggested\nmaking clean.requireForce default to true in the next (or one\nafter) version of git ;-).\n"},{"id":"57902","messageId":"2c6b72b30711011700t7a9d4027k39e61ac472253cc3@mail.gmail.com","threadId":"10420","inReplyTo":"DB2DC59C-8580-4AFE-860F-6E7C4A47499E@adacore.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2007-11-02T00:00:56Z","receivedAt":"2007-11-02T00:00:56Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"On Nov 1, 2007 10:17 PM, Geert Bosch wrote:\n> On Nov 1, 2007, at 16:27, Junio C Hamano wrote:\n> > I think what you are trying to do is to deprecate or remove \"git\n> > clean\".\n>\n> Yes, and in the meantime I'd like to discourage people\n> from spending time and effort to upgrade it to first\n> class built-in status.\n\nIf you search the archive you will find that a builtin-clean.c has already\nbeen offered.\n\n-- \nJonas Fonseca\n"},{"id":"57903","messageId":"fgdphj$6ga$1@ger.gmane.org","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-02T00:04:03Z","receivedAt":"2007-11-02T00:04:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> On Wed, 31 Oct 2007, Junio C Hamano wrote:\n>> \n>> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits\n>>  + ...\n>> \n>> It appears 1.5.4 will be, to a certain extent, a \"Let's clean up\n>> the internal implementation\" release.  This series should become\n>> part of it.  Hopefully will merge to 'master' soon, but I\n>> haven't looked this series very closely yet.\n> \n> I certainly think this should go in, but it does make one deficiency \n> painfully clear: the remaining shell scripts end up having all the old \n> flags behaviour.\n\nIs 'getopts' bash-ism, or is it in POSIX?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"57907","messageId":"7vmytx7aij.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vhck5acj4.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-02T00:32:04Z","receivedAt":"2007-11-02T00:32:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I am personally very much in favor of removing \"git clean\", but\n> having many people on the list saying loudly that it is a bad\n> command is not good enough justification, as people who are\n> content with the status quo tend to be silent.\n>\n> The steps I think is sensible to transition to that goal would\n> be:\n>\n> - Change clean.requireForce to default to 'true' in the next\n> (or one after) version of git, to make 'clean' even safer.\n> See if anybody complains (I do not expect any).\n>\n> - Implement the same functionarity as a new option to \"git rm\",\n> which is already in C.\n>\n> - Do \"git clean\" in C, but sharing the code with \"git rm\"\n> implementation above.\n>\n> - Discuss deprecation and removal of redundant commands. Ship\n> a version of git with deprecation and future removal notice.\n> Outline how to achieve the same thing as the deprecated\n> command used to do (or give convincing argument why what the\n> deprecated command used to do was a bad thing and do not\n> offer an alternative).\n>\n> - Wait for a while (6 months to 1 year) and then remove them.\n\nAnd this is the first step.\n\n---\n\n Documentation/config.txt | 4 ++--\n git-clean.sh | 6 +++++-\n 2 files changed, 7 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex edf50cd..2144855 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -345,8 +345,8 @@ branch..mergeoptions::\n \tsupported.\n \n clean.requireForce::\n-\tA boolean to make git-clean do nothing unless given -f or -n. Defaults\n-\tto false.\n+\tA boolean to make git-clean do nothing unless given -f\n+\tor -n. Defaults to true.\n \n color.branch::\n \tA boolean to enable/disable color in the output of\ndiff --git a/git-clean.sh b/git-clean.sh\nindex 4491738..f4965b8 100755\n--- a/git-clean.sh\n+++ b/git-clean.sh\n@@ -20,12 +20,16 @@ require_work_tree\n ignored=\n ignoredonly=\n cleandir=\n-disabled=\"`git config --bool clean.requireForce`\"\n rmf=\"rm -f --\"\n rmrf=\"rm -rf --\"\n rm_refuse=\"echo Not removing\"\n echo1=\"echo\"\n \n+# requireForce used to default to false but now it defaults to true.\n+# IOW, lack of explicit \"clean.requireForce = false\" is taken as\n+# \"clean.requireForce = true\".\n+disabled=$(git config --bool clean.requireForce || echo true)\n+\n while test $# != 0\n do\n \tcase \"$1\" in\n"},{"id":"57913","messageId":"20071102021953.GT18279@machine.or.cz","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011459490.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-11-02T02:19:53Z","receivedAt":"2007-11-02T02:19:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Nov 01, 2007 at 03:05:44PM -0700, Linus Torvalds wrote:\n> On Thu, 1 Nov 2007, Junio C Hamano wrote:\n> > \n> > \"git clean\" is about things that git usually do not care about\n> > (i.e. things not in .gitignore, or even in .gitignore when -x is\n> > given). Everything else including \"git stash\" is all about what\n> > git cares about (i.e. tracked paths).\n\nBTW, it comes from Cogito. Pavel Roskin is the author of the original\nCogito script and I'm not sure if it came there from anywhere else or is\nan original \"invention\".\n\n> Right. I *love* \"git clean\". Real men have everything they care about \n> tracked by git, and thus by definition \"git clean\" is the safest operation \n> possible. I don't understand how anybody can call it \"unsafe\".\n\nI agree! If you want to keep anything around in git-tracked tree, tell\ngit about it! (Either marking it as ignored or adding it to the index.)\nI think I wasn't too fond of it originally but now tend to use it a lot\nto keep my trees clean of temporary cruft.\n\n> I just wish it was quiet by default - right now it takes a _loong_ time to \n> clean out your crud just because it scrolls forever talking about all \n> those girly files you don't want to keep - and that it had -x and -d on by \n> default, so that us *real* men wouldn't have to type so much.\n\nI do not agree with either, though. Having it verbose by default makes\nit at least obvious that something potentially, uh, surprising is going\non; and I _prefer_ the non-x behaviour. If I told git that it should\nignore $file, it better not touch it.\n\n> But yeah, I guess we could make the \"clean.Imagirlyman\" option (or however \n> the \"please-don't-hurt-me-by-default\" option is spelled) the default. That \n> way I'd just feel *extra* manly for immediately disabling it, and laughing \n> at you wimps.\n\nYeah!\n\n-- \n\t\t\t\tPetr \"Pasky, laughing at the wimps\" Baudis\nWe don't know who it was that discovered water, but we're pretty sure\nthat it wasn't a fish.\t\t-- Marshall McLuhan\n"},{"id":"57914","messageId":"20071102022335.GU18279@machine.or.cz","threadId":"10420","inReplyTo":"fgdphj$6ga$1@ger.gmane.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-11-02T02:23:35Z","receivedAt":"2007-11-02T02:23:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:\n> Is 'getopts' bash-ism, or is it in POSIX?\n\n\thttp://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html\n\n(Also, most modern distributions have manpage section 1p (3p, ...) with\nthe same contents, so you can check for this stuff pretty easily.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nWe don't know who it was that discovered water, but we're pretty sure\nthat it wasn't a fish.\t\t-- Marshall McLuhan\n"},{"id":"57929","messageId":"buofxzp18qp.fsf@dhapc248.dev.necel.com","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2007-11-02T06:06:54Z","receivedAt":"2007-11-02T06:06:54Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"Linus Torvalds writes:\n> So while you can combine flags for *most* programs, you still won't \n> be able to say things like\n>\n> \tgit clean -qdx\n>\n> just because that's still a shellscript, and doing any fancy argument \n> parsing in shell is just painful.\n\nIndeed... but for my personal shell scripts I like to use a construct\nlike the following for parsing args:\n\n while :; do\n case \"$1\" in\n ... lots of cases to handle normal args ...\n\n -[!-]?*)\n # split concatenated single-letter options apart\n FIRST=\"$1\"; shift\n set -- `echo $FIRST | $SED 's/-\\(.\\)\\(.*\\)/-\\1 -\\2/'` \"$@\"\n ;;\n\n -*)\n # unrecognized option\n unrec_opt \"$1\"; exit 1;;\n *)\n # non-option\n break;\n esac\n done\n\nI'm sure there are problems with it, but it generally seems to work\npretty reasonably for short options.\n\n-Miles\n-- \n97% of everything is grunge\n"},{"id":"57931","messageId":"200711020825.23464.jnareb@gmail.com","threadId":"10420","inReplyTo":"20071102022335.GU18279@machine.or.cz","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-02T07:25:21Z","receivedAt":"2007-11-02T07:25:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis napisał:\n> On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:\n\n>> Is 'getopts' bash-ism, or is it in POSIX?\n> \n> \thttp://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html\n> \n> (Also, most modern distributions have manpage section 1p (3p, ...) with\n> the same contents, so you can check for this stuff pretty easily.)\n\nThanks.\n\nI have just realized however that it doesn't help any (option parser\nnot only for C builtin, but also for shell scripts, Perl scripts and\nPython scripts). First, we (the git development community) do not\nconsider fact that something is in POSIX as indicator that we can use\nthe construct. Second, getopts delas IIRC only with _short_ options.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"57932","messageId":"200711020828.30969.jnareb@gmail.com","threadId":"10420","inReplyTo":"200711020825.23464.jnareb@gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-02T07:28:30Z","receivedAt":"2007-11-02T07:28:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski wrote:\n> Petr Baudis wrote:\n> > On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:\n> \n> >> Is 'getopts' bash-ism, or is it in POSIX?\n> > \n> > \thttp://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html\n> > \n> > (Also, most modern distributions have manpage section 1p (3p, ...) with\n> > the same contents, so you can check for this stuff pretty easily.)\n> \n> Thanks.\n> \n> I have just realized however that it doesn't help any (option parser\n> not only for C builtin, but also for shell scripts, Perl scripts and\n> Python scripts). First, we (the git development community) do not\n> consider fact that something is in POSIX as indicator that we can use\n> the construct. Second, getopts delas IIRC only with _short_ options.\n\nJust a thought:\n http://www.systhread.net/texts/200704optparse.php\n\n-- \nJakub Narebski\nPoland\n"},{"id":"57938","messageId":"20071102084207.GC20200@artemis.corp","threadId":"10420","inReplyTo":"200711020828.30969.jnareb@gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-02T08:42:07Z","receivedAt":"2007-11-02T08:42:07Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Fri, Nov 02, 2007 at 07:28:30AM +0000, Jakub Narebski wrote:\n> Jakub Narebski wrote:\n> > Petr Baudis wrote:\n> > > On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:\n> > \n> > >> Is 'getopts' bash-ism, or is it in POSIX?\n> > > \n> > > \thttp://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html\n> > > \n> > > (Also, most modern distributions have manpage section 1p (3p, ...) with\n> > > the same contents, so you can check for this stuff pretty easily.)\n> > \n> > Thanks.\n> > \n> > I have just realized however that it doesn't help any (option parser\n> > not only for C builtin, but also for shell scripts, Perl scripts and\n> > Python scripts). First, we (the git development community) do not\n> > consider fact that something is in POSIX as indicator that we can use\n> > the construct. Second, getopts delas IIRC only with _short_ options.\n> \n> Just a thought:\n> http://www.systhread.net/texts/200704optparse.php\n\nWell, I'm sure we could probably do the same with our own `git-parseopt`\ntool, couldn't we ?\n\nI'll try to give it a shot, and it'll have all the features shell-script\ncurrently have at great costs of code length (like the lazy way to type\nlong options: -q|--q|--qu|--qui|...)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"57950","messageId":"472AF01F.9030002@op5.se","threadId":"10420","inReplyTo":"alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-02T09:38:39Z","receivedAt":"2007-11-02T09:38:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Linus Torvalds wrote:\n> \n> On Wed, 31 Oct 2007, Junio C Hamano wrote:\n>> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits\n>> + ...\n>>\n>> It appears 1.5.4 will be, to a certain extent, a \"Let's clean up\n>> the internal implementation\" release. This series should become\n>> part of it. Hopefully will merge to 'master' soon, but I\n>> haven't looked this series very closely yet.\n> \n> I certainly think this should go in, but it does make one deficiency \n> painfully clear: the remaining shell scripts end up having all the old \n> flags behaviour.\n> \n> So while you can combine flags for *most* programs, you still won't \n> be able to say things like\n> \n> \tgit clean -qdx\n> \n> just because that's still a shellscript, and doing any fancy argument \n> parsing in shell is just painful.\n> \n> Is somebody still working on doing the shell->C conversion?\n> \n\nMe, although my git work is happening with the speed of continental drift\nat the moment.\n\ngit-merge and git-pull are (slowly) being converted. It's more in the\nnature of a learning experience for me than \"oh shit I need this fast\"\nthough. Hence the blazing speed with which I work ;-)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57951","messageId":"472AF042.5080208@op5.se","threadId":"10420","inReplyTo":"20071101214257.GB7161@artemis.corp","subject":"Re: What's cooking in git.git (topics)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-02T09:39:14Z","receivedAt":"2007-11-02T09:39:14Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Pierre Habouzit wrote:\n> On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote:\n>> Geert Bosch writes:\n>>\n>>> I often type \"make clean\" as well many \"git xyz\" commands\n>>> during development, and so it happens that at times, I type\n>>> \"git clean\" by accident.\n>> Happened to me once. I hate that command.\n>>\n>>> So, I propose *not* converting git clean to a C builtin,\n>>> but instead adding --untracked and --ignored options to\n>>> git-rm.\n>> I think what you are trying to do is to deprecate or remove \"git\n>> clean\".\n>>\n>> I do not know where \"git clean\" came from. I am suspecting that\n>> it was to give counterparts to some other SCMs, but do not know\n>> which ones. Some people wanted to have it --- so you need to\n>> convince them that it is a bad idea first. Adding an equivalent\n>> options to \"git rm\" alone does not solve that issue.\n> \n> FWIW I do use git clean a _lot_. I don't mind if it's doable from\n> another kind of command, but I do use git clean and even git clean -x a\n> lot, because it achives cleansing my repository faster (and sometimes\n> faster) than a `make distclean` would do.\n> \n\nI'm of two minds about this. On the one hand, it's incredibly useful to\nclear out an imported repository where distlcean doesn't quite distclean.\nWe also use it for our autobuild tools (although that's just us being lazy).\n\nOn the other hand, I've been bit by the brain-bug once and done a git clean\nwhen I really meant make clean.\n\nChanging it to the wimpy 'rm -i' equivalent would reduce risk substantially\nwhile maintaining its usefulness, so +1 to Junio's patch, I guess.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"57961","messageId":"87F9D7C1-8E4D-4F74-B514-EF128189CB8A@wincent.com","threadId":"10420","inReplyTo":"20071101214131.GF4099@lavos.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-02T10:26:43Z","receivedAt":"2007-11-02T10:26:43Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 1/11/2007, a las 22:41, Brian Downing escribió:\n\n> On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:\n>> * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit\n>> - git-diff: complain about >=8 consecutive spaces in initial indent\n>>\n>> This is a counterpart of an earlier patch from J. Bruce Fields\n>> to change \"git-apply --whitespace\" to make SP{8,} at the\n>> beginning of line a whitespace error.\n>>\n>> Personally, I am in favor of the stricter check, but I had to\n>> reject the \"git-apply\" patch because there was no way to disable\n>> the additional check without disabling the existing check for\n>> trailing whitespaces. We probably would want to revisit that\n>> one (perhaps with a new option and/or config to selectively\n>> enable different kinds of whitespace check).\n>\n> Just to throw in my two cents, I would be strongly opposed to this\n> going in without some form of configuration to make it work for\n> spaces-only-indent projects.\n\nDitto, I also work on some projects which have a spaces-only policy, \nand the proposed change would be quite painful when working on those \nprojects, so configurability would be very important to me.\n\nCheers,\nWincent\n"},{"id":"57967","messageId":"Pine.LNX.4.64.0711021102380.4362@racer.site","threadId":"10420","inReplyTo":"472AF01F.9030002@op5.se","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-02T11:03:17Z","receivedAt":"2007-11-02T11:03:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Nov 2007, Andreas Ericsson wrote:\n\n> Linus Torvalds wrote:\n> > \n> > On Wed, 31 Oct 2007, Junio C Hamano wrote:\n> > > * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits\n> > > + ...\n> > > \n> > > It appears 1.5.4 will be, to a certain extent, a \"Let's clean up\n> > > the internal implementation\" release. This series should become\n> > > part of it. Hopefully will merge to 'master' soon, but I\n> > > haven't looked this series very closely yet.\n> > \n> > I certainly think this should go in, but it does make one deficiency\n> > painfully clear: the remaining shell scripts end up having all the old\n> > flags behaviour.\n> > \n> > So while you can combine flags for *most* programs, you still won't be able\n> > to say things like\n> > \n> > \tgit clean -qdx\n> > \n> > just because that's still a shellscript, and doing any fancy argument\n> > parsing in shell is just painful.\n> > \n> > Is somebody still working on doing the shell->C conversion?\n> > \n> \n> Me, although my git work is happening with the speed of continental drift\n> at the moment.\n> \n> git-merge and git-pull are (slowly) being converted. It's more in the\n> nature of a learning experience for me than \"oh shit I need this fast\"\n> though. Hence the blazing speed with which I work ;-)\n\nIf you would share what you have on repo.or.cz, others could help at a \nfaster pace, instead of duplicating your work or waiting for you to \nfinish.\n\nCiao,\nDscho\n"},{"id":"57992","messageId":"87d4usaden.fsf@catnip.gol.com","threadId":"10420","inReplyTo":"buofxzp18qp.fsf@dhapc248.dev.necel.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2007-11-02T15:13:36Z","receivedAt":"2007-11-02T15:13:36Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"I previously wrote:\n> Indeed... but for my personal shell scripts I like to use a construct\n> like the following for parsing args:\n\nIn a little more detail, the arg-splitting case:\n\n> -[!-]?*)\n> # split concatenated single-letter options apart\n> FIRST=\"$1\"; shift\n> set -- `echo $FIRST | $SED 's/-\\(.\\)\\(.*\\)/-\\1 -\\2/'` \"$@\"\n> ;;\n\nJust strips off the first short option and stuffs it back into the list\nof args to parse, so \"-xyz\" becomes \"-x -yz\". That way short args get\nsplit by default, but short-args with an appended value still work\ncorrectly.\n\nSo, for instance, if in the above example, \"-y\" takes an argument, then\nthere'd be a switch case case for \"-y*\") which would consume the \"-yz\"\nbefore it reached the arg-splitting case; if \"-y\" _doesn't_ take an\nargument, then \"-yz\" would get split in turn, becoming \"-y -z\".\n\n-Miles\n\n-- \n/\\ /\\\n(^.^)\n(\")\")\n*This is the cute kitty virus, please copy this into your sig so it can spread.\n"},{"id":"58205","messageId":"7vr6j6ve90.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vmytycykt.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-04T04:14:19Z","receivedAt":"2007-11-04T04:14:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"(Note. I haven't dealt with the patch queue from today yet)\n\nHere are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n* cp/p4 (Thu Nov 1 20:43:14 2007 -0700) 2 commits\n + git-p4: Detect changes to executable bit and include them in p4\n submit.\n + git-p4: Add a helper function to parse the full git diff-tree\n output.\n\nI would like to get success stories from p4 users before pushing\nthis out.\n\n* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit\n + cvsexportcommit: Add switch to specify CVS workdir\n\nI would like to get success stories from CVS users before\npushing this out.\n\n* db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits\n + Use built-in send-pack.\n + Build-in send-pack, with an API for other programs to call.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\nLooked Ok. Hopefully will be in 'master' shortly.\n\n* np/fetch (Sat Nov 3 01:32:48 2007 -0400) 1 commit\n + git-fetch: more terse fetch output\n\nWill merge to 'master'.\n\n* jn/gitweb (Sat Nov 3 00:41:20 2007 +0100) 9 commits\n + gitweb: Use config file for repository description and URLs\n + gitweb: Read repo config using 'git config -z -l'\n + gitweb: Add tests for overriding gitweb config with repo config\n + gitweb: Use href(-replay=>1, action=>...) to generate alternate\n views\n + gitweb: Use href(-replay=>1, page=>...) to generate pagination\n links\n + gitweb: Easier adding/changing parameters to current URL\n + gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb\n test\n + gitweb: Add 'status_str' to parse_difftree_raw_line output\n + gitweb: Always set 'from_file' and 'to_file' in\n parse_difftree_raw_line\n\nWill push these out to 'master' over the weekend.\n\n* jc/format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n + test format-patch -s: make sure MIME content type is shown as\n needed\n + format-patch -s: add MIME encoding header if signer's name\n requires so\n\nThis hopefully fixes a real issue we had at vger recently.\n\n\thttp://article.gmane.org/gmane.comp.version-control.git/62689\n\nWill merge to 'master' shortly, and then cherry-pick to 'maint'.\n\n* np/pack (Thu Nov 1 23:43:24 2007 -0400) 2 commits\n + pack-objects: get rid of an ugly cast\n + make the pack index version configurable\n\nWill merge to 'master'.\n\n* ss/mailsplit (Thu Nov 1 23:57:45 2007 +0100) 1 commit\n + Make mailsplit and mailinfo strip whitespace from the start of the\n input\n\nWill merge to 'master'.\n\n* lt/rev-list-replay (Fri Nov 2 13:35:17 2007 -0700) 2 commits\n - Support \"history replay\" for git log commands\n - Simplify topo-sort logic\n\nNeed to drop the second one and replace it with today's \"Final\noutput\" patch. The first one should be mergeable to 'master'\nimmediately and independently.\n\n* dz/color-addi (Mon Oct 22 16:08:01 2007 -0500) 2 commits\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\nFurther comments on minor issues sent back to the author.\n\n* jc/revert-merge (Fri Nov 2 17:25:24 2007 -0700) 2 commits\n + cherry-pick/revert -m: add tests\n + revert/cherry-pick: work on merge commits as well\n\nWill merge to 'master'.\n\n* jc/stash-create (Thu Nov 1 14:30:30 2007 -0700) 4 commits\n + git-merge: no reason to use cpio anymore\n + Revert \"rebase: allow starting from a dirty tree.\"\n + rebase: allow starting from a dirty tree.\n + stash: implement \"stash create\"\n\nDropped the unconditional auto-stash-unstash, but \"stash create\"\nturns out to be a useful alternative to cpio in the git-merge\nimplementation.\n\n* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nI actually like the idea of tying this to gitattributes by J\nBruce Fields. We would want to have such an update before\npushing this out to 'master'. \"diff\" alone would not do any\nharm but \"apply\" can reject and/or munge the user input, and we\nreally would want to get the semantics right with the first\nversion that appears on 'master'.\n\n* kh/commit (Fri Nov 2 11:33:09 2007 -0400) 3 commits\n - Implement git commit and status as a builtin commands.\n - Export launch_editor() and make it accept ':' as a no-op editor.\n - Add testcase for ammending and fixing author in git commit.\n\nThere may be still some glitches left, but it is hopefully\ngettng into a \"testable without breaking things too much\" shape\n(which is the definition of 'next').\n\n* ph/parseopt-sh (Fri Nov 2 23:39:52 2007 +0100) 5 commits\n - Migrate git-am.sh to use git-rev-parse --parseopt\n - Migrate git-clone to use git-rev-parse --parseopt\n - Migrate git-clean.sh to use git-rev-parse --parseopt.\n - Update git-sh-setup(1) to allow transparent use of git-rev-parse -\n -parseopt\n - Add a parseopt mode to git-rev-parse to bring parse-options to\n shell scripts.\n\nTogether with today's batch which is missing from the above\nlist, hopefully merge to 'next' over the weekend.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n - Make git-svn rebase --dirty pass along --dirty to git-rebase.\n - Implement --dirty for git-rebase--interactive.\n - Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nThis needs tests to primarily make sure that it does not regress\nnon --dirty case.\n\n* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 6 commits\n - push: teach push to pass --verbose option to transport layer\n - push: teach push to accept --verbose option\n - push: use same rules as git-rev-parse to resolve refspecs\n - add ref_abbrev_matches_full_with_rev_parse_rules() comparing\n abbrev with full ref name\n - rename ref_matches_abbrev() to\n ref_abbrev_matches_full_with_fetch_rules()\n - push: support pushing HEAD to real branch name\n\nWill need to review first.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n - handle renames using similarity engine\n - introduce generic similarity library\n - change hash table calling conventions\n\nUnchanged.\n"},{"id":"58235","messageId":"fgk476$lha$1@ger.gmane.org","threadId":"10420","inReplyTo":"7vr6j6ve90.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-04T09:43:02Z","receivedAt":"2007-11-04T09:43:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: Junio C Hamano , git @vger.kernel.org]\n\nJunio C Hamano wrote:\n\n> * jn/gitweb (Sat Nov 3 00:41:20 2007 +0100) 9 commits\n\nNow that I have sned those patches ;-) I have a few doubts about them\n\n>  + gitweb: Use config file for repository description and URLs\n>  + gitweb: Read repo config using 'git config -z -l'\n\nI'd like some comments on that series, preferably by someone better \nwith Perl than me, but I think this is a good change performance wise.\n\n>  + gitweb: Add tests for overriding gitweb config with repo config\n\nMore tests is always good.\n\n>  + gitweb: Use href(-replay=>1, action=>...) to generate alternate\n>    views\n>  + gitweb: Use href(-replay=>1, page=>...) to generate pagination\n>    links\n>  + gitweb: Easier adding/changing parameters to current URL\n\nNow I'm not so sure about this, because it changes semantics of \"next page\"\nand alternate view links: after this series they count from current\nversion, not from the displayed version.\n\nBut perhaps those doubts are unnecessary...\n\n>  + gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb\n>    test\n\nThis removes unnecessary code, which can cause mysterious errors.\n\n>  + gitweb: Add 'status_str' to parse_difftree_raw_line output\n>  + gitweb: Always set 'from_file' and 'to_file' in\n>    parse_difftree_raw_line\n\nThis simplifies gitweb code, and I think there aren't any issues with those\npatches.\n \n> Will push these out to 'master' over the weekend.\n\nThanks.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"58249","messageId":"20071104113852.GE26269@artemis.corp","threadId":"10420","inReplyTo":"7vr6j6ve90.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-04T11:38:52Z","receivedAt":"2007-11-04T11:38:52Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Sun, Nov 04, 2007 at 04:14:19AM +0000, Junio C Hamano wrote:\n> * ph/parseopt-sh (Fri Nov 2 23:39:52 2007 +0100) 5 commits\n> - Migrate git-am.sh to use git-rev-parse --parseopt\n> - Migrate git-clone to use git-rev-parse --parseopt\n> - Migrate git-clean.sh to use git-rev-parse --parseopt.\n> - Update git-sh-setup(1) to allow transparent use of git-rev-parse -\n> -parseopt\n> - Add a parseopt mode to git-rev-parse to bring parse-options to\n> shell scripts.\n> \n> Together with today's batch which is missing from the above\n> list, hopefully merge to 'next' over the weekend.\n\n Please note that the last resend has the issues you raised fixed and\nthat it modifies git-clone and git-sh-setup commits from above.\n\n Someone proposed many fixes in the documentation too, I wont do it\nbecause (again) I'm not a native speaker so I let that ungrateful job to\nsomeone actually able to do it.\n\nCheers,\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"58819","messageId":"7vir4d40sw.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vr6j6ve90.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-08T08:08:15Z","receivedAt":"2007-11-08T08:08:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n----------------------------------------------------------------\n[Will merge to 'master' this weekend]\n\n* js/parseopt-abbrev-fix (Mon Nov 5 13:15:21 2007 +0000) 1 commit\n + parse-options: abbreviation engine fix.\n\n* js/reset (Sat Nov 3 15:21:21 2007 +0000) 2 commits\n + builtin-reset: avoid forking \"update-index --refresh\"\n + builtin-reset: do not call \"ls-files --unmerged\"\n\n* js/upload-pack (Sun Nov 4 20:46:48 2007 +0100) 1 commit\n + upload-pack: Use finish_{command,async}() instead of waitpid().\n\n----------------------------------------------------------------\n[Will cook til next week and then merge to 'master']\n\n* bg/format-patch-N (Tue Nov 6 10:04:24 2007 +1100) 3 commits\n + Rearrange git-format-patch synopsis to improve clarity.\n + format-patch: Test --[no-]numbered and format.numbered\n + format-patch: Add configuration and off switch for --numbered\n\n* db/remote-builtin (Tue Nov 6 20:29:20 2007 -0500) 6 commits\n + Reteach builtin-ls-remote to understand remotes\n + Build in ls-remote\n + Use built-in send-pack.\n + Build-in send-pack, with an API for other programs to call.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\n* jc/stash-create (Wed Nov 7 15:10:27 2007 -0600) 5 commits\n + git-stash: Fix listing stashes\n + git-merge: no reason to use cpio anymore\n + Revert \"rebase: allow starting from a dirty tree.\"\n + rebase: allow starting from a dirty tree.\n + stash: implement \"stash create\"\n\n* lt/rev-list-interactive (Mon Nov 5 13:22:34 2007 -0800) 4 commits\n + revision walker: mini clean-up\n + Enhance --early-output format\n + Add \"--early-output\" log flag for interactive GUI use\n + Simplify topo-sort logic\n\n* jk/terse-push (Mon Nov 5 00:12:18 2007 -0500) 6 commits\n + send-pack: require --verbose to show update of tracking refs\n + receive-pack: don't mention successful updates\n + more terse push output\n + Build-in send-pack, with an API for other programs to call.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\n* mh/retag (Sun Nov 4 01:11:15 2007 +0100) 2 commits\n + Add tests for git tag\n + Reuse previous annotation when overwriting a tag\n\n* np/progress (Tue Nov 6 16:30:28 2007 -0500) 6 commits\n + make display of total transferred fully accurate\n + remove dead code from the csum-file interface\n + git-fetch: be even quieter.\n + make display of total transferred more accurate\n + sideband.c: ESC is spelled '\\033' not '\\e' for portability.\n + fix display overlap between remote and local progress\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* ph/parseopt-sh (Wed Nov 7 23:04:38 2007 -0800) 14 commits\n + git-sh-setup: fix parseopt `eval` string underquoting\n + Give git-am back the ability to add Signed-off-by lines.\n + git-rev-parse --parseopt\n + scripts: Add placeholders for OPTIONS_SPEC\n + Migrate git-repack.sh to use git-rev-parse --parseopt\n + Migrate git-quiltimport.sh to use git-rev-parse --parseopt\n + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-\n dashdash\n + Migrate git-instaweb.sh to use git-rev-parse --parseopt\n + Migrate git-merge.sh to use git-rev-parse --parseopt\n + Migrate git-am.sh to use git-rev-parse --parseopt\n + Migrate git-clone to use git-rev-parse --parseopt\n + Migrate git-clean.sh to use git-rev-parse --parseopt.\n + Update git-sh-setup(1) to allow transparent use of git-rev-parse -\n -parseopt\n + Add a parseopt mode to git-rev-parse to bring parse-options to\n shell scripts.\n\nWe are still finding breakages and applying fixes.\n\n* rs/pretty (Wed Nov 7 00:17:14 2007 +0100) 1 commit\n - pretty=format: Avoid some expensive calculations when not needed\n\nThe numbers are impressive and the code is reasonably clean, but\nRené seems to have further improvements to the API?\n\n* sb/clean (Sun Nov 4 13:02:21 2007 -0600) 1 commit\n - Make git-clean a builtin\n\nI ran out of time to look at the replacement patch. Sorry.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n - Make git-svn rebase --dirty pass along --dirty to git-rebase.\n - Implement --dirty for git-rebase--interactive.\n - Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nReally need to look at this series to merge to 'next'. Sorry.\n\n* sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 5 commits\n - push: teach push to pass --verbose option to transport layer\n - push: use same rules as git-rev-parse to resolve refspecs\n - add ref_abbrev_matches_full_with_rev_parse_rules() comparing\n abbrev with full ref name\n - rename ref_matches_abbrev() to\n ref_abbrev_matches_full_with_fetch_rules()\n - push: support pushing HEAD to real branch name\n\nReally need to look at this series to merge to 'next'. Sorry.\n\n----------------------------------------------------------------\n[Stalled]\n\n* bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit\n - git-commit.sh: Fix usage checks regarding paths given when they do\n not make sense\n\nThis is waiting for tests. Then merge to 'next', 'master' and\nthen to 'maint'.\n\n* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n + Add missing inside_work_tree setting in setup_git_directory_gently\n\nThis is waiting for tests. Then merge to 'next', 'master' and\nthen to 'maint'.\n\n* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit\n + cvsexportcommit: Add switch to specify CVS workdir\n\nNeed success stories, but pushing it out to 'master' may be the\nonly way to get users' attention.\n\n* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nRemaining tasks are:\n\n 1. teach \"git-apply --whitespace=[warn|strip]\" the same;\n 2. (possibly) use gitattributes instead of config.\n\n* dz/color-addi (Mon Oct 22 16:08:01 2007 -0500) 2 commits\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\nThere was a RFH to avoid \"require Term::ANSIColor\" in Git.pm and\na suggestion in response to it, but I do not recall\nanything happened afterwards. Stalled.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\nThis does not have a in-tree user yet.\n\n* kh/commit (Fri Nov 2 11:33:09 2007 -0400) 3 commits\n - Implement git commit and status as a builtin commands.\n - Export launch_editor() and make it accept ':' as a no-op editor.\n - Add testcase for ammending and fixing author in git commit.\n\nThis does not pass tests.\n\n* sp/fetch-fix (Tue Nov 6 21:41:18 2007 -0500) 2 commits\n - git-fetch: avoid local fetching from alternate (again)\n - run-command: allow discarding the standard error output\n\nThis does not pass tests (breaks shallow clone deepening).\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n - handle renames using similarity engine\n - introduce generic similarity library\n - change hash table calling conventions\n\nThis does not pass tests.\n\n* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n - test format-patch -s: make sure MIME content type is shown as\n needed\n - format-patch -s: add MIME encoding header if signer's name\n requires so\n\nThis is already in 'master' but rebased for 'maint', just in\ncase we would want a maint release with this series.\n\n* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit\n - git-branch --with=commit\n\nThis was just for fun.\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\nMy pet peeve. Completely stalled.\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n\nSeriously stalled.\n"},{"id":"58933","messageId":"6EB4B3BC-7538-45CF-AEF3-3B3D23DADF0E@zib.de","threadId":"10420","inReplyTo":"7vir4d40sw.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-08T20:44:10Z","receivedAt":"2007-11-08T20:44:10Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 8, 2007, at 9:08 AM, Junio C Hamano wrote:\n\n> * sp/push-refspec (Sun Oct 28 18:46:20 2007 +0100) 5 commits\n> - push: teach push to pass --verbose option to transport layer\n> - push: use same rules as git-rev-parse to resolve refspecs\n> - add ref_abbrev_matches_full_with_rev_parse_rules() comparing\n> abbrev with full ref name\n> - rename ref_matches_abbrev() to\n> ref_abbrev_matches_full_with_fetch_rules()\n> - push: support pushing HEAD to real branch name\n>\n> Really need to look at this series to merge to 'next'. Sorry.\n\nTake your time. There is a slight chance that I'll unify\nref_abbrev_matches_full_with_rev_parse_rules() and \nref_abbrev_matches_full_with_fetch_rules() over the weekend.\n\n\tSteffen\n"},{"id":"59431","messageId":"7vwsso3poo.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vir4d40sw.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-12T07:09:43Z","receivedAt":"2007-11-12T07:09:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n----------------------------------------------------------------\n[Will cook further in 'next' and then merge to 'master' soon]\n\n* rs/pretty (Sat Nov 10 12:55:48 2007 +0100) 6 commits\n + Simplify strchrnul() compat code\n + --format=pretty: avoid calculating expensive expansions twice\n + add strbuf_adddup()\n + --pretty=format: parse commit message only once\n + --pretty=format: on-demand format expansion\n + Add strchrnul()\n\n* np/progress (Thu Nov 8 15:45:41 2007 -0500) 7 commits\n + nicer display of thin pack completion\n + make display of total transferred fully accurate\n + remove dead code from the csum-file interface\n + git-fetch: be even quieter.\n + make display of total transferred more accurate\n + sideband.c: ESC is spelled '\\033' not '\\e' for portability.\n + fix display overlap between remote and local progress\n\n* bg/format-patch-N (Tue Nov 6 10:04:24 2007 +1100) 3 commits\n + Rearrange git-format-patch synopsis to improve clarity.\n + format-patch: Test --[no-]numbered and format.numbered\n + format-patch: Add configuration and off switch for --numbered\n\n* lt/rev-list-interactive (Mon Nov 5 13:22:34 2007 -0800) 4 commits\n + revision walker: mini clean-up\n + Enhance --early-output format\n + Add \"--early-output\" log flag for interactive GUI use\n + Simplify topo-sort logic\n\n* db/remote-builtin (Tue Nov 6 20:29:20 2007 -0500) 6 commits\n + Reteach builtin-ls-remote to understand remotes\n + Build in ls-remote\n + Use built-in send-pack.\n + Build-in send-pack, with an API for other programs to call.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\nWith the \"ls-remote origin\" fix at its tip, this should be\nready.\n\n* jk/terse-push (Thu Nov 8 01:38:12 2007 -0800) 7 commits\n + send-pack: segfault fix on forced push\n + send-pack: require --verbose to show update of tracking refs\n + receive-pack: don't mention successful updates\n + more terse push output\n\nWith the segfault fix at its tip, I think this is ready. This\ndepends on the early parts of db/remote-builtin series.\n\n* jc/stash-create (Wed Nov 7 15:10:27 2007 -0600) 5 commits\n + git-stash: Fix listing stashes\n + git-merge: no reason to use cpio anymore\n + Revert \"rebase: allow starting from a dirty tree.\"\n + rebase: allow starting from a dirty tree.\n + stash: implement \"stash create\"\n\nThe end result of this series is just to remove one use of cpio\nin our scripts; this should be ready.\n\n* gh/cvsimport-user (Thu Nov 8 13:15:20 2007 -0700) 1 commit\n + git-cvsimport: fix handling of user name when it is not set in\n CVSROOT\n\n* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit\n + cvsexportcommit: Add switch to specify CVS workdir\n\n* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits\n + git-checkout: Test for relative path use.\n + git-checkout: Support relative paths containing \"..\".\n\nThis will allow you to stay in a subdirectory and checking out\npaths in directories outside. With Dscho's \"git status\" that\nshows relatives paths (in kh/commit series), this would make\ncutting and pasting easier.\n\n* mh/retag (Sun Nov 4 01:11:15 2007 +0100) 2 commits\n + Add tests for git tag\n + Reuse previous annotation when overwriting a tag\n\n* jc/maint-add-sync-stat (Sun Nov 11 18:44:16 2007 -0800) 3 commits\n + t2200: test more cases of \"add -u\"\n + git-add: make the entry stat-clean after re-adding the same\n contents\n + ce_match_stat, run_diff_files: use symbolic constants for\n readability\n\nMeant to eventually go to 'maint'. I added tests so now this\nseries can go to 'next'.\n\n* bs/maint-t7005 (Sun Nov 11 18:38:11 2007 +0100) 1 commit\n + t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH\n\nMeant to eventually go to 'maint'.\n\n* sp/maint-plug-traverse-commit-list-leak (Fri Nov 9 06:06:10 2007 -0500) 1 commit\n + Fix memory leak in traverse_commit_list\n\nMeant to eventually go to 'maint'.\n\n* rv/maint-index-commit (Sun Nov 11 13:28:08 2007 +0100) 1 commit\n + Make GIT_INDEX_FILE apply to git-commit\n\nMeant to eventually go to 'maint'. The test needs to be run\nwith Kristian's rewrite in C to catch any regression.\n\n\n----------------------------------------------------------------\n[Still actively cooking]\n\n* ph/parseopt-sh (Thu Nov 8 23:04:31 2007 -0800) 16 commits\n + git-am: -i does not take a string parameter.\n + sh-setup: don't let eval output to be shell-expanded.\n + git-sh-setup: fix parseopt `eval` string underquoting\n + Give git-am back the ability to add Signed-off-by lines.\n + git-rev-parse --parseopt\n + scripts: Add placeholders for OPTIONS_SPEC\n + Migrate git-repack.sh to use git-rev-parse --parseopt\n + Migrate git-quiltimport.sh to use git-rev-parse --parseopt\n + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-\n dashdash\n + Migrate git-instaweb.sh to use git-rev-parse --parseopt\n + Migrate git-merge.sh to use git-rev-parse --parseopt\n + Migrate git-am.sh to use git-rev-parse --parseopt\n + Migrate git-clone to use git-rev-parse --parseopt\n + Migrate git-clean.sh to use git-rev-parse --parseopt.\n + Update git-sh-setup(1) to allow transparent use of git-rev-parse -\n -parseopt\n + Add a parseopt mode to git-rev-parse to bring parse-options to\n shell scripts.\n\nThe rate of incoming changes to fix breakage with this topic has\nslowed down, which is a good indication that this is getting\nready.\n\n* sp/fetch-fix (Sun Nov 11 02:29:47 2007 -0500) 6 commits\n + git-fetch: avoid local fetching from alternate (again)\n + rev-list: Introduce --quiet to avoid /dev/null redirects\n + run-command: Support sending stderr to /dev/null\n + git-fetch: Always fetch tags if the object they reference exists\n + Merge branch 'sp/maint-plug-traverse-commit-list-leak' into\n sp/fetch-fix\n\nThis should restore the traditional behaviour of git-fetch in\nthe C rewrite series.\n\n* js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit\n + rebase: operate on a detached HEAD\n\n----------------------------------------------------------------\n[Approaching 'next']\n\n* kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits\n - builtin-commit: Add newline when showing which commit was created\n - builtin-commit: resurrect behavior for multiple -m options\n - builtin-commit --s: add a newline if the last line was not a S-o-b\n - builtin-commit: fix --signoff\n - git status: show relative paths when run in a subdirectory\n - builtin-commit: fix author date with --amend --author=\n - builtin-commit: Refresh cache after adding files.\n - builtin-commit: fix reflog message generation\n - launch_editor(): read the file, even when EDITOR=:\n - Port git commit to C.\n - Export launch_editor() and make it accept ':' as a no-op editor.\n - Add testcase for ammending and fixing author in git commit.\n\nDscho fixed a handful obvious glitches. I am hoping that this\nseries should be in \"testable\" shape now. Will merge to \"next\"\nafter giving it a final round of eyeballing.\n\n* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n - refactor fetch's ref matching to use refname_match()\n - push: use same rules as git-rev-parse to resolve refspecs\n - add refname_match()\n - push: support pushing HEAD to real branch name\n\nThis changes the semantics slightly but I think it is a move in\nthe right direction.\n\n* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits\n - Added diff hunk coloring to git-add--interactive\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\n* aw/mirror-push (Fri Nov 9 23:32:57 2007 +0000) 16 commits\n - git-push: add documentation for the newly added --mirror mode\n - Add tests for git push'es mirror mode\n - git-push: plumb in --mirror mode\n - Teach send-pack a mirror mode\n\nLooking good.\n\nThis depends on Jeff's \"even terser push output\" series which in\nturn depends on Daniel's \"rewrite ls-remote and send-pack to\nbuild them in\" series, both of which should graduate to 'master'\nhopefully shortly.\n\n* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits\n - Reorder diff_opt_parse options more logically per topics.\n - Make the diff_options bitfields be an unsigned with explicit\n masks.\n + Use OPT_BIT in builtin-pack-refs\n + Use OPT_BIT in builtin-for-each-ref\n + Use OPT_SET_INT and OPT_BIT in builtin-branch\n + parse-options new features.\n\nAlthough I found the whole series reasonable, I parked the later\nparts of the series in 'pu' because diff is one of the more\nimportant parts of the system.\n\n* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit\n - Make builtin-tag.c use parse_options.\n\nThis changes the handling of multiple -m option without much\ngood reason. It should be a simple fix, once we know what we\nwant. I think the existing behaviour of refusing multiple -m\nis probably the most sane at this point.\n\n* sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit\n - Make git-clean a builtin\n\n----------------------------------------------------------------\n[Stalled]\n\n* bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit\n - git-commit.sh: Fix usage checks regarding paths given when they do\n not make sense\n\nThis is meant to go to 'maint' but needs test script to exhibit\nthe existing breakage and demonstrate the fix.\n\nThe test will help catching future regression even after we\nreplace git-commit with Kristian's rewrite in C.\n\n* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n + Add missing inside_work_tree setting in setup_git_directory_gently\n\nThis is meant to go to 'maint' but needs test script to exhibit\nthe existing breakage and demonstrate the fix.\n\n* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nTeaching \"git apply --whitespace=[warn|strip]\" to honor the same\nconfiguration would be a good addition, but this could go to\n'master' as is.\n\n----------------------------------------------------------------\n[Others]\n\n* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n - Do git reset --hard HEAD when using git rebase --skip\n\nSome people on the list may find this debatable.\n\n* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit\n - git-branch --with=commit\n\nI did this just for my own fun.\n\n* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n - test format-patch -s: make sure MIME content type is shown as\n needed\n - format-patch -s: add MIME encoding header if signer's name\n requires so\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'master'.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n - Make git-svn rebase --dirty pass along --dirty to git-rebase.\n - Implement --dirty for git-rebase--interactive.\n - Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nThis seems to be optimized for the --dirty case too much. I'd\nprefer an implementation that make rebases without --dirty to\npay no penalty (if that is possible, otherwise \"as little as\npossible\").\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n - handle renames using similarity engine\n - introduce generic similarity library\n - change hash table calling conventions\n"},{"id":"59472","messageId":"Pine.LNX.4.64.0711121203150.4362@racer.site","threadId":"10420","inReplyTo":"7vwsso3poo.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T12:21:34Z","receivedAt":"2007-11-12T12:21:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 11 Nov 2007, Junio C Hamano wrote:\n\n> * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit\n> + rebase: operate on a detached HEAD\n\nNote: this might have a subtle bug when the last patch in the series \nfailed. If I was not too tired this morning (which might well have been \nthe case), rebase could not switch back to the branch correctly with this.\n\n> ----------------------------------------------------------------\n> [Approaching 'next']\n> \n> * kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits\n> - builtin-commit: Add newline when showing which commit was created\n> - builtin-commit: resurrect behavior for multiple -m options\n> - builtin-commit --s: add a newline if the last line was not a S-o-b\n> - builtin-commit: fix --signoff\n> - git status: show relative paths when run in a subdirectory\n> - builtin-commit: fix author date with --amend --author=\n> - builtin-commit: Refresh cache after adding files.\n> - builtin-commit: fix reflog message generation\n> - launch_editor(): read the file, even when EDITOR=:\n> - Port git commit to C.\n> - Export launch_editor() and make it accept ':' as a no-op editor.\n> - Add testcase for ammending and fixing author in git commit.\n> \n> Dscho fixed a handful obvious glitches. I am hoping that this\n> series should be in \"testable\" shape now. Will merge to \"next\"\n> after giving it a final round of eyeballing.\n\nFWIW I am running 'next'+builtin-commit+a couple of other patches I am \nbrewing. These issues are on my TODO list (most pressing first):\n\n- commit --amend erroneously commits other files that were\n git-add'ed\n- under certain circumstances (my maildir update script) does not\n show newly created and deleted files anymore.\n- do not rebuild the whole index when committing just one file,\n instead use the old index, and then adjust it to the HEAD.\n- remove \"launching editor, logfile (null)\" message\n- forward port 6d4bbebd35e3a6e8091d7188f1c4d49af7f054e3 to builtin-commit\n- when a message is given and no editor should be launched, avoid\n lengthy runstatus calculation\n\nClarification for the \"do not rebuild\" thingie: ATM it seems that there \nis a lengthy calculation going on, even if the index is clean and you only \npassed one single filename on the command line.\n\n> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n> - refactor fetch's ref matching to use refname_match()\n> - push: use same rules as git-rev-parse to resolve refspecs\n> - add refname_match()\n> - push: support pushing HEAD to real branch name\n> \n> This changes the semantics slightly but I think it is a move in\n> the right direction.\n\nWe could add a \"--matching\" option and output a warning when it is not \npassed. I would like this pretty soon, and would not be sad if it went \ninto 'next' before this topic.\n\n> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit\n> - Make builtin-tag.c use parse_options.\n> \n> This changes the handling of multiple -m option without much\n> good reason. It should be a simple fix, once we know what we\n> want. I think the existing behaviour of refusing multiple -m\n> is probably the most sane at this point.\n\nI tend to agree.\n\n> * sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit\n> - Make git-clean a builtin\n\nTime is fleeting, so I could not yet look into the ambiguity problem where \nhelp was requested.\n\n> ----------------------------------------------------------------\n> [Others]\n> \n> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit\n> - git-branch --with=commit\n> \n> I did this just for my own fun.\n\nAs I already said, I'd like this, but renamed to --containing=. In fact, \nI just scrapped a script of mine to do the same, in excited expectation of \nthis feature.\n\nCiao,\nDscho\n"},{"id":"59475","messageId":"20071112122652.GC20482@artemis.corp","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711121203150.4362@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-12T12:26:52Z","receivedAt":"2007-11-12T12:26:52Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sun, 11 Nov 2007, Junio C Hamano wrote:\n> \n> > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit\n> > + rebase: operate on a detached HEAD\n> \n> Note: this might have a subtle bug when the last patch in the series \n> failed. If I was not too tired this morning (which might well have been \n> the case), rebase could not switch back to the branch correctly with this.\n\n OOOH so this was what happened to me today then. I did a rebase, there\nwas a commit to skip, the last one, and I ended up on a detached head.\nAs I didn't had my coffee yet, I assumed this was my fault and did\nsomething stupid. So after all it seems it wasn't the case then :)\n\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"59477","messageId":"Pine.LNX.4.64.0711121232370.4362@racer.site","threadId":"10420","inReplyTo":"20071112122652.GC20482@artemis.corp","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T12:33:19Z","receivedAt":"2007-11-12T12:33:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Pierre Habouzit wrote:\n\n> On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:\n> \n> > On Sun, 11 Nov 2007, Junio C Hamano wrote:\n> > \n> > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit\n> > > + rebase: operate on a detached HEAD\n> > \n> > Note: this might have a subtle bug when the last patch in the series \n> > failed. If I was not too tired this morning (which might well have \n> > been the case), rebase could not switch back to the branch correctly \n> > with this.\n> \n> OOOH so this was what happened to me today then. I did a rebase, there \n> was a commit to skip, the last one, and I ended up on a detached head. \n> As I didn't had my coffee yet, I assumed this was my fault and did \n> something stupid. So after all it seems it wasn't the case then :)\n\nThanks for acknowleding, and sorry for the bug.\n\nWill work on a fix,\nDscho\n"},{"id":"59481","messageId":"Pine.LNX.4.64.0711121310160.4362@racer.site","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711121232370.4362@racer.site","subject":"[PATCH] rebase: brown paper bag fix after the detached HEAD patch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T13:11:46Z","receivedAt":"2007-11-12T13:11:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThe --skip case was handled properly when rebasing without --merge,\nbut the --continue case was not.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Mon, 12 Nov 2007, Johannes Schindelin wrote:\n\n\t> On Mon, 12 Nov 2007, Pierre Habouzit wrote:\n\t> \n\t> > On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin \n\t> > wrote:\n\t> > \n\t> > > On Sun, 11 Nov 2007, Junio C Hamano wrote:\n\t> > > \n\t> > > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit\n\t> > > > + rebase: operate on a detached HEAD\n\t> > > \n\t> > > Note: this might have a subtle bug when the last patch in \n\t> > > the series failed. If I was not too tired this morning \n\t> > > (which might well have been the case), rebase could not \n\t> > > switch back to the branch correctly with this.\n\t> > \n\t> > OOOH so this was what happened to me today then. I did a \n\t> > rebase, there was a commit to skip, the last one, and I ended \n\t> > up on a detached head. As I didn't had my coffee yet, I \n\t> > assumed this was my fault and did something stupid. So after \n\t> > all it seems it wasn't the case then :)\n\t> \n\t> Thanks for acknowleding, and sorry for the bug.\n\t> \n\t> Will work on a fix,\n\n\tHere you are. Sorry again.\n\n git-rebase.sh | 6 +++++-\n t/t3403-rebase-skip.sh | 17 +++++++++++++++++\n 2 files changed, 22 insertions(+), 1 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 7a45e27..c9034b8 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -171,7 +171,11 @@ do\n \t\t\tfinish_rb_merge\n \t\t\texit\n \t\tfi\n-\t\tgit am --resolved --3way --resolvemsg=\"$RESOLVEMSG\"\n+\t\thead_name=$(cat .dotest/head-name) &&\n+\t\tonto=$(cat .dotest/onto) &&\n+\t\torig_head=$(cat .dotest/orig-head) &&\n+\t\tgit am --resolved --3way --resolvemsg=\"$RESOLVEMSG\" &&\n+\t\tmove_to_original_branch\n \t\texit\n \t\t;;\n \t--skip)\ndiff --git a/t/t3403-rebase-skip.sh b/t/t3403-rebase-skip.sh\nindex becabfc..657f681 100755\n--- a/t/t3403-rebase-skip.sh\n+++ b/t/t3403-rebase-skip.sh\n@@ -38,6 +38,19 @@ test_expect_failure 'rebase with git am -3 (default)' '\n test_expect_success 'rebase --skip with am -3' '\n \tgit rebase --skip\n \t'\n+\n+test_expect_success 'rebase moves back to skip-reference' '\n+\ttest refs/heads/skip-reference = $(git symbolic-ref HEAD) &&\n+\tgit branch post-rebase &&\n+\tgit reset --hard pre-rebase &&\n+\t! git rebase master &&\n+\techo \"hello\" > hello &&\n+\tgit add hello &&\n+\tgit rebase --continue &&\n+\ttest refs/heads/skip-reference = $(git symbolic-ref HEAD) &&\n+\tgit reset --hard post-rebase\n+'\n+\n test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'\n \n test_expect_failure 'rebase with --merge' 'git rebase --merge master'\n@@ -49,6 +62,10 @@ test_expect_success 'rebase --skip with --merge' '\n test_expect_success 'merge and reference trees equal' \\\n \t'test -z \"`git diff-tree skip-merge skip-reference`\"'\n \n+test_expect_success 'moved back to branch correctly' '\n+\ttest refs/heads/skip-merge = $(git symbolic-ref HEAD)\n+'\n+\n test_debug 'gitk --all & sleep 1'\n \n test_done\n-- \n1.5.3.5.1738.g5c070\n"},{"id":"59491","messageId":"087FCF8E-74BF-42EA-B7E2-4622DD0F5F9B@zib.de","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711121203150.4362@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-12T14:27:40Z","receivedAt":"2007-11-12T14:27:40Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 12, 2007, at 1:21 PM, Johannes Schindelin wrote:\n\n>> * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n>> - refactor fetch's ref matching to use refname_match()\n>> - push: use same rules as git-rev-parse to resolve refspecs\n>> - add refname_match()\n>> - push: support pushing HEAD to real branch name\n>>\n>> This changes the semantics slightly but I think it is a move in\n>> the right direction.\n>\n> We could add a \"--matching\" option and output a warning when it is not\n> passed. I would like this pretty soon, and would not be sad if it \n> went\n> into 'next' before this topic.\n\nIs this the road towards\n1) \"git push --matching\" push matching branches.\n2) \"git push --current\" push only current branch.\n3) \"git push\" report error if the config does not contain a Push line.\n (after it reported a warning for a while).\n\nI'd like to see this too. Unfortunately it's unlikely that I'll start\nworking on it before next weekend.\n\n\"--matching\" would be a no-op at this time. Only a warning would be \nprinted\nif it is missing. Right?\n\n\tSteffen\n"},{"id":"59495","messageId":"20071112145334.GB343@artemis.corp","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711121232370.4362@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Pierre Habouzit","fromEmail":"madcoder@debian.org","sentAt":"2007-11-12T14:53:34Z","receivedAt":"2007-11-12T14:53:34Z","isPatch":false,"sender":{"key":"madcoder@debian.org","avatar":"https://avatars.githubusercontent.com/u/44708?v=4"},"body":"On Mon, Nov 12, 2007 at 12:33:19PM +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 12 Nov 2007, Pierre Habouzit wrote:\n> \n> > On Mon, Nov 12, 2007 at 12:21:34PM +0000, Johannes Schindelin wrote:\n> > \n> > > On Sun, 11 Nov 2007, Junio C Hamano wrote:\n> > > \n> > > > * js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit\n> > > > + rebase: operate on a detached HEAD\n> > > \n> > > Note: this might have a subtle bug when the last patch in the series \n> > > failed. If I was not too tired this morning (which might well have \n> > > been the case), rebase could not switch back to the branch correctly \n> > > with this.\n> > \n> > OOOH so this was what happened to me today then. I did a rebase, there \n> > was a commit to skip, the last one, and I ended up on a detached head. \n> > As I didn't had my coffee yet, I assumed this was my fault and did \n> > something stupid. So after all it seems it wasn't the case then :)\n> \n> Thanks for acknowleding, and sorry for the bug.\n\n well, shit happens, I'm running next especially to spot those :)\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"59496","messageId":"Pine.LNX.4.64.0711121501500.4362@racer.site","threadId":"10420","inReplyTo":"087FCF8E-74BF-42EA-B7E2-4622DD0F5F9B@zib.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-12T15:02:37Z","receivedAt":"2007-11-12T15:02:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 12 Nov 2007, Steffen Prohaska wrote:\n\n> On Nov 12, 2007, at 1:21 PM, Johannes Schindelin wrote:\n> \n> > > * sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n> > > - refactor fetch's ref matching to use refname_match()\n> > > - push: use same rules as git-rev-parse to resolve refspecs\n> > > - add refname_match()\n> > > - push: support pushing HEAD to real branch name\n> > > \n> > > This changes the semantics slightly but I think it is a move in\n> > > the right direction.\n> > \n> > We could add a \"--matching\" option and output a warning when it is not\n> > passed. I would like this pretty soon, and would not be sad if it went\n> > into 'next' before this topic.\n> \n> Is this the road towards\n> 1) \"git push --matching\" push matching branches.\n> 2) \"git push --current\" push only current branch.\n> 3) \"git push\" report error if the config does not contain a Push line.\n> (after it reported a warning for a while).\n\nAFAIAC yes. Maybe in two years (that's twice an eternity in git time \nscales):\n\n4) make \"git push --current\" the default.\n\n> I'd like to see this too. Unfortunately it's unlikely that I'll start \n> working on it before next weekend.\n> \n> \"--matching\" would be a no-op at this time. Only a warning would be printed\n> if it is missing. Right?\n\nRight.\n\nCiao,\nDscho\n"},{"id":"59497","messageId":"20071112151539.GA2696@atjola.homenet","threadId":"10420","inReplyTo":"7vwsso3poo.fsf@gitster.siamese.dyndns.org","subject":"[PATCH] git-commit: Add tests for invalid usage of -a/--interactive with paths","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2007-11-12T15:15:39Z","receivedAt":"2007-11-12T15:15:39Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"git-commit was/is broken in that it accepts paths together with -a or\n--interactive, which it shouldn't. There tests check those usage errors.\n\nSigned-off-by: Björn Steinbrink \n---\n> [Stalled]\n> \n> * bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit\n> - git-commit.sh: Fix usage checks regarding paths given when they do\n> not make sense\n> \n> This is meant to go to 'maint' but needs test script to exhibit\n> the existing breakage and demonstrate the fix.\n> \n> The test will help catching future regression even after we\n> replace git-commit with Kristian's rewrite in C.\n\nSorry, didn't take your comment to that patch as a request to provide\ntests. Anyway, here they are :-) I hope I got the commit message/comment\nformatting right this time.\n\ndiff --git a/t/t7501-commit.sh b/t/t7501-commit.sh\nindex 4dc35bd..9dba104 100644\n--- a/t/t7501-commit.sh\n+++ b/t/t7501-commit.sh\n@@ -34,6 +34,16 @@ test_expect_failure \\\n \t\"git-commit -C HEAD -m illegal\"\n \n test_expect_failure \\\n+\t\"using paths with -a\" \\\n+\t\"echo King of the bongo >file &&\n+\tgit-commit -m foo -a file\"\n+\n+test_expect_failure \\\n+\t\"using paths with --interactive\" \\\n+\t\"echo bong-o-bong >file &&\n+\techo 7 | git-commit -m foo --interactive file\"\n+\n+test_expect_failure \\\n \t\"using invalid commit with -C\" \\\n \t\"git-commit -C bogus\"\n \n"},{"id":"59891","messageId":"7vfxz89x9q.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vwsso3poo.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-15T00:18:25Z","receivedAt":"2007-11-15T00:18:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n----------------------------------------------------------------\n[Will cook further in 'next' and then merge to 'master' soon]\n\n* lt/rev-list-interactive (Mon Nov 12 23:16:08 2007 -0800) 5 commits\n + Fix parent rewriting in --early-output\n + revision walker: mini clean-up\n + Enhance --early-output format\n + Add \"--early-output\" log flag for interactive GUI use\n + Simplify topo-sort logic\n\n* lt/rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit\n + Fix rev-list when showing objects involving submodules\n\nThis fix from Dscho and Linus will need to be cherry-picked to\n'maint' as well.\n\n* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits\n + git-checkout: Test for relative path use.\n + git-checkout: Support relative paths containing \"..\".\n\nThis will allow you to stay in a subdirectory and check out\npaths in directories outside. With Dscho's \"git status\" that\nshows relatives paths (in kh/commit series), this would make\ncutting and pasting paths you forgot to \"git add\" easier.\n\n* ph/parseopt-sh (Mon Nov 12 12:07:40 2007 +0000) 17 commits\n + git-quiltimport.sh fix --patches handling\n + git-am: -i does not take a string parameter.\n + sh-setup: don't let eval output to be shell-expanded.\n + git-sh-setup: fix parseopt `eval` string underquoting\n + Give git-am back the ability to add Signed-off-by lines.\n + git-rev-parse --parseopt\n + scripts: Add placeholders for OPTIONS_SPEC\n + Migrate git-repack.sh to use git-rev-parse --parseopt\n + Migrate git-quiltimport.sh to use git-rev-parse --parseopt\n + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-\n dashdash\n + Migrate git-instaweb.sh to use git-rev-parse --parseopt\n + Migrate git-merge.sh to use git-rev-parse --parseopt\n + Migrate git-am.sh to use git-rev-parse --parseopt\n + Migrate git-clone to use git-rev-parse --parseopt\n + Migrate git-clean.sh to use git-rev-parse --parseopt.\n + Update git-sh-setup(1) to allow transparent use of git-rev-parse -\n -parseopt\n + Add a parseopt mode to git-rev-parse to bring parse-options to\n shell scripts.\n\nThe rate of incoming fix with this topic has slowed down, which\nis a good indication that this is getting ready.\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* jk/send-pack (Tue Nov 13 06:37:10 2007 -0500) 24 commits\n - send-pack: assign remote errors to each ref\n - send-pack: check ref->status before updating tracking refs\n - send-pack: track errors for each ref\n - Merge branch 'aw/mirror-push' into jk/send-pack\n - Merge branch 'ar/send-pack-remote-track' into jk/send-pack\n - Merge branch 'db/remote-builtin' into jk/send-pack\n + git-push: add documentation for the newly added --mirror mode\n + Add tests for git push'es mirror mode\n + Update the tracking references only if they were succesfully\n updated on remote\n + Add a test checking if send-pack updated local tracking branches\n correctly\n + git-push: plumb in --mirror mode\n + Teach send-pack a mirror mode\n + Merge master into aw/mirror-push\n + Merge branch 'jk/terse-push' into aw/mirror-push\n + send-pack: segfault fix on forced push\n + Reteach builtin-ls-remote to understand remotes\n + send-pack: require --verbose to show update of tracking refs\n + receive-pack: don't mention successful updates\n + more terse push output\n + Build in ls-remote\n + Build-in send-pack, with an API for other programs to call.\n + Use built-in send-pack.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\nThis three-patch series is built on top of four other topics and\nis meant to fix issues in built-in send-pack. I dropped\nindividial topics from Alex, Daniel, Andy and another from Jeff\nthat this series depends on. IOW, they all will graduate to\n\"master\" at the same time when this series proves to be stable.\n\nWill wait for a few days to hear opinions from the list, and\nthen merge to \"next\" and start cooking.\n\n* js/mingw-fallouts (Tue Nov 13 21:05:06 2007 +0100) 11 commits\n + Allow ETC_GITCONFIG to be a relative path.\n + Introduce git_etc_gitconfig() that encapsulates access of\n ETC_GITCONFIG.\n + Allow a relative builtin template directory.\n + Close files opened by lock_file() before unlinking.\n + builtin run_command: do not exit with -1.\n + Move #include and to git-compat-\n util.h.\n + Use is_absolute_path() in sha1_file.c.\n + Skip t3902-quoted.sh if the file system does not support funny\n names.\n + t5302-pack-index: Skip tests of 64-bit offsets if necessary.\n + t7501-commit.sh: Not all seds understand option -i\n + t5300-pack-object.sh: Split the big verify-pack test into smaller\n parts.\n\nA set of good general clean-up patches.\n\n* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nTeaching \"git apply --whitespace=[warn|strip]\" to honor the same\nconfiguration would be a good addition, but this could go to\n'master' as is.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\n* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits\n + Remove hint to use \"git help -a\"\n + Make the list of common commands more exclusive\n\nSome people on the list may find the exact list of commands\nsomewhat debatable. We can fine-tune that in-tree ('pu' does\nnot count as \"in-tree\").\n\n* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits\n + Reorder diff_opt_parse options more logically per topics.\n + Make the diff_options bitfields be an unsigned with explicit\n masks.\n + Use OPT_BIT in builtin-pack-refs\n + Use OPT_BIT in builtin-for-each-ref\n + Use OPT_SET_INT and OPT_BIT in builtin-branch\n + parse-options new features.\n\nFurther code clean-ups.\n\n----------------------------------------------------------------\n[Approaching 'next']\n\n* kh/commit (Wed Nov 14 10:31:53 2007 -0500) 13 commits\n - builtin-commit: Clean up an unused variable and a debug fprintf().\n - Call refresh_cache() when updating the user index for --only\n commits.\n - builtin-commit: Add newline when showing which commit was created\n - builtin-commit: resurrect behavior for multiple -m options\n - builtin-commit --s: add a newline if the last line was not a S-o-b\n - builtin-commit: fix --signoff\n - git status: show relative paths when run in a subdirectory\n - builtin-commit: Refresh cache after adding files.\n - builtin-commit: fix reflog message generation\n - launch_editor(): read the file, even when EDITOR=:\n - Port git commit to C.\n - Export launch_editor() and make it accept ':' as a no-op editor.\n - Add testcase for amending and fixing author in git commit.\n\nDscho fixed a few obvious glitches, but indicated he has a\nhandful more issues with the series. I have been hoping that\nthis series should be in \"testable\" shape now. Will need to\nlook at it again.\n\n* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n - refactor fetch's ref matching to use refname_match()\n - push: use same rules as git-rev-parse to resolve refspecs\n - add refname_match()\n - push: support pushing HEAD to real branch name\n\nThis changes the semantics slightly but I think it is a move in\nthe right direction.\n\n* sb/clean (Mon Nov 12 21:13:05 2007 -0800) 2 commits\n - git-clean: Fix error message if clean.requireForce is not set.\n - Make git-clean a builtin\n\nIt has a subtle change in behaviour but it does not quite\nqualify as a regression. Will merge to \"next\" shortly. We can\nfix the corner case semantics in-tree. I also adjusted the\nerror message to match the fix from Hannes on 'master'.\n\n----------------------------------------------------------------\n[Stalled]\n\n* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n - Do git reset --hard HEAD when using git rebase --skip\n\nSome people on the list may find this debatable. Opinions?\n\n* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit\n - Make builtin-tag.c use parse_options.\n\nThis changes the handling of multiple -m options without much\ngood reason. It should be a simple fix, once we know what we\nwant. I think the existing behaviour of refusing multiple -m\nis probably the most sane at this point.\n\n* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits\n - Added diff hunk coloring to git-add--interactive\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\nThis series has improved quite a bit since the last round, but\nanother round was requested from the list. Waiting for\nrefinements.\n\n* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n + Add missing inside_work_tree setting in setup_git_directory_gently\n\nThere was an additional patch, which still had issues Dscho\npointed out. Waiting for refinements.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n - Make git-svn rebase --dirty pass along --dirty to git-rebase.\n - Implement --dirty for git-rebase--interactive.\n - Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nThis seems to be optimized for the --dirty case too much. I'd\nprefer an implementation that make rebases without --dirty to\npay no penalty (if that is possible, otherwise \"as little as\npossible\").\n\n----------------------------------------------------------------\n[Others]\n\n* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit\n - git-branch --with=commit\n\nI did this just for my own fun. --contains might be more\nconsistent with git-describe but --with is shorter to type ;-)\n\nBesides, it needs documentation and tests.\n\n* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n - test format-patch -s: make sure MIME content type is shown as\n needed\n - format-patch -s: add MIME encoding header if signer's name\n requires so\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'master'.\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n - handle renames using similarity engine\n - introduce generic similarity library\n - change hash table calling conventions\n\n* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit\n - revert/cherry-pick: start refactoring call to merge_recursive\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n"},{"id":"59898","messageId":"Pine.LNX.4.64.0711150038020.4362@racer.site","threadId":"10420","inReplyTo":"7vfxz89x9q.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-15T00:49:25Z","receivedAt":"2007-11-15T00:49:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 14 Nov 2007, Junio C Hamano wrote:\n\n> ----------------------------------------------------------------\n> [Approaching 'next']\n> \n> * kh/commit (Wed Nov 14 10:31:53 2007 -0500) 13 commits\n> - builtin-commit: Clean up an unused variable and a debug fprintf().\n> - Call refresh_cache() when updating the user index for --only\n> commits.\n> - builtin-commit: Add newline when showing which commit was created\n> - builtin-commit: resurrect behavior for multiple -m options\n> - builtin-commit --s: add a newline if the last line was not a S-o-b\n> - builtin-commit: fix --signoff\n> - git status: show relative paths when run in a subdirectory\n> - builtin-commit: Refresh cache after adding files.\n> - builtin-commit: fix reflog message generation\n> - launch_editor(): read the file, even when EDITOR=:\n> - Port git commit to C.\n> - Export launch_editor() and make it accept ':' as a no-op editor.\n> - Add testcase for amending and fixing author in git commit.\n> \n> Dscho fixed a few obvious glitches, but indicated he has a\n> handful more issues with the series. I have been hoping that\n> this series should be in \"testable\" shape now. Will need to\n> look at it again.\n\nWell, it _is_ in testable shape. My working setup is using builtin-commit \nsince a week. One glitch is serious: \"git add a1 && git commit b1\" will \ncommit a1, too.\n\nAnother glitch is only mildly annoying to me (but I have not investigated \nin detail yet): when you commit new files in a subsubdirectory, no summary \n\"created file\" is printed for them.\n\nOther than that, I am pretty happy with it, and the other issues I listed \nshould be easily fixable.\n\n> ----------------------------------------------------------------\n> [Stalled]\n> \n> * mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n> - Do git reset --hard HEAD when using git rebase --skip\n> \n> Some people on the list may find this debatable. Opinions?\n\nI run with it, and like it. Sometimes when I rebase to 'next', a patch \nhas subtle differences compared to the patch which was applied, and then I \nsee in the conflict handling that it was applied already. So I do the \nobvious: I --skip, and it Just Works.\n\nBut you _can_ mistakenly say \"--skip\". That's why I pushed for the \ndetached HEAD when rebasing.\n\n> * cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit\n> - Make builtin-tag.c use parse_options.\n> \n> This changes the handling of multiple -m options without much good \n> reason. It should be a simple fix, once we know what we want. I think \n> the existing behaviour of refusing multiple -m is probably the most sane \n> at this point.\n\nAgree.\n\n> * nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n> + Add missing inside_work_tree setting in setup_git_directory_gently\n> \n> There was an additional patch, which still had issues Dscho pointed out. \n> Waiting for refinements.\n\nThis might be something pretty painful, though, speaking from my own \nexperience with the work-tree stuff.\n\n> ----------------------------------------------------------------\n> [Others]\n> \n> * jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit\n> - git-branch --with=commit\n> \n> I did this just for my own fun. --contains might be more\n> consistent with git-describe but --with is shorter to type ;-)\n\n--with might confuse people who know that you can use \"git branch\" to \ncreate branches, but do not quite know how.\n\nBesides, \"--con\" would be enough, and you can always add '-c'. Or use \ncompletions.\n\nCiao,\nDscho\n"},{"id":"59989","messageId":"1195138198-24511-1-git-send-email-krh@redhat.com","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711150038020.4362@racer.site","subject":"[PATCH] t7501-commit: Add test for git commit with dirty index.","fromName":"Kristian Høgsberg","fromEmail":"krh@redhat.com","sentAt":"2007-11-15T14:49:58Z","receivedAt":"2007-11-15T14:49:58Z","isPatch":true,"sender":{"key":"krh@redhat.com","avatar":"https://gravatar.com/avatar/763dee6f9594ac474f725b137a39565792928e583ddf59b32befc2907409027e?d=mp&s=160"},"body":"---\n t/t7501-commit.sh | 10 ++++++++++\n 1 files changed, 10 insertions(+), 0 deletions(-)\n\ndiff --git a/t/t7501-commit.sh b/t/t7501-commit.sh\nindex 5aed3de..3627d9f 100644\n--- a/t/t7501-commit.sh\n+++ b/t/t7501-commit.sh\n@@ -259,4 +259,14 @@ test_expect_success 'amend commit to fix author' '\n \tdiff expected current\n \n '\n+\n+test_expect_success 'git commit with dirty index' '\n+\techo tacocat > elif &&\n+\techo tehlulz > chz &&\n+\tgit add chz &&\n+\tgit commit elif -m \"tacocat is a palindrome\" &&\n+\tgit show --stat | grep elif &&\n+\tgit diff --cached | grep chz\n+'\n+\t\n test_done\n-- \n1.5.3.4.206.g58ba4\n"},{"id":"59993","messageId":"Pine.LNX.4.64.0711151554430.30886@racer.site","threadId":"10420","inReplyTo":"1195138198-24511-1-git-send-email-krh@redhat.com","subject":"Re: [PATCH] t7501-commit: Add test for git commit with dirty index.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-15T15:55:46Z","receivedAt":"2007-11-15T15:55:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Nov 2007, Kristian Høgsberg wrote:\n\n> ---\n> t/t7501-commit.sh | 10 ++++++++++\n> 1 files changed, 10 insertions(+), 0 deletions(-)\n> \n> diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh\n> index 5aed3de..3627d9f 100644\n> --- a/t/t7501-commit.sh\n> +++ b/t/t7501-commit.sh\n> @@ -259,4 +259,14 @@ test_expect_success 'amend commit to fix author' '\n> \tdiff expected current\n> \n> '\n> +\n> +test_expect_success 'git commit with dirty index' '\n> +\techo tacocat > elif &&\n> +\techo tehlulz > chz &&\n> +\tgit add chz &&\n> +\tgit commit elif -m \"tacocat is a palindrome\" &&\n> +\tgit show --stat | grep elif &&\n> +\tgit diff --cached | grep chz\n> +'\n> +\t\n\nFunny... I have something similar, but with a fix for builtin-commit ;-) \nWill send out in a minute.\n\nCiao,\nDscho\n"},{"id":"59996","messageId":"Pine.LNX.4.64.0711151611090.30886@racer.site","threadId":"10420","inReplyTo":"1195138198-24511-1-git-send-email-krh@redhat.com","subject":"[PATCH] builtin-commit: fix \"git add x y && git commit y\" committing x, too","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-15T16:11:42Z","receivedAt":"2007-11-15T16:11:42Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nEarlier, builtin commit would implicitly commit also the staged\nchanges.\n\nThis patch fixes that.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tThe function reset_index_to_head() could be moved to somewhere\n\tmore central and be reused in builtin-reset.c instead of\n\treset_index_file() later...\n\n builtin-add.c | 1 +\n builtin-commit.c | 30 +++++++++++++++++++++++++++++-\n t/t7500-commit.sh | 10 ++++++++++\n 3 files changed, 40 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-add.c b/builtin-add.c\nindex 77dcde6..017c8f2 100644\n--- a/builtin-add.c\n+++ b/builtin-add.c\n@@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,\n \t\tcase DIFF_STATUS_UNMERGED:\n \t\tcase DIFF_STATUS_MODIFIED:\n \t\tcase DIFF_STATUS_TYPE_CHANGED:\n+\t\tcase DIFF_STATUS_ADDED:\n \t\t\tadd_file_to_cache(path, verbose);\n \t\t\tbreak;\n \t\tcase DIFF_STATUS_DELETED:\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 535039c..0dc6e1c 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -19,6 +19,7 @@\n #include \"strbuf.h\"\n #include \"utf8.h\"\n #include \"parse-options.h\"\n+#include \"unpack-trees.h\"\n \n static const char * const builtin_commit_usage[] = {\n \t\"git-commit [options] [--] ...\",\n@@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {\n \tOPT_END()\n };\n \n+static int reset_index_to_head(void)\n+{\n+\tstruct unpack_trees_options opts;\n+\tstruct tree_desc tree_desc;\n+\tstruct tree *tree;\n+\tunsigned char sha1[20];\n+\n+\t/* ignore if it is an initial commit */\n+\tif (get_sha1(\"HEAD\", sha1))\n+\t\treturn 0;\n+\ttree = parse_tree_indirect(sha1);\n+\tif (!tree || parse_tree(tree))\n+\t\treturn error(\"Could not get HEAD's tree\");\n+\tinit_tree_desc(&tree_desc, tree->buffer, tree->size);\n+\n+\tmemset(&opts, 0, sizeof(opts));\n+\topts.index_only = 1;\n+\topts.merge = 1;\n+\topts.head_idx = 1;\n+\topts.fn = oneway_merge;\n+\tif (unpack_trees(1, &tree_desc, &opts))\n+\t\treturn error(\"Could not reset temporary index to HEAD\");\n+\treturn 0;\n+}\n+\n static char *prepare_index(const char **files, const char *prefix)\n {\n \tint fd;\n@@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)\n \t\t\tdie(\"failed to read HEAD tree object\");\n \t}\n \n+\tif (reset_index_to_head())\n+\t\tdie (\"failed to reset temporary index to HEAD\");\n+\n \t/* Use a lock file to garbage collect the temporary index file. */\n \tnext_index_lock = xmalloc(sizeof(*next_index_lock));\n \tfd = hold_lock_file_for_update(next_index_lock,\n \t\t\t\t git_path(\"next-index-%d\", getpid()), 1);\n \tadd_files_to_cache(verbose, prefix, files);\n-\trefresh_cache(REFRESH_QUIET);\n \tif (write_cache(fd, active_cache, active_nr) || close(fd))\n \t\tdie(\"unable to write new_index file\");\n \ndiff --git a/t/t7500-commit.sh b/t/t7500-commit.sh\nindex c9d65e5..d4d7ed7 100755\n--- a/t/t7500-commit.sh\n+++ b/t/t7500-commit.sh\n@@ -139,4 +139,14 @@ test_expect_success '--signoff' '\n \tdiff expect output\n '\n \n+test_expect_success 'implicit --only only commits specified files' '\n+\techo \"tonight: \" > take &&\n+\techo \"over the\" > world &&\n+\tgit add world take &&\n+\ttest_tick &&\n+\tgit commit -m partial world &&\n+\tgit diff-tree HEAD^..HEAD -- take &&\n+\t! git diff-index --cached --exit-code HEAD -- take\n+'\n+\n test_done\n-- \n1.5.3.5.1786.gdaaa\n"},{"id":"59999","messageId":"Pine.LNX.4.64.0711151635580.30886@racer.site","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711151611090.30886@racer.site","subject":"Re: [PATCH] builtin-commit: fix \"git add x y && git commit y\" committing x, too","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-15T16:37:46Z","receivedAt":"2007-11-15T16:37:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Nov 2007, Johannes Schindelin wrote:\n\n> \n> Earlier, builtin commit would implicitly commit also the staged\n> changes.\n> \n> This patch fixes that.\n\nThis was only lightly tested. Alas, there is still a subtle bug... the \ngenerated \"Untracked/Staged/ToBeCommitted\" list seems off. I guess we'd \nhave to reread the index after resetting it to HEAD and adding the files, \nbut before generating that commit message.\n\nCiao,\nDscho\n"},{"id":"60002","messageId":"1195146094.21076.6.camel@hinata.boston.redhat.com","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711151611090.30886@racer.site","subject":"Re: [PATCH] builtin-commit: fix \"git add x y && git commit y\" committing x, too","fromName":"Kristian Høgsberg","fromEmail":"krh@redhat.com","sentAt":"2007-11-15T17:01:34Z","receivedAt":"2007-11-15T17:01:34Z","isPatch":true,"sender":{"key":"krh@redhat.com","avatar":"https://gravatar.com/avatar/763dee6f9594ac474f725b137a39565792928e583ddf59b32befc2907409027e?d=mp&s=160"},"body":"On Thu, 2007-11-15 at 16:11 +0000, Johannes Schindelin wrote:\n> Earlier, builtin commit would implicitly commit also the staged\n> changes.\n> \n> This patch fixes that.\n> \n> Signed-off-by: Johannes Schindelin \n> ---\n> \n> \tThe function reset_index_to_head() could be moved to somewhere\n> \tmore central and be reused in builtin-reset.c instead of\n> \treset_index_file() later...\n> \n> builtin-add.c | 1 +\n> builtin-commit.c | 30 +++++++++++++++++++++++++++++-\n> t/t7500-commit.sh | 10 ++++++++++\n> 3 files changed, 40 insertions(+), 1 deletions(-)\n> \n> diff --git a/builtin-add.c b/builtin-add.c\n> index 77dcde6..017c8f2 100644\n> --- a/builtin-add.c\n> +++ b/builtin-add.c\n> @@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,\n> \t\tcase DIFF_STATUS_UNMERGED:\n> \t\tcase DIFF_STATUS_MODIFIED:\n> \t\tcase DIFF_STATUS_TYPE_CHANGED:\n> +\t\tcase DIFF_STATUS_ADDED:\n> \t\t\tadd_file_to_cache(path, verbose);\n> \t\t\tbreak;\n> \t\tcase DIFF_STATUS_DELETED:\n> diff --git a/builtin-commit.c b/builtin-commit.c\n> index 535039c..0dc6e1c 100644\n> --- a/builtin-commit.c\n> +++ b/builtin-commit.c\n> @@ -19,6 +19,7 @@\n> #include \"strbuf.h\"\n> #include \"utf8.h\"\n> #include \"parse-options.h\"\n> +#include \"unpack-trees.h\"\n> \n> static const char * const builtin_commit_usage[] = {\n> \t\"git-commit [options] [--] ...\",\n> @@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {\n> \tOPT_END()\n> };\n> \n> +static int reset_index_to_head(void)\n> +{\n> +\tstruct unpack_trees_options opts;\n> +\tstruct tree_desc tree_desc;\n> +\tstruct tree *tree;\n> +\tunsigned char sha1[20];\n> +\n> +\t/* ignore if it is an initial commit */\n> +\tif (get_sha1(\"HEAD\", sha1))\n> +\t\treturn 0;\n> +\ttree = parse_tree_indirect(sha1);\n> +\tif (!tree || parse_tree(tree))\n> +\t\treturn error(\"Could not get HEAD's tree\");\n> +\tinit_tree_desc(&tree_desc, tree->buffer, tree->size);\n> +\n> +\tmemset(&opts, 0, sizeof(opts));\n> +\topts.index_only = 1;\n> +\topts.merge = 1;\n> +\topts.head_idx = 1;\n> +\topts.fn = oneway_merge;\n> +\tif (unpack_trees(1, &tree_desc, &opts))\n> +\t\treturn error(\"Could not reset temporary index to HEAD\");\n> +\treturn 0;\n> +}\n> +\n> static char *prepare_index(const char **files, const char *prefix)\n> {\n> \tint fd;\n> @@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)\n> \t\t\tdie(\"failed to read HEAD tree object\");\n> \t}\n> \n> +\tif (reset_index_to_head())\n> +\t\tdie (\"failed to reset temporary index to HEAD\");\n> +\n\nIf you look just above where you added these lines, there is code to\ndeal with this case, except it doesn't work. I was trying to fix this\ntoo by adding a discard_cache() call before building the temp index, but\nthen I couldn't add the files in question because the index was now\nnewer than those files. Anyway, I don't know if your code is better\nthat just doing read_tree(), but we should only have one or the other in\nthere.\n\nKristian\n"},{"id":"60045","messageId":"Pine.LNX.4.64.0711160036450.30886@racer.site","threadId":"10420","inReplyTo":"1195146094.21076.6.camel@hinata.boston.redhat.com","subject":"Re: [PATCH] builtin-commit: fix \"git add x y && git commit y\" committing x, too","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-16T00:43:17Z","receivedAt":"2007-11-16T00:43:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 15 Nov 2007, Kristian H?gsberg wrote:\n\n> On Thu, 2007-11-15 at 16:11 +0000, Johannes Schindelin wrote:\n> > Earlier, builtin commit would implicitly commit also the staged\n> > changes.\n> > \n> > This patch fixes that.\n> > \n> > Signed-off-by: Johannes Schindelin \n> > ---\n> > \n> > \tThe function reset_index_to_head() could be moved to somewhere\n> > \tmore central and be reused in builtin-reset.c instead of\n> > \treset_index_file() later...\n> > \n> > builtin-add.c | 1 +\n> > builtin-commit.c | 30 +++++++++++++++++++++++++++++-\n> > t/t7500-commit.sh | 10 ++++++++++\n> > 3 files changed, 40 insertions(+), 1 deletions(-)\n> > \n> > diff --git a/builtin-add.c b/builtin-add.c\n> > index 77dcde6..017c8f2 100644\n> > --- a/builtin-add.c\n> > +++ b/builtin-add.c\n> > @@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,\n> > \t\tcase DIFF_STATUS_UNMERGED:\n> > \t\tcase DIFF_STATUS_MODIFIED:\n> > \t\tcase DIFF_STATUS_TYPE_CHANGED:\n> > +\t\tcase DIFF_STATUS_ADDED:\n> > \t\t\tadd_file_to_cache(path, verbose);\n> > \t\t\tbreak;\n> > \t\tcase DIFF_STATUS_DELETED:\n> > diff --git a/builtin-commit.c b/builtin-commit.c\n> > index 535039c..0dc6e1c 100644\n> > --- a/builtin-commit.c\n> > +++ b/builtin-commit.c\n> > @@ -19,6 +19,7 @@\n> > #include \"strbuf.h\"\n> > #include \"utf8.h\"\n> > #include \"parse-options.h\"\n> > +#include \"unpack-trees.h\"\n> > \n> > static const char * const builtin_commit_usage[] = {\n> > \t\"git-commit [options] [--] ...\",\n> > @@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {\n> > \tOPT_END()\n> > };\n> > \n> > +static int reset_index_to_head(void)\n> > +{\n> > +\tstruct unpack_trees_options opts;\n> > +\tstruct tree_desc tree_desc;\n> > +\tstruct tree *tree;\n> > +\tunsigned char sha1[20];\n> > +\n> > +\t/* ignore if it is an initial commit */\n> > +\tif (get_sha1(\"HEAD\", sha1))\n> > +\t\treturn 0;\n> > +\ttree = parse_tree_indirect(sha1);\n> > +\tif (!tree || parse_tree(tree))\n> > +\t\treturn error(\"Could not get HEAD's tree\");\n> > +\tinit_tree_desc(&tree_desc, tree->buffer, tree->size);\n> > +\n> > +\tmemset(&opts, 0, sizeof(opts));\n> > +\topts.index_only = 1;\n> > +\topts.merge = 1;\n> > +\topts.head_idx = 1;\n> > +\topts.fn = oneway_merge;\n> > +\tif (unpack_trees(1, &tree_desc, &opts))\n> > +\t\treturn error(\"Could not reset temporary index to HEAD\");\n> > +\treturn 0;\n> > +}\n> > +\n> > static char *prepare_index(const char **files, const char *prefix)\n> > {\n> > \tint fd;\n> > @@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)\n> > \t\t\tdie(\"failed to read HEAD tree object\");\n> > \t}\n> > \n> > +\tif (reset_index_to_head())\n> > +\t\tdie (\"failed to reset temporary index to HEAD\");\n> > +\n> \n> If you look just above where you added these lines, there is code to\n> deal with this case, except it doesn't work. I was trying to fix this\n> too by adding a discard_cache() call before building the temp index, but\n> then I couldn't add the files in question because the index was now\n> newer than those files. Anyway, I don't know if your code is better\n> that just doing read_tree(), but we should only have one or the other in\n> there.\n\nIt's not only about discarding the cache. It's also about avoiding do \nregenerate the index completely; this would waste time, especially for big \ntrees.\n\nBut the code you are referencing is only updating the index. The code I \nadded is to build the temporary index in a correct manner.\n\nUnfortunately, I guess that the index as calculated by the code you are \nreferencing would be needed to show the correct status.\n\nTherefore I propose to use a different struct index_state, copied from the \ncurrent one, for reset_index_to_head(), add_files_to_index() and \nwrite_index() instead of working on the_index.\n\nBut that has to be done by somebody else than me, or wait for Tuesday, as \nI will be travelling.\n\nCiao,\nDscho\n"},{"id":"60125","messageId":"7vk5ohuunv.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711160036450.30886@racer.site","subject":"Re: [PATCH] builtin-commit: fix \"git add x y && git commit y\" committing x, too","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-17T08:45:56Z","receivedAt":"2007-11-17T08:45:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> It's not only about discarding the cache. It's also about avoiding do \n> regenerate the index completely; this would waste time, especially for big \n> trees.\n\nI was looking at this code earlier tonight but I am too tired so\nhere are a few comments before I stop.\n\n> But the code you are referencing is only updating the index. The code I \n> added is to build the temporary index in a correct manner.\n\nYes, except that it is only in the partial commit codepath and\nthere is not much point optimizing it, as there are more to it.\n\nIf a path that was not in the HEAD was added to the index\nearlier, and the path was named on the command line, the\nadd_files_to_index() function you are borrowing from the\nimplementation of \"add -u\" would not notice it. Look at the\nscript version of git-commit.sh and look for places near\n\"ls-files --error-unmatch --with-tree=HEAD\".\n\nI _think_ we need to do the equivalent of this, keep the\naffected paths in a path-list and use add_file_to_cache()\ninstead. We need to feed the same set of paths to update the\nindex twice (once for the fake one for partial commit, and\nanother for the real index to be used after the commit is made),\nand (1) using add_files_to_index() is more expensive than\nwalking a path-list, and (2) add_files_to_index() is a wrong\nthing to use anyway (by definition you cannot notice addition\nwhen you are comparing the index and the work tree, so I think\nyour patch to update_callback() is a no-op).\n\n\nI noticed that the implementation left next-index crufts almost\nevery time it was run, and started to clean it up. Here is\nstill a WIP and it does not optimize the read_tree(HEAD) part,\nbut you should be able to replace that part with your one-way\nmerge easily. As I haven't done that ls-files --error-unmatch\nequivalent, this does not pass tests that involve partial\ncommits with added or removed paths.\n\n---\n\n builtin-commit.c | 174 +++++++++++++++++++++++++++++++++++++++++++-----------\n 1 files changed, 139 insertions(+), 35 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 3e7d281..187d613 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -7,6 +7,7 @@\n \n #include \"cache.h\"\n #include \"cache-tree.h\"\n+#include \"dir.h\"\n #include \"builtin.h\"\n #include \"diff.h\"\n #include \"diffcore.h\"\n@@ -28,7 +29,13 @@ static const char * const builtin_commit_usage[] = {\n static unsigned char head_sha1[20], merge_head_sha1[20];\n static char *use_message_buffer;\n static const char commit_editmsg[] = \"COMMIT_EDITMSG\";\n-static struct lock_file lock_file;\n+static struct lock_file index_lock; /* real index */\n+static struct lock_file false_lock; /* used only for partial commits */\n+static enum {\n+\tCOMMIT_AS_IS = 1,\n+\tCOMMIT_NORMAL,\n+\tCOMMIT_PARTIAL,\n+} commit_style;\n \n static char *logfile, *force_author, *template_file;\n static char *edit_message, *use_message;\n@@ -78,41 +85,122 @@ static struct option builtin_commit_options[] = {\n \tOPT_END()\n };\n \n+static void rollback_index_files(void)\n+{\n+\tswitch (commit_style) {\n+\tcase COMMIT_AS_IS:\n+\t\tbreak; /* nothing to do */\n+\tcase COMMIT_NORMAL:\n+\t\trollback_lock_file(&index_lock);\n+\t\tbreak;\n+\tcase COMMIT_PARTIAL:\n+\t\trollback_lock_file(&index_lock);\n+\t\trollback_lock_file(&false_lock);\n+\t\tbreak;\n+\t}\n+}\n+\n+static void commit_index_files(void)\n+{\n+\tswitch (commit_style) {\n+\tcase COMMIT_AS_IS:\n+\t\tbreak; /* nothing to do */\n+\tcase COMMIT_NORMAL:\n+\t\tcommit_lock_file(&index_lock);\n+\t\tbreak;\n+\tcase COMMIT_PARTIAL:\n+\t\tcommit_lock_file(&index_lock);\n+\t\trollback_lock_file(&false_lock);\n+\t\tbreak;\n+\t}\n+}\n+\n static char *prepare_index(const char **files, const char *prefix)\n {\n \tint fd;\n \tstruct tree *tree;\n-\tstruct lock_file *next_index_lock;\n \n \tif (interactive) {\n \t\tinteractive_add();\n \t\treturn get_index_file();\n \t}\n \n-\tfd = hold_locked_index(&lock_file, 1);\n \tif (read_cache() < 0)\n \t\tdie(\"index file corrupt\");\n \n+\t/*\n+\t * Non partial, non as-is commit.\n+\t *\n+\t * (1) get the real index;\n+\t * (2) update the_index as necessary;\n+\t * (3) write the_index out to the real index (still locked);\n+\t * (4) return the name of the locked index file.\n+\t *\n+\t * The caller should run hooks on the locked real index, and\n+\t * (A) if all goes well, commit the real index;\n+\t * (B) on failure, rollback the real index.\n+\t */\n \tif (all || also) {\n+\t\tfd = hold_locked_index(&index_lock, 1);\n \t\tadd_files_to_cache(verbose, also ? prefix : NULL, files);\n \t\trefresh_cache(REFRESH_QUIET);\n \t\tif (write_cache(fd, active_cache, active_nr) || close(fd))\n \t\t\tdie(\"unable to write new_index file\");\n-\t\treturn lock_file.filename;\n+\t\tcommit_style = COMMIT_NORMAL;\n+\t\treturn index_lock.filename;\n \t}\n \n+\t/*\n+\t * As-is commit.\n+\t *\n+\t * (1) return the name of the real index file.\n+\t *\n+\t * The caller should run hooks on the real index, and run\n+\t * hooks on the real index, and create commit from the_index.\n+\t * No lockfile is needed.\n+\t */\n \tif (*files == NULL) {\n-\t\t/* Commit index as-is. */\n-\t\trollback_lock_file(&lock_file);\n+\t\tfd = hold_locked_index(&index_lock, 1);\n+\t\trefresh_cache(REFRESH_QUIET);\n+\t\tif (write_cache(fd, active_cache, active_nr) ||\n+\t\t close(fd) || commit_locked_index(&index_lock))\n+\t\t\tdie(\"unable to write new_index file\");\n+\t\tcommit_style = COMMIT_AS_IS;\n \t\treturn get_index_file();\n \t}\n \n-\t/* update the user index file */\n+\t/*\n+\t * A partial commit.\n+\t *\n+\t * (0) find the set of affected paths [NEEDSWORK: NOT DONE YET]\n+\t * (1) get lock on the real index file;\n+\t * (2) update the_index with the given paths;\n+\t * (3) write the_index out to the real index (still locked);\n+\t * (4) get lock on the false index file;\n+\t * (5) reset the_index from HEAD, but keep the addition;\n+\t * (6) update the_index the same way as (2);\n+\t * (7) write the_index out to the false index file;\n+\t * (8) return the name of the false index file (still locked);\n+\t *\n+\t * The caller should run hooks on the locked false index, and\n+\t * (A) if all goes well, commit the real index;\n+\t * (B) on failure, rollback the real index;\n+\t * In either case, rollback the false index.\n+\t */\n+\tcommit_style = COMMIT_PARTIAL;\n+\n+\tif (file_exists(git_path(\"MERGE_HEAD\")))\n+\t\tdie(\"cannot do a partial commit during a merge.\");\n+\n+\tfd = hold_locked_index(&index_lock, 1);\n \tadd_files_to_cache(verbose, prefix, files);\n \trefresh_cache(REFRESH_QUIET);\n \tif (write_cache(fd, active_cache, active_nr) || close(fd))\n \t\tdie(\"unable to write new_index file\");\n \n+\tfd = hold_lock_file_for_update(&false_lock,\n+\t\t\t\t git_path(\"next-index-%d\", getpid()), 1);\n+\tdiscard_cache();\n \tif (!initial_commit) {\n \t\ttree = parse_tree_indirect(head_sha1);\n \t\tif (!tree)\n@@ -120,17 +208,12 @@ static char *prepare_index(const char **files, const char *prefix)\n \t\tif (read_tree(tree, 0, NULL))\n \t\t\tdie(\"failed to read HEAD tree object\");\n \t}\n-\n-\t/* Use a lock file to garbage collect the temporary index file. */\n-\tnext_index_lock = xmalloc(sizeof(*next_index_lock));\n-\tfd = hold_lock_file_for_update(next_index_lock,\n-\t\t\t\t git_path(\"next-index-%d\", getpid()), 1);\n \tadd_files_to_cache(verbose, prefix, files);\n \trefresh_cache(REFRESH_QUIET);\n-\tif (write_cache(fd, active_cache, active_nr) || close(fd))\n-\t\tdie(\"unable to write new_index file\");\n \n-\treturn next_index_lock->filename;\n+\tif (write_cache(fd, active_cache, active_nr) || close(fd))\n+\t\tdie(\"unable to write temporary index file\");\n+\treturn false_lock.filename;\n }\n \n static int run_status(FILE *fp, const char *index_file, const char *prefix)\n@@ -437,7 +520,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \n \tcommitable = run_status(stdout, index_file, prefix);\n \n-\trollback_lock_file(&lock_file);\n+\trollback_index_files();\n \n \treturn commitable ? 0 : 1;\n }\n@@ -527,23 +610,36 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \n \tindex_file = prepare_index(argv, prefix);\n \n-\tif (!no_verify && run_hook(index_file, \"pre-commit\", NULL))\n-\t\texit(1);\n+\tif (!no_verify && run_hook(index_file, \"pre-commit\", NULL)) {\n+\t\trollback_index_files();\n+\t\treturn 1;\n+\t}\n \n \tif (!prepare_log_message(index_file, prefix) && !in_merge) {\n \t\trun_status(stdout, index_file, prefix);\n+\t\trollback_index_files();\n \t\tunlink(commit_editmsg);\n \t\treturn 1;\n \t}\n \n-\tstrbuf_init(&sb, 0);\n-\n-\t/* Start building up the commit header */\n+\t/*\n+\t * Re-read the index as pre-commit hook could have updated it,\n+\t * and write it out as a tree.\n+\t */\n+\tdiscard_cache();\n \tread_cache_from(index_file);\n-\tactive_cache_tree = cache_tree();\n+\tif (!active_cache_tree)\n+\t\tactive_cache_tree = cache_tree();\n \tif (cache_tree_update(active_cache_tree,\n-\t\t\t active_cache, active_nr, 0, 0) < 0)\n+\t\t\t active_cache, active_nr, 0, 0) < 0) {\n+\t\trollback_index_files();\n \t\tdie(\"Error building trees\");\n+\t}\n+\n+\t/*\n+\t * The commit object\n+\t */\n+\tstrbuf_init(&sb, 0);\n \tstrbuf_addf(&sb, \"tree %s\\n\",\n \t\t sha1_to_hex(active_cache_tree->sha1));\n \n@@ -592,20 +688,27 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \theader_len = sb.len;\n \tif (!no_edit)\n \t\tlaunch_editor(git_path(commit_editmsg), &sb);\n-\telse if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0)\n+\telse if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0) {\n+\t\trollback_index_files();\n \t\tdie(\"could not read commit message\\n\");\n-\tif (run_hook(index_file, \"commit-msg\", commit_editmsg))\n+\t}\n+\tif (run_hook(index_file, \"commit-msg\", commit_editmsg)) {\n+\t\trollback_index_files();\n \t\texit(1);\n+\t}\n \tstripspace(&sb, 1);\n-\tif (sb.len < header_len ||\n-\t message_is_empty(&sb, header_len))\n+\tif (sb.len < header_len || message_is_empty(&sb, header_len)) {\n+\t\trollback_index_files();\n \t\tdie(\"* no commit message? aborting commit.\");\n+\t}\n \tstrbuf_addch(&sb, '\\0');\n \tif (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))\n \t\tfprintf(stderr, commit_utf8_warn);\n \n-\tif (write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1))\n+\tif (write_sha1_file(sb.buf, sb.len - 1, commit_type, commit_sha1)) {\n+\t\trollback_index_files();\n \t\tdie(\"failed to write commit object\");\n+\t}\n \n \tref_lock = lock_any_ref_for_update(\"HEAD\",\n \t\t\t\t\t initial_commit ? NULL : head_sha1,\n@@ -620,21 +723,22 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \tstrbuf_insert(&sb, 0, reflog_msg, strlen(reflog_msg));\n \tstrbuf_insert(&sb, strlen(reflog_msg), \": \", 2);\n \n-\tif (!ref_lock)\n+\tif (!ref_lock) {\n+\t\trollback_index_files();\n \t\tdie(\"cannot lock HEAD ref\");\n-\tif (write_ref_sha1(ref_lock, commit_sha1, sb.buf) < 0)\n+\t}\n+\tif (write_ref_sha1(ref_lock, commit_sha1, sb.buf) < 0) {\n+\t\trollback_index_files();\n \t\tdie(\"cannot update HEAD ref\");\n+\t}\n \n \tunlink(git_path(\"MERGE_HEAD\"));\n \tunlink(git_path(\"MERGE_MSG\"));\n \n-\tif (lock_file.filename[0] && commit_locked_index(&lock_file))\n-\t\tdie(\"failed to write new index\");\n+\tcommit_index_files();\n \n \trerere();\n-\n-\trun_hook(index_file, \"post-commit\", NULL);\n-\n+\trun_hook(get_index_file(), \"post-commit\", NULL);\n \tif (!quiet)\n \t\tprint_summary(prefix, commit_sha1);\n \n"},{"id":"60133","messageId":"20071117124003.GA23028@sigill.intra.peff.net","threadId":"10420","inReplyTo":"7vfxz89x9q.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-17T12:40:05Z","receivedAt":"2007-11-17T12:40:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 14, 2007 at 04:18:25PM -0800, Junio C Hamano wrote:\n\n> * jk/send-pack (Tue Nov 13 06:37:10 2007 -0500) 24 commits\n> [...]\n> This three-patch series is built on top of four other topics and\n> is meant to fix issues in built-in send-pack. I dropped\n> individial topics from Alex, Daniel, Andy and another from Jeff\n> that this series depends on. IOW, they all will graduate to\n> \"master\" at the same time when this series proves to be stable.\n\nThank you, it was getting confusing with so many people working in the\nsame area. :)\n\n> Will wait for a few days to hear opinions from the list, and\n> then merge to \"next\" and start cooking.\n\nI am about to send out an improved patch set that incorporates some of\nthe test fixes from Alex, some new tests from me, and a few code\ncleanups.\n\n-Peff\n"},{"id":"60167","messageId":"7vabpctx3b.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vfxz89x9q.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-17T20:51:04Z","receivedAt":"2007-11-17T20:51:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n----------------------------------------------------------------\n[New Topics]\n\n* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit\n - Move gitk to its own subdirectory\n\n----------------------------------------------------------------\n[Will cook further in 'next' and then merge to 'master' soon]\n\n* sh/p4 (Thu Nov 15 10:38:45 2007 +0100) 1 commit\n + git-p4: Fix direct import from perforce after fetching changes\n through git from origin\n\n* lt/rev-list-interactive (Mon Nov 12 23:16:08 2007 -0800) 5 commits\n + Fix parent rewriting in --early-output\n + revision walker: mini clean-up\n + Enhance --early-output format\n + Add \"--early-output\" log flag for interactive GUI use\n + Simplify topo-sort logic\n\n* lt/rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit\n + Fix rev-list when showing objects involving submodules\n\nThis fix from Dscho and Linus will need to be cherry-picked to\n'maint' as well.\n\n* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits\n + git-checkout: Test for relative path use.\n + git-checkout: Support relative paths containing \"..\".\n\nThis will allow you to stay in a subdirectory and check out\npaths in directories outside. With Dscho's \"git status\" that\nshows relatives paths (in kh/commit series), this would make\ncutting and pasting paths you forgot to \"git add\" easier.\n\n* ph/parseopt-sh (Mon Nov 12 12:07:40 2007 +0000) 17 commits\n + git-quiltimport.sh fix --patches handling\n + git-am: -i does not take a string parameter.\n + sh-setup: don't let eval output to be shell-expanded.\n + git-sh-setup: fix parseopt `eval` string underquoting\n + Give git-am back the ability to add Signed-off-by lines.\n + git-rev-parse --parseopt\n + scripts: Add placeholders for OPTIONS_SPEC\n + Migrate git-repack.sh to use git-rev-parse --parseopt\n + Migrate git-quiltimport.sh to use git-rev-parse --parseopt\n + Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-\n dashdash\n + Migrate git-instaweb.sh to use git-rev-parse --parseopt\n + Migrate git-merge.sh to use git-rev-parse --parseopt\n + Migrate git-am.sh to use git-rev-parse --parseopt\n + Migrate git-clone to use git-rev-parse --parseopt\n + Migrate git-clean.sh to use git-rev-parse --parseopt.\n + Update git-sh-setup(1) to allow transparent use of git-rev-parse -\n -parseopt\n + Add a parseopt mode to git-rev-parse to bring parse-options to\n shell scripts.\n\nThe rate of incoming fix with this topic has slowed down, which\nis a good indication that this is getting ready.\n\n* js/mingw-fallouts (Thu Nov 15 12:24:17 2007 -0500) 12 commits\n + rehabilitate some t5302 tests on 32-bit off_t machines\n + Allow ETC_GITCONFIG to be a relative path.\n + Introduce git_etc_gitconfig() that encapsulates access of\n ETC_GITCONFIG.\n + Allow a relative builtin template directory.\n + Close files opened by lock_file() before unlinking.\n + builtin run_command: do not exit with -1.\n + Move #include and to git-compat-\n util.h.\n + Use is_absolute_path() in sha1_file.c.\n + Skip t3902-quoted.sh if the file system does not support funny\n names.\n + t5302-pack-index: Skip tests of 64-bit offsets if necessary.\n + t7501-commit.sh: Not all seds understand option -i\n + t5300-pack-object.sh: Split the big verify-pack test into smaller\n parts.\n\nA set of good general clean-up patches.\n\n* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits\n + Reorder diff_opt_parse options more logically per topics.\n + Make the diff_options bitfields be an unsigned with explicit\n masks.\n + Use OPT_BIT in builtin-pack-refs\n + Use OPT_BIT in builtin-for-each-ref\n + Use OPT_SET_INT and OPT_BIT in builtin-branch\n + parse-options new features.\n\nFurther code clean-ups.\n\n* cc/bisect (Sat Nov 17 14:35:25 2007 +0100) 5 commits\n + Bisect visualize: use \"for-each-ref\" to list all good refs.\n + git-bisect: modernize branch shuffling hack\n + git-bisect: use update-ref to mark good/bad commits\n + git-bisect: war on \"sed\"\n + Bisect reset: remove bisect refs that may have been packed.\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* jk/send-pack (Sat Nov 17 07:56:03 2007 -0500) 24 commits\n + send-pack: assign remote errors to each ref\n + send-pack: check ref->status before updating tracking refs\n + send-pack: track errors for each ref\n + Merge branch 'aw/mirror-push' into jk/send-pack\n + Merge branch 'ar/send-pack-remote-track' into jk/send-pack\n + Merge branch 'db/remote-builtin' into jk/send-pack\n + git-push: add documentation for the newly added --mirror mode\n + Add tests for git push'es mirror mode\n + Update the tracking references only if they were succesfully\n updated on remote\n + Add a test checking if send-pack updated local tracking branches\n correctly\n + git-push: plumb in --mirror mode\n + Teach send-pack a mirror mode\n + Merge master into aw/mirror-push\n + Merge branch 'jk/terse-push' into aw/mirror-push\n + send-pack: segfault fix on forced push\n + Reteach builtin-ls-remote to understand remotes\n + send-pack: require --verbose to show update of tracking refs\n + receive-pack: don't mention successful updates\n + more terse push output\n + Build in ls-remote\n + Build-in send-pack, with an API for other programs to call.\n + Use built-in send-pack.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\nLooking good.\n\n* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nTeaching \"git apply --whitespace=[warn|strip]\" to honor the same\nconfiguration would be a good addition, but this could go to\n'master' as is.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\n* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits\n + Remove hint to use \"git help -a\"\n + Make the list of common commands more exclusive\n\nSome people on the list may find the exact list of commands\nsomewhat debatable. We can fine-tune that in-tree ('pu' does\nnot count as \"in-tree\").\n\n----------------------------------------------------------------\n[Approaching 'next']\n\n* kh/commit (Sat Nov 17 00:46:33 2007 -0800) 16 commits\n - PARK: cruft next-index clean-up\n - Replace \"runstatus\" with \"status\" in the tests\n - t7501-commit: Add test for git commit with dirty index.\n - builtin-commit: Clean up an unused variable and a debug fprintf().\n - Call refresh_cache() when updating the user index for --only\n commits.\n - builtin-commit: Add newline when showing which commit was created\n - builtin-commit: resurrect behavior for multiple -m options\n - builtin-commit --s: add a newline if the last line was not a S-o-b\n - builtin-commit: fix --signoff\n - git status: show relative paths when run in a subdirectory\n - builtin-commit: Refresh cache after adding files.\n - builtin-commit: fix reflog message generation\n - launch_editor(): read the file, even when EDITOR=:\n - Port git commit to C.\n - Export launch_editor() and make it accept ':' as a no-op editor.\n - Add testcase for amending and fixing author in git commit.\n\nDscho fixed a few obvious glitches, but indicated he has a\nhandful more issues with the series. Partial commit is\nseriously broken.\n\n* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n - refactor fetch's ref matching to use refname_match()\n - push: use same rules as git-rev-parse to resolve refspecs\n - add refname_match()\n - push: support pushing HEAD to real branch name\n\nThis changes the semantics slightly but I think it is a move in\nthe right direction.\n\n* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits\n - Teach git clean to use setup_standard_excludes()\n - git-clean: Fix error message if clean.requireForce is not set.\n - Make git-clean a builtin\n\nIt has a subtle change in behaviour but it does not quite\nqualify as a regression. Will merge to \"next\" shortly. We can\nfix the corner case semantics in-tree. I also adjusted the\nerror message to match the fix from Hannes on 'master'.\n\n----------------------------------------------------------------\n[Stalled]\n\n* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n - Do git reset --hard HEAD when using git rebase --skip\n\nSome people on the list may find this debatable. Opinions?\n\n* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit\n - Make builtin-tag.c use parse_options.\n\nThis changes the handling of multiple -m options without much\ngood reason. It should be a simple fix, once we know what we\nwant. I think the existing behaviour of refusing multiple -m\nis probably the most sane at this point.\n\n* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits\n - Added diff hunk coloring to git-add--interactive\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\nThis series has improved quite a bit since the last round, but\nanother round was requested from the list. Waiting for\nrefinements.\n\n* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n + Add missing inside_work_tree setting in setup_git_directory_gently\n\nThere was an additional patch, which still had issues Dscho\npointed out. Waiting for refinements.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n - Make git-svn rebase --dirty pass along --dirty to git-rebase.\n - Implement --dirty for git-rebase--interactive.\n - Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nThis seems to be optimized for the --dirty case too much. I'd\nprefer an implementation that make rebases without --dirty to\npay no penalty (if that is possible, otherwise \"as little as\npossible\").\n\n----------------------------------------------------------------\n[Others]\n\n* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit\n - git-branch --with=commit\n\nI did this just for my own fun. --contains might be more\nconsistent with git-describe but --with is shorter to type ;-)\n\nBesides, it needs documentation and tests.\n\n* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n - test format-patch -s: make sure MIME content type is shown as\n needed\n - format-patch -s: add MIME encoding header if signer's name\n requires so\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'master'.\n\n* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit\n - Fix rev-list when showing objects involving submodules\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'next' and will be merged to 'master' soon.\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n - handle renames using similarity engine\n - introduce generic similarity library\n - change hash table calling conventions\n\n* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit\n - revert/cherry-pick: start refactoring call to merge_recursive\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n"},{"id":"60184","messageId":"20071117234240.GB7664@steel.home","threadId":"10420","inReplyTo":"7vabpctx3b.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-11-17T23:42:40Z","receivedAt":"2007-11-17T23:42:40Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Junio C Hamano, Sat, Nov 17, 2007 21:51:04 +0100:\n> * mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n> - Do git reset --hard HEAD when using git rebase --skip\n> \n> Some people on the list may find this debatable. Opinions?\n\nI like it (and didn't like the previous behaviour). Anyway, it is not\nobvious what to do when --skip refuses to continue rebase because of\ndirty index.\n"},{"id":"60196","messageId":"7v1waoz6hu.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"20071117234240.GB7664@steel.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-18T01:29:01Z","receivedAt":"2007-11-18T01:29:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alex Riesen writes:\n\n> Junio C Hamano, Sat, Nov 17, 2007 21:51:04 +0100:\n>> * mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n>> - Do git reset --hard HEAD when using git rebase --skip\n>> \n>> Some people on the list may find this debatable. Opinions?\n>\n> I like it (and didn't like the previous behaviour). Anyway, it is not\n> obvious what to do when --skip refuses to continue rebase because of\n> dirty index.\n\nTrue. Let's have it in 'next' then.\n"},{"id":"60213","messageId":"7v8x4vykqm.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vk5ohuunv.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] builtin-commit: fix \"git add x y && git commit y\" committing x, too","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-18T09:18:57Z","receivedAt":"2007-11-18T09:18:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> I noticed that the implementation left next-index crufts almost\n> every time it was run, and started to clean it up. Here is\n> still a WIP and it does not optimize the read_tree(HEAD) part,\n> but you should be able to replace that part with your one-way\n> merge easily. As I haven't done that ls-files --error-unmatch\n> equivalent, this does not pass tests that involve partial\n> commits with added or removed paths.\n\nI was working on this tonight. Will send out a proposed fix\nbased on this WIP shortly. The result seems to pass all the\ntests.\n"},{"id":"60236","messageId":"11954023881802-git-send-email-prohaska@zib.de","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711121501500.4362@racer.site","subject":"[PATCH 1/2] push: Add '--matching' option and print warning if it should be used","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-18T16:13:07Z","receivedAt":"2007-11-18T16:13:07Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"This on the road to\n1) \"git push --matching\" pushes matching branches.\n2) \"git push --current\" pushes only current branch.\n3) \"git push\" reports error if the config does not contain a Push line.\n (after it reported a warning for a while).\n\nMaybe in two years (that's twice an eternity in git time scales):\n\n4) make \"git push --current\" the default.\n\nThis commit adds '--matching', which is a no-op at this point.\nIf appropriate, a warning is printed to tell the user that the\ndefault will change in the future.\n\nThanks to Dscho for suggesting this.\n\nSigned-off-by: Steffen Prohaska \n---\n Documentation/git-push.txt | 8 +++++++-\n builtin-push.c | 13 +++++++++++--\n t/t5516-fetch-push.sh | 13 +++++++++++++\n 3 files changed, 31 insertions(+), 3 deletions(-)\n\nSo here is '--matching'. And PATCH 2/2 will bring '--current'.\nThey apply on top of sp/refspec-match.\n\n Steffen\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 4a68aab..d2417f3 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects\n SYNOPSIS\n --------\n [verse]\n-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=]\n+'git-push' [--all] [--matching] [--dry-run] [--tags] [--receive-pack=]\n [--repo=all] [-f | --force] [-v | --verbose] [ ...]\n \n DESCRIPTION\n@@ -63,6 +63,12 @@ the remote repository.\n \tInstead of naming each ref to push, specifies that all\n \trefs under `$GIT_DIR/refs/heads/` be pushed.\n \n+\\--matching::\n+\tInstead of naming each ref to push, specifies that matching\n+\trefs under `$GIT_DIR/refs/heads/` be pushed. Matching means\n+\tthe branch exists locally and at the remote under the same name.\n+\tCurrently, this is the default. But this will change in the future.\n+\n \\--dry-run::\n \tDo everything except actually send the updates.\n \ndiff --git a/builtin-push.c b/builtin-push.c\nindex 54fba0e..7e9dcf1 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -10,7 +10,7 @@\n #include \"parse-options.h\"\n \n static const char * const push_usage[] = {\n-\t\"git-push [--all] [--dry-run] [--tags] [--receive-pack=] [--repo=all] [-f | --force] [-v] [ ...]\",\n+\t\"git-push [--all] [--matching] [--dry-run] [--tags] [--receive-pack=] [--repo=all] [-f | --force] [-v] [ ...]\",\n \tNULL,\n };\n \n@@ -100,6 +100,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n {\n \tint flags = 0;\n \tint all = 0;\n+\tint matching = 0;\n \tint dry_run = 0;\n \tint force = 0;\n \tint tags = 0;\n@@ -109,6 +110,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tOPT__VERBOSE(&verbose),\n \t\tOPT_STRING( 0 , \"repo\", &repo, \"repository\", \"repository\"),\n \t\tOPT_BOOLEAN( 0 , \"all\", &all, \"push all refs\"),\n+\t\tOPT_BOOLEAN( 0 , \"matching\", &matching, \"push matching refs\"),\n \t\tOPT_BOOLEAN( 0 , \"tags\", &tags, \"push tags\"),\n \t\tOPT_BOOLEAN( 0 , \"dry-run\", &dry_run, \"dry run\"),\n \t\tOPT_BOOLEAN('f', \"force\", &force, \"force updates\"),\n@@ -135,8 +137,15 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\trepo = argv[0];\n \t\tset_refspecs(argv + 1, argc - 1);\n \t}\n-\tif ((flags & TRANSPORT_PUSH_ALL) && refspec)\n+\tif ((all != 0) + (matching != 0) > 1) {\n+\t\tfprintf(stderr, \"--all and --matching are mutual exclusive.\\n\");\n \t\tusage_with_options(push_usage, options);\n+\t}\n+\tif ((all || matching) && refspec)\n+\t\tusage_with_options(push_usage, options);\n+\tif (!all && !matching && !refspec)\n+\t\tfprintf(stderr, \"Warning: assuming '--matching'.\"\n+\t\t \" This default will change in the future.\\n\");\n \n \treturn do_push(repo, flags);\n }\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex fd5f284..21aa7c3 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -100,6 +100,19 @@ test_expect_success 'fetch with wildcard' '\n \t)\n '\n \n+test_expect_code 129 'push command line options (1)' '\n+\tgit push --all --matching testrepo\n+'\n+\n+test_expect_code 129 'push command line options (2)' '\n+\tgit push --matching testrepo master\n+'\n+\n+test_expect_success 'push command line options (3)' '\n+\tgit push testrepo 2>stderr.txt &&\n+\tgrep -q \"Warning: assuming.*--matching\" stderr.txt\n+'\n+\n test_expect_success 'push without wildcard' '\n \tmk_empty &&\n \n-- \n1.5.3.5.743.g87c5c\n"},{"id":"60237","messageId":"119540238994-git-send-email-prohaska@zib.de","threadId":"10420","inReplyTo":"11954023881802-git-send-email-prohaska@zib.de","subject":"[PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-18T16:13:08Z","receivedAt":"2007-11-18T16:13:08Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"Often you want to push only the current branch to the default\nremote. This was awkward to do in the past. You needed to\nremember the default remote and type \"git push $remote HEAD\".\n\nThis commit teaches push to do this if you use '--current'.\n\nSigned-off-by: Steffen Prohaska \n---\n Documentation/git-push.txt | 6 +++++-\n builtin-push.c | 16 +++++++++++-----\n t/t5516-fetch-push.sh | 29 +++++++++++++++++++++++++++++\n 3 files changed, 45 insertions(+), 6 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex d2417f3..2dfaf50 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects\n SYNOPSIS\n --------\n [verse]\n-'git-push' [--all] [--matching] [--dry-run] [--tags] [--receive-pack=]\n+'git-push' [--all] [--matching] [--current] [--dry-run] [--tags] [--receive-pack=]\n [--repo=all] [-f | --force] [-v | --verbose] [ ...]\n \n DESCRIPTION\n@@ -69,6 +69,10 @@ the remote repository.\n \tthe branch exists locally and at the remote under the same name.\n \tCurrently, this is the default. But this will change in the future.\n \n+\\--current::\n+\tInstead of naming each ref to push, specifies that only the\n+\tcurrent branch be pushed.\n+\n \\--dry-run::\n \tDo everything except actually send the updates.\n \ndiff --git a/builtin-push.c b/builtin-push.c\nindex 7e9dcf1..e5646d4 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -10,7 +10,7 @@\n #include \"parse-options.h\"\n \n static const char * const push_usage[] = {\n-\t\"git-push [--all] [--matching] [--dry-run] [--tags] [--receive-pack=] [--repo=all] [-f | --force] [-v] [ ...]\",\n+\t\"git-push [--all] [--matching] [--current] [--dry-run] [--tags] [--receive-pack=] [--repo=all] [-f | --force] [-v] [ ...]\",\n \tNULL,\n };\n \n@@ -101,6 +101,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \tint flags = 0;\n \tint all = 0;\n \tint matching = 0;\n+\tint current = 0;\n \tint dry_run = 0;\n \tint force = 0;\n \tint tags = 0;\n@@ -111,6 +112,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tOPT_STRING( 0 , \"repo\", &repo, \"repository\", \"repository\"),\n \t\tOPT_BOOLEAN( 0 , \"all\", &all, \"push all refs\"),\n \t\tOPT_BOOLEAN( 0 , \"matching\", &matching, \"push matching refs\"),\n+\t\tOPT_BOOLEAN( 0 , \"current\", ¤t, \"push current branch\"),\n \t\tOPT_BOOLEAN( 0 , \"tags\", &tags, \"push tags\"),\n \t\tOPT_BOOLEAN( 0 , \"dry-run\", &dry_run, \"dry run\"),\n \t\tOPT_BOOLEAN('f', \"force\", &force, \"force updates\"),\n@@ -137,15 +139,19 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\trepo = argv[0];\n \t\tset_refspecs(argv + 1, argc - 1);\n \t}\n-\tif ((all != 0) + (matching != 0) > 1) {\n-\t\tfprintf(stderr, \"--all and --matching are mutual exclusive.\\n\");\n+\tif ((all != 0) + (matching != 0) + (current != 0) > 1) {\n+\t\tfprintf(stderr, \"--all, --matching, and --current are mutual exclusive.\\n\");\n \t\tusage_with_options(push_usage, options);\n \t}\n-\tif ((all || matching) && refspec)\n+\tif ((all || matching || current) && refspec)\n \t\tusage_with_options(push_usage, options);\n-\tif (!all && !matching && !refspec)\n+\tif (!all && !matching && !current && !refspec)\n \t\tfprintf(stderr, \"Warning: assuming '--matching'.\"\n \t\t \" This default will change in the future.\\n\");\n+\tif (current) {\n+\t\tconst char* head[1] = { \"HEAD\" };\n+\t\tset_refspecs(head, 1);\n+\t}\n \n \treturn do_push(repo, flags);\n }\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 21aa7c3..20e0796 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -113,6 +113,18 @@ test_expect_success 'push command line options (3)' '\n \tgrep -q \"Warning: assuming.*--matching\" stderr.txt\n '\n \n+test_expect_code 129 'push command line options (4)' '\n+\tgit push --all --current testrepo\n+'\n+\n+test_expect_code 129 'push command line options (5)' '\n+\tgit push --matching --current testrepo\n+'\n+\n+test_expect_code 129 'push command line options (6)' '\n+\tgit push --current testrepo master\n+'\n+\n test_expect_success 'push without wildcard' '\n \tmk_empty &&\n \n@@ -284,6 +296,23 @@ test_expect_success 'push with HEAD nonexisting at remote' '\n \tcheck_push_result $the_commit heads/local\n '\n \n+test_expect_success 'push with --current' '\n+\n+\tmk_test heads/master &&\n+\tgit checkout master &&\n+\tgit push --current testrepo &&\n+\tcheck_push_result $the_commit heads/master\n+\n+'\n+\n+test_expect_success 'push with --current nonexisting at remote' '\n+\n+\tmk_test heads/master &&\n+\tgit checkout local &&\n+\tgit push --current testrepo &&\n+\tcheck_push_result $the_commit heads/local\n+'\n+\n test_expect_success 'push with dry-run' '\n \n \tmk_test heads/master &&\n-- \n1.5.3.5.743.g87c5c\n"},{"id":"60262","messageId":"7vwssfqb0w.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"119540238994-git-send-email-prohaska@zib.de","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T01:28:15Z","receivedAt":"2007-11-19T01:28:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> Often you want to push only the current branch to the default\n> remote. This was awkward to do in the past.\n\nWhile I think --current is a handy shorthand to have, I do not\nthink the above description is correct.\n\nWouldn't your earlier patch have allowed the configuration setting:\n\n\t[remote \"$there\"]\n \tpush = HEAD\n\t[branch \"$current\"]\n \tremote = $there\n\nto work very well already?\n\nI do not think it is \"Often you want\" that makes it awkward.\n\nInstead, the awkward case is if you do the \"only the current\"\npush NOT often enough. If it is often enough, you set the\nconfiguration once and the awkwardness is behind you.\n\nIf however it is not often enough, you cannot afford to have the\nconfiguration above, because that would force you to tell from\nthe command line which branches, not just the current one, to\npush, and that is inconvenient because it is not rare enough.\n\nTogether with your [PATCH 1/2], I like the general direction\nthese patckes are taking us, but it feels a bit too hasty. I\npersonally am not convinced that switching to --current for\neverybody is a good move.\n\n> ...\n> Maybe in two years (that's twice an eternity in git time scales):\n>\n> 4) make \"git push --current\" the default.\n\nIf these, both the uncertainly expressed by \"Maybe\" and \"twice\nan eternity\" are true, which they are, the new warning in the\ncurrent patch are inappropriate. Many people's settings depend\non a working \"push the matching refs\" behaviour, and we need a\nvery good excuse to annoy the existing happy users with such a\nwarning.\n\nRemember, how much vocal the dissenters might have been on the\nlist in the recent discussions, we need to consider the needs of\nthe silent majority that has been content with the current\nbehaviour for a long time.\n\nThe \"warning\" to annoy them may be a way to get their attention\nand get them involved in a discussion to decide what the default\nshould be. But changing the default without giving the people\nwho do not like the _new_ default a way to avoid inconvenience\nof always typing --matching or --current is not nice. And\nhonestly, I do not think there is one single default that is\ngood for everybody.\n\nWe should be doing better.\n\nA smoother transition route would be:\n\n - Keep \"matching\" the built-in default for now;\n\n - Take your patches (but drop \"warning\" bits at this point) to\n introduce 'matching' and 'current' behaviours, and a way to\n override the built-in default from the command line;\n\n - Introduce a configuration 'push.defaultRefs' ('matching' or\n 'current') to override that built-in default, so people who\n prefer 'current' can override the built-in default, without\n having to type --current every time.\n\nAfter all that happens, we can start discussing what the\nbuilt-in default should be. When it is changed after the\ndiscussion concludes (which may never happen), people who want\nto keep 'matching' behaviour would have had the configuration\nmechanism to override that built-in default for some time during\nthe discussion period. So the beginning of that discussion\nperiod is when we should start talking about \"We might change\nthe default soon; set the configuration to your liking if you do\nnot want to get affected\" in the warning.\n\nThen after that, we may or may not decide to change the default.\nEven if we end up not changing the default, 'current' people\nwill then have a way (push.matching = false) to tailor their git\nfor their liking, so everybody wins.\n\n> DESCRIPTION\n> @@ -63,6 +63,12 @@ the remote repository.\n> \tInstead of naming each ref to push, specifies that all\n> \trefs under `$GIT_DIR/refs/heads/` be pushed.\n> \n> +\\--matching::\n> +\tInstead of naming each ref to push, specifies that matching\n> +\trefs under `$GIT_DIR/refs/heads/` be pushed. Matching means\n> +\tthe branch exists locally and at the remote under the same name.\n> +\tCurrently, this is the default. But this will change in the future.\n\nFor the above reason, \"But this will...\" is a bit premature.\n"},{"id":"60268","messageId":"EA5C3227-12E1-43C4-96E8-43BABF26792B@zib.de","threadId":"10420","inReplyTo":"7vwssfqb0w.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-19T06:41:59Z","receivedAt":"2007-11-19T06:41:59Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 19, 2007, at 2:28 AM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> Often you want to push only the current branch to the default\n>> remote. This was awkward to do in the past.\n>\n> While I think --current is a handy shorthand to have, I do not\n> think the above description is correct.\n>\n> Wouldn't your earlier patch have allowed the configuration setting:\n>\n> \t[remote \"$there\"]\n> \tpush = HEAD\n> \t[branch \"$current\"]\n> \tremote = $there\n>\n> to work very well already?\n\nNo. This was the case in the verst first version of the patch\nseries. Someone, I don't remember who, proposed to put the\nresolution of HEAD into builtin-push.c. This simplified code\na lot. Now, HEAD is resolved when parsing the command line.\nAt that time it is replaced with the full local refname.\nThe refspec parsing code never sees HEAD, and it won't\nunderstand it. Try the above setup, and you'll see that it\ndoesn't work.\n\nAnyway it's not needed if we proceed as outlined below.\n\n\n> I do not think it is \"Often you want\" that makes it awkward.\n>\n> Instead, the awkward case is if you do the \"only the current\"\n> push NOT often enough. If it is often enough, you set the\n> configuration once and the awkwardness is behind you.\n>\n> If however it is not often enough, you cannot afford to have the\n> configuration above, because that would force you to tell from\n> the command line which branches, not just the current one, to\n> push, and that is inconvenient because it is not rare enough.\n\nWill try to rephrase the commit message.\n\n\n> Together with your [PATCH 1/2], I like the general direction\n> these patckes are taking us, but it feels a bit too hasty. I\n> personally am not convinced that switching to --current for\n> everybody is a good move.\n>\n>> ...\n>> Maybe in two years (that's twice an eternity in git time scales):\n>>\n>> 4) make \"git push --current\" the default.\n>\n> If these, both the uncertainly expressed by \"Maybe\" and \"twice\n> an eternity\" are true, which they are, the new warning in the\n> current patch are inappropriate. Many people's settings depend\n> on a working \"push the matching refs\" behaviour, and we need a\n> very good excuse to annoy the existing happy users with such a\n> warning.\n\nI think 3) is the interesting case. \"git push\" should do\nnothing by default. Either you can configure \"git push\" to do\nsomething by setting a remote.$remote.push line or you need\nto provide a command line switch. But if you do not tell\nexplicitly what you want, \"git push\" will not do anything\nfor you.\n\nI'm not sure if we ever switch to 4). But already with 3) the\ndefault changed. So a warning seems to be appropriate. But if\nwe go as outlined below, it's probably a different warning.\n\nI attached a patch that illustrates what \"do nothing by default\"\nmeans. This patch should _not_ be applied. It's only an\nillustration what I'm working on.\n\n\n> Remember, how much vocal the dissenters might have been on the\n> list in the recent discussions, we need to consider the needs of\n> the silent majority that has been content with the current\n> behaviour for a long time.\n>\n> The \"warning\" to annoy them may be a way to get their attention\n> and get them involved in a discussion to decide what the default\n> should be. But changing the default without giving the people\n> who do not like the _new_ default a way to avoid inconvenience\n> of always typing --matching or --current is not nice. And\n> honestly, I do not think there is one single default that is\n> good for everybody.\n\nPersonally, I'd switch to the do-nothing default immediately.\nBut you are right. More work is needed to have a smooth transition.\n\n\n> We should be doing better.\n>\n> A smoother transition route would be:\n>\n> - Keep \"matching\" the built-in default for now;\n>\n> - Take your patches (but drop \"warning\" bits at this point) to\n> introduce 'matching' and 'current' behaviours, and a way to\n> override the built-in default from the command line;\n>\n> - Introduce a configuration 'push.defaultRefs' ('matching' or\n> 'current') to override that built-in default, so people who\n> prefer 'current' can override the built-in default, without\n> having to type --current every time.\n\nSounds like a plan.\n\nIf we have the configuration variable, maybe we could switch\noff the default behaviour immediately. Setting a single global\nconfig variable once would be sufficient to get it back. So,\nwe could change the default and print a recommendation to run\n'git config --global push.defaultRefs matching' to get it back.\n\n...\n\n> After all that happens, we can start discussing what the\n> built-in default should be. When it is changed after the\n> discussion concludes (which may never happen), people who want\n> to keep 'matching' behaviour would have had the configuration\n> mechanism to override that built-in default for some time during\n> the discussion period. So the beginning of that discussion\n> period is when we should start talking about \"We might change\n> the default soon; set the configuration to your liking if you do\n> not want to get affected\" in the warning.\n\n... And we'd not even start the discussion. Because there's no\nneed to. Every user should make a choice, once. We do not\nprovide a default (which obviously will trigger another discussion ;)\n\n\n> Then after that, we may or may not decide to change the default.\n> Even if we end up not changing the default, 'current' people\n> will then have a way (push.matching = false) to tailor their git\n> for their liking, so everybody wins.\n>\n>> DESCRIPTION\n>> @@ -63,6 +63,12 @@ the remote repository.\n>> \tInstead of naming each ref to push, specifies that all\n>> \trefs under `$GIT_DIR/refs/heads/` be pushed.\n>>\n>> +\\--matching::\n>> +\tInstead of naming each ref to push, specifies that matching\n>> +\trefs under `$GIT_DIR/refs/heads/` be pushed. Matching means\n>> +\tthe branch exists locally and at the remote under the same name.\n>> +\tCurrently, this is the default. But this will change in the \n>> future.\n>\n> For the above reason, \"But this will...\" is a bit premature.\n\nI'll change the plan and will come back with a full\nimplementation.\n\nThanks for the helpful comments.\n\n\tSteffen\n\n\n\n\nFrom a97c117794c631f556f87419a3dbaa702b858d95 Mon Sep 17 00:00:00 2001\nFrom: Steffen Prohaska \nDate: Sun, 18 Nov 2007 19:22:30 +0100\nSubject: [PATCH] push: do nothing by default\n\nWe used to push all matching branches. This behaviour\nwas suitable in many situations, but sometimes confusing.\n\nThis commit switches off the default. push now dies instead.\n\nWORK IN PROGRESS. NOT-SIGNED-OFF.\n---\n builtin-push.c | 9 +++++++--\n t/t5516-fetch-push.sh | 13 ++++---------\n 2 files changed, 11 insertions(+), 11 deletions(-)\n\ndiff --git a/builtin-push.c b/builtin-push.c\nindex e5646d4..e637540 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -143,8 +143,13 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tfprintf(stderr, \"--all, --matching, and --current are mutual exclusive.\\n\");\n \t\tusage_with_options(push_usage, options);\n \t}\n-\tif ((all || matching || current) && refspec)\n-\t\tusage_with_options(push_usage, options);\n+\tif (all || matching || current) {\n+\t\tif (refspec)\n+\t\t\tusage_with_options(push_usage, options);\n+\t} else {\n+\t\tif (!refspec)\n+\t\t\tdie(\"No default action found.\");\n+\t}\n \tif (!all && !matching && !current && !refspec)\n \t\tfprintf(stderr, \"Warning: assuming '--matching'.\"\n \t\t \" This default will change in the future.\\n\");\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 20e0796..48689b9 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -108,11 +108,6 @@ test_expect_code 129 'push command line options (2)' '\n \tgit push --matching testrepo master\n '\n \n-test_expect_success 'push command line options (3)' '\n-\tgit push testrepo 2>stderr.txt &&\n-\tgrep -q \"Warning: assuming.*--matching\" stderr.txt\n-'\n-\n test_expect_code 129 'push command line options (4)' '\n \tgit push --all --current testrepo\n '\n@@ -154,7 +149,7 @@ test_expect_success 'push with wildcard' '\n test_expect_success 'push with matching heads' '\n \n \tmk_test heads/master &&\n-\tgit push testrepo &&\n+\tgit push --matching testrepo &&\n \tcheck_push_result $the_commit heads/master\n \n '\n@@ -319,7 +314,7 @@ test_expect_success 'push with dry-run' '\n \tcd testrepo &&\n \told_commit=$(git show-ref -s --verify refs/heads/master) &&\n \tcd .. &&\n-\tgit push --dry-run testrepo &&\n+\tgit push --dry-run --matching testrepo &&\n \tcheck_push_result $old_commit heads/master\n '\n \n@@ -331,7 +326,7 @@ test_expect_success 'push updates local refs' '\n \tcd .. &&\n \tgit clone parent child && cd child &&\n \t\techo two >foo && git commit -a -m two &&\n-\t\tgit push &&\n+\t\tgit push --matching &&\n \ttest $(git rev-parse master) = $(git rev-parse remotes/origin/master)\n \n '\n@@ -346,7 +341,7 @@ test_expect_success 'push does not update local refs on failure' '\n \tcd .. &&\n \tgit clone parent child && cd child &&\n \t\techo two >foo && git commit -a -m two || exit 1\n-\t\tgit push && exit 1\n+\t\tgit push --matching && exit 1\n \ttest $(git rev-parse master) != $(git rev-parse remotes/origin/master)\n \n '\n-- \n1.5.3.5.750.gc43b\n\n\n\n\n"},{"id":"60270","messageId":"7vejempudf.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"EA5C3227-12E1-43C4-96E8-43BABF26792B@zib.de","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T07:27:56Z","receivedAt":"2007-11-19T07:27:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n>> Together with your [PATCH 1/2], I like the general direction\n>> these patckes are taking us, but it feels a bit too hasty. I\n>> personally am not convinced that switching to --current for\n>> everybody is a good move.\n>>\n>>> ...\n>>\n> I think 3) is the interesting case. \"git push\" should do\n> nothing by default.\n\nNO WAY.\n\nMaking things cumbersome to everybody does not achieve anything\nuseful except for a false sense of equality, does it?\n\nDrop that step (3). That is not useful to anybody.\n"},{"id":"60273","messageId":"7v4pfiptb5.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vejempudf.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T07:50:54Z","receivedAt":"2007-11-19T07:50:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Steffen Prohaska writes:\n> ...\n>> I think 3) is the interesting case. \"git push\" should do\n>> nothing by default.\n>\n> NO WAY.\n>\n> Making things cumbersome to everybody does not achieve anything\n> useful except for a false sense of equality, does it?\n>\n> Drop that step (3). That is not useful to anybody.\n\nThinking about it a bit more, I think my wording was a bit too\nstrong and needs clarifying explanations.\n\nIn a case like this, a fix of a \"misfeature\" for somebody is a\nregression for somebody else. Because there is no single right\ndefault that is appropriate for everybody.\n\nAt least having _one_ default (and picking arbitrarily the\nhistorical default as that one default) is better than no\ndefault at all. The former will not inconvenience anybody by\nforcing what has been necessary from before. The latter will\nhurt the lucky ones whose preferred way happened to be the\nhistorical default.\n\nKeeping the status quo, however, will inconvinience unfortunate\npeople whose preferred way was not the historical default.\nThat's where we start to tackle the problem, by introducing the\nconfiguration variable.\n\nIf we can come up with a way to tell projects that use the\nworkflow better served with --current, perhaps when a remote is\nadded to the repository (either the initial clone or \"git remote\nadd\") and/or when a new branch is created. If we automatically\nset up the configuration \"push.defaultRefs = current\" in such a\ncase, I suspect that we do not have to have the built-in default\n(at least, the value of the built-in default would not matter\nmuch).\n"},{"id":"60276","messageId":"53F12F4D-73C5-446E-9A97-9D2D4CA9DF9F@zib.de","threadId":"10420","inReplyTo":"7vejempudf.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-19T08:17:06Z","receivedAt":"2007-11-19T08:17:06Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 19, 2007, at 8:27 AM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>>> Together with your [PATCH 1/2], I like the general direction\n>>> these patckes are taking us, but it feels a bit too hasty. I\n>>> personally am not convinced that switching to --current for\n>>> everybody is a good move.\n>>>\n>>>> ...\n>>>\n>> I think 3) is the interesting case. \"git push\" should do\n>> nothing by default.\n>\n> NO WAY.\n>\n> Making things cumbersome to everybody does not achieve anything\n> useful except for a false sense of equality, does it?\n\nIf forces people to make a decision. And it will hopefully reduce\nthe amount of questions\n\"What does '! [rejected] master -> master (non-fast forward)' mean\"?\nAt least I am pretty sure that it will reduce the number of\ntimes I'll be asked this question. Because I'll ask people to\nset a reasonable default. But if they forget to do so, they'll be\nreminded by \"git push\", before calling me.\n\nAnd with \"push.defaultRefs = matching\" it's easy to tell push\nonce and forever which decision you made.\n\n\n> Drop that step (3). That is not useful to anybody.\n\n\n From you follow-up mail:\n\n> Thinking about it a bit more, I think my wording was a bit too\n> strong and needs clarifying explanations.\n>\n> In a case like this, a fix of a \"misfeature\" for somebody is a\n> regression for somebody else. Because there is no single right\n> default that is appropriate for everybody.\n>\n> At least having _one_ default (and picking arbitrarily the\n> historical default as that one default) is better than no\n> default at all. The former will not inconvenience anybody by\n> forcing what has been necessary from before. The latter will\n> hurt the lucky ones whose preferred way happened to be the\n> historical default.\n\nWell, here we disagree. My point is: if there's no single\nright default, then it's better to force the user to make\nthe decision.\n\n\n> Keeping the status quo, however, will inconvinience unfortunate\n> people whose preferred way was not the historical default.\n> That's where we start to tackle the problem, by introducing the\n> configuration variable.\n>\n> If we can come up with a way to tell projects that use the\n> workflow better served with --current, perhaps when a remote is\n> added to the repository (either the initial clone or \"git remote\n> add\") and/or when a new branch is created. If we automatically\n> set up the configuration \"push.defaultRefs = current\" in such a\n> case, I suspect that we do not have to have the built-in default\n> (at least, the value of the built-in default would not matter\n> much).\n\nThat's beyond what I plan to implement.\n\nAnyway, I'll not change the default behaviour.\n\nBut then, if I think a bit more, I don't see a point in\nproviding the push.defaultRefs configuration. The default\n_is_ and _will forever be_ '--matching'. That's it. If a\nuser wants to have something different, either he needs to\ntell on the command line (e.g. '--all', '--current'); or he\ncan use the a remote.*.push configuration.\n\nThat's easier to explain than a configuration variable\n\"push.defaultRefs\", which he can set to \"current\". Or he is\nallowed to set it to \"matching\" without triggering an error. But\nthis wouldn't change anything, because it's the default anyway.\nThen why should someone ever set it to \"matching\"?\n\nAnd further, if we have no plans for changing the default, it's\nuseless to introduce a switch \"--matching\". So if the plan is\nto stick with the current default forever, then I'll withdraw\nmy patch that introduces \"--matching\".\n\nWhat's left is a new switch \"--current\". Less code, easy\nto explain.\n\n\tSteffen\n"},{"id":"60278","messageId":"7vk5oeocnr.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"53F12F4D-73C5-446E-9A97-9D2D4CA9DF9F@zib.de","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T08:35:52Z","receivedAt":"2007-11-19T08:35:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steffen Prohaska writes:\n\n> What's left is a new switch \"--current\". Less code, easy\n> to explain.\n\nBut won't that force the \"current\" people always type that from\nthe command line, as your previous point was that your earlier\npatch to say \"remote.$there.push = HEAD\" does not work that way?\nIf that configuration works as expected, then I'd 100% agree\nthat we would not need push.defaultRefs. Either you do not have\n\"push\" at all if your preference is --matching, or you do have\n\"push = HEAD\" if your preference is --current. But if it\ndoesn't (which was what I gathered from your earlier response),\nhaving a configuration would help them, wouldn't it?\n\nChanging the default, if it will ever happen, is _NOT_ to help\npeople who are already using git and want \"current\" NOW. The\ncurrent users cannot be helped _unless_ we switch overnight, but\nthat is not an option as it introduces a regression to people's\nestablished workflow.\n\nChanging the default is to help new users who will come in the\nfuture, if majority of the existing users find --current easier\nto explain to new people _they_ need to train.\n"},{"id":"60281","messageId":"4741565E.1020500@op5.se","threadId":"10420","inReplyTo":"EA5C3227-12E1-43C4-96E8-43BABF26792B@zib.de","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-19T09:24:46Z","receivedAt":"2007-11-19T09:24:46Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Steffen Prohaska wrote:\n> \n> On Nov 19, 2007, at 2:28 AM, Junio C Hamano wrote:\n> \n> \n> \n>> I do not think it is \"Often you want\" that makes it awkward.\n>>\n>> Instead, the awkward case is if you do the \"only the current\"\n>> push NOT often enough. If it is often enough, you set the\n>> configuration once and the awkwardness is behind you.\n>>\n>> If however it is not often enough, you cannot afford to have the\n>> configuration above, because that would force you to tell from\n>> the command line which branches, not just the current one, to\n>> push, and that is inconvenient because it is not rare enough.\n> \n> Will try to rephrase the commit message.\n> \n> \n>> Together with your [PATCH 1/2], I like the general direction\n>> these patckes are taking us, but it feels a bit too hasty. I\n>> personally am not convinced that switching to --current for\n>> everybody is a good move.\n>>\n>>> ...\n>>> Maybe in two years (that's twice an eternity in git time scales):\n>>>\n>>> 4) make \"git push --current\" the default.\n>>\n>> If these, both the uncertainly expressed by \"Maybe\" and \"twice\n>> an eternity\" are true, which they are, the new warning in the\n>> current patch are inappropriate. Many people's settings depend\n>> on a working \"push the matching refs\" behaviour, and we need a\n>> very good excuse to annoy the existing happy users with such a\n>> warning.\n> \n> I think 3) is the interesting case. \"git push\" should do\n> nothing by default. Either you can configure \"git push\" to do\n> something by setting a remote.$remote.push line or you need\n> to provide a command line switch. But if you do not tell\n> explicitly what you want, \"git push\" will not do anything\n> for you.\n> \n\nI'd really, really hate that. I often have changes on several branches\nwhen I push. I like the behaviour as it is today.\n\n> \n>> Remember, how much vocal the dissenters might have been on the\n>> list in the recent discussions, we need to consider the needs of\n>> the silent majority that has been content with the current\n>> behaviour for a long time.\n>>\n>> The \"warning\" to annoy them may be a way to get their attention\n>> and get them involved in a discussion to decide what the default\n>> should be. But changing the default without giving the people\n>> who do not like the _new_ default a way to avoid inconvenience\n>> of always typing --matching or --current is not nice. And\n>> honestly, I do not think there is one single default that is\n>> good for everybody.\n> \n> Personally, I'd switch to the do-nothing default immediately.\n> But you are right. More work is needed to have a smooth transition.\n> \n> \n>> We should be doing better.\n>>\n>> A smoother transition route would be:\n>>\n>> - Keep \"matching\" the built-in default for now;\n>>\n>> - Take your patches (but drop \"warning\" bits at this point) to\n>> introduce 'matching' and 'current' behaviours, and a way to\n>> override the built-in default from the command line;\n>>\n>> - Introduce a configuration 'push.defaultRefs' ('matching' or\n>> 'current') to override that built-in default, so people who\n>> prefer 'current' can override the built-in default, without\n>> having to type --current every time.\n> \n> Sounds like a plan.\n> \n> If we have the configuration variable, maybe we could switch\n> off the default behaviour immediately. Setting a single global\n> config variable once would be sufficient to get it back. So,\n> we could change the default and print a recommendation to run\n> 'git config --global push.defaultRefs matching' to get it back.\n> \n\nUgh. People who neither know nor care about git development will\nwonder why the hell they now have to tell git something in order\nfor it to do something it's always done anyway. The majority of\ngit users never read release-notes. They just do \"yum update\" and\nthen go about their business the same way they've always done.\n\nNewcomers that obviously have no such configuration will wonder\nwhy they're getting warnings from using the standard command-set.\n\n> ...\n> \n>> After all that happens, we can start discussing what the\n>> built-in default should be. When it is changed after the\n>> discussion concludes (which may never happen), people who want\n>> to keep 'matching' behaviour would have had the configuration\n>> mechanism to override that built-in default for some time during\n>> the discussion period. So the beginning of that discussion\n>> period is when we should start talking about \"We might change\n>> the default soon; set the configuration to your liking if you do\n>> not want to get affected\" in the warning.\n> \n> ... And we'd not even start the discussion. Because there's no\n> need to. Every user should make a choice, once. We do not\n> provide a default (which obviously will trigger another discussion ;)\n> \n\nIf the default's to be changed, making it default to no-op is really\nthe only sensible thing to do. Otherwise I'm guessing a lot of people\nthat actually count on the current behaviour will get quite vexed, and\n--current is definitely not the universally correct default thing to do.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60282","messageId":"47415711.7060507@op5.se","threadId":"10420","inReplyTo":"7v4pfiptb5.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-19T09:27:45Z","receivedAt":"2007-11-19T09:27:45Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> If we can come up with a way to tell projects that use the\n> workflow better served with --current, perhaps when a remote is\n> added to the repository (either the initial clone or \"git remote\n> add\") and/or when a new branch is created. If we automatically\n> set up the configuration \"push.defaultRefs = current\" in such a\n> case, I suspect that we do not have to have the built-in default\n> (at least, the value of the built-in default would not matter\n> much).\n\nSo when someone who's been using git of today adds a new remote\nwith a newer git, all of a sudden the default push behaviour\nchanges for that repo?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60284","messageId":"3FB7B6E8-FC22-4FDF-BDAD-08312202B29A@zib.de","threadId":"10420","inReplyTo":"7vk5oeocnr.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-19T09:54:55Z","receivedAt":"2007-11-19T09:54:55Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 19, 2007, at 9:35 AM, Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n>\n>> What's left is a new switch \"--current\". Less code, easy\n>> to explain.\n>\n> But won't that force the \"current\" people always type that from\n> the command line, as your previous point was that your earlier\n> patch to say \"remote.$there.push = HEAD\" does not work that way?\n> If that configuration works as expected, then I'd 100% agree\n> that we would not need push.defaultRefs. Either you do not have\n> \"push\" at all if your preference is --matching, or you do have\n> \"push = HEAD\" if your preference is --current. But if it\n> doesn't (which was what I gathered from your earlier response),\n> having a configuration would help them, wouldn't it?\n\nMy main point is that I want to have something that _always_\nworks as expected without manually tweaking the configuration\nvariables. In a setting with shared repos, \"git push\" doesn't.\nSooner or later it will complain about refusing an update\nbecause of non-fast-forward. The only thing that currently\nworks it \"git push $correct-remote $correct-branch\", but this\ndepends on the local configuration and on the branch you're on.\n\n\"git push --current\" would always work as expected; without\nsetting any configuration variable.\n\nI can tell my users that their workflow is\n\n\tgit checkout foo\n\tgit pull\n\twork work work ...\n\tgit push --current\n\nThat simple. I'm fine with that.\n\n\n> Changing the default, if it will ever happen, is _NOT_ to help\n> people who are already using git and want \"current\" NOW. The\n> current users cannot be helped _unless_ we switch overnight, but\n> that is not an option as it introduces a regression to people's\n> established workflow.\n>\n> Changing the default is to help new users who will come in the\n> future, if majority of the existing users find --current easier\n> to explain to new people _they_ need to train.\n\nI'll not change the default. I'll only add the --current switch.\n\n\tSteffen\n"},{"id":"60291","messageId":"fhrrbt$lvk$1@ger.gmane.org","threadId":"10420","inReplyTo":"7vk5oeocnr.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-19T11:17:17Z","receivedAt":"2007-11-19T11:17:17Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Steffen Prohaska writes:\n> \n>> What's left is a new switch \"--current\". Less code, easy\n>> to explain.\n> \n> But won't that force the \"current\" people always type that from\n> the command line, as your previous point was that your earlier\n> patch to say \"remote.$there.push = HEAD\" does not work that way?\n> If that configuration works as expected, then I'd 100% agree\n> that we would not need push.defaultRefs. Either you do not have\n> \"push\" at all if your preference is --matching, or you do have\n> \"push = HEAD\" if your preference is --current. But if it\n> doesn't (which was what I gathered from your earlier response),\n> having a configuration would help them, wouldn't it?\n\nBrief recap, to check if I understand things correctly:\n\n1. If you use \"matching\" more often, then it should be enough to provide\n remote..push with refspec or wildcard refspec. \"git push\"\n would push matching. If one wants to push only current branch, one\n would use \"git push --current\" or \"git push HEAD\".\n\n Question: what to do if there is no remote..push? Assume\n 1-1 matching?\n\n2. If you use \"current\" more often, then it should be anough (after\n correcting git; although it was written that it is quite a bit of work)\n to provide \"remote..push = HEAD\", or \n \"push.defaultRefs = current\" if one wants to set this up for all\n remotes, or perhaps \"remote.*.push = HEAD\". \"git push\" would push\n current. If one wants to push matching, one would use \"git push\n --matching\"... although for matching one needs remote configured...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"60329","messageId":"11954911172958-git-send-email-prohaska@zib.de","threadId":"10420","inReplyTo":"3FB7B6E8-FC22-4FDF-BDAD-08312202B29A@zib.de","subject":"[PATCH] push: Add \"--current\", which pushes only the current branch","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-19T16:51:57Z","receivedAt":"2007-11-19T16:51:57Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"Pushing only the current branch to the default remote was awkward\nin the past. You needed to remember the default remote and type\n\"git push $remote $current\". A recent commit added support for\n\"git push $remote HEAD\". But still you need to remember and type\nthe remote.\n\nThis commit teaches push a short-cut: \"git push --current\" now\npushes the current branch to the default remote.\n\nNote, this commit doesn't save you much if you want to push the\ncurrent branch to a remote that is not the default: You can now\nsay either \"git push --current foo\" or \"git push foo HEAD\".\n\nSigned-off-by: Steffen Prohaska \n---\n Documentation/git-push.txt | 6 +++++-\n builtin-push.c | 14 ++++++++++++--\n t/t5516-fetch-push.sh | 25 +++++++++++++++++++++++++\n 3 files changed, 42 insertions(+), 3 deletions(-)\n\nEventually, I gave in. I accepted that the default is to push\nmatching branches. I'll not send further patches that try to\nchange this. This is the last patch.\n\nThe patch applies on top of sp/refspec-match.\n\n Steffen\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex 4a68aab..6ec6078 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects\n SYNOPSIS\n --------\n [verse]\n-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=]\n+'git-push' [--all] [--current] [--dry-run] [--tags] [--receive-pack=]\n [--repo=all] [-f | --force] [-v | --verbose] [ ...]\n \n DESCRIPTION\n@@ -63,6 +63,10 @@ the remote repository.\n \tInstead of naming each ref to push, specifies that all\n \trefs under `$GIT_DIR/refs/heads/` be pushed.\n \n+\\--current::\n+\tInstead of naming each ref to push, specifies that only the\n+\tcurrent branch is pushed.\n+\n \\--dry-run::\n \tDo everything except actually send the updates.\n \ndiff --git a/builtin-push.c b/builtin-push.c\nindex 54fba0e..c5243ca 100644\n--- a/builtin-push.c\n+++ b/builtin-push.c\n@@ -10,7 +10,7 @@\n #include \"parse-options.h\"\n \n static const char * const push_usage[] = {\n-\t\"git-push [--all] [--dry-run] [--tags] [--receive-pack=] [--repo=all] [-f | --force] [-v] [ ...]\",\n+\t\"git-push [--all] [--current] [--dry-run] [--tags] [--receive-pack=] [--repo=all] [-f | --force] [-v] [ ...]\",\n \tNULL,\n };\n \n@@ -100,6 +100,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n {\n \tint flags = 0;\n \tint all = 0;\n+\tint current = 0;\n \tint dry_run = 0;\n \tint force = 0;\n \tint tags = 0;\n@@ -109,6 +110,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\tOPT__VERBOSE(&verbose),\n \t\tOPT_STRING( 0 , \"repo\", &repo, \"repository\", \"repository\"),\n \t\tOPT_BOOLEAN( 0 , \"all\", &all, \"push all refs\"),\n+\t\tOPT_BOOLEAN( 0 , \"current\", ¤t, \"push current branch\"),\n \t\tOPT_BOOLEAN( 0 , \"tags\", &tags, \"push tags\"),\n \t\tOPT_BOOLEAN( 0 , \"dry-run\", &dry_run, \"dry run\"),\n \t\tOPT_BOOLEAN('f', \"force\", &force, \"force updates\"),\n@@ -135,8 +137,16 @@ int cmd_push(int argc, const char **argv, const char *prefix)\n \t\trepo = argv[0];\n \t\tset_refspecs(argv + 1, argc - 1);\n \t}\n-\tif ((flags & TRANSPORT_PUSH_ALL) && refspec)\n+\tif ((all != 0) + (current != 0) > 1) {\n+\t\tfprintf(stderr, \"--all and --current are mutual exclusive.\\n\");\n \t\tusage_with_options(push_usage, options);\n+\t}\n+\tif ((all || current) && refspec)\n+\t\tusage_with_options(push_usage, options);\n+\tif (current) {\n+\t\tconst char* head[1] = { \"HEAD\" };\n+\t\tset_refspecs(head, 1);\n+\t}\n \n \treturn do_push(repo, flags);\n }\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex fd5f284..11c078a 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -100,6 +100,14 @@ test_expect_success 'fetch with wildcard' '\n \t)\n '\n \n+test_expect_code 129 'push: --current and --all mutual exclusive' '\n+\tgit push --all --current testrepo\n+'\n+\n+test_expect_code 129 'push: --current and refspec mutual exclusive' '\n+\tgit push --current testrepo master\n+'\n+\n test_expect_success 'push without wildcard' '\n \tmk_empty &&\n \n@@ -271,6 +279,23 @@ test_expect_success 'push with HEAD nonexisting at remote' '\n \tcheck_push_result $the_commit heads/local\n '\n \n+test_expect_success 'push with --current' '\n+\n+\tmk_test heads/master &&\n+\tgit checkout master &&\n+\tgit push --current testrepo &&\n+\tcheck_push_result $the_commit heads/master\n+\n+'\n+\n+test_expect_success 'push with --current nonexisting at remote' '\n+\n+\tmk_test heads/master &&\n+\tgit checkout local &&\n+\tgit push --current testrepo &&\n+\tcheck_push_result $the_commit heads/local\n+'\n+\n test_expect_success 'push with dry-run' '\n \n \tmk_test heads/master &&\n-- \n1.5.3.5.742.gb61a8b\n"},{"id":"60356","messageId":"7vy7cum2k1.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"fhrrbt$lvk$1@ger.gmane.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T19:57:02Z","receivedAt":"2007-11-19T19:57:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Brief recap, to check if I understand things correctly:\n>\n> 1. If you use \"matching\" more often, then it should be enough to provide\n> remote..push with refspec or wildcard refspec.\n\nEh, excuse me, what refspec would you write there? \"matching\"\nis defined to push the intersection of what we have and what\nthey have when \"git-push\" is run. I do not think there is any\nway to write that in remote.$there.push and cast in stone.\n\nWith \"matching\", you can arrange a set of semi-permanent\nbranches to be shown to others and let others build on, in\neither \"publishing\" or \"shared repository\" model, while keeping\nexperimental branches in your private repository, and:\n\n\t$ git push $there\n\nwill only send what are in \"the set of semi-permament branches\",\nlike 'master' and 'maint. Adding a new branch to that set is\njust the matter of a one-shot:\n\n\t$ git push $there next\n\n(older git may have choked and asked you to be more explicit by\n\"next:refs/heads/next\"). After you do it once, \"matching\" will\npush 'master', 'maint', 'next' without any additional\nconfiguration. Removing a branch from the set is also just a\nmatter of one-shot:\n\n\t$ git push $there :next\n\nWhen you replace 'next' in the above with something that is a\nlot short lived, the principle is the same. I can push a topic\nbranch (say, jn/gitweb), asking \"I have queued your patches but\nI am having trouble merging this back to 'master' due to heavy\nconflicts; could you do the honors instead?\". While waiting for\nyou to respond to that request, I may add more commits to that\nbranch and the \"matching\" push by me will update what is shown\n$there. Hopefully you would eventually pick it up and merge,\nand either push the result back to my 'master' directly or\npublish the result elsewhere for me to pull to my 'master'.\n\nAfter all the interaction is done, the topic branch does not\nhave to stay $there and can be deleted. Then 'matching' will\nnot touch the topic branch anymore, even if I still keep it\nprivately in my repository.\n\n> ... If one wants to push only current branch, one\n> would use \"git push --current\" or \"git push HEAD\".\n\nI think that is the proposal by Steffen (added back CC).\n\nI am wondering if an alternative approach could be simpler. If\nwe teach \"git-push\" to notice when only the refspecs are given\nwithout remotename, and default to branch.$current.remote in\nsuch a case, IOW, make these:\n\n\t$ git push HEAD\n $ git push next\n\npush the obvious thing to the default remote, I _think_ we can\nachieve the same effect as --current and a bit more.\n\nThe latter could be run after I made the 'next' integration\nbranch into a good shape, switched to 'pu' to merge up other\nbits but before finishing that merging yet (it would not help me\npersonally as I do not work that way --- I push things out only\nafter I am done with all the public branches --- but it may help\nthe others).\n\n> Question: what to do if there is no remote..push? Assume\n> 1-1 matching?\n\nOne-to-one is what 'matching' does, and the way to trigger it is\nnot to have a remote.$there.push.\n"},{"id":"60363","messageId":"200711192204.26772.jnareb@gmail.com","threadId":"10420","inReplyTo":"7vy7cum2k1.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-19T21:04:25Z","receivedAt":"2007-11-19T21:04:25Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>> Brief recap, to check if I understand things correctly:\n>>\n>> 1. If you use \"matching\" more often, then it should be enough\n>> to provide remote..push with refspec or wildcard\n>> refspec. \n> \n> Eh, excuse me, what refspec would you write there? \"matching\"\n> is defined to push the intersection of what we have and what\n> they have when \"git-push\" is run. I do not think there is any\n> way to write that in remote.$there.push and cast in stone.\n[...]\n>> Question: what to do if there is no remote..push?\n>> Assume 1-1 matching?\n> \n> One-to-one is what 'matching' does, and the way to trigger it is\n> not to have a remote.$there.push.\n\nI'm sorry, I had to have \"stupid\" moment. Thanks a lot for complete \nexplanation of git-push, anyway.\n\n\n>> ... If one wants to push only current branch, one\n>> would use \"git push --current\" or \"git push HEAD\".\n> \n> I think that is the proposal by Steffen (added back CC).\n> \n> I am wondering if an alternative approach could be simpler. If\n> we teach \"git-push\" to notice when only the refspecs are given\n> without remotename, and default to branch.$current.remote in\n> such a case, \n\nIncluding default remote when branch..remote is not set?\n\n> IOW, make these: \n> \n> \t$ git push HEAD\n> $ git push next\n> \n> push the obvious thing to the default remote, I _think_ we can\n> achieve the same effect as --current and a bit more.\n\nThe only problem would be when there is conflict between remote name and \nbranch name (for example default \"origin\" remote, and old git \nno-separate-remotes \"origin\" branch, or origin = origin/HEAD).\nPerhaps we can reuse '--' as separator between remote(s) and refspecs \n(branch names); other command use it to separate refname / commit-ish \nfrom pathspec (file name).\n\nSo for scripts it would be \"git push -- HEAD\"; still shorter than\n\"git push --current\".\n\n\nBTW. what would happen for \"git push branch1 branch2\" if branch1 has \ndifferent remote than branch2?\n\n> The latter could be run after I made the 'next' integration\n> branch into a good shape, switched to 'pu' to merge up other\n> bits but before finishing that merging yet (it would not help me\n> personally as I do not work that way --- I push things out only\n> after I am done with all the public branches --- but it may help\n> the others). \n\n-- \nJakub Narebski\nPoland\n"},{"id":"60370","messageId":"7vfxz1naq0.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"200711192204.26772.jnareb@gmail.com","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-19T22:15:19Z","receivedAt":"2007-11-19T22:15:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>> Jakub Narebski writes:\n>> \n>>> Brief recap, to check if I understand things correctly:\n>>>\n>>> 1. If you use \"matching\" more often, then it should be enough\n>>> to provide remote..push with refspec or wildcard\n>>> refspec. \n>> \n>> Eh, excuse me, what refspec would you write there? \"matching\"\n>> is defined to push the intersection of what we have and what\n>> they have when \"git-push\" is run. I do not think there is any\n>> way to write that in remote.$there.push and cast in stone.\n> [...]\n>>> Question: what to do if there is no remote..push?\n>>> Assume 1-1 matching?\n>> \n>> One-to-one is what 'matching' does, and the way to trigger it is\n>> not to have a remote.$there.push.\n>\n> I'm sorry, I had to have \"stupid\" moment. Thanks a lot for complete \n> explanation of git-push, anyway.\n>\n>\n>>> ... If one wants to push only current branch, one\n>>> would use \"git push --current\" or \"git push HEAD\".\n>> \n>> I think that is the proposal by Steffen (added back CC).\n>> \n>> I am wondering if an alternative approach could be simpler. If\n>> we teach \"git-push\" to notice when only the refspecs are given\n>> without remotename, and default to branch.$current.remote in\n>> such a case, \n>\n> Including default remote when branch..remote is not set?\n>\n>> IOW, make these: \n>> \n>> \t$ git push HEAD\n>> $ git push next\n>> \n>> push the obvious thing to the default remote, I _think_ we can\n>> achieve the same effect as --current and a bit more.\n>\n> The only problem would be when there is conflict between remote name and \n> branch name...\n\nYes. *If* we were to do that fallback it has to be something\nlike this:\n\n (1) does $0 look like remote and $1..$n look like a refspec? If\n so do not fallback;\n\n (2) Do we have branch.$current.remote? If not, we cannot\n fallback so error out.\n\n (3) otherwise, does $0 look like a refspec? If so, try insert\n it before the params, treating $0..$n all refspecs.\n\n> So for scripts it would be \"git push -- HEAD\"; still shorter than\n> \"git push --current\".\n\nscripts should be as explicit as they need to be.\n\nWhat matters is the case when the command cannot be explicit,\njust like you cannot write --matching with explicit refspecs.\n\n> BTW. what would happen for \"git push branch1 branch2\" if branch1 has \n> different remote than branch2?\n\nRead my example more carefully. It says \"push HEAD\" and \"push\nnext\" while on 'pu' and it takes branch.pu.remote.\n"},{"id":"60373","messageId":"200711192329.44905.jnareb@gmail.com","threadId":"10420","inReplyTo":"7vfxz1naq0.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] push: Add '--current', which pushes only the current branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-19T22:29:44Z","receivedAt":"2007-11-19T22:29:44Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n>> Junio C Hamano wrote:\n\n>>> IOW, make these: \n>>> \n>>> \t$ git push HEAD\n>>> $ git push next\n>>> \n>>> push the obvious thing to the default remote, I _think_ we can\n>>> achieve the same effect as --current and a bit more.\n>>\n>> The only problem would be when there is conflict between remote name and \n>> branch name...\n\nWhat about idea of using \"--\" to separate remote from branchname?\n\n> Yes. *If* we were to do that fallback it has to be something\n> like this:\n> \n> (1) does $0 look like remote and $1..$n look like a refspec? If\n> so do not fallback;\n\nBy \"look like remote\" you mean that there is [remote \"$0\"] section\nin config (I guess that we can not support old .git/remotes/\nconfiguration for _new_ features, especially that there exist script\nconverting to new way of configuring remotes, contrib/remotes2config.sh)\n \n> (2) Do we have branch.$current.remote? If not, we cannot\n> fallback so error out.\n\nDo not fallback to \"origin\"?\n\n> (3) otherwise, does $0 look like a refspec? If so, try insert\n> it before the params, treating $0..$n all refspecs.\n\nYou mean $0 is existing branch, or of the form branch:?\nOr should we forbid remote names containing ':'?\n\n>> BTW. what would happen for \"git push branch1 branch2\" if branch1 has \n>> different remote than branch2?\n> \n> Read my example more carefully. It says \"push HEAD\" and \"push\n> next\" while on 'pu' and it takes branch.pu.remote.\n\nSomehow I missed that $current means _current branch_ (branch we are on,\nwhich defines default remote). \n\n-- \nJakub Narebski\nPoland\n"},{"id":"60487","messageId":"7vsl30eyuk.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vabpctx3b.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-21T09:23:31Z","receivedAt":"2007-11-21T09:23:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\nJust in case anybody is wondering, this message is updated with\nthe help with a new script UWC in 'todo' branch these days (I\nhave 'todo' checked out in Meta/ directory, so the script is\ncalled Meta/UWC and uses Meta/git-topic.perl script etc.)\n\n----------------------------------------------------------------\n[Will cook further in 'next' and then merge to 'master' soon]\n\n* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit\n + Move gitk to its own subdirectory\n\nI have a phoney Makefile under the subdirectory for gitk, but\nhopefully with the next pull from Paulus I can replace it with\nthe real thing, along with the i18n stuff.\n\n* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits\n + Bisect reset: do nothing when not bisecting.\n + Bisect: use \"$GIT_DIR/BISECT_NAMES\" to check if we are bisecting.\n + Bisect visualize: use \"for-each-ref\" to list all good refs.\n + git-bisect: modernize branch shuffling hack\n + git-bisect: use update-ref to mark good/bad commits\n + git-bisect: war on \"sed\"\n + Bisect reset: remove bisect refs that may have been packed.\n\nWill merge by the weekend (if I can find time, that is).\n\n* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n + Do git reset --hard HEAD when using git rebase --skip\n\nAfter seeing a conflicted rebase, you may decide to skip that\npatch but then you would need \"git reset --hard\" before saying\n\"git rebase --skip\". This teaches \"git rebase --skip\" to\nautomatically discard the conflicted rebase for you.\n\nWill merge by the weekend.\n\n* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits\n + Remove hint to use \"git help -a\"\n + Make the list of common commands more exclusive\n\nSome people on the list may find the exact list of commands\nsomewhat debatable. We can fine-tune that in-tree ('pu' does\nnot count as \"in-tree\").\n\n* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits\n + fetch-pack: Prepare for a side-band demultiplexer in a thread.\n + rehabilitate some t5302 tests on 32-bit off_t machines\n + Allow ETC_GITCONFIG to be a relative path.\n + Introduce git_etc_gitconfig() that encapsulates access of\n ETC_GITCONFIG.\n + Allow a relative builtin template directory.\n + Close files opened by lock_file() before unlinking.\n + builtin run_command: do not exit with -1.\n + Move #include and to git-compat-\n util.h.\n + Use is_absolute_path() in sha1_file.c.\n + Skip t3902-quoted.sh if the file system does not support funny\n names.\n + t5302-pack-index: Skip tests of 64-bit offsets if necessary.\n + t7501-commit.sh: Not all seds understand option -i\n + t5300-pack-object.sh: Split the big verify-pack test into smaller\n parts.\n\nA set of good general clean-up patches.\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits\n - send-pack: cluster ref status reporting\n + send-pack: fix \"everything up-to-date\" message\n + send-pack: tighten remote error reporting\n + make \"find_ref_by_name\" a public function\n + Fix warning about bitfield in struct ref\n + send-pack: assign remote errors to each ref\n + send-pack: check ref->status before updating tracking refs\n + send-pack: track errors for each ref\n + Merge branch 'aw/mirror-push' into jk/send-pack\n + Merge branch 'ar/send-pack-remote-track' into jk/send-pack\n + Merge branch 'db/remote-builtin' into jk/send-pack\n + git-push: add documentation for the newly added --mirror mode\n + Add tests for git push'es mirror mode\n + Update the tracking references only if they were succesfully\n updated on remote\n + Add a test checking if send-pack updated local tracking branches\n correctly\n + git-push: plumb in --mirror mode\n + Teach send-pack a mirror mode\n + Merge master into aw/mirror-push\n + Merge branch 'jk/terse-push' into aw/mirror-push\n + send-pack: segfault fix on forced push\n + Reteach builtin-ls-remote to understand remotes\n + send-pack: require --verbose to show update of tracking refs\n + receive-pack: don't mention successful updates\n + more terse push output\n + Build in ls-remote\n + Build-in send-pack, with an API for other programs to call.\n + Use built-in send-pack.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\nVarious improvements on status reporting and error handling by\nsend-pack, and implementation of \"mirror\" pushing.\n\n* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits\n + Teach git clean to use setup_standard_excludes()\n + git-clean: Fix error message if clean.requireForce is not set.\n + Make git-clean a builtin\n\nIt has a subtle change in behaviour but it does not quite\nqualify as a regression. Will merge to \"next\" shortly. We can\nfix the corner case semantics in-tree. I also adjusted the\nerror message to match the fix from Hannes on 'master'.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\n----------------------------------------------------------------\n[Approaching 'next']\n\n* kh/commit (Sun Nov 18 01:52:55 2007 -0800) 21 commits\n - builtin-commit: fix partial-commit support\n - Fix add_files_to_cache() to take pathspec, not user specified list\n of files\n - Export three helper functions from ls-files\n - builtin-commit: run commit-msg hook with correct message file\n - builtin-commit: do not color status output shown in the message\n template\n - file_exists(): dangling symlinks do exist\n - Replace \"runstatus\" with \"status\" in the tests\n - t7501-commit: Add test for git commit with dirty index.\n - builtin-commit: Clean up an unused variable and a debug fprintf().\n - Call refresh_cache() when updating the user index for --only\n commits.\n - builtin-commit: Add newline when showing which commit was created\n - builtin-commit: resurrect behavior for multiple -m options\n - builtin-commit --s: add a newline if the last line was not a S-o-b\n - builtin-commit: fix --signoff\n - git status: show relative paths when run in a subdirectory\n - builtin-commit: Refresh cache after adding files.\n - builtin-commit: fix reflog message generation\n - launch_editor(): read the file, even when EDITOR=:\n - Port git commit to C.\n - Export launch_editor() and make it accept ':' as a no-op editor.\n - Add testcase for amending and fixing author in git commit.\n\nThere are still a few regressions that keep this series out of\n'next', including the lossage of \"-v\" (final diff review).\n\nBy the way, I am meaning to squash the part that introduces and\nthen fixes builtin-commit.c into a smaller number of commits for\nfuture readability and bisectability (currently the series is\nnot bisectable).\n\n----------------------------------------------------------------\n[Stalled]\n\n* sp/refspec-match (Sun Nov 18 17:13:08 2007 +0100) 6 commits\n - push: Add '--current', which pushes only the current branch\n - push: Add '--matching' option and print warning if it should be\n used\n - refactor fetch's ref matching to use refname_match()\n - push: use same rules as git-rev-parse to resolve refspecs\n - add refname_match()\n - push: support pushing HEAD to real branch name\n\n(\"Stalled\" is my fault, not the author's) This changes the\nsemantics slightly but I think it is a move in the right\ndirection. Perhaps merge the early parts to 'next'; I am not\nentirely happy with the updated --current patch which does not\nappear in this queue.\n\n* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nTeaching \"git apply --whitespace=[warn|strip]\" to honor the same\nconfiguration would be a good addition, but this could go to\n'master' as is.\n\n* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit\n - Make builtin-tag.c use parse_options.\n\nThis changes the handling of multiple -m options without much\ngood reason. It should be a simple fix, once we know what we\nwant. I think the existing behaviour of refusing multiple -m\nis probably the most sane at this point.\n\n* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits\n - Added diff hunk coloring to git-add--interactive\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\nThis series has improved quite a bit since the last round, but\nanother round was requested from the list. Waiting for\nrefinements.\n\n* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n + Add missing inside_work_tree setting in setup_git_directory_gently\n\nThere was an additional patch, which still had issues Dscho\npointed out. Waiting for refinements.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n - Make git-svn rebase --dirty pass along --dirty to git-rebase.\n - Implement --dirty for git-rebase--interactive.\n - Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nThis seems to be optimized for the --dirty case too much. I'd\nprefer an implementation that make rebases without --dirty to\npay no penalty (if that is possible, otherwise \"as little as\npossible\").\n\n----------------------------------------------------------------\n[Others]\n\n* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits\n - git-branch --contains: doc and test\n - git-branch --contains=commit\n - parse-options: Allow to hide options from the default usage.\n\nContains Pierre's \"hidable options with --help-all\" patch. I\nthink this is ready to be in 'next'.\n\n* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n - test format-patch -s: make sure MIME content type is shown as\n needed\n - format-patch -s: add MIME encoding header if signer's name\n requires so\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'master'.\n\n* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit\n - Fix rev-list when showing objects involving submodules\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'next' and will be merged to 'master' soon.\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n - handle renames using similarity engine\n - introduce generic similarity library\n - change hash table calling conventions\n\n* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit\n - revert/cherry-pick: start refactoring call to merge_recursive\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n\nThe second one could probably be used to replace the use of\npath-list in the tip commit on the kh/commit series.\n"},{"id":"60738","messageId":"7vve7tuz3a.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vsl30eyuk.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-23T08:48:25Z","receivedAt":"2007-11-23T08:48:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\nI ran out of time while re-reviewing the stalled topics to\ndecide what to do with them, and many of them are left out of\n'pu' branch for tonight, even though I haven't dropped them\nentirely from my repository yet.\n\nA funny thing is, 'pu' passes most of the testsuite thanks to\nthis temporary droppage. The tip of 'pu' hasn't passed the\ntests for quite some time.\n\nNew tests for svn-info seem to be failing in my private\nrepository at k.org; I haven't tried to look into it yet.\n\n----------------------------------------------------------------\n[Will cook further in 'next' and then merge to 'master' soon]\n\n* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit\n + Move gitk to its own subdirectory\n\nI have a phoney Makefile under the subdirectory for gitk, but\nhopefully with the next pull from Paulus I can replace it with\nthe real thing, along with the i18n stuff.\n\n* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits\n + Bisect reset: do nothing when not bisecting.\n + Bisect: use \"$GIT_DIR/BISECT_NAMES\" to check if we are bisecting.\n + Bisect visualize: use \"for-each-ref\" to list all good refs.\n + git-bisect: modernize branch shuffling hack\n + git-bisect: use update-ref to mark good/bad commits\n + git-bisect: war on \"sed\"\n + Bisect reset: remove bisect refs that may have been packed.\n\nWill merge by the weekend (if I can find time, that is).\n\n* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n + Do git reset --hard HEAD when using git rebase --skip\n\nAfter seeing a conflicted rebase, you may decide to skip that\npatch but then you would need \"git reset --hard\" before saying\n\"git rebase --skip\". This teaches \"git rebase --skip\" to\nautomatically discard the conflicted rebase for you.\n\nWill merge by the weekend.\n\n* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits\n + Remove hint to use \"git help -a\"\n + Make the list of common commands more exclusive\n\nSome people on the list may find the exact list of commands\nsomewhat debatable. We can fine-tune that in-tree ('pu' does\nnot count as \"in-tree\").\n\n* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits\n + fetch-pack: Prepare for a side-band demultiplexer in a thread.\n + rehabilitate some t5302 tests on 32-bit off_t machines\n + Allow ETC_GITCONFIG to be a relative path.\n + Introduce git_etc_gitconfig() that encapsulates access of\n ETC_GITCONFIG.\n + Allow a relative builtin template directory.\n + Close files opened by lock_file() before unlinking.\n + builtin run_command: do not exit with -1.\n + Move #include and to git-compat-\n util.h.\n + Use is_absolute_path() in sha1_file.c.\n + Skip t3902-quoted.sh if the file system does not support funny\n names.\n + t5302-pack-index: Skip tests of 64-bit offsets if necessary.\n + t7501-commit.sh: Not all seds understand option -i\n + t5300-pack-object.sh: Split the big verify-pack test into smaller\n parts.\n\nA set of good general clean-up patches.\n\n* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits\n + Teach git clean to use setup_standard_excludes()\n + git-clean: Fix error message if clean.requireForce is not set.\n + Make git-clean a builtin\n\n* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nTeaching \"git apply --whitespace=[warn|strip]\" to honor the same\nconfiguration would be a good addition, but this could go to\n'master' as is.\n\n* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits\n + send-pack: cluster ref status reporting\n + send-pack: fix \"everything up-to-date\" message\n + send-pack: tighten remote error reporting\n + make \"find_ref_by_name\" a public function\n + Fix warning about bitfield in struct ref\n + send-pack: assign remote errors to each ref\n + send-pack: check ref->status before updating tracking refs\n + send-pack: track errors for each ref\n + Merge branch 'aw/mirror-push' into jk/send-pack\n + Merge branch 'ar/send-pack-remote-track' into jk/send-pack\n + Merge branch 'db/remote-builtin' into jk/send-pack\n + git-push: add documentation for the newly added --mirror mode\n + Add tests for git push'es mirror mode\n + Update the tracking references only if they were succesfully\n updated on remote\n + Add a test checking if send-pack updated local tracking branches\n correctly\n + git-push: plumb in --mirror mode\n + Teach send-pack a mirror mode\n + Merge master into aw/mirror-push\n + Merge branch 'jk/terse-push' into aw/mirror-push\n + send-pack: segfault fix on forced push\n + Reteach builtin-ls-remote to understand remotes\n + send-pack: require --verbose to show update of tracking refs\n + receive-pack: don't mention successful updates\n + more terse push output\n + Build in ls-remote\n + Build-in send-pack, with an API for other programs to call.\n + Use built-in send-pack.\n + Build-in peek-remote, using transport infrastructure.\n + Miscellaneous const changes and utilities\n\nVarious improvements on status reporting and error handling by\nsend-pack, and implementation of \"mirror\" pushing.\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* kh/commit (Thu Nov 22 16:21:49 2007 -0800) 23 commits\n + Add a few more tests for git-commit\n + builtin-commit: Include the diff in the commit message when\n verbose.\n + builtin-commit: fix partial-commit support\n + Fix add_files_to_cache() to take pathspec, not user specified list\n of files\n + Export three helper functions from ls-files\n + builtin-commit: run commit-msg hook with correct message file\n + builtin-commit: do not color status output shown in the message\n template\n + file_exists(): dangling symlinks do exist\n + Replace \"runstatus\" with \"status\" in the tests\n + t7501-commit: Add test for git commit with dirty index.\n + builtin-commit: Clean up an unused variable and a debug fprintf().\n + Call refresh_cache() when updating the user index for --only\n commits.\n + builtin-commit: Add newline when showing which commit was created\n + builtin-commit: resurrect behavior for multiple -m options\n + builtin-commit --s: add a newline if the last line was not a S-o-b\n + builtin-commit: fix --signoff\n + git status: show relative paths when run in a subdirectory\n + builtin-commit: Refresh cache after adding files.\n + builtin-commit: fix reflog message generation\n + launch_editor(): read the file, even when EDITOR=:\n + Port git commit to C.\n + Export launch_editor() and make it accept ':' as a no-op editor.\n + Add testcase for amending and fixing author in git commit.\n\nAlthough I found the fd shuffling somewhat distasteful, overall\nthe series seems reasonably stable so it is in 'next'.\n\n* cr/tag-options (Thu Nov 22 23:16:51 2007 -0800) 2 commits\n + builtin-tag: accept and process multiple -m just like git-commit\n + Make builtin-tag.c use parse_options.\n\nThe handling of multiple -m options are made consistent with\nwhat git-commit does; i.e. they are concatenated as separate\nparagraphs.\n\n* wc/add-i (Thu Nov 22 01:47:13 2007 -0800) 3 commits\n + git-add -i: allow multiple selection in patch subcommand\n + Add path-limiting to git-add--interactive\n + Teach builtin-add to pass multiple paths to git-add--interactive\n\nThis still does not have the \"directly invoke 'patch' subcommand\nand exit after the interaction without coming back to the menu\"\npart.\n\n* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n + refactor fetch's ref matching to use refname_match()\n + push: use same rules as git-rev-parse to resolve refspecs\n + add refname_match()\n + push: support pushing HEAD to real branch name\n\nThese are the uncontroversial bits from the series.\n\nThe \"--matching\" patch was dropped; I do not know what will\nhappen to the \"--current\" thing. I'd prefer to postpone the\ndiscussion until jk/send-pack topic stabilizes and graduates.\n\n* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits\n + git-branch --contains: doc and test\n + git-branch --contains=commit\n + parse-options: Allow to hide options from the default usage.\n\nContains Pierre's \"hidable options with --help-all\" patch.\n\n----------------------------------------------------------------\n[Approaching 'next']\n\n----------------------------------------------------------------\n[Others]\n\n* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n - test format-patch -s: make sure MIME content type is shown as\n needed\n - format-patch -s: add MIME encoding header if signer's name\n requires so\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'master'.\n\n* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit\n - Fix rev-list when showing objects involving submodules\n\nThis is to apply to 'maint' later; the equivalent fix is already\nin 'next' and will be merged to 'master' soon.\n\n----------------------------------------------------------------\n[Stalled]\n\n* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit\n - revert/cherry-pick: start refactoring call to merge_recursive\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n\nThe second one could probably be used to replace the use of\npath-list in the tip commit on the kh/commit series.\n\n* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits\n - Added diff hunk coloring to git-add--interactive\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\nThere were many good suggestions by Jeff to the updated series;\nhopefully we can replace these three with it.\n\n* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n + Add missing inside_work_tree setting in setup_git_directory_gently\n\nThere was an additional patch, which still had issues Dscho\npointed out. Waiting for refinements.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n . Make git-svn rebase --dirty pass along --dirty to git-rebase.\n . Implement --dirty for git-rebase--interactive.\n . Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nThis seems to be optimized for the --dirty case too much. I'd\nprefer an implementation that make rebases without --dirty to\npay no penalty (if that is possible, otherwise \"as little as\npossible\").\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n . handle renames using similarity engine\n . introduce generic similarity library\n . change hash table calling conventions\n\nThis was an attempt to use different strategy to speed up\nsimilarity computation, but does not work quite well as is.\n"},{"id":"60755","messageId":"20071123103003.GB6754@sigill.intra.peff.net","threadId":"10420","inReplyTo":"7vve7tuz3a.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-23T10:30:03Z","receivedAt":"2007-11-23T10:30:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 23, 2007 at 12:48:25AM -0800, Junio C Hamano wrote:\n\n> * jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits\n> + send-pack: cluster ref status reporting\n\nDid we decide that printing the \"maybe you need to pull\" hint is not\nworth doing?\n\n> * jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n> . handle renames using similarity engine\n> . introduce generic similarity library\n> . change hash table calling conventions\n> \n> This was an attempt to use different strategy to speed up\n> similarity computation, but does not work quite well as is.\n\nThis is still on my long-term todo list, but obviously needs quite a bit\nof cleanup. Eventually I will get around to it.\n\nI wonder if it is worth dropping from 'pu'. It doesn't pass the tests,\nmaking it harder to play with other pu topics, and it is not being\nactively worked on or tested by anyone.\n\n-Peff\n"},{"id":"60761","messageId":"Pine.LNX.4.64.0711231319220.27959@racer.site","threadId":"10420","inReplyTo":"20071123103003.GB6754@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-23T13:23:44Z","receivedAt":"2007-11-23T13:23:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Nov 2007, Jeff King wrote:\n\n> On Fri, Nov 23, 2007 at 12:48:25AM -0800, Junio C Hamano wrote:\n> \n> > * jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits\n> > + send-pack: cluster ref status reporting\n> \n> Did we decide that printing the \"maybe you need to pull\" hint is not \n> worth doing?\n\nMaybe we could change the (non-fast forward) message into (non-fast \nforward; need to pull?).\n\nJust an idea.\n\nCiao,\nDscho\n"},{"id":"60807","messageId":"20071124113814.GA17861@sigill.intra.peff.net","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711231319220.27959@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-24T11:38:15Z","receivedAt":"2007-11-24T11:38:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 23, 2007 at 01:23:44PM +0000, Johannes Schindelin wrote:\n\n> Maybe we could change the (non-fast forward) message into (non-fast \n> forward; need to pull?).\n\nNot unreasonable, although I think our line length is getting a bit\nlong. Rejected refs would look something like (actually they say\n\"[rejected]\" but the text is column-aligned with the X's):\n\n ! XXXXXXX...XXXXXXX ref_name -> ref_name (non-fast forward; need to pull?)\n\nThere's 58 characters of text not including the two ref_names, leaving\nabout 11 characters for each ref name. The name of this topic,\njk/send-pack, would overflow an 80-character terminal:\n\n ! [rejected] jk/send-pack -> jk/send-pack (non-fast forward; need to pull?)\n\n-Peff\n"},{"id":"60816","messageId":"alpine.LFD.0.99999.0711241042011.9605@xanadu.home","threadId":"10420","inReplyTo":"20071124113814.GA17861@sigill.intra.peff.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-24T15:47:56Z","receivedAt":"2007-11-24T15:47:56Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 24 Nov 2007, Jeff King wrote:\n\n> On Fri, Nov 23, 2007 at 01:23:44PM +0000, Johannes Schindelin wrote:\n> \n> > Maybe we could change the (non-fast forward) message into (non-fast \n> > forward; need to pull?).\n> \n> Not unreasonable, although I think our line length is getting a bit\n> long. Rejected refs would look something like (actually they say\n> \"[rejected]\" but the text is column-aligned with the X's):\n> \n> ! XXXXXXX...XXXXXXX ref_name -> ref_name (non-fast forward; need to pull?)\n> \n> There's 58 characters of text not including the two ref_names, leaving\n> about 11 characters for each ref name. The name of this topic,\n> jk/send-pack, would overflow an 80-character terminal:\n> \n> ! [rejected] jk/send-pack -> jk/send-pack (non-fast forward; need to pull?)\n\nI personally think this is a bad idea, especially after all the efforts \nthat has been put into making those lines not to wrap.\n\nYet the message itself is not totally accurate either, since \"need to \npull\" might have to be \"need to force\" in some cases.\n\nI think that would be better to append a single line at the end of the \ndisplay with a clue about what \"non fast forward\" means.\n\n\nNicolas\n"},{"id":"60819","messageId":"7vtznbqx2w.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711241042011.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-24T19:09:59Z","receivedAt":"2007-11-24T19:09:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> Yet the message itself is not totally accurate either, since \"need to \n> pull\" might have to be \"need to force\" in some cases.\n\nWe used to say only \"this is not a fast-forward\", and did not\nmention \"what next\". Later we added \"maybe you want to pull\nfirst?\" without making it clear enough that the reason why the\nsuggestion may or may not apply to the user is because it\ndepended largely on the user's workflow. It probably was a\nmistake and not mentioning \"what next\" at all might have been\nless confusion-prone. I dunno.\n\n> I think that would be better to append a single line at the end of the \n> display with a clue about what \"non fast forward\" means.\n\nI'd agree, but having said all the above, I am not entirely\nhappy not mentioning \"what next\" at all.\n\nThere are two equally valid \"what next\" after your push is\nrejected due to non-fast-forwardness.\n\n (1) You know what you are doing.\n\n - You are pushing into a \"back-up\" repository, not for a\n public consumption.\n\n - You are pushing a branch that are advertised to rebase and\n rewind into your own publishing repository, and other\n people interacting with the branch know about this.\n\n - You pushed a wrong head there very recently and are fairly\n confident that nobody has seen that mistake, and pushing\n the correct one to fix the mistake.\n\n In these cases, forcing the push is the right solution\n (except that the third one is dubious, because it depends\n heavily on the \"fairly confident\" part).\n\n (2) You were building on a stale head, and were indeed about to\n lose others' changes with a non-fast-forward push.\n\n The right solution is to rebuild what you push so that you\n will not lose others' changes. Rebuilding can take two\n different forms:\n\n - You may want to git-fetch and rebase your work on top of\n others'.\n\n - You may want to git-pull, which will merge your work with\n what others did.\n\nBut of couse the above is way too long as the help text.\n\nDoes the user-manual talk about this? It has a really good\ndescription of how to notice when a merge is not resolved\nautomatically and what to do next (\"Resolving a merge\" section).\nPerhaps we can enhance \"Pushing changes to a public repository\"\nsection to include \"what if the push is refused\" information.\n"},{"id":"60847","messageId":"7v4pfakr4j.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7vve7tuz3a.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-25T20:27:24Z","receivedAt":"2007-11-25T20:27:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n----------------------------------------------------------------\n[Graduated to 'master']\n\n* cc/bisect (Tue Nov 20 06:39:53 2007 +0100) 7 commits\n* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit\n* js/mingw-fallouts (Sat Nov 17 23:09:28 2007 +0100) 13 commits\n* sb/clean (Wed Nov 14 23:00:54 2007 -0600) 3 commits\n* jk/send-pack (Tue Nov 20 06:18:01 2007 -0500) 29 commits\n\n----------------------------------------------------------------\n[Graduated to 'maint']\n\n* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits\n* lt/maint-rev-list-gitlink (Sun Nov 11 23:35:23 2007 +0000) 1 commit\n\n----------------------------------------------------------------\n[New Topics]\n\n* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit\n - Start preparing the API documents.\n\nThis currently consists of mostly stubs, although I wrote about a few\ntopics as examples.\n\n* jc/diff-pathspec (Sun Nov 25 10:03:48 2007 -0800) 1 commit\n - Making ce_path_match() more useful by accepting globs\n\n----------------------------------------------------------------\n[Will cook further in 'next' and then merge to 'master' soon]\n\n* jc/move-gitk (Sat Nov 17 10:51:16 2007 -0800) 1 commit\n + Move gitk to its own subdirectory\n\nI have a phoney Makefile under the subdirectory for gitk, but\nhopefully with the next pull from Paulus I can replace it with\nthe real thing, along with the i18n stuff.\n\n* tt/help (Sun Nov 11 19:57:57 2007 -0500) 2 commits\n + Remove hint to use \"git help -a\"\n + Make the list of common commands more exclusive\n\nSome people on the list may find the exact list of commands\nsomewhat debatable. We can fine-tune that in-tree ('pu' does\nnot count as \"in-tree\").\n\n* kh/commit (Thu Nov 22 16:21:49 2007 -0800) 23 commits\n + Add a few more tests for git-commit\n + builtin-commit: Include the diff in the commit message when\n verbose.\n + builtin-commit: fix partial-commit support\n + Fix add_files_to_cache() to take pathspec, not user specified list\n of files\n + Export three helper functions from ls-files\n + builtin-commit: run commit-msg hook with correct message file\n + builtin-commit: do not color status output shown in the message\n template\n + file_exists(): dangling symlinks do exist\n + Replace \"runstatus\" with \"status\" in the tests\n + t7501-commit: Add test for git commit with dirty index.\n + builtin-commit: Clean up an unused variable and a debug fprintf().\n + Call refresh_cache() when updating the user index for --only\n commits.\n + builtin-commit: Add newline when showing which commit was created\n + builtin-commit: resurrect behavior for multiple -m options\n + builtin-commit --s: add a newline if the last line was not a S-o-b\n + builtin-commit: fix --signoff\n + git status: show relative paths when run in a subdirectory\n + builtin-commit: Refresh cache after adding files.\n + builtin-commit: fix reflog message generation\n + launch_editor(): read the file, even when EDITOR=:\n + Port git commit to C.\n + Export launch_editor() and make it accept ':' as a no-op editor.\n + Add testcase for amending and fixing author in git commit.\n\nI've been running with this, and so are people following 'next', for a\nfew days. The series seems to be in a good shape.\n\n* cr/tag-options (Thu Nov 22 23:16:51 2007 -0800) 2 commits\n + builtin-tag: accept and process multiple -m just like git-commit\n + Make builtin-tag.c use parse_options.\n\nThe handling of multiple -m options are made consistent with\nwhat git-commit does; i.e. they are concatenated as separate\nparagraphs.\n\n* jc/branch-contains (Sun Nov 18 22:22:00 2007 -0800) 3 commits\n + git-branch --contains: doc and test\n + git-branch --contains=commit\n + parse-options: Allow to hide options from the default usage.\n\nContains Pierre's \"hidable options with --help-all\" patch.\n\n----------------------------------------------------------------\n[Actively cooking]\n\n* jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits\n + core.whitespace: documentation updates.\n + builtin-apply: teach whitespace_rules\n + builtin-apply: rename \"whitespace\" variables and fix styles\n + core.whitespace: add test for diff whitespace error highlighting\n + git-diff: complain about >=8 consecutive spaces in initial indent\n + War on whitespace: first, a bit of retreat.\n\nNow apply also knows about the customizable definition of what\nwhitespace breakages are, and I was reasonably happy. But Bruce kicked\nit back from \"scheduled to merge\" to \"still cooking\" status, reminding\nthat we would want to have this not a tree-wide configuration but\nper-path attribute. And I agree with him.\n\n* wc/add-i (Sun Nov 25 14:15:42 2007 +0100) 30 commits\n - Add \"--patch\" option to git-add--interactive\n + add -i: Fix running from a subdirectory\n + builtin-add: fix command line building to call interactive\n + Merge branch 'kh/commit' into wc/add-i\n + Add a few more tests for git-commit\n + git-add -i: allow multiple selection in patch subcommand\n + builtin-commit: Include the diff in the commit message when\n verbose.\n + builtin-commit: fix partial-commit support\n + Fix add_files_to_cache() to take pathspec, not user specified list\n of files\n + Export three helper functions from ls-files\n + builtin-commit: run commit-msg hook with correct message file\n + builtin-commit: do not color status output shown in the message\n template\n + file_exists(): dangling symlinks do exist\n + Replace \"runstatus\" with \"status\" in the tests\n + t7501-commit: Add test for git commit with dirty index.\n + builtin-commit: Clean up an unused variable and a debug fprintf().\n + Call refresh_cache() when updating the user index for --only\n commits.\n + builtin-commit: Add newline when showing which commit was created\n + builtin-commit: resurrect behavior for multiple -m options\n + builtin-commit --s: add a newline if the last line was not a S-o-b\n + builtin-commit: fix --signoff\n + git status: show relative paths when run in a subdirectory\n + builtin-commit: Refresh cache after adding files.\n + builtin-commit: fix reflog message generation\n + launch_editor(): read the file, even when EDITOR=:\n + Port git commit to C.\n + Export launch_editor() and make it accept ':' as a no-op editor.\n + Add testcase for amending and fixing author in git commit.\n + Add path-limiting to git-add--interactive\n + Teach builtin-add to pass multiple paths to git-add--interactive\n\nThis looks larger than it really is, as I merged in the builtin commit\nseries near the tip (they interact with each other somewhat, and it is\nvery likely that builtin commit series will graduate to 'master' before\nthis series).\n\nI also adjusted the \"git add -p\" patch from Wincent and have it at the\ntip. It is parked in 'pu' for now.\n\n* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits\n + refactor fetch's ref matching to use refname_match()\n + push: use same rules as git-rev-parse to resolve refspecs\n + add refname_match()\n + push: support pushing HEAD to real branch name\n\nI think the \"git push HEAD\" is a good change, and also using the same\nshort refname resolving as rev-parse does for matching the destination\nof push. I am having second thoughts on the last one. The changed\nsemantics is somewhat less safe:\n\n * We did not allow fetching outside refs/ (except HEAD), but now we\n allow any random string.\n\n * We used to restrict fetching names that do not begin with refs/ to\n heads, tags and remotes, but now the code grabs anything underneath\n refs/.\n\nwhich could invite mistakes by letting typos slip through.\n\nHaving said that, I probably \"fetch\" much less often than other people\ndo and these are non issues in the real-world usecases. It could be\nthat I am worried too much needlessly. If anybody who is following\n'next' has been bitten by the change, please speak up.\n\n----------------------------------------------------------------\n[Stalled]\n\n* jc/cherry-pick (Tue Nov 13 12:38:51 2007 -0800) 1 commit\n - revert/cherry-pick: start refactoring call to merge_recursive\n\n* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits\n - merge-nu: a new merge backend without using unpack_trees()\n - read_tree: take an explicit index structure\n - gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix\n\nThe second one could probably be used to replace the use of\npath-list in the tip commit on the kh/commit series.\n\n* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits\n - Added diff hunk coloring to git-add--interactive\n - Let git-add--interactive read colors from .gitconfig\n - Added basic color support to git add --interactive\n\nThere were many good suggestions by Jeff to the updated series;\nhopefully we can replace these three with it.\n\n* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit\n + Add missing inside_work_tree setting in setup_git_directory_gently\n\nThere was an additional patch, which still had issues Dscho\npointed out. Waiting for refinements.\n\n* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit\n + Teach \"git reflog\" a subcommand to delete single entries\n\n* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits\n - pathspec_can_match(): move it from builtin-ls-tree.c to tree.c\n - ls-tree.c: refactor show_recursive() and rename it.\n - tree-diff.c: split out a function to match a single pattern.\n\n* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits\n . Make git-svn rebase --dirty pass along --dirty to git-rebase.\n . Implement --dirty for git-rebase--interactive.\n . Introduce --dirty option to git-rebase, allowing you to start from\n a dirty state.\n\nThis seems to be optimized for the --dirty case too much. I'd\nprefer an implementation that make rebases without --dirty to\npay no penalty (if that is possible, otherwise \"as little as\npossible\").\n\n* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits\n . handle renames using similarity engine\n . introduce generic similarity library\n . change hash table calling conventions\n\nThis was an attempt to use different strategy to speed up\nsimilarity computation, but does not work quite well as is.\n"},{"id":"60852","messageId":"ficmbr$s87$1@ger.gmane.org","threadId":"10420","inReplyTo":"7v4pfakr4j.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-25T20:36:14Z","receivedAt":"2007-11-25T20:36:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> [Actively cooking]\n> \n> * jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits\n>  + core.whitespace: documentation updates.\n>  + builtin-apply: teach whitespace_rules\n>  + builtin-apply: rename \"whitespace\" variables and fix styles\n>  + core.whitespace: add test for diff whitespace error highlighting\n>  + git-diff: complain about >=8 consecutive spaces in initial indent\n>  + War on whitespace: first, a bit of retreat.\n> \n> Now apply also knows about the customizable definition of what\n> whitespace breakages are, and I was reasonably happy. But Bruce kicked\n> it back from \"scheduled to merge\" to \"still cooking\" status, reminding\n> that we would want to have this not a tree-wide configuration but\n> per-path attribute.  And I agree with him.\n\nCurrently apply.whitespace is per repository - would this be changed\nas well, i.e. would it be moved to gitattributes together with custom\ndiff drivers (or at least custom funcnames), custom merge drivers,\nmaking it per-project (if put under version control) and per-path?\n\n\nBy the way, i18n.commitEncoding is per repository, and used to affect\nrepository; not so with the \"encoding\" header in commit object.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"60866","messageId":"20071125205357.GA23820@fieldses.org","threadId":"10420","inReplyTo":"ficmbr$s87$1@ger.gmane.org","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-25T20:53:57Z","receivedAt":"2007-11-25T20:53:57Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Nov 25, 2007 at 09:36:14PM +0100, Jakub Narebski wrote:\n> Junio C Hamano wrote:\n> \n> > [Actively cooking]\n> > \n> > * jc/spht (Sat Nov 24 11:57:41 2007 -0800) 6 commits\n> >  + core.whitespace: documentation updates.\n> >  + builtin-apply: teach whitespace_rules\n> >  + builtin-apply: rename \"whitespace\" variables and fix styles\n> >  + core.whitespace: add test for diff whitespace error highlighting\n> >  + git-diff: complain about >=8 consecutive spaces in initial indent\n> >  + War on whitespace: first, a bit of retreat.\n> > \n> > Now apply also knows about the customizable definition of what\n> > whitespace breakages are, and I was reasonably happy. But Bruce kicked\n> > it back from \"scheduled to merge\" to \"still cooking\" status, reminding\n> > that we would want to have this not a tree-wide configuration but\n> > per-path attribute.  And I agree with him.\n> \n> Currently apply.whitespace is per repository - would this be changed\n> as well,\n\nThere's a difference between the choice of preferred whitespace style\nand the choice of action to take when encountering \"bad\" whitespace.\n\nThe former is (I think) obviously a property of the project (or perhaps\nof individual paths within the project). The latter may depend on what\nyou're doing with it at any given moment--for example, if I'm applying\npatches to submit, I generally want to fix whitespace, but if I'm just\nexamining someone else's patches temporarily then I might want to import\nthem quickly without fixing up everything.\n\nSo, no, I don't think there should be a .gitattribute equivalent to\napply.whitespace.\n\n--b.\n\n> i.e. would it be moved to gitattributes together with custom\n> diff drivers (or at least custom funcnames), custom merge drivers,\n> making it per-project (if put under version control) and per-path?\n\n> \n> \n> By the way, i18n.commitEncoding is per repository, and used to affect\n> repository; not so with the \"encoding\" header in commit object.\n> \n> -- \n> Jakub Narebski\n> Warsaw, Poland\n> ShadeHawk on #git\n> \n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"60876","messageId":"20071125215128.GC23820@fieldses.org","threadId":"10420","inReplyTo":"7vtznbqx2w.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-25T21:51:28Z","receivedAt":"2007-11-25T21:51:28Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sat, Nov 24, 2007 at 11:09:59AM -0800, Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> > I think that would be better to append a single line at the end of the \n> > display with a clue about what \"non fast forward\" means.\n> \n> I'd agree, but having said all the above, I am not entirely\n> happy not mentioning \"what next\" at all.\n> \n> There are two equally valid \"what next\" after your push is\n> rejected due to non-fast-forwardness.\n> \n> (1) You know what you are doing.\n> \n> - You are pushing into a \"back-up\" repository, not for a\n> public consumption.\n> \n> - You are pushing a branch that are advertised to rebase and\n> rewind into your own publishing repository, and other\n> people interacting with the branch know about this.\n> \n> - You pushed a wrong head there very recently and are fairly\n> confident that nobody has seen that mistake, and pushing\n> the correct one to fix the mistake.\n> \n> In these cases, forcing the push is the right solution\n> (except that the third one is dubious, because it depends\n> heavily on the \"fairly confident\" part).\n> \n> (2) You were building on a stale head, and were indeed about to\n> lose others' changes with a non-fast-forward push.\n> \n> The right solution is to rebuild what you push so that you\n> will not lose others' changes. Rebuilding can take two\n> different forms:\n> \n> - You may want to git-fetch and rebase your work on top of\n> others'.\n> \n> - You may want to git-pull, which will merge your work with\n> what others did.\n> \n> But of couse the above is way too long as the help text.\n> \n> Does the user-manual talk about this? It has a really good\n> description of how to notice when a merge is not resolved\n> automatically and what to do next (\"Resolving a merge\" section).\n> Perhaps we can enhance \"Pushing changes to a public repository\"\n> section to include \"what if the push is refused\" information.\n\nThere's a very brief mention of this:\n\n\t\"As with git-fetch, git-push will complain if this does not\n\tresult in a <>. Normally this is a\n\tsign of something wrong. However, if you are sure you know what\n\tyou're doing, you may force git-push to perform the update\n\tanyway by preceding the branch name by a plus sign:\n\nBut it'd probably be better to have a separate section. That makes it\npossible to say a little more, and also gets a section called \"what to\ndo when a push fails\" into the table of contents.\n\n(Though that's a little vague--push can also fail just because you\nmispell the url or something. A more precise reference to the\nparticular error might be better, but we'll have to agree on the error\nmessage first....)\n\nAnyway, here's a first draft.\n\n--b.\n\ndiff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\nindex 8355cce..7544715 100644\n--- a/Documentation/user-manual.txt\n+++ b/Documentation/user-manual.txt\n@@ -1929,15 +1929,9 @@ or just\n $ git push ssh://yourserver.com/~you/proj.git master\n -------------------------------------------------\n \n-As with git-fetch, git-push will complain if this does not result in\n-a <>. Normally this is a sign of\n-something wrong. However, if you are sure you know what you're\n-doing, you may force git-push to perform the update anyway by\n-proceeding the branch name by a plus sign:\n-\n--------------------------------------------------\n-$ git push ssh://yourserver.com/~you/proj.git +master\n--------------------------------------------------\n+As with git-fetch, git-push will complain if this does not result in a\n+<>; see the following section for details on\n+handling this case.\n \n Note that the target of a \"push\" is normally a\n <> repository. You can also push to a\n@@ -1965,6 +1959,55 @@ See the explanations of the remote..url, branch..remote,\n and remote..push options in gitlink:git-config[1] for\n details.\n \n+[[forcing-push]]\n+What to do when a push fails\n+~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n+\n+If the push does not result in a <> of the\n+remote branch, then it will fail with an error like:\n+\n+-------------------------------------------------\n+error: remote 'refs/heads/master' is not an ancestor of\n+ local 'refs/heads/master'.\n+ Maybe you are not up-to-date and need to pull first?\n+error: failed to push to 'ssh://yourserver.com/~you/proj.git'\n+-------------------------------------------------\n+\n+The most likely reason for this is that you have replaced some of the\n+history that you already pushed, so that your \"master\" is no longer a\n+descendant of upstream's \"master\", This could happen, for example, if\n+you:\n+\n+\t- use `git reset --hard` to remove already-published commits, or\n+\t- use `git commit --amend` to replace already-published commits\n+\t (as in <>), or\n+\t- use `git rebase` to rebase any already-published commits (as\n+\t in <>).\n+\n+If you are sure you want to replace the branch in the public repository\n+by your branch, you may force git-push to perform the update anyway by\n+preceding the branch name with a plus sign:\n+\n+-------------------------------------------------\n+$ git push ssh://yourserver.com/~you/proj.git +master\n+-------------------------------------------------\n+\n+Normally whenever a branch head in a public repository is modified, it\n+is modified to point to a descendent of the commit that it pointed to\n+before. By forcing a push in this situation, you break that convention.\n+(See <>).\n+\n+Nevertheless, this is a common practice for people that need a simple\n+way to publish a work-in-progress patch series, and it is an acceptable\n+compromise as long as you warn other developers that this is how you\n+intend to manage the branch.\n+\n+It's also possible for a push to fail in this way when other people have\n+the right to push to the same repository. In that case, the correct\n+solution is to update your work by either a pull or a fetch followed by\n+a rebase; see the <> for\n+more.\n+\n [[setting-up-a-shared-repository]]\n Setting up a shared repository\n ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n"},{"id":"60884","messageId":"7v63zqj6bj.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"20071125215128.GC23820@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-25T22:42:08Z","receivedAt":"2007-11-25T22:42:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> Anyway, here's a first draft.\n>\n> --b.\n>\n> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> index 8355cce..7544715 100644\n> --- a/Documentation/user-manual.txt\n> +++ b/Documentation/user-manual.txt\n> ...\n> +Normally whenever a branch head in a public repository is modified, it\n> +is modified to point to a descendent of the commit that it pointed to\n> +before. By forcing a push in this situation, you break that convention.\n> +(See <>).\n> +\n> +Nevertheless, this is a common practice for people that need a simple\n> +way to publish a work-in-progress patch series, and it is an acceptable\n> +compromise as long as you warn other developers that this is how you\n> +intend to manage the branch.\n\nNote that modern git allows repository owners to forbid such a forced\nnon fast forward push at the receiving end. In such a case, you cannot\neven force a push.\n\nInstead, you would need to fetch the current branch tip from the remote\nand merge it into the branch you were tring to push, possibly using the\n\"ours\" merge strategy, before pushing it again. Use of \"ours\" merge in\nsuch a case:\n\n - makes the next fetch by other people properly fast-forwarding;\n\n - records your admission of guilt: \"I screwed up the last push and\n this is a replacement --- this is what I really should have pushed\n the last time\".\n\n - makes the resulting tree exactly the same as what you tried to push\n unsuccessfully. This is a valid substitute to a forced push in that\n it reverts the mistakes _you_ made with the previous push.\n"},{"id":"60886","messageId":"20071125230855.GE23820@fieldses.org","threadId":"10420","inReplyTo":"7v63zqj6bj.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-25T23:08:55Z","receivedAt":"2007-11-25T23:08:55Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Nov 25, 2007 at 02:42:08PM -0800, Junio C Hamano wrote:\n> \"J. Bruce Fields\" writes:\n> \n> > Anyway, here's a first draft.\n> >\n> > --b.\n> >\n> > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt\n> > index 8355cce..7544715 100644\n> > --- a/Documentation/user-manual.txt\n> > +++ b/Documentation/user-manual.txt\n> > ...\n> > +Normally whenever a branch head in a public repository is modified, it\n> > +is modified to point to a descendent of the commit that it pointed to\n> > +before. By forcing a push in this situation, you break that convention.\n> > +(See <>).\n> > +\n> > +Nevertheless, this is a common practice for people that need a simple\n> > +way to publish a work-in-progress patch series, and it is an acceptable\n> > +compromise as long as you warn other developers that this is how you\n> > +intend to manage the branch.\n> \n> Note that modern git allows repository owners to forbid such a forced\n> non fast forward push at the receiving end. In such a case, you cannot\n> even force a push.\n> \n> Instead, you would need to fetch the current branch tip from the remote\n> and merge it into the branch you were tring to push, possibly using the\n> \"ours\" merge strategy, before pushing it again. Use of \"ours\" merge in\n> such a case:\n> \n> - makes the next fetch by other people properly fast-forwarding;\n> \n> - records your admission of guilt: \"I screwed up the last push and\n> this is a replacement --- this is what I really should have pushed\n> the last time\".\n> \n> - makes the resulting tree exactly the same as what you tried to push\n> unsuccessfully. This is a valid substitute to a forced push in that\n> it reverts the mistakes _you_ made with the previous push.\n\nOK, that's interesting. In a similar vein, I've been experimenting with\n\"merge -s ours\" lately as a way to keep track of the \"meta-history\" of\nan unsubmitted patch series in progress. It seems a little hairy right\nnow, but maybe it'll turn out to be The Right Thing to do.\n\nI don't want to deal with this in the manual yet. For the sake of\nkeeping things simple, I'd rather first stick to the case of a public\nrepository set up by the user which the user controls. And I think that\nkind of use of \"-s ours\" is worth documenting but I'm not sure how to\ndeal with it yet.\n\n--b.\n"},{"id":"60901","messageId":"alpine.LFD.0.99999.0711252029020.9605@xanadu.home","threadId":"10420","inReplyTo":"20071125215128.GC23820@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T04:02:05Z","receivedAt":"2007-11-26T04:02:05Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sun, 25 Nov 2007, J. Bruce Fields wrote:\n\n> There's a very brief mention of this:\n> \n> \t\"As with git-fetch, git-push will complain if this does not\n> \tresult in a <>. Normally this is a\n> \tsign of something wrong. However, if you are sure you know what\n> \tyou're doing, you may force git-push to perform the update\n> \tanyway by preceding the branch name by a plus sign:\n\n... or use \"git push -f\" (is it mentioned in the manual?)\n\n> But it'd probably be better to have a separate section. That makes it\n> possible to say a little more, and also gets a section called \"what to\n> do when a push fails\" into the table of contents.\n> \n> (Though that's a little vague--push can also fail just because you\n> mispell the url or something. A more precise reference to the\n> particular error might be better, but we'll have to agree on the error\n> message first....)\n> \n> Anyway, here's a first draft.\n\nI think we should devote a section of the manual to the \"rebase\" \nworkflow compared to the \"merge\" workflow. One of the public Git repo \nI currently maintain is constantly rebased, and I've provided a quick \nGit update cheat sheet along with its announcement for that case:\n\n http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-November/043147.html\n\nI also wrote an introductory document for $job internal use. I have a \nsection where I briefly cover the main differences and implications for \nmerge vs rebase. Here it is -- please feel free to add it to the manual \nif you think it can be valuable.\n\n----- >8\n\nRebase vs Merge\n---------------\n\nMerge and rebase may look like they are doing the same thing, but they act \nvery differently on the repository. Merging basically takes all the \nchanges in the remote branch and mix them with your local branch. \nFor example, if you create a branch \"mywork\" from the orion/core branch, \nyou will end up with something that looks like this:\n\n\ta--b--c <-- orion/master\n\t \\\n\t A--B--C <-- mywork \n\nAfter a fetch, the remote branch might have advanced in parallel to\nlocal changes as follows:\n\n\ta--b--c--d--e--f <-- orion/master\n\t \\\n\t A--B--C <-- mywork \n\nIf you later do a 'git merge orion/master', your history will look like\nthis, where 'M' is a merge commit:\n\n\ta--b--c--d--e--f <-- orion/master\n\t \\ \\\n\t A--B--C--M <-- mywork\n\nA rebase, on the other hand, takes all your changes and reapplies them to \nthe current state of the specified branch, and assign the result to the \ncurrently checked out branch. With the same example, if you were to do a \n'git rebase orion/master', you would get something like this:\n\n\ta--b--c--d--e--f <-- orion/master\n\t \\\n\t A'--B'--C' <-- mywork\n\nRebase does what the name implies and creates a new baseline for your \nbranch. The benefit of this is that you end up with a cleaner history log,\nespecially if you have to update with the remote branch often, in both\nyour repository and in upstream repositories that gets updated from you. \n\n\nTracking a rebased remote branch\n--------------------------------\n\nLet's suppose that the remote branch you're tracking is itself subject\nto be rebased. Before performing a fetch to update that remote branch,\nyour history might look like the previous example:\n\n\ta--b--c--d--e--f <-- orion/master\n\t \\\n\t A'--B'--C' <-- mywork\n\nIf the remote branch had some commit replaced, or was rebased on a\ndifferent commit (or both), then things could look like this after a\nfetch:\n\n\ta---b---c'--d'--e'--f'--g <-- orion/master\n\t \\\n\t c---d---e---f <-- orion/master@{1}\n\t \\\n\t A---B---C <-- mywork\n\nIn this example, commits c, d, e and f are not present anymore in the\nremote repository. They are still reachable from your \"mywork\" local\nbranch though. The \"orion/master@{1}\" is the notation used to refer to the\nprevious value (before the fetch) of \"orion/master\".\n\nIf you were to use 'git merge' to bring the new commits (c', d', e', f'\nand g) into your local branch, that wouldn't get rid of the commits that\nthey are meant to replace, and is likely to cause a major merge conflict.\n\nThe only option in that case is to rebase your work. Yet there is a twist\nbecause 'rebase' moves every commit reachable from the current branch on\ntop of the specified branch by default, including those c-d-e-f commits.\nSo the --onto argument to 'git rebase' must be used to skip over those\nunwanted commits as follows:\n\n\tgit rebase --onto orion/master orion/master@{1} mywork\n\nThis means to rebase commits between orion/master@{1} and mywork on top of\norion/master and assing mywork to the result. The git-rebase man page\nprovides more examples and a detailed explanation of how 'rebase' works\nwhich is worth a read.\n\nNOte: the orion Git repository is indeed rebased often. So you'll have\nto use this rebase invokation when fetching updates from it.\n"},{"id":"60903","messageId":"20071126041521.GA21120@fieldses.org","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711252029020.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-26T04:15:21Z","receivedAt":"2007-11-26T04:15:21Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Nov 25, 2007 at 11:02:05PM -0500, Nicolas Pitre wrote:\n> On Sun, 25 Nov 2007, J. Bruce Fields wrote:\n> \n> > There's a very brief mention of this:\n> > \n> > \t\"As with git-fetch, git-push will complain if this does not\n> > \tresult in a <>. Normally this is a\n> > \tsign of something wrong. However, if you are sure you know what\n> > \tyou're doing, you may force git-push to perform the update\n> > \tanyway by preceding the branch name by a plus sign:\n> \n> ... or use \"git push -f\" (is it mentioned in the manual?)\n> \n> > But it'd probably be better to have a separate section. That makes it\n> > possible to say a little more, and also gets a section called \"what to\n> > do when a push fails\" into the table of contents.\n> > \n> > (Though that's a little vague--push can also fail just because you\n> > mispell the url or something. A more precise reference to the\n> > particular error might be better, but we'll have to agree on the error\n> > message first....)\n> > \n> > Anyway, here's a first draft.\n> \n> I think we should devote a section of the manual to the \"rebase\" \n> workflow compared to the \"merge\" workflow.\n\nThere's this:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-git-rebase\n\nIt doesn't explicitly compare the two, but I think between that and the\ncontaining chapter, it hits on the main issues.\n\n> One of the public Git repo \n> I currently maintain is constantly rebased, and I've provided a quick \n> Git update cheat sheet along with its announcement for that case:\n> \n> http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2007-November/043147.html\n\nThe trick of\n\n\ttag -d old_base remote/master\n\tgit fetch remote\n\tgit rebase --onto remote/master old_base my_work\n\nis something we don't document anywhere.\n\n(We might not have to quite so much if we came up with a command that\ndid the job of git-rebase and/or cherry-pick with more intuitive\nsyntax....)\n\n> I also wrote an introductory document for $job internal use. I have a \n> section where I briefly cover the main differences and implications for \n> merge vs rebase. Here it is -- please feel free to add it to the manual \n> if you think it can be valuable.\n\nThanks. I think the manual covers most of what's in the \"rebase vs\nmerge\" section already. (Though it'd be worth reconsidering how we do\nit.)\n\nThe \"tracking a rebased remote branch\" stuff would be new and, I think,\nhelpful.\n\nI'll take a closer look at it eventually--but if someone wants to speed\nthe process by working out exactly where to fit this in, which parts are\nduplicated, etc., and turn the result into a patch, I'd be happy.\n\nI do find that trying to work on top of a constantly rebased branch is\nannoying no matter how I do it. So I sometimes wonder if we shouldn't\ninstead be finding ways to avoid the practice.\n\n--b.\n\n> \n> ----- >8\n> \n> Rebase vs Merge\n> ---------------\n> \n> Merge and rebase may look like they are doing the same thing, but they act \n> very differently on the repository. Merging basically takes all the \n> changes in the remote branch and mix them with your local branch. \n> For example, if you create a branch \"mywork\" from the orion/core branch, \n> you will end up with something that looks like this:\n> \n> \ta--b--c <-- orion/master\n> \t \\\n> \t A--B--C <-- mywork \n> \n> After a fetch, the remote branch might have advanced in parallel to\n> local changes as follows:\n> \n> \ta--b--c--d--e--f <-- orion/master\n> \t \\\n> \t A--B--C <-- mywork \n> \n> If you later do a 'git merge orion/master', your history will look like\n> this, where 'M' is a merge commit:\n> \n> \ta--b--c--d--e--f <-- orion/master\n> \t \\ \\\n> \t A--B--C--M <-- mywork\n> \n> A rebase, on the other hand, takes all your changes and reapplies them to \n> the current state of the specified branch, and assign the result to the \n> currently checked out branch. With the same example, if you were to do a \n> 'git rebase orion/master', you would get something like this:\n> \n> \ta--b--c--d--e--f <-- orion/master\n> \t \\\n> \t A'--B'--C' <-- mywork\n> \n> Rebase does what the name implies and creates a new baseline for your \n> branch. The benefit of this is that you end up with a cleaner history log,\n> especially if you have to update with the remote branch often, in both\n> your repository and in upstream repositories that gets updated from you. \n> \n> \n> Tracking a rebased remote branch\n> --------------------------------\n> \n> Let's suppose that the remote branch you're tracking is itself subject\n> to be rebased. Before performing a fetch to update that remote branch,\n> your history might look like the previous example:\n> \n> \ta--b--c--d--e--f <-- orion/master\n> \t \\\n> \t A'--B'--C' <-- mywork\n> \n> If the remote branch had some commit replaced, or was rebased on a\n> different commit (or both), then things could look like this after a\n> fetch:\n> \n> \ta---b---c'--d'--e'--f'--g <-- orion/master\n> \t \\\n> \t c---d---e---f <-- orion/master@{1}\n> \t \\\n> \t A---B---C <-- mywork\n> \n> In this example, commits c, d, e and f are not present anymore in the\n> remote repository. They are still reachable from your \"mywork\" local\n> branch though. The \"orion/master@{1}\" is the notation used to refer to the\n> previous value (before the fetch) of \"orion/master\".\n> \n> If you were to use 'git merge' to bring the new commits (c', d', e', f'\n> and g) into your local branch, that wouldn't get rid of the commits that\n> they are meant to replace, and is likely to cause a major merge conflict.\n> \n> The only option in that case is to rebase your work. Yet there is a twist\n> because 'rebase' moves every commit reachable from the current branch on\n> top of the specified branch by default, including those c-d-e-f commits.\n> So the --onto argument to 'git rebase' must be used to skip over those\n> unwanted commits as follows:\n> \n> \tgit rebase --onto orion/master orion/master@{1} mywork\n> \n> This means to rebase commits between orion/master@{1} and mywork on top of\n> orion/master and assing mywork to the result. The git-rebase man page\n> provides more examples and a detailed explanation of how 'rebase' works\n> which is worth a read.\n> \n> NOte: the orion Git repository is indeed rebased often. So you'll have\n> to use this rebase invokation when fetching updates from it.\n"},{"id":"60904","messageId":"alpine.LFD.0.99999.0711252324360.9605@xanadu.home","threadId":"10420","inReplyTo":"20071126041521.GA21120@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T04:29:56Z","receivedAt":"2007-11-26T04:29:56Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, J. Bruce Fields wrote:\n\n> I do find that trying to work on top of a constantly rebased branch is\n> annoying no matter how I do it. So I sometimes wonder if we shouldn't\n> instead be finding ways to avoid the practice.\n\nI don't think it can't be avoided in many cases. Some stuff gets \nrebased because it has to be refined before it is merged in a more \nstable and more \"official\" repository. Working on top of a rebased \nbranch could be much easier if there was a dedicated command to perform \nthe local rebase of one's work after a fetch, just like the pull command \ndoes a merge after a fetch, at which point both work flows would be \nalmost equivalent wrt ease of use.\n\n\nNicolas\n"},{"id":"60905","messageId":"20071126044538.GC21120@fieldses.org","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711252324360.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-11-26T04:45:38Z","receivedAt":"2007-11-26T04:45:38Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Nov 25, 2007 at 11:29:56PM -0500, Nicolas Pitre wrote:\n> On Mon, 26 Nov 2007, J. Bruce Fields wrote:\n> \n> > I do find that trying to work on top of a constantly rebased branch is\n> > annoying no matter how I do it. So I sometimes wonder if we shouldn't\n> > instead be finding ways to avoid the practice.\n> \n> I don't think it can't be avoided in many cases. Some stuff gets \n> rebased because it has to be refined before it is merged in a more \n> stable and more \"official\" repository.\n\nWell, there is for example the option of doing things like:\n\n\tgit checkout -b new-mywork mywork\n\tgit fetch origin\n\tgit rebase new-mywork origin\n\t# further reordering of commits, etc., as needed\n\tgit merge -s ours mywork\n\tgit branch -d mywork\n\tgit push mypubrepo new-mywork:mywork\n\nand if you do this each time, then the public branch named \"mywork\"\nalways fast-forwards. Its first parent, mywork^, is always a clean\npatch series against upstream, and is what you'll eventually submit.\nThe second parent leads to historical versions of the patch series.\n\n> Working on top of a rebased \n> branch could be much easier if there was a dedicated command to perform \n> the local rebase of one's work after a fetch, just like the pull command \n> does a merge after a fetch, at which point both work flows would be \n> almost equivalent wrt ease of use.\n\nI don't think that works if you have more than one branch built on top\nof the branch you're fetching.\n\nThe problem is that you have to do the rebase at the same time as the\nfetch, because it's only the fetch that knows what the old head of the\nbranch was.\n\nYou don't need to know what the old head of the branch was before if\nyou're fetching a branch that always fast-forwards. But you do in the\ncase where it doesn't fast-forward, because in that case the old head\nwill be forgotten as soon as you're done.\n\n--b.\n"},{"id":"60909","messageId":"20071126061509.GA21116@efreet.light.src","threadId":"10420","inReplyTo":"20071126041521.GA21120@fieldses.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-26T06:15:09Z","receivedAt":"2007-11-26T06:15:09Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Mon, Nov 26, 2007 at 04:15:21 +0000, J. Bruce Fields wrote:\n> The trick of\n> \n> \ttag -d old_base remote/master\n> \tgit fetch remote\n> \tgit rebase --onto remote/master old_base my_work\n> \n> is something we don't document anywhere.\n\nDo we really need the tag/branch?\n\ngit fetch remote\ngit rebase --onto remote/master remote/master@{1} my_work\n\nAnd of course the thing is only needed if master has been rewound. Otherwise\njust:\n\ngit rebase remote/master my_work\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"60921","messageId":"fie23u$5tc$1@ger.gmane.org","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711252324360.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-26T09:03:01Z","receivedAt":"2007-11-26T09:03:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> On Mon, 26 Nov 2007, J. Bruce Fields wrote:\n> \n>> I do find that trying to work on top of a constantly rebased branch is\n>> annoying no matter how I do it. So I sometimes wonder if we shouldn't\n>> instead be finding ways to avoid the practice.\n> \n> I don't think it can't be avoided in many cases. Some stuff gets \n> rebased because it has to be refined before it is merged in a more \n> stable and more \"official\" repository. Working on top of a rebased \n> branch could be much easier if there was a dedicated command to perform \n> the local rebase of one's work after a fetch, just like the pull command \n> does a merge after a fetch, at which point both work flows would be \n> almost equivalent wrt ease of use.\n\nThere was idea of 'rebase' merge strategy (which was in some form\nimplemented once under another name: check archives if you want).\nAnd there is an idea of --rebase switch git git-pull.\n\nWhat is left is the implementation ;-)\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"60922","messageId":"474A8D2D.6010800@op5.se","threadId":"10420","inReplyTo":"fie23u$5tc$1@ger.gmane.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-26T09:09:01Z","receivedAt":"2007-11-26T09:09:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> Nicolas Pitre wrote:\n> \n>> On Mon, 26 Nov 2007, J. Bruce Fields wrote:\n>>\n>>> I do find that trying to work on top of a constantly rebased branch is\n>>> annoying no matter how I do it. So I sometimes wonder if we shouldn't\n>>> instead be finding ways to avoid the practice.\n>> I don't think it can't be avoided in many cases. Some stuff gets \n>> rebased because it has to be refined before it is merged in a more \n>> stable and more \"official\" repository. Working on top of a rebased \n>> branch could be much easier if there was a dedicated command to perform \n>> the local rebase of one's work after a fetch, just like the pull command \n>> does a merge after a fetch, at which point both work flows would be \n>> almost equivalent wrt ease of use.\n> \n> There was idea of 'rebase' merge strategy (which was in some form\n> implemented once under another name: check archives if you want).\n> And there is an idea of --rebase switch git git-pull.\n> \n> What is left is the implementation ;-)\n> \n\n\"git pull --rebase\" already has an implementation. Dscho cooked one up\nwhich I've been using since then. It works nicely.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"60953","messageId":"alpine.LFD.0.99999.0711261358410.9605@xanadu.home","threadId":"10420","inReplyTo":"fie23u$5tc$1@ger.gmane.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T19:11:17Z","receivedAt":"2007-11-26T19:11:17Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"\n[ I get really really annoyed when your replies to me aren't directly \n addressed to me, Jakub. Told you so repeatedly in the past as well.\n Why are you the only one on this list apparently not able to use a \n proper email setup? ]\n\nOn Mon, 26 Nov 2007, Jakub Narebski wrote:\n\n> Nicolas Pitre wrote:\n> \n> > Some stuff gets rebased because it has to be refined before it is \n> > merged in a more stable and more \"official\" repository. Working on \n> > top of a rebased branch could be much easier if there was a \n> > dedicated command to perform the local rebase of one's work after a \n> > fetch, just like the pull command does a merge after a fetch, at \n> > which point both work flows would be almost equivalent wrt ease of \n> > use.\n> \n> There was idea of 'rebase' merge strategy (which was in some form\n> implemented once under another name: check archives if you want).\n> And there is an idea of --rebase switch git git-pull.\n> \n> What is left is the implementation ;-)\n\nI thought that had been implemented already. But in fact I had forgot \nabout it altogether.\n\nIt shouldn't be much complicated than:\n\n\tgit fetch ${remote} && \\\n\tgit rebase --onto ${remote} ${remote}\"@{1}\" ${local}\n\ngiven that ${remote} did actually change during the fetch.\n\n\nNicolas\n"},{"id":"60957","messageId":"85lk8k24ju.fsf@lola.goethe.zz","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711261358410.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T19:24:37Z","receivedAt":"2007-11-26T19:24:37Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Nicolas Pitre writes:\n\n> [ I get really really annoyed when your replies to me aren't directly \n> addressed to me, Jakub. Told you so repeatedly in the past as well.\n> Why are you the only one on this list apparently not able to use a \n> proper email setup? ]\n\nX-Injected-Via-Gmane: http://gmane.org/\n\nAnd Jakub by far is not the only one using gmane for reading and writing\nto the list.\n\nI am reading and writing on a number of mailing lists with either\nexplicit or implicit gateways to news servers. But the git mailing list\nis the only one where I ever encountered a semi-permanent stream of\n(sometimes quite rude) complaints because people insist on getting\nreplies at least twice: once by the mailing list, and once by personal\nEmail. In contrast to claims made here, it is _not_ common netiquette\nto create extra personal copies. In fact, for articles sent through\nUsenet servers, it is generally considered an _annoyance_ to include\nunannounced \"courtesy copies\" since replies to them will not usually\nreach the list and will require redoing.\n\nAnd I have received complaints about accumulating Cc lists from mailing\nlist moderators as well, since list servers tend to queue stuff for\nmoderation once the Cc header reaches a certain size.\n\nI really don't get the point of those demands for personal extra copies:\ndo people or don't they read the mailing list?\n\nOn the current computer setup, I am answering to the list. On a\ndifferent computer, all mail to the mailing list disappears into a black\nhole without any indication why. So I _have_ to use gmane there. And I\ndon't see why I should get heat for that when apparently the\nautomoderation of the list is set up as rabidly as to quietly censor\neverything I send via Email (everybody else is able to receive mail\nthrough that account from me).\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"60974","messageId":"alpine.LFD.0.99999.0711261511240.9605@xanadu.home","threadId":"10420","inReplyTo":"85lk8k24ju.fsf@lola.goethe.zz","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T20:25:36Z","receivedAt":"2007-11-26T20:25:36Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, David Kastrup wrote:\n\n> Nicolas Pitre writes:\n> \n> > [ I get really really annoyed when your replies to me aren't directly \n> > addressed to me, Jakub. Told you so repeatedly in the past as well.\n> > Why are you the only one on this list apparently not able to use a \n> > proper email setup? ]\n> \n> X-Injected-Via-Gmane: http://gmane.org/\n> \n> And Jakub by far is not the only one using gmane for reading and writing\n> to the list.\n\nIt is strange, though, that Jakub is the only one I've noticed who isn't \nable to do me the courtesy of addressing me directly when replying to \nme.\n\n> I am reading and writing on a number of mailing lists with either\n> explicit or implicit gateways to news servers. But the git mailing list\n> is the only one where I ever encountered a semi-permanent stream of\n> (sometimes quite rude) complaints because people insist on getting\n> replies at least twice: once by the mailing list, and once by personal\n> Email. In contrast to claims made here, it is _not_ common netiquette\n> to create extra personal copies.\n\nWe must not live in the same virtual world then. This _is_ common \nnetiquette in the Linux world.\n\nI get over 500 emails a day. I can thread them just like a news \nreader would do. But I do sort them in different folders as well. My \nmost important folder contains emails directly sent to me, or on which \nI'm CC'd. The other folders might get completely ignored when I'm too \nbusy, or threads quickly purged out.\n\n> In fact, for articles sent through\n> Usenet servers, it is generally considered an _annoyance_ to include\n> unannounced \"courtesy copies\" since replies to them will not usually\n> reach the list and will require redoing.\n\nThis is a mailing list and not a news group. I don't care if you use a \nnewsgroup gateway if it isn't broken. As it is, gmane is broken as far \nas I'm concerned.\n\nSo please complain to gmane or change your setup.\n\n\nNicolas\n"},{"id":"60979","messageId":"7voddgg2pa.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711261511240.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-26T20:40:49Z","receivedAt":"2007-11-26T20:40:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n>> Nicolas Pitre writes:\n>> \n> This is a mailing list and not a news group. I don't care if you use a \n> newsgroup gateway if it isn't broken. As it is, gmane is broken as far \n> as I'm concerned.\n>\n> So please complain to gmane or change your setup.\n\nDon't blame gmane, please. I picked this message up in gmane and I am\nresponding to you in my newsreader.\n"},{"id":"60980","messageId":"85hcj8zqfm.fsf@lola.goethe.zz","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711261511240.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T20:45:33Z","receivedAt":"2007-11-26T20:45:33Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 26 Nov 2007, David Kastrup wrote:\n>\n>> In fact, for articles sent through Usenet servers, it is generally\n>> considered an _annoyance_ to include unannounced \"courtesy copies\"\n>> since replies to them will not usually reach the list and will\n>> require redoing.\n>\n> This is a mailing list and not a news group. I don't care if you use\n> a newsgroup gateway if it isn't broken. As it is, gmane is broken as\n> far as I'm concerned.\n\nA gateway should not be sending to anything but the mailing list\naddress. It is not a mail multiplicator.\n\n> So please complain to gmane or change your setup.\n\nI already explained: the git mailing list is set up in a manner that\nwill block mail from some accounts of mine without notice or error\nreport.\n\nIf there is general consensus on the list that news gateways are not\ncompatible with the mailing list policies, please report this to gmane,\nand gmane will switch the list off-line.\n\nI have no idea why anybody would think this an improvement, but given\nthe amount of flak I already got for daring to use gmane, it will\nprobably improve the atmosphere on the list if people like me are locked\nout completely from participation rather than their usage of gmane be\nlambasted time and again.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"60985","messageId":"alpine.LFD.0.99999.0711261601240.9605@xanadu.home","threadId":"10420","inReplyTo":"85hcj8zqfm.fsf@lola.goethe.zz","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T21:09:58Z","receivedAt":"2007-11-26T21:09:58Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, David Kastrup wrote:\n\n> Nicolas Pitre writes:\n> \n> > This is a mailing list and not a news group. I don't care if you use\n> > a newsgroup gateway if it isn't broken. As it is, gmane is broken as\n> > far as I'm concerned.\n> \n> A gateway should not be sending to anything but the mailing list\n> address. It is not a mail multiplicator.\n\nThen don't use it.\n\nYet Junio just replied to my mail, apparently using his news reader, and \nI was directly addressed.\n\n> > So please complain to gmane or change your setup.\n> \n> I already explained: the git mailing list is set up in a manner that\n> will block mail from some accounts of mine without notice or error\n> report.\n\nAnd why should _I_ care? This is _your_ problem for you to investigate.\n\n> If there is general consensus on the list that news gateways are not\n> compatible with the mailing list policies, please report this to gmane,\n> and gmane will switch the list off-line.\n\nLook, it is you the offender here with your broken setup to interact \nwith this mailing list. So I'm complaining to _you_. Please cope with \nit.\n\n> I have no idea why anybody would think this an improvement, but given\n> the amount of flak I already got for daring to use gmane, it will\n> probably improve the atmosphere on the list if people like me are locked\n> out completely from participation rather than their usage of gmane be\n> lambasted time and again.\n\nPlease figure out an alternative to gmane on your own, or ask those who \napparently get it to work properly. I'm sure you're bright enough to \nfind a way.\n\n\nNicolas\n"},{"id":"60986","messageId":"200711262214.54291.jnareb@gmail.com","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711261511240.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-26T21:14:53Z","receivedAt":"2007-11-26T21:14:53Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n> On Mon, 26 Nov 2007, David Kastrup wrote:\n> \n>> Nicolas Pitre writes:\n>> \n>>> [ I get really really annoyed when your replies to me aren't directly \n>>> addressed to me, Jakub. Told you so repeatedly in the past as well.\n>>> Why are you the only one on this list apparently not able to use a \n>>> proper email setup? ]\n\nIt is about proper _newsreader_ setup, in fact...\n\n>> X-Injected-Via-Gmane: http://gmane.org/\n>> \n>> And Jakub by far is not the only one using gmane for reading and writing\n>> to the list.\n> \n> It is strange, though, that Jakub is the only one I've noticed who isn't \n> able to do me the courtesy of addressing me directly when replying to \n> me.\n\nMy responding [sometimes] only to list is combination of several\nissues.\n\nFirst, newsreader I use, namely KNode 0.10.2 in Kontact 1.2.3 from\nKDE 3.5.3 does not make it easy. By default it replies only to list\nunless Mail-Reply-To header is used (which shouldn't IIRC). I have\nto click reply by e-mail button to send reply via email... and it\nadds only last author, from From header. The rest I have to add by\nhand.\n\nSecond, something is rotten^W broken between GMane and VGER; if I add\ngit email address to the list of addresses to send to, VGER rejects and\nrefuses to send to git mailing list. I have to send also to newsgroup\n(gmane.comp.version-control.git) to send to all git mailing list. Now\nit looks like two mails are actually send: one to CC'ed addresses, one\nto git mailing list, and sometimes people when replying me forget to\nreply also to git mailing list.\n\nSo third, when I don't think I have something significant to contribute,\nand I don't necessary expect answer, I send email only to git mailing\nlist (news message only to GMane newsgroup coupled with git mailing\nlist, actually).\n\n\nSure, one of solutions would be for me to change newsreader, for example\nto Gnus (as people using Gnus doesn't seem to have the same problem\nI have), but I think you do know that it is not easy to change habits.\n\n[cut]\n\nNevertheless, mails are sent to git mailing list, so they should go\nto you too.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"60987","messageId":"85sl2sya55.fsf@lola.goethe.zz","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711261601240.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T21:22:46Z","receivedAt":"2007-11-26T21:22:46Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Nicolas Pitre writes:\n\n> Please figure out an alternative to gmane on your own, or ask those\n> who apparently get it to work properly. I'm sure you're bright enough\n> to find a way.\n\nWithout so much as a bounce message or delivery report, there is nothing\nto apply one's brightness to.\n\nSince the git mailing list is the only mailing list that censors my work\naccount in that manner, it is obviously set up in a way different from\nmost other mailing lists.\n\nNot being a list moderator and not getting any bounce notification,\nthere is nothing I can use for figuring out what makes the git mailing\nlist different from others.\n\nAnd the gratuitous hostility easily evoked towards anybody experiencing\nproblems with either the list or other aspects concerning git is really\nsomething I have not experienced in any other developer circle.\n\nAnd I am quite an oldtimer concerning both mailing lists and Usenet.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"60993","messageId":"Pine.LNX.4.64.0711262135430.27959@racer.site","threadId":"10420","inReplyTo":"200711262214.54291.jnareb@gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-26T21:36:59Z","receivedAt":"2007-11-26T21:36:59Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Nov 2007, Jakub Narebski wrote:\n\n> Nicolas Pitre wrote:\n> > On Mon, 26 Nov 2007, David Kastrup wrote:\n> > \n> >> Nicolas Pitre writes:\n> >> \n> >>> [ I get really really annoyed when your replies to me aren't directly \n> >>> addressed to me, Jakub. Told you so repeatedly in the past as well.\n> >>> Why are you the only one on this list apparently not able to use a \n> >>> proper email setup? ]\n> \n> Nevertheless, mails are sent to git mailing list, so they should go to \n> you too.\n\nIt was already explained (not often enough?) that some people are \nextremely busy, such as Nicolas.\n\nTherefore, they have to prioritise.\n\nIf you choose to be ignored, that's fine by me ;-)\n\nCiao,\nDscho\n"},{"id":"60997","messageId":"alpine.LFD.0.99999.0711261642350.9605@xanadu.home","threadId":"10420","inReplyTo":"Pine.LNX.4.64.0711262135430.27959@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T21:47:03Z","receivedAt":"2007-11-26T21:47:03Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, Johannes Schindelin wrote:\n\n> On Mon, 26 Nov 2007, Jakub Narebski wrote:\n> \n> > Nevertheless, mails are sent to git mailing list, so they should go to \n> > you too.\n> \n> It was already explained (not often enough?) that some people are \n> extremely busy, such as Nicolas.\n> \n> Therefore, they have to prioritise.\n> \n> If you choose to be ignored, that's fine by me ;-)\n\nI hate when I miss on followups to my own posts though. \nThat is the real issue.\n\n\nNicolas\n"},{"id":"60999","messageId":"alpine.LFD.0.99999.0711261649000.9605@xanadu.home","threadId":"10420","inReplyTo":"85sl2sya55.fsf@lola.goethe.zz","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T22:02:37Z","receivedAt":"2007-11-26T22:02:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Mon, 26 Nov 2007, David Kastrup wrote:\n\n> Without so much as a bounce message or delivery report, there is nothing\n> to apply one's brightness to.\n\nMaybe you could try firing up your web browser and directing it at \nhttp://vger.kernel.org, just in case there might be a web page set up \nthere with some clues. Hey, there is actually a web page there.\n\nIn particular, there is a link there that reads as \"Email delivery \ntesting tool: mxverify\". Did you try it?\n\nThere is another link with \"TABOO in the lists\". Maybe you might find \nsomething there?\n\n\nNicolas\n"},{"id":"61005","messageId":"85bq9gy5e0.fsf@lola.goethe.zz","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711261649000.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T23:05:27Z","receivedAt":"2007-11-26T23:05:27Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Nicolas Pitre writes:\n\n> On Mon, 26 Nov 2007, David Kastrup wrote:\n>\n>> Without so much as a bounce message or delivery report, there is nothing\n>> to apply one's brightness to.\n>\n> Maybe you could try firing up your web browser and directing it at \n> http://vger.kernel.org, just in case there might be a web page set up \n> there with some clues. Hey, there is actually a web page there.\n\nI really _love_ how the default response on this list for any problem is\nto treat one as an idiot and openly show one's contempt. The\ninformation about subscribing to the mailing list can be found at the\nGit home page at . It does not mention\nanything like a mailing list home page. Only the archives are\nmentioned, and those contain no pointer whatsoever. It does remind me\nof the late Douglas Adams' Hitchhiker's guide to the galaxy:\n\n `...You hadn't exactly gone out of your way to call attention to\n them had you? I mean like actually telling anyone or anything.'\n `But the plans were on display...'\n `On display? I eventually had to go down to the cellar to find\n them.'\n `That's the display department.'\n `With a torch.'\n `Ah, well the lights had probably gone.'\n `So had the stairs.'\n `But look you found the notice didn't you?'\n `Yes,' said Arthur, `yes I did. It was on display in the bottom of a\n locked filing cabinet stuck in a disused lavatory with a sign on the\n door saying \"Beware of The Leopard\".'\n\nAnyway, with your pointer I might be able to work through the stuff and\nfigure out what makes vger so unique here as a mailing list host.\n\nOn the other hand: why bother participating in a community that turns\nopenly hostile whenever one experiences problems? Where is the fun in\nthat? That one will at one point of time be in the situation to lambast\nothers for their shortcomings, and feel that one is entirely in-style\ndoing so here?\n\nIs it really impossible to proffer any information without a denigrating\nsneer?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61008","messageId":"alpine.LFD.0.99999.0711261817450.9605@xanadu.home","threadId":"10420","inReplyTo":"85bq9gy5e0.fsf@lola.goethe.zz","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-26T23:28:43Z","receivedAt":"2007-11-26T23:28:43Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, David Kastrup wrote:\n\n> On the other hand: why bother participating in a community that turns\n> openly hostile whenever one experiences problems? Where is the fun in\n> that? That one will at one point of time be in the situation to lambast\n> others for their shortcomings, and feel that one is entirely in-style\n> doing so here?\n\nDavid, honestly, my problem with you is that you seem to be the only one \nhaving such relational problems around here, and instead of doing some \nhomework and obvious guessing on your own to save everyone's nerves, you \ninstead write dissertations about the list hostility, etc. Which in \nturns will obviously earn you more hostilities.\n\nPlease get a grip.\n\n\nNicolas\n"},{"id":"61009","messageId":"85oddgva33.fsf@lola.goethe.zz","threadId":"10420","inReplyTo":"alpine.LFD.0.99999.0711261817450.9605@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-11-26T23:52:16Z","receivedAt":"2007-11-26T23:52:16Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Nicolas Pitre writes:\n\n> On Tue, 27 Nov 2007, David Kastrup wrote:\n>\n>> On the other hand: why bother participating in a community that turns\n>> openly hostile whenever one experiences problems? Where is the fun in\n>> that? That one will at one point of time be in the situation to lambast\n>> others for their shortcomings, and feel that one is entirely in-style\n>> doing so here?\n>\n> David, honestly, my problem with you is that you seem to be the only one \n> having such relational problems around here,\n\nI am the only one? I quote from your reply to my original contribution\nin this thread:\n\n>On Mon, 26 Nov 2007, David Kastrup wrote:\n>\n>> Nicolas Pitre writes:\n>> \n>> > [ I get really really annoyed when your replies to me aren't directly \n>> > addressed to me, Jakub. Told you so repeatedly in the past as well.\n>> > Why are you the only one on this list apparently not able to use a \n>> > proper email setup? ]\n>> \n>> X-Injected-Via-Gmane: http://gmane.org/\n>> \n>> And Jakub by far is not the only one using gmane for reading and writing\n>> to the list.\n>\n>It is strange, though, that Jakub is the only one I've noticed who isn't \n>able to do me the courtesy of addressing me directly when replying to \n>me.\n\nSo here you are telling Jakub off as discourteous and the \"only one on\nthis list apparently not able to use a proper email setup\". And when I\nexplain that I have been in the same situation with a different account\nof mine and that this has nothing to do with discourtesy, the heat turns\nover to me.\n\nAnd, again, this is declared an absolutely isolated phenomenon\nrestricted to a single person.\n\nI am afraid that I am too stupid to understand what goal is supposed to\nbe achieved by this sort of behavior. I don't see anything except\nannoyance for everybody involved.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"61026","messageId":"alpine.LFD.0.99999.0711262250310.9605@xanadu.home","threadId":"10420","inReplyTo":"85oddgva33.fsf@lola.goethe.zz","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T04:05:07Z","receivedAt":"2007-11-27T04:05:07Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, David Kastrup wrote:\n\n> Nicolas Pitre writes:\n> \n> > David, honestly, my problem with you is that you seem to be the only one \n> > having such relational problems around here,\n> \n> I am the only one? I quote from your reply to my original contribution\n> in this thread:\n> \n> >On Mon, 26 Nov 2007, David Kastrup wrote:\n> >\n> >> Nicolas Pitre writes:\n> >> \n> >> > [ I get really really annoyed when your replies to me aren't directly \n> >> > addressed to me, Jakub. Told you so repeatedly in the past as well.\n> >> > Why are you the only one on this list apparently not able to use a \n> >> > proper email setup? ]\n> >> \n> >> X-Injected-Via-Gmane: http://gmane.org/\n> >> \n> >> And Jakub by far is not the only one using gmane for reading and writing\n> >> to the list.\n> >\n> >It is strange, though, that Jakub is the only one I've noticed who isn't \n> >able to do me the courtesy of addressing me directly when replying to \n> >me.\n> \n> So here you are telling Jakub off as discourteous and the \"only one on\n> this list apparently not able to use a proper email setup\".\n\nExact.\n\n> And when I explain that I have been in the same situation with a \n> different account of mine and that this has nothing to do with \n> discourtesy, the heat turns over to me.\n\nThen it must be laziness. And while Jakub admits there is a problem, \nyou insist otherwise, building hostility towards you in the process.\n\n> And, again, this is declared an absolutely isolated phenomenon\n> restricted to a single person.\n\nOK now you are two. So what? This still looks like a tiny minority to \nme.\n\n> I am afraid that I am too stupid to understand what goal is supposed to\n> be achieved by this sort of behavior. I don't see anything except\n> annoyance for everybody involved.\n\nYou are really annoying indeed.\n\n\nNicolas\n"},{"id":"61552","messageId":"7vzlwv6sxr.fsf@gitster.siamese.dyndns.org","threadId":"10420","inReplyTo":"7v4pfakr4j.fsf@gitster.siamese.dyndns.org","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-01T02:37:52Z","receivedAt":"2007-12-01T02:37:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking. Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'. The topics list the commits in reverse chronological\norder.\n\n----------------------------------------------------------------\n[Graduated to 'master']\n\n* jk/maint-cvsimport-fix (Wed Nov 28 13:56:28 2007 -0500)\n\n----------------------------------------------------------------\n[New Topics]\n\n* jc/api-doc (Sat Nov 24 23:48:04 2007 -0800) 1 commit\n - Start preparing the API documents.\n\nThe primary reason of this series is because I think we made the system\na lot less approachable by losing hackability. Although we still have\nsample scripts in contrib/example for use of plumbing in scripts, they\nwill not help aspiring git-hacker-wannabees when our primary attention\nhas already shifted to moving things to C.\n\nThis currently consists of mostly stubs, although I wrote about a few\ntopics as examples.\n\n* js/fast-export (Sun Nov 25 22:37:20 2007 +0100) 1 commit\n - Add 'git fast-export', the sister of 'git fast-import'\n\nThis needs something like 9e42d6a1c53dadd409fab11cc76e0eba9ec15365\n(sha1_file.c: Fix size_t related printf format warnings) to compile, I\nthink, but I haven't tried to fix it (parked in pu)\n\n* js/pull-rebase (Wed Nov 28 13:11:07 2007 +0000) 1 commit\n + Teach 'git pull' about --rebase\n\nResurrected from an old thread (thanks, Dscho and Nana for reminding).\n\n* jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit\n + Support builtin aliases\n\nCute hack. I'd like to have \"git less\" here.\n\n* wc/rebase-insn (Sat Nov 24 00:38:50 2007 +1100) 2 commits\n + Mention that git-rm can be an appropriate resolution as well as\n git-add.\n + revert/cherry-pick: Allow overriding the help text by the calling\n Porcelain\n\nPatches from Wincent and David Symonds. They both improve the help\nmessage upon conflicts.\n\n* js/prune-expire (Thu Nov 29 20:59:55 2007 +0000) 1 commit\n + Add \"--expire