Re: Hacking on PostgreSQL via GIT

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Hacking on PostgreSQL via GIT
Дата
Msg-id 20070419004100.GB72669@nasby.net
обсуждение исходный текст
Ответ на Hacking on PostgreSQL via GIT  (Martin Langhoff <martin@catalyst.net.nz>)
Ответы Re: Hacking on PostgreSQL via GIT  (Markus Schiltknecht <markus@bluegap.ch>)
Re: Hacking on PostgreSQL via GIT  (Martin Langhoff <martin@catalyst.net.nz>)
Список pgsql-hackers
On Thu, Apr 19, 2007 at 10:07:08AM +1200, Martin Langhoff wrote:
> Jim C. Nasby wrote:
> > Then how do you tell what version a file is if it's outside of a
> > checkout?
> 
> It's trivial for git to answer that - the file will either be pristine,
> and then we can just scan for the matching SHA1, or modified, and we can
> scan (taking a weee bit more time) which are the "closest matches" in
> your history, in what branches and commits.
> 
> The actual scripting for this isn't written just yet -- Linus posted a
> proof-of-concept shell implementation along the lines of
> 
>      git rev-list --no-merges --full-history v0.5..v0.7 --
> src/widget/widget.c > rev-list
> 
>        best_commit=none
>        best=1000000
>        while read commit
>        do
>                git cat-file blob "$commit:src/widget/widget.c" > tmpfile
>                lines=$(diff reference-file tmpfile | wc -l)
>                if [ "$lines" -lt "$best" ]
>                then
>                        echo Best so far: $commit $lines
>                        best=$lines
>                fi
>        done < rev-list
> 
> and it's fast. One of the good properties of this is that you can ask
> for a range of your history (v0.5 to v0.7 in the example) and an exact
> path (src/widget/widget.c) but you can also say --all (meaning "in all
> branches") and a handwavy "over there", like src. And git will take an
> extra second or two on a large repo, but tell you about all the good
> candidates across the branches.
> 
> Metadata is metadata, and we can fish it out of the SCM easily - and
> data is data, and it's silly to pollute it with metadata that is mostly
> incidental.
> 
> If I find time today I'll post to the git list a cleaned up version of
> Linus' shell script as
> 
>     git-findclosestmatch <head or range or --all> path/to/scan/ \
>                         randomfile.c

Not bad... took you 40 lines to answer my question. Let's see if I can
beat that...

> > Then how do you tell what version a file is if it's outside of a
> > checkout?

Answer: you look at the $Id$ (or in this case, $PostgreSQL$) tag.

Sorry, tried to get it to 2 lines, but couldn't. ;)

I understand the argument about metadata and all, and largely agree with
it. But on the other hand I think a version identifier is a critical
piece of information; it's just as critical as the file name when it
comes to identifying the information contained in the file.

Or does GIT not use filenames, either? :)
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: modifying the table function
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Background LRU Writer/free list