{"thread":{"id":"15599","subject":"What's cooking in git.git (Sep 2008, #03; Fri, 19)","startedAt":"2008-09-19T20:52:35Z","lastAt":"2008-09-19T23:43:13Z","messageCount":5,"participants":["Junio C Hamano","Thomas Rast","Santi Béjar","david@lang.hm"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"91145","messageId":"7vprmzrh7w.fsf@gitster.siamese.dyndns.org","threadId":"15599","inReplyTo":null,"subject":"What's cooking in git.git (Sep 2008, #03; Fri, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-19T20:52:35Z","receivedAt":"2008-09-19T20:52:35Z","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'.\n\nThe topics list the commits in reverse chronological order.  The topics\nmeant to be merged to the maintenance series have \"maint-\" in their names.\n\nBy the way, I'll be on vacation from Sep 24 til Oct 08, but e-mail based\nproposal/review/discussion/improvement cycle and the distributed nature of\ngit mean that it shouldn't keep the participants from further working on\nthe system.  Hopefully when I come back I'll see a much improved git ;-).\n\n----------------------------------------------------------------\n[New Topics]\n\n* mg/maint-remote-fix (Thu Sep 18 18:11:02 2008 +0200) 1 commit\n - make \"git remote\" report multiple URLs\n\nStill with a minor nit but I think this is an improvement.\n\n* pb/submodule (Fri Sep 12 23:09:19 2008 +0200) 1 commit\n - t7400: Add short \"git submodule add\" testsuite\n\nWaiting for a reroll.\n\n* tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits\n + Documentation: Refer to git-rebase(1) to warn against rewriting\n + Documentation: new upstream rebase recovery section in git-rebase\n\nI think the last one on \"recommended practice\" needs discussion.  I do not\nthink it describes _the_ recommended workflow, although I think (1) what\nis recommended in the draft does make sense within its own scope, and (2)\nit may be impossible to come up with _the_ recommended workflow anyway.\n\n* bc/maint-diff-hunk-header-fix (Thu Sep 18 17:44:33 2008 -0500) 3 commits\n + diff.*.xfuncname which uses \"extended\" regex's for hunk header\n   selection\n + diff.c: associate a flag with each pattern and use it for\n   compiling regex\n + diff.c: return pattern entry pointer rather than just the hunk\n   header pattern\n\n* bc/master-diff-hunk-header-fix (Thu Sep 18 20:32:50 2008 -0700) 4 commits\n + Merge branch 'bc/maint-diff-hunk-header-fix' into bc/master-diff-\n   hunk-header-fix\n + diff.*.xfuncname which uses \"extended\" regex's for hunk header\n   selection\n + diff.c: associate a flag with each pattern and use it for\n   compiling regex\n + diff.c: return pattern entry pointer rather than just the hunk\n   header pattern\n\nI've commented on these two branches in a separate message.\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\n* mh/maint-honor-no-ssl-verify (Thu Feb 21 15:10:37 2008 -0800) 1 commit\n + Don't verify host name in SSL certs when GIT_SSL_NO_VERIFY is set\n\n* dp/maint-rebase-fix (Tue Sep 9 16:05:26 2008 +0400) 2 commits\n + git-rebase--interactive: auto amend only edited commit\n + git-rebase-interactive: do not squash commits on abort\n\n* jc/maint-checkout-keep-remove (Sun Sep 7 19:49:25 2008 -0700) 1 commit\n + checkout: do not lose staged removal\n\n* jc/maint-template-permbits (Thu Aug 21 19:31:50 2008 -0500) 1 commit\n + Fix permission bits on sources checked out with an overtight umask\n\n* np/pack (Tue Sep 2 10:22:22 2008 -0400) 4 commits\n + t5300: improve SHA1 collision test\n + pack-objects: don't include missing preferred base objects\n + sha1write: don't copy full sized buffers\n + Merge branch 'np/maint-safer-pack' into np/pack\n\n* bw/shortref (Fri Sep 5 23:16:23 2008 +0200) 1 commit\n + for-each-ref: `:short` format for `refname`\n\n* rs/decorate (Thu Sep 4 23:40:03 2008 +0200) 3 commits\n + add '%d' pretty format specifier to show decoration\n + move load_ref_decorations() to log-tree.c and export it\n + log: add load_ref_decorations()\n\n* tr/rev-list-reverse (Mon Sep 1 00:31:37 2008 +0200) 2 commits\n + t6013: replace use of 'tac' with equivalent Perl\n + rev-list: fix --reverse interaction with --parents\n\n* cc/bisect (Sat Sep 6 07:27:03 2008 +0200) 3 commits\n + bisect: remove \"checkout_done\" variable used when checking merge\n   bases\n + bisect: only check merge bases when needed\n + bisect: test merge base if good rev is not an ancestor of bad rev\n\n* jc/setlinebuf-setvbuf (Wed Sep 3 20:33:29 2008 -0700) 1 commit\n + daemon.c: avoid setlinebuf()\n\n* jc/maint-diff-quiet (Mon Sep 1 23:20:26 2008 -0700) 2 commits\n + diff --quiet: make it synonym to --exit-code >/dev/null\n + diff Porcelain: do not disable auto index refreshing on -C -C\n\n* jc/maint-name-hash-clear (Sat Aug 23 13:05:10 2008 -0700) 1 commit\n + discard_cache: reset lazy name_hash bit\n\n* jc/diff-prefix (Mon Aug 18 20:08:09 2008 -0700) 1 commit\n + diff: vary default prefix depending on what are compared\n\n----------------------------------------------------------------\n[Stalled -- Needs Action to Proceed (or to be dropped)]\n\n* bd/blame (Thu Aug 21 18:22:01 2008 -0500) 5 commits\n - Use xdiff caching to improve git blame performance\n - Allow xdiff machinery to cache hash results for a file\n - Always initialize xpparam_t to 0\n - Bypass textual patch generation and parsing in git blame\n - Allow alternate \"low-level\" emit function from xdl_diff\n\nRéne had good comments on how the callback should be structured.\n\n* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit\n - git-am: Pass the --directory option through to git-apply\n\nI think this is still buggy and drops the option when am stops with\nconflicts.\n\n----------------------------------------------------------------\n[Will be merged to \"master\" soon]\n\n* mv/merge-recursive (Sat Sep 6 18:29:49 2008 +0200) 11 commits\n + builtin-merge: release the lockfile in try_merge_strategy()\n + merge-recursive: get rid of virtual_id\n + merge-recursive: move current_{file,directory}_set to struct\n   merge_options\n + merge-recursive: move the global obuf to struct merge_options\n + merge-recursive: get rid of the index_only global variable\n + merge-recursive: move call_depth to struct merge_options\n + cherry-pick/revert: make direct internal call to merge_tree()\n + builtin-merge: avoid run_command_v_opt() for recursive and subtree\n + merge-recursive: introduce merge_options\n + merge-recursive.c: Add more generic merge_recursive_generic()\n + Split out merge_recursive() to merge-recursive.c\n\n* ho/dirstat-by-file (Fri Sep 5 22:27:35 2008 +0300) 1 commit\n + diff --dirstat-by-file: count changed files, not lines\n\n* jc/safe-c-l-d (Tue Sep 2 14:10:15 2008 -0700) 1 commit\n + safe_create_leading_directories(): make it about \"leading\"\n   directories\n\n* jc/apply-include-exclude (Mon Aug 25 01:05:31 2008 -0700) 1 commit\n + git-apply:--include=pathspec\n\n* mv/commit-tree (Wed Sep 10 22:10:33 2008 +0200) 3 commits\n + t7603: add new testcases to ensure builtin-commit uses\n   reduce_heads()\n + builtin-commit: use commit_tree()\n + commit_tree(): add a new author parameter\n\n* pb/autocorrect-wrapper (Wed Sep 10 17:54:28 2008 +0200) 1 commit\n + git wrapper: also use aliases to correct mistyped commands\n\n* pb/commit-where (Mon Sep 8 01:05:41 2008 +0200) 1 commit\n + builtin-commit.c: show on which branch a commit was added\n\n* jc/better-conflict-resolution (Thu Sep 4 23:48:48 2008 +0200) 15 commits\n + Fix AsciiDoc errors in merge documentation\n + git-merge documentation: describe how conflict is presented\n + checkout --conflict=<style>: recreate merge in a non-default style\n + checkout -m: recreate merge when checking out of unmerged index\n + Merge branch 'jc/maint-checkout-fix' into 'jc/better-conflict-\n   resolution'\n + git-merge-recursive: learn to honor merge.conflictstyle\n + merge.conflictstyle: choose between \"merge\" and \"diff3 -m\" styles\n + rerere: understand \"diff3 -m\" style conflicts with the original\n + rerere.c: use symbolic constants to keep track of parsing states\n + xmerge.c: \"diff3 -m\" style clips merge reduction level to EAGER or\n   less\n + xmerge.c: minimum readability fixups\n + xdiff-merge: optionally show conflicts in \"diff3 -m\" style\n + xdl_fill_merge_buffer(): separate out a too deeply nested function\n + checkout --ours/--theirs: allow checking out one side of a\n   conflicting merge\n + checkout -f: allow ignoring unmerged paths when checking out of\n   the index\n\n* jc/alternate-push (Tue Sep 9 01:27:10 2008 -0700) 4 commits\n + push: receiver end advertises refs from alternate repositories\n + push: prepare sender to receive extended ref information from the\n   receiver\n + receive-pack: make it a builtin\n + is_directory(): a generic helper function\n\n----------------------------------------------------------------\n[Actively Cooking]\n\n* am/status (Mon Sep 8 00:05:03 2008 +0200) 2 commits\n + wt-status: Teach how to discard changes in the working directory\n + wt-status: Split header generation into three functions\n\n* lt/time-reject-fractional-seconds (Sat Aug 16 21:25:40 2008 -0700) 1 commit\n + date/time: do not get confused by fractional seconds\n\n* jc/add-ita (Thu Aug 21 01:44:53 2008 -0700) 1 commit\n + git-add --intent-to-add (-N)\n\nTeaches \"git add\" to record only the intent to add a path later.\nI rerolled this without the fake empty blob object.\n\n* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits\n - revision --simplify-merges: incremental simplification\n - revision --simplify-merges: prepare for incremental simplification\n\nI started making this incremental but the progress is not so great.\n\n----------------------------------------------------------------\n[On Hold]\n\n* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits\n - git-am --forge: add Signed-off-by: line for the author\n - git-am: clean-up Signed-off-by: lines\n - stripspace: add --log-clean option to clean up signed-off-by:\n   lines\n - stripspace: use parse_options()\n - Add \"git am -s\" test\n - git-am: refactor code to add signed-off-by line for the committer\n\nThe one at second from the tip needs reworking.\n\n* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit\n - \"git push\": tellme-more protocol extension\n\n* jc/merge-whitespace (Sun Feb 24 23:29:36 2008 -0800) 1 commit\n - WIP: start teaching the --whitespace=fix to merge machinery\n\n* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits\n - blame: show \"previous\" information in --porcelain/--incremental\n   format\n - git-blame: refactor code to emit \"porcelain format\" output\n\n* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit\n + merge: remove deprecated summary and diffstat options and config\n   variables\n\nThis was previously in \"will be in master soon\" category, but it turns out\nthat the synonyms to the ones this one deletes are fairly new invention\nthat happend in 1.5.6 timeframe, and we cannot do this just yet.  Perhaps\nin 1.7.0, but with the loud whining about moving git-foo out of $PATH we\nhave been hearing, it might not be a bad idea to drop this.\n\n* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit\n - diff: enable \"too large a rename\" warning when -M/-C is explicitly\n   asked for\n\nThis would be the right thing to do for command line use, but gitk will be\nhit due to tcl/tk's limitation, so I am holding this back for now.\n"},{"id":"91150","messageId":"200809200020.32285.trast@student.ethz.ch","threadId":"15599","inReplyTo":"7vprmzrh7w.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2008-09-19T22:20:24Z","receivedAt":"2008-09-19T22:20:24Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> * tr/workflow-doc (Sat Sep 13 18:11:01 2008 +0200) 2 commits\n>  + Documentation: Refer to git-rebase(1) to warn against rewriting\n>  + Documentation: new upstream rebase recovery section in git-rebase\n> \n> I think the last one on \"recommended practice\" needs discussion.  I do not\n> think it describes _the_ recommended workflow, although I think (1) what\n> is recommended in the draft does make sense within its own scope, and (2)\n> it may be impossible to come up with _the_ recommended workflow anyway.\n\n[The patch referred to is\n\n  http://article.gmane.org/gmane.comp.version-control.git/95806\n\nand the only response so far, to an earlier version,\n\n  http://article.gmane.org/gmane.comp.version-control.git/95620 ]\n\nI was hoping for more feedback, but maybe the list is not the right\naudience: the intended readers of the document probably aren't as\nactive on the list and confident about patch review.\n\nRegarding _the_ recommended workflow, I can think of a few possible\napproaches:\n\na) Authoritative: either because we really believe it's the One True\n   Workflow, or just because we want to sound so.\n\nb) Descriptive: describe it as the workflow \"we\" use (presumably this\n   includes linux.git which may be worth mentioning; I haven't touched\n   the kernel though).\n\nc) Encyclopedic: describe and classify as many recipes (building\n   blocks) and workflows as possible in an attempt to build a\n   complete reference of sorts.\n\nd) Blind eye: we're just the tool.  Others can devise workflows.\n\nI certainly aimed the patch at (a), since I wanted to be able to point\npeople at it (mostly on #git).  The resources I learned Git with,\nexcept for the videos, just show simple examples of pull/push usage,\nwhich I found both unsatisfactory (e.g. I want to know _why_ it's a\ngood idea to make topic branches) and incomplete.  This list is an\nexcellent place to learn, but I doubt that's an effort the average\nuser is willing to put in.\n\nThat being said, I'm certainly willing to rewrite it in the direction\nof (b), and possibly help with the writeup (though not brainstorming)\nof (c), if either of those is the list consensus.\n\n- Thomas\n\nPS: Anyone else noticed the striking number of \"we have <setup>, what\nis the best workflow and how do I implement it\" mails in the past few\ndays?  Is that just a statistical anomaly, or another need for\ndocumentation?\n\n-- \nThomas Rast\ntrast@student.ethz.ch\n\n"},{"id":"91152","messageId":"7vk5d7pxep.fsf@gitster.siamese.dyndns.org","threadId":"15599","inReplyTo":"200809200020.32285.trast@student.ethz.ch","subject":"Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-19T22:45:50Z","receivedAt":"2008-09-19T22:45:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast <trast@student.ethz.ch> writes:\n\n> Regarding _the_ recommended workflow, I can think of a few possible\n> approaches:\n>\n> a) Authoritative: either because we really believe it's the One True\n>    Workflow, or just because we want to sound so.\n>\n> b) Descriptive: describe it as the workflow \"we\" use (presumably this\n>    includes linux.git which may be worth mentioning; I haven't touched\n>    the kernel though).\n>\n> c) Encyclopedic: describe and classify as many recipes (building\n>    blocks) and workflows as possible in an attempt to build a\n>    complete reference of sorts.\n>\n> d) Blind eye: we're just the tool.  Others can devise workflows.\n>\n> I certainly aimed the patch at (a), since I wanted to be able to point\n> people at it (mostly on #git).  The resources I learned Git with,\n> except for the videos, just show simple examples of pull/push usage,\n> which I found both unsatisfactory (e.g. I want to know _why_ it's a\n> good idea to make topic branches) and incomplete.  This list is an\n> excellent place to learn, but I doubt that's an effort the average\n> user is willing to put in.\n\nI think we should be honest and not try to do (a) nor (c).  And as I\nalready said, as (b) your description looked fine, but it wasn't very\nencouraging that not many people commented on it (nor said \"Yeah, that's\nwhat I was missing, thanks\").\n"},{"id":"91153","messageId":"adf1fd3d0809191557nf46f6bao44eff93381650672@mail.gmail.com","threadId":"15599","inReplyTo":"7vk5d7pxep.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)","fromName":"Santi Béjar","fromEmail":"santi@agolina.net","sentAt":"2008-09-19T22:57:22Z","receivedAt":"2008-09-19T22:57:22Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Sat, Sep 20, 2008 at 12:45 AM, Junio C Hamano <gitster@pobox.com> wrote:\n[...]\n\n> And as I\n> already said, as (b) your description looked fine, but it wasn't very\n> encouraging that not many people commented on it (nor said \"Yeah, that's\n> what I was missing, thanks\").\n\nA bit late, but I think it is a very good addition, thanks. I'll review it.\n\nSanti\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>\n"},{"id":"91155","messageId":"alpine.DEB.1.10.0809191636380.26104@asgard.lang.hm","threadId":"15599","inReplyTo":"7vk5d7pxep.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Sep 2008, #03; Fri, 19)","fromName":"","fromEmail":"david@lang.hm","sentAt":"2008-09-19T23:43:13Z","receivedAt":"2008-09-19T23:43:13Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 19 Sep 2008, Junio C Hamano wrote:\n\n> Thomas Rast <trast@student.ethz.ch> writes:\n>\n>> Regarding _the_ recommended workflow, I can think of a few possible\n>> approaches:\n>>\n>> a) Authoritative: either because we really believe it's the One True\n>>    Workflow, or just because we want to sound so.\n>>\n>> b) Descriptive: describe it as the workflow \"we\" use (presumably this\n>>    includes linux.git which may be worth mentioning; I haven't touched\n>>    the kernel though).\n>>\n>> c) Encyclopedic: describe and classify as many recipes (building\n>>    blocks) and workflows as possible in an attempt to build a\n>>    complete reference of sorts.\n>>\n>> d) Blind eye: we're just the tool.  Others can devise workflows.\n>>\n>> I certainly aimed the patch at (a), since I wanted to be able to point\n>> people at it (mostly on #git).  The resources I learned Git with,\n>> except for the videos, just show simple examples of pull/push usage,\n>> which I found both unsatisfactory (e.g. I want to know _why_ it's a\n>> good idea to make topic branches) and incomplete.  This list is an\n>> excellent place to learn, but I doubt that's an effort the average\n>> user is willing to put in.\n>\n> I think we should be honest and not try to do (a) nor (c).  And as I\n> already said, as (b) your description looked fine, but it wasn't very\n> encouraging that not many people commented on it (nor said \"Yeah, that's\n> what I was missing, thanks\").\n\nthere is no workflow that is right for every situation, so only describing \none (A or B) is very limiting (even if you don't claim that it's the One \nTrue way)\n\nWe've seen that D doesn't work well (people are confused and create \nhorribly bad workflows, decide that git is too confusing and too limited, \nand tell everyone they know)\n\nI think C is best. this doesn't mean that we need to imagine and create \nevery possible workflow, but including the workflows that we are sent (and \ncommenting on advantages/disadvantages of them) would be very helpful for \npeople just getting started with a project. Having a catagory of 'how not \nto use git' with some of the worst examples would be very educational.\n\nIn almost all cases where people have spoken up and described their \nworkflow (and the pains involved with it) the git experts here have been \nable to simplify things for the user (either by pointing out better ways \nto do the same thing, or in some cases by tweaking git to better support \nthe different class of workflow)\n\nDavid Lang\n"}]}