* 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
* 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: 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
* 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: [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
* [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 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
* 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: 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: 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
* 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: 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
* [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
* [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
* 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
* 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: [patch] color of branches in git status -sb
From: Junio C Hamano @ 2011-11-17 1:13 UTC (permalink / raw)
To: Nicolas Dudebout; +Cc: git
In-Reply-To: <CA+TMmKns-9jiedxY4FiJoBg8akkxwkPBib11EmvCD3r7mRA6vQ@mail.gmail.com>
Nicolas Dudebout <nicolas.dudebout@gmail.com> writes:
> 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
Please follow Documentation/SubmittingPatches.
Also expect that patches to add new feature this deep in the pre-release
feature freeze period is not likely to get reviewed by regular list
members.
>
> Modified Documentation/config.txt
Don't do this. We can tell what is modified from "diff --git" lines.
> 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
Don't do this. Proper patches have context lines for good reasons.
> 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
* Re: [PATCH 3/3] rename git_path() to git_path_unsafe()
From: Junio C Hamano @ 2011-11-17 1:20 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20111116080716.GE13706@elie.hsd1.il.comcast.net>
Given that other functions like real_path() and mkpath() share the same
"perishable, use it immediately" property, and also git_path() is such a
short and sweet name, I am beginning to think that we probably should
leave these alone but document that *path() are "unsafe" somewhere and
just add *path_cpy() or your strbuf_addpath() function.
In any case, I do not like seeing many list regulars throwing too many
non-regression-fix patches during prerelease freeze period on the
list. Continuing development for the next cycle is encouraged and trying
to do so using workflows that you do not usually use is even more
encouraged, though. You would make more use of the release candidate Git
for such activities, and may uncover regressions before the final.
Thanks.
^ permalink raw reply
* [PATCH] mailmap: xcalloc mailmap_info
From: Marc-André Lureau @ 2011-11-17 1:25 UTC (permalink / raw)
To: git; +Cc: Marc-André Lureau
In-Reply-To: <7v8vnfpn9v.fsf@alter.siamese.dyndns.org>
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.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
---
mailmap.c | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index 02fcfde..8c3196c 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -70,8 +70,7 @@ static void add_mapping(struct string_list *map,
} else {
/* create mailmap entry */
struct string_list_item *item = string_list_insert_at_index(map, index, old_email);
- item->util = xmalloc(sizeof(struct mailmap_entry));
- memset(item->util, 0, sizeof(struct mailmap_entry));
+ item->util = xcalloc(1, sizeof(struct mailmap_entry));
((struct mailmap_entry *)item->util)->namemap.strdup_strings = 1;
}
me = (struct mailmap_entry *)map->items[index].util;
@@ -88,7 +87,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: [patch] color of branches in git status -sb
From: Nicolas Dudebout @ 2011-11-17 2:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4ny3pn4v.fsf@alter.siamese.dyndns.org>
Please disregard this as a patch. I do not have the time to understand
how they have to be properly formatted. I just pasted the output of my
git client.
I am just letting you know that there is a problem that can be easily
fixed. I can resend a separate email if that makes it easier for your
bug tracking.
On Wed, Nov 16, 2011 at 8:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nicolas Dudebout <nicolas.dudebout@gmail.com> writes:
>
>> 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
>
> Please follow Documentation/SubmittingPatches.
>
> Also expect that patches to add new feature this deep in the pre-release
> feature freeze period is not likely to get reviewed by regular list
> members.
>
>>
>> Modified Documentation/config.txt
>
> Don't do this. We can tell what is modified from "diff --git" lines.
>
>> 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
>
> Don't do this. Proper patches have context lines for good reasons.
>
>> 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
* Re: git clone --reference not working
From: Michael Haggerty @ 2011-11-17 4:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrea Arcangeli, git
In-Reply-To: <7vobwbpnzr.fsf@alter.siamese.dyndns.org>
On 11/17/2011 01:54 AM, Junio C Hamano wrote:
> 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
> [...]
I reviewed the patch (and ran the test suite here for good measure).
Looks good.
>From SubmittingPatches it looks like I should authorize
Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu>
Is there a standard way to do so?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Suggestions for gitk
From: Michael Haggerty @ 2011-11-17 5:53 UTC (permalink / raw)
To: git discussion list, Paul Mackerras
I use gitk every day and love it. I have a few suggestions that IMO
would make it even better. Please note that I've been collecting these
ideas for a while, and they are only small niggles about an excellent tool.
1. Add a "HEAD" button
Frequently I want to jump to the HEAD revision after having moved around
in the history for a while. Since HEAD is not always at the top of the
revision list, I do this by typing "HEAD" into the "SHA1 ID" field. Is
there a better way already? If not, I think it would be very convenient
to have a small "HEAD" button near that field that causes gitk to jump
there.
2. Option to check out new branch
After I "Create new branch", I often want to check out the new branch
(the equivalent of "git checkout -b BRANCH REV"). So it would be
convenient if the dialog opened by right-clicking on a commit and select
"Create new branch" offered the option to check out the newly-created
branch. For example, it could have a third confirmation button "Create
and check out", or it could have a tick box "Check out new branch".
3. Allow "Branches: many (N)" to be expanded
There is some limit above which the commit window doesn't list the
branches that contain the commit, but instead displays "Branches: many
(N)". But sometimes one wants to know anyway. For example, the field
could be a link that one could click on to open a dialog box listing all
of the branches containing the commit.
In fact, a tabular format would often be more convenient than the
current format (which is hard to skim through due to its horizontal
layout and often scrolls off the right side of the screen) even if there
are only a few branches, and the same applies to "Tags", "Precedes",
etc. So perhaps this dialog could be made available in all cases, even
if the branches/tags/etc are expanded in the commit summary.
4. Hide "commit" part of window
When I'm trying to get an overview of the history, I am often not
interested in the commit summary. So it would be great if there were a
hotkey to hide the "commit" part of the window and allow the "log" part
of the window to use the whole surface. This would be like
Thunderbird's "F8" key (which I also use all the time), so if this
feature is implemented you might consider using "F8" for it.
5. Tab completion in "SHA1 ID" field
It would be wonderful if the SHA1 ID field supported some kind of tab
completion for branch names, similar to that offered by the git mode for
bash. Currently it is painful to type a long branch name into this field.
6. Display "git log" command line
I assume that gitk is using something like "git log" to generate the
list of commits that it displays. The "git log" command line can be
configured quite flexibly using the "F4" dialog. So flexibly, in fact,
that I often wonder what options it is passing to "git log". I think it
would be cool if gitk would display the "git log" command line that
corresponds to the options currently selected in the "F4" dialog.
7. Tags squeeze out commit message in the "log" window
If a commit has a tag, the tag is listed next in the first column of the
"log" window, pushing the first line of the commit message off to the
right. If a commit has multiple tags, it can easily happen that the
tags push the commit's log message completely out of the window. There
is no scrollbar, so there is no way to see the commit message in this
situation.
The inability to read the commit message is not such a problem, because
one can select the commit and see the commit message in the bottom part
of the window. More frustrating is that in this situation, it is
impossible to get to the menu that is normally accessed by
right-clicking on the commit message.
So perhaps the menu could also be made available elsewhere, for example
by right-clicking on the blue dot on the "graph" part of the display,
and/or by right clicking on author and date associated with the commit.
I don't know tcl/tk; otherwise I'd try to make some of these changes by
myself...
Thanks for listening,
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: git clone --reference not working
From: Junio C Hamano @ 2011-11-17 5:55 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Andrea Arcangeli, git
In-Reply-To: <4EC4926D.5050004@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 11/17/2011 01:54 AM, Junio C Hamano wrote:
> ...
> Looks good.
>
>>From SubmittingPatches it looks like I should authorize
>
> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu>
>
> Is there a standard way to do so?
That's perfect. I asked for an extra set of eyeballs from somebody who is
familiar with the codepath that had a problem, and that person eyeballed
and found the change to be an appropriate fix to the problem.
Either Acked-by or Reviewed-by is fine by me.
As a tentative measure, for tonight's pushout, I am inclined to queue an
equivalent of this patch on top of both mh/ref-api-2 and mh/ref-api-3
topic and merge them to 'next' and 'pu'. I'd appreciate if you can double
check the two merges on master..pu after I push them out in a few hours.
Thanks.
^ permalink raw reply
* [PATCH] pack-object: tolerate broken packs that have duplicated objects
From: Junio C Hamano @ 2011-11-17 6:04 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
When --reuse-delta is in effect (which is the default), and an existing
pack in the repository has the same object registered twice (e.g. one copy
in a non-delta format and the other copy in a delta against some other
object), an attempt to repack the repository can result in a cyclic delta
dependency, causing write_one() function to infinitely recurse into
itself.
Detect such a case and break the loopy dependency by writing out an object
that is involved in such a loop in the non-delta format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This may need to be cherry-picked to earlier maintenance series. The
topic I queued tonight is built on v1.7.6.4.
builtin/pack-objects.c | 55 +++++++++++++++++++++++++++++++++++++----------
1 files changed, 43 insertions(+), 12 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index c6e2d87..5ae808b 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -404,25 +404,56 @@ static unsigned long write_object(struct sha1file *f,
return hdrlen + datalen;
}
-static int write_one(struct sha1file *f,
- struct object_entry *e,
- off_t *offset)
+enum write_one_status {
+ WRITE_ONE_SKIP = -1, /* already written */
+ WRITE_ONE_BREAK = 0, /* writing this will bust the limit; not written */
+ WRITE_ONE_WRITTEN = 1, /* normal */
+ WRITE_ONE_RECURSIVE = 2 /* already scheduled to be written */
+};
+
+static enum write_one_status write_one(struct sha1file *f,
+ struct object_entry *e,
+ off_t *offset)
{
unsigned long size;
+ int recursing;
- /* offset is non zero if object is written already. */
- if (e->idx.offset || e->preferred_base)
- return -1;
+ /*
+ * we set offset to 1 (which is an impossible value) to mark
+ * the fact that this object is involved in "write its base
+ * first before writing a deltified object" recursion.
+ */
+ recursing = (e->idx.offset == 1);
+ if (recursing) {
+ warning("recursive delta detected for object %s",
+ sha1_to_hex(e->idx.sha1));
+ return WRITE_ONE_RECURSIVE;
+ } else if (e->idx.offset || e->preferred_base) {
+ /* offset is non zero if object is written already. */
+ return WRITE_ONE_SKIP;
+ }
/* if we are deltified, write out base object first. */
- if (e->delta && !write_one(f, e->delta, offset))
- return 0;
+ if (e->delta) {
+ e->idx.offset = 1; /* now recurse */
+ switch (write_one(f, e->delta, offset)) {
+ case WRITE_ONE_RECURSIVE:
+ /* we cannot depend on this one */
+ e->delta = NULL;
+ break;
+ default:
+ break;
+ case WRITE_ONE_BREAK:
+ e->idx.offset = recursing;
+ return WRITE_ONE_BREAK;
+ }
+ }
e->idx.offset = *offset;
size = write_object(f, e, *offset);
if (!size) {
- e->idx.offset = 0;
- return 0;
+ e->idx.offset = recursing;
+ return WRITE_ONE_BREAK;
}
written_list[nr_written++] = &e->idx;
@@ -430,7 +461,7 @@ static int write_one(struct sha1file *f,
if (signed_add_overflows(*offset, size))
die("pack too large for current definition of off_t");
*offset += size;
- return 1;
+ return WRITE_ONE_WRITTEN;
}
static void write_pack_file(void)
@@ -468,7 +499,7 @@ static void write_pack_file(void)
offset = sizeof(hdr);
nr_written = 0;
for (; i < nr_objects; i++) {
- if (!write_one(f, objects + i, &offset))
+ if (write_one(f, objects + i, &offset) == WRITE_ONE_BREAK)
break;
display_progress(progress_state, written);
}
--
1.7.8.rc2.109.g72037
^ permalink raw reply related
* [PATCH] receive-pack, fetch-pack: reject bogus pack that records objects twice
From: Junio C Hamano @ 2011-11-17 6:04 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
When receive-pack & fetch-pack are run and store the pack obtained over
the wire to a local repository, they internally run the index-pack command
with the --strict option. Make sure that we reject incoming packfile that
records objects twice to avoid spreading such a damage.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Passing --strict from fetch-pack actually is a recent invention, so
this will be only useful to 1.7.8 and later.
builtin/index-pack.c | 4 +++-
object.c | 2 ++
pack-write.c | 4 ++++
pack.h | 3 ++-
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 0945adb..98025da 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1122,8 +1122,10 @@ int cmd_index_pack(int argc, const char **argv, const char *prefix)
if (!index_name)
die("--verify with no packfile name given");
read_idx_option(&opts, index_name);
- opts.flags |= WRITE_IDX_VERIFY;
+ opts.flags |= WRITE_IDX_VERIFY | WRITE_IDX_STRICT;
}
+ if (strict)
+ opts.flags |= WRITE_IDX_STRICT;
curr_pack = open_pack_file(pack_name);
parse_pack_header();
diff --git a/object.c b/object.c
index 31976b5..d8d09f9 100644
--- a/object.c
+++ b/object.c
@@ -149,6 +149,8 @@ struct object *parse_object_buffer(const unsigned char *sha1, enum object_type t
struct tree *tree = lookup_tree(sha1);
if (tree) {
obj = &tree->object;
+ if (!tree->buffer)
+ tree->object.parsed = 0;
if (!tree->object.parsed) {
if (parse_tree_buffer(tree, buffer, size))
return NULL;
diff --git a/pack-write.c b/pack-write.c
index 9cd3bfb..f84adde 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -129,6 +129,10 @@ const char *write_idx_file(const char *index_name, struct pack_idx_entry **objec
}
sha1write(f, obj->sha1, 20);
git_SHA1_Update(&ctx, obj->sha1, 20);
+ if ((opts->flags & WRITE_IDX_STRICT) &&
+ (i && !hashcmp(list[-2]->sha1, obj->sha1)))
+ die("The same object %s appears twice in the pack",
+ sha1_to_hex(obj->sha1));
}
if (index_version >= 2) {
diff --git a/pack.h b/pack.h
index 722a54e..aca4739 100644
--- a/pack.h
+++ b/pack.h
@@ -37,7 +37,8 @@ struct pack_header {
struct pack_idx_option {
unsigned flags;
/* flag bits */
-#define WRITE_IDX_VERIFY 01
+#define WRITE_IDX_VERIFY 01 /* verify only, do not write the idx file */
+#define WRITE_IDX_STRICT 02
uint32_t version;
uint32_t off32_limit;
--
1.7.8.rc2.109.g72037
^ 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