{"thread":{"id":"3247","subject":"What's new in git.git","startedAt":"2006-02-06T07:52:01Z","lastAt":"2006-02-07T08:40:10Z","messageCount":5,"participants":["Junio C Hamano","Linus Torvalds","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"15631","messageId":"7vbqxkapr2.fsf@assigned-by-dhcp.cox.net","threadId":"3247","inReplyTo":null,"subject":"What's new in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-06T07:52:01Z","receivedAt":"2006-02-06T07:52:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was planning to do a 1.2.0 this weekend, but things slipped.\nBut in a good way. We've had quite a long but good discussion\non how people expect \"git commit paths...\" to behave, and along\nthe way the command learned a couple of new tricks.\n\nIn 1.2.0, there will be three major changes that might surprise\npeople who are still using 1.1.0 based releases (e.g. 1.1.6).\nPeople who followed the list traffic and/or the master branch\nare familiar with them already:\n\n * Checkout -m option. This allows you to switch branches when\n you have local changes to paths that are different in the\n current branch and new branch.\n\n * Add -c and --cc to diff-tree and diff-files. They give the\n \"combined diff\" output that shows merges more human readably.\n\n * git-commit updates.\n\n - Allow git-commit from a subdirecotry.\n\n - Aborted \"git-commit -a\" leaves the index as it was.\n\n - \"git commit --only paths...\" checks in changes to only\n named paths. We may later make this default for \"git\n commit\" with explicit paths.\n\n - Add --author='A U Thor ' command\n line option.\n\nThese are still in \"pu\" but I am expecting all of them would\ngraduate to \"master\" before 1.2.0:\n\n - git-show (Linus)\n - git-daemon updates (Mark Wooding)\n - git-http-fetch various fixes (Mark Wooding)\n - git-commit updates\n - git-read-tree --aggressive to speed up resolve merger\n - git-fmt-merge-msg to optionally put shortlog in merge commit log\n - fix git-rev-list --parents | git-diff-tree --stdin\n - git-rerere\n"},{"id":"15632","messageId":"Pine.LNX.4.64.0602060754470.3854@g5.osdl.org","threadId":"3247","inReplyTo":"7vbqxkapr2.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's new in git.git","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-02-06T16:03:28Z","receivedAt":"2006-02-06T16:03:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 5 Feb 2006, Junio C Hamano wrote:\n> \n> * Add -c and --cc to diff-tree and diff-files. They give the\n> \"combined diff\" output that shows merges more human readably.\n\nBtw, the only concern I have left about \"-c\" and \"--cc\" is that I don't \nthink the old merge-diff behaviour makes any sense at all, and that we \nshould drop it entirely in favour of \"-c\" and \"--cc\".\n\nThe old merge-diff code was so useless that nobody ever used it. It was \ndisabled by default (you had to enable it specially with the \"-m\" flag), \nand I don't think anybody really ever did. The output was just not usable.\n\nThe only reason it existed at all was really because I _didn't_ do it \nright, and I wanted some output.\n\nSo I would actually much prefer that \"-c\" would be the default, and that \n\"-p\" would imply \"--cc\". With some other option to have the \"long format\" \ndiff.\n\nHas anybody on the git list ever used \"-m\" with git-diff-tree? Speak up..\n\n\t\tLinus\n"},{"id":"15633","messageId":"7vbqxk8lvg.fsf@assigned-by-dhcp.cox.net","threadId":"3247","inReplyTo":"Pine.LNX.4.64.0602060754470.3854@g5.osdl.org","subject":"Re: What's new in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-06T16:58:43Z","receivedAt":"2006-02-06T16:58:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 5 Feb 2006, Junio C Hamano wrote:\n>> \n>> * Add -c and --cc to diff-tree and diff-files. They give the\n>> \"combined diff\" output that shows merges more human readably.\n>\n> Btw, the only concern I have left about \"-c\" and \"--cc\" is that I don't \n> think the old merge-diff behaviour makes any sense at all, and that we \n> should drop it entirely in favour of \"-c\" and \"--cc\".\n> ...\n> Has anybody on the git list ever used \"-m\" with git-diff-tree? Speak up..\n\nOne thing that makes me a bit reluctant is that I am not as\nconfident as you are about -c doing the right thing. I have not\nexamined differences between -m -p and -c, especially under\nvarious combinations of other flags like -B, -C and -M. I did\ncompare output from -c and --cc to check if the logic to drop\n\"uninteresting\" hunks are doing the right thing and I am\nreasonably sure that part is good, though.\n\nThe code to do -c punts at showing type changes, and there is no\nfilemode information in the output either. So far nobody has\ncomplained about it, and a type change would be a rare thing\nanyway and might not matter in practice. We should however not\njust silently ignore rare cases that we do not handle. Instead\nwe should raise a big red flag; otherwise the rare cases in\nwhich -c cheats can go unnoticed, which feels wrong.\n\nHaving said that, the above concern is primarily about debugging\nthe -c implementation and for that we could always fall back on\nrunning \"diff-tree -p H H^2\" by hand, so maybe dropping \"-m -p\"\nis an OK thing to do from that point of view.\n\nPeople who are doing SCM migration part might be using it as a\nreplacement for \"for i; do diff-tree -p H H^$i; done\" to extract\ndiffs from each parent with a single command, though...\n"},{"id":"15634","messageId":"Pine.LNX.4.63.0602061808120.23350@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3247","inReplyTo":"Pine.LNX.4.64.0602060754470.3854@g5.osdl.org","subject":"Re: What's new in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-02-06T17:10:50Z","receivedAt":"2006-02-06T17:10:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 6 Feb 2006, Linus Torvalds wrote:\n\n> Has anybody on the git list ever used \"-m\" with git-diff-tree? Speak up..\n\nI have. When I tried to pickaxe some ugly bug across several merges. I \nguess \"--cc\" is more effective anyway, so I wouldn't mind to let \"-m\" go.\n\nCiao,\nDscho\n"},{"id":"15664","messageId":"7vek2fzhn9.fsf@assigned-by-dhcp.cox.net","threadId":"3247","inReplyTo":"7vbqxkapr2.fsf@assigned-by-dhcp.cox.net","subject":"Heads up, git.git approaches 1.2.0","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-02-07T08:40:10Z","receivedAt":"2006-02-07T08:40:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've done a bit more work to round the corners diff-tree -c/--cc\nhad. Most notably, earlier the algorithm punted if the merge\nremoved or added files. These should raise red flag, because\ndiff-tree -c/--cc deal with case where the result is different\nfrom all parents, so removal of a file means all parents had it\nin some shape but the file does not appear in the result, and\naddition of a file means no parents had it but merge made it\nmagically appear. These cases are now shown as interesting.\n\nBTW, I was pleasantly surprised that \"git show 2950411\" showed\nexactly what the commit log message said. Now I agree with\nLinus that --cc is a wonderful thing ;-).\n\nTonight I have pushed out all I said I would want to have in the\nnext feature release 1.2.0 in the master branch, so that people\ncan beat it more easily and help us shaking out potential bugs.\nMost of the things are something I've been using myself on git\nitself and also during my day-job, so there hopefully won't be\nany major data eating problems. Admittedly I almost never do\n\"git commit paths...\", but for the last couple of days I tried\nto use it whenever possible to make sure it works as intended.\nIt defaults to --include behaviour which is the traditional one.\n\n\"git commit --only paths...\" and running \"git commit\" from a\nsubdirectory are also implemented and I've tried them with toy\ncommits. If you are one of the people who missed them, please\ntry it out and see if they satisfy your expectations.\n\nI might receive some more HTTP fixes from Mark, documentation\nupdates from J. Bruce etc. and I'd merge them before 1.2.0. But\notherwise I am pretty happy with what's there in the \"master\"\nbranch right now. The tip of the \"master\" is this commit:\n\n commit 5a798fb57f788692467b1a11416dd5ebff0d31ae\n Author: Junio C Hamano \n\n git-commit: finishing touches.\n\nPlease consider it a 1.2.0-rc1, and treat it the same way you\nwould treat -rc1 from the kernel project. If you are going to\ntest only one -rc version, this is THE one to test, and all the\nrest are bugfixes.\n"}]}