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