* Re: Author name and e-mail address in .stgitrc
From: Catalin Marinas @ 2006-11-11 23:02 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061111141530.GF11224@diana.vm.bytemark.co.uk>
On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
> Is there any particular reason to have the author and committer names
> in ~/.stgitrc? Simply taking them from the same place git does would
> probably be a usability enhancement (unless they're specified on the
> command line, of course).
At the time I added these to .stgitrc, the only place git was taking
them from was the environment variables and I wanted to put them in a
single place. I also didn't like the idea of having the committer
e-mail address be some username@local-machine as I don't think the
name of the machine where I create patches is relevant. I also define
the committer/author per repository in the .git/stgitrc file (i.e. I
use @arm.com for Linux patches and @gmail.com for StGIT).
I use StGIT almost exclusively, even in "maintainer" mode and I would
like not to spread the configuration options over many files. It is on
my todo list to use the same configuration file as git (with a [stgit]
section) since it has a format that should be understood by the Python
config module.
--
^ permalink raw reply
* [PATCH 0/3] Re: Author name and e-mail address in .stgitrc
From: Karl Hasselström @ 2006-11-11 23:23 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611111502q2f68be67l1a2441d84923a732@mail.gmail.com>
On 2006-11-11 23:02:04 +0000, Catalin Marinas wrote:
> On 11/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > Is there any particular reason to have the author and committer
> > names in ~/.stgitrc? Simply taking them from the same place git
> > does would probably be a usability enhancement (unless they're
> > specified on the command line, of course).
>
> At the time I added these to .stgitrc, the only place git was taking
> them from was the environment variables and I wanted to put them in a
> single place. I also didn't like the idea of having the committer
> e-mail address be some username@local-machine as I don't think the
> name of the machine where I create patches is relevant. I also define
> the committer/author per repository in the .git/stgitrc file (i.e. I
> use @arm.com for Linux patches and @gmail.com for StGIT).
Well, this should all be sorted out now; git has both per-repository
and per-user config files.
> I use StGIT almost exclusively, even in "maintainer" mode and I
> would like not to spread the configuration options over many files.
> It is on my todo list to use the same configuration file as git
> (with a [stgit] section) since it has a format that should be
> understood by the Python config module.
The last patch in this series deprecates name and email config in
stgitrc by not mentioning them in the example stgitrc, because
teaching newbies to use yet another layer of identity configuration on
top of what git already provides is madness. Old-timers may continue
using stgitrc for that purpose for now (but as you say, integrating
the configuration with git is on the TODO list).
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* [PATCH 1/3] Ask git for author and committer name
From: Karl Hasselström @ 2006-11-11 23:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061111232322.17760.26214.stgit@localhost>
From: Karl Hasselström <kha@treskal.com>
Consistently do the following to get hold of default user and
committer:
1. Use the value specified on the command line, if any.
1. Otherwise, use the value from stgitrc, if available.
2. Otherwise, ask git for the value. git will produce the value from
on of its config files, from environment variables, or make it
up. It might be asking the spirits of the dead for all we care.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/mail.py | 19 ++------------
stgit/git.py | 63 ++++++++++++++++++++++++++++++++++++++++++++++++
stgit/stack.py | 32 ++++--------------------
3 files changed, 70 insertions(+), 44 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 154df9c..78abfa4 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -127,17 +127,6 @@ options = [make_option('-a', '--all',
action = 'store_true')]
-def __get_maintainer():
- """Return the 'authname <authemail>' string as read from the
- configuration file
- """
- if config.has_option('stgit', 'authname') \
- and config.has_option('stgit', 'authemail'):
- return '%s <%s>' % (config.get('stgit', 'authname'),
- config.get('stgit', 'authemail'))
- else:
- return None
-
def __parse_addresses(addresses):
"""Return a two elements tuple: (from, [to])
"""
@@ -301,9 +290,7 @@ def edit_message(msg):
def __build_cover(tmpl, total_nr, msg_id, options):
"""Build the cover message (series description) to be sent via SMTP
"""
- maintainer = __get_maintainer()
- if not maintainer:
- maintainer = ''
+ maintainer = git.user()
if options.version:
version_str = ' %s' % options.version
@@ -370,9 +357,7 @@ def __build_message(tmpl, patch, patch_n
short_descr = descr_lines[0].rstrip()
long_descr = '\n'.join(descr_lines[1:]).lstrip()
- maintainer = __get_maintainer()
- if not maintainer:
- maintainer = '%s <%s>' % (p.get_commname(), p.get_commemail())
+ maintainer = git.user()
if options.version:
version_str = ' %s' % options.version
diff --git a/stgit/git.py b/stgit/git.py
index 8d88769..a6e1a63 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -33,6 +33,35 @@ class GitException(Exception):
#
# Classes
#
+
+class Person:
+ """An author, committer, etc."""
+ def __init__(self, name = None, email = None, date = None,
+ desc = None):
+ if name or email or date:
+ assert not desc
+ self.name = name
+ self.email = email
+ self.date = date
+ elif desc:
+ assert not (name or email or date)
+ def parse_desc(s):
+ m = re.match(r'^(.+)<(.+)>(.*)$', s)
+ assert m
+ return [x.strip() or None for x in m.groups()]
+ self.name, self.email, self.date = parse_desc(desc)
+ def set_name(self, val):
+ if val:
+ self.name = val
+ def set_email(self, val):
+ if val:
+ self.email = val
+ def __str__(self):
+ if self.name and self.email:
+ return '%s <%s>' % (self.name, self.email)
+ else:
+ raise Exception, 'not enough identity data'
+
class Commit:
"""Handle the commit objects
"""
@@ -402,6 +431,40 @@ def rm(files, force = False):
if files:
__run('git-update-index --force-remove --', files)
+def var(key):
+ """Ask git-var for the value of a variable."""
+ return _output_one_line(['git-var', key])
+
+def repo_config(key):
+ """Ask git-repo-config for the value of a variable."""
+ return _output_one_line(['git-repo-config', key])
+
+__cached_git_persons = {}
+def __git_person(p):
+ if not p in __cached_git_persons:
+ __cached_git_persons[p] = {
+ 'author': lambda: Person(desc = var('GIT_AUTHOR_IDENT')),
+ 'committer': lambda: Person(desc = var('GIT_COMMITTER_IDENT')),
+ 'user': lambda: Person(repo_config('user.name'),
+ repo_config('user.email')),
+ }[p]()
+ return __cached_git_persons[p]
+
+__cached_stgit_persons = {}
+def __stgit_person(p, name_key, email_key):
+ if not p in __cached_stgit_persons:
+ person = __git_person(p)
+ if config.has_option('stgit', name_key):
+ person.set_name(config.get('stgit', name_key))
+ if config.has_option('stgit', email_key):
+ person.set_email(config.get('stgit', email_key))
+ __cached_stgit_persons[p] = person
+ return __cached_stgit_persons[p]
+
+def author(): return __stgit_person('author', 'authname', 'authemail')
+def committer(): return __stgit_person('committer', 'commname', 'commemail')
+def user(): return __stgit_person('user', 'authname', 'authemail')
+
def update_cache(files = None, force = False):
"""Update the cache information for the given files
"""
diff --git a/stgit/stack.py b/stgit/stack.py
index a477e7d..fee1316 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -238,53 +238,31 @@ class Patch:
return self.__get_field('authname')
def set_authname(self, name):
- if not name:
- if config.has_option('stgit', 'authname'):
- name = config.get('stgit', 'authname')
- elif 'GIT_AUTHOR_NAME' in os.environ:
- name = os.environ['GIT_AUTHOR_NAME']
- self.__set_field('authname', name)
+ self.__set_field('authname', name or git.author().name)
def get_authemail(self):
return self.__get_field('authemail')
def set_authemail(self, address):
- if not address:
- if config.has_option('stgit', 'authemail'):
- address = config.get('stgit', 'authemail')
- elif 'GIT_AUTHOR_EMAIL' in os.environ:
- address = os.environ['GIT_AUTHOR_EMAIL']
- self.__set_field('authemail', address)
+ self.__set_field('authemail', address or git.author().email)
def get_authdate(self):
return self.__get_field('authdate')
def set_authdate(self, date):
- if not date and 'GIT_AUTHOR_DATE' in os.environ:
- date = os.environ['GIT_AUTHOR_DATE']
- self.__set_field('authdate', date)
+ self.__set_field('authdate', date or git.author().date)
def get_commname(self):
return self.__get_field('commname')
def set_commname(self, name):
- if not name:
- if config.has_option('stgit', 'commname'):
- name = config.get('stgit', 'commname')
- elif 'GIT_COMMITTER_NAME' in os.environ:
- name = os.environ['GIT_COMMITTER_NAME']
- self.__set_field('commname', name)
+ self.__set_field('commname', name or git.committer().name)
def get_commemail(self):
return self.__get_field('commemail')
def set_commemail(self, address):
- if not address:
- if config.has_option('stgit', 'commemail'):
- address = config.get('stgit', 'commemail')
- elif 'GIT_COMMITTER_EMAIL' in os.environ:
- address = os.environ['GIT_COMMITTER_EMAIL']
- self.__set_field('commemail', address)
+ self.__set_field('commemail', address or git.committer().email)
def get_log(self):
^ permalink raw reply related
* [PATCH 2/3] Don't mention deprecated template variables
From: Karl Hasselström @ 2006-11-11 23:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061111232322.17760.26214.stgit@localhost>
From: Karl Hasselström <kha@treskal.com>
%(endofheaders)s and %(date)s are deprecated and expand to the empty
string, so don't mention them in the help text.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/mail.py | 13 ++++---------
1 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index 78abfa4..d4fc293 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -52,19 +52,14 @@ SMTP authentication is also possible wit
'--smtp-password' options, also available as configuration settings:
'smtpuser' and 'smtppassword'.
-The template e-mail headers and body must be separated by
-'%(endofheaders)s' variable, which is replaced by StGIT with
-additional headers and a blank line. The patch e-mail template accepts
-the following variables:
+The patch e-mail template accepts the following variables:
%(patch)s - patch name
%(maintainer)s - 'authname <authemail>' as read from the config file
%(shortdescr)s - the first line of the patch description
%(longdescr)s - the rest of the patch description, after the first line
- %(endofheaders)s - delimiter between e-mail headers and body
%(diff)s - unified diff of the patch
%(diffstat)s - diff statistics
- %(date)s - current date/time
%(version)s - ' version' string passed on the command line (or empty)
%(prefix)s - 'prefix ' string passed on the command line
%(patchnr)s - patch number
@@ -76,9 +71,9 @@ the following variables:
%(commname)s - committer's name
%(commemail)s - committer's e-mail
-For the preamble e-mail template, only the %(maintainer)s, %(date)s,
-%(endofheaders)s, %(version)s, %(patchnr)s, %(totalnr)s and %(number)s
-variables are supported."""
+For the preamble e-mail template, only the %(maintainer)s,
+%(version)s, %(patchnr)s, %(totalnr)s and %(number)s variables are
+supported."""
options = [make_option('-a', '--all',
^ permalink raw reply related
* [PATCH 3/3] Deprecate author and committer details in stgitrc
From: Karl Hasselström @ 2006-11-11 23:31 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061111232322.17760.26214.stgit@localhost>
From: Karl Hasselström <kha@treskal.com>
There are two distinct disadvantages to having author and committer
names in stgitrc:
* They override GIT_AUTHOR_NAME and friends, not the other way
around as one might imagine.
* They cause stgit and plain git to use different names (unless one
manages to keep them in sync manually), which can't possibly be a
good idea.
This patch removes the description of these variables in the example
stgitrc, so that new users aren't tempted to use them. They will still
continue to function, however.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
examples/stgitrc | 5 -----
stgit/git.py | 3 +++
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/examples/stgitrc b/examples/stgitrc
index 45a629b..9cd95e1 100644
--- a/examples/stgitrc
+++ b/examples/stgitrc
@@ -3,11 +3,6 @@
# the former.
[stgit]
-# Default author/committer details
-#authname: Your Name
-#authemail: your.name@yourcompany.com
-#commname: Your Name
-#commemail: your.name@yourcompany.com
# Automatically Bcc the address below
#autobcc: your.name@yourcompany.com
diff --git a/stgit/git.py b/stgit/git.py
index a6e1a63..f654cde 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -452,6 +452,9 @@ def __git_person(p):
__cached_stgit_persons = {}
def __stgit_person(p, name_key, email_key):
+ """Calls __git_person to get the details for a person, but allows
+ the deprecated author and committer variables in stgitrc override
+ the result."""
if not p in __cached_stgit_persons:
person = __git_person(p)
^ permalink raw reply related
* Re: [PATCH 1/3] Ask git for author and committer name
From: Karl Hasselström @ 2006-11-11 23:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061111233046.17760.62871.stgit@localhost>
On 2006-11-12 00:30:46 +0100, Karl Hasselström wrote:
> 1. Use the value specified on the command line, if any.
>
> 1. Otherwise, use the value from stgitrc, if available.
>
> 2. Otherwise, ask git for the value. git will produce the value
> from on of its config files, from environment variables, or
> make it up. It might be asking the spirits of the dead for all
> we care.
Oops. Feel free to renumber these points as you see fit. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Author name and e-mail address in .stgitrc
From: Karl Hasselström @ 2006-11-12 0:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611111502q2f68be67l1a2441d84923a732@mail.gmail.com>
On 2006-11-11 23:02:04 +0000, Catalin Marinas wrote:
> I use StGIT almost exclusively, even in "maintainer" mode
It used to be the case that I did almost all my comitting with stgit
(while still using other git tools, such as gitk, reset, bisect, fetch
etc.). But then I discovered the extremely handy git emacs modes, and
started using them to commit stuff. Thus the need for "stg
assimilate". :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: information for a 60-minute "intro to git" needed
From: Ryan Anderson @ 2006-11-12 4:51 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Randal L. Schwartz, jnareb, git
In-Reply-To: <46a038f90611111449g63ab5b41p8dc669beea864e51@mail.gmail.com>
On 11/11/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 11/11/06, Junio C Hamano <junkio@cox.net> wrote:
> > I think Martin Langhoff promised to make his presentation done
> > in Mexico available to us sometime ago, but I wonder what
> > happened to it...
>
> Hola! You are right, I never published anything... The Mexico
> presentation was a combination of your original slides (I ended up
> using the PDF directly as I didn't have OOv2) plus a version of my
> older talk notes, updated and in Spanish. So I swapped the two
> around.... "live".
>
> The old, outdated talk is based on Cogito, and can be found here. I
> still use it for my inhouse team --
> http://wellington.pm.org/archive/200510/git/
I gave this talk at Ubucon:
http://h4x0r5.com/~ryan/presentations/git-why.pdf
(I modeled this one after Junio's OLS talk, as I thought it was more
interesting to give a 'why' talk, rather than a 'magic incantation'
talk.)
Back in April, I used these to give a talk at Penguicon:
http://h4x0r5.com/~ryan/presentations/git-tutorial.pdf
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.3.5
From: Junio C Hamano @ 2006-11-12 5:23 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.3.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.3.5.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.3.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.3.5.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.3.5-1.$arch.rpm (RPM)
The 'master' front has been very quiet and it will hopefully
soon produce 1.4.4 but in the meantime here is primarily to fix
git-svn correctness issues.
----------------------------------------------------------------
Changes since v1.4.3.4 are as follows:
Alex Riesen (1):
merge-recursive implicitely depends on trust_executable_bit
Eric Wong (3):
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
git-svn: fix dcommit losing changes when out-of-date from svn
Jakub Narebski (1):
Documentation: Transplanting branch with git-rebase --onto
Jeff King (1):
Fix git-runstatus for repositories containing a file named HEAD
Junio C Hamano (3):
adjust_shared_perm: chmod() only when needed.
path-list: fix path-list-insert return value
git-cvsserver: read from git with -z to get non-ASCII pathnames.
Petr Baudis (1):
Nicer error messages in case saving an object to db goes wrong
Robert Shearman (1):
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
Tero Roponen (1):
remove an unneeded test
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-11-12 6:07 UTC (permalink / raw)
To: git
Execuive summary.
I've tagged the tip of 'master' as v1.4.4-rc2 tonight. In the
meantime, GIT 1.4.3.5 was cut from the 'maint' branch.
We hopefully can declare the real 1.4.4 soon enough, before the
turkey time.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Eric Wong (3):
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
git-svn: fix dcommit losing changes when out-of-date from svn
Junio C Hamano (2):
path-list: fix path-list-insert return value
git-cvsserver: read from git with -z to get non-ASCII pathnames.
Petr Baudis (1):
Nicer error messages in case saving an object to db goes wrong
Robert Shearman (1):
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
* The 'master' branch has these since the last announcement.
Eric Wong (3):
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
git-svn: fix dcommit losing changes when out-of-date from svn
Jakub Narebski (3):
gitweb: Better git-unquoting and gitweb-quoting of pathnames
gitweb: Use character or octal escape codes (and add span.cntrl) in esc_path
gitweb: New improved patchset view
Junio C Hamano (14):
gitweb: fix disabling of "forks"
gitweb: minimally fix "fork" support.
gitweb: do not give blame link unconditionally in diff-tree view
git-status: quote LF in its output
git-pickaxe: retire pickaxe
gitweb: protect blob and diff output lines from controls.
gitweb: protect commit messages from controls.
gitweb: fix unmatched div in commitdiff
Documentation: move blame examples
git-annotate: no need to exec blame; it is built-in now.
git-annotate: fix -S on graft file with comments.
path-list: fix path-list-insert return value
git-cvsserver: read from git with -z to get non-ASCII pathnames.
GIT 1.4.4-rc2
OGAWA Hirofumi (1):
gitk: Fix nextfile() and add prevfile()
Petr Baudis (1):
Nicer error messages in case saving an object to db goes wrong
Robert Shearman (1):
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
* The 'next' branch, in addition, has these.
Junio C Hamano (4):
upload-pack: stop the other side when they have more roots than we do.
pack-objects: use of version 3 delta is now optional.
Revert "pack-objects: use of version 3 delta is now optional."
adjust_shared_perm: chmod() only when needed.
* The 'pu' branch, in addition, has these.
Alexandre Julliard (1):
Shallow clone: do not ignore shallowness when following tags
Jakub Narebski (1):
gitweb: New improved formatting of chunk header in diff
Johannes Schindelin (6):
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
Build in shortlog
allow deepening of a shallow repository
add tests for shallow stuff
Junio C Hamano (6):
git-branch -a: show both local and remote tracking branches.
git-commit: show --summary after successful commit.
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
rev-list --left-right
blame: --show-stats for easier optimization work.
gitweb: steal loadavg throttle from kernel.org
^ permalink raw reply
* gitweb some known issues
From: Junio C Hamano @ 2006-11-12 6:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Luben Tuikov
Visit git.git gitweb page (http://repo.or.cz/w/git.git would
work fine if git.kernel.org is too busy), and click on "GIT 1.4.4-rc1"
to view the tag (not the commit).
The navigation bar has commit/commitdiff/tree with explicit h
and hb object names that point at 'master', which feels wrong.
When the tag that is displayed points at a commit, perhaps we
would want to use that commit for commit and commitdiff? When
the tag does not point at a commit (which is admittably very
rare), probably not showing these links is the right thing to do
(if tag points at tree it might make sense to give tree,
though).
Also shortlog/log links do not say where to begin the log with,
which means start digging from HEAD. When we display a commit
or commitdiff, we seem to give a link to start log at that
commit, so doing the same as above for shortlog/log may make
them more consistent.
^ permalink raw reply
* Re: Shallow clone
From: Junio C Hamano @ 2006-11-12 8:16 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Aneesh Kumar K.V, git
In-Reply-To: <87zmaynl18.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> There's also a problem with the packing, a clone --depth 1 currently
> results in a pack that's about 3 times as large as it should be.
That's interesting.
: gitster; git clone -n --depth 1 git://127.0.0.1/git.git victim-001
remote: Generating pack...
remote: Done counting 6246 objects.
remote: Deltifying 6246 objects.
remote: 100% (6246/6246) done
Indexing 6246 objects.
remote: Total 6246, written 6246 (delta 3106), reused 4313 (delta 3106)
100% (6246/6246) done
Resolving 3106 deltas.
100% (3106/3106) done
: gitster; cd victim-001
: gitster; ls -lh .git/objects/pack/
total 9.6M
drwxrwsr-x 2 junio src 4.0K 2006-11-11 23:52 ./
drwxrwsr-x 4 junio src 4.0K 2006-11-11 23:52 ../
-r--r--r-- 1 junio src 148K 2006-11-11 23:52 pack-f5f88d83....idx
-r--r--r-- 1 junio src 9.5M 2006-11-11 23:52 pack-f5f88d83....pack
Repacking immediately after cloning brings it down to what is
expected.
: gitster; git repack -a -d -f
Generating pack...
Done counting 6246 objects.
Deltifying 6246 objects.
100% (6246/6246) done
Writing 6246 objects.
100% (6246/6246) done
Total 6246, written 6246 (delta 4815), reused 1407 (delta 0)
Pack pack-f5f88d83524213e3ab05697ff75f245b1ef9081a created.
: gitster; ls -lh .git/objects/pack/
total 2.8M
drwxrwsr-x 2 junio src 4.0K 2006-11-11 23:53 ./
drwxrwsr-x 4 junio src 4.0K 2006-11-11 23:52 ../
-rw-rw-r-- 1 junio src 148K 2006-11-11 23:53 pack-f5f88d83....idx
-rw-rw-r-- 1 junio src 2.6M 2006-11-11 23:53 pack-f5f88d83....pack
In any case, after this "shallow" stuff, repeated "fetch --depth
99" seems to fetch 0 object and 3400 objects alternately, and
the shallow file alternates between 900 bytes and 11000 bytes.
We would need to take a deeper look into what this series does,
before moving it to 'next'.
^ permalink raw reply
* Re: Shallow clone [Was Re: What's in git.git ]
From: Petr Baudis @ 2006-11-12 13:12 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <45521AE9.7050902@gmail.com>
On Wed, Nov 08, 2006 at 06:59:05PM CET, Aneesh Kumar K.V wrote:
> diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt
> index 275d18b..03a6f77 100644
> --- a/Documentation/repository-layout.txt
> +++ b/Documentation/repository-layout.txt
> @@ -141,3 +141,9 @@ logs/refs/heads/`name`::
>
> logs/refs/tags/`name`::
> Records all changes made to the tag named `name`.
> +
> +shallow::
Hmm, shouldn't the shallow file rather belong to the info/ subdirectory?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* [PATCH] Rework cvsexportcommit to handle binary files for all cases.
From: Robin Rosenberg @ 2006-11-12 15:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now adding, removing and changing binary files works. I added test cases to make sure
it works and can be verified by others. Som other corner cases were resolved too.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index 5e23851f8cf866112baf3e76973a8ca649d5c105..78c847ec906af8044e43f55d860a0652eff3e759 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -139,6 +139,17 @@ foreach my $f (@files) {
push @dfiles, $fields[5];
}
}
+my (@binfiles, @abfiles, @dbfiles, @bfiles, @mbfiles);
+@binfiles = grep m/^Binary files/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit);
+map { chomp } @binfiles;
+@abfiles = grep s/^Binary files \/dev\/null and b\/(.*) differ$/$1/, @binfiles;
+@dbfiles = grep s/^Binary files a\/(.*) and \/dev\/null differ$/$1/, @binfiles;
+@mbfiles = grep s/^Binary files a\/(.*) and b\/(.*) differ$/$1/, @binfiles;
+push @bfiles, @abfiles;
+push @bfiles, @dbfiles;
+push @bfiles, @mbfiles;
+push @mfiles, @mbfiles;
+
$opt_v && print "The commit affects:\n ";
$opt_v && print join ("\n ", @afiles,@mfiles,@dfiles) . "\n\n";
undef @files; # don't need it anymore
@@ -153,6 +164,10 @@ foreach my $d (@dirs) {
}
foreach my $f (@afiles) {
# This should return only one value
+ if ($f =~ m,(.*)/[^/]*$,) {
+ my $p="m,^".$1."\$,";
+ next if grep $p,@dirs;
+ }
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
if (@status > 1) { warn 'Strange! cvs status returned more than one line?'};
if (-d dirname $f and $status[0] !~ m/Status: Unknown$/
@@ -162,6 +177,7 @@ foreach my $f (@afiles) {
warn "Status was: $status[0]\n";
}
}
+
foreach my $f (@mfiles, @dfiles) {
# TODO:we need to handle removed in cvs
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
@@ -200,24 +216,32 @@ foreach my $d (@dirs) {
print "'Patching' binary files\n";
-my @bfiles = grep(m/^Binary/, safe_pipe_capture('git-diff-tree', '-p', $parent, $commit));
-@bfiles = map { chomp } @bfiles;
foreach my $f (@bfiles) {
# check that the file in cvs matches the "old" file
# extract the file to $tmpdir and compare with cmp
- my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
- chomp $tree;
- my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
- chomp $blob;
- `git-cat-file blob $blob > $tmpdir/blob`;
- if (system('cmp', '-s', $f, "$tmpdir/blob")) {
- warn "Binary file $f in CVS does not match parent.\n";
- $dirty = 1;
- next;
+ my $p="m/^$f$/";
+ if (not(grep $p,@afiles)) {
+ my $tree = safe_pipe_capture('git-rev-parse', "$parent^{tree}");
+ chomp $tree;
+ my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
+ chomp $blob;
+ `git-cat-file blob $blob > $tmpdir/blob`;
+ if (system('cmp', '-s', $f, "$tmpdir/blob")) {
+ warn "Binary file $f in CVS does not match parent.\n";
+ if (not $opt_f) {
+ $dirty = 1;
+ next;
+ }
+ }
+ }
+ if (not(grep m/^$f$/,@dfiles)) {
+ my $tree = safe_pipe_capture('git-rev-parse', "$commit^{tree}");
+ chomp $tree;
+ my $blob = `git-ls-tree $tree "$f" | cut -f 1 | cut -d ' ' -f 3`;
+ chomp $blob;
+ # replace with the new file
+ `git-cat-file blob $blob > $f`;
}
-
- # replace with the new file
- `git-cat-file blob $blob > $f`;
# TODO: something smart with file modes
@@ -231,7 +255,10 @@ ## apply non-binary changes
my $fuzz = $opt_p ? 0 : 2;
print "Patching non-binary files\n";
-print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
+
+if (scalar(@afiles)+scalar(@dfiles)+scalar(@mfiles) ne scalar(@bfiles)) {
+ print `(git-diff-tree -p $parent -p $commit | patch -p1 -F $fuzz ) 2>&1`;
+}
my $dirtypatch = 0;
if (($? >> 8) == 2) {
@@ -242,7 +269,11 @@ if (($? >> 8) == 2) {
}
foreach my $f (@afiles) {
- system('cvs', 'add', $f);
+ if (grep /^$f$/,@bfiles) {
+ system('cvs', 'add','-kb',$f);
+ } else {
+ system('cvs', 'add', $f);
+ }
if ($?) {
$dirty = 1;
warn "Failed to cvs add $f -- you may need to do it manually";
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
new file mode 100755
index 0000000000000000000000000000000000000000..0ae03f80694a5d4ca3e61b40f6787a89fe8a496e
--- /dev/null
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -0,0 +1,145 @@
+#!/bin/bash
+#
+# Copyright (c) Robin Rosenberg
+#
+test_description='CVS export comit. '
+
+. ./test-lib.sh
+
+cvs >/dev/null 2>&1
+if test $? -ne 1
+then
+ test_expect_success 'skipping git-cvsexportcommit tests, cvs not found' :
+ test_done
+ exit
+fi
+
+export CVSROOT=$(pwd)/cvsroot
+export CVSWORK=$(pwd)/cvswork
+rm -rf "$CVSROOT" "$CVSWORK"
+mkdir "$CVSROOT" &&
+cvs init &&
+cvs -Q co -d "$CVSWORK" . &&
+export GIT_DIR=$(pwd)/.git &&
+echo >empty &&
+git add empty &&
+git commit -a -m "Initial" 2>/dev/null ||
+exit 1
+
+test_expect_success \
+ 'New file' \
+ 'mkdir A B C D E F &&
+ echo hello1 >A/newfile1.txt &&
+ echo hello2 >B/newfile2.txt &&
+ cp ../test9200a.png C/newfile3.png &&
+ cp ../test9200a.png D/newfile4.png &&
+ git add A/newfile1.txt &&
+ git add B/newfile2.txt &&
+ git add C/newfile3.png &&
+ git add D/newfile4.png &&
+ git commit -a -m "Test: New file" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.1/" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "newfile2.txt/1.1/" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "newfile3.png/1.1/-kb" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "newfile4.png/1.1/-kb" &&
+ diff A/newfile1.txt ../A/newfile1.txt &&
+ diff B/newfile2.txt ../B/newfile2.txt &&
+ diff C/newfile3.png ../C/newfile3.png &&
+ diff D/newfile4.png ../D/newfile4.png
+ )'
+
+test_expect_success \
+ 'Remove two files, add two and update two' \
+ 'echo Hello1 >>A/newfile1.txt &&
+ rm -f B/newfile2.txt &&
+ rm -f C/newfile3.png &&
+ echo Hello5 >E/newfile5.txt &&
+ cp ../test9200b.png D/newfile4.png &&
+ cp ../test9200a.png F/newfile6.png &&
+ git add E/newfile5.txt &&
+ git add F/newfile6.png &&
+ git commit -a -m "Test: Remove, add and update" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "newfile4.png/1.2/-kb" &&
+ test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
+ test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ diff A/newfile1.txt ../A/newfile1.txt &&
+ diff D/newfile4.png ../D/newfile4.png &&
+ diff E/newfile5.txt ../E/newfile5.txt &&
+ diff F/newfile6.png ../F/newfile6.png
+ )'
+
+# Should fail (but only on the git-cvsexportcommit stage)
+test_expect_success \
+ 'Fail to change binary more than one generation old' \
+ 'cat F/newfile6.png >>D/newfile4.png &&
+ git commit -a -m "generatiion 1" &&
+ cat F/newfile6.png >>D/newfile4.png &&
+ git commit -a -m "generation 2" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ ! git cvsexportcommit -c $id
+ )'
+
+# Should fail, but only on the git-cvsexportcommit stage
+test_expect_success \
+ 'Fail to remove binary file more than one generation old' \
+ 'git reset --hard HEAD^ &&
+ cat F/newfile6.png >>D/newfile4.png &&
+ git commit -a -m "generation 2 (again)" &&
+ rm -f D/newfile4.png &&
+ git commit -a -m "generation 3" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ ! git cvsexportcommit -c $id
+ )'
+
+# We reuse the state from two tests back here
+
+# This test is here because a patch for only binary files will
+# fail with gnu patch, so cvsexportcommit must handle that.
+test_expect_success \
+ 'Remove only binary files' \
+ 'git reset --hard HEAD^^^ &&
+ rm -f D/newfile4.png &&
+ git commit -a -m "test: remove only a binary file" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "newfile1.txt/1.2/" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
+ test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ diff A/newfile1.txt ../A/newfile1.txt &&
+ diff E/newfile5.txt ../E/newfile5.txt &&
+ diff F/newfile6.png ../F/newfile6.png
+ )'
+
+test_expect_success \
+ 'Remove only a text file' \
+ 'rm -f A/newfile1.txt &&
+ git commit -a -m "test: remove only a binary file" &&
+ id=$(git rev-list --max-count=1 HEAD) &&
+ (cd "$CVSWORK" &&
+ git cvsexportcommit -c $id &&
+ test "$(echo $(sort A/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort B/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort C/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort D/CVS/Entries|cut -d/ -f2,3,5))" = "" &&
+ test "$(echo $(sort E/CVS/Entries|cut -d/ -f2,3,5))" = "newfile5.txt/1.1/" &&
+ test "$(echo $(sort F/CVS/Entries|cut -d/ -f2,3,5))" = "newfile6.png/1.1/-kb" &&
+ diff E/newfile5.txt ../E/newfile5.txt &&
+ diff F/newfile6.png ../F/newfile6.png
+ )'
+
+test_done
diff --git a/t/test9200a.png b/t/test9200a.png
new file mode 100644
index 0000000000000000000000000000000000000000..7b181d15cebb4c86a6ad7fed3dbf30ce2223b4c5
GIT binary patch
literal 5660
zc$`Id1yoe;^Zo)$N(e0J(p}QEfPi$DQW8>2hjdCvBQ2c^N=U=fEQ%l<OE*Zj)FMj$
z_VYjAbN=_7_s)Cf+&g#PnP=v?6Q`@KLPS7I0001p)KnGq(GvdO!oxw|WyWxX&;rL=
zLq!o#3}6JD5q?UcKx^<lR8719fafg#Ee!uJvc6~~uD6<&67C!}76@A+ze^|xt)lZ*
zGWJ$*cXhRM^9Cq*+F5zq*)sY$dOI+_a<F4mQPa{rwPkYy04T!L6y;y}FP#*)x`19U
z4?K2;EPnZ}m4_D*|7mH8Eb&57u38Jik~sH^?kl_U(~Q48dvnsHNa~{}zdt5Nt}*E5
zikv5GD3NPue*dxh7f`vl7%RR~(J)J59p_3~+O<^D1-DxcdEsKe+S1fy4;}Avtqaw!
zJo)YY2lCCU;K*zbVvpIWj!VXv>ZvF%gb^3Uo{Hx{HuQcc9lxw_w{~z~g<>)9VYESF
z9Gq}_*o5t%FVT#8d*scY-TdptZBgpXqn{gtNC=55me$ro4Z(adx7mm2&Hfc!(~-Qt
zlU{8#Y|nbzoE2hkeI~#OrBwm3l``6d^zzd=F+P^lx+@O&E;?8;eo8OsT?%S%b8B~*
zG}a>Ic5(kKK7O=yc|w^zJuA^l_j)6D1(1tvTZ&T<&$#ZdQ&@QxfxB=}TA`O+BX`18
zoaI7@6~>nAxoZrLnKR3oBJb`Liv;6JPVcvuSN4KNp)g-Mhfdn>cnfGZB?SF}95~6v
zur@(awR4tHWfd_F=|5dTPk7CH@n&i<PZY8C!&k+SpK={9<2OdtPjnCOvk#0XP~#W2
zDh43z63*QBp|9I;61|oSFanuD)m+pZh@rl}9S5VmXxouhOk?po7RJyAZLNouh}_v8
z;8<XKOE`P=DNo_{#?1P`Pc3bdL?`1*%~M`f&H6adt79HM!qVi+J3ALxhd3{k)`?Mw
zU}U6CG;O3xAjGQqk?UBY{VhB$Q2-sMOc%nS=i?*0@&Ovnu*vbX1DR@`P>XQWG}h$@
zWn_hXQ+PFQ<RRBRd!YqHMq6yThrN4UM~ni9k*eC4*1C%cr%B%YNnO{{GWWVT!2b^I
z*D<&2cVR@+8QL97e|x@qY<U3@!EGE7l57OoR!-cGKZfg1VVzg3WZ~-+iOM;}VreJ%
zjUr_kI26Dh;kXA>kUA@wDl3^L&J``Pn(?nZFWt1Ns|s?w9}a2q8P;GW!(YAKPEFq3
zD~QSuH?dQ6PpjD7YR7PGVJexd*t42D3^uJl<8<C;QyZqsZVGS|X8U3iE_PUe`hLbT
z)0Np1;O`)+kdlzQe@7etOpDLS&YWxJ4gL7ef;LDgUy^dKMZc}PZs9_dEN*2j0mey?
z%OGj%sJOigLmRAIcutmh(<nD|dJdmGOTu@^j22B_zk<ITfN=4foPgiwCbw~wNqe_g
ziD$h`^gbUgcylG)?qJDhqID`{v~0KJlTsy61%dApwB9E`{oMXC-RGz^@+Lp~X=2=9
z?WM3&ddQq`!=|P`KHf3i9JImaHZRn1cxaSurx*E|vy86Tq=Ii&A*i`Hzt!KpPZYD+
zvOt;fY5k1anA?}q^mMb7=}xPal(k4xJrEERgOiqi#fjII)<M?LKY+-o)33LUD^rh6
zrh6`}!*MD00)2iqVS(F9)uMq>si$}zvMamMcW)+jS7OOOsCY0vH0?T9_fNz#+g$&q
z1{A~LGkTr)5n-#He)e}EmX-{d;bCr?_tR@fe+H1y<n)WC;}`Vue0N3EZ}Lp&UV*R$
zO$tT05|qh3AWT0Svvf~|X$w-G5lf;Gr!(ZCu=)a;HAB>nM*Vs6jX0B9nq;;TsdY4=
z0&kgwn|S8S_cFf{8=={nb?*Ie1M#)=7<A#c6pp{5sO?F+ff#fKf%GCPI18KJh|tcC
z1={9;Y4NWJ1024&^uwn$)|;7ZtIAtM;P&B?WTa-D-(2i~XrwJQ5MjA$*bE944|ZcL
zC*<ij*%5XXUe$X-V;qZ598~o{OzLEqC6RKB06h?$D_BX7am2IH;2*qqu%trDrOAJg
z5YeZ{f5M6ELU@&Jca(6Zu*SVfw#y0ENCUn*cIW;mSYd7zV<p8CzY9c`STV*kW9m;0
zeU_r-p_3(xTd=s^B0%z1qU~mHZ2FKKPJpO543$rK2W+9)*>s7~MEXg}H_oi0c~=6$
zlH0^0tscGKY3xg=n~1<Ny&Xi&4OY^(ArGYwT5d_u;0h?%3DNP-n0FV9bknprCT>Sr
zLt2Y>Wpqe^7^jcxk3xt!PF>ytwWIeRqv@2D`PhpC`V-Q0q>C7YaCxuo{YIVom20t1
z#$#GTW4u`P^L&ii?1-49eZ&j-7<|eqWNy#0D#@1`tesSL`vxs^giY|oshoqc;D8=8
z(y;|aB|;!${NcQD2iJ#I3ZPf1+>P*U7w=Y>GNIX<MnpPI2FH8@HhDRgR&F0xXh`XU
zS=9mu8L2l%QCf*+oGX-^!<Ba<)1-5OW?t$Lc4Eq9J*GNHqp#m_z4I1)k`WWvczjC^
z9P;M+YWU_HLNT1q6qCxN#-ES8Xt5~Vr@>wtPgS6Dl9v;4dT@9Cf*TM*sS*yQb2<j6
z!6}Kmyj8W0E}t6ZnX1V^BOp!+Dx0&r@>0?<8F?+8VM@--TYFwgjdmZZiB%7|8l5`N
zBx2Y?KE0Ya^c9KTrCPSTj#Nf`nS^nB{a!R?38;*G#lKw4Nd_93*XeJq#_h8|ddrRU
z&6nJC7)<4}&&hY77N@Q<nt$VaHQYV|%~xshH>5-~ZE}qa9V)9?%gU|{3XkN3i_tFU
zTmqp|>XGL@dRr_CIH&emGH4pi>+lt!9dnRVO8u45?jb^}#7ZUzXB0*^=a-K%1qUAV
z15IGxpM!x28A-U^;(7j%*OMjWVtXC(V-_V41Ha(!oTgoV7Au~M&QmY2L#GhIkiCzh
zsFbcJv&~I3$Nk{%*DrazGBrz6W>v^L`Si4j1sA(SF5AJ<MZ(#ROpyaF;)@QLK-io|
zLC<!<5GGmNP}rGt>MQqb(V%P{r#CrKy<~_oIXN6gyO0M+Q_L<6x2+I&vgep>E|)bm
zbZnL<(H~93gQ*lUO%2|Ge;89$B^r|_+}QGztuK(ZH6Z0uJ=IChscAbXL4Sbb#bJhk
zBSz2fg&h0+)E8EUMMHxuC%cAFR`bA#J3%0PQ1YIf6sSn9hsVWV(kAwd;oG@f*ymIN
zuZ|z%Jk4~!1MO{g2;^<3_KF@zQ_R#8J0zszOR`%&XCB+8a$Vrz)%8}3rta**npb3X
z>eI1ziAn6Yq~#j-l^K%{;@TE96`zXCJ8!QD&;qz{<kA>FPX%E{0iJ7sC}OPvNE7&k
zh~%jFd=TrPI*@)j#Kz5&mXuLo=G|a?g#I1XB$Q*Ykx=P|rxaF>ZjmBI5pM$r;+Yd-
z@g@na;<|C|Luk`h$r@i0athMKE4vguWQ$oO>x_$#>eS8Zg6uq%%UXPSca7e{2Zx`)
zlz7<{^uq*m`G%yCHXO&Qj&Dt6PE`5mJ)ilT7&59g{!S?u6?Eiu+rBBjMbj#$Iyq+e
zF_FwU#UXH6V|f4sXlQs;Rd;b=9v2_^-lgxbowIJ%wP!q3V(@lEwJ_qV#~|Do`;E-d
z`ry{OF*s`4V?^yb@7N_@*f_`K*reD%(2dz@nei*&Y5Mb=&YmW|$qqXkwRlh2KsoK?
z$)^fJfhjKc;GD4WYoXEa3;lBrGn5rdN*IbcxAo=PrgPU6!ZJU`j>(~87<@1FMw8zY
zgk|$8=%rD3=r>xg3tMR!lDMLV%Ef*%s4jS%eO$94^LH{jkW)@+rUz|jo3O<>hQ4*$
z+=X>KHDHS2cuP+{5n?}d9PSk(=oH1^mK3=45)yqVRStPU!a<6{8eLH!iqWBbE%UC!
z6#)=V;JY(apqt6FBOkq+5kp2^h5R&LH#(MF9;Qi}%%FIrGtMF1H~Vya{sFp@#%#w4
zNeF1_lXp*}%jXv0c*d!Wf}*A_KD$I4O<afpy|sgwH!~N-JcZWIR`<@Zk?cCIY{iMH
z>d%F^0GI&KP$xx3U{!stV<-AEh3)?|4`_I3aLXwL@07inQ%BWC0IVcshch0%XY3}0
z*kZm{ic*_(mAvv_uYT%g*4&qYkrp?>7E^6E#66wYIW;E{7Ovi<Q8LPjFAE{7QX1VA
zB~UA&{hzSK@rZvYVueD8<W`}vq3Kc2ay7xcKy#KGU(7Rd&NZbA-gHGNBjstS@@vmK
zn*mjaa6w=F)b%thc^=_mv$Nbod$=>^SBp+q+oax`M#;U=PA=@^dY4b~WtgEH(xMux
z_2iq)Z&(c!{MlSN@i3VoKD$FUKt&@1dMKFtGKr#DklirpJT?JAJz{!a9Z0mHOb2%g
zot^VC+D?{Iyc=!spR=LO?{L3*F(x6QAlDQq!NK9D9dM#4c-A-JfD%43&!g(=S`PQ)
z^XpJ(I$UYP(%KXjqW-t4h?nopdMMKn=_uX9R;*_5^8e2T{}UKm%sY`61%Fv!n*epn
zJ*(Xs`ABulK@!}-3j@XT9$@qh`QOVuJ=CK>1XEs9Ukir08EM~-*{E#GtmL#|X(tmh
zK=I=MY5wonQolz59PK2}Z!fN+G9)!F>unXNFP$zbuT(p3PE^4KV;>~0uVSymh}WNf
zZxsK*>CE{#lbJ?eXIY?oNhr4G$(-J{5LbSa2uY}Wk-R{<W@R<(DS8`@HnoD=v3ZUu
z{rB7(w5p0vo)$o{O5OK?K}Y517WQup^K*ZUua72?Z!zrnROcvo@rrMXlroFOh*0@o
z0*uecMVzq7{A&E|a}UmXLCB3~m=&%}6Pk?^2J<Z-reKBdG{sp6(z5Iv+aOKEabo?w
z+=NN4$|7MJ3%4_;2sn@$CvYfQz$AA&`{M-^Z+|nMu?CO^p6$vF1{ncQFakH62t-xK
zNAUcj!wM}`)^fJHK6(rgdRIuuz4l@?dZnKeqx&w5AIX-04^2zZ6}}iCM2)`TI@R>l
zslIE70kgrmRsY)xVreaxsk+5y$i}m%O0r?*D$1p+77}R<0^4D7OCN;D<0^xSt6Atx
zGwsm-m%WznI}D#Yj%4z2a&!Nft9gU(koI`B7IeC?)a>kkz3Ruc&DhRTXx0BSfokCX
zs0x{IWtQ~6`E3y9ze3?7N&@q`WsCx|4tu6Z98G=E_<Pn%GP$;vblQDOO!eGMjuZ4_
zOnm+0;h|Htc_*chkB|TDNh=4!Z!A~T8169HR^;R7SK8bxy0u<aQxnCA7yY{dfuJ)t
zH;*0IN@pL>0TD#i2mkY234Oc=d1_LeEHq%%bzKm=f4uiwonH+)MMwmq_CFWJ^jev9
z`ns-6lxgKf_w<bR*0E~6f8Sd8;%1*k`W`i1CTrvD%v0#UiLVn0-iEo(pr5M`x%DlZ
zcj`IL!r$57udsK~mRtVpy4;fZAz-pZ$-%{?4~s-PY_Z9H>+avBMDSmM7Pr;-bPgS-
zKodZ2VO>)bdC;F@nrmSty<*Pz%Ak<L%5q(O{fOGy=N~_Q{QTg16XH-=U;h*xT?KP<
zx+rjawL!Ty?CV!<3d(8=1T918onU-?JUimg;cS(0r!U{1({=YD=i$cuhzW;5c@yHa
z+O_{qJ?gje4)@RTVky2b07O9nYi_1!U4Jh{lk@@4;hFb75;k+4C+@B+Q61XS2X~yV
z54eO1fiX_B(19)Qw%2m3F>6mFRFMlZP*6~)JhdOsA3_z<2t!jg?g+j8{KSWchjk4N
z#l}l_el$ZT3TqB(u0CfRF#f~a54rsVYi*@MAP|31(>h*<rXyMWIw9Yj=bx8d*LNpv
z>lIJO*dbo?%UT=_aTIBWtWQlv81t6h1}f<xr=~V(I4>?9AXqk=`Vts2*jEcS$ySSv
zc7U*r4XbL?W&$a{-}&$oF$g5SK+4a0_UmhEdip=3_x#57Z_VtdpG>R;9`Sw3$}0W*
z88|jJR=X}$16tbNK*!+&8cX>yL6k<dW<5<4FB1IL0&sbZYBg&>?;rl{?H?Rib^p$?
zd><$3JogKAFx^p?&Z_1W<^FK@&%xF8XUO$x`R#+x(cBk;FNQUyQ8zb%uU@}~q4Si*
zZ`ogIP=0pOx?WOO=e}}l5qj_AvQQr$Hm;PBk-<cn0E59WIJENt02B&Ejp<(kfj}C6
zRF_Ye>y(z3vhX15x^K9N>7`@029j<3{i$(@!QaENa2tI$`}_M>u8}e_G7Fu4{IwPc
z2$$Q;vpMK!cDM>d2<QpbbJSh4P-SBy*?RCLQH$$xbY>=HzLcN#rO(dJj{im!)!CE=
z|A9qaZ7nfF@EOMYe>+qLuJ1<pS_Nj!|ARznDOMfg53TR<f?(wmKeo>M7r(o2-K0@S
z1>;sXI=9XfvH9>8L}qDM7g+Wlm0p?0!_Uu<HGXl}Yz#^scz5^rUGU@mwM6KHGywsD
z$F!EX)xp#k<1T+evN&Kw&-N#F5P?bI$_2W-vpi7ydT7{eCCfg@$;)Hxj^)J+538>P
z>=k5-jpcB_0?L9v?LBv_vq*5{9Gy_{@e%!6RV5l)v?kBZ%`Ht1LD&70tE;Puy1Hwn
z3VSJJ3<*PjcgU^Bzl$9;g-*!lClLaUF;Nis?S`r0?D~50USW`%S!N^}Z0K$hi_WXb
zrQgA?`cG1USEhj-{^!g~OG{@*b>Fnrmx)M7O6%%KibDR-;Nalsb2Vw@iIL`f+Bqw8
za&po)Npj)l<NMk30aws@j#nsOZSqI_nDt^Ih&bkaGl9PZUC!t%+lpKu*Ji0KgToO)
z*G^@}WjaMk@$m$)C9&V`Puy*JWwGc8qC~z;d~wG3o-gTjc6T{J?$}Q6DIy|*p07bq
zD0#oLBul5I&ogT=k(j@J9ksT$mfuYo#~#J{A4$^SKwe}sI;WbE^MsDdkzA1@S+Dzs
z8HADO(5oA=wX+*OWQYHLw2G`&_tg4-jU5Xg^{A?wZWi`$fRvEPgIE&q%UdPCTEo*!
zxlI`8efnV4_<ZOc&BpjsBo>Ft`7-In6zd*pIaLBpqDxpJ0B<ppv<$VRAx`(`@E6xt
zc!5itD8|LQ!WOIi+rU1HVvJu^d>`5ZGtsZzdS4xLb}v~=(+XgtenkPTAH66_=N+$7
z`YcQ5(}RgDR3)(Bw1MEDOInknKJ$UKE~vyzJ)sC7|85)daL*m!L?%0NcWP9(xy>=J
zW!dZbZ+}Rqb_==012RbG9T<(7vuFScQx(siZCR37mL1~`eF|KPKCg@6&m$I|`Wf6p
zSGCJK)|*CTHChED+F=d3_hn5Q-<5yPxQqk;ie^m8+UI?D9l@Vo?dlz+0$86UYWwv~
zc7`q>35t*8%6VRa<%Tw;N4rF0b=3g>HUQ1XAiZFLaM%Oz;VuAlFI#Uk7C`GjHpDf_
sZt`C;NRh1n6KI-bE>`<bG#WgTFr20ZTb_|v0nnG4lD1;)%eN8#2U^3?i2wiq
diff --git a/t/test9200b.png b/t/test9200b.png
new file mode 100644
index 0000000000000000000000000000000000000000..ac22ccbd3ee9f03a3b38249ac8efdbe96b5da2cd
GIT binary patch
literal 275
zc%17D@N?(olHy`uVBq!ia0vp^9zZP3!VDyJZ(h*_aRPioToo7?5)xuJtY5{@z;N#D
z@dFGDFJ3(R{{7qk|No7uYm$J<7)yfuf*Bm1-ADs*lDyqr7&=&GL8fsQctjR6FmMZl
zFeAgPITAoY_7YEDSN3bH%%X-S`j4JZ016d)x;TbtoKN<6ufXCZA)&>gl@*-uLV<^+
zZOfu-7cOu}w0W9H3$HwJqlx472Q4Ervph31wm>lpQB&rr2^-hlWNOq5Vkv20<q=-Z
z@v30LY2AXTcBx4_L=O5$-0^JfxTAF7fm=Y}A_nHk3XTg7IPfqqTq@aCrp)Sh2xvKj
Mr>mdKI;Vst05+voj{pDw
--
1.4.2
^ permalink raw reply related
* Re: StGIT repository not clonable?
From: Petr Baudis @ 2006-11-12 15:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, catalin.marinas
In-Reply-To: <ej5jt1$9tf$1@sea.gmane.org>
On Sat, Nov 11, 2006 at 11:48:04PM CET, Jakub Narebski wrote:
> Catalin Marinas wrote:
>
> > IIRC, there was some advise in some GIT document
> > or e-mail saying that you shouldn't pack if the export is over a dumb
> > protocol. That's good for people pulling regularly but bad for
> > cloning.
>
> By the way, does dumb protocols download _whole_ packs only? Or do they
> download parts of packs (curl can do that, I think)?
curl can, but it might very easily get even much more expensive than
downloading the whole patch unless your latency is very small and
bandwidth very tight, which would be quite a unusual situation.
It's true that repacking can hurt dumb protocols - if you repack often,
dumb clients will have to re-fetch the single whole patck with all the
stuff they already have plus the few additional objects they are
missing.
But at least packing once can be a huge improvement and won't hurt the
dumb clients since their problem is with incremental fetches.
Furthermore, if you do just repack, not repack -a, the cost for dumb
protocols is quite small (though it's not optimal packing strategy):
It is not unlikely at all that if you have set of unpacked objects A,
client fetches that, then you create set of objects B and then repack,
creating pack(A \cup B), this pack will still be much smaller than the
set of objects B (even if |A| >> |B|) so it's more beneficial even for
the dumb clients to refetch the A objects contained in the pack, instead
of fetching just the unpacked B objects.
By the way, in case of glibc-cvs the pack sice is 104M, and after
importing new CVS changes after few days, the repository size doubled to
200M. git-repack -a -d brought that _back_ to 104M!
Packs are a funny thing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* should git download missing objects?
From: Anand Kumria @ 2006-11-12 15:44 UTC (permalink / raw)
To: git
Hi,
I did an initial clone of Linus' linux-2.6.git tree, via the git protocol,
and then managed to accidently delete one of the .pack and
corresponding .idx files.
I thought that 'cg-fetch' would do the job of bring down the missing pack
again, and all would be well. Alas this isn't the case.
<http://pastebin.ca/246678>
Pasky, on IRC, indicated that this might be because git-fetch-pack isn't
downloading missing objects when the git:// protocol is being used.
Should it? Is there a magic invocation of git fetch I can use to fix this
up. I can always re-clone completely (since this is just a tracking repo)
but it would be nice to fix this with the tools themselves.
Any hints?
Thanks,
Anand
^ permalink raw reply
* when is a remote a branch?
From: Anand Kumria @ 2006-11-12 15:50 UTC (permalink / raw)
To: git
Hi,
I generally tend to use cogito -- it does all the heavy lifting, like
recovering from interrupted fetchs (usually) for me. One thing I haven't
really gotten my head around is the difference between a branch and a
remote.
git-branch knows of 'remotes' (via the -r parameter) and these to be
unrelated to what cogito thinks remotes are (it seems to look for things
in .git/refs/head/<name> and then a corresponding .git/branches/<name>/
which it then declares a remote).
Yet, git-init-db creates both .git/remotes and .git/branches
What is the difference between the two. From my (naïve) perspective the
two tools (git and cogito) regarded them very differently.
Any explanation, or pointer to some documentation, would be helpful.
Thanks,
Anand
^ permalink raw reply
* Re: when is a remote a branch?
From: Jakub Narebski @ 2006-11-12 16:11 UTC (permalink / raw)
To: git
In-Reply-To: <ej7fra$8ca$2@sea.gmane.org>
Anand Kumria wrote:
> I generally tend to use cogito -- it does all the heavy lifting, like
> recovering from interrupted fetchs (usually) for me. One thing I haven't
> really gotten my head around is the difference between a branch and a
> remote.
>
> git-branch knows of 'remotes' (via the -r parameter) and these to be
> unrelated to what cogito thinks remotes are (it seems to look for things
> in .git/refs/head/<name> and then a corresponding .git/branches/<name>/
> which it then declares a remote).
Not about 'remotes', but about 'remote [read-only] branches', i.e. refs not
from .refs/heads/, but from .refs/remotes/<remotename>/
> Yet, git-init-db creates both .git/remotes and .git/branches
>
> What is the difference between the two. From my (na?ve) perspective the
> two tools (git and cogito) regarded them very differently.
>
> Any explanation, or pointer to some documentation, would be helpful.
Read Documentation/repository-layout.txt (ot it's HTML version, either
locally ot at www.kernel.org).
branches::
A slightly deprecated way to store shorthands to be used
to specify URL to `git fetch`, `git pull` and `git push`
commands is to store a file in `branches/'name'` and
give 'name' to these commands in place of 'repository'
argument.
You can store only one branch to fetch per shorthand. I'm not sure about
where it is stored which branch to download, and how to name this branch
locally.
remotes::
Stores shorthands to be used to give URL and default
refnames to interact with remote repository to `git
fetch`, `git pull` and `git push` commands.
From Documentation/urls.txt
In addition to the above, as a short-hand, the name of a
file in `$GIT_DIR/remotes` directory can be given; the
named file should be in the following format:
URL: one of the above URL format
Push: <refspec>
Pull: <refspec>
Currently there is yet another way, by using config file:
(also from Documentation/urls.txt):
Or, equivalently, in the `$GIT_DIR/config` (note the use
of `fetch` instead of `Pull:`):
[remote "<remote>"]
url = <url>
push = <refspec>
fetch = <refspec>
where <refspec> is defined in Documentation/fetch-pull-param.txt
<refspec>::
The canonical format of a <refspec> parameter is
`+?<src>:<dst>`; that is, an optional plus `+`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
(or, simply, in git-pull(1), which includes those files, with exception of
repository layout document).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: when is a remote a branch?
From: Petr Baudis @ 2006-11-12 16:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ej7h1n$ed8$1@sea.gmane.org>
On Sun, Nov 12, 2006 at 05:11:41PM CET, Jakub Narebski wrote:
> Read Documentation/repository-layout.txt (ot it's HTML version, either
> locally ot at www.kernel.org).
>
> branches::
> A slightly deprecated way to store shorthands to be used
> to specify URL to `git fetch`, `git pull` and `git push`
> commands is to store a file in `branches/'name'` and
> give 'name' to these commands in place of 'repository'
> argument.
>
> You can store only one branch to fetch per shorthand. I'm not sure about
> where it is stored which branch to download, and how to name this branch
> locally.
I think the above is quite confusing description. This really is not
about any "shorthands" at all, but just about branches (how the name
implies, after all).
Git and Cogito share the same models of branches. These branches are
'heads' with commit pointers stored in refs/heads/, etc. The branches/
directory says that some branches do not correspond to local development
(and should never be used for that) but instead they correspond to a
particular branch in some remote repository. Such branches are called
"REMOTE BRANCHES".
So it's "if branch X has corresponding .git/branch/X file, it's not a
local branch but instead a REMOTE BRANCH corresponding to the URL stored
in that file". That simple. The URL is address of the repository plus
optionally a '#branchname' if the branch name in the remote repository
should not default to remote HEAD or master.
In addition, Git (not Cogito at this point) supports a completely
different and unrelated abstraction called REMOTES. They don't have
anything to do with branches. Instead, a REMOTE represents a repository
URL and a set of local/remote branch pairs to handle on pulls and
pushes; it has no other obvious mapping to branches and branches can be
even shared between various REMOTES etc. (this is changing lately with
the refs/remotes/ hierarchy, but I think that's still not in wide use).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* gitk broken or user error?
From: Seth Falcon @ 2006-11-12 17:00 UTC (permalink / raw)
To: git
Hi,
I get the following error when invoking gitk with any command line
argument, for example, 'gitk --all':
ziti:~/proj/R-devel seth$ gitk --all
Error in startup script: unknown option "-state"
while executing
".bar.view entryconf 3 -state normal"
invoked from within
"if {$cmdline_files ne {} || $revtreeargs ne {}} {
# create a view for the files/dirs specified on the command line
set curview 1
set selec..."
(file "/Users/seth/scm/bin/gitk" line 6298)
I tried a certainly incorrect thing; just commenting out the offending
lines:
diff --git a/gitk b/gitk
index ab383b3..a6c0a9f 100755
--- a/gitk
+++ b/gitk
@@ -6305,8 +6305,8 @@ if {$cmdline_files ne {} || $revtreeargs
set viewargs(1) $revtreeargs
set viewperm(1) 0
addviewmenu 1
- .bar.view entryconf 2 -state normal
- .bar.view entryconf 3 -state normal
+# .bar.view entryconf 2 -state normal
+# .bar.view entryconf 3 -state normal
}
if {[info exists permviews]} {
And now gitk _seems_ to work. No error message, and I can pass
argument to gitk like --all (wow, very useful).
I posted about this in October [*1*], but didn't get any response.
I'd like to be able to use gitk without my must-be-wrong patch. This
is on OS X ppc (git version 1.4.4.rc1.g73347) with Tcl & Tk at 8.4.7.
Can I provide more info? Have I missed a configuration step?
Thanks,
+ seth
^ permalink raw reply related
* Re: when is a remote a branch?
From: Jakub Narebski @ 2006-11-12 17:31 UTC (permalink / raw)
To: Petr Baudis, Anand Kumria; +Cc: git
In-Reply-To: <20061112163624.GE7201@pasky.or.cz>
Petr "Pasky" Baudis wrote:
> On Sun, Nov 12, 2006 at 05:11:41PM CET, Jakub Narebski wrote:
>> Read Documentation/repository-layout.txt (ot it's HTML version, either
>> locally ot at www.kernel.org).
>>
>> branches::
>> A slightly deprecated way to store shorthands to be used
>> to specify URL to `git fetch`, `git pull` and `git push`
>> commands is to store a file in `branches/'name'` and
>> give 'name' to these commands in place of 'repository'
>> argument.
>>
>> You can store only one branch to fetch per shorthand. I'm not sure about
>> where it is stored which branch to download, and how to name this branch
>> locally.
>
> I think the above is quite confusing description. This really is not
> about any "shorthands" at all, but just about branches (how the name
> implies, after all).
Well, it is a shorthand in a way that you can just use "git fetch"
or "cg fetch" to fetch correct branch without need for URL.
But I agree that the description (although of deprecated feature)
could be better.
> Git and Cogito share the same models of branches. These branches are
> 'heads' with commit pointers stored in refs/heads/, etc.
Not exactly. "Live" branches (i.e. branches you can commit to) are head
refs stored in refs/heads/. But in repository cloned with git-clone
--use-separate-remotes tracking heads (tracking branches) would be at
refs/remotes/<remotename>/. You can fetch to such a ref, but you can't
checkout it, nor commit to it.
> The branches/
> directory says that some branches do not correspond to local development
> (and should never be used for that) but instead they correspond to a
Does that _should_ is enforced in Cogito? Is it enforced in Git?
> particular branch in some remote repository. Such branches are called
> "REMOTE BRANCHES".
I'd rather call them "tracking branches", at least in git. So if there
is branch 'localbranch' in refs/heads/ (?), and there is corresponding
branches file branches/localbranch, which contains a single URL
git://host.domain/path/to/repository#remotebranch
it is AFAICU equivalent to having some remotes file, named e.g. 'repo',
with the following contents:
URL: git://host.domain/path/to/repository
Pull: remotebranch:localbranch
Push: remotebranch:localbranch
or equivalent entry in git config.
> So it's "if branch X has corresponding .git/branch/X file, it's not a
> local branch but instead a REMOTE BRANCH corresponding to the URL stored
> in that file". That simple. The URL is address of the repository plus
> optionally a '#branchname' if the branch name in the remote repository
> should not default to remote HEAD or master.
The whole concept of branches file (and marking some branches as "remote"
branches) is IMHO from the times where there were most common to have one
live branch per repository, and we fetched and pushed single branches.
This simple picture changed with more widespread use of multiple heads,
and with the introduction of tags (I think).
> In addition, Git (not Cogito at this point) supports a completely
> different and unrelated abstraction called REMOTES. They don't have
> anything to do with branches. Instead, a REMOTE represents a repository
> URL and a set of local/remote branch pairs to handle on pulls and
> pushes; it has no other obvious mapping to branches and branches can be
> even shared between various REMOTES etc. (this is changing lately with
> the refs/remotes/ hierarchy, but I think that's still not in wide use).
Remote is usually a repository. It is single URL (although it would be
nice to be able to specify alternate URLs for the same repository, or
for different mirrors of the same repository) representing repository
to fetch from/to push to, together with branches we want to fetch (which
parts of DAG we want to fetch), and local names of those branches,
following fetched contents.
By the way, with introduction of branches and remotes in config file,
you can say:
[branch "localbranch"]
remote = someremote
[remote "someremote"]
fetch = remotebranch:localbranch
push = remotebranch:localbranch
and that would be equivalent to example branches file from the beginning
of this email.
--
Jakub Narebski
^ permalink raw reply
* Re: Shallow clone
From: Sergey Vlasov @ 2006-11-12 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexandre Julliard, Aneesh Kumar K.V, git
In-Reply-To: <7vu015f5av.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]
On Sun, 12 Nov 2006 00:16:40 -0800 Junio C Hamano wrote:
> Alexandre Julliard <julliard@winehq.org> writes:
>
> > There's also a problem with the packing, a clone --depth 1 currently
> > results in a pack that's about 3 times as large as it should be.
>
> That's interesting.
>
> : gitster; git clone -n --depth 1 git://127.0.0.1/git.git victim-001
[...]
> -r--r--r-- 1 junio src 9.5M 2006-11-11 23:52 pack-f5f88d83....pack
>
> Repacking immediately after cloning brings it down to what is
> expected.
>
> : gitster; git repack -a -d -f
[...]
> -rw-rw-r-- 1 junio src 2.6M 2006-11-11 23:53 pack-f5f88d83....pack
This is due to optimization in builtin-pack-objects.c:try_delta():
/*
* We do not bother to try a delta that we discarded
* on an earlier try, but only when reusing delta data.
*/
if (!no_reuse_delta && trg_entry->in_pack &&
trg_entry->in_pack == src_entry->in_pack)
return 0;
After removing this part the shallow pack after clone is 2.6M, as it
should be.
The problem with this optimization is that it is only valid if we are
repacking either the same set of objects as we did earlier, or its
superset. But if we are packing a subset of objects, there will be some
objects in that subset which were delta-compressed in the original pack,
but base objects for that deltas are not included in our subset -
therefore we will be unable to reuse existing deltas, and with that
optimization we will never try to use delta compression for these
objects. (The optimization assumes that if we will try to use delta
compression, we will try mostly the same base objects as we have tried
when we made the existing pack, and therefore will likely get the same
result - which is close to the truth when we are doing "repack -a", but
is badly wrong when we are doing "git-upload-pack" with a large number
of common commits, and therefore are excluding a lot of objects.)
So any partial fetch (shallow or not) from a mostly packed repository
currently results in a suboptimal pack. In fact, the fresh "repack -a
-d -f" is probably the worst case for subsequent fetch (not initial
clone) from that repository - objects for the most recent commit are
most likely to be stored without delta compression, and even if deltas
are used, they are likely in the wrong direction for someone who has an
older version and wants to update it.
> In any case, after this "shallow" stuff, repeated "fetch --depth
> 99" seems to fetch 0 object and 3400 objects alternately, and
> the shallow file alternates between 900 bytes and 11000 bytes.
I confirm this - different numbers, but the same problem...
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Adapt to fuse in kernel 2.6.17
From: Robin Rosenberg @ 2006-11-12 18:45 UTC (permalink / raw)
To: git
From: Robin Rosenberg <robin.rosenberg@dewire.com>
---
Makefile | 2 +-
api-fuse.c | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 8668a03..e80661f 100644
--- a/Makefile
+++ b/Makefile
@@ -5,7 +5,7 @@ GITCFLAGS = '-DSHA1_HEADER=<openssl/sha.
GITLDFLAGS = $(GITDIR)/libgit.a -lcrypto -lz
# What flags are required to build against FUSE
-FUSECFLAGS = '-DFUSE_HEADER="/usr/src/linux-2.6.14.4/include/linux/fuse.h"'
+FUSECFLAGS = '-DFUSE_HEADER="/usr/src/linux-2.6.17-5mdv/include/linux/fuse.h"'
OBJS = gitobj.o api-fuse.o gnode.o topdir.o util.o tagdir.o autotree.o \
gitdir.o main.o worktree.o openfile.o gitworker.o rbtree.o pcbuf.o \
diff --git a/api-fuse.c b/api-fuse.c
index aba5088..28c5da0 100644
--- a/api-fuse.c
+++ b/api-fuse.c
@@ -146,7 +146,7 @@ struct fuse_out {
struct fuse_write_out write;
struct fuse_statfs_out statfs;
struct fuse_getxattr_out getxattr;
- struct fuse_init_in_out init;
+ struct fuse_init_in init;
char read[0];
} arg;
};
@@ -307,7 +307,7 @@ struct fuse_in {
struct fuse_getxattr_in chdr;
char name[0];
} getxattr;
- struct fuse_init_in_out init;
+ struct fuse_init_in init;
/*
* lookup, unlink, rmdir, and removexattr just take a
* string; no per-command header. symlink takes two
@@ -980,7 +980,7 @@ enum service_result api_service_poll(voi
{
union {
struct fuse_in f;
- unsigned char storage[FUSE_MAX_IN];
+ unsigned char storage[FUSE_MIN_READ_BUFFER];
} in;
int rv = read(fuse_fd, in.storage, sizeof(in.storage));
^ permalink raw reply related
* Re: [PATCH] Adapt to fuse in kernel 2.6.17
From: Robin Rosenberg @ 2006-11-12 18:56 UTC (permalink / raw)
To: git
In-Reply-To: <20061112184519.8713.7707.stgit@lathund.dewire.com>
This was a patch to GITFS, which may be somewhat unclear from the Subject
line :)
^ permalink raw reply
* Re: [PATCH] Adapt to fuse in kernel 2.6.17
From: Jeff Garzik @ 2006-11-12 19:31 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200611121956.25481.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> This was a patch to GITFS, which may be somewhat unclear from the Subject
> line :)
I blinked, and I missed it. Where can I find gitfs? I've long thought
about doing something like that myself.
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox