Re: What's cooking in git.git (Feb 2009, #05; Mon, 16)

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 17, 2009, 23:29 UTC
Message-ID: <200902180029.29344.jnareb@gmail.com>
In-Reply-To: <7v1vtw6h84.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes: 
>> Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

>>> [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...

Show 16 quoted lines

>>> * 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...

Show 22 quoted lines

>>> * 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