{"thread":{"id":"4664","subject":"What's in git.git","startedAt":"2006-06-25T09:37:15Z","lastAt":"2006-06-27T07:55:16Z","messageCount":8,"participants":["Junio C Hamano","Linus Torvalds","Timo Hirvonen","Martin Langhoff","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"22533","messageId":"7v7j35wp84.fsf@assigned-by-dhcp.cox.net","threadId":"4664","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-25T09:37:15Z","receivedAt":"2006-06-25T09:37:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"No v1.4.1-rc2 this weekend, as I am expecting a visitor today\nand will mostly be offline. But we got a dozen or so good fixes\nand cleanups in \"master\" so far.\n\nIn \"next\", we have the following being cooked. I expect most of\nthem to be in v1.4.1-rc2 sometime next week. Please report\nbreakage on any of these if you see one.\n\n - \"git rebase --merge\" updates by Eric Wong.\n - \"git diff -b -w\" by Johannes.\n - \"git cvsimport\" multi-branch fixes by Martin and Johannes.\n - \"git diff --color\" can be controlled from $GIT_DIR/config.\n - \"git merge --squash\"; this may not be strictly needed as it\n can be emulated with repeated use of \"cherry-pick -n\" but it\n might be handy in some workflows.\n\nIn \"pu\", I have queued other bigger changes. I do not think\nmost of them are v1.4.1 material yet.\n\n - \"git format-patch --ignore-already-merged\" fixes by\n Johannes; I am hoping to have this in v1.4.1.\n\n - Perl scripts clean-up and Git.xs by Pasky with a few fixes by\n me; in my mailbox there are several other patches in this\n series not in \"pu\" that primarily makes more scripts to use\n the new Perl infrastructure. My feeling is that the series\n needs to be proven to have a sound infrastructure (building,\n testing and installation) on a bit wider platforms before\n starting to consider them for inclusion in \"next\". We may be\n able to have the basics from this series in v1.4.1, but am\n still uneasy to convert any important scripts to use this,\n even in \"next\", at this moment. Not just yet.\n\n - built-in \"git am\" by Lukas; it fails some tests which is not\n a good sign, and as I said in a separate message a few days\n ago, I think it is not worth going this route for something\n high-level as \"am\", so probably the next round I'd drop the\n last patch from the topic. The patch to clean up cmd_apply()\n might be worth keeping and merging in \"next\", depending on\n how the Git.xs effort goes, though.\n\n - \"git diff\" option clean-ups by Timo Hirvonen; this is moving\n things in a good direction but as with any intrusive cleanups\n still has some rough edges. I am hoping we can round them\n off soon to merge it in \"next\".\n\n - A new PPC SHA-1 implementation by linux@horizon.com; Linus\n showed that this does not make much difference in real life\n from performance point of view. If it has other benefits\n (such as code size -- which I do not know how it fares), I am\n willing to merge it as it seems to be correct and does not\n seem to introduce regressions. But I am not a PPC user so\n somebody needs to push my back on this one.\n\n----------------------------------------------------------------\n\n* The 'master' branch has these since the last announcement.\n\n Jeff King:\n git-commit: allow -e option anywhere on command line\n\n Johannes Schindelin:\n patch-id: take \"commit\" prefix as well as \"diff-tree\" prefix\n apply: replace NO_ACCURATE_DIFF with --inaccurate-eof runtime flag.\n\n Junio C Hamano:\n Makefile: do not recompile main programs when libraries have changed.\n usage: minimum type fix.\n git-pull: abort when fmt-merge-msg fails.\n diff --color: use reset sequence when we mean reset.\n repo-config: fix printing of bool\n\n Linus Torvalds:\n Tweak diff colors\n\n Martin Langhoff:\n git-repack -- respect -q and be quiet\n\n Matthias Kestenholz:\n add GIT-CFLAGS to .gitignore\n\n Peter Eriksen:\n Rename safe_strncpy() to strlcpy().\n\n Petr Baudis:\n Customizable error handlers\n\n Timo Hirvonen:\n git-merge: Don't use -p when outputting summary\n Clean up diff.c\n\n Yann Dirson:\n git-commit: filter out log message lines only when editor was run.\n\n\n* The 'next' branch, in addition, has these.\n\n Eric Wong:\n rebase: allow --merge option to handle patches merged upstream\n rebase: cleanup rebasing with --merge\n rebase: allow --skip to work with --merge\n\n Johannes Schindelin:\n Teach diff about -b and -w flags\n cvsimport: always set $ENV{GIT_INDEX_FILE} to $index{$branch}\n\n Junio C Hamano:\n Makefile: add framework to verify and bench sha1 implementations.\n git-merge --squash\n test-sha1: test hashing large buffer\n diff --color: use $GIT_DIR/config\n\n Martin Langhoff:\n cvsimport: setup indexes correctly for ancestors and incremental imports\n\n\n* The 'pu' branch, in addition, has these (this fails the tests).\n\n Johannes Schindelin:\n add diff_flush_patch_id() to calculate the patch id\n format-patch: introduce \"--ignore-if-in-upstream\"\n\n Junio C Hamano:\n Perl interface: add build-time configuration to allow building with -fPIC\n Perl interface: make testsuite work again.\n perl: fix make clean\n Git.pm: tentative fix to test the freshly built Git.pm\n\n Lukas Sandström:\n Make it possible to call cmd_apply multiple times\n Make git-am a builtin\n\n Petr Baudis:\n Introduce Git.pm (v4)\n Git.pm: Implement Git::exec_path()\n Git.pm: Call external commands using execv_git_cmd()\n Git.pm: Implement Git::version()\n Add Error.pm to the distribution\n Git.pm: Better error handling\n Git.pm: Handle failed commands' output\n Git.pm: Enhance the command_pipe() mechanism\n Git.pm: Implement options for the command interface\n Git.pm: Add support for subdirectories inside of working copies\n Convert git-mv to use Git.pm\n Git.pm: assorted build related fixes.\n\n Timo Hirvonen:\n Merge with_raw, with_stat and summary variables to output_format\n Make --raw option available for all diff commands\n Set default diff output format after parsing command line\n DIFF_FORMAT_RAW is not default anymore\n --name-only, --name-status, --check and -s are mutually exclusive\n Remove awkward compatibility warts\n\n Unknown (linux@horizon.com):\n A better-scheduled PPC SHA-1 implementation.\n"},{"id":"22574","messageId":"Pine.LNX.4.64.0606251033030.3747@g5.osdl.org","threadId":"4664","inReplyTo":"7v7j35wp84.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-25T17:47:10Z","receivedAt":"2006-06-25T17:47:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 25 Jun 2006, Junio C Hamano wrote:\n> \n> Timo Hirvonen:\n> Clean up diff.c\n\nTHIS IS CRAP!\n\nDammit, anybody who claims that casting a constant string to \"(char *)\" is \na _cleanup_ is doing something seriously wrong.\n\nThat's crap, crap, crap, CRAP!\n\nIf the \"cleanup\" was about hiding compiler warnings, then dammit, those \nwarnings should be fixed by fixing the code, not by casting the warning \naway but leaving the broken code.\n\nIf the ptr really is never accessed, and doesn't matter, then don't use a \nconstant empty string, use NULL.\n\nAnd if it _is_ accessed, then casting a constant string to \"char *\" is \n_wrong_. \n\nThe whole and only point about the \"const\" warnings is not to hide them, \nbut to fix the code. If you're not going to fix the code, then you \nshouldn't ask the compiler to warn about it, it's that simple. Adding \nbogus casts is not the answer.\n\nI really hate how many _bogus_ casts we're growing. Casts are one of the \nmost important features of C (it's what allows you to break the type \nsystem if you need to, and turns C into the truly extensible language it \nis), but they should be used with reverence and care, not to shut up a \ncompiler.\n\nI'm _especially_ disgusted by how this was claimed to be a \"cleanup\". \nAdding a cast is _never_ a cleanup.\n\nDammit, don't do crap like this!\n\nTHIS is a cleanup:\n\n- char *prefix = \"\";\n+ const char *prefix = \"\";\n\nbut THESE are total and utter CRAP:\n\n- mf->ptr = \"\"; /* does not matter */\n+ mf->ptr = (char *)\"\"; /* does not matter */\n- s->data = \"\";\n+ s->data = (char *)\"\";\n\nand we're better off with the warning than with the new code.\n\nI suspect that both could have been made to use NULL instead to indicate \nthat no pointer exists.\n\n\t\t\tLinus\n"},{"id":"22576","messageId":"20060625210724.934617c4.tihirvon@gmail.com","threadId":"4664","inReplyTo":"Pine.LNX.4.64.0606251033030.3747@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-06-25T18:07:24Z","receivedAt":"2006-06-25T18:07:24Z","isPatch":false,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"Linus Torvalds wrote:\n\n> On Sun, 25 Jun 2006, Junio C Hamano wrote:\n> > \n> > Timo Hirvonen:\n> > Clean up diff.c\n> \n> THIS IS CRAP!\n> \n> Dammit, anybody who claims that casting a constant string to \"(char *)\" is \n> a _cleanup_ is doing something seriously wrong.\n> \n> That's crap, crap, crap, CRAP!\n\nSorry. It got really annoying to skip over the same compiler warnings\nin vim's quickfix window many times. At that time I just wanted to\nfocus on the code I was writing.\n\n> but THESE are total and utter CRAP:\n> \n> - mf->ptr = \"\"; /* does not matter */\n> + mf->ptr = (char *)\"\"; /* does not matter */\n> - s->data = \"\";\n> + s->data = (char *)\"\";\n> \n> and we're better off with the warning than with the new code.\n> \n> I suspect that both could have been made to use NULL instead to indicate \n> that no pointer exists.\n\nI'll look into this.\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"22577","messageId":"Pine.LNX.4.64.0606251138580.3747@g5.osdl.org","threadId":"4664","inReplyTo":"20060625210724.934617c4.tihirvon@gmail.com","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-25T18:43:30Z","receivedAt":"2006-06-25T18:43:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 25 Jun 2006, Timo Hirvonen wrote:\n> > \n> > I suspect that both could have been made to use NULL instead to indicate \n> > that no pointer exists.\n> \n> I'll look into this.\n\nAn alternative is to really mark the char pointer structure members const. \nThat is often the preferred thing to do, if usage allows it.\n\nThe biggest problem I've traditionally had with structure members that are \n\"const char *\" has ironically been that the standard C definition of \n\"free()\" is misdesigned. \n\n\"free()\" should take a \"const volatile void *\", not just a \"void *\". As it \nis, you often have to cast things to free() just to avoid the warning \nabout discarding qualifiers. Which is really sad.\n\nIt's perfectly valid to do something like\n\n\tstruct xyzzy {\n\t\tconst char *member;\n\t\t..\n\t};\n\n\ts->member = strdup(string);\n\t..\n\tfree(s->member);\n\tfree(s)\n\nbut sadly, that member free generates a (bogus) warning.\n\nOf course, we should probably do a \"xfree()\" anyway, to match our \n\"x[c|re]alloc()\".\n\n\t\t\tLinus\n"},{"id":"22616","messageId":"46a038f90606261524q6b0d7abbweb4fb40cd4fb423a@mail.gmail.com","threadId":"4664","inReplyTo":"7v7j35wp84.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-06-26T22:24:59Z","receivedAt":"2006-06-26T22:24:59Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 6/25/06, Junio C Hamano wrote:\n> - \"git cvsimport\" multi-branch fixes by Martin and Johannes.\n\nNote: I have the nagging suspicion that there's a thinko in the\nopening of new branches, but can't get into fixing that till later\ntoday.\n\ncheers,\n\n\n\nmartin\n"},{"id":"22639","messageId":"7vpsgvf8jf.fsf@assigned-by-dhcp.cox.net","threadId":"4664","inReplyTo":"Pine.LNX.4.64.0606251033030.3747@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-27T05:54:12Z","receivedAt":"2006-06-27T05:54:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I suspect that both could have been made to use NULL instead to indicate \n> that no pointer exists.\n\nAs long as none of the following does not dereference the NULL\npointer that should work fine:\n\n\t- memchr(NULL, ch, 0);\n\n - memcmp(NULL, ptr, 0);\n\n - stream.next_in = NULL;\n stream.avail_in = 0;\n deflate(&stream, Z_FINISH);\n"},{"id":"22640","messageId":"Pine.LNX.4.64.0606262321270.3927@g5.osdl.org","threadId":"4664","inReplyTo":"7vpsgvf8jf.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-06-27T06:29:36Z","receivedAt":"2006-06-27T06:29:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 26 Jun 2006, Junio C Hamano wrote:\n> \n> As long as none of the following does not dereference the NULL\n> pointer that should work fine:\n> \n> \t- memchr(NULL, ch, 0);\n> \n> - memcmp(NULL, ptr, 0);\n> \n> - stream.next_in = NULL;\n> stream.avail_in = 0;\n> deflate(&stream, Z_FINISH);\n\nWell, they clearly _shouldn't_, but bugs happen in libraries too.\n\n(The reason they shouldn't is simple: replace the NULL pointer with a \nperfectly normal pointer at the end of a page, and if you access past the \nlength of the memory area, you'd get the same SIGSEGV that a NULL pointer \nshould give you).\n\nSo the question is how much to trust the libraries for a special case that \nhas a clearly \"Right Answer\", but is probably unusual in practice.\n\n(That said, \"malloc(0)\" can validly return NULL, so the NULL+ \nthing can really happen in real code even if it's not explicit).\n\nIf people want to be anally defensive, we should give it a valid pointer. \nIf there are known buggy libraries, I wouldn't object to something \nexplicit like\n\n\t#define DUMMYPTR ((void *)\"\")\n\nand hide it that way - the code may be the exact same thing that I \nobjected to, but now you're showing that you know that the cast is crud, \nand you're just wanting to pass in some non-NULL valid pointer that can be \ndereferenced but never written to.\n\nPersonally, I think NULL is much better, until somebody shows an actual \nbuggy library.\n\n\t\t\tLinus\n"},{"id":"22643","messageId":"Pine.LNX.4.63.0606270954500.29667@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4664","inReplyTo":"Pine.LNX.4.64.0606262321270.3927@g5.osdl.org","subject":"Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-27T07:55:16Z","receivedAt":"2006-06-27T07:55:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Jun 2006, Linus Torvalds wrote:\n\n> \t#define DUMMYPTR ((void *)\"\")\n\nNULL_STRING describes better what you want.\n\nCiao,\nDscho\n"}]}