{"thread":{"id":"6076","subject":"What's cooking in git.git (topics)","startedAt":"2006-12-22T09:37:50Z","lastAt":"2006-12-23T16:38:45Z","messageCount":6,"participants":["Junio C Hamano","Andy Parkins","Johannes Schindelin","Josef Weidendorfer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"30037","messageId":"7vzm9g2rv5.fsf@assigned-by-dhcp.cox.net","threadId":"6076","inReplyTo":null,"subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T09:37:50Z","receivedAt":"2006-12-22T09:37:50Z","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* jc/rm (Fri Dec 22 01:02:59 2006 -0800) 2 commits\n - t3600: update the test for updated git rm\n - git-rm: update to saner semantics\n\nThis still needs 'require -r to descend into directories'\nsafety. I'd really want to have this in v1.5.0.\n\n* jc/fsck-reflog (Fri Dec 22 00:46:33 2006 -0800) 8 commits\n + reflog expire: prune commits that are not incomplete\n + Don't crash during repack of a reflog with pruned commits.\n + git reflog expire\n + Move in_merge_bases() to commit.c\n + reflog: fix warning message.\n + Teach git-repack to preserve objects referred to by reflog\n entries.\n + Protect commits recorded in reflog from pruning.\n + add for_each_reflog_ent() iterator\n\nThe latest 'reflog expire' hopefully should revive Shawn's\nrepository and make prune or repack working again for him.\n\nTip for 'next' users. fsck and prune consider commits that are\nreferenced by reflog entries reachable, but your repositories\nmay have been pruned by earlier 'prune' already, which may cause\nrepack to barf and refuse. Please use 'reflog expire --all' to\nprune out reflog entries that refer to commits that are already\nlost if repack fails in your repository and try again.\n\nBecause we have made the reflog enabled by default, I really\nwould want to have this in v1.5.0 to prevent unbounded growth of\nreflog files.\n\nI think none of the rest are 'must have's for v1.5.0. Perhaps\nexcept for js/rerere series.\n\n* js/rerere (Wed Dec 20 17:39:41 2006 +0100) 3 commits\n + Make git-rerere a builtin\n + Add a test for git-rerere\n + move read_mmfile() into xdiff-interface\n* jc/skip-count (Tue Dec 19 18:25:32 2006 -0800) 1 commit\n + revision: --skip=\n* jn/web (Sat Dec 16 17:12:55 2006 +0100) 1 commit\n - gitweb: Add some mod_perl specific support\n* jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits\n + git-add --interactive: hunk splitting\n + git-add --interactive\n* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit\n - git-explain\n* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit\n + git-merge: preserve and merge local changes when doing fast\n forward\n* js/shallow (Fri Nov 24 16:00:13 2006 +0100) 15 commits\n + fetch-pack: Do not fetch tags for shallow clones.\n + get_shallow_commits: Avoid memory leak if a commit has been\n reached already.\n + git-fetch: Reset shallow_depth before auto-following tags.\n + upload-pack: Check for NOT_SHALLOW flag before sending a shallow\n to the client.\n + fetch-pack: Properly remove the shallow file when it becomes\n empty.\n + shallow clone: unparse and reparse an unshallowed commit\n + Why didn't we mark want_obj as ~UNINTERESTING in the old code?\n + Why does it mean we do not have to register shallow if we have\n one?\n + We should make sure that the protocol is still extensible.\n + add tests for shallow stuff\n + Shallow clone: do not ignore shallowness when following tags\n + allow deepening of a shallow repository\n + allow cloning a repository \"shallowly\"\n + support fetching into a shallow repository\n + upload-pack: no longer call rev-list\n* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit\n - gitweb: steal loadavg throttle from kernel.org\n* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit\n - blame: --show-stats for easier optimization work.\n* jc/diff (Mon Sep 25 23:03:34 2006 -0700) 1 commit\n - para-walk: walk n trees, index and working tree in parallel\n* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit\n + git-diff/git-apply: make diff output a bit friendlier to GNU patch\n (part 2)\n"},{"id":"30043","messageId":"200612221111.58071.andyparkins@gmail.com","threadId":"6076","inReplyTo":"7vzm9g2rv5.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-22T11:11:56Z","receivedAt":"2006-12-22T11:11:56Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2006 December 22 09:37, Junio C Hamano wrote:\n\n> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits\n> + git-add --interactive: hunk splitting\n> + git-add --interactive\n\nI used this to disentangle a load of changes that I made under pressure and \nturned them into lovely isolated commits. I didn't have any trouble with it, \nand thought it was incredibly useful.\n\nI'd vote for putting it in 1.5 - it's in keeping with the usability theme - \npeople love interactive stuff.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"30129","messageId":"7vlkkzv6rq.fsf@assigned-by-dhcp.cox.net","threadId":"6076","inReplyTo":"200612221111.58071.andyparkins@gmail.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-22T23:40:41Z","receivedAt":"2006-12-22T23:40:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Friday 2006 December 22 09:37, Junio C Hamano wrote:\n>\n>> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits\n>> + git-add --interactive: hunk splitting\n>> + git-add --interactive\n>\n> I used this to disentangle a load of changes that I made under pressure and \n> turned them into lovely isolated commits. I didn't have any trouble with it, \n> and thought it was incredibly useful.\n>\n> I'd vote for putting it in 1.5 - it's in keeping with the usability theme - \n> people love interactive stuff.\n\nSeconds? Thirds? Vetoes?\n"},{"id":"30131","messageId":"Pine.LNX.4.63.0612230052220.19693@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6076","inReplyTo":"7vlkkzv6rq.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-22T23:53:00Z","receivedAt":"2006-12-22T23:53:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 22 Dec 2006, Junio C Hamano wrote:\n\n> Andy Parkins writes:\n> \n> > On Friday 2006 December 22 09:37, Junio C Hamano wrote:\n> >\n> >> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits\n> >> + git-add --interactive: hunk splitting\n> >> + git-add --interactive\n> >\n> > I used this to disentangle a load of changes that I made under pressure and \n> > turned them into lovely isolated commits. I didn't have any trouble with it, \n> > and thought it was incredibly useful.\n> >\n> > I'd vote for putting it in 1.5 - it's in keeping with the usability theme - \n> > people love interactive stuff.\n> \n> Seconds? Thirds? Vetoes?\n\nObviously, I like git-hunk-commit better ;-)\n\nSeriously again, I will play with it in the next days.\n\nCiao,\nDscho\n"},{"id":"30133","messageId":"200612230112.24212.Josef.Weidendorfer@gmx.de","threadId":"6076","inReplyTo":"7vlkkzv6rq.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-12-23T00:12:24Z","receivedAt":"2006-12-23T00:12:24Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Saturday 23 December 2006 00:40, you wrote:\n> Andy Parkins writes:\n> \n> > On Friday 2006 December 22 09:37, Junio C Hamano wrote:\n> >\n> >> * jc/git-add--interactive (Mon Dec 11 17:09:26 2006 -0800) 2 commits\n> >> + git-add --interactive: hunk splitting\n> >> + git-add --interactive\n> >\n> > I used this to disentangle a load of changes that I made under pressure and \n> > turned them into lovely isolated commits. I didn't have any trouble with it, \n> > and thought it was incredibly useful.\n> >\n> > I'd vote for putting it in 1.5 - it's in keeping with the usability theme - \n> > people love interactive stuff.\n> \n> Seconds? Thirds? Vetoes?\n\nSeconds. I like it.\n\nAndy: Did you check whether your disentangled commits each actually did compile\non their own? If yes, how did you do it?\n\nJosef\n"},{"id":"30207","messageId":"200612231638.50045.andyparkins@gmail.com","threadId":"6076","inReplyTo":"200612230112.24212.Josef.Weidendorfer@gmx.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-23T16:38:45Z","receivedAt":"2006-12-23T16:38:45Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2006, December 23 00:12, Josef Weidendorfer wrote:\n\n> Andy: Did you check whether your disentangled commits each actually did\n> compile on their own? If yes, how did you do it?\n\nI didn't; they were easily separable and independent fortunately. I don't \nhave a good way of doing what you ask other than making the commits then \ntesting each of those individually; then again there have been plenty of \nocassions when a git guru tells me some magic that suddenly does exactly what \nI want.\n\nIn the case of testing my split commits I suppose it would need some way of \npushing the working directory into a kind of alternate index temporarily.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"}]}