* Re: [PATCH] gitk: disable checkout of remote branch
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90911030800j22b00372r99a56c3f847a3644@mail.gmail.com>
Sitaram Chamarty writes:
> This prevents a lot of detached HEAD commits by new users.
>
> Signed-off-by: Sitaram Chamarty <sitaramc@gmail.com>
Thanks, applied.
Paul.
^ permalink raw reply
* Re: gitk: Update Japanese translation
From: Paul Mackerras @ 2009-11-14 11:14 UTC (permalink / raw)
To: Mizar; +Cc: git, gitster
In-Reply-To: <d092a4360911060557v970753fn2294124aedda93ec@mail.gmail.com>
Mizar writes:
> The main changes are as follows.
> Several issues remain and is pending because there is no improvement.
> http://github.com/mizar/gitk/issues
Thanks, applied.
Paul.
^ permalink raw reply
* Re: GNU patch: new 2.6 release
From: Björn Gustavsson @ 2009-11-14 12:27 UTC (permalink / raw)
To: bug-patch; +Cc: git
In-Reply-To: <200911141117.29238.agruen@suse.de>
2009/11/14 Andreas Gruenbacher <agruen@suse.de>:
> Support for git's extended header lines for renames, copies, hashes, file
> modes would be great. I'll happily take patches or eventually implement it
> myself. Binary patches are not as high on my wish list, but feel free to send
> code.
Support for the other extended header lines would be useful for me too.
I might have a go at implementing them (and binary patches) at some
point in the future.
>> That would be very useful in a workflow when you work in git (and have some
>> binary files in the repository), but need to commit your finished work
>> into another VCS (such as Clearcase).
>
> Isn't there a better way to do this than with patches?
If there is a better way, I would be very interested in finding out what it is.
Feeding the output from 'git format-patch' to patch is the
best way I've had come up with yet. patch (given the '-g 1' option)
will automatically check out the files that are to be patched.
I have wrapped that in a simple script that retrieves the commit
comment from the patch and check in the files with that commit
comment.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: [PATCH] Speed up bash completion loading
From: SZEDER Gábor @ 2009-11-14 14:43 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Junio C Hamano,
Shawn O. Pearce, git
In-Reply-To: <20091114110141.GB1829@progeny.tock>
Hi,
On Sat, Nov 14, 2009 at 05:01:41AM -0600, Jonathan Nieder wrote:
> Stephen Boyd wrote:
>
> > I see a small problem, but it can be fixed in another patch. git
> > merge -s <TAB><TAB> the first time when you're not in a git
> > directory will make git merge -s <TAB><TAB> after never complete
> > correctly even in a git directory.
>
> Not good. I think the sanest thing to do is avoid caching the merge
> strategy list entirely. Listing merge strategies takes about 100 ms
> here, which is short enough not to be annoying.
>
> > I guess this become more serious
> > if git isn't in your path initially and you do git <TAB><TAB> and
> > then git becomes part of your path and you try again. Here you lose
> > porcelain completion. This is probably never going to happen though,
> > right?
>
> Right, if this happened to me I would not be too surprised. A similar
> problem occurs when someone installs a new git subcommand in the
> middle of a session. Starting a new session fixes the completion, but
> should the completion script do something to help people before then?
>
> It could provide a shell function with a slightly friendlier name than
> "__git_compute_porcelain_commands" for the user to invoke explicitly.
>
> It could retry "git help -a" each time completion was needed if it
> gave no results last time (i.e. use "${__git_all_commands:=" instead
> of "${__git_all_commands="). This would help with the missing git
> problem (which seems unusual), but not the missing git-svn.
>
> Maybe it could detect signs of user frustration (repeated attempts to
> complete the same thing?) and add to the frustration by silently
> fixing the cache.
Why? Don't get overly creative here, the command
. /path/to/git-completion.bash
already does that, plus it fixes the merge strategy completion issue,
and it's friendly enough for the users.
Best,
Gábor
^ permalink raw reply
* git svn fetch loses data
From: Victor Engmark @ 2009-11-14 17:07 UTC (permalink / raw)
To: git
Hi all,
I've been trying to move from Subversion to Git for a couple days now,
and I can't get git svn to get all my data. The progress so far is
explained at <http://l0b0.wordpress.com/2009/11/14/n-way-git-synchronization-with-extra-cheese/>.
git svn fetch doesn't report any errors, and goes through the entire
repository as regular as anything, but at the end about half of the
root directories are missing. Even the file modified by the last
commit is not there at all. Any ideas why this is?
--
Victor Engmark
^ permalink raw reply
* Re: git svn fetch loses data
From: Sverre Rabbelier @ 2009-11-14 17:25 UTC (permalink / raw)
To: Victor Engmark; +Cc: git
In-Reply-To: <7d4f41f50911140907n285d72dcp7bbe802900f8bae5@mail.gmail.com>
Heya,
On Sat, Nov 14, 2009 at 18:07, Victor Engmark <victor.engmark@gmail.com> wrote:
> but at the end about half of the
> root directories are missing.
Can you be more specific, what is the layout of your repository and
which directories are missing?
/ -- trunk
-- branches
-- tags
-- thirdparty
-- private
If your repository looks like that, and 'thirdparty' and 'private' are
missing, that's because git svn assumes that you're only interested in
trunk, branches and tags by default.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-14 17:27 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, trast, gitster
In-Reply-To: <20091114180123.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Raman Gupta <rocketraman@fastmail.fm>
>
>> Ok, another dumb question: since you have now submitted a patch on top
>> of my patch, what is the proper etiquette for proceeding? Who
>> maintains this patch series until it is committed? Since your patch
>> applies on top of mine I can't really make any more changes without
>> affecting your patch right? I can't find any guidance in the
>> SubmittingPatches document.
>
> What usually happens is that we wait now.
>
> In this case we are in agreement that it is a good idea to apply
> both of our patches (mine was only repeating what Junio said in
> his comments), so if I were you, I would anticipate that Junio
> would apply both of them and start preparing incremental updates
> on top of them now, and send them when the patches appear in his
> 'pu' branch.
>
> Junio has gone quiet for the past few days; maybe he is too busy
> to read or respond to either of our patch. Instead of preparing
> the final text you write in the document in a patch format, it
> may be a better to bring up your ideas here and discuss them
> first. What changes do you have in mind? I think the new section
> now already is in a reasonable shape.
No specific changes -- it was a hypothetical question...
Cheers,
Raman
^ permalink raw reply
* [PATCH] Doc: mention the crlf attribute in config autocrlf section
From: Matthew Ogilvie @ 2009-11-14 18:35 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
The reverse reference has long existed, and the autocrlf description
was actually obsolete and wrong (saying only file content is used),
not just incomplete.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/config.txt | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..0dc6b12 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -169,9 +169,10 @@ core.autocrlf::
writing to the filesystem. The variable can be set to
'input', in which case the conversion happens only while
reading from the filesystem but files are written out with
- `LF` at the end of lines. Currently, which paths to consider
- "text" (i.e. be subjected to the autocrlf mechanism) is
- decided purely based on the contents.
+ `LF` at the end of lines. A file is considered
+ "text" (i.e. be subjected to the autocrlf mechanism) based on
+ the file's `crlf` attribute, or if `crlf` is unspecified,
+ based on the file's contents. See linkgit:gitattributes[5].
core.safecrlf::
If true, makes git check if converting `CRLF` as controlled by
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH] cvsserver doc: database generally can not be reproduced consistently
From: Matthew Ogilvie @ 2009-11-14 18:39 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
A regenerated git-cvsserver database is at risk of having different
CVS revision numbers from an incrementally updated database. Mention
this in the the documentation, and remove an erroneous statement
to the contrary.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/git-cvsserver.txt | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 785779e..99a7c14 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -182,10 +182,9 @@ Database Backend
----------------
'git-cvsserver' uses one database per git head (i.e. CVS module) to
-store information about the repository for faster access. The
-database doesn't contain any persistent data and can be completely
-regenerated from the git repository at any time. The database
-needs to be updated (i.e. written to) after every commit.
+store information about the repository to maintain consistent
+CVS revision numbers. The database needs to be
+updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to
using 'git-cvsserver') the update will need to happen on the
@@ -204,6 +203,18 @@ write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
+The database can not be reliably regenerated in a
+consistent form after the branch it is tracking has changed.
+Example: For merged branches, 'git-cvsserver' only tracks
+one branch of development, and after a 'git-merge' an
+incrementally updated database may track a different branch
+than a database regenerated from scratch, causing inconsistent
+CVS revision numbers. `git-cvsserver` has no way of knowing which
+branch it would have picked if it had been run incrementally
+pre-merge. So if you have to fully or partially (from old
+backup) regenerate the database, you should be suspicious
+of pre-existing CVS sandboxes.
+
You can configure the database backend with the following
configuration variables:
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-14 19:33 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Stephen Boyd, Kirill Smelkov, Sverre Rabbelier, Junio C Hamano,
Shawn O. Pearce, git
In-Reply-To: <20091114144303.GA31540@neumann>
Hi Gábor,
SZEDER Gábor wrote:
> Why? Don't get overly creative here, the command
>
> . /path/to/git-completion.bash
>
> already does that, plus it fixes the merge strategy completion issue,
> and it's friendly enough for the users.
Sounds like a good approach. Squashing this in should get that
working again.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
In this patch, I assume the merge strategy list is not being cached
any more. Something like this would allow recovering from the merge
strategy completion issue, but the victim would have to notice what
went wrong first.
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 634941f..ae39373 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -495,6 +495,7 @@ __git_list_all_commands ()
done
}
+unset __git_all_commands
__git_compute_all_commands ()
{
: ${__git_all_commands=$(__git_list_all_commands)}
@@ -586,6 +587,7 @@ __git_list_porcelain_commands ()
done
}
+unset __git_porcelain_commands
__git_compute_porcelain_commands ()
{
__git_compute_all_commands
--
1.6.5.2
^ permalink raw reply related
* git gc - out of memory
From: Simon Strandgaard @ 2009-11-14 19:26 UTC (permalink / raw)
To: git
My bare repository is on an OpenBSD machine.
I was unaware of the importance of git gc until today
after investigating a problem with "git pull".
So there hasn't been run git gc on the repository ever.
The biggest file in the repository is a 45 mb file.
The repository size is near 2 gb.
What can I do?
$ git gc
Counting objects: 5934, done.
warning: suboptimal pack - out of memory
fatal: Out of memory, malloc failed8)
error: failed to run repack
$ git --version
git version 1.6.5.2
$ uname -a
OpenBSD amiga.opcoders.com 4.3 GENERIC#698 i386
$ ulimit -a
time(cpu-seconds) unlimited
file(blocks) unlimited
coredump(blocks) unlimited
data(kbytes) 524288
stack(kbytes) 4096
lockedmem(kbytes) 662576
memory(kbytes) 1985524
nofiles(descriptors) 128
processes 64
$ du -ks myrepository.git
1859538 myrepository.git
$
Below is the "git pull" problem I'm having. I think its caused
by the former problem. When pulling it dies because of malloc failure.
prompt> git pull
remote: Counting objects: 280, done.
remote: fatal: Out of memory, malloc failed
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption
on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header
prompt> git --version
git version 1.6.5.2
prompt> uname -a
Darwin pidgin.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386
prompt> sw_vers
ProductName: Mac OS X
ProductVersion: 10.5.8
BuildVersion: 9L31a
prompt>
Kind regards
Simon Strandgaard - http://gdtoolbox.com/
^ permalink raw reply
* Re: git svn fetch loses data
From: Victor Engmark @ 2009-11-14 19:29 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911140925r3f7b7806s65da03c046bf5ab4@mail.gmail.com>
On Sat, Nov 14, 2009 at 6:25 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Sat, Nov 14, 2009 at 18:07, Victor Engmark <victor.engmark@gmail.com> wrote:
>> but at the end about half of the
>> root directories are missing.
>
> Can you be more specific, what is the layout of your repository and
> which directories are missing?
>
> / -- trunk
> -- branches
> -- tags
> -- thirdparty
> -- private
> If your repository looks like that, and 'thirdparty' and 'private' are
> missing, that's because git svn assumes that you're only interested in
> trunk, branches and tags by default.
I'm not entirely sure which directories you mean - I've got none of
those, neither in the repository nor the working copy. One of the
directories missing in the top-level directory of the working copy is
"Linux", which contains my .bashrc and tens of other config files.
Which is really odd, because here are the last few lines of "git svn
fetch --revision 993:1879":
r1878 = 3fcec05426b59b0bad43b02cc3c367525d2c0b93 (git-svn)
M Linux/etc/cups/printers.conf
r1879 = 7ab92e8f4bb1a277621d67ba7373f56a694466c1 (git-svn)
After checking this output a bit closer, it turns out only the
directories and files that were retrieved by "git svn clone" (the
first revision only) remain. Where did the files from the "git svn
fetch" go? Do I need to run something after fetch to see them?
--
Victor Engmark
^ permalink raw reply
* Re: git svn fetch loses data
From: Sverre Rabbelier @ 2009-11-14 19:38 UTC (permalink / raw)
To: Victor Engmark; +Cc: git
In-Reply-To: <7d4f41f50911141129n967374ap7d92296c5723e31e@mail.gmail.com>
Heya,
On Sat, Nov 14, 2009 at 20:29, Victor Engmark <victor.engmark@gmail.com> wrote:
> Do I need to run something after fetch to see them?
Your working copy is probably not up to date anymore, try:
$ git rebase git-svn
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Question about "git pull --rebase"
From: Francis Moreau @ 2009-11-14 20:39 UTC (permalink / raw)
To: git
hello,
Let's say I'm on a branch called 'foo'.
I tried to rebase this branch by using 'git pull --rebase'.
I first tried the following command:
$ git pull --rebase origin master:foo
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /dev/shm/git/A
! [rejected] master -> foo (non fast forward)
which failed.
Then I tried:
$ git pull --rebase origin master
which worked.
Reading the man git-pull I would assume the 2 commands are equivalent
but obviously they're not.
So the question is: why ?
Thanks
--
Francis
^ permalink raw reply
* Re: git svn fetch loses data
From: Victor Engmark @ 2009-11-14 20:35 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911141138r5279650ge57db2413e2321a4@mail.gmail.com>
On Sat, Nov 14, 2009 at 8:38 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Sat, Nov 14, 2009 at 20:29, Victor Engmark <victor.engmark@gmail.com> wrote:
>> Do I need to run something after fetch to see them?
>
> Your working copy is probably not up to date anymore, try:
>
> $ git rebase git-svn
Thank you very much! That did the trick. Now to update svn2git.sh...
--
Victor Engmark
^ permalink raw reply
* [gitk] [PATCH] Fix selection of tags.
From: Pat Thoyts @ 2009-11-14 13:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
When a tag is clicked an error is raised due to a missing parameter in
a function call.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 4e2be7f..364c7a8 100755
--- a/gitk
+++ b/gitk
@@ -10489,7 +10489,7 @@ proc showtag {tag isnew} {
set text "[mc "Tag"]: $tag\n[mc "Id"]: $tagids($tag)"
}
appendwithlinks $text {}
- maybe_scroll_ctext
+ maybe_scroll_ctext 1
$ctext conf -state disabled
init_flist {}
}
--
1.6.5.1.1367.gcd48
^ permalink raw reply related
* [PATCH 1/2] http-backend: Fix access beyond end of string.
From: Tarmigan Casebolt @ 2009-11-14 21:10 UTC (permalink / raw)
To: Shawn O . Pearce, git; +Cc: Tarmigan Casebolt
Found with valgrind while looking for Content-Length corruption in
smart http.
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
http-backend.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index f8ea9d7..ab9433d 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -634,7 +634,7 @@ int main(int argc, char **argv)
cmd = c;
cmd_arg = xmalloc(n);
strncpy(cmd_arg, dir + out[0].rm_so + 1, n);
- cmd_arg[n] = '\0';
+ cmd_arg[n-1] = '\0';
dir[out[0].rm_so] = 0;
break;
}
--
1.6.5.51.g191f5
^ permalink raw reply related
* [PATCH 2/2] http-backend: Let gcc check the format of more printf-type functions.
From: Tarmigan Casebolt @ 2009-11-14 21:10 UTC (permalink / raw)
To: Shawn O . Pearce, git; +Cc: Tarmigan Casebolt
In-Reply-To: <1258233058-2348-1-git-send-email-tarmigan+git@gmail.com>
We already have these checks in many printf-type functions that have
prototypes which are in header files. Add these same checks to
static functions in http-backend.c
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Shawn, please consider this patch in addition to the one that you posted
that actually fixes the bug. With this patch, gcc will warn about that bug.
http-backend.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index ab9433d..110b166 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -108,6 +108,7 @@ static const char *get_parameter(const char *name)
return i ? i->util : NULL;
}
+__attribute__((format (printf, 2, 3)))
static void format_write(int fd, const char *fmt, ...)
{
static char buffer[1024];
@@ -165,6 +166,7 @@ static void end_headers(void)
safe_write(1, "\r\n", 2);
}
+__attribute__((format (printf, 1, 2)))
static NORETURN void not_found(const char *err, ...)
{
va_list params;
@@ -180,6 +182,7 @@ static NORETURN void not_found(const char *err, ...)
exit(0);
}
+__attribute__((format (printf, 1, 2)))
static NORETURN void forbidden(const char *err, ...)
{
va_list params;
--
1.6.5.51.g191f5
^ permalink raw reply related
* [PATCH] Check the format of more printf-type functions
From: Tarmigan Casebolt @ 2009-11-14 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tarmigan Casebolt, Miklos Vajna
We already have these checks in many printf-type functions that have
prototypes which are in header files. Add these same checks to some
more prototypes in header functions and to static functions in .c
files.
cc: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
Junio, please consider this for next. It will hopefully catch some bugs like
the Content-Length one in http-backend.c.
One extra warning is
CC merge-recursive.o
merge-recursive.c: In function ‘write_tree_from_memory’:
merge-recursive.c:218: warning: field precision should have type ‘int’, but argument 5 has type ‘size_t’
A fix that might work in practice (because pathnames won't be longer than
an int?) is:
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -215,7 +215,9 @@ struct tree *write_tree_from_memory(struct merge_options *o)
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
if (ce_stage(ce))
- output(o, 0, "%d %.*s", ce_stage(ce), ce_namelen(ce), ce->name);
+ output(o, 0, "%d %.*s", ce_stage(ce), (int)ce_namelen(ce), ce->name);
+ if (ce_namelen(ce) > INT_MAX)
+ die("A filename was too long");
}
return NULL;
}
but I don't think that is likely to be an acceptable fix, so I'm leaving
it for others to make a proper fix. Looks like Miklos touched that line
last, so perhaps he knows of a better fix.
builtin-fsck.c | 2 ++
builtin-update-index.c | 1 +
builtin-upload-archive.c | 1 +
cache.h | 2 ++
color.h | 2 ++
daemon.c | 2 ++
fsck.h | 1 +
imap-send.c | 6 ++++++
merge-recursive.c | 1 +
strbuf.h | 2 +-
10 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 2d88e45..0e5faae 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -47,6 +47,7 @@ static void objreport(struct object *obj, const char *severity,
fputs("\n", stderr);
}
+__attribute__((format (printf, 2, 3)))
static int objerror(struct object *obj, const char *err, ...)
{
va_list params;
@@ -57,6 +58,7 @@ static int objerror(struct object *obj, const char *err, ...)
return -1;
}
+__attribute__((format (printf, 3, 4)))
static int fsck_error_func(struct object *obj, int type, const char *err, ...)
{
va_list params;
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 92beaaf..a6b7f2d 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -27,6 +27,7 @@ static int mark_valid_only;
#define MARK_VALID 1
#define UNMARK_VALID 2
+__attribute__((format (printf, 1, 2)))
static void report(const char *fmt, ...)
{
va_list vp;
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index c4cd1e1..b2d1259 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -67,6 +67,7 @@ static int run_upload_archive(int argc, const char **argv, const char *prefix)
return write_archive(sent_argc, sent_argv, prefix, 0);
}
+__attribute__((format (printf, 1, 2)))
static void error_clnt(const char *fmt, ...)
{
char buf[1024];
diff --git a/cache.h b/cache.h
index 7cec30e..9fdf122 100644
--- a/cache.h
+++ b/cache.h
@@ -964,7 +964,9 @@ extern void *alloc_object_node(void);
extern void alloc_report(void);
/* trace.c */
+__attribute__((format (printf, 1, 2)))
extern void trace_printf(const char *format, ...);
+__attribute__((format (printf, 2, 3)))
extern void trace_argv_printf(const char **argv, const char *format, ...);
/* convert.c */
diff --git a/color.h b/color.h
index 18abeb7..7d8da6f 100644
--- a/color.h
+++ b/color.h
@@ -29,7 +29,9 @@ int git_color_default_config(const char *var, const char *value, void *cb);
int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
void color_parse(const char *value, const char *var, char *dst);
void color_parse_mem(const char *value, int len, const char *var, char *dst);
+__attribute__((format (printf, 3, 4)))
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
+__attribute__((format (printf, 3, 4)))
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
int color_fwrite_lines(FILE *fp, const char *color, size_t count, const char *buf);
diff --git a/daemon.c b/daemon.c
index 1b5ada6..641ebe1 100644
--- a/daemon.c
+++ b/daemon.c
@@ -77,6 +77,7 @@ static void logreport(int priority, const char *err, va_list params)
}
}
+__attribute__((format (printf, 1, 2)))
static void logerror(const char *err, ...)
{
va_list params;
@@ -85,6 +86,7 @@ static void logerror(const char *err, ...)
va_end(params);
}
+__attribute__((format (printf, 1, 2)))
static void loginfo(const char *err, ...)
{
va_list params;
diff --git a/fsck.h b/fsck.h
index 008456b..1e4f527 100644
--- a/fsck.h
+++ b/fsck.h
@@ -17,6 +17,7 @@ typedef int (*fsck_walk_func)(struct object *obj, int type, void *data);
/* callback for fsck_object, type is FSCK_ERROR or FSCK_WARN */
typedef int (*fsck_error)(struct object *obj, int type, const char *err, ...);
+__attribute__((format (printf, 3, 4)))
int fsck_error_function(struct object *obj, int type, const char *fmt, ...);
/* descend in all linked child objects
diff --git a/imap-send.c b/imap-send.c
index 6c9938a..854b6a4 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -102,13 +102,16 @@ struct msg_data {
static int Verbose, Quiet;
+__attribute__((format (printf, 1, 2)))
static void imap_info(const char *, ...);
+__attribute__((format (printf, 1, 2)))
static void imap_warn(const char *, ...);
static char *next_arg(char **);
static void free_generic_messages(struct message *);
+__attribute__((format (printf, 3, 4)))
static int nfsnprintf(char *buf, int blen, const char *fmt, ...);
static int nfvasprintf(char **strp, const char *fmt, va_list ap)
@@ -560,6 +563,7 @@ static struct imap_cmd *v_issue_imap_cmd(struct imap_store *ctx,
return cmd;
}
+__attribute__((format (printf, 3, 4)))
static struct imap_cmd *issue_imap_cmd(struct imap_store *ctx,
struct imap_cmd_cb *cb,
const char *fmt, ...)
@@ -573,6 +577,7 @@ static struct imap_cmd *issue_imap_cmd(struct imap_store *ctx,
return ret;
}
+__attribute__((format (printf, 3, 4)))
static int imap_exec(struct imap_store *ctx, struct imap_cmd_cb *cb,
const char *fmt, ...)
{
@@ -588,6 +593,7 @@ static int imap_exec(struct imap_store *ctx, struct imap_cmd_cb *cb,
return get_cmd_result(ctx, cmdp);
}
+__attribute__((format (printf, 3, 4)))
static int imap_exec_m(struct imap_store *ctx, struct imap_cmd_cb *cb,
const char *fmt, ...)
{
diff --git a/merge-recursive.c b/merge-recursive.c
index f55b7eb..d198312 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -86,6 +86,7 @@ static void flush_output(struct merge_options *o)
}
}
+__attribute__((format (printf, 3, 4)))
static void output(struct merge_options *o, int v, const char *fmt, ...)
{
int len;
diff --git a/strbuf.h b/strbuf.h
index d05e056..fa07ecf 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -117,7 +117,7 @@ struct strbuf_expand_dict_entry {
};
extern size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder, void *context);
-__attribute__((format(printf,2,3)))
+__attribute__((format (printf,2,3)))
extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
extern size_t strbuf_fread(struct strbuf *, size_t, FILE *);
--
1.6.5.52.g4544ce0
^ permalink raw reply related
* Re: [PATCH 1/2] git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
From: Eric Wong @ 2009-11-14 21:40 UTC (permalink / raw)
To: Junio C Hamano, Toby Allsopp; +Cc: git, Sam Vilain
In-Reply-To: <874ooz5o8s.fsf@navakl084.mitacad.com>
Toby Allsopp <toby.allsopp@navman.co.nz> wrote:
> This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
> properties. The problematic case is when there is some commit on an
> unrelated branch after the last commit on the merged-from branch.
> When SVN records the mergeinfo property, it records the latest
> revision in the whole repository, which, in the problematic case, is
> not on the branch it is merging from.
>
> To trigger the git-svn bug, we modify t9151 to include two SVN merges,
> the second of which has an intervening commit. The SVN dump was
> generated using SVN 1.6.6 (on Debian squeeze amd64).
>
> Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
Hi Toby,
Thanks for this series, acked and squashed into a single commit to avoid
unnecessary bisection failures at git://git.bogomips.org/git-svn
commit 753dc384dc2c4ab3e1049f695425cebf41ff7e6b
Author: Toby Allsopp <toby.allsopp@navman.co.nz>
Date: Sat Nov 14 13:26:47 2009 -0800
git svn: handle SVN merges from revisions past the tip of the branch
When recording the revisions that it has merged, SVN sets the top
revision to be the latest revision in the repository, which is not
necessarily a revision on the branch that is being merged from. When
it is not on the branch, git-svn fails to add the extra parent to
represent the merge because it relies on finding the commit on the
branch that corresponds to the top of the SVN merge range.
In order to correctly handle this case, we look for the maximum
revision less than or equal to the top of the SVN merge range that is
actually on the branch being merged from.
[ew: This includes the following (squashed) commit to prevent
errors during bisect:]
Author: Toby Allsopp <toby.allsopp@navman.co.nz>
Date: Fri Nov 13 09:48:39 2009 +1300
git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
properties. The problematic case is when there is some commit on an
unrelated branch after the last commit on the merged-from branch.
When SVN records the mergeinfo property, it records the latest
revision in the whole repository, which, in the problematic case, is
not on the branch it is merging from.
To trigger the git-svn bug, we modify t9151 to include two SVN merges,
the second of which has an intervening commit. The SVN dump was
generated using SVN 1.6.6 (on Debian squeeze amd64).
Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] http-backend: Fix bad treatment of uintmax_t in Content-Length
From: Tarmigan @ 2009-11-14 21:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091112044240.GP11919@spearce.org>
On Wed, Nov 11, 2009 at 8:42 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Our Content-Length needs to report an off_t, which could be larger
> precision than size_t on this system (e.g. 32 bit binary built with
> 64 bit large file support).
>
> We also shouldn't be passing a size_t parameter to printf when
> we've used PRIuMAX as the format specifier.
>
> Fix both issues by using uintmax_t for the hdr_int() routine,
> allowing strbuf's size_t to automatically upcast, and off_t to
> always fit.
>
> Also fixed the copy loop we use inside of send_local_file(), we never
> actually updated the size variable so we might as well not use it.
>
> Reported-by: Tarmigan <tarmigan+git@gmail.com>
Tested-by: Tarmigan <tarmigan+git@gmail.com>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> Tarmigan <tarmigan+git@gmail.com> wrote:
> > unhappy. Curl returns 18 (CURLE_PARTIAL_FILE), the test takes a long
> > time to fail, and the "out" file looks OK (compared to a linux machine
> > where the test passes) expect for "Content-Length: 37847251812411".
> >
> > Digging into it a bit more with gdb, the call to hdr_int() in
> > http-backend.c looks OK, but then something goes wrong in
> > format_write(). Hmmm it looks like my setup does not like PRIuMAX
> > with size_t, which puts some garbage in the upper bytes of
>
> Yup, only the right fix is to keep using PRIuMAX... patch below.
This fix is better than the (uintmax_t) cast that I was thinking about posting.
Please also consider the "__attribute__((format(printf,1,2))" patches
that I just posted to the list that would warn about this in the
future.
Thanks,
Tarmigan
^ permalink raw reply
* [PATCH] git svn: read global+system config for clone+init
From: Eric Wong @ 2009-11-14 22:39 UTC (permalink / raw)
To: Curt Sampson, Junio C Hamano; +Cc: git
In-Reply-To: <20091110130913.GR19475@poetic.cynic.net>
Curt Sampson <cjs@cynic.net> wrote:
> When using "git svn fetch" or "git svn clone", the --authors-file
> command line parameter does what it claims in the docs. Additionally,
> for "git svn fetch", an svn.authorsfile configuration parameter in
> ~/.gitconfig is used, if no command line argument is specified. However,
> svn.authorsfile is ignored by "git svn clone", though the documentation
> claims that clone "runs init and fetch."
>
> I have confirmed this bug is present in git versions 1.6.0.4 and 1.6.5.1.
Hi Curt,
Thanks for the bug report, the following patch should fix
the bug. Also pullable from git://git.bogomips.org/git-svn
>From 1a30582b43e137e16b3486d83bb86b0eb090e13d Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sat, 14 Nov 2009 14:25:11 -0800
Subject: [PATCH] git svn: read global+system config for clone+init
Since $GIT_DIR does not exist when initializing new repositories,
we can follow back to the global and system config files for
git.
The logic for this was originally introduced when
$GIT_DIR/config was the only config file git could read (back
when "git config" was "git repo-config"), so the function is
renamed to "read_git_config" instead of "read_repo_config".
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 27fbe30..ea922ac 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -274,7 +274,7 @@ unless ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
my %opts = %{$cmd{$cmd}->[2]} if (defined $cmd);
-read_repo_config(\%opts);
+read_git_config(\%opts);
if ($cmd && ($cmd eq 'log' || $cmd eq 'blame')) {
Getopt::Long::Configure('pass_through');
}
@@ -1390,8 +1390,7 @@ sub load_authors {
}
# convert GetOpt::Long specs for use by git-config
-sub read_repo_config {
- return unless -d $ENV{GIT_DIR};
+sub read_git_config {
my $opts = shift;
my @config_only;
foreach my $o (keys %$opts) {
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] git svn: read global+system config for clone+init
From: Eric Wong @ 2009-11-14 22:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Curt Sampson
In-Reply-To: <20091114223930.GA10176@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Hi Curt,
>
> Thanks for the bug report, the following patch should fix
> the bug. Also pullable from git://git.bogomips.org/git-svn
It took me a while (possibly due to low caffeine levels) to make a
failing (automated) test case, but I've also pushed this out as
well.
>From e2f8617b266e320fd58ab584cae2ebe9906daaac Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sat, 14 Nov 2009 14:43:20 -0800
Subject: [PATCH] git svn: add authorsfile test case for ~/.gitconfig
The commit for:
git svn: read global+system config for clone+init
Initially lacked a test case because the author was unable to
reproduce it under his test environment, this adds it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9130-git-svn-authors-file.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t9130-git-svn-authors-file.sh b/t/t9130-git-svn-authors-file.sh
index f5abdb3..134411e 100755
--- a/t/t9130-git-svn-authors-file.sh
+++ b/t/t9130-git-svn-authors-file.sh
@@ -91,4 +91,27 @@ test_expect_success 'fetch continues after authors-file is fixed' '
)
'
+test_expect_success 'fresh clone with svn.authors-file in config' '
+ (
+ rm -r "$GIT_DIR" &&
+ test x = x"$(git config svn.authorsfile)" &&
+ HOME="`pwd`" &&
+ export HOME &&
+ test_config="$HOME"/.gitconfig &&
+ unset GIT_CONFIG_NOGLOBAL &&
+ unset GIT_DIR &&
+ unset GIT_CONFIG &&
+ git config --global \
+ svn.authorsfile "$HOME"/svn-authors &&
+ test x"$HOME"/svn-authors = x"$(git config svn.authorsfile)" &&
+ git svn clone "$svnrepo" gitconfig.clone &&
+ cd gitconfig.clone &&
+ nr_ex=$(git log | grep "^Author:.*example.com" | wc -l) &&
+ nr_rev=$(git rev-list HEAD | wc -l) &&
+ test $nr_rev -eq $nr_ex
+ )
+'
+
+test_debug 'GIT_DIR=gitconfig.clone/.git git log'
+
test_done
--
Eric Wong
^ permalink raw reply related
* Re: Question about "git pull --rebase"
From: Nanako Shiraishi @ 2009-11-14 23:16 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <38b2ab8a0911141239w2bab7277o66350bc742d985dd@mail.gmail.com>
Quoting Francis Moreau <francis.moro@gmail.com>
> Let's say I'm on a branch called 'foo'.
> ...
> $ git pull --rebase origin master:foo
With this command line, you are asking:
1) Please first fetch master from origin and update the local
'foo' with it, but please fail if this doesn't fast forward;
2) If the first step was successful, please rebase the current
branch on top of that commit.
If your current branch 'foo' doesn't fast forward, the first step
should fail, and that is the failure you saw.
Your request doesn't make any sense. The first step would succeed
only when your 'foo' doesn't have anything to replay on 'master'
from origin, and the second step either isn't executed (when 'foo'
has some commits), or it doesn't do anything (when 'foo' doesn't
have any commit).
> $ git pull --rebase origin master
With this command line, you are asking:
1) Please first fetch master from origin, but don't store it anywhere;
2) Then on top of that fetched commit, please rebase the current branch.
That is a much saner request.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Johan 't Hart @ 2009-11-14 23:29 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <38b2ab8a0911141239w2bab7277o66350bc742d985dd@mail.gmail.com>
Francis Moreau schreef:
> hello,
>
> Let's say I'm on a branch called 'foo'.
>
> I tried to rebase this branch by using 'git pull --rebase'.
>
> I first tried the following command:
>
> $ git pull --rebase origin master:foo
> remote: Counting objects: 5, done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From /dev/shm/git/A
> ! [rejected] master -> foo (non fast forward)
When using a refspec, you usually mean to update a remote tracking
branch, like refs/remotes/origin/master. Internally the refspec
parameter is passed to git fetch, which fast-forwards your local
tracking branch to match the remote branch.
With this command, you make git clear you want to fast-forward your
branch refs/foo to match the remotes master branch, and then rebase your
current branch on that foo branch.
Foo probably is also your current branch. So what you probably want is
to fetch the remotes master branch and rebase your current branch foo on
it. You could do it this way:
> Then I tried:
>
> $ git pull --rebase origin master
>
> which worked.
This does not update any remote tracking branches, but it will rebase
your foo branch on the remote master branch (which is what you want)
It could also be done with:
git pull --rebase origin master:origin/master
This will also update your remote tracking branch
refs/remotes/origin/master to match the master branch on the remote
repo. Your foo branch will then be rebased onto it.
>
> Reading the man git-pull I would assume the 2 commands are equivalent
> but obviously they're not.
>
> So the question is: why ?
So, thats why :) They're not the same. Many words... Hope you
understand... I hope I understood it well too..?
>
> Thanks
^ 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