* Ignore version update changes on git show report?
From: Preben Liland Madsen @ 2013-02-26 19:53 UTC (permalink / raw)
To: git
Hello,
I'm trying to investigate some what changes have been done between two versions of a software with the name IP.Board.
This proves more troublesome than I thought, since their release builder appearantly updates the version number automatically in all files.
This causes a lot of files to have this as the only change:
- * IP.Board v3.4.2
+ * IP.Board v3.4.3
Which is quite annoying to have to go through and therefor is responsible for more than 800 files being changed.
Is there some sort of git command or command I can combine together with git show that will ignore files with only these changes? Something along the lines of ignoring files where the only change matches this change or ignore files that've only gotten 1 line removed and 1 line added?
Best regards, Preben
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 0/5] Fix msvc build
From: Johannes Sixt @ 2013-02-26 19:48 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, GIT Mailing-list, Ramsay Jones, Erik Faye-Lund,
Jonathan Nieder
In-Reply-To: <alpine.DEB.1.00.1302252000440.32206@s15462909.onlinehome-server.info>
Am 25.02.2013 20:01, schrieb Johannes Schindelin:
> Can you please send a pull request on GitHub?
It's not github, but hopefully useful for you:
The following changes since commit bcd45b4085f9269a536c8fb1963ac8380bfac0e8:
Update draft release notes to 1.8.2 (2013-02-01 12:52:08 -0800)
are available in the git repository at:
git://repo.or.cz/git/mingw/j6t.git rj/msvc
for you to fetch changes up to 4c3f0410bfc3f42f9c62c7a23a0ef78420967f84:
msvc: avoid collisions between "tags" and "TAGS" (2013-02-26 20:40:16
+0100)
----------------------------------------------------------------
Ramsay Allan Jones (5):
msvc: Fix compilation errors caused by poll.h emulation
msvc: git-daemon: Fix linker "unresolved external" errors
msvc: Fix build by adding missing symbol defines
msvc: test-svn-fe: Fix linker "unresolved external" error
msvc: avoid collisions between "tags" and "TAGS"
compat/msvc.h | 2 ++
compat/vcbuild/include/sys/poll.h | 1 -
compat/vcbuild/include/unistd.h | 3 +++
config.mak.uname | 4 +++-
git-compat-util.h | 3 +++
test-svn-fe.c | 2 +-
6 files changed, 12 insertions(+), 3 deletions(-)
delete mode 100644 compat/vcbuild/include/sys/poll.h
^ permalink raw reply
* Re: [PATCH 1/4] config: factor out config file stack management
From: Jeff King @ 2013-02-26 19:54 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git, Jens Lehmann
In-Reply-To: <20130226193850.GB22756@sandbox-ub>
On Tue, Feb 26, 2013 at 08:38:50PM +0100, Heiko Voigt wrote:
> Because a config callback may start parsing a new file, the
> global context regarding the current config file is stored
> as a stack. Currently we only need to manage that stack from
> git_config_from_file. Let's factor it out to allow new
> sources of config data.
>
> Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
> ---
>
> Peff, I hope you do not mind that I totally copied your commit message
> here.
I don't mind at all.
> The patch takes a different approach though. If you like we can add a
>
> Commit-Message-by: Jeff King <peff@peff.net>
>
> here :-)
I think my name is plastered all over "git log" enough as it is.
> +static int do_config_from(struct config_file *top, config_fn_t fn, void *data)
> +{
> + int ret;
> +
> + /* push config-file parsing state stack */
> + top->prev = cf;
> + top->linenr = 1;
> + top->eof = 0;
> + strbuf_init(&top->value, 1024);
> + strbuf_init(&top->var, 1024);
> + cf = top;
> +
> + ret = git_parse_file(fn, data);
> +
> + /* pop config-file parsing state stack */
> + strbuf_release(&top->value);
> + strbuf_release(&top->var);
> + cf = top->prev;
> +
> + return ret;
> +}
This function name is a bit weird. I would have thought the "from" here
was going to be a file, or a string, or whatever. But the filename setup
happens outside this function (and yet this function depends on it being
set up, as it calls git_parse_file). But maybe it will get less
confusing with the other patches on top...
-Peff
^ permalink raw reply
* Re: [PATCH 2/4] config: drop file pointer validity check in get_next_char()
From: Jeff King @ 2013-02-26 20:05 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git, Jens Lehmann
In-Reply-To: <20130226194023.GC22756@sandbox-ub>
On Tue, Feb 26, 2013 at 08:40:23PM +0100, Heiko Voigt wrote:
> The only location where cf is set in this file is in do_config_from().
> This function has only one callsite which is config_from_file(). In
> config_from_file() its ensured that the f member is set to non-zero.
Makes sense, although...
> - if (cf && ((f = cf->f) != NULL)) {
> + if (cf) {
> + FILE *f = cf->f;
Couldn't we say the same thing about "cf" here (i.e., that it would
never be NULL)? Can we just get rid of this conditional entirely?
-Peff
^ permalink raw reply
* two-way merge corner case bug
From: Junio C Hamano @ 2013-02-26 20:06 UTC (permalink / raw)
To: git; +Cc: peff
It seems that we have a corner case bug in two-way merge to reset
away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
In a freshly created repository:
rm -f A Z
for i in $(seq 100)
do
echo hello
done >Z
git add Z
git commit -m initial
git branch side
echo goodbye >>Z
git commit -a -m changed
git checkout side
git mv Z A
echo kitty >>A
git commit -a -m side
if you do one of these:
git checkout master && git merge side
git checkout side && git merge master
you will get three stages for path A, and nothing for path Z.
With the former, you are starting from a tree with Z (and not A),
and "resetting" should give you A that is the same as 'master' in
the working tree. With the latter, you are starting from a tree
with A, and "resetting" should give you Z and remove conflicted A
from the working tree.
git read-tree -u --reset ORIG_HEAD
does the right thing in either case, but
git read-tree -u --reset HEAD ORIG_HEAD
dies with "cache entry has null sha1: A" for both cases.
The direct symptom comes from 4337b5856f88 (do not write null sha1s
to on-disk index, 2012-07-28), but I think the root cause is
somewhere else. When we start from 'side', we should notice that
our HEAD has Z, and conflicted A we see in the index came from a
conflicted merge that we are resetting away and should disappear
from the working tree. When we start from 'master', we should
notice that we do not want to keep the cache entry that is
"modified" in the index, and write the one taken from the "going to"
tree (ORIG_HEAD).
^ permalink raw reply
* Re: [PATCH 1/4] config: factor out config file stack management
From: Heiko Voigt @ 2013-02-26 20:09 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Jens Lehmann
In-Reply-To: <20130226195449.GA13830@sigill.intra.peff.net>
On Tue, Feb 26, 2013 at 02:54:49PM -0500, Jeff King wrote:
> On Tue, Feb 26, 2013 at 08:38:50PM +0100, Heiko Voigt wrote:
> > +static int do_config_from(struct config_file *top, config_fn_t fn, void *data)
> > +{
> > + int ret;
> > +
> > + /* push config-file parsing state stack */
> > + top->prev = cf;
> > + top->linenr = 1;
> > + top->eof = 0;
> > + strbuf_init(&top->value, 1024);
> > + strbuf_init(&top->var, 1024);
> > + cf = top;
> > +
> > + ret = git_parse_file(fn, data);
> > +
> > + /* pop config-file parsing state stack */
> > + strbuf_release(&top->value);
> > + strbuf_release(&top->var);
> > + cf = top->prev;
> > +
> > + return ret;
> > +}
>
> This function name is a bit weird. I would have thought the "from" here
> was going to be a file, or a string, or whatever. But the filename setup
> happens outside this function (and yet this function depends on it being
> set up, as it calls git_parse_file). But maybe it will get less
> confusing with the other patches on top...
The "do_config_from" means "parse from whatever is in 'top'". Later in
the series its type changes from config_file to struct config.
The name 'git_parse_file' becomes definitely wrong after this series.
Maybe I should rename it?
Cheers Heiko
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Matt Kraai @ 2013-02-26 20:13 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
Hi,
Please include me in the Cc field, since I'm not subscribed to the
list.
Mike Gorchak wrote:
> Do you have a testcase for this (without using git codebase)? I wrote
> numerous resource managers since QNX 6.0 using threads and fork()s for
> daemonization in different order and never experienced a problems.
> There can be issues with pipes in case of external command run.
I just created the following one:
#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <process.h>
static void *
start_routine (void *arg)
{
return NULL;
}
int
main (int argc, char **argv)
{
int err;
if ((err = pthread_create (NULL, NULL, start_routine, NULL)))
{
fprintf (stderr, "foo: pthread_create failed: %s\n", strerror (errno));
return 1;
}
if (fork () == -1)
{
fprintf (stderr, "foo: fork failed: %s\n", strerror (errno));
return 1;
}
return 0;
}
When I compile and run it on either QNX 6.3.2 or QNX 6.5.0, it
produces the following output:
foo: fork failed: Function not implemented
If I remove the call to pthread_create, it doesn't output anything and
exits successfully.
^ permalink raw reply
* Re: [PATCH 1/4] config: factor out config file stack management
From: Jeff King @ 2013-02-26 20:15 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, git, Jens Lehmann
In-Reply-To: <20130226200940.GF22756@sandbox-ub>
On Tue, Feb 26, 2013 at 09:09:41PM +0100, Heiko Voigt wrote:
> > This function name is a bit weird. I would have thought the "from" here
> > was going to be a file, or a string, or whatever. But the filename setup
> > happens outside this function (and yet this function depends on it being
> > set up, as it calls git_parse_file). But maybe it will get less
> > confusing with the other patches on top...
>
> The "do_config_from" means "parse from whatever is in 'top'". Later in
> the series its type changes from config_file to struct config.
Ah, I see. The "from" is the "struct config".
I wonder if it would be more obvious with the more usual OO-struct
functions, like:
struct config_source {
...
};
void config_source_init_file(struct config_source *, const char *fn);
void config_source_init_strbuf(struct config_source *,
const struct strbuf *buf);
void config_source_clear(struct config_source *);
int config_source_parse(struct config_source *);
and then the use would be something like:
struct config_source top;
int ret;
config_source_init_file(&top, "foo");
ret = config_source_parse(&top);
config_source_clear(&top);
return ret;
I.e., "init" constructors, a "clear" destructor, and any methods like
"parse" that you need. I haven't though too hard about it, though, so
maybe there is some reason it does not fit that model (it is a little
uncommon that the "init" would push itself onto a stack, but I think
that's OK).
-Peff
^ permalink raw reply
* Re: two-way merge corner case bug
From: Jeff King @ 2013-02-26 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7glun8kt.fsf@alter.siamese.dyndns.org>
On Tue, Feb 26, 2013 at 12:06:42PM -0800, Junio C Hamano wrote:
> It seems that we have a corner case bug in two-way merge to reset
> away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
Isn't this a repeat of:
http://thread.gmane.org/gmane.comp.version-control.git/202440/focus=212316
whose fix never got finalized? It's on my todo list, but it seems that
items keep sinking further down on that list, rather than getting
completed. :-/
-Peff
^ permalink raw reply
* Re: [PATCH 12/13] Documentation/Makefile: update git guide links
From: Philip Oakley @ 2013-02-26 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GitList
In-Reply-To: <7va9qsndnn.fsf@alter.siamese.dyndns.org>
On 26/02/13 00:04, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.org> writes:
>
>> On 25/02/13 05:29, Junio C Hamano wrote:
>> ...
>>> In other words, can't you change the side that launches the document
>>> viewer so that we do not have to rename anything in the first place?
>>
>> The current help code will only show either 'git-<cmd>' man pages, or
>> git<guide>' pages so the current everyday and user-manual pages aren't
>> served by the existing help code.
>
> That is exactly what I meant by "the side that launches the document
> viewer". We obviously would not want to type
>
> $ git help gituser-manual
> $ git help giteveryday
Neither do I...
>
> I was wondering if you can keep document names as-is, register these
> names without "git" prefix (i.e. "user-manual.html")
I don't register them at all. I'm simply gathering a list of common
guides in the array so that I can show that list as a 'usage' list, in
exactly the same manner as the common commands list is used when 'git
help' [ no options] is typed.
> to the list of
> guide documents you are generating and compiling into the binary,
> and let the user ask:
>
> $ git help everyday
This is the existing way.
'git help tutorial' will display the gittutorial.txt man page - Note the
git prefix is required by the code.
It is interesting to note that 'git help k' and 'git help gitk' produce
the same response, while gitk can't be a common-command because it
doesn't have a dashed form so isn't picked up by the script ;-)
>
> which you would turn into "browser %s/%s.html" % (GIT_HTML_PATH, 'everyday'),
> after checking "everyday" is one of the guides that are available to us.
>
> If some guides are already named with git prefix, you can keep them
> in the compiled-in list with that name. We do not have to worry
> about redirects and people's bookmarks if we can avoid renaming
> existing pages, so "because grabbing everything with git* glob was
> easier to write the generate-guidelist script" is a false economy.
I was hoping to avoid more special casing of special files for special
purposes..
> That is the single place we can afford to spend extra effort to make
> the end result easier to use by the users, no?
It could be done.
>
> Or am I misreading the series completely?
Yes, I think so (in terms of my starting point and approach).
I was using the existing common-commands approach _just_ to display a
'usage' string of common guides. so that new users would be informed of
their presence, and then they would use the existing command 'git help
<guide>' to read about it (see also patch 2/13).
It was just unfortunate that the user-manual and everyday didn't fit the
existing naming pattern causing the writing of patch 8 & 9 et seq to
sort the renames to fit the pattern (just like git-remote-helpers)
Also, I think it's the user-manual, one of the files doesn't fit the
'man page' style required by the MAN7 list in Documentation/Makefile, so
that's another potential complication I need to bottom out - most likely
keep it 'as is' in the Makefile and check that the Help command will
display it properly if done that way.
Philip
^ permalink raw reply
* Re: gc does not clean up after itself when not enough disk space
From: Jens Lehmann @ 2013-02-26 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jones.noamle, git
In-Reply-To: <7v1uc3njnf.fsf@alter.siamese.dyndns.org>
Am 26.02.2013 17:07, schrieb Junio C Hamano:
> "jones.noamle" <lenoam@gmail.com> writes:
>
>> # git gc
>> Counting objects: 44626, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (7756/7756), done.
>> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
>> space left on device
>
> In general when we encounter an unexpected error, we tend to try
> leaving things as they are so that we can help diagnosing the
> failure. But when you ran out of disk space I would agree that it
> may be sensible to remove a temporary file we didn't manage to write
> out in full.
Ack. I just recently had to do
git gc || rm -f .git/objects/*/tmp_*
as workaround in the nightly housekeeping script on our CI server.
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Mike Gorchak @ 2013-02-26 20:32 UTC (permalink / raw)
To: Matt Kraai, git
In-Reply-To: <20130226201305.GA3502@ftbfs.org>
> If I remove the call to pthread_create, it doesn't output anything and
> exits successfully.
I see. Most resource managers use procmgr_daemon(), which has no such
limitation. Anyway, as far as I can see current git sources do not use
fork together with pthread, except for daemonize() function.
^ permalink raw reply
* [PATCH] diff: prevent pprint_rename from underrunning input
From: Thomas Rast @ 2013-02-26 20:47 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git, Junio C Hamano
In-Reply-To: <1361638125-11245-1-git-send-email-apelisse@gmail.com>
The logic described in d020e27 (diff: Fix rename pretty-print when
suffix and prefix overlap, 2013-02-23) is wrong: The proof in the
comment is valid only if both strings are the same length. *One* of
old/new can reach a-1 (b-1, resp.) if 'a' is a suffix of 'b' (or vice
versa).
Since the intent was to let the loop run down to the '/' at the end of
the common prefix, fix it by making that distinction explicit: if
there is no prefix, allow no underrun.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Hi Antoine,
Unfortunately there's this bug in your patch. Luckily it was found by
valgrind on t4016 and others.
Cheers
Thomas
diff.c | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index 7d49cab..8396527 100644
--- a/diff.c
+++ b/diff.c
@@ -1264,6 +1264,7 @@ static char *pprint_rename(const char *a, const char *b)
const char *new = b;
struct strbuf name = STRBUF_INIT;
int pfx_length, sfx_length;
+ int pfx_adjust_for_slash;
int len_a = strlen(a);
int len_b = strlen(b);
int a_midlen, b_midlen;
@@ -1291,14 +1292,16 @@ static char *pprint_rename(const char *a, const char *b)
new = b + len_b;
sfx_length = 0;
/*
- * Note:
- * if pfx_length is 0, old/new will never reach a - 1 because it
- * would mean the whole string is common suffix. But then, the
- * whole string would also be a common prefix, and we would not
- * have pfx_length equals 0.
+ * If there is a common prefix, it must end in a slash. In
+ * that case we let this loop run 1 into the prefix to see the
+ * same slash.
+ *
+ * If there is no common prefix, we cannot do this as it would
+ * underrun the input strings.
*/
- while (a + pfx_length - 1 <= old &&
- b + pfx_length - 1 <= new &&
+ pfx_adjust_for_slash = (pfx_length ? 1 : 0);
+ while (a + pfx_length - pfx_adjust_for_slash <= old &&
+ b + pfx_length - pfx_adjust_for_slash <= new &&
*old == *new) {
if (*old == '/')
sfx_length = len_a - (old - a);
--
1.8.2.rc1.307.ge0d2dea
^ permalink raw reply related
* Re: [PATCH] Improve QNX support in GIT
From: Johannes Sixt @ 2013-02-26 20:53 UTC (permalink / raw)
To: Mike Gorchak; +Cc: Matt Kraai, git
In-Reply-To: <CAHXAxrOcC7GX-rhT793t4vcF68TvrE9w9OW856+7cGDBGMx0VA@mail.gmail.com>
Am 26.02.2013 21:32, schrieb Mike Gorchak:
>> If I remove the call to pthread_create, it doesn't output anything and
>> exits successfully.
>
> I see. Most resource managers use procmgr_daemon(), which has no such
> limitation. Anyway, as far as I can see current git sources do not use
> fork together with pthread, except for daemonize() function.
Not true: When a clean or smudge filter is configured, a thread is
created, and the thread runs the external program via fork().
-- Hannes
^ permalink raw reply
* Re: [PATCH] Improve QNX support in GIT
From: Matt Kraai @ 2013-02-26 21:02 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrOcC7GX-rhT793t4vcF68TvrE9w9OW856+7cGDBGMx0VA@mail.gmail.com>
On Tue, Feb 26, 2013 at 10:32:16PM +0200, Mike Gorchak wrote:
> I see. Most resource managers use procmgr_daemon(), which has no such
> limitation. Anyway, as far as I can see current git sources do not use
> fork together with pthread, except for daemonize() function.
If threads are enabled, git does use fork after calling pthread_create:
* When I run "git grep foo".
* When I run "git fetch" to update my git working copy, which is
using an HTTPS remote.
Both of these commands fail as a result.
^ permalink raw reply
* Re: two-way merge corner case bug
From: Junio C Hamano @ 2013-02-26 21:41 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130226201820.GD13830@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Feb 26, 2013 at 12:06:42PM -0800, Junio C Hamano wrote:
>
>> It seems that we have a corner case bug in two-way merge to reset
>> away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
>
> Isn't this a repeat of:
>
> http://thread.gmane.org/gmane.comp.version-control.git/202440/focus=212316
>
> whose fix never got finalized? It's on my todo list, but it seems that
> items keep sinking further down on that list, rather than getting
> completed. :-/
Yeah, I think the patch in your message is a good starting point to
solve a half of the issue (i.e. unmerged current one should be
replaced with the version from the "going to" tree). Attached is
with a slight update.
The other half that is not solved by this patch is that we will lose
Z because merge-recursive removed it when it renamed it and left
three stages for A in the index, and to "read-tree --reset -u HEAD
ORIG_HEAD", it looks as if you removed Z yourself while on HEAD and
want to carry your local change forward to ORIG_HEAD.
I think this too needs to be fixed. We are saying "-u --reset" to
mean "I want to go there no matter what", not "-u -m" that means "I
am carrying my changes forward while checking out another branch".
unpack-trees.c | 25 +++++++++++++++++--------
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 09e53df..3d17108 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1748,14 +1748,23 @@ int twoway_merge(struct cache_entry **src, struct unpack_trees_options *o)
newtree = NULL;
if (current) {
- if ((!oldtree && !newtree) || /* 4 and 5 */
- (!oldtree && newtree &&
- same(current, newtree)) || /* 6 and 7 */
- (oldtree && newtree &&
- same(oldtree, newtree)) || /* 14 and 15 */
- (oldtree && newtree &&
- !same(oldtree, newtree) && /* 18 and 19 */
- same(current, newtree))) {
+ if (current->ce_flags & CE_CONFLICTED) {
+ if (same(oldtree, newtree) || o->reset) {
+ if (!newtree)
+ return deleted_entry(current, current, o);
+ else
+ return merged_entry(newtree, current, o);
+ }
+ return o->gently ? -1 : reject_merge(current, o);
+ }
+ else if ((!oldtree && !newtree) || /* 4 and 5 */
+ (!oldtree && newtree &&
+ same(current, newtree)) || /* 6 and 7 */
+ (oldtree && newtree &&
+ same(oldtree, newtree)) || /* 14 and 15 */
+ (oldtree && newtree &&
+ !same(oldtree, newtree) && /* 18 and 19 */
+ same(current, newtree))) {
return keep_entry(current, o);
}
else if (oldtree && !newtree && same(current, oldtree)) {
^ permalink raw reply related
* Re: [PATCH] diff: prevent pprint_rename from underrunning input
From: Junio C Hamano @ 2013-02-26 21:44 UTC (permalink / raw)
To: Thomas Rast; +Cc: Antoine Pelisse, git
In-Reply-To: <d74fcfa693e5feb7249023feda8d3ad1f22ab16d.1361911196.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> The logic described in d020e27 (diff: Fix rename pretty-print when
> suffix and prefix overlap, 2013-02-23) is wrong: The proof in the
> comment is valid only if both strings are the same length. *One* of
> old/new can reach a-1 (b-1, resp.) if 'a' is a suffix of 'b' (or vice
> versa).
Thanks. I was also having hard time convincing myself why that -1
does not under-run yesterday.
Will queue.
^ permalink raw reply
* Re: [PATCH 1/4] config: factor out config file stack management
From: Junio C Hamano @ 2013-02-26 22:10 UTC (permalink / raw)
To: Jeff King; +Cc: Heiko Voigt, git, Jens Lehmann
In-Reply-To: <20130226201518.GC13830@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I wonder if it would be more obvious with the more usual OO-struct
> functions, like:
>
> struct config_source {
> ...
> };
> void config_source_init_file(struct config_source *, const char *fn);
> void config_source_init_strbuf(struct config_source *,
> const struct strbuf *buf);
> void config_source_clear(struct config_source *);
>
> int config_source_parse(struct config_source *);
>
> and then the use would be something like:
>
> struct config_source top;
> int ret;
>
> config_source_init_file(&top, "foo");
> ret = config_source_parse(&top);
> config_source_clear(&top);
>
> return ret;
>
> I.e., "init" constructors, a "clear" destructor, and any methods like
> "parse" that you need.
Yup, that cocincides with my first impression I sent out for the
previous RFC/PATCH round.
^ permalink raw reply
* Re: [PATCH 1/4] config: factor out config file stack management
From: Junio C Hamano @ 2013-02-26 22:12 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Jeff King, git, Jens Lehmann
In-Reply-To: <20130226200940.GF22756@sandbox-ub>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> The "do_config_from" means "parse from whatever is in 'top'". Later in
> the series its type changes from config_file to struct config.
Yuck. It would be nice to have it as struct config_src or
something. "struct config" sounds as if it represents the entire
configuration state and you can ask it to add new ones or enumerate
all known configuration variables, etc.
^ permalink raw reply
* What's cooking in git.git (Feb 2013, #10; Tue, 26)
From: Junio C Hamano @ 2013-02-26 22:16 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'.
The tip of the 'master' is a bit past 1.8.2-rc1. I am hoping to do
an -rc2 by the end of this week.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[Graduated to "master"]
* as/check-ignore (2013-02-19) 2 commits
(merged to 'next' on 2013-02-21 at 27927a2)
+ name-hash: allow hashing an empty string
+ t0008: document test_expect_success_multi
"git check-ignore ." segfaulted, as a function it calls deep in its
callchain took a string in the <ptr, length> form but did not stop
when given an empty string.
* ct/autoconf-htmldir (2013-02-19) 1 commit
(merged to 'next' on 2013-02-21 at 44f127d)
+ Bugfix: undefined htmldir in config.mak.autogen
An earlier change to config.mak.autogen broke a build driven by the
./configure script when --htmldir is not specified on the command
line of ./configure.
* jn/less-reconfigure (2013-02-20) 1 commit
(merged to 'next' on 2013-02-21 at 811e0c0)
+ Makefile: avoid infinite loop on configure.ac change
A change made on v1.8.1.x maintenance track had a nasty regression
to break the build when autoconf is used.
* wk/man-deny-current-branch-is-default-these-days (2013-02-18) 1 commit
(merged to 'next' on 2013-02-21 at e67b15b)
+ user-manual: typofix (ofthe->of the)
* wk/user-manual (2013-02-19) 3 commits
(merged to 'next' on 2013-02-19 at dbc0eb2)
+ user-manual: Flesh out uncommitted changes and submodule updates
+ user-manual: Use request-pull to generate "please pull" text
+ user-manual: Reorganize the reroll sections, adding 'git rebase -i'
Further updates to the user manual.
--------------------------------------------------
[New Topics]
* jc/perl-cat-blob (2013-02-22) 1 commit
(merged to 'next' on 2013-02-25 at 7c0079a)
+ Git.pm: fix cat_blob crashes on large files
perl/Git.pm::cat_blob slurped everything in core only to write it
out to a file descriptor, which was not a very smart thing to do.
Will cook in 'next'.
* nd/doc-index-format (2013-02-23) 3 commits
(merged to 'next' on 2013-02-26 at 4d3caea)
+ update-index: list supported idx versions and their features
+ read-cache.c: use INDEX_FORMAT_{LB,UB} in verify_hdr()
+ index-format.txt: mention of v4 is missing in some places
Update the index format documentation to mention the v4 format.
Will cook in 'next'.
* ap/maint-diff-rename-avoid-overlap (2013-02-26) 2 commits
(merged to 'next' on 2013-02-26 at 19d70bf)
+ diff: prevent pprint_rename from underrunning input
(merged to 'next' on 2013-02-25 at c9bd6d3)
+ diff: Fix rename pretty-print when suffix and prefix overlap
The logic used by "git diff -M --stat" to shorten the names of
files before and after a rename did not work correctly when the
common prefix and suffix between the two filenames overlapped.
Will cook in 'next'.
* ap/maint-update-index-h-is-for-help (2013-02-23) 1 commit
(merged to 'next' on 2013-02-25 at f5f767c)
+ update-index: allow "-h" to also display options
Will cook in 'next'.
* jc/color-diff-doc (2013-02-22) 1 commit
(merged to 'next' on 2013-02-25 at c37541c)
+ diff-options: unconfuse description of --color
Will cook in 'next'.
* nd/branch-error-cases (2013-02-23) 1 commit
(merged to 'next' on 2013-02-25 at 1d0289f)
+ branch: segfault fixes and validation
"git branch" had more cases where it did not bother to check
nonsense command line parameters.
Will cook in 'next'.
* rt/commit-cleanup-config (2013-02-23) 1 commit
(merged to 'next' on 2013-02-25 at 8249b61)
+ t7502: perform commits using alternate editor in a subshell
Fix tests that contaminated their environments and affected new
tests introduced later in the sequence by containing their effects
in their own subshells.
Will cook in 'next'.
* wk/doc-pre-rebase (2013-02-24) 1 commit
(merged to 'next' on 2013-02-25 at a6ec310)
+ Documentation/githooks: Explain pre-rebase parameters
Will cook in 'next'.
* da/downcase-u-in-usage (2013-02-24) 20 commits
(merged to 'next' on 2013-02-26 at 977b67e)
+ contrib/mw-to-git/t/install-wiki.sh: use a lowercase "usage:" string
+ contrib/examples/git-remote.perl: use a lowercase "usage:" string
+ tests: use a lowercase "usage:" string
+ git-svn: use a lowercase "usage:" string
+ Documentation/user-manual.txt: use a lowercase "usage:" string
+ templates/hooks--update.sample: use a lowercase "usage:" string
+ contrib/hooks/setgitperms.perl: use a lowercase "usage:" string
+ contrib/examples: use a lowercase "usage:" string
+ contrib/fast-import/import-zips.py: use spaces instead of tabs
+ contrib/fast-import/import-zips.py: fix broken error message
+ contrib/fast-import: use a lowercase "usage:" string
+ contrib/credential: use a lowercase "usage:" string
+ git-cvsimport: use a lowercase "usage:" string
+ git-cvsimport: use a lowercase "usage:" string
+ git-cvsexportcommit: use a lowercase "usage:" string
+ git-archimport: use a lowercase "usage:" string
+ git-merge-one-file: use a lowercase "usage:" string
+ git-relink: use a lowercase "usage:" string
+ git-svn: use a lowercase "usage:" string
+ git-sh-setup: use a lowercase "usage:" string
Will cook in 'next'.
* dm/ni-maxhost-may-be-missing (2013-02-25) 1 commit
(merged to 'next' on 2013-02-26 at 93ec2c9)
+ git-compat-util.h: Provide missing netdb.h definitions
Will cook in 'next'.
* gp/avoid-explicit-mention-of-dot-git-refs (2013-02-24) 1 commit
(merged to 'next' on 2013-02-26 at ec42d98)
+ Fix ".git/refs" stragglers
Will cook in 'next'.
* gp/describe-match-uses-glob-pattern (2013-02-24) 1 commit
(merged to 'next' on 2013-02-26 at c9cc789)
+ describe: Document --match pattern format
(this branch is used by gp/forbid-describe-all-match.)
Will cook in 'next'.
* gp/forbid-describe-all-match (2013-02-24) 1 commit
- describe: make --all and --match=PATTERN mutually incompatible
(this branch uses gp/describe-match-uses-glob-pattern.)
Not sure if we should forbid the combination or explain the
semantics better, perhaps by giving a better synonym to "--all",
which meant "disable the usual limit that only gives the annotated
tags".
* jk/common-make-variables-export-safety (2013-02-25) 1 commit
- Makefile: make mandir, htmldir and infodir absolute
Make the three variables safer to be exported to submakes by
ensuring that they are full paths so that they can be used as
installation location.
* jk/suppress-clang-warning (2013-02-25) 1 commit
- fix clang -Wtautological-compare with unsigned enum
* mg/qnx6 (2013-02-25) 1 commit
- QNX: newer QNX 6.x.x is not so crippled
Still under discussion.
Not ready for inclusion.
* mg/unsigned-time-t (2013-02-25) 2 commits
- Fix time offset calculation in case of unsigned time_t
- date.c: fix unsigned time_t comparison
A few workarounds for systems with unsigned time_t.
* rj/msvc-build (2013-02-25) 5 commits
(merged to 'next' on 2013-02-26 at 7493068)
+ msvc: avoid collisions between "tags" and "TAGS"
+ msvc: test-svn-fe: Fix linker "unresolved external" error
+ msvc: Fix build by adding missing symbol defines
+ msvc: git-daemon: Fix linker "unresolved external" errors
+ msvc: Fix compilation errors caused by poll.h emulation
Will cook in 'next'.
* wk/user-manual-literal-format (2013-02-25) 1 commit
(merged to 'next' on 2013-02-26 at d59ce38)
+ user-manual: Standardize backtick quoting
Will cook in 'next'.
* jk/utf-8-can-be-spelled-differently (2013-02-25) 1 commit
(merged to 'next' on 2013-02-26 at c079525)
+ utf8: accept alternate spellings of UTF-8
Will cook in 'next'.
--------------------------------------------------
[Stalled]
* mb/gitweb-highlight-link-target (2012-12-20) 1 commit
- Highlight the link target line in Gitweb using CSS
Expecting a reroll.
$gmane/211935
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
There seems to be some interest. Let's see if it results in a solid
execution of a sensible transition plan towards Git 2.0.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a reroll.
$gmane/210151
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* jk/pkt-line-cleanup (2013-02-24) 19 commits
(merged to 'next' on 2013-02-25 at d83e970)
+ remote-curl: always parse incoming refs
+ remote-curl: move ref-parsing code up in file
+ remote-curl: pass buffer straight to get_remote_heads
+ teach get_remote_heads to read from a memory buffer
+ pkt-line: share buffer/descriptor reading implementation
+ pkt-line: provide a LARGE_PACKET_MAX static buffer
+ pkt-line: move LARGE_PACKET_MAX definition from sideband
+ pkt-line: teach packet_read_line to chomp newlines
+ pkt-line: provide a generic reading function with options
+ pkt-line: drop safe_write function
+ pkt-line: move a misplaced comment
+ write_or_die: raise SIGPIPE when we get EPIPE
+ upload-archive: use argv_array to store client arguments
+ upload-archive: do not copy repo name
+ send-pack: prefer prefixcmp over memcmp in receive_status
+ fetch-pack: fix out-of-bounds buffer offset in get_ack
+ upload-pack: remove packet debugging harness
+ upload-pack: do not add duplicate objects to shallow list
+ upload-pack: use get_sha1_hex to parse "shallow" lines
Cleans up pkt-line API, implementation and its callers to make
them more robust.
Will cook in 'next'.
* ob/imap-send-ssl-verify (2013-02-20) 1 commit
(merged to 'next' on 2013-02-25 at e897609)
+ imap-send: support Server Name Indication (RFC4366)
Correctly connect to SSL/TLS sites that serve multiple hostnames on
a single IP by including Server Name Indication in the client-hello.
Will cook in 'next'.
* jc/format-patch (2013-02-21) 2 commits
- format-patch: --inline-single
- format-patch: rename "no_inline" field
A new option to send a single patch to the standard output to be
appended at the bottom of a message. I personally have no need for
this, but it was easy enough to cobble together. Tests, docs and
stripping out more MIMEy stuff are left as exercises to interested
parties.
Not ready for inclusion.
* mh/maint-ceil-absolute (2013-02-22) 1 commit
(merged to 'next' on 2013-02-26 at ba83c45)
+ Provide a mechanism to turn off symlink resolution in ceiling paths
An earlier workaround designed to help people who list logical
directories that will not match what getcwd(3) returns in the
GIT_CEILING_DIRECTORIES had an adverse effect when it is slow to
stat and readlink a directory component of an element listed on it.
Will fast-track to 'master' (regression fix).
* tk/doc-filter-branch (2013-02-26) 2 commits
(merged to 'next' on 2013-02-26 at bd4638b)
+ Documentation: filter-branch env-filter example
+ git-filter-branch.txt: clarify ident variables usage
Will cook in 'next'.
* bc/commit-complete-lines-given-via-m-option (2013-02-19) 4 commits
(merged to 'next' on 2013-02-19 at cf622b7)
+ Documentation/git-commit.txt: rework the --cleanup section
+ git-commit: only append a newline to -m mesg if necessary
+ t7502: demonstrate breakage with a commit message with trailing newlines
+ t/t7502: compare entire commit message with what was expected
'git commit -m "$str"' when $str was already terminated with a LF
now avoids adding an extra LF to the message.
Will cook in 'next'.
* da/difftool-fixes (2013-02-21) 4 commits
(merged to 'next' on 2013-02-25 at 687db1f)
+ t7800: "defaults" is no longer a builtin tool name
+ t7800: modernize tests
+ t7800: update copyright notice
+ difftool: silence uninitialized variable warning
Minor maintenance updates to difftool, and updates to its tests.
Will cook in 'next'.
* nd/read-directory-recursive-optim (2013-02-17) 1 commit
(merged to 'next' on 2013-02-17 at 36ba9f4)
+ read_directory: avoid invoking exclude machinery on tracked files
"git status" has been optimized by taking advantage of the fact
that paths that are already known to the index do not have to be
checked against the .gitignore mechanism under some conditions.
Will cook in 'next'.
* mg/gpg-interface-using-status (2013-02-14) 5 commits
(merged to 'next' on 2013-02-26 at 93f0e72)
+ pretty: make %GK output the signing key for signed commits
+ pretty: parse the gpg status lines rather than the output
+ gpg_interface: allow to request status return
+ log-tree: rely upon the check in the gpg_interface
+ gpg-interface: check good signature in a reliable way
Call "gpg" using the right API when validating the signature on
tags.
Will cook in 'next'.
* jn/shell-disable-interactive (2013-02-11) 2 commits
- shell: pay attention to exit status from 'help' command
- shell doc: emphasize purpose and security model
Expecting a reroll.
$gmane/216229
* jc/fetch-raw-sha1 (2013-02-07) 4 commits
(merged to 'next' on 2013-02-14 at ffa3c65)
+ fetch: fetch objects by their exact SHA-1 object names
+ upload-pack: optionally allow fetching from the tips of hidden refs
+ fetch: use struct ref to represent refs to be fetched
+ parse_fetch_refspec(): clarify the codeflow a bit
Allows requests to fetch objects at any tip of refs (including
hidden ones). It seems that there may be use cases even outside
Gerrit (e.g. $gmane/215701).
Will cook in 'next'.
* mn/send-email-works-with-credential (2013-02-12) 6 commits
- git-send-email: use git credential to obtain password
- Git.pm: add interface for git credential command
- Git.pm: allow pipes to be closed prior to calling command_close_bidi_pipe
- Git.pm: refactor command_close_bidi_pipe to use _cmd_close
- Git.pm: fix example in command_close_bidi_pipe documentation
- Git.pm: allow command_close_bidi_pipe to be called as method
Hooks the credential system to send-email.
Rerolled.
Waiting for a review.
* nd/branch-show-rebase-bisect-state (2013-02-08) 1 commit
- branch: show rebase/bisect info when possible instead of "(no branch)"
Expecting a reroll.
$gmane/215771
* nd/count-garbage (2013-02-15) 4 commits
(merged to 'next' on 2013-02-17 at b2af923)
+ count-objects: report how much disk space taken by garbage files
+ count-objects: report garbage files in pack directory too
+ sha1_file: reorder code in prepare_packed_git_one()
+ git-count-objects.txt: describe each line in -v output
Will cook in 'next'.
* tz/credential-authinfo (2013-02-25) 1 commit
- Add contrib/credentials/netrc with GPG support
A new read-only credential helper (in contrib/) to interact with
the .netrc/.authinfo files. Hopefully mn/send-email-authinfo topic
can rebuild on top of something like this.
Will merge to and cook in 'next'.
* jl/submodule-deinit (2013-02-17) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Expecting a reroll.
$gmane/216498
* jc/remove-export-from-config-mak-in (2013-02-12) 2 commits
(merged to 'next' on 2013-02-12 at eb8af04)
+ Makefile: do not export mandir/htmldir/infodir
(merged to 'next' on 2013-02-07 at 33f7d4f)
+ config.mak.in: remove unused definitions
config.mak.in template had an "export" line to cause a few
common makefile variables to be exported; if they need to be
expoted for autoconf/configure users, they should also be exported
for people who write config.mak the same way. Move the "export" to
the main Makefile. Also, stop exporting mandir that used to be
exported (only) when config.mak.autogen was used. It would have
broken installation of manpages (but not other documentation
formats).
Will cook in 'next'.
* jc/remove-treesame-parent-in-simplify-merges (2013-01-17) 1 commit
(merged to 'next' on 2013-01-30 at b639b47)
+ simplify-merges: drop merge from irrelevant side branch
The --simplify-merges logic did not cull irrelevant parents from a
merge that is otherwise not interesting with respect to the paths
we are following.
This touches a fairly core part of the revision traversal
infrastructure; even though I think this change is correct, please
report immediately if you find any unintended side effect.
Will cook in 'next'.
* jc/push-2.0-default-to-simple (2013-01-16) 14 commits
(merged to 'next' on 2013-01-16 at 23f5df2)
+ t5570: do not assume the "matching" push is the default
+ t5551: do not assume the "matching" push is the default
+ t5550: do not assume the "matching" push is the default
(merged to 'next' on 2013-01-09 at 74c3498)
+ doc: push.default is no longer "matching"
+ push: switch default from "matching" to "simple"
+ t9401: do not assume the "matching" push is the default
+ t9400: do not assume the "matching" push is the default
+ t7406: do not assume the "matching" push is the default
+ t5531: do not assume the "matching" push is the default
+ t5519: do not assume the "matching" push is the default
+ t5517: do not assume the "matching" push is the default
+ t5516: do not assume the "matching" push is the default
+ t5505: do not assume the "matching" push is the default
+ t5404: do not assume the "matching" push is the default
Will cook in 'next' until Git 2.0.
* bc/append-signed-off-by (2013-02-23) 13 commits
(merged to 'next' on 2013-02-25 at 32f7ac2)
+ git-commit: populate the edit buffer with 2 blank lines before s-o-b
+ Unify appending signoff in format-patch, commit and sequencer
+ format-patch: update append_signoff prototype
+ t4014: more tests about appending s-o-b lines
+ sequencer.c: teach append_signoff to avoid adding a duplicate newline
+ sequencer.c: teach append_signoff how to detect duplicate s-o-b
+ sequencer.c: always separate "(cherry picked from" from commit body
+ sequencer.c: require a conforming footer to be preceded by a blank line
+ sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
+ t/t3511: add some tests of 'cherry-pick -s' functionality
+ t/test-lib-functions.sh: allow to specify the tag name to test_commit
+ commit, cherry-pick -s: remove broken support for multiline rfc2822 fields
+ sequencer.c: rework search for start of footer to improve clarity
Will cook in 'next'.
^ permalink raw reply
* clean/smudge filters on .zip/.tgz files
From: Tim Chase @ 2013-02-26 22:38 UTC (permalink / raw)
To: git
Various programs that I use ([Open|Libre]Office, Vym, etc) use a
zipped/.tgz'ed file format, usually containing multiple
(usually) plain-text files within.
I'm trying to figure out a way for git to treat these as virtual
directories for purposes of merging/diffing.
Reading up on clean/smudge filters, it looks like they expect one
file coming in and one file going out, rather than one file
on one side and a directory-tree of files on the other side.
I tried creating my own pair of clean/smudge filters that would
uncompress the files, but there's no good way put multiple files on
stdout.
Has anybody else played with such a scheme for uncompressing files as
they go into git and recompressing them as they come back out?
-tkc
^ permalink raw reply
* Re: [PATCH 01/13] Use 'Git' in help messages
From: Philip Oakley @ 2013-02-26 22:56 UTC (permalink / raw)
To: Junio C Hamano, David Aguilar; +Cc: GitList
From: "Philip Oakley" <philipoakley@iee.org>
Sent: Sunday, February 24, 2013 9:50 PM
> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Sunday, February 24, 2013 8:59 AM
>> David Aguilar <davvid@gmail.com> writes:
>>
>>> This is referring to "git the command", not "git the system",
>>> so it should not be changed according to the rule that was
>>> applied when many "git" strings were changed to "Git".
>>
>> That sounds like a sensible objection.
>>
>
> I'd read the messages in the tone 'commands of the Git system', but I
> can see that both views are equally plausible. Though the final
> _("git: '%s' is not a Git command. See 'git --help'.") can't be
> referring to a 'git-<cmd>', obviously ;-)
>
>>> There are scripts, etc. in the wild that parse this output.
>>> which is another reason we would not want to change this.
>>
>> Are there? For what purpose?
>>
Just found that Git Gui checks for the version number (line 936)
if {![regsub {^git version } $_git_version {} _git_version]} {
and then parses for the dot separated digits etc.
So looks like the version string change would be a problematic
regression.
Given the change elsewhere of 'Usage:' to 'usage:' it looks like I
should drop this patch.
>> Especially when these are all _("l10n ready"), I find that somewhat
>> unlikely.
>>
>> The bash completion (in contrib/) does read from the command list
>> IIRC. I do not think it relies on the messages, though.
>
> I was aware of that bash completion used 'git help -a' so I avoided
> changing the response to that option. Initially I'd thought of making
> '-a' provide both commands and guides but knew I'd need to ensure the
> completion would still be sensible. I'd taken Juio's earlier advice to
> keep '-a' unchanged and simply add the -g|--guides option as a
> supplemental 'git help' response..
>
> Philip
^ permalink raw reply
* problem switching branches
From: J.V. @ 2013-02-26 23:08 UTC (permalink / raw)
To: git@vger.kernel.org
I was on my master branch, I then checked out a branch (
origin/somebranch ), made no updates
but did a few git pulls on the branch over about a week; then made a
small change to only a single file & committed & pushed.
Now am trying to go back to my master branch and get:
error: The following untracked working tree files would be overwritten
by checkout:
lib/derbyclient.jar
Please move or remove them before you can switch branches.
Aborting
I did not put that jar file there (I edited a single config file), how
do I now get back to my master branch?
I do not want to muck up the branch that I am now on by deleting anything.
Any ideas how this happened?
Obviously someone put derbyclient.jar there, not sure, but it is
supposed to be there so do not want to remove as advised.
any ideas on how I can get back to my master branch and get out of this?
^ permalink raw reply
* Re: gc does not clean up after itself when not enough disk space
From: Sitaram Chamarty @ 2013-02-27 0:28 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, jones.noamle, git
In-Reply-To: <512D1B8C.9070506@web.de>
On Wed, Feb 27, 2013 at 2:01 AM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
> Am 26.02.2013 17:07, schrieb Junio C Hamano:
>> "jones.noamle" <lenoam@gmail.com> writes:
>>
>>> # git gc
>>> Counting objects: 44626, done.
>>> Delta compression using up to 8 threads.
>>> Compressing objects: 100% (7756/7756), done.
>>> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
>>> space left on device
>>
>> In general when we encounter an unexpected error, we tend to try
>> leaving things as they are so that we can help diagnosing the
>> failure. But when you ran out of disk space I would agree that it
>> may be sensible to remove a temporary file we didn't manage to write
>> out in full.
>
> Ack. I just recently had to do
>
> git gc || rm -f .git/objects/*/tmp_*
>
> as workaround in the nightly housekeeping script on our CI server.
it's not just 'git gc'; a failed push of a large repo (failed due to,
say, network issues or whatever) also leave tmp_* lying around. At
least as far as I can tell...
^ permalink raw reply
* [PATCH] Documentation/submodule: Add --force to update synopsis
From: Brad King @ 2013-02-27 0:41 UTC (permalink / raw)
To: git; +Cc: gitster
In commit 9db31bdf (submodule: Add --force option for git submodule
update, 2011-04-01) we added the option to the implementation's usage
synopsis but forgot to add it to the synopsis in the command
documentation. Add the option to the synopsis in the same location it
is reported in usage and re-wrap the options to avoid long lines.
Signed-off-by: Brad King <brad.king@kitware.com>
---
Documentation/git-submodule.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index a0c9df8..c604731 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,8 +13,9 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
- [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
+'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
+ [-f|--force] [--rebase] [--reference <repository>] [--merge]
+ [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox