* What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-16 3:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzetjbif.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
It so happens that the topics clearly separated between the ones that are
obviously ready for 1.6.0 and the others that aren't yet as of tonight.
It seems that it is a good time to draw that line and tag -rc0 tomorrow,
after merging the remaining topics in 'next'.
----------------------------------------------------------------
[New Topics]
I could apply these directly to master, but I am just playing it safe.
* sp/maint-index-pack (Tue Jul 15 04:45:34 2008 +0000) 4 commits
+ index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
+ index-pack: Track the object_entry that creates each base_data
+ index-pack: Chain the struct base_data on the stack for traversal
+ index-pack: Refactor base arguments of resolve_delta into a struct
* rs/rebase-checkout-not-so-quiet (Mon Jul 14 14:05:35 2008 -0700) 1 commit
+ git-rebase: report checkout failure
* ag/blame (Wed Jul 16 02:00:58 2008 +0400) 2 commits
+ Do not try to detect move/copy for entries below threshold.
+ Avoid rescanning unchanged entries in search for copies.
This gives a drastic performance improvement to "git-blame -C -C" with
quite straightforward and obvious code change.
* rs/archive (Mon Jul 14 21:22:05 2008 +0200) 6 commits
+ archive: remove extra arguments parsing code
+ archive: unify file attribute handling
+ archive: centralize archive entry writing
+ archive: add baselen member to struct archiver_args
+ add context pointer to read_tree_recursive()
+ archive: remove args member from struct archiver
----------------------------------------------------------------
[Will merge to master soon]
* sb/dashless (Sun Jul 13 15:36:15 2008 +0200) 3 commits
+ Make usage strings dash-less
+ t/: Use "test_must_fail git" instead of "! git"
+ t/test-lib.sh: exit with small negagive int is ok with
test_must_fail
* mv/dashless (Fri Jul 11 02:12:06 2008 +0200) 4 commits
+ make remove-dashes: apply to scripts and programs as well, not
just to builtins
+ git-bisect: use dash-less form on git bisect log
+ t1007-hash-object.sh: use quotes for the test description
+ t0001-init.sh: change confusing directory name
* ls/mailinfo (Sun Jul 13 20:30:12 2008 +0200) 3 commits
+ git-mailinfo: use strbuf's instead of fixed buffers
+ Add some useful functions for strbuf manipulation.
+ Make some strbuf_*() struct strbuf arguments const.
----------------------------------------------------------------
[Graduated to "master"]
* sp/maint-bash-completion-optim (Mon Jul 14 00:22:03 2008 +0000) 1 commit
+ bash completion: Append space after file names have been completed
Early parts were already merged to 'master' and need to be merged down to
maint as well, as this is about a "performance bug" that has been with us
almost forever.
* ag/rewrite_one (Sat Jul 12 22:00:57 2008 +0400) 1 commit
+ Fix quadratic performance in rewrite_one.
* sp/win (Fri Jul 11 18:52:42 2008 +0200) 3 commits
+ We need to check for msys as well as Windows in add--interactive.
+ Convert CR/LF to LF in tag signatures
+ Fixed text file auto-detection: treat EOF character 032 at the end
of file as printable
* js/merge-rr (Sat Jul 12 15:56:19 2008 +0100) 2 commits
+ Move MERGE_RR from .git/rr-cache/ into .git/
+ builtin-rerere: more carefully find conflict markers
* sb/rerere-lib (Wed Jul 9 14:58:57 2008 +0200) 2 commits
+ rerere: Separate libgit and builtin functions
+ builtin-rerere: more carefully find conflict markers
* js/maint-pretty-mailmap (Sat Jul 12 00:28:18 2008 +0100) 1 commit
+ Add pretty format %aN which gives the author name, respecting
.mailmap
* js/more-win (Sun Jul 13 22:31:23 2008 +0200) 3 commits
+ help (Windows): Display HTML in default browser using Windows'
shell API
+ help.c: Add support for htmldir relative to git_exec_path()
+ Move code interpreting path relative to exec-dir to new function
system_path()
* jc/rebase-orig-head (Tue Jul 8 00:12:22 2008 -0400) 2 commits
+ Documentation: mention ORIG_HEAD in am, merge, and rebase
+ Teach "am" and "rebase" to mark the original position with
ORIG_HEAD
* jc/branch-merged (Tue Jul 8 17:55:47 2008 -0700) 3 commits
+ branch --merged/--no-merged: allow specifying arbitrary commit
+ branch --contains: default to HEAD
+ parse-options: add PARSE_OPT_LASTARG_DEFAULT flag
* om/rerere-careful (Mon Jul 7 14:42:48 2008 +0200) 1 commit
+ builtin-rerere: more carefully find conflict markers
* ls/maint-mailinfo-patch-label (Thu Jul 10 23:41:33 2008 +0200) 1 commit
+ git-mailinfo: Fix getting the subject from the in-body [PATCH]
line
* mv/merge-in-c (Mon Jul 14 00:09:41 2008 -0700) 20 commits
+ reduce_heads(): protect from duplicate input
+ reduce_heads(): thinkofix
+ Add a new test for git-merge-resolve
+ t6021: add a new test for git-merge-resolve
+ Teach merge.log to "git-merge" again
+ Build in merge
+ Fix t7601-merge-pull-config.sh on AIX
+ git-commit-tree: make it usable from other builtins
+ Add new test case to ensure git-merge prepends the custom merge
message
+ Add new test case to ensure git-merge reduces octopus parents when
possible
+ Introduce reduce_heads()
+ Introduce get_merge_bases_many()
+ Add new test to ensure git-merge handles more than 25 refs.
+ Introduce get_octopus_merge_bases() in commit.c
+ git-fmt-merge-msg: make it usable from other builtins
+ Move read_cache_unmerged() to read-cache.c
+ Add new test to ensure git-merge handles pull.twohead and
pull.octopus
+ Move parse-options's skip_prefix() to git-compat-util.h
+ Move commit_list_count() to commit.c
+ Move split_cmdline() to alias.c
----------------------------------------------------------------
[On Hold]
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
- Documentation: Improve documentation for git-imap-send(1)
- imap-send.c: more style fixes
- imap-send.c: style fixes
- git-imap-send: Support SSL
- git-imap-send: Allow the program to be run from subdirectories of
a git tree
Some people seem to prefer having this feature available also with gnutls.
If such a patch materializes soon, that would be good, but otherwise I'll
merge this as-is to 'next'. Such an enhancement can be done in-tree on
top of this series.
* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
+ Teach git-merge -X<option> again.
+ Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
+ builtin-merge.c: use parse_options_step() "incremental parsing"
machinery
+ Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
This needs to be merged to master iff/when merge-theirs gets merged,
but I do not think this series is widely supported, so both are on hold.
* jc/merge-theirs (Mon Jun 30 22:18:57 2008 -0700) 5 commits
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
Punting a merge by discarding your own work in conflicting parts but still
salvaging the parts that are cleanly automerged. It is likely that this
will result in nonsense mishmash, but somehow often people want this, so
here they are. The interface to the backends is updated so that you can
say "git merge -Xours -Xsubtree=foo/bar/baz -s recursive other" now.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
- diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
----------------------------------------------------------------
[Stalled/Needs more work]
* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
. cherry: cache patch-ids to avoid repeating work
* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
. gitweb: use new Git::Repo API, and add optional caching
. Add new Git::Repo API
. gitweb: add test suite with Test::WWW::Mechanize::CGI
* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
. Migrate git-am to use git-sequencer
. Add git-sequencer test suite (t3350)
. Add git-sequencer prototype documentation
. Add git-sequencer shell prototype
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
- [BROKEN wrt shallow clones] Ignore graft during object transfer
Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck. This fixes object transfer to ignore grafts.
Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.
* 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
This is for peeling to see what's behind the blamed commit, which may or
may not help applications like gitweb.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2008-07-16 3:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vmykljahl.fsf@gitster.siamese.dyndns.org>
"Merge-in-C" is in, so is "rename .dotest", and remaining Windows bits.
Now it is almost there for 1.6.0-rc0.
* The 'master' branch has these since the last announcement.
Alexander N. Gavrilov (1):
Fix quadratic performance in rewrite_one.
Brian Gernhardt (1):
Documentation: mention ORIG_HEAD in am, merge, and rebase
Ciaran McCreesh (1):
Make git-add -i accept ranges like 7-
Dmitry Kakurin (1):
Fixed text file auto-detection: treat EOF character 032 at the end of
file as printable
Frederik Schwarzer (1):
git-svn: typofix
Ian Katz (1):
tutorial: use prompt with user names in example, to clarify who is doing
what
Johannes Schindelin (6):
Convert CR/LF to LF in tag signatures
Add pretty format %aN which gives the author name, respecting .mailmap
Move MERGE_RR from .git/rr-cache/ into .git/
git-gui: MERGE_RR lives in .git/ directly with newer Git versions
shortlog: support --pretty=format: option
Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
João Abecasis (1):
git-svn: find-rev and rebase for SVN::Mirror repositories
Junio C Hamano (10):
Introduce get_merge_bases_many()
Introduce reduce_heads()
Teach "am" and "rebase" to mark the original position with ORIG_HEAD
branch --contains: default to HEAD
branch --merged/--no-merged: allow specifying arbitrary commit
Teach merge.log to "git-merge" again
Update draft release notes for 1.6.0
reduce_heads(): protect from duplicate input
tutorial: clarify "pull" is "fetch + merge"
Update draft release notes to 1.6.0
Lukas Sandström (1):
git-mailinfo: Fix getting the subject from the in-body [PATCH] line
Mark Levedahl (2):
git-submodule - make "submodule add" more strict, and document it
git-submodule - register submodule URL if adding in place
Mike Pape (1):
We need to check for msys as well as Windows in add--interactive.
Miklos Vajna (15):
Move split_cmdline() to alias.c
Move commit_list_count() to commit.c
Move parse-options's skip_prefix() to git-compat-util.h
Add new test to ensure git-merge handles pull.twohead and pull.octopus
Move read_cache_unmerged() to read-cache.c
git-fmt-merge-msg: make it usable from other builtins
Introduce get_octopus_merge_bases() in commit.c
Add new test to ensure git-merge handles more than 25 refs.
Add new test case to ensure git-merge reduces octopus parents when
possible
Add new test case to ensure git-merge prepends the custom merge message
git-commit-tree: make it usable from other builtins
Fix t7601-merge-pull-config.sh on AIX
Build in merge
t6021: add a new test for git-merge-resolve
Add a new test for git-merge-resolve
Nicolas Pitre (1):
restore legacy behavior for read_sha1_file()
Olivier Marin (1):
builtin-rerere: more carefully find conflict markers
Pavel Roskin (1):
t9600: allow testing with cvsps 2.2, including beta versions
Pierre Habouzit (1):
parse-options: add PARSE_OPT_LASTARG_DEFAULT flag
Shawn O. Pearce (3):
bash completion: Append space after file names have been completed
bash completion: Resolve git show ref:path<tab> losing ref: portion
bash completion: Remove dashed command completion support
Soeren Finster (1):
git-gui: Exit shortcut in MacOSX repaired
Steffen Prohaska (3):
Move code interpreting path relative to exec-dir to new function
system_path()
help.c: Add support for htmldir relative to git_exec_path()
help (Windows): Display HTML in default browser using Windows' shell API
Stephan Beyer (1):
rerere: Separate libgit and builtin functions
Sverre Hvammen Johansen (1):
reduce_heads(): thinkofix
Teemu Likonen (1):
bash: Add long option completion for 'git send-email'
^ permalink raw reply
* Re: [PATCH] setup.py: don't try to import stgit.run before the python version check
From: Karl Hasselström @ 2008-07-16 4:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Catalin Marinas, Thomas Rast, Petr Baudis, Git Mailing List
In-Reply-To: <1215806972-18713-2-git-send-email-vmiklos@frugalware.org>
On 2008-07-11 22:09:32 +0200, Miklos Vajna wrote:
> @@ -68,6 +67,8 @@ if sys.argv[1] in ['install', 'build']:
> __check_python_version()
> __check_git_version()
>
> +from stgit.run import Run
> +
> # ensure readable template files
> old_mask = os.umask(0022)
>
I had to modify the second hunk to make it work:
@@ -37,6 +36,7 @@ def __check_python_version():
def __check_git_version():
"""Check the minimum GIT version
"""
+ from stgit.run import Run
gitver = Run('git', '--version').output_one_line().split()[2]
if not __check_min_version(git_min_ver, gitver):
print >> sys.stderr, 'GIT version %s or newer required. Found %s' \
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Jeff King @ 2008-07-16 5:18 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git
In-Reply-To: <1215877672-17049-1-git-send-email-s-beyer@gmx.net>
On Sat, Jul 12, 2008 at 05:47:51PM +0200, Stephan Beyer wrote:
> The test_must_fail function in test-lib.sh has been designed
> to distinguish segmentation faults from controlled errors.
> But in the current implementation this only works if a git
> command does not return a small negative value, like -1, -2
> or -3. But some git commands do.
This is probably a fine protective measure, and it looks like Junio has
already applied it. But shouldn't any git commands returning such values
be fixed? Which commands return such bogus error codes?
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: Let test_must_fail fail on signals only
From: Junio C Hamano @ 2008-07-16 5:54 UTC (permalink / raw)
To: Jeff King; +Cc: Stephan Beyer, git
In-Reply-To: <20080716051829.GB4030@segfault.peff.net>
Jeff King <peff@peff.net> writes:
> This is probably a fine protective measure, and it looks like Junio has
> already applied it. But shouldn't any git commands returning such values
> be fixed? Which commands return such bogus error codes?
Anything that returns error() from its cmd_xxx() routine, for example,
would end up exiting with (-1). Is it "such bogus" error codes, though?
I am somewhat tired tonight, so I'll leave it up to the list to do the
grepping and go to bed ;-)
^ permalink raw reply
* Re: MSysGit Stability
From: Vincent Kergonna @ 2008-07-16 5:22 UTC (permalink / raw)
To: Joe Fiorini; +Cc: git
In-Reply-To: <73fd69b50807151458u22a383a3l343779e47f4161fa@mail.gmail.com>
On Jul 15, 2008, at 23:58 , Joe Fiorini wrote:
> Hey all,
Hi,
>
>
> I'm going to be working with a small dev shop in the near future and
> we would like to use Git for our project. Two of us are on Macs, but
> the other is on Windows. I know the options are MSysGit or Git
> through cygwin. I'm curious which is better to use and if MSysGit is
> even stable yet. Does anyone have experience running Git on Windows?
> Any experiences you can share? Is MSysGit ready yet or should we
> wait?
We are using MSysGit at work. We've had no problem with it so far
(using it for about four months). I think you can safely use MSysGit
on Windows. Since it comes with a dedicated installer It is easier to
install/upgrade than the cygwin version.
>
>
> Thanks all!
> Joe
>
Vincent
> --
> joe fiorini
> http://www.faithfulgeek.org
> // freelancing & knowledge sharing
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/5] add pack index v2 reading capability to git v1.4.4.4
From: Nicolas Pitre @ 2008-07-16 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Well, here it is. I know I know, I'm just too nice. Oh well...
This is the minimum set of backported patches on top of git v1.4.4.4
to allow it to cope with pack index version 2.
Junio: if you could just apply them, tag the result as v1.4.4.5 and
push it out then at that point it simply will be up to Debian to make
it available as a "major usability fix".
Nicolas
^ permalink raw reply
* [PATCH 1/5] clean up pack index handling a bit
From: Nicolas Pitre @ 2008-07-16 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1216189899-14279-1-git-send-email-nico@cam.org>
Especially with the new index format to come, it is more appropriate
to encapsulate more into check_packed_git_idx() and assume less of the
index format in struct packed_git.
To that effect, the index_base is renamed to index_data with void * type
so it is not used directly but other pointers initialized with it. This
allows for a couple pointer cast removal, as well as providing a better
generic name to grep for when adding support for new index versions or
formats.
And index_data is declared const too while at it.
(based on commit 4287307833a7c67b09973fc1023311e473f830b2)
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 14 ++++---
cache.h | 5 ++-
pack-check.c | 8 ++--
pack-redundant.c | 30 ++++++++-------
pack.h | 28 ++++++++++++++
sha1_file.c | 94 ++++++++++++++++++++++++++----------------------
6 files changed, 110 insertions(+), 69 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 69e5dd3..ae051f9 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -170,11 +170,12 @@ static void prepare_pack_revindex(struct pack_revindex *rix)
struct packed_git *p = rix->p;
int num_ent = num_packed_objects(p);
int i;
- void *index = p->index_base + 256;
+ const char *index = p->index_data;
+ index += 4 * 256;
rix->revindex = xmalloc(sizeof(*rix->revindex) * (num_ent + 1));
for (i = 0; i < num_ent; i++) {
- unsigned int hl = *((unsigned int *)((char *) index + 24*i));
+ uint32_t hl = *((uint32_t *)(index + 24 * i));
rix->revindex[i].offset = ntohl(hl);
rix->revindex[i].nr = i;
}
@@ -222,11 +223,11 @@ static unsigned long find_packed_object_size(struct packed_git *p,
return entry[1].offset - ofs;
}
-static unsigned char *find_packed_object_name(struct packed_git *p,
- unsigned long ofs)
+static const unsigned char *find_packed_object_name(struct packed_git *p,
+ unsigned long ofs)
{
struct revindex_entry *entry = find_packed_object(p, ofs);
- return (unsigned char *)(p->index_base + 256) + 24 * entry->nr + 4;
+ return ((unsigned char *)p->index_data) + 4 * 256 + 24 * entry->nr + 4;
}
static void *delta_against(void *buf, unsigned long size, struct object_entry *entry)
@@ -959,7 +960,8 @@ static void check_object(struct object_entry *entry)
* delta.
*/
if (!no_reuse_delta) {
- unsigned char c, *base_name;
+ unsigned char c;
+ const unsigned char *base_name;
unsigned long ofs;
/* there is at least 20 bytes left in the pack */
switch (entry->in_pack_type) {
diff --git a/cache.h b/cache.h
index a0e9727..cc8e84e 100644
--- a/cache.h
+++ b/cache.h
@@ -334,8 +334,9 @@ extern struct packed_git {
struct packed_git *next;
unsigned long index_size;
unsigned long pack_size;
- unsigned int *index_base;
+ const void *index_data;
void *pack_base;
+ int index_version;
unsigned int pack_last_used;
unsigned int pack_use_cnt;
int pack_local;
@@ -374,7 +375,7 @@ extern int server_supports(const char *feature);
extern struct packed_git *parse_pack_index(unsigned char *sha1);
extern struct packed_git *parse_pack_index_file(const unsigned char *sha1,
- char *idx_path);
+ const char *idx_path);
extern void prepare_packed_git(void);
extern void reprepare_packed_git(void);
diff --git a/pack-check.c b/pack-check.c
index 8e123b7..7db44e9 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -6,7 +6,7 @@
static int verify_packfile(struct packed_git *p)
{
unsigned long index_size = p->index_size;
- void *index_base = p->index_base;
+ const unsigned char *index_base = p->index_data;
SHA_CTX ctx;
unsigned char sha1[20];
struct pack_header *hdr;
@@ -42,7 +42,7 @@ static int verify_packfile(struct packed_git *p)
if (hashcmp(sha1, (unsigned char *)(p->pack_base) + p->pack_size - 20))
return error("Packfile %s SHA1 mismatch with itself",
p->pack_name);
- if (hashcmp(sha1, (unsigned char *)index_base + index_size - 40))
+ if (hashcmp(sha1, index_base + index_size - 40))
return error("Packfile %s SHA1 mismatch with idx",
p->pack_name);
@@ -136,7 +136,7 @@ static void show_pack_info(struct packed_git *p)
int verify_pack(struct packed_git *p, int verbose)
{
unsigned long index_size = p->index_size;
- void *index_base = p->index_base;
+ const unsigned char *index_base = p->index_data;
SHA_CTX ctx;
unsigned char sha1[20];
int ret;
@@ -146,7 +146,7 @@ int verify_pack(struct packed_git *p, int verbose)
SHA1_Init(&ctx);
SHA1_Update(&ctx, index_base, index_size - 20);
SHA1_Final(sha1, &ctx);
- if (hashcmp(sha1, (unsigned char *)index_base + index_size - 20))
+ if (hashcmp(sha1, index_base + index_size - 20))
ret = error("Packfile index for %s SHA1 mismatch",
p->pack_name);
diff --git a/pack-redundant.c b/pack-redundant.c
index edb5524..83812f3 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -17,7 +17,7 @@ static int load_all_packs, verbose, alt_odb;
struct llist_item {
struct llist_item *next;
- unsigned char *sha1;
+ const unsigned char *sha1;
};
static struct llist {
struct llist_item *front;
@@ -104,9 +104,9 @@ static struct llist * llist_copy(struct llist *list)
return ret;
}
-static inline struct llist_item * llist_insert(struct llist *list,
- struct llist_item *after,
- unsigned char *sha1)
+static inline struct llist_item *llist_insert(struct llist *list,
+ struct llist_item *after,
+ const unsigned char *sha1)
{
struct llist_item *new = llist_item_get();
new->sha1 = sha1;
@@ -128,12 +128,14 @@ static inline struct llist_item * llist_insert(struct llist *list,
return new;
}
-static inline struct llist_item *llist_insert_back(struct llist *list, unsigned char *sha1)
+static inline struct llist_item *llist_insert_back(struct llist *list,
+ const unsigned char *sha1)
{
return llist_insert(list, list->back, sha1);
}
-static inline struct llist_item *llist_insert_sorted_unique(struct llist *list, unsigned char *sha1, struct llist_item *hint)
+static inline struct llist_item *llist_insert_sorted_unique(struct llist *list,
+ const unsigned char *sha1, struct llist_item *hint)
{
struct llist_item *prev = NULL, *l;
@@ -246,12 +248,12 @@ static struct pack_list * pack_list_difference(const struct pack_list *A,
static void cmp_two_packs(struct pack_list *p1, struct pack_list *p2)
{
int p1_off, p2_off;
- unsigned char *p1_base, *p2_base;
+ const unsigned char *p1_base, *p2_base;
struct llist_item *p1_hint = NULL, *p2_hint = NULL;
p1_off = p2_off = 256 * 4 + 4;
- p1_base = (unsigned char *) p1->pack->index_base;
- p2_base = (unsigned char *) p2->pack->index_base;
+ p1_base = p1->pack->index_data;
+ p2_base = p2->pack->index_data;
while (p1_off <= p1->pack->index_size - 3 * 20 &&
p2_off <= p2->pack->index_size - 3 * 20)
@@ -351,11 +353,11 @@ static size_t sizeof_union(struct packed_git *p1, struct packed_git *p2)
{
size_t ret = 0;
int p1_off, p2_off;
- unsigned char *p1_base, *p2_base;
+ const unsigned char *p1_base, *p2_base;
p1_off = p2_off = 256 * 4 + 4;
- p1_base = (unsigned char *)p1->index_base;
- p2_base = (unsigned char *)p2->index_base;
+ p1_base = p1->index_data;
+ p2_base = p2->index_data;
while (p1_off <= p1->index_size - 3 * 20 &&
p2_off <= p2->index_size - 3 * 20)
@@ -534,7 +536,7 @@ static struct pack_list * add_pack(struct packed_git *p)
{
struct pack_list l;
size_t off;
- unsigned char *base;
+ const unsigned char *base;
if (!p->pack_local && !(alt_odb || verbose))
return NULL;
@@ -543,7 +545,7 @@ static struct pack_list * add_pack(struct packed_git *p)
llist_init(&l.all_objects);
off = 256 * 4 + 4;
- base = (unsigned char *)p->index_base;
+ base = p->index_data;
while (off <= p->index_size - 3 * 20) {
llist_insert_back(l.all_objects, base + off);
off += 24;
diff --git a/pack.h b/pack.h
index 4814800..e0051fd 100644
--- a/pack.h
+++ b/pack.h
@@ -15,5 +15,33 @@ struct pack_header {
unsigned int hdr_entries;
};
+/*
+ * The first four bytes of index formats later than version 1 should
+ * start with this signature, as all older git binaries would find this
+ * value illegal and abort reading the file.
+ *
+ * This is the case because the number of objects in a packfile
+ * cannot exceed 1,431,660,000 as every object would need at least
+ * 3 bytes of data and the overall packfile cannot exceed 4 GiB with
+ * version 1 of the index file due to the offsets limited to 32 bits.
+ * Clearly the signature exceeds this maximum.
+ *
+ * Very old git binaries will also compare the first 4 bytes to the
+ * next 4 bytes in the index and abort with a "non-monotonic index"
+ * error if the second 4 byte word is smaller than the first 4
+ * byte word. This would be true in the proposed future index
+ * format as idx_signature would be greater than idx_version.
+ */
+#define PACK_IDX_SIGNATURE 0xff744f63 /* "\377tOc" */
+
+/*
+ * Packed object index header
+ */
+struct pack_idx_header {
+ uint32_t idx_signature;
+ uint32_t idx_version;
+};
+
+
extern int verify_pack(struct packed_git *, int);
#endif
diff --git a/sha1_file.c b/sha1_file.c
index 09456d2..df31462 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -402,15 +402,15 @@ static int pack_used_ctr;
static unsigned long pack_mapped;
struct packed_git *packed_git;
-static int check_packed_git_idx(const char *path, unsigned long *idx_size_,
- void **idx_map_)
+static int check_packed_git_idx(const char *path, struct packed_git *p)
{
void *idx_map;
- unsigned int *index;
+ struct pack_idx_header *hdr;
unsigned long idx_size;
- int nr, i;
+ unsigned int nr, i, *index;
int fd = open(path, O_RDONLY);
struct stat st;
+
if (fd < 0)
return -1;
if (fstat(fd, &st)) {
@@ -423,14 +423,21 @@ static int check_packed_git_idx(const char *path, unsigned long *idx_size_,
if (idx_map == MAP_FAILED)
return -1;
- index = idx_map;
- *idx_map_ = idx_map;
- *idx_size_ = idx_size;
+ /* a future index format would start with this, as older git
+ * binaries would fail the non-monotonic index check below.
+ * give a nicer warning to the user if we can.
+ */
+ hdr = idx_map;
+ if (hdr->idx_signature == htonl(PACK_IDX_SIGNATURE)) {
+ munmap(idx_map, idx_size);
+ return error("index file %s is a newer version"
+ " and is not supported by this binary"
+ " (try upgrading GIT to a newer version)",
+ path);
+ }
- /* check index map */
- if (idx_size < 4*256 + 20 + 20)
- return error("index file too small");
nr = 0;
+ index = idx_map;
for (i = 0; i < 256; i++) {
unsigned int n = ntohl(index[i]);
if (n < nr)
@@ -448,6 +455,9 @@ static int check_packed_git_idx(const char *path, unsigned long *idx_size_,
if (idx_size != 4*256 + nr * 24 + 20 + 20)
return error("wrong index file size");
+ p->index_version = 1;
+ p->index_data = idx_map;
+ p->index_size = idx_size;
return 0;
}
@@ -521,7 +531,7 @@ int use_packed_git(struct packed_git *p)
/* Check if the pack file matches with the index file.
* this is cheap.
*/
- if (hashcmp((unsigned char *)(p->index_base) +
+ if (hashcmp((unsigned char *)(p->index_data) +
p->index_size - 40,
(unsigned char *)p->pack_base +
p->pack_size - 20)) {
@@ -536,35 +546,34 @@ int use_packed_git(struct packed_git *p)
struct packed_git *add_packed_git(char *path, int path_len, int local)
{
struct stat st;
- struct packed_git *p;
- unsigned long idx_size;
- void *idx_map;
- unsigned char sha1[20];
+ struct packed_git *p = xmalloc(sizeof(*p) + path_len + 2);
- if (check_packed_git_idx(path, &idx_size, &idx_map))
+ /*
+ * Make sure a corresponding .pack file exists and that
+ * the index looks sane.
+ */
+ path_len -= strlen(".idx");
+ if (path_len < 1)
return NULL;
-
- /* do we have a corresponding .pack file? */
- strcpy(path + path_len - 4, ".pack");
- if (stat(path, &st) || !S_ISREG(st.st_mode)) {
- munmap(idx_map, idx_size);
+ memcpy(p->pack_name, path, path_len);
+ strcpy(p->pack_name + path_len, ".pack");
+ if (stat(p->pack_name, &st) || !S_ISREG(st.st_mode) ||
+ check_packed_git_idx(path, p)) {
+ free(p);
return NULL;
}
+
/* ok, it looks sane as far as we can check without
* actually mapping the pack file.
*/
- p = xmalloc(sizeof(*p) + path_len + 2);
- strcpy(p->pack_name, path);
- p->index_size = idx_size;
p->pack_size = st.st_size;
- p->index_base = idx_map;
p->next = NULL;
p->pack_base = NULL;
p->pack_last_used = 0;
p->pack_use_cnt = 0;
p->pack_local = local;
- if ((path_len > 44) && !get_sha1_hex(path + path_len - 44, sha1))
- hashcpy(p->sha1, sha1);
+ if (path_len < 40 || get_sha1_hex(path + path_len - 40, p->sha1))
+ hashclr(p->sha1);
return p;
}
@@ -574,23 +583,19 @@ struct packed_git *parse_pack_index(unsigned char *sha1)
return parse_pack_index_file(sha1, path);
}
-struct packed_git *parse_pack_index_file(const unsigned char *sha1, char *idx_path)
+struct packed_git *parse_pack_index_file(const unsigned char *sha1,
+ const char *idx_path)
{
- struct packed_git *p;
- unsigned long idx_size;
- void *idx_map;
- char *path;
+ const char *path = sha1_pack_name(sha1);
+ struct packed_git *p = xmalloc(sizeof(*p) + strlen(path) + 2);
- if (check_packed_git_idx(idx_path, &idx_size, &idx_map))
+ if (check_packed_git_idx(idx_path, p)) {
+ free(p);
return NULL;
+ }
- path = sha1_pack_name(sha1);
-
- p = xmalloc(sizeof(*p) + strlen(path) + 2);
strcpy(p->pack_name, path);
- p->index_size = idx_size;
p->pack_size = 0;
- p->index_base = idx_map;
p->next = NULL;
p->pack_base = NULL;
p->pack_last_used = 0;
@@ -1175,24 +1180,27 @@ int num_packed_objects(const struct packed_git *p)
int nth_packed_object_sha1(const struct packed_git *p, int n,
unsigned char* sha1)
{
- void *index = p->index_base + 256;
+ const unsigned char *index = p->index_data;
+ index += 4 * 256;
if (n < 0 || num_packed_objects(p) <= n)
return -1;
- hashcpy(sha1, (unsigned char *) index + (24 * n) + 4);
+ hashcpy(sha1, index + 24 * n + 4);
return 0;
}
unsigned long find_pack_entry_one(const unsigned char *sha1,
struct packed_git *p)
{
- unsigned int *level1_ofs = p->index_base;
+ const unsigned int *level1_ofs = p->index_data;
int hi = ntohl(level1_ofs[*sha1]);
int lo = ((*sha1 == 0x0) ? 0 : ntohl(level1_ofs[*sha1 - 1]));
- void *index = p->index_base + 256;
+ const unsigned char *index = p->index_data;
+
+ index += 4 * 256;
do {
int mi = (lo + hi) / 2;
- int cmp = hashcmp((unsigned char *)index + (24 * mi) + 4, sha1);
+ int cmp = hashcmp(index + 24 * mi + 4, sha1);
if (!cmp)
return ntohl(*((unsigned int *) ((char *) index + (24 * mi))));
if (cmp > 0)
--
1.5.6.3.499.geae9
^ permalink raw reply related
* [PATCH 2/5] clean up and optimize nth_packed_object_sha1() usage
From: Nicolas Pitre @ 2008-07-16 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1216189899-14279-2-git-send-email-nico@cam.org>
Let's avoid the open coded pack index reference in pack-object and use
nth_packed_object_sha1() instead. This will help encapsulating index
format differences in one place.
And while at it there is no reason to copy SHA1's over and over while a
direct pointer to it in the index will do just fine.
(based on commit d72308e01c5977177cda0aed06cfeee9192e1247)
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 2 +-
cache.h | 2 +-
fsck-objects.c | 9 +++------
pack-check.c | 11 +++++++----
sha1_file.c | 11 +++++------
sha1_name.c | 16 ++++++++--------
6 files changed, 25 insertions(+), 26 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index ae051f9..4c345d5 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -227,7 +227,7 @@ static const unsigned char *find_packed_object_name(struct packed_git *p,
unsigned long ofs)
{
struct revindex_entry *entry = find_packed_object(p, ofs);
- return ((unsigned char *)p->index_data) + 4 * 256 + 24 * entry->nr + 4;
+ return nth_packed_object_sha1(p, entry->nr);
}
static void *delta_against(void *buf, unsigned long size, struct object_entry *entry)
diff --git a/cache.h b/cache.h
index cc8e84e..191c738 100644
--- a/cache.h
+++ b/cache.h
@@ -388,7 +388,7 @@ extern int use_packed_git(struct packed_git *);
extern void unuse_packed_git(struct packed_git *);
extern struct packed_git *add_packed_git(char *, int, int);
extern int num_packed_objects(const struct packed_git *p);
-extern int nth_packed_object_sha1(const struct packed_git *, int, unsigned char*);
+extern const unsigned char *nth_packed_object_sha1(const struct packed_git *, unsigned int);
extern unsigned long find_pack_entry_one(const unsigned char *, struct packed_git *);
extern void *unpack_entry_gently(struct packed_git *, unsigned long, char *, unsigned long *);
extern unsigned long unpack_object_header_gently(const unsigned char *buf, unsigned long len, enum object_type *type, unsigned long *sizep);
diff --git a/fsck-objects.c b/fsck-objects.c
index 46b628c..f6015a8 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -289,7 +289,7 @@ static int fsck_tag(struct tag *tag)
return 0;
}
-static int fsck_sha1(unsigned char *sha1)
+static int fsck_sha1(const unsigned char *sha1)
{
struct object *obj = parse_object(sha1);
if (!obj)
@@ -551,11 +551,8 @@ int main(int argc, char **argv)
for (p = packed_git; p; p = p->next) {
int num = num_packed_objects(p);
- for (i = 0; i < num; i++) {
- unsigned char sha1[20];
- nth_packed_object_sha1(p, i, sha1);
- fsck_sha1(sha1);
- }
+ for (i = 0; i < num; i++)
+ fsck_sha1(nth_packed_object_sha1(p, i));
}
}
diff --git a/pack-check.c b/pack-check.c
index 7db44e9..11f6ed2 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -51,12 +51,13 @@ static int verify_packfile(struct packed_git *p)
* we do not do scan-streaming check on the pack file.
*/
for (i = err = 0; i < nr_objects; i++) {
- unsigned char sha1[20];
+ const unsigned char *sha1;
void *data;
char type[20];
unsigned long size, offset;
- if (nth_packed_object_sha1(p, i, sha1))
+ sha1 = nth_packed_object_sha1(p, i);
+ if (!sha1)
die("internal error pack-check nth-packed-object");
offset = find_pack_entry_one(sha1, p);
if (!offset)
@@ -93,14 +94,16 @@ static void show_pack_info(struct packed_git *p)
memset(chain_histogram, 0, sizeof(chain_histogram));
for (i = 0; i < nr_objects; i++) {
- unsigned char sha1[20], base_sha1[20];
+ const unsigned char *sha1;
+ unsigned char base_sha1[20];
char type[20];
unsigned long size;
unsigned long store_size;
unsigned long offset;
unsigned int delta_chain_length;
- if (nth_packed_object_sha1(p, i, sha1))
+ sha1 = nth_packed_object_sha1(p, i);
+ if (!sha1)
die("internal error pack-check nth-packed-object");
offset = find_pack_entry_one(sha1, p);
if (!offset)
diff --git a/sha1_file.c b/sha1_file.c
index df31462..b4c5209 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1177,15 +1177,14 @@ int num_packed_objects(const struct packed_git *p)
return (p->index_size - 20 - 20 - 4*256) / 24;
}
-int nth_packed_object_sha1(const struct packed_git *p, int n,
- unsigned char* sha1)
+const unsigned char *nth_packed_object_sha1(const struct packed_git *p,
+ unsigned int n)
{
const unsigned char *index = p->index_data;
index += 4 * 256;
- if (n < 0 || num_packed_objects(p) <= n)
- return -1;
- hashcpy(sha1, index + 24 * n + 4);
- return 0;
+ if (num_packed_objects(p) <= n)
+ return NULL;
+ return index + 24 * n + 4;
}
unsigned long find_pack_entry_one(const unsigned char *sha1,
diff --git a/sha1_name.c b/sha1_name.c
index 6d7cd78..d083096 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -71,7 +71,7 @@ static int match_sha(unsigned len, const unsigned char *a, const unsigned char *
static int find_short_packed_object(int len, const unsigned char *match, unsigned char *sha1)
{
struct packed_git *p;
- unsigned char found_sha1[20];
+ const unsigned char *found_sha1 = NULL;
int found = 0;
prepare_packed_git();
@@ -80,10 +80,10 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
unsigned first = 0, last = num;
while (first < last) {
unsigned mid = (first + last) / 2;
- unsigned char now[20];
+ const unsigned char *now;
int cmp;
- nth_packed_object_sha1(p, mid, now);
+ now = nth_packed_object_sha1(p, mid);
cmp = hashcmp(match, now);
if (!cmp) {
first = mid;
@@ -96,14 +96,14 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
last = mid;
}
if (first < num) {
- unsigned char now[20], next[20];
- nth_packed_object_sha1(p, first, now);
+ const unsigned char *now, *next;
+ now = nth_packed_object_sha1(p, first);
if (match_sha(len, match, now)) {
- if (nth_packed_object_sha1(p, first+1, next) ||
- !match_sha(len, match, next)) {
+ next = nth_packed_object_sha1(p, first+1);
+ if (!next|| !match_sha(len, match, next)) {
/* unique within this pack */
if (!found) {
- hashcpy(found_sha1, now);
+ found_sha1 = now;
found++;
}
else if (hashcmp(found_sha1, now)) {
--
1.5.6.3.499.geae9
^ permalink raw reply related
* [PATCH 3/5] get rid of num_packed_objects()
From: Nicolas Pitre @ 2008-07-16 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1216189899-14279-3-git-send-email-nico@cam.org>
The coming index format change doesn't allow for the number of objects
to be determined from the size of the index file directly. Instead, Let's
initialize a field in the packed_git structure with the object count when
the index is validated since the count is always known at that point.
(based on commit 57059091fad25427bce9b3d47e073ce0518d164b)
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-count-objects.c | 2 +-
builtin-pack-objects.c | 4 ++--
cache.h | 2 +-
fsck-objects.c | 2 +-
pack-check.c | 4 ++--
sha1_file.c | 9 ++-------
sha1_name.c | 2 +-
7 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index 73c5982..7795a63 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -110,7 +110,7 @@ int cmd_count_objects(int ac, const char **av, const char *prefix)
for (p = packed_git; p; p = p->next) {
if (!p->pack_local)
continue;
- packed += num_packed_objects(p);
+ packed += p->num_objects;
}
printf("count: %lu\n", loose);
printf("size: %lu\n", loose_size / 2);
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 4c345d5..b9c3da2 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -168,7 +168,7 @@ static int cmp_offset(const void *a_, const void *b_)
static void prepare_pack_revindex(struct pack_revindex *rix)
{
struct packed_git *p = rix->p;
- int num_ent = num_packed_objects(p);
+ int num_ent = p->num_objects;
int i;
const char *index = p->index_data;
@@ -202,7 +202,7 @@ static struct revindex_entry * find_packed_object(struct packed_git *p,
prepare_pack_revindex(rix);
revindex = rix->revindex;
lo = 0;
- hi = num_packed_objects(p) + 1;
+ hi = p->num_objects + 1;
do {
int mi = (lo + hi) / 2;
if (revindex[mi].offset == ofs) {
diff --git a/cache.h b/cache.h
index 191c738..1bcc7c1 100644
--- a/cache.h
+++ b/cache.h
@@ -336,6 +336,7 @@ extern struct packed_git {
unsigned long pack_size;
const void *index_data;
void *pack_base;
+ unsigned int num_objects;
int index_version;
unsigned int pack_last_used;
unsigned int pack_use_cnt;
@@ -387,7 +388,6 @@ extern struct packed_git *find_sha1_pack(const unsigned char *sha1,
extern int use_packed_git(struct packed_git *);
extern void unuse_packed_git(struct packed_git *);
extern struct packed_git *add_packed_git(char *, int, int);
-extern int num_packed_objects(const struct packed_git *p);
extern const unsigned char *nth_packed_object_sha1(const struct packed_git *, unsigned int);
extern unsigned long find_pack_entry_one(const unsigned char *, struct packed_git *);
extern void *unpack_entry_gently(struct packed_git *, unsigned long, char *, unsigned long *);
diff --git a/fsck-objects.c b/fsck-objects.c
index f6015a8..bdbca54 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -550,7 +550,7 @@ int main(int argc, char **argv)
verify_pack(p, 0);
for (p = packed_git; p; p = p->next) {
- int num = num_packed_objects(p);
+ int num = p->num_objects;
for (i = 0; i < num; i++)
fsck_sha1(nth_packed_object_sha1(p, i));
}
diff --git a/pack-check.c b/pack-check.c
index 11f6ed2..578f59e 100644
--- a/pack-check.c
+++ b/pack-check.c
@@ -22,10 +22,10 @@ static int verify_packfile(struct packed_git *p)
return error("Packfile version %d unsupported",
ntohl(hdr->hdr_version));
nr_objects = ntohl(hdr->hdr_entries);
- if (num_packed_objects(p) != nr_objects)
+ if (p->num_objects != nr_objects)
return error("Packfile claims to have %d objects, "
"while idx size expects %d", nr_objects,
- num_packed_objects(p));
+ p->num_objects);
/* Check integrity of pack data with its SHA-1 checksum */
SHA1_Init(&ctx);
diff --git a/sha1_file.c b/sha1_file.c
index b4c5209..9c40e7e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -458,6 +458,7 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
p->index_version = 1;
p->index_data = idx_map;
p->index_size = idx_size;
+ p->num_objects = nr;
return 0;
}
@@ -1171,18 +1172,12 @@ void *unpack_entry_gently(struct packed_git *p, unsigned long offset,
}
}
-int num_packed_objects(const struct packed_git *p)
-{
- /* See check_packed_git_idx() */
- return (p->index_size - 20 - 20 - 4*256) / 24;
-}
-
const unsigned char *nth_packed_object_sha1(const struct packed_git *p,
unsigned int n)
{
const unsigned char *index = p->index_data;
index += 4 * 256;
- if (num_packed_objects(p) <= n)
+ if (n >= p->num_objects)
return NULL;
return index + 24 * n + 4;
}
diff --git a/sha1_name.c b/sha1_name.c
index d083096..be9be52 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -76,7 +76,7 @@ static int find_short_packed_object(int len, const unsigned char *match, unsigne
prepare_packed_git();
for (p = packed_git; p && found < 2; p = p->next) {
- unsigned num = num_packed_objects(p);
+ unsigned num = p->num_objects;
unsigned first = 0, last = num;
while (first < last) {
unsigned mid = (first + last) / 2;
--
1.5.6.3.499.geae9
^ permalink raw reply related
* [PATCH 5/5] sha1_file.c: learn about index version 2
From: Nicolas Pitre @ 2008-07-16 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1216189899-14279-5-git-send-email-nico@cam.org>
This allows for pack index v2 to be used. On 32-bit machines the
maximum pack size is 2GB. To lift this limitation just use a newer
git version.
(based on commit 74e34e1fca2ed9998581cc94073bc2dd28bbb8f3)
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
sha1_file.c | 117 +++++++++++++++++++++++++++++++++++++++++++++--------------
1 files changed, 89 insertions(+), 28 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 9c40e7e..927ac06 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -407,7 +407,7 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
void *idx_map;
struct pack_idx_header *hdr;
unsigned long idx_size;
- unsigned int nr, i, *index;
+ unsigned int version, nr, i, *index;
int fd = open(path, O_RDONLY);
struct stat st;
@@ -423,21 +423,23 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
if (idx_map == MAP_FAILED)
return -1;
- /* a future index format would start with this, as older git
- * binaries would fail the non-monotonic index check below.
- * give a nicer warning to the user if we can.
- */
hdr = idx_map;
if (hdr->idx_signature == htonl(PACK_IDX_SIGNATURE)) {
- munmap(idx_map, idx_size);
- return error("index file %s is a newer version"
- " and is not supported by this binary"
- " (try upgrading GIT to a newer version)",
- path);
- }
+ version = ntohl(hdr->idx_version);
+ if (version < 2 || version > 2) {
+ munmap(idx_map, idx_size);
+ return error("index file %s is version %d"
+ " and is not supported by this binary"
+ " (try upgrading GIT to a newer version)",
+ path, version);
+ }
+ } else
+ version = 1;
nr = 0;
index = idx_map;
+ if (version > 1)
+ index += 2; /* skip index header */
for (i = 0; i < 256; i++) {
unsigned int n = ntohl(index[i]);
if (n < nr)
@@ -445,17 +447,47 @@ static int check_packed_git_idx(const char *path, struct packed_git *p)
nr = n;
}
- /*
- * Total size:
- * - 256 index entries 4 bytes each
- * - 24-byte entries * nr (20-byte sha1 + 4-byte offset)
- * - 20-byte SHA1 of the packfile
- * - 20-byte SHA1 file checksum
- */
- if (idx_size != 4*256 + nr * 24 + 20 + 20)
- return error("wrong index file size");
+ if (version == 1) {
+ /*
+ * Total size:
+ * - 256 index entries 4 bytes each
+ * - 24-byte entries * nr (20-byte sha1 + 4-byte offset)
+ * - 20-byte SHA1 of the packfile
+ * - 20-byte SHA1 file checksum
+ */
+ if (idx_size != 4*256 + nr * 24 + 20 + 20) {
+ munmap(idx_map, idx_size);
+ return error("wrong index file size in %s", path);
+ }
+ } else if (version == 2) {
+ /*
+ * Minimum size:
+ * - 8 bytes of header
+ * - 256 index entries 4 bytes each
+ * - 20-byte sha1 entry * nr
+ * - 4-byte crc entry * nr
+ * - 4-byte offset entry * nr
+ * - 20-byte SHA1 of the packfile
+ * - 20-byte SHA1 file checksum
+ * And after the 4-byte offset table might be a
+ * variable sized table containing 8-byte entries
+ * for offsets larger than 2^31.
+ */
+ unsigned long min_size = 8 + 4*256 + nr*(20 + 4 + 4) + 20 + 20;
+ if (idx_size < min_size || idx_size > min_size + (nr - 1)*8) {
+ munmap(idx_map, idx_size);
+ return error("wrong index file size in %s", path);
+ }
+ if (idx_size != min_size) {
+ /* make sure we can deal with large pack offsets */
+ if (sizeof(unsigned long) <= 4) {
+ munmap(idx_map, idx_size);
+ return error("pack %s too large -- please upgrade your git version", path);
+ }
+ }
+ }
- p->index_version = 1;
+ p->index_version = version;
p->index_data = idx_map;
p->index_size = idx_size;
p->num_objects = nr;
@@ -1176,27 +1208,56 @@ const unsigned char *nth_packed_object_sha1(const struct packed_git *p,
unsigned int n)
{
const unsigned char *index = p->index_data;
- index += 4 * 256;
if (n >= p->num_objects)
return NULL;
- return index + 24 * n + 4;
+ index += 4 * 256;
+ if (p->index_version == 1) {
+ return index + 24 * n + 4;
+ } else {
+ index += 8;
+ return index + 20 * n;
+ }
+}
+
+static off_t nth_packed_object_offset(const struct packed_git *p, uint32_t n)
+{
+ const unsigned char *index = p->index_data;
+ index += 4 * 256;
+ if (p->index_version == 1) {
+ return ntohl(*((uint32_t *)(index + 24 * n)));
+ } else {
+ uint32_t off;
+ index += 8 + p->num_objects * (20 + 4);
+ off = ntohl(*((uint32_t *)(index + 4 * n)));
+ if (!(off & 0x80000000))
+ return off;
+ index += p->num_objects * 4 + (off & 0x7fffffff) * 8;
+ return (((uint64_t)ntohl(*((uint32_t *)(index + 0)))) << 32) |
+ ntohl(*((uint32_t *)(index + 4)));
+ }
}
unsigned long find_pack_entry_one(const unsigned char *sha1,
struct packed_git *p)
{
const unsigned int *level1_ofs = p->index_data;
- int hi = ntohl(level1_ofs[*sha1]);
- int lo = ((*sha1 == 0x0) ? 0 : ntohl(level1_ofs[*sha1 - 1]));
const unsigned char *index = p->index_data;
+ unsigned hi, lo;
+ if (p->index_version > 1) {
+ level1_ofs += 2;
+ index += 8;
+ }
index += 4 * 256;
+ hi = ntohl(level1_ofs[*sha1]);
+ lo = ((*sha1 == 0x0) ? 0 : ntohl(level1_ofs[*sha1 - 1]));
do {
- int mi = (lo + hi) / 2;
- int cmp = hashcmp(index + 24 * mi + 4, sha1);
+ unsigned mi = (lo + hi) / 2;
+ unsigned x = (p->index_version > 1) ? (mi * 20) : (mi * 24 + 4);
+ int cmp = hashcmp(index + x, sha1);
if (!cmp)
- return ntohl(*((unsigned int *) ((char *) index + (24 * mi))));
+ return nth_packed_object_offset(p, mi);
if (cmp > 0)
hi = mi;
else
--
1.5.6.3.499.geae9
^ permalink raw reply related
* [PATCH 4/5] pack-objects: learn about pack index version 2
From: Nicolas Pitre @ 2008-07-16 6:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1216189899-14279-4-git-send-email-nico@cam.org>
This is the reading part only. No creation of index v2 is provided.
(extracted from commit c553ca25bd60dc9fd50b8bc7bd329601b81cee66)
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 30 +++++++++++++++++++++++++-----
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index b9c3da2..5198563 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -172,13 +172,33 @@ static void prepare_pack_revindex(struct pack_revindex *rix)
int i;
const char *index = p->index_data;
- index += 4 * 256;
rix->revindex = xmalloc(sizeof(*rix->revindex) * (num_ent + 1));
- for (i = 0; i < num_ent; i++) {
- uint32_t hl = *((uint32_t *)(index + 24 * i));
- rix->revindex[i].offset = ntohl(hl);
- rix->revindex[i].nr = i;
+ index += 4 * 256;
+
+ if (p->index_version > 1) {
+ const uint32_t *off_32 =
+ (uint32_t *)(index + 8 + p->num_objects * (20 + 4));
+ const uint32_t *off_64 = off_32 + p->num_objects;
+ for (i = 0; i < num_ent; i++) {
+ uint32_t off = ntohl(*off_32++);
+ if (!(off & 0x80000000)) {
+ rix->revindex[i].offset = off;
+ } else {
+ rix->revindex[i].offset =
+ ((uint64_t)ntohl(*off_64++)) << 32;
+ rix->revindex[i].offset |=
+ ntohl(*off_64++);
+ }
+ rix->revindex[i].nr = i;
+ }
+ } else {
+ for (i = 0; i < num_ent; i++) {
+ uint32_t hl = *((uint32_t *)(index + 24 * i));
+ rix->revindex[i].offset = ntohl(hl);
+ rix->revindex[i].nr = i;
+ }
}
+
/* This knows the pack format -- the 20-byte trailer
* follows immediately after the last object data.
*/
--
1.5.6.3.499.geae9
^ permalink raw reply related
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Karl Hasselström @ 2008-07-16 6:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Geoffrey Irving, git@vger.kernel.org
In-Reply-To: <7vod4yztf5.fsf@gitster.siamese.dyndns.org>
On 2008-07-15 15:14:38 -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > > +static const char *signature = "CS1M";
> >
> > Carrie Scr*ws 1 Man?
>
> No Idea ;-)
Given the "cached_sha1_map_header" union (or struct) earlier in the
patch, I know what my guess is. :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] t9600: allow testing with cvsps 2.2, including beta versions
From: Jeff King @ 2008-07-16 7:11 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <20080714205114.cnwynr1q804wow4k-cebfxv@webmail.spamcop.net>
On Mon, Jul 14, 2008 at 08:51:14PM -0400, Pavel Roskin wrote:
> > Excuse me, but we never assumed such.
> >
> > Neither too old nor too new ones are proven to work with us yet, so we
> > cannot be call them supported.
>
> The message was "skipping cvsimport tests, cvsps too old" so the
> assumption was there.
Heh, you can blame me for making that assumption. But at the time I
wrote it, I think cvsps development had stagnated, so there weren't new
versions. :)
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: Allow "Stage Line" to stage adjacent changes independently
From: Johannes Sixt @ 2008-07-16 7:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vy742zul7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
>> Consider this hunk:
>>
>> @@ -10,4 +10,4 @@
>> context before
>> -old 1
>> -old 2
>> +new 1
>> +new 2
>> context after
>>
>> [Nomenclature: to "stage change 2" means to stage lines "-old 1" and
>> "+new 1", in any order; likewise for "unstage" and "change 2".]
>
> You lost me.
>
> Do you mean to say that you always interpret the above hunk as:
>
> @@ -10,4 +10,4 @@
> context before
> -old 1
> +new 1
> -old 2
> +new 2
> context after
>
> and call "replace 'old 1' with 'new 1'" as "change 1", "replace 'old
> 2' with 'new 2'" as "change 2"?
No, it is not that I *always* interpret it this way. There is a problem to
fix only if I *want* to interpret it this way. Probably that's what I have
to make clear?
> If it is what you are doing, it does not make much sense to me. "new 1"
> may correspond to "old 1" and "old 2" while "new 2" may be an independent
> addition. E.g.
>
> @@ -10,4 +10,4 @@
> context before
> -#define add(x,y) \
> - (x) + (y)
> +#define add(x,y) ((x)+(y))
> +#define sub(x,y) ((x)-(y))
> context after
>
> I might want to pick bugfix of add() definition without using the new
> definition of sub().
In order to that, there is nothing to fix; you can do that today without
this patch.
> Please call
>
> "-old 1" - change #1
> "-old 2" - change #2
> "+new 1" - change #3
> "+new 2" - change #4
>
> and try explaining what you are doing again, pretty please?
No, this sounds like 4 independent changes, and that is not what this fix
is about.
I'll try to come up with a better wording.
-- Hannes
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Andreas Ericsson @ 2008-07-16 7:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080715233851.GA23672@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> I beat you to it ;-) This works just fine for me regardless of whether
>> or not I have a colon in COMP_WORDBREAKS.
> ...
>> Subject: git-completion.bash: Handle "rev:path" completion properly
> ...
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index d268e6f..e138022 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -293,7 +293,11 @@ __git_complete_file ()
>> *)
>> ls="$ref"
>> ;;
>> - esac
>> + esac
>> + # When completing something like 'rev:path', bash behaves
>> + # differently whether or not COMP_WORDBREAKS contains a
>> + # colon or not. This lets it handle both cases
>> + test "${COMP_WORDBREAKS//:}" = "$COMP_WORDBREAKS" && pfx="$ref:$pfx"
>> COMPREPLY=($(compgen -P "$pfx" \
>> -W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
>> | sed '/^100... blob /s,^.* ,,
>
> Yea, I did more or less the same thing in my patch, but I also
> handled this fix in git-fetch and git-push. The : is also used
> there in a refspec and we support completion the right side of the
> : in both cases (and yes, on git-push that can be slow as we do
> network IO, possibly over SSH).
>
> So I'm in favor of my patch over yours, but only because of
> the fetch and push fixes as well.
>
I agree, although I'd rather not have seen the case statement in
yours. It's bash completion after all, so no need to be "portably
fast" ;-)
I don't care that much though so long as it gets fixed.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johan Herland @ 2008-07-16 7:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin, Geoffrey Irving
In-Reply-To: <7vod4yztf5.fsf@gitster.siamese.dyndns.org>
On Wednesday 16 July 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Okay, it seems like I never have time to review this, so I'll just
> >
> > take a few minutes to comment on some aspects:
> >> @@ -1094,6 +1104,8 @@ int cmd_cherry(int argc, const char **argv,
> >> const char *prefix)
> >> const char *limit = NULL;
> >> int verbose = 0;
> >>
> >> + git_config(git_cherry_config, NULL);
> >> +
> >> if (argc > 1 && !strcmp(argv[1], "-v")) {
> >> verbose = 1;
> >> argc--;
> >
> > Is this really purely for cherry, and not at all for "log
> > --cherry-pick"? Maybe it should be "cache.patchIds" to begin with.
>
> What other things would we want caches for?
This should be fairly obvious:
- git-notes (uses sha1-to-sha1 cache for storing commit-to-note
relationship)
- integrated bug trackers (uses sha1-to-sha1 cache for storing
commit-to-bugreport (or similar) relationships)
- ...any other mechanism that want to quickly map from a git object to some
associated data
There are probably plenty more ideas and use cases if people start looking.
AFAICS, each different use case would keep its cache in a separate file.
For local-repo-only caches the cache is kept within $GIT_DIR, and for shared
caches (IF that makes sense in any of the use cases) the cache could be
located in the working tree (either as a .git_foo file on relevant
branches, or as a file on a separate domain-specific branch).
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: MSysGit Stability
From: Peter Krefting @ 2008-07-16 8:30 UTC (permalink / raw)
To: Joe Fiorini; +Cc: Git Mailing List
In-Reply-To: <73fd69b50807151458u22a383a3l343779e47f4161fa@mail.gmail.com>
Joe Fiorini:
> I'm curious which is better to use and if MSysGit is even stable yet.
> Does anyone have experience running Git on Windows? Any experiences
> you can share? Is MSysGit ready yet or should we wait?
I have been using MSysGit actively for several projects since late last
year. The first time was a bit rough, but with the latest few version,
the MSysGit version has really matured, and I am happy to recommend it
anyone who wants to try out Git.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: git-rebase eats empty commits
From: Michael J Gruber @ 2008-07-16 9:24 UTC (permalink / raw)
To: git
In-Reply-To: <20080715201902.GC6244@leksak.fem-net>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
Stephan Beyer venit, vidit, dixit 15.07.2008 22:19:
> Hi,
...
> any version of git. Or I am missing a point.
>
> $ git cherry-pick empty # empty is an empty commit tagged as "empty"
> Already uptodate!
> Finished one cherry-pick.
> # Not currently on any branch.
> # Untracked files:
> [...]
> nothing added to commit but untracked files present (use "git add" to track)
How would an empty commit produce untracked files? You seem to be
testing something different.
I reattach the test case from my original post, as well as the log of
runs with git 1.5.6.3: once with rebase and once with rebase -i.
Uuuh, doh: I interpreted
Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply e1f497c... empty 1
8d0c67a675bc65d375e8a9d019500bb2a16fb1e9 rewritten 1
as the end of the (interactive) rebase operation! Nothing indicated it
was interrupted: no message and no git status output. It all looked like
a failed rebase.
Now, thanks to your persistence, I tried going ahead with commit --amend
and rebase --continue, and all went fine (stopped again for empty 2,
giving no clue; amend & cont).
So, you're right: cherry-pick stops at empty commits, so that rebase -i
is the way to go. rebase (non-i) uses format-patch resp. merge (-m),
which eat empty commits.
I recall some discussion about informative rb-i messages, may upcoming
git would have saved me and will save others from this misinterpretation.
Thanks!
Michael
[-- Attachment #2: empty.sh --]
[-- Type: application/x-shellscript, Size: 400 bytes --]
[-- Attachment #3: empty.log --]
[-- Type: text/x-log, Size: 816 bytes --]
Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit 6b9e2af: 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
Created commit 8387962: empty 1
Created commit 6c4c3fe: 2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
Created commit 3521900: empty 2
3521900fb7b032aa9e1f5a50a82f71785aa5c208 empty 2
6c4c3fe8b7619e1107256d0b47d0f419c05ceb69 2
8387962b740bb47662dd866eb57b4fe5ad21b355 empty 1
6b9e2afad8bed27378f0c9d23e77631be8447d37 1
Switched to a new branch "temp"
Created commit 1cced89: rewritten 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
First, rewinding head to replay your work on top of it...
Applying 2
a4116113335fc6be47fb9f8481547ea0923ac09d 2
1cced892a90024f4230a9f7aec1989ffe0b6c16f rewritten 1
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: empty-i.log --]
[-- Type: text/x-log; name="empty-i.log", Size: 873 bytes --]
Initialized empty Git repository in /tmp/mjg/t/empty/.git/
Created initial commit 2796c9d: 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
Created commit e1f497c: empty 1
Created commit b3867ae: 2
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
Created commit 2edad43: empty 2
2edad436286f39e407b83bbb448b3aa62b91aeb9 empty 2
b3867ae2a345ab30bfd68a1c7e0e19999a1eb9eb 2
e1f497c4ee7a040162faa7dcc2b6d8e41d5fd920 empty 1
2796c9d9f8fced86134e5b36462916c938c6f819 1
Switched to a new branch "temp"
Created commit 8d0c67a: rewritten 1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
Rebasing (1/3)\rAlready uptodate!
Finished one cherry-pick.
# Not currently on any branch.
nothing to commit (working directory clean)
Could not apply e1f497c... empty 1
8d0c67a675bc65d375e8a9d019500bb2a16fb1e9 rewritten 1
^ permalink raw reply
* Re: [PATCH] rebase-i: keep old parents when preserving merges
From: Stephan Beyer @ 2008-07-16 9:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807160432480.2841@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 16 Jul 2008, Stephan Beyer wrote:
>
> > This patch fixes two issues for rebase -i with preserving
> > merges of unrelated branches.
>
> Two? What's the second?
Oh, eh, well ;)
It's only one bug, but it results in two different behaviors...
If you have a merge with more than two parents and not all are lost,
then it merges with too few parents.
If you have a merge with exactly two parents and one is lost, then
it tries to cherry-pick (with an error).
"Two" "issues" :)
Regards.
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* git-cvsexportcommit keyword mismatch issue
From: Barak A. Pearlmutter @ 2008-07-16 9:09 UTC (permalink / raw)
To: git
I used git-cvsimport -k to create my own git repo to deal with a
project that uses CVS. I push my mods upstream using
git-cvsexportcommit. This works fine *unless* there is a keyword
mismatch, i.e., some file in git has $Id: foo$ while in CVS keyword
expansion somehow changed it to $Id: bar$. In that case
git-cvsexportcommit barfs with a patch failure.
When that happens I use git-format-patch to generate a patch file and
integrate it manually. BLECH! This also confuses git-cvsimport when
I try to pull upstream changes, so I end up manually resolving the
keyword conflict again at that point, i.e., twice.
Simply avoiding expanded keywords should solve the problem. I thought
git-cvsimport -k would keep them out of my git repo, but no such luck.
Even when I use "cvs checkout -kk" for the CVS sandbox and then
"git-cvsimport -k", keywords were *still* expanded in my git repo.
(This is with both git 1.4.4.4 and git 1.5.6.) Either the -k switch
to git-cvsimport is busted, or I'm doing something wrong. In any case
even if this approached worked it would introduce a host of new
issues, since others on the project *are* using keyword expansion, and
the build process relies upon them.
One solution that occurs to me would be for git-cvsexportcommit to do
the dirty work of ignoring keyword mismatches for files that do not
have keywords disabled in CVS. It seems like it is in the best
position to solve the problem---everything else is hacking around to
avoid it instead of actually solving it, which gets brittle. So what
I'm hoping is that this lengthy discourse of mine will convince
someone to add code to git-cvsexportcommit that causes the patch
creation and application stuff inside it to ignore keyword expansion
mismatches (on files which do not have -kb on in CVS), perhaps by
simply contracting keywords on all files/patches from both CVS/git at
an early stage.
The same hack could be used in git-cvsimport to avoid the same problem
in the other direction, albeit with a little more work since keywords
that were not unexpanded in the git files would need to be re-expanded
in git to avoid gratuitous keyword-value-change patches.
Or perhaps I'm missing some other solution...?
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
^ permalink raw reply
* [PATCH] Fix buffer overflow in git-grep
From: Dmitry Potapov @ 2008-07-16 10:15 UTC (permalink / raw)
To: git; +Cc: Dmitry Potapov
If PATH_MAX on your system is smaller than any path stored in the git
repository, that can cause memory corruption inside of the grep_tree
function used by git-grep.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
builtin-grep.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index ef29910..530a53d 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -441,14 +441,17 @@ static int grep_tree(struct grep_opt *opt, const char **paths,
len = strlen(path_buf);
while (tree_entry(tree, &entry)) {
- strcpy(path_buf + len, entry.path);
+ int te_len = tree_entry_len(entry.path, entry.sha1);
+ if (len + te_len >= PATH_MAX + tn_len)
+ die ("path too long: %s", path_buf+tn_len);
+ memcpy(path_buf + len, entry.path, te_len);
if (S_ISDIR(entry.mode))
/* Match "abc/" against pathspec to
* decide if we want to descend into "abc"
* directory.
*/
- strcpy(path_buf + len + tree_entry_len(entry.path, entry.sha1), "/");
+ strcpy(path_buf + len + te_len, "/");
if (!pathspec_matches(paths, down))
;
--
1.5.6.3.1.gb5587a
^ permalink raw reply related
* Re: [PATCH] rebase-i: keep old parents when preserving merges
From: Johannes Schindelin @ 2008-07-16 10:24 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080716094301.GA25087@leksak.fem-net>
Hi,
On Wed, 16 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin wrote:
>
> > On Wed, 16 Jul 2008, Stephan Beyer wrote:
> >
> > > This patch fixes two issues for rebase -i with preserving merges of
> > > unrelated branches.
> >
> > Two? What's the second?
>
> Oh, eh, well ;)
> It's only one bug, but it results in two different behaviors...
Ah, okay. Worthwhile clarifying in the commit message.
Thanks for the patch,
Dscho
^ permalink raw reply
* Re: git-cvsexportcommit keyword mismatch issue
From: Johannes Schindelin @ 2008-07-16 10:31 UTC (permalink / raw)
To: Barak A. Pearlmutter; +Cc: git
In-Reply-To: <E1KJ30U-0004EL-BV@corti>
Hi,
On Wed, 16 Jul 2008, Barak A. Pearlmutter wrote:
> So what I'm hoping is that this lengthy discourse of mine will convince
> someone to add code to git-cvsexportcommit that causes the patch
> creation and application stuff inside it to ignore keyword expansion
> mismatches (on files which do not have -kb on in CVS), perhaps by simply
> contracting keywords on all files/patches from both CVS/git at an early
> stage.
I doubt that this is going to happen. Obviously, it has been nonbody's
itch _enough_ to scratch it.
I see your problem, but unless you start hacking, I do not see it being
solved anytime soon.
Ciao,
Dscho
^ permalink raw reply
* git submodules and commit
From: Nigel Magnay @ 2008-07-16 10:32 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <320075ff0807160331j30e8f832m4de3e3bbe9c26801@mail.gmail.com>
I wonder if this is a fairly common pattern. We tend to have modules
as git repositories, and projects that tie together those git
repositories as submodules. In general, > 90% of the work is done in
one module, and the following stanza gets used a lot:
cd /proj/modA
git commit -s -m "Some change"
git push
cd ..
git add modA
git commit -s -m "Some change (modA)"
git push
But since this is much more cumbersome than (say) "svn ci", what often
happens is developers just commit into modA, then carry on. Or for
people just learning git, they somtimes screw up, and push the parent
proj but not the child modA
This is a shame, as it means any external people pulling updates
directly from proj will not get this change (e.g. CI tools
speculatively compiling against every developer tree).
For me, in some really high proportion of cases, I think I want 'git
commit' to mean 'commit to any child repositories, any sibling
repositories, and any parent repositories (updating the submodule sha1
as appropriate). In other words, 'pretend like the whole thing is one
big repo'.
I guess it probably gets sticky when there are merge conflicts. Is
anyone working on this kind of thing; I might be able to give some
time to help work on it?
^ 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