* Re: [PATCH] mailmap: xcalloc mailmap_info
From: Junio C Hamano @ 2011-11-17 1:10 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: git
In-Reply-To: <1321487473-29194-1-git-send-email-marcandre.lureau@gmail.com>
Marc-André Lureau <marcandre.lureau@gmail.com> writes:
> This is to avoid reaching free of uninitialized members.
>
> With an invalid .mailmap (and perhaps in other cases), it can reach
> free(mi->name) with garbage for example.
> ---
Sign-off?
Thanks. We might want to turn xmalloc() followed by memset(,0,) for the
allocation of the mailmap entry itself in the same function, but that is a
minor issue.
> mailmap.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/mailmap.c b/mailmap.c
> index 02fcfde..fbf7764 100644
> --- a/mailmap.c
> +++ b/mailmap.c
> @@ -88,7 +88,7 @@ static void add_mapping(struct string_list *map,
> me->email = xstrdup(new_email);
> }
> } else {
> - struct mailmap_info *mi = xmalloc(sizeof(struct mailmap_info));
> + struct mailmap_info *mi = xcalloc(1, sizeof(struct mailmap_info));
> debug_mm("mailmap: adding (complex) entry for %s at index %d\n", old_email, index);
> if (new_name)
> mi->name = xstrdup(new_name);
^ permalink raw reply
* Re: git clone --reference not working
From: Junio C Hamano @ 2011-11-17 0:54 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: git, Michael Haggerty
In-Reply-To: <20111116234314.GF3306@redhat.com>
Andrea Arcangeli <aarcange@redhat.com> writes:
> latest git.git won't clone linux upstream with --reference. Those
> v*^{} tags breaks it. What's that stuff anyway, looks totally ugly
> (two commits with same data contents and header) bah.
They point at commits they tag, and are essential for auto-following. They
have been there forever in ls-remote output and they are not the real
problem.
A recent topic that was merged at 9bd5000 tightened the refname checking
code without thinking and started to needlessly barf upon seeing them. I
think we have discussed about the issue on the list, but I do not think
there were fixes yet.
Thanks for reminding.
Michael, how does this look?
-- >8 --
Subject: refs: loosen over-strict "format" check
The add_extra_ref() interface is used to add an extra-ref that is _not_
our ref for the purpose of helping auto-following of tags and reducing
object transfer from remote repository, and they are typically formatted
as a tagname followed by ^{} to make sure no valid refs match that
pattern. In other words, these entries are deliberately formatted not to
pass check-refname-format test.
A recent series however added a test unconditionally to the add_ref()
function that is called from add_extra_ref(). The check may be sensible
for other two callsites of the add_ref() interface, but definitely is
a wrong thing to do in add_extra_ref(). Disable it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* In general, we should make things lenient when we are reading from
existing source, so that the code can be used to recover a repository
with badly formatted refs left by other tools, and enforce the format
check when we write things out. We may further need to loosen the checks
introduced earlier by mh/check-ref-format-3 topic for similar breakages
as they are discovered.
refs.c | 20 ++++++++++----------
t/t5700-clone-reference.sh | 7 +++++++
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index e69ba26..e7843eb 100644
--- a/refs.c
+++ b/refs.c
@@ -48,7 +48,7 @@ static const char *parse_ref_line(char *line, unsigned char *sha1)
}
static void add_ref(const char *name, const unsigned char *sha1,
- int flag, struct ref_array *refs,
+ int flag, int check_name, struct ref_array *refs,
struct ref_entry **new_entry)
{
int len;
@@ -59,7 +59,8 @@ static void add_ref(const char *name, const unsigned char *sha1,
entry = xmalloc(sizeof(struct ref_entry) + len);
hashcpy(entry->sha1, sha1);
hashclr(entry->peeled);
- if (check_refname_format(name, REFNAME_ALLOW_ONELEVEL|REFNAME_DOT_COMPONENT))
+ if (check_name &&
+ check_refname_format(name, REFNAME_ALLOW_ONELEVEL|REFNAME_DOT_COMPONENT))
die("Reference has invalid format: '%s'", name);
memcpy(entry->name, name, len);
entry->flag = flag;
@@ -234,7 +235,7 @@ static void read_packed_refs(FILE *f, struct ref_array *array)
name = parse_ref_line(refline, sha1);
if (name) {
- add_ref(name, sha1, flag, array, &last);
+ add_ref(name, sha1, flag, 1, array, &last);
continue;
}
if (last &&
@@ -249,7 +250,7 @@ static void read_packed_refs(FILE *f, struct ref_array *array)
void add_extra_ref(const char *name, const unsigned char *sha1, int flag)
{
- add_ref(name, sha1, flag, &extra_refs, NULL);
+ add_ref(name, sha1, flag, 0, &extra_refs, NULL);
}
void clear_extra_refs(void)
@@ -333,12 +334,11 @@ static void get_ref_dir(const char *submodule, const char *base,
hashclr(sha1);
flag |= REF_ISBROKEN;
}
- } else
- if (!resolve_ref(ref, sha1, 1, &flag)) {
- hashclr(sha1);
- flag |= REF_ISBROKEN;
- }
- add_ref(ref, sha1, flag, array, NULL);
+ } else if (!resolve_ref(ref, sha1, 1, &flag)) {
+ hashclr(sha1);
+ flag |= REF_ISBROKEN;
+ }
+ add_ref(ref, sha1, flag, 1, array, NULL);
}
free(ref);
closedir(dir);
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index 895f559..c4c375a 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -146,4 +146,11 @@ test_expect_success 'cloning with reference being subset of source (-l -s)' \
cd "$base_dir"
+test_expect_success 'clone with reference from a tagged repository' '
+ (
+ cd A && git tag -a -m 'tagged' HEAD
+ ) &&
+ git clone --reference=A A I
+'
+
test_done
^ permalink raw reply related
* [patch] color of branches in git status -sb
From: Nicolas Dudebout @ 2011-11-17 0:39 UTC (permalink / raw)
To: git
The following patch fixes the fact that two colors of the status
output could not be configured in .git/config.
The color of the current branch could not be modified because of the
name WT_STATUS_ONBRANCH having been changed to WT_STATUS_LOCAL_BRANCH.
The color of the remote branch was not defined at all.
By the way, when I do 'git status' instead of git 'status -sb' the
local and remote branch do not get colored. Is this a desired
behavior?
Nicolas
Modified Documentation/config.txt
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5a841da..7a0ddd6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -809 +809,2 @@ color.status.<slot>::
- `branch` (the current branch), or
+ `branch` (the current branch),
+ `remote` (the remote branch) or
Modified builtin/commit.c
diff --git a/builtin/commit.c b/builtin/commit.c
index c46f2d1..4674600 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1118 +1118,3 @@ static int parse_status_slot(const char *var, int offset)
- return WT_STATUS_ONBRANCH;
+ return WT_STATUS_LOCAL_BRANCH;
+ if (!strcasecmp(var+offset, "remote"))
+ return WT_STATUS_REMOTE_BRANCH;
^ permalink raw reply related
* [PATCH] mailmap: xcalloc mailmap_info
From: Marc-André Lureau @ 2011-11-16 23:51 UTC (permalink / raw)
To: git; +Cc: Marc-André Lureau
This is to avoid reaching free of uninitialized members.
With an invalid .mailmap (and perhaps in other cases), it can reach
free(mi->name) with garbage for example.
---
mailmap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index 02fcfde..fbf7764 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -88,7 +88,7 @@ static void add_mapping(struct string_list *map,
me->email = xstrdup(new_email);
}
} else {
- struct mailmap_info *mi = xmalloc(sizeof(struct mailmap_info));
+ struct mailmap_info *mi = xcalloc(1, sizeof(struct mailmap_info));
debug_mm("mailmap: adding (complex) entry for %s at index %d\n", old_email, index);
if (new_name)
mi->name = xstrdup(new_name);
--
1.7.7
^ permalink raw reply related
* Re: delete deprecated refs to release disk space
From: Peter Vereshagin @ 2011-11-16 23:44 UTC (permalink / raw)
To: git; +Cc: ??var Arnfj??r?? Bjarmason, git
In-Reply-To: <20111114142525.GB8641@external.screwed.box>
Hello.
2011/11/14 18:25:25 +0400 Peter Vereshagin <peter@vereshagin.org> => To ??var Arnfj??r?? Bjarmason :
PV> N commits ago is a fine setting for me as it's a cron job backup. Thanks?
* = Thanks!
Here is the PoC QnD code that releases disk space for me by far:
git rev-list --all --timestamp |\
perl -Mstrict -MTime::ParseDate -wE \
'my $match = 0; my $expire = parsedate( "3 days ago" ); while (<>)
{ chomp; my ( $tstamp => $graft_id ) = split /\s+/;
if ( not( $match ) and $tstamp < $expire )
{ say $graft_id; $match = 1; } }
' > .git/info/grafts && \
git filter-branch -f
for case a one shall seek for it.
--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: A0E26627
^ permalink raw reply
* Git Gems
From: Hilco Wijbenga @ 2011-11-16 23:18 UTC (permalink / raw)
To: Git Users
Hi all,
Just today, I found out about 'git add -p'. I had never even thought
of this but, now that I know, I can't imagine life without it. :-)
Actually, it's a bit scary to note that the Git devs apparently aren't
just telepathic but they can read my thoughts even before I think
them. ;-)
All kidding aside, I'm starting to wonder which other Git Gems I don't
know about. For me, the list of Git Gems would include Git's Bash
command line prompt, 'git add -p', 'git rebase', 'git commit --amend',
and 'git-new-workdir'. I realize there are plenty of books and such
out there but I'm really just looking for a list of Git commands
and/or options that are worth looking into. Finding out more about a
particular command/script/option is easy, realizing that a particular
one is the one you need is not. Especially, if you don't even know you
have a problem.
As an example, 'git rebase' didn't really seem useful until I
understood (well, more or less) what it did. Until then, I just
naively assumed that merge commits and non-linear history were
something you simply had to live with. I'm guessing that, like me, a
lot of people come to Git with quite a few assumptions and
preconceived notions due to their exposure to other SCM tools. :-(
Cheers,
Hilco
^ permalink raw reply
* Re: gitweb ignores git-daemon-export-ok and displays all repositories
From: Jonathan Nieder @ 2011-11-16 22:47 UTC (permalink / raw)
To: git
Cc: Erik Wenzel, Jakub Narebski, John 'Warthog9' Hawley,
Matthias Lederhofer
In-Reply-To: <D765D350-947E-4DB2-8A91-4B9653064F80@code.de>
Hi gitwebbers,
Erik Wenzel wrote[1]:
> Am 13.11.2011 um 02.19 schrieb Jonathan Nieder:
>> The git-daemon(1) manpage describes git daemon, not gitweb, so I guess
>> you mean that
>>
>> # Do not list projects without git-daemon-export-ok in the
>> # projects list.
>> our $export_ok = "git-daemon-export-ok";
>>
>> # Do not allow access to projects not listed in the projects
>> # list.
>> our $strict_export = 1;
>>
>> should be the default.
[...]
> Because I think this is the way a user is expecting the behavior of gitweb.
> As I do. Don't let gitweb overwrite the meaning of "git-daemon-export-ok".
> Just act like git-daemon. Keep it simple and stupid.
My first thought was that if we could turn back time, it would
probably be best for both git-daemon and gitweb to look for a file
named git-export-ok. In the present world, maybe git-daemon-export-ok
is a good substitute for that.
What do you think? Should the default in the makefile be changed? If
so, how could we go about it to avoid disturbing existing
installations? (For example, in a system where no repositories have
the export-ok files and "git daemon" is configured to run with
--export-all, the effect would be to make repos suddenly disappear
from the projects list in gitweb. Unpleasant.)
Looking forward to your thoughts,
Jonathan
[1] http://bugs.debian.org/648561
^ permalink raw reply
* Re: Git 1.7.5 problem with HTTPS
From: Jonathan Nieder @ 2011-11-16 22:28 UTC (permalink / raw)
To: Dmitry Smirnov
Cc: Daniel Stenberg, Tay Ray Chuan, Junio C Hamano, Shawn Pearce, git
In-Reply-To: <CACf55T6rUiE8Pm3s16oFgJ1ueTAdOwOz_+XptE-tZM1z9fcq+w@mail.gmail.com>
Dmitry Smirnov wrote:
> What Git is providing to libcurl? Can I log it?
ltrace can help.
^ permalink raw reply
* Re: old git reference manuals & release notes
From: Tomas Carnecky @ 2011-11-16 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, Git Users
In-Reply-To: <7vty69pz92.fsf@alter.siamese.dyndns.org>
On 11/12/11 8:37 AM, Junio C Hamano wrote:
> I am not involved in the git-scm.com site that shows the documentation,
> but I am guessing that it keeps an up to date copy of the preformatted
> git-htmldocs repository and shows blob contents directly from the tip of
> the history. The preformatted documents in git-htmldocs repository are
That site does not host any documentation directly, it merely links to
other websites. One of those websites is
http://schacon.github.com/git/git.html, but it has not seen any update
since July 23, 2011.
tom
^ permalink raw reply
* Re: [PATCH 0/3] avoiding unintended consequences of git_path() usage
From: Junio C Hamano @ 2011-11-16 22:04 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jonathan Nieder, Ramkumar Ramachandra, Git List
In-Reply-To: <CACsJy8Di3ZrPdXh1Jf=PbLYRWwx-TEV78NzUukwaxA0xW=rSNg@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> ... git_path() could learn to keep track
> of all generated strings while keep it convenient to use.
That certainly sounds an interesting approach.
^ permalink raw reply
* [PATCH/RFC] introduce strbuf_addpath()
From: Jonathan Nieder @ 2011-11-16 21:50 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Ramkumar Ramachandra, Junio C Hamano, Git List
In-Reply-To: <20111116085944.GA18781@elie.hsd1.il.comcast.net>
strbuf_addpath() is like git_path_unsafe(), except instead of
returning its own buffer, it appends its result to a buffer provided
by the caller.
Benefits:
- Since it uses a caller-supplied buffer, unlike git_path_unsafe(),
there is no risk that one call will clobber the result from
another.
- Unlike git_pathdup(), it does not need to waste time allocating
memory in the middle of your tight loop over refs.
- The size of the result is not limited to PATH_MAX.
Caveat: the size of its result is not limited to PATH_MAX. Existing
code might be relying on git_path*() to produce a result that is safe
to copy to a PATH_MAX-sized buffer. Be careful.
This patch introduces the strbuf_addpath() function and converts a few
existing users of the strbuf_addstr(git_path(...)) idiom to
demonstrate the API.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jonathan Nieder wrote:
> I think if I ran the world, the fundamental operation would be
> strbuf_addpath().
Like this, maybe.
In these v1.7.8-rc2 days, you should probably spend your time
reviewing patch 2/3 of the previous series, though. ;-)
cache.h | 3 +++
notes-merge.c | 2 +-
path.c | 34 ++++++++++++++++++++++++++++++++++
sha1_file.c | 2 +-
transport.c | 4 ++--
5 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 7fb85445..33d7d147 100644
--- a/cache.h
+++ b/cache.h
@@ -659,6 +659,8 @@ extern char *git_snpath(char *buf, size_t n, const char *fmt, ...)
__attribute__((format (printf, 3, 4)));
extern char *git_pathdup(const char *fmt, ...)
__attribute__((format (printf, 1, 2)));
+extern void strbuf_addpath(struct strbuf *sb, const char *fmt, ...)
+ __attribute__((format (printf, 2, 3)));
/* Return a statically allocated filename matching the sha1 signature */
extern char *mkpath(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
diff --git a/notes-merge.c b/notes-merge.c
index 0b49e8ad..738442de 100644
--- a/notes-merge.c
+++ b/notes-merge.c
@@ -733,7 +733,7 @@ int notes_merge_abort(struct notes_merge_options *o)
struct strbuf buf = STRBUF_INIT;
int ret;
- strbuf_addstr(&buf, git_path_unsafe(NOTES_MERGE_WORKTREE));
+ strbuf_addpath(&buf, NOTES_MERGE_WORKTREE);
OUTPUT(o, 3, "Removing notes merge worktree at %s", buf.buf);
ret = remove_dir_recursively(&buf, 0);
strbuf_release(&buf);
diff --git a/path.c b/path.c
index 0611b7be..28d6326d 100644
--- a/path.c
+++ b/path.c
@@ -33,6 +33,20 @@ static char *cleanup_path(char *path)
return path;
}
+static void strbuf_cleanup_path(struct strbuf *sb, size_t pos)
+{
+ char *newstart;
+
+ /*
+ * cleanup_path expects to be acting on a static buffer,
+ * so it modifies its argument in place and returns
+ * a pointer to the new start of the path.
+ */
+ newstart = cleanup_path(sb->buf + pos);
+ strbuf_remove(sb, pos, newstart - sb->buf - pos);
+ strbuf_setlen(sb, strlen(sb->buf));
+}
+
char *mksnpath(char *buf, size_t n, const char *fmt, ...)
{
va_list args;
@@ -68,6 +82,18 @@ bad:
return buf;
}
+static void strbuf_vaddpath(struct strbuf *sb, const char *fmt, va_list args)
+{
+ const char *git_dir = get_git_dir();
+ size_t pos = sb->len;
+
+ strbuf_addstr(sb, git_dir);
+ if (pos < sb->len && !is_dir_sep(sb->buf[sb->len - 1]))
+ strbuf_addch(sb, '/');
+ strbuf_vaddf(sb, fmt, args);
+ strbuf_cleanup_path(sb, pos);
+}
+
char *git_snpath(char *buf, size_t n, const char *fmt, ...)
{
va_list args;
@@ -87,6 +113,14 @@ char *git_pathdup(const char *fmt, ...)
return xstrdup(path);
}
+void strbuf_addpath(struct strbuf *sb, const char *fmt, ...)
+{
+ va_list args;
+ va_start(args, fmt);
+ strbuf_vaddpath(sb, fmt, args);
+ va_end(args);
+}
+
char *mkpath(const char *fmt, ...)
{
va_list args;
diff --git a/sha1_file.c b/sha1_file.c
index ba7eca89..315d1004 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2706,7 +2706,7 @@ static int index_stream(unsigned char *sha1, int fd, size_t size,
int len, tmpfd;
strbuf_addstr(&export_marks, "--export-marks=");
- strbuf_addstr(&export_marks, git_path_unsafe("hashstream_XXXXXX"));
+ strbuf_addpath(&export_marks, "hashstream_XXXXXX");
tmpfile = export_marks.buf + strlen("--export-marks=");
tmpfd = git_mkstemp_mode(tmpfile, 0600);
if (tmpfd < 0)
diff --git a/transport.c b/transport.c
index cc0ca04c..f5c95b40 100644
--- a/transport.c
+++ b/transport.c
@@ -203,7 +203,7 @@ static struct ref *get_refs_via_rsync(struct transport *transport, int for_push)
/* copy the refs to the temporary directory */
- strbuf_addstr(&temp_dir, git_path_unsafe("rsync-refs-XXXXXX"));
+ strbuf_addpath(&temp_dir, "rsync-refs-XXXXXX");
if (!mkdtemp(temp_dir.buf))
die_errno ("Could not make temporary directory");
temp_dir_len = temp_dir.len;
@@ -366,7 +366,7 @@ static int rsync_transport_push(struct transport *transport,
/* copy the refs to the temporary directory; they could be packed. */
- strbuf_addstr(&temp_dir, git_path_unsafe("rsync-refs-XXXXXX"));
+ strbuf_addpath(&temp_dir, "rsync-refs-XXXXXX");
if (!mkdtemp(temp_dir.buf))
die_errno ("Could not make temporary directory");
strbuf_addch(&temp_dir, '/');
--
1.7.8.rc2
^ permalink raw reply related
* Re: [PATCH] apply: squash consecutive slashes with p_value > 0
From: Junio C Hamano @ 2011-11-16 17:36 UTC (permalink / raw)
To: Robie Basak; +Cc: git
In-Reply-To: <20111116120403.GA10342@mal.justgohome.co.uk>
Robie Basak <robie.basak@canonical.com> writes:
> "patch" works with -p1 and diffs in the following form:
> --- foo.orig//bar
> +++ foo//bar
> ...
>
> patch(1) says that "A sequence of one or more adjacent slashes is
> counted as a single slash."
It merely says patch(1) treats duplicate slashes that way; it does not
mean it is a useful thing to do in the real life.
Could you justify why such a change is a good thing in your proposed
commit log message?
> builtin/apply.c | 8 ++++++--
> t/t4153-apply-doubleslash.sh | 29 +++++++++++++++++++++++++++++
> 2 files changed, 35 insertions(+), 2 deletions(-)
> create mode 100755 t/t4153-apply-doubleslash.sh
Can we avoid wasting a new test number for just a single trivial test by
findign appropriate places in existing tests to add new ones to? I think
4133 may be one of the good places (not just checkint between a/f vs b/f,
you would check a//f vs b/f and somesuch).
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 84a8a0b..78e25fa 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -627,9 +627,13 @@ static char *find_name_common(const char *line, char *def, int p_value,
> if (name_terminate(start, line-start, c, terminate))
> break;
> }
> - line++;
> - if (c == '/' && !--p_value)
> + if (c == '/' && !--p_value) {
> + while (*line == '/')
> + line++;
> start = line;
I am not sure if this is sufficient or necessarily correct.
You are de-dupling slashes only when p_value hits 0. When working on an
input "a///b//c" with -p3, your loop strips one slash per decrement of
p_value between "a" and "b" and then you notice slashes after "b" are
duplicated and clean them up, which would mean you normalized the input to
"a///b/c", not "a/b/c", no?
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: Geoff Mets @ 2011-11-16 17:19 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111108T114722-414@post.gmane.org>
Hi Francois
Reading this thread mirrored the exact problems I'm seeing but sadly your
solution adding +ExecCGI didn't fix it.
I'm guessing, like you, it's probably an apache config issue. Could you
share your working apache.conf
Many thanks ..............Geoff
--
View this message in context: http://git.661346.n2.nabble.com/git-receive-pack-missing-credentials-tp6970872p7001142.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git, Parrot, Perl6, Rakudo for G4 MAC
From: Torsten Bögershausen @ 2011-11-16 15:35 UTC (permalink / raw)
To: Greg; +Cc: git
In-Reply-To: <loom.20111115T112500-386@post.gmane.org>
Hej,
you actually don't need perl, if I remember my experimenta with git under
G4 MAC PPC right.
See the Makefile:
# Define NO_PERL if you do not want Perl scripts or libraries at all
And, if I remember it right, git (the selfe compiled) stopped
working after 1.7.0 or so.
I didn't do a bisect, since that machine runs linux most of the time.
/Torsten
On 15.11.11 11:36, Greg wrote:
> Howdy:
>
> Could someone please assist me in locating the resources to "GIT"
> this stuff going on a G4 MAC PPC? I
> keep getting weird bugs.
> Need me to be more explicit? Ok - it says gcc v3.3 isn't compatible, and a
> bunch of other sheet!
>
> I'd like to start messing with this while I'm waiting for my Debian
> Linux box to be returned. (A friend
> borrowed it to do some work:
> He installed a horribly virulent bug called WInBlows XP!!!!)
>
> I already have Perl5.10.1 working fine, and performing
> numerous marvelous tasks, so I (perhaps
> mistakenly) thought it would be an easy addition.
>
>
> Cheers,
>
> Greg
>
> --
> 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
* What to do if the path of my git submodules change upstream
From: Harald Heigl @ 2011-11-16 14:37 UTC (permalink / raw)
To: git
Hi everyone!
First setup of my git was a server (with ssh) and some clients.
Today I changed to gitolite because I wanted a more sophisticated way of
managing my repos. So far so good…
So the old path “ssh://[ip]/[fullpath].git” would change to a new path
“git@[servername]:[gitreponame]”.
This is no problem for “normal” repos, I change the remote origin and
continue using push and pull.
I have some submodules:
I changed the .gitmodules to reflect my changes, did a git submodule sync.
This works flawlessly too!
But what if someone wants to checkout an older version of the project? (for
comparison, or because he/she wanted to try something out)
He would get an old .gitmodules with old paths.
After a git submodule sync he would get errors, because old paths won’t work
anymore, because I changed some paths on the server
It is only one project I have this problem and therein I changed the
.gitmodules only 3 times. Is it possible to rewrite .gitmodules on these
specific commits on the server (perhaps with git-filter-branch)?
Or is there another easy solution? Has someone ever had this problem?
Hope you can help,
Kind regards,
Harald Heigl
^ permalink raw reply
* Re: [RFC 2/2] Make misuse of get_pathname() buffers detectable by valgrind
From: Nguyen Thai Ngoc Duy @ 2011-11-16 14:18 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Junio C Hamano
In-Reply-To: <1317097687-11098-3-git-send-email-mhagger@alum.mit.edu>
On Tue, Sep 27, 2011 at 11:28 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> +#ifdef VALGRIND
> + static char *pathname_array[PATHNAME_BUFFER_COUNT];
> + index = (index + 1) & (PATHNAME_BUFFER_COUNT - 1);
> + if (pathname_array[index]) {
> + /*
> + * In a correct program, this will have no effect, but
> + * *if* somebody erroneously uses this buffer after it
> + * has been freed, it gives more of a chance that the
> + * error will be detected even if valgrind is not
> + * running:
> + */
> + strcpy(pathname_array[index], buggy_path);
> +
> + free(pathname_array[index]);
> + }
> + pathname_array[index] = xmalloc(PATH_MAX);
> + return pathname_array[index];
> +#else
Not sure if it works (just read man pages, haven't tried anything) I'm
thinking to use mmap() with MAP_ANONYMOUS instead of xmalloc(), then
mprotect() instead of free() to remove read access from that area. Any
access after that should be caught. Leaking may not be severe for
git_path(), hopefully.
--
Duy
^ permalink raw reply
* Re: [RFC 2/2] Make misuse of get_pathname() buffers detectable by valgrind
From: Nguyen Thai Ngoc Duy @ 2011-11-16 13:57 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Junio C Hamano, Petr Baudis
In-Reply-To: <1317097687-11098-3-git-send-email-mhagger@alum.mit.edu>
On Tue, Sep 27, 2011 at 11:28 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> A temporary buffer produced by get_pathname() is recycled after a few
> subsequent calls of get_pathname(). The use of such a buffer after it
> has been recycled can result in the wrong file being accessed with
> very strange effects. Moreover, such a bug can lie dormant until code
> elsewhere is changed to use a temporary buffer, causing very
> mysterious, nonlocal failures that are hard to analyze.
>
> Add a second implementation of get_pathname() (activated if the
> VALGRIND preprocessor macro is defined) that allocates and frees
> buffers instead of recycling statically-allocated buffers. This does
> not make the problem less serious, but it turns the errors into
> access-after-free errors, making it possible to locate the guilty code
> using valgrind.
>
> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
> ---
>
> I believe that it is frowned upon to use #ifdefs in git code, but no
> good alternative is obvious to me for this type of use. Suggestions
> are welcome.
Enable the code based on an environment variable, e.g.
GIT_DEBUG_FENCE, then enable it by default in test-lib.sh :-)
--
Duy
^ permalink raw reply
* Re: [PATCH 0/3] avoiding unintended consequences of git_path() usage
From: Michael Haggerty @ 2011-11-16 13:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jonathan Nieder, Ramkumar Ramachandra, Junio C Hamano, Git List
In-Reply-To: <CACsJy8A2=qBiyY3SD-PZo+E=U+Dfjm1UQidgq6khQARZ3d41WQ@mail.gmail.com>
On 11/16/2011 02:33 PM, Nguyen Thai Ngoc Duy wrote:
> 2011/11/16 Jonathan Nieder <jrnieder@gmail.com>:
>> Jokes aside, here's a rough series to do the git_path ->
>> git_path_unsafe renaming. While writing it, I noticed a couple of
>> bugs, hence the two patches before the last one. Patch 2 is the more
>> interesting one.
>
> Another approach is do nothing and leave it for a static analysis tool
> to detect potential problems. I'm looking at sparse at the moment,
> although I know nothing about it to say if it can or cannot detect
> such problems. We can at least make sparse detect return value from
> git_path() being passed to an unsafe function, I think.
For the cases when static analysis doesn't suffice, recently I posted
some patches that make it possible for debug a problem that results from
the use of a "stale" buffer [1]. But having myself also been bitten by
this problem, I'd also be in favor of a more systematic solution, even
if it has a small runtime cost. After all, most of the time the
filename created by git_path() is going to be passed to the kernel a
moment later, which will usually be vastly slower than an extra malloc/free.
Michael
[1] http://comments.gmane.org/gmane.comp.version-control.git/182209
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Merging back from master but keeping a subtree
From: Steinar Bang @ 2011-11-16 13:39 UTC (permalink / raw)
To: git
In-Reply-To: <20110918033719.GB17977@sigill.intra.peff.net>
>>>>> Jeff King <peff@peff.net>:
> Git should generally do that automatically, unless both sides are
> changing mydirectory. In which case it will produce conflicts.
I thought so too, but the end result didn't build, and I was unable to
figure out why.
> Are you sure you really want to just throw out what the other side did
> in mydirectory?
Yes, that's the only thing I'm sure about. All changes to mydirectory
should come from my branch. If there are changes necessary to make
things build, they are better done by me.
> If git was able to auto-merge some files, then they will not be marked
> as conflicts in the index. And "git checkout --ours" is about looking in
> the index for conflicted entries, and then selecting one side.
> I think what you want instead is to do is (assuming you really want to
> throw out their side):
Thanks for the suggestion. I tried following this approach, but...
> 1. Start a merge between them and us:
> git merge --no-commit remoterepo/master
> 2. Throw out whatever the merge came up with and make it look like
> their tree:
...I never quite could figure out if I did the right thing here.
Ie. when throwing out what the commit came up with.
> git checkout remoterepo/master -- top
> 3. Now overwrite their version of mydirectory with what was in your
> branch:
> git checkout HEAD -- top/middle/mydirectory
> 4. Commit the resulting tree:
> git commit
The problem was that the end result didn't build, wit pretty much the
same obscure failures that the regular merge had.
But I eventually tried something that worked:
1. First create a local branch off master
2. Merge in mybranch with "-s ours --no-commit"
3. Checkout mydirectory from mybranch
4. Commit
5. Switch to mybranch
6. Merge in the new local branch, which resulted in a conflict-free
merge that has my changes in mydirectory and the rest of the world
in the rest of the working directory, and the history of mydirectory
looks ok
The end result built and worked.
If git had had a "-s theirs" strategy, I wouldn't have needed the
temporary branch made off master. That need for that branch is probably
the most cryptic thing for people following my instructions for future
merges.
To sum up the commands:
git checkout master
git checkout -b master_nicely_merged_with_mybranch
git merge -s ours --no-commit origin/mybranch
git checkout origin/mybranch top/middle/mydirectory
git commit
git checkout mybranch
git merge master_nicely_merged_with_mybranch
Thanks!
- Steinar
^ permalink raw reply
* Re: [PATCH 0/3] avoiding unintended consequences of git_path() usage
From: Nguyen Thai Ngoc Duy @ 2011-11-16 13:33 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, Junio C Hamano, Git List
In-Reply-To: <20111116075955.GB13706@elie.hsd1.il.comcast.net>
2011/11/16 Jonathan Nieder <jrnieder@gmail.com>:
> Jokes aside, here's a rough series to do the git_path ->
> git_path_unsafe renaming. While writing it, I noticed a couple of
> bugs, hence the two patches before the last one. Patch 2 is the more
> interesting one.
Another approach is do nothing and leave it for a static analysis tool
to detect potential problems. I'm looking at sparse at the moment,
although I know nothing about it to say if it can or cannot detect
such problems. We can at least make sparse detect return value from
git_path() being passed to an unsafe function, I think.
--
Duy
^ permalink raw reply
* feature request: git format-patch - allow --suffix to work with --numbered-files
From: MikeW @ 2011-11-16 13:02 UTC (permalink / raw)
To: git
"Numbered files" is good for creating patches with uniform filenames, rather
than verbose filenames containing part of the commit message, but if working for
example with submodules, there is possible name collision if pooling the patches
in one place.
I thought that --suffix=$name would be a good way to disambiguate but found that
--numbered-files wins and kills any suffix.
Hence suggestion that --suffix used with --numbered-files is allowed to generate
a filename suffix as it does when not in "numbered files" mode.
In the absence of a --suffix command, the behaviour would be as now.
^ permalink raw reply
* Re: [PATCH] git-show-ref: fix escaping in asciidoc source
From: Thomas Rast @ 2011-11-16 13:08 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git
In-Reply-To: <4EC3A45F.9080005@alum.mit.edu>
Michael Haggerty wrote:
> 36 [2]. How can I escape AsciiDoc markup?
>
> Most AsciiDoc inline elements can be suppressed by preceding them with a
> backslash character. These elements include: [...] But there are
> exceptions — see the next question.
[...]
> Note Escaping is unnecessary inside inline literal passthroughs
> (backtick quoted text).
Beware! We actively change the inline literal quoting behaviour to
ensure consistent output with different versions of asciidoc. See
this commit:
commit 71c020c53ec472b04678237d8fe5687f2299db2a
Author: Thomas Rast <trast@student.ethz.ch>
Date: Sat Jul 25 14:06:50 2009 +0200
Disable asciidoc 8.4.1+ semantics for `{plus}` and friends
asciidoc 8.4.1 changed the semantics of inline backtick quoting so
that they disable parsing of inline constructs, i.e.,
Input: `{plus}`
Pre 8.4.1: +
Post 8.4.1: {plus}
Fix this by defining the asciidoc attribute 'no-inline-literal'
(which, per the 8.4.1 changelog, is the toggle to return to the old
behaviour) when under ASCIIDOC8.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 00/28] Store references hierarchically in cache -- benchmark results
From: Michael Haggerty @ 2011-11-16 12:51 UTC (permalink / raw)
To: mhagger
Cc: Junio C Hamano, git, Jeff King, Drew Northup, Jakub Narebski,
Heiko Voigt, Johan Herland, Julian Phillips
In-Reply-To: <1319804921-17545-1-git-send-email-mhagger@alum.mit.edu>
On 10/28/2011 02:28 PM, mhagger@alum.mit.edu wrote:
> [...]
> This patch series changes how references are stored in the reference
> cache data structures (entirely internal to refs.c). Previously, the
> packed refs were stored in one big array of pointers-to-struct, and
> the loose refs were stored in another. [...]
>
> Therefore, this patch series changes the data structure used to store
> the reference cache from a single array of pointers-to-struct into a
> tree-like structure in which each subdirectory of the reference
> namespace is stored as an array of pointers-to-entry and entries can
> be either references or subdirectories containing more references.
> Moreover, each subdirectory of loose references is only read from disk
> when a reference from that subdirectory (or one of its descendants) is
> needed. This slightly slows down commands that need to iterate
> through all references (simply because the new data structures are
> more complicated), but it *dramatically* decreases the time needed for
> some common operations. For example, in a test repository with 20000
> revisions and 10000 loose tags:
Due to the death of my old computer, I got distracted and never
published the benchmark results that I cited above. (The numbers here
are different than the originals because they are done on a different
computer.) The benchmarks are done using code from [1]; the test
repository consists of a linear series of 20000 commits (with very
little content) and 10000 tags (on every second commit); the tags are
unsharded. The numbers are times in seconds; "cold" means that the disk
cache was flushed immediately before the test; "warm" usually means that
the same operation was done a second time.
Column #0 is Git 1.7.7.2; column #1 is Git 1.7.8-rc2; column #2 is a
recent git master plus my ref-related patch series (what Junio calls
mh/ref-api-take-2 plus the fix that I posted yesterday).
The main change between 1.7.7.2 and 1.7.8 is that the latter stores the
reference cache in a sorted array rather than a linked list, meaning
that it is possible to use bisection to locate a reference quickly by
name rather than having to search linearly through a linked list. This
greatly helps some operations when most references are packed and can be
read from disk quickly. It doesn't make much difference when most
references are loose, because the time required to read the loose
references from disk overwhelms the time for iterating through the array
in memory.
The main improvements between 1.7.8 and the new version are when the old
code would have read all of the loose references but the new code only
needs to read a couple of directories of them. Given that almost all of
the references in the test repository are tags, they often don't need to
be read at all when branches are being manipulated. By contrast, many
old code paths force *all* of the references to be read, for example
when they check for replacements in refs/replace/.
I've done other benchmarks with varying numbers of references. The
results suggest that many operations go from O(N) in the number of loose
references to O(1) (e.g., if all they do is check refs/replace/) or some
other slow scaling that depends on how the reference namespace is organized.
Anything involving packed references necessarily scales at least like
O(N) because packed references are all read at once. OTOH reading
packed refs is so much faster than reading loose references that with
10000 references, packing is still advantageous. (For some number of
references, of course, the curves must cross and loose references will
be more efficient than packed references for some operations.)
The case of git-filter-branch is particularly dramatic; the old code
scales like O(N^2) whereas the new code scales like O(N) as expected.
Moreover, git-filter-branch creates lots of loose references while it
works, so it is not possible to evade the problem by packing the
references before invoking git-filter-branch. I believe that
git-filter-branch is mostly slowed down be each subcommand's check for
replacements in refs/replace (even though there are none in my test
repository) because in the old code this check forces *all* loose
references to be read. Versions 1.7.7 and 1.7.8 of git-filter-branch
runs much faster if the --no-replace-objects option is used.
With these changes, it becomes thinkable to work with repositories with
very large numbers of references (especially if the reference namespace
is sharded appropriately), whereas in 1.7.7 some operations were
annoyingly slow.
Michael
[1] branch "refperf" at git://github.com/mhagger/git.git
> =================================== ======== ======== ========
> Test name [0] [1] [2]
> =================================== ======== ======== ========
> branch-loose-cold 1.59 1.68 0.29
> branch-loose-warm 0.04 0.04 0.00
> for-each-ref-loose-cold 1.86 1.96 1.88
> for-each-ref-loose-warm 0.10 0.10 0.11
> checkout-loose-cold 1.66 1.86 0.39
> checkout-loose-warm 0.04 0.05 0.01
> checkout-orphan-loose 0.04 0.04 0.00
> checkout-from-detached-loose-cold 2.04 2.11 1.81
> checkout-from-detached-loose-warm 0.24 0.15 0.16
> branch-contains-loose-cold 1.79 1.86 1.87
> branch-contains-loose-warm 0.14 0.14 0.14
> pack-refs-loose 0.49 0.53 0.53
> branch-packed-cold 0.28 0.25 0.25
> branch-packed-warm 0.02 0.00 0.00
> for-each-ref-packed-cold 0.34 0.39 0.40
> for-each-ref-packed-warm 0.07 0.07 0.07
> checkout-packed-cold 2.81 0.50 0.55
> checkout-packed-warm 0.01 0.00 0.01
> checkout-orphan-packed 0.00 0.00 0.00
> checkout-from-detached-packed-cold 2.83 0.55 0.46
> checkout-from-detached-packed-warm 2.45 0.12 0.13
> branch-contains-packed-cold 0.38 0.32 0.43
> branch-contains-packed-warm 0.11 0.11 0.11
> clone-loose-cold 30.16 30.31 30.51
> clone-loose-warm 1.28 1.30 1.33
> fetch-nothing-loose 0.21 0.39 0.38
> pack-refs 0.14 0.12 0.14
> fetch-nothing-packed 0.21 0.40 0.39
> clone-packed-cold 1.07 1.24 1.18
> clone-packed-warm 0.23 0.23 0.22
> fetch-everything-cold 30.49 30.89 31.09
> fetch-everything-warm 1.78 2.01 2.06
> filter-branch-warm 2949.81 2891.51 440.60
> =================================== ======== ======== ========
>
>
> [0] 8d19b44 (tag: v1.7.7.2) Git 1.7.7.2
> Test repository created using: t/make-refperf-repo --commits 20000 --refs 10000
> [1] bc1bbe0 (tag: v1.7.8-rc2) Git 1.7.8-rc2
> Test repository created using: t/make-refperf-repo --commits 20000 --refs 10000
> [2] 01494b4 (github/ref-api-D) repack_without_ref(): call clear_packed_ref_cache()
> Test repository created using: t/make-refperf-repo --commits 20000 --refs 10000
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Finding info about git svn
From: Sverre Rabbelier @ 2011-11-16 12:39 UTC (permalink / raw)
To: git; +Cc: John 'Warthog9' Hawley, Tim van Heugten, Petr Baudis
In-Reply-To: <CAEtpghyV+w_9hN-hF_Z2MbKAUKyen6e=E9-XSyPxawAyamy3oA@mail.gmail.com>
Heya,
[+git, without HTML part this time, and trying Petr's other address]
On Wed, Nov 16, 2011 at 13:32, Tim van Heugten <stimme@gmail.com> wrote:
> Hi,
>
> When I was looking for info on git svn, the first google hit took me to
> http://git.or.cz/course/svn.html.
> The first thing on the page I notice is a message that the page is no longer
> maintained.
> Unfortunately, GitCrashCourse link from http://git.or.cz/course/svn.html
> gives a 404.
>
> Instead I moved to the root at https://git.wiki.kernel.org to find out more
> about git svn.
> In my hurry I just wanted to jump to the relevant page, and started a
> search.
> Unfortunately, performing a search on git.wiki.kernel.org gives a 404.
>
> I found the relevant page the 'slow' way ;), but I suggest you have a look
> at the search.
> Btw. via the slow way, on the Documentation page I find this: "Git SVN crash
> course (superseded by GitSvnCrashCourse)" - a link back to git.or.cz.
> Shouldn't this link be removed, since it is superseded?
>
> Thanks!
>
>
> Tim van Heugten
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] apply: squash consecutive slashes with p_value > 0
From: Robie Basak @ 2011-11-16 12:04 UTC (permalink / raw)
To: git
"patch" works with -p1 and diffs in the following form:
--- foo.orig//bar
+++ foo//bar
...
patch(1) says that "A sequence of one or more adjacent slashes is
counted as a single slash."
This patch amends git-apply's filename parsing to behave in the same
way, eliminating both '/'s with -p1 in this example.
Test case included.
Signed-off-by: Robie Basak <robie.basak@canonical.com>
---
builtin/apply.c | 8 ++++++--
t/t4153-apply-doubleslash.sh | 29 +++++++++++++++++++++++++++++
2 files changed, 35 insertions(+), 2 deletions(-)
create mode 100755 t/t4153-apply-doubleslash.sh
diff --git a/builtin/apply.c b/builtin/apply.c
index 84a8a0b..78e25fa 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -627,9 +627,13 @@ static char *find_name_common(const char *line, char *def, int p_value,
if (name_terminate(start, line-start, c, terminate))
break;
}
- line++;
- if (c == '/' && !--p_value)
+ if (c == '/' && !--p_value) {
+ while (*line == '/')
+ line++;
start = line;
+ } else {
+ line++;
+ }
}
if (!start)
return squash_slash(def);
diff --git a/t/t4153-apply-doubleslash.sh b/t/t4153-apply-doubleslash.sh
new file mode 100755
index 0000000..1ea76b5
--- /dev/null
+++ b/t/t4153-apply-doubleslash.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+#
+# Copyright (c) 2011 Canonical Ltd.
+#
+
+test_description='git apply filenames with double slashes
+
+Try to apply a patch with git-apply where the filename specified has a double
+slash after the first (to-be-stripped) component'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ test_commit 1 f &&
+ cat > good.patch <<EOF
+diff -u a//f b//f
+--- a//f
++++ b//f
+@@ -1 +1 @@
+-1
++2
+EOF
+'
+
+test_expect_success 'apply diff with double slashes in filenames' '
+ git apply good.patch 2>err
+'
+
+test_done
--
1.7.5.4
^ permalink raw reply related
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