Junio C Hamano wrote: > Jakub Narebski <jnareb@xxxxxxxxx> writes: >> Junio C Hamano <gitster@xxxxxxxxx> writes: >>> [Stalled and may need help and prodding to go forward] >>> >>> * jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits >>> + blame: show "previous" information in --porcelain/--incremental >>> format >>> + git-blame: refactor code to emit "porcelain format" output >>> >> It would be nice to have for gitweb... especially if it is a merge >> commit that gets the blame (which I guess should happen only for 'evil >> merge' case). > > Will then move to "perhaps 'master' after 1.6.2" list, but the line number > logic needs to be revisited, especially taking into account what was said > in a recent discussion thread. Well, even without 'line number logic', i.e. having line number for version of given line _before_ current version (which might be not solvable anyway, only approximated), having parents from git-blame, without need to run at least 'git cat-file --batch', would be nice enhancement. If merge is blamed, then we can offer user more than one parent to choose from to go to... >>> * db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits >>> - Support fetching from foreign VCSes >>> - Add specification of git-vcs helpers >>> - Add "vcs" config option in remotes >>> >>> The "spec" did not seem quite well cooked yet, but in the longer term I >>> think something like this to allow interoperating with other SCMs as if >>> the other end is a native git repository is a very worthy goal. >> >> I wonder what are the limitations: I guess that importer has to be >> incremental (and probably store additional info, or at least cache >> it). IIRC the example was for Perforce; much more interesting would >> be to have example for Subversion, I guess. > > We have a working git-svn. As a demonstration, a one that works with git > would be more interesting. Hmmm... I wonder then how hard would be to reuse git-svn (which is not fast-import importer) for foreign-scm feature... >>> * cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits >>> - builtin-replace: use "usage_msg_opt" to give better error messages >>> - parse-options: add new function "usage_msg_opt" >>> - builtin-replace: teach "git replace" to actually replace >>> - Add new "git replace" command >>> - environment: add global variable to disable replacement >>> - mktag: call "check_sha1_signature" with the replacement sha1 >>> - replace_object: add a test case >>> - object: call "check_sha1_signature" with the replacement sha1 >>> - sha1_file: add a "read_sha1_file_repl" function >>> - replace_object: add mechanism to replace objects found in >>> "refs/replace/" >>> - refs: add a "for_each_replace_ref" function >>> >>> I think the code is much cleaner than the first round, but I am not >>> convinced it is doing the right thing in the connectivity traverser. >>> Independent review sorely needed. >> >> This is certainly something that it would be nice to have. > > "Nice to have" we probably all know (otherwise it would not have been > queued). Independent review is sorely needed. Perhaps I would take a look, then... Not that I know anything about this area of code ;-) -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
