* 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
* Re: Git 1.7.5 problem with HTTPS
From: Dmitry Smirnov @ 2011-11-17 6:36 UTC (permalink / raw)
To: git
In-Reply-To: <CACf55T6BGds_D=nbb8G=m+Jwr+bHFruCs-Q0+FOO+WXitXEJ-g@mail.gmail.com>
I had fixed the problem by manually installing the most recent version
of the libcurl3-gnutls for Ubuntu (from precise):
http://packages.ubuntu.com/precise/libcurl3-gnutls
It will require also most recent libgnutls:
http://packages.ubuntu.com/precise/libgnutls26
Dmitry
^ permalink raw reply
* What's cooking in git.git (Nov 2011, #04; Wed, 16)
From: Junio C Hamano @ 2011-11-17 6:46 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
One nasty regression killed, hopefully we are good to go for the third
release candidate tomorrow.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* jk/refresh-porcelain-output (2011-11-14) 5 commits
- perhaps squash? show intent-to-add entries as "A" in verbose refresh
- refresh_index: notice typechanges in output
- read-cache: let refresh_cache_ent pass up changed flags
- refresh_index: mark deletions in porcelain output
- refresh_index: rename format variables
The tip two commits need to be squashed into one.
* ab/enable-i18n (2011-11-14) 1 commit
- i18n: add infrastructure for translating Git with gettext
* gh/userdiff-matlab (2011-11-15) 1 commit
- Add built-in diff patterns for MATLAB code
* jc/maint-pack-object-cycle (2011-11-16) 1 commit
- pack-object: tolerate broken packs that have duplicated objects
Make the client side more robust against bogus pack stream; the problem
was discovered by accident while repacking a clone obtained from somewhat
buggy test server.
* jc/index-pack-reject-dups (2011-11-16) 1 commit
- receive-pack, fetch-pack: reject bogus pack that records objects twice
And this is the prevention to reject such pack stream in the first place.
* jc/maint-name-rev-all (2011-11-15) 1 commit
- name-rev --all: do not even attempt to describe non-commit object
Fix for a corner-case bug? that was present from day one of the command.
* ml/mailmap (2011-11-16) 1 commit
- mailmap: xcalloc mailmap_info
An obvious(ly correct) cleanup.
* rr/misc-fixes (2011-11-15) 4 commits
- git-compat-util: don't assume value for undefined variable
- sha1_file: don't mix enum with int
- convert: don't mix enum with int
- http: remove unused function hex()
Obvious(ly correct) cleanups.
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-10-26 at d65e2b4)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
Will keep in 'next' during this cycle.
Needs an Ack or two from completion folks before going forward.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
See comments on sr/fix-fast-export-tips topic.
* sr/fix-fast-export-tips (2011-11-05) 3 commits
- fast-export: output reset command for commandline revs
- fast-export: do not refer to non-existing marks
- t9350: point out that refs are not updated correctly
The bottom commit from the stalled sr/transport-helper-fix-rfc topic is
fixed with this. It may make sense to drop the other topic and include
that commit in this series.
The command line parser is still too lax and accepts malformed input, but
this is a step in the right direction and tightening the command line now
should be doable without a low level surgery that touches codepaths that
are unrelated to the command line processing like the previous attempt
used to do.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
* eh/grep-scale-to-cpunum (2011-11-05) 1 commit
- grep: detect number of CPUs for thread spawning
Kills I/O parallelism and needs to be improved or discarded.
* jc/commit-tree-extra (2011-11-12) 2 commits
- commit-tree: teach -C <extra-commit>
- commit-tree: teach -x <extra>
(this branch uses jc/pull-signed-tag; is tangled with jc/signed-commit.)
Not absolutely needed; parked in 'pu' but may drop.
--------------------------------------------------
[Cooking]
* nd/resolve-ref (2011-11-13) 2 commits
- Copy resolve_ref() return value for longer use
- Convert many resolve_ref() calls to read_ref*() and ref_exists()
A fix for an error-reporting codepath that is not a regression, that
turned into a patch that touches many callsite.
* vr/msvc (2011-10-31) 3 commits
(merged to 'next' on 2011-11-14 at f46d021)
+ MSVC: Remove unneeded header stubs
+ Compile fix for MSVC: Include <io.h>
+ Compile fix for MSVC: Do not include sys/resources.h
Will keep in 'next' during this cycle.
* na/strtoimax (2011-11-05) 3 commits
(merged to 'next' on 2011-11-14 at b64e1cb)
+ Support sizes >=2G in various config options accepting 'g' sizes.
+ Compatibility: declare strtoimax() under NO_STRTOUMAX
+ Add strtoimax() compatibility function.
Will keep in 'next' during this cycle.
* jc/signed-commit (2011-11-12) 4 commits
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
(this branch uses jc/pull-signed-tag; is tangled with jc/commit-tree-extra.)
Rebased on top of jc/pull-signed-tag topic, after reverting the old one
out of 'next'.
* jc/pull-signed-tag (2011-11-12) 15 commits
(merged to 'next' on 2011-11-14 at 25e8838)
+ commit-tree: teach -m/-F options to read logs from elsewhere
+ commit-tree: update the command line parsing
+ commit: teach --amend to carry forward extra headers
+ merge: force edit and no-ff mode when merging a tag object
+ commit: copy merged signed tags to headers of merge commit
+ merge: record tag objects without peeling in MERGE_HEAD
+ merge: make usage of commit->util more extensible
+ fmt-merge-msg: Add contents of merged tag in the merge message
+ fmt-merge-msg: package options into a structure
+ fmt-merge-msg: avoid early returns
+ refs DWIMmery: use the same rule for both "git fetch" and others
+ fetch: allow "git fetch $there v1.0" to fetch a tag
+ merge: notice local merging of tags and keep it unwrapped
+ fetch: do not store peeled tag object names in FETCH_HEAD
+ Split GPG interface into its own helper library
(this branch is used by jc/commit-tree-extra and jc/signed-commit.)
Further updated to allow "commit --amend" to retain the mergetag
headers. I think this is ready for the cycle after upcoming 1.7.8.
Will keep in 'next' during this cycle.
* jc/request-pull-show-head-4 (2011-11-09) 12 commits
(merged to 'next' on 2011-11-13 at e473fd2)
+ request-pull: use the annotated tag contents
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements. It also allows requesting for
a signed tag to be pulled and shows the tag message in the generated message.
Will keep in 'next' during this cycle.
* ab/clang-lints (2011-11-06) 2 commits
(merged to 'next' on 2011-11-13 at a573aec)
+ cast variable in call to free() in builtin/diff.c and submodule.c
+ apply: get rid of useless x < 0 comparison on a size_t type
Will keep in 'next' during this cycle.
* ab/pull-rebase-config (2011-11-07) 1 commit
(merged to 'next' on 2011-11-13 at 72bb2d5)
+ pull: introduce a pull.rebase option to enable --rebase
Will keep in 'next' during this cycle.
* nd/fsck-progress (2011-11-06) 4 commits
(merged to 'next' on 2011-11-13 at 8831811)
+ fsck: print progress
+ fsck: avoid reading every object twice
+ verify_packfile(): check as many object as possible in a pack
+ fsck: return error code when verify_pack() goes wrong
Will keep in 'next' during this cycle.
* nd/prune-progress (2011-11-07) 3 commits
(merged to 'next' on 2011-11-13 at c5722ac)
+ reachable: per-object progress
+ prune: handle --progress/no-progress
+ prune: show progress while marking reachable objects
Will keep in 'next' during this cycle.
* jc/stream-to-pack (2011-11-03) 4 commits
- Bulk check-in
- finish_tmp_packfile(): a helper function
- create_tmp_packfile(): a helper function
- write_pack_header(): a helper function
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. I think this
codepath to move data from worktree to repository needs to become aware of
streaming, just like the checkout codepath that goes the other way, which
was done in the previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
- gitweb: Add navigation to select side-by-side diff
- gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
- t9500: Add basic sanity tests for side-by-side diff in gitweb
- t9500: Add test for handling incomplete lines in diff by gitweb
- gitweb: Give side-by-side diff extra CSS styling
- gitweb: Add a feature to show side-by-side diff
- gitweb: Extract formatting of diff chunk header
- gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
* mf/curl-select-fdset (2011-11-04) 4 commits
(merged to 'next' on 2011-11-06 at a49516f)
+ http: drop "local" member from request struct
+ http.c: Rely on select instead of tracking whether data was received
+ http.c: Use timeout suggested by curl instead of fixed 50ms timeout
+ http.c: Use curl_multi_fdset to select on curl fds instead of just sleeping
Reduces unnecessary waits.
Will keep in 'next' during this cycle.
* nd/misc-cleanups (2011-10-27) 6 commits
(merged to 'next' on 2011-10-28 at 2527a49)
+ unpack_object_header_buffer(): clear the size field upon error
+ tree_entry_interesting: make use of local pointer "item"
+ tree_entry_interesting(): give meaningful names to return values
+ read_directory_recursive: reduce one indentation level
+ get_tree_entry(): do not call find_tree_entry() on an empty tree
+ tree-walk.c: do not leak internal structure in tree_entry_len()
These are unquestionably good parts taken out of a larger series, so that
we can focus more on the other changes in later rounds of review.
Will keep in 'next' during this cycle.
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
(merged to 'next' on 2011-10-27 at 2e4acd6)
+ cache.h: put single NUL at end of struct cache_entry
+ read-cache.c: allocate index entries individually
Will keep in 'next' during this cycle.
* mh/ref-api-3 (2011-11-16) 26 commits
(merged to 'next' on 2011-11-16 at cc76151)
+ refs: loosen over-strict "format" check
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is tangled with mh/ref-api-2.)
Will keep in 'next' during this cycle.
* rr/revert-cherry-pick (2011-10-23) 5 commits
(merged to 'next' on 2011-10-26 at 27b7496)
+ revert: simplify communicating command-line arguments
+ revert: allow mixed pick and revert instructions
+ revert: make commit subjects in insn sheet optional
+ revert: simplify getting commit subject in format_todo()
+ revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will keep in 'next' during this cycle.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* mh/ref-api-2 (2011-11-16) 15 commits
(merged to 'next' on 2011-11-16 at 511457f)
+ refs: loosen over-strict "format" check
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is tangled with mh/ref-api-3.)
Will keep in 'next' during this cycle.
^ permalink raw reply
* Re: [PATCH 3/3] rename git_path() to git_path_unsafe()
From: Jonathan Nieder @ 2011-11-17 7:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, Git List,
Nguyễn Thái Ngọc Duy
In-Reply-To: <7vzkfvo88i.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> 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.
Fine, but what about the buffer overflow (not an incredibly recent
regression, but certainly a fix) addressed in patch 2 of the series?
^ permalink raw reply
* BUG. git rebase -i successfully continues (and also skips rewording) when pre-commit hook fails (exits with non-zero code)
From: Alexey Shumkin @ 2011-11-17 8:58 UTC (permalink / raw)
To: git
For a project I have a pre-commit hook that monitors
whether files in a folder (scripts of DB) changed or not
and fails if another special file (DB version) did not changed, too.
So, I did some commits and then I decided to change the order of them.
Of course, I used a lovely "git rebase -i" command. I changed the order
of the commits, then rebasing went ok. But I noticed that my pre-commit
hook output failure message (one of the commits did not meet
above-mentioned condition). It's not too bad but ugly. But when I
decided to correct a message of that specific commit I ran
"git rebase -i" again, marked that commit for rewording, rewording did
not start (because pre-commit hook failed, obviously) and rebasing went
on (commit had an unchanged message) and successfully finished. That is
not what I expected.
I guess if any of hooks fail (which usually fail the commit), rebasing
have to be interrupted (as when there are conflicts)
Here is a sample to reproduce the error
git init .
echo content > file
git add -fv file
git commit -a -m 'first commit'
echo line 2 >> file
git commit -a -m 'secont commit' # note a typo ;)
echo '#!/bin/bash
echo commit failed
exit 1' > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
echo fail >> file
git commit -a -m 'failed commit' # to show that pre-commit hook fails
# and outputs "commit failed"
git reset --hard
git rebase -i HEAD^
# mark commit for rewording and exit an editor
note following output after all this:
>commit fail/1)
>Successfully rebased and updated refs/heads/master
^ 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