* Re: [PATCH v2] ident: check /etc/mailname if email is unknown
From: Ian Jackson @ 2011-10-03 11:32 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jonathan Nieder, Junio C Hamano, git, Matt Kraai, Gerrit Pape,
Linus Torvalds
In-Reply-To: <4E895FBD.8020904@viscovery.net>
Johannes Sixt writes ("Re: [PATCH v2] ident: check /etc/mailname if email is unknown"):
> Am 10/3/2011 8:16, schrieb Jonathan Nieder:
> > +static int add_mailname_host(char *buf, size_t len)
> > +{
> > + FILE *mailname;
> > +
> > + mailname = fopen("/etc/mailname", "r");
> > + if (!mailname) {
> > + if (errno != ENOENT)
> > + warning("cannot open /etc/mailname: %s",
> > + strerror(errno));
>
> This warns on EACCES. Is that OK? (Just asking, I have no opinion.)
I think that's correct. Personally I'm a bit of an error handling
fascist and I would have it crash on EACCES but that's probably a bit
harsh.
Certainly this file ought to be generally readable, if it exists.
Ian.
^ permalink raw reply
* [PATCH/RFC] remote: support --all for the prune-subcommand
From: Erik Faye-Lund @ 2011-10-03 12:16 UTC (permalink / raw)
To: git
While we're at it, wrap a long line to fit on a 80 char terminal.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
I recently needed to prune remote branches in a repo with a lot
of remotes, and to my surprise "git remote prune" didn't support
the --all option. So I added it. Perhaps this is useful for other
people as well?
Documentation/git-remote.txt | 2 +-
builtin/remote.c | 27 ++++++++++++++++++++-------
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 5a8c506..856cc7f 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -19,7 +19,7 @@ SYNOPSIS
'git remote set-url --add' [--push] <name> <newurl>
'git remote set-url --delete' [--push] <name> <url>
'git remote' [-v | --verbose] 'show' [-n] <name>
-'git remote prune' [-n | --dry-run] <name>
+'git remote prune' [-n | --dry-run] (--all | <name>...)
'git remote' [-v | --verbose] 'update' [-p | --prune] [(<group> | <remote>)...]
DESCRIPTION
diff --git a/builtin/remote.c b/builtin/remote.c
index f2a9c26..2e8407d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -14,7 +14,7 @@ static const char * const builtin_remote_usage[] = {
"git remote rm <name>",
"git remote set-head <name> (-a | -d | <branch>)",
"git remote [-v | --verbose] show [-n] <name>",
- "git remote prune [-n | --dry-run] <name>",
+ "git remote prune [-n | --dry-run] (--all | <name>)",
"git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)...]",
"git remote set-branches <name> [--add] <branch>...",
"git remote set-url <name> <newurl> [<oldurl>]",
@@ -1222,22 +1222,35 @@ static int set_head(int argc, const char **argv)
return result;
}
+static int add_one_remote(struct remote *remote, void *remotes)
+{
+ string_list_append(remotes, remote->name);
+ return 0;
+}
+
static int prune(int argc, const char **argv)
{
- int dry_run = 0, result = 0;
+ struct string_list remotes = STRING_LIST_INIT_NODUP;
+ int dry_run = 0, result = 0, all = 0, i;
struct option options[] = {
+ OPT_BOOLEAN(0, "all", &all, "prune all remotes"),
OPT__DRY_RUN(&dry_run, "dry run"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
- 0);
+ argc = parse_options(argc, argv, NULL, options,
+ builtin_remote_prune_usage, 0);
- if (argc < 1)
+ if (all)
+ for_each_remote(add_one_remote, &remotes);
+ else if (argc < 1)
usage_with_options(builtin_remote_prune_usage, options);
+ else
+ for (; argc; argc--, argv++)
+ string_list_append(&remotes, *argv);
- for (; argc; argc--, argv++)
- result |= prune_remote(*argv, dry_run);
+ for (i = 0; i < remotes.nr; ++i)
+ result |= prune_remote(remotes.items[i].string, dry_run);
return result;
}
--
1.7.6.msysgit.0.579.ga3d6f
^ permalink raw reply related
* Re: [PATCH] diff: resurrect XDF_NEED_MINIMAL with --minimal
From: Jonathan Nieder @ 2011-10-03 12:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, René Scharfe, Tay Ray Chuan
In-Reply-To: <7voby0j86c.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * This together with René's c5aa906 (Revert removal of multi-match
> discard heuristic in 27af01, 2011-09-25) on top of v1.7.7 seems to give
> identical diff output as v1.7.1 (e.g. "git diff-tree -p v2.6.39 v3.0"
> in the kernel repository, with "--minimal").
Very neat.
> --- a/diff.c
> +++ b/diff.c
> @@ -3511,6 +3511,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
> }
> else if (!strcmp(arg, "--abbrev"))
> options->abbrev = DEFAULT_ABBREV;
> + else if (!strcmp(arg, "--minimal"))
> + DIFF_XDL_SET(options, NEED_MINIMAL);
> + else if (!strcmp(arg, "--no-minimal"))
> + DIFF_XDL_CLR(options, NEED_MINIMAL);
> else if (!prefixcmp(arg, "--abbrev=")) {
I think this would fit well near --patience (the "xdiff options"
section), instead of hidden between the unsticked and sticked forms of
--abbrev. ;-)
Like this:
diff --git i/Documentation/diff-options.txt w/Documentation/diff-options.txt
index b620b3af..4d87256e 100644
--- i/Documentation/diff-options.txt
+++ w/Documentation/diff-options.txt
@@ -48,6 +48,10 @@ endif::git-format-patch[]
--patience::
Generate a diff using the "patience diff" algorithm.
+--minimal::
+ Spend extra time to make sure the smallest possible
+ diff is produced.
+
--stat[=<width>[,<name-width>[,<count>]]]::
Generate a diffstat. You can override the default
output width for 80-column terminal by `--stat=<width>`.
diff --git i/diff.c w/diff.c
index fcc00780..2282f86f 100644
--- i/diff.c
+++ w/diff.c
@@ -3393,6 +3393,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
else if (!strcmp(arg, "--patience"))
DIFF_XDL_SET(options, PATIENCE_DIFF);
+ else if (!strcmp(arg, "--minimal"))
+ DIFF_XDL_SET(options, NEED_MINIMAL);
+ else if (!strcmp(arg, "--no-minimal"))
+ DIFF_XDL_CLR(options, NEED_MINIMAL);
else if (!strcmp(arg, "--histogram"))
DIFF_XDL_SET(options, HISTOGRAM_DIFF);
^ permalink raw reply related
* Re: [PATCH] show git tag output in pager
From: Matthieu Moy @ 2011-10-03 12:57 UTC (permalink / raw)
To: Jeff King; +Cc: Michal Vyskocil, git
In-Reply-To: <20110930104241.GB24507@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Sep 29, 2011 at 11:37:49AM +0200, Michal Vyskocil wrote:
>
>> On Tue, Sep 27, 2011 at 04:19:39PM +0200, Matthieu Moy wrote:
>> > The commit message should explain why this is needed, and in particular
>> > why you prefer this to setting pager.tag in your ~/.gitconfig.
>>
>> Opps! I read a documentation, but I did not realize this works for all
>> commands and not only for them calling setup_pager(). Then sorry, no
>> change is needed.
>
> I don't think you want to set pager.tag. It will invoke the pager for
> all tag subcommands, including tag creation and deletion.
That's the kind of argument/discussion I was expecting in the commit
message.
> I think instead, you want some way for commands to say "OK, I'm in a
> subcommand that might or might not want a pager now".
Right.
I like the try_subcommand_pager idea. Ideally, there would also be a
nice mechanism to set defaults for subcommands, so that "git tag
<whatever>" does the right thing without configuration.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] diff: resurrect XDF_NEED_MINIMAL with --minimal
From: Tay Ray Chuan @ 2011-10-03 13:04 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, René Scharfe
In-Reply-To: <20111003123843.GA15493@elie>
On Mon, Oct 3, 2011 at 8:38 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Thanks for the Cc, Johnathan.
> Junio C Hamano wrote:
>
>> * This together with René's c5aa906 (Revert removal of multi-match
>> discard heuristic in 27af01, 2011-09-25) on top of v1.7.7 seems to give
>> identical diff output as v1.7.1 (e.g. "git diff-tree -p v2.6.39 v3.0"
>> in the kernel repository, with "--minimal").
>
> Very neat.
Interesting. Clearly there is more than just the multi-match discard
heuristic in (xdl_clean_mmatch() and xdl_cleanup_records()).
> diff --git i/diff.c w/diff.c
> index fcc00780..2282f86f 100644
> --- i/diff.c
> +++ w/diff.c
> @@ -3393,6 +3393,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
> DIFF_XDL_SET(options, IGNORE_WHITESPACE_AT_EOL);
> else if (!strcmp(arg, "--patience"))
> DIFF_XDL_SET(options, PATIENCE_DIFF);
> + else if (!strcmp(arg, "--minimal"))
> + DIFF_XDL_SET(options, NEED_MINIMAL);
> + else if (!strcmp(arg, "--no-minimal"))
> + DIFF_XDL_CLR(options, NEED_MINIMAL);
> else if (!strcmp(arg, "--histogram"))
> DIFF_XDL_SET(options, HISTOGRAM_DIFF);
>
>
That's an improvement, but it would be even better if it was placed
above the --<strategy> options, instead of being placed between them.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jay Soffian @ 2011-10-03 13:13 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, John Szakmeister
In-Reply-To: <20111003105908.GF16078@sigill.intra.peff.net>
On Mon, Oct 3, 2011 at 6:59 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Sep 30, 2011 at 06:42:22PM -0400, Jay Soffian wrote:
>
>> Usually it won't. In the default case, the keychain is unlocked and no
>> permission is needed to add an entry, nor to retrieve that entry by
>> the application which added it. The prompt will only occur if the
>> credential helper is not on the entry's ACL, or if the keychain is
>> locked.
>
> Yeah. I was thinking the ACL prompt would come up more often, but I
> guess most people would hit "allow always", since it would get annoying
> pretty quickly otherwise (I didn't, because I was testing).
In the normal case, the keychain entry would be added via the
credential helper, so they'd never even see the prompt since the
binary which adds an entry is automatically on that entry's ACL.
> Side note: do you know how to edit those ACLs? I couldn't find it in the
> keychain manager. It would be helpful for testing to be able to tweak it
> (as a workaround, I just modified the binary, which apparently the
> keychain code cares about).
Double-click on the entry in Keychain Access, then click the "Access
Control" tab.
j.
^ permalink raw reply
* Re: [PATCH] contrib: add a pair of credential helpers for Mac OS X's keychain
From: Jay Soffian @ 2011-10-03 13:16 UTC (permalink / raw)
To: John Szakmeister; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <CAEBDL5XhLAccfMoSyBjDA4ZsCgc4FnxEVYyqJsnGfzDW3Otudw@mail.gmail.com>
On Sat, Oct 1, 2011 at 2:57 AM, John Szakmeister <john@szakmeister.net> wrote:
>>> I don't use GitHub for Mac... does that mean this is busted for me?
>>
>> No. It just means that the credential helper and GitHub for Mac store
>> their entry in a compatible fashion. (So that each can locate the
>> entry stored by the other.)
>
> Ah, interesting. But it does mean that it won't pick up the password
> I've cached via my browser, right?
Correct. I can add code to also make it look for the password entry as
stored by Safari/Chrome. It's actually stored as a slightly different
entry type ("Web form password" vs "Internet password"), so it's not
just the hostname difference.
j.
^ permalink raw reply
* Unable to remove a file
From: robert mena @ 2011-10-03 14:21 UTC (permalink / raw)
To: git
Hi,
I had a file called \ under a directory scripts. I've removed,
committed, pushed to the server BUT my windows clients when they try
to clone I stop because of this.
Don't ask me why and it is probably windows/the IDE fault but I have
to solve it.
I found the command filter but it is not working.
git filter-branch --index-filter 'git rm --cached scripts/\\' HEAD
Rewrite b75a1a3af45a4d82fcfe7a6148fc4d6e1c55ee91 (1/48)rm 'scripts/\'
Rewrite 8a32d6194e9c46dc0f1ce60a2245fcbcd7c12d00 (2/48)rm 'scripts/\'
Rewrite 892bba8bd7563186d7b1c493cf05d8823cfe2f7b (3/48)rm 'scripts/\'
Rewrite 0be74d8143f670b08806510dd09cf77029f57bcb (4/48)rm 'scripts/\'
Rewrite ec7e45a5d8100b7a1e49ca8d0cf5ec5d638f2dd7 (5/48)rm 'scripts/\'
Rewrite c9dde5bf86391a66f80dc86bcc3078c78866b5da (6/48)rm 'scripts/\'
Rewrite 499be785b2538a1d6b382e1a0d6e9bdc8a771a76 (7/48)rm 'scripts/\'
Rewrite 327ac340d4dee02bc2bfed07bd94df5f87b8036c (8/48)rm 'scripts/\'
Rewrite 5ae256edce2959585b2819c4d6d0d4704b02984a (9/48)rm 'scripts/\'
Rewrite 3811ef08c5a2be9f4f049c50caf501944483ec72 (10/48)rm 'scripts/\'
Rewrite 52b3de12d3cde4f6bb920d335fe8629d368d965b (11/48)rm 'scripts/\'
Rewrite ff115cd8f3213d8218d369361d5ee77010081c22 (12/48)rm 'scripts/\'
Rewrite d28c02b462e8ee70c6d516d7d2c6754b82bfc80e (13/48)rm 'scripts/\'
Rewrite 173aecfa81f64644747934f815befb8f83daf6ce (14/48)rm 'scripts/\'
Rewrite d4649a98584c25c1c8d52adbd49d822c961dc7cb (15/48)rm 'scripts/\'
Rewrite d026354566abc0d135cdd3838fa96055baa29a03 (16/48)rm 'scripts/\'
Rewrite 9f7869cf30bc0c04e072859bfbc1325758a5e893 (17/48)rm 'scripts/\'
Rewrite 6058b6d0b783cd290ce78e344f442d161989b72d (18/48)rm 'scripts/\'
Rewrite 7f7842d461a645223e39d5b6c451ec8b3e8f89a4 (19/48)rm 'scripts/\'
Rewrite 11f9ad3c22746e4fddb407790eb0db4db709902d (20/48)fatal:
pathspec 'scripts/\' did not match any files
index filter failed: git rm --cached scripts/\
How can I really delete this without having to start from scratch? I
won't hold my breath for windows or even the IDE's to detect this and
solve it.
^ permalink raw reply
* pack-object poor performance (with large number of objects?)
From: Piotr Krukowiecki @ 2011-10-03 14:43 UTC (permalink / raw)
To: Git Mailing List; +Cc: Ingo Molnar, Junio C Hamano
Hi,
I'm having poor git gc (pack-object) performance. Please read below
for details. What can I do to improve the performance/debug the reason
for the slowness? Should I leave the process running over night, or
should I stop it (for debugging)?
CCing people who posted some patches/benchmarks for pack-objects recently.
git gc was first run automatically by git svn clone. It found 1544673
objects and worked for 50 minutes until I've killed it.
Then I've run it by hand with --aggresive (because I've found on
Internet it helped in some cases). It found 1742200 objects this time.
At this moment it's been working for about 90 minutes.
The large number of unpacked objects is probably caused by me - I've
disabled auto gc when I was cloning from svn (I though it might speed
up things if it didn't repack several times during clone, only once
afterwards).
My git version is 1.7.7.rc3.4.g8d714
The file system is ext4.
First run process tree:
pkruk 27873 0.0 0.0 15704 816 pts/2 S+ 11:53 0:00
| | \_ git gc --auto
pkruk 27885 0.0 0.0 15704 776 pts/2 S+ 11:53 0:00
| | \_ git repack -d -l
pkruk 27886 0.0 0.0 4220 608 pts/2 S+ 11:53 0:00
| | \_ /bin/sh
/usr/local/stow/git-master/libexec/git-core/git-repack -d -l
pkruk 27897 3.6 9.3 1136072 381148 pts/2 D+ 11:53 5:51
| | \_ git
pack-objects --keep-true-parents --honor-pack-keep --non-empty --all
--reflog --unpacked --incremental --local --delta-base-offset
/home/pkruk/dv/devel1_git_repos/.git/objects/pack/.tmp-27886-pack
Second run process tree:
pkruk 6171 0.0 0.0 15704 1428 pts/2 S+ 14:34 0:00
| | \_ git gc --aggressive
pkruk 6174 0.0 0.0 15704 1356 pts/2 S+ 14:34 0:00
| | \_ git repack -d -l -f
--depth=250 --window=250 -A
pkruk 6175 0.0 0.0 4220 648 pts/2 S+ 14:34 0:00
| | \_ /bin/sh
/usr/local/stow/git-master/libexec/git-core/git-repack -d -l -f
--depth=250 --window=250 -A
pkruk 6189 4.9 10.5 1143640 427396 pts/2 D+ 14:34 4:50
| | \_ git pack-objects
--keep-true-parents --honor-pack-keep --non-empty --all --reflog
--unpack-unreachable --local --no-reuse-delta --depth=250 --window=250
--delta-base-offset
/home/pkruk/dv/devel1_git_repos/.git/objects/pack/.tmp-6175-pack
--
Piotr Krukowiecki
^ permalink raw reply
* Re: Branches & directories
From: Robin Rosenberg @ 2011-10-03 14:59 UTC (permalink / raw)
To: Hilco Wijbenga
Cc: Jeff King, Kyle Moffett, Michael Witten, Junio C Hamano,
Evan Shelhamer, Git Mailing List
In-Reply-To: <CAE1pOi2xmVHrVJcC85wvCv=anhn_kYizyUMpUVZF4EE33RoGmg@mail.gmail.com>
Hilco Wijbenga skrev 2011-10-03 09.15:
> On 2 October 2011 20:07, Jeff King<peff@peff.net> wrote:
> <snip/>
>> Or did you really mean your example literally, as in you run two
>> checkouts back to back, without running anything in between, and the
>> second checkout restores the state before the first one. In that case,
>> yes, it would be correct to keep the old timestamps. But this is an
>> optimization that can only apply in a few very specific cases. And
>> moreoever, how can git know when it is OK to apply that optimization? It
>> has no idea what commands you might have run since the last time we were
>> at "master".
> Yes, I meant it literally. And, no, Git could not possibly know so it
> would have to be optional behaviour. But it's probably a lot of work
> for (for most people) little gain.
> --
> 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
>
I wouldn't use stash for that. Just regular commit/amend and your
timestamps should be fine. Alternative submit a patch for either
the save or create subcommands of stash. That would not be very
hard (technically) and no one needs to mess with the timestamps;
they will just survive.
-- robin
^ permalink raw reply
* Re: Unable to remove a file
From: Andreas Schwab @ 2011-10-03 16:04 UTC (permalink / raw)
To: robert mena; +Cc: git
In-Reply-To: <CAAZ43xa2upWQ2LWJRVcOPew3kF0W7gSz9UgQ=g0gnMHKQB3Y4A@mail.gmail.com>
robert mena <robert.mena@gmail.com> writes:
> I found the command filter but it is not working.
>
> git filter-branch --index-filter 'git rm --cached scripts/\\' HEAD
$ git filter-branch --index-filter 'git rm -q --ignore-unmatch --cached scripts/\\' HEAD
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: pack-object poor performance (with large number of objects?)
From: Shawn Pearce @ 2011-10-03 16:05 UTC (permalink / raw)
To: Piotr Krukowiecki; +Cc: Git Mailing List, Ingo Molnar, Junio C Hamano
In-Reply-To: <CAA01CspZijOO_xbR=OcaRaesTeSy=6RM4DR01-07qimVzxvJZA@mail.gmail.com>
On Mon, Oct 3, 2011 at 07:43, Piotr Krukowiecki
<piotr.krukowiecki@gmail.com> wrote:
> I'm having poor git gc (pack-object) performance. Please read below
> for details. What can I do to improve the performance/debug the reason
> for the slowness? Should I leave the process running over night, or
> should I stop it (for debugging)?
> CCing people who posted some patches/benchmarks for pack-objects recently.
>
> git gc was first run automatically by git svn clone. It found 1544673
> objects and worked for 50 minutes until I've killed it.
>
> Then I've run it by hand with --aggresive (because I've found on
> Internet it helped in some cases). It found 1742200 objects this time.
> At this moment it's been working for about 90 minutes.
Packing time depends on a number of factors. One of them is the number
of unpacked objects to process. With 1.7 million objects, yes, its
going to take some time. Another factor is how much RAM you have on
your system. Packing requires a lot of memory, especially with the
--aggressive flag, as the packer tries up to 250 different
combinations of two objects searching for a good delta compression
format, and all 250 of those are typically in-memory at once. If you
have insufficient physical RAM, the system will swap, unless you
decrease the window size.
> The large number of unpacked objects is probably caused by me - I've
> disabled auto gc when I was cloning from svn (I though it might speed
> up things if it didn't repack several times during clone, only once
> afterwards).
Yes, this the reason `git svn` runs GC during its import. If you defer
all of the repacking work until the end, with everything loose, it can
take a very, very long time to repack. If you repack as you go, the
incremental repacks are less expensive than a full repack, and the
entire process will go faster overall.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] git checkout $tree path
From: Junio C Hamano @ 2011-10-03 16:08 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111003102647.GD16078@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But we can't distinguish those two cases without actually having a merge
> base. And this isn't a merge; it's not about picking changes from
> master, it's about saying "make dir look like it does in master". So
> in that sense, the most straightforward thing is your second
> alternative: afterwards, we should have only the files in "dir" that
> master has.
We can think of it both ways, but the "make it look like the other one"
unfortunately is too big a departure from the traditional semantics. At
least I wanted "checkout master -- $path" to mean "I want to copy $path
out of master and _overlay_ that on top of what I have now", similar to
the way how "tar xf master.tar $path" and "cp -r ../master/$path $path"
would be used, so that the command can help the user advance what is in
progress and already underway in $path in the current working tree.
Replacing could be easily done with "git rm -r [--cached] $path" followed
by "git checkout $tree $path" under the original semantics, but overlaying
is not very easily done if "git checkout $tree $path" had your "make $path
look like it does in $tree" semantics.
The change brought in by the RFC/PATCH does change the behaviour, and I am
fairly comfortable now to say that it is a bugfix ("copy and overlay" a la
"tar xf" never clobbers/removes files not in the source, but the current
code does).
^ permalink raw reply
* strange behaviour, default branch on clone not as expected
From: Chris Friesen @ 2011-10-03 16:50 UTC (permalink / raw)
To: git
Hi,
I have a bare repository on a server with (among others) branches
"atca6900-ecgl" and "ncgl". The "HEAD" file in the bare repository
contains "ref: refs/heads/ncgl" and "git branch" in the bare repository
shows an asterisk beside "ncgl".
However, if I clone the bare repository I get "atca-6900-ecgl" as the
default branch. ".git/HEAD" contains "ref: refs/heads/atca6900-ecgl".
Something that might be relevent--currently both of these branches
actually point to the same commit (Don't ask, it's a vendor thing.) thus
"refs/heads/atca6900-ecgl" and "refs/heads/ncgl" have the same contents.
I find it suspicious that atca6900-ecgl is alphabetically before ncgl
and that they point to the same commit ID...but I don't know how it
works internally so this may be just coincidence.
Any ideas what's going on? I'm using git 1.7.3.2 if it makes any
difference.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [RFC/PATCH]: reverse bisect v 2.0
From: Junio C Hamano @ 2011-10-03 17:00 UTC (permalink / raw)
To: Jeff King
Cc: Michal Vyskocil, git, Sverre Rabbelier, Johannes Sixt,
Christian Couder
In-Reply-To: <20111003104112.GE16078@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Sep 30, 2011 at 11:13:25AM -0700, Junio C Hamano wrote:
>
>> I wonder if something along the following line would make the usage more
>> pleasant and self-explanatory:
>>
>> $ git bisect start --used-to='git frotz says xyzzy' v0.99 master
>> Bisecting: 171 revisions left to test after this (roughly 8 steps)
>> $ ... build and then test ...
>> $ git bisect tested
>> You are trying to check: git frotz says xyzzy
>> Does the result satisify what you are trying to find [y/n]? yes
>
> I like this idea a lot. My "yes/no" thing was a "if I were designing
> bisect from scratch today..." suggestion, but having something like
> --used-to makes it a natural addition to the regular good/bad interface.
> And I really like the prompt to help people remember what it is they're
> declaring each time.
I forgot to clarify that "tested" was only to help users who wanted
reminder; if the user is confident with the usual "yes/no", the
interactivity is not required.
> However, --used-to feels a bit backwards to me. I think of it as
> "--has-property" or something similar.
I do not think --used-to='frotz says xyzzy' is a good phrasing at all; it
is grammatically incorrect. But --has-property has one large downside. At
least --used-to makes it clear that the user is supposed to decribe the
property of the tree in the past.
Let's step back a bit to understand why I think this is not optimal.
The low-level "bisect" machinery is about bisecting a history whose
ancient commits have a property (e.g. "used to work" or "used to be
broken") and more recent ones does not have the property to find one
commit where the property is lost. Conceptually, this "property" does not
have any value judgement associated with it, but historically, we called
that property "good" (and lack of it "bad"), which caused confusion at the
surface level when looking for a recent fix. The user has to say "ah, this
is still broken and does not contain the fix---good" with a twisted mind.
To dissociate the value judgement from the "property", it is a good idea
to allow users to operate the bisect machinery without using "good/bad",
and "yes/no" is a good pair of words to use. However, the user still needs
to be aware of the fact that the "property" must exist in older history
and must be lacking in newer history.
"--has-property" strips the value judgement but does not surface this
crucial point to the UI. When the user wants to find a recent fix, the
property can be spelled in various ways: "it is broken", "it no longer is
broken", "it is fixed", "it works", etc.. We need to map the 'yes' answer
to 'bad' if --has-property=works is given and the user is looking for a
fix, not a regression. But --has-property does not explicitly tell the
user that the property must exist in the past and absent in the present.
My --used-to was an attempt to surface this "we are looking for a commit
that changed the condition that used to hold, but no longer holds for
recent commits" to the UI level and force "yes == observation consistent
with the older tree" and "no == new tree" interpretation, without a need
to map yes/no to good/bad or bad/good depending on what is hunted.
The alternative approach of "bisect start --reverse" was an attempt to
allow swapping this mapping. When reverse is in effect, "good" maps to
"observation consistent with the newer tree". I do not _mind_ mapping if
it turns out to be absolutely necessary, but I wanted to see if we can do
this without one.
> something appeared (be it a bug, a feature, or whatever). But I guess it
> depends on what you are bisecting. In my case, "yes" would be the
> current "bad", and "no" would be the current "good".
I think we are aiming for the same thing, but I think you are assuming
that a naive user would always describe the condition that used to hold
with --has-property without being told; I do not think that assumption
holds.
^ permalink raw reply
* Re: pack-object poor performance (with large number of objects?)
From: Piotr Krukowiecki @ 2011-10-03 17:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Git Mailing List, Ingo Molnar, Junio C Hamano
In-Reply-To: <CAJo=hJtw+sYrP09zrDbZJNGHDYOeguQLkOe88FBYQDZrnaqsAw@mail.gmail.com>
On Mon, Oct 3, 2011 at 6:05 PM, Shawn Pearce <spearce@spearce.org> wrote:
> On Mon, Oct 3, 2011 at 07:43, Piotr Krukowiecki
> <piotr.krukowiecki@gmail.com> wrote:
>> I'm having poor git gc (pack-object) performance. Please read below
>> for details. What can I do to improve the performance/debug the reason
>> for the slowness? Should I leave the process running over night, or
>> should I stop it (for debugging)?
>> CCing people who posted some patches/benchmarks for pack-objects recently.
>>
>> git gc was first run automatically by git svn clone. It found 1544673
>> objects and worked for 50 minutes until I've killed it.
>>
>> Then I've run it by hand with --aggresive (because I've found on
>> Internet it helped in some cases). It found 1742200 objects this time.
>> At this moment it's been working for about 90 minutes.
>
> Packing time depends on a number of factors. One of them is the number
> of unpacked objects to process. With 1.7 million objects, yes, its
> going to take some time.
Any statistics how long it should take?
> Another factor is how much RAM you have on
> your system. Packing requires a lot of memory, especially with the
> --aggressive flag, as the packer tries up to 250 different
> combinations of two objects searching for a good delta compression
> format, and all 250 of those are typically in-memory at once. If you
> have insufficient physical RAM, the system will swap, unless you
> decrease the window size.
I have 4GB of RAM and not all was used so it certainly shouldn't be
swapping. The process was in 'D' state so I suppose the hard disk
might be the limiting factor.
I think I also disabled threading (I'll check tomorrow) - I suppose it
has impact on packing time too.
I'll re-run packing tomorrow with threading and check the memory
usage, is there anything else I can do?
>
>> The large number of unpacked objects is probably caused by me - I've
>> disabled auto gc when I was cloning from svn (I though it might speed
>> up things if it didn't repack several times during clone, only once
>> afterwards).
>
> Yes, this the reason `git svn` runs GC during its import. If you defer
> all of the repacking work until the end, with everything loose, it can
> take a very, very long time to repack. If you repack as you go, the
> incremental repacks are less expensive than a full repack, and the
> entire process will go faster overall.
I've learned the lesson :)
--
Piotr Krukowiecki
^ permalink raw reply
* Re: Do we have a convenient way to refer to a specific commit in an already filtered rev-list?
From: Tzu-Jung Lee @ 2011-10-03 17:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110927213517.GB5176@sigill.intra.peff.net>
On Wed, Sep 28, 2011 at 5:35 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Sep 25, 2011 at 12:46:20AM +0800, Tzu-Jung Lee wrote:
>
>> Do we have a convenient/symbolic way to refer to a specific commit of
>> an already filtered rev-list? For example, I'm interested in the
>> commits with some constraints:
>>
>> git log somepath --author=someone
>>
>> Without gui/tui tools, I have to frequently CUT & PASTE the commit-ID
>> for further manipulation (show, cherry-pick, ...), and possibly repeat
>> the parsing couple of times if I didn't save the output. I wonder if
>> we have a convenient way to refer to the discrete commits? like
>> HEAD~4, HEAD@{3} or something magic.
>
> Use the shell:
>
> git rev-list --author=someone HEAD >saved-query
> git log --no-walk --stdin <saved-query
> git cherry-pick `cat saved-query`
>
> or even:
>
> q=`git rev-list --author=someone HEAD`
> git log --no-walk $q
> git cherry-pick $q
>
> -Peff
>
Cool, this does record and replay.
How about adding a command or teaching some existing one an option
like --saved=<ref_name>, which put the saved-list to
refs/saved/<ref_name> ?
And also teach the rev-list to parse or interpret the 'saved' refs differently.
So we can have the following use case:
git log branch_foo --author=some_one -S some_string --saved=cached_ref
git log cached_ref
git cherry-pick cached_ref~4
git format-patch cached_ref~6..cached_ref~2
I often have such use cases. not sure others would be benefited from
such feature.
Just asking for comment. :)
Regards,
Roy
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-10-03 17:20 UTC (permalink / raw)
To: Robin Rosenberg
Cc: Jeff King, Kyle Moffett, Michael Witten, Junio C Hamano,
Evan Shelhamer, Git Mailing List
In-Reply-To: <4E89CDCA.9030802@gmail.com>
On 3 October 2011 07:59, Robin Rosenberg <robin.rosenberg@gmail.com> wrote:
> Hilco Wijbenga skrev 2011-10-03 09.15:
>>
>> On 2 October 2011 20:07, Jeff King<peff@peff.net> wrote:
>> <snip/>
>>>
>>> Or did you really mean your example literally, as in you run two
>>> checkouts back to back, without running anything in between, and the
>>> second checkout restores the state before the first one. In that case,
>>> yes, it would be correct to keep the old timestamps. But this is an
>>> optimization that can only apply in a few very specific cases. And
>>> moreoever, how can git know when it is OK to apply that optimization? It
>>> has no idea what commands you might have run since the last time we were
>>> at "master".
>>
>> Yes, I meant it literally. And, no, Git could not possibly know so it
>> would have to be optional behaviour. But it's probably a lot of work
>> for (for most people) little gain.
>> --
>> 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
>>
> I wouldn't use stash for that. Just regular commit/amend and your
> timestamps should be fine. Alternative submit a patch for either
> the save or create subcommands of stash. That would not be very
> hard (technically) and no one needs to mess with the timestamps;
> they will just survive.
By "that" you mean jump to another branch? I don't see how doing an
explicit commit changes anything. Stashing is essentially committing
(i.e. a "dummy" commit is created to store the stash, IIUC), isn't it?
As I mentioned before, I'm quite happy with git-new-workdir. It allows
me to work exactly the way I want. I may have some philosophical
reservations about Git's timestamp handling but practically speaking
I'm a happy little camper. :-)
^ permalink raw reply
* Re: Branches & directories
From: Hilco Wijbenga @ 2011-10-03 17:31 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jeff King, Robin Rosenberg, Kyle Moffett, Michael Witten,
Junio C Hamano, Evan Shelhamer, Git Mailing List
In-Reply-To: <vpqaa9ijzt4.fsf@bauges.imag.fr>
On 3 October 2011 00:32, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
>
>> Yes, I meant it literally. And, no, Git could not possibly know so it
>> would have to be optional behaviour. But it's probably a lot of work
>> for (for most people) little gain.
>
> Not only little gain, but also important risk: users of this feature
> would be likely to spend hours debugging something just because some
> files weren't recompiled at the right time.
Possibly. When I do a git pull or similar I do a full build
regardless. I don't know of any build tool that triggers a build
because of a deleted source file (that's an actual problem I ran into
only a couple of weeks ago). Of course, in that scenario the build was
succeeding where it should have been failing. :-)
> If you want to optimize the number of files compiled by "make", then
> ccache is your friend. This one is safe.
This is all C, right? I'm in Java land so I would assume ccache is of
no use to me. And we certainly don't use make.
^ permalink raw reply
* Re: strange behaviour, default branch on clone not as expected
From: Junio C Hamano @ 2011-10-03 17:35 UTC (permalink / raw)
To: Chris Friesen; +Cc: git
In-Reply-To: <4E89E7E1.4000907@genband.com>
Chris Friesen <chris.friesen@genband.com> writes:
> I have a bare repository on a server with (among others) branches
> "atca6900-ecgl" and "ncgl". The "HEAD" file in the bare repository
> contains "ref: refs/heads/ncgl" and "git branch" in the bare
> repository shows an asterisk beside "ncgl".
>
> However, if I clone the bare repository I get "atca-6900-ecgl" as the
> default branch. ".git/HEAD" contains "ref: refs/heads/atca6900-ecgl".
If ncgl is at the same commit as the acta one, this is expected. The
protocol does not carry enough information to tell which branch HEAD
points at.
^ permalink raw reply
* Re: [PATCH v2] gitk: Show patch for initial commit
From: Junio C Hamano @ 2011-10-03 17:44 UTC (permalink / raw)
To: Marcus Karlsson; +Cc: Zbigniew J??drzejewski-Szmek, git, Paul Mackerras
In-Reply-To: <20111003063359.GA11391@kennedy.acc.umu.se>
Marcus Karlsson <mk@acc.umu.se> writes:
>> Also the gitk should be mentioned in the man-page for git-config log.showroot.
>> The current description of this option seems suboptimal because it explains
>> how it used to be, which is not really relevant:
>> log.showroot
>> If true, the initial commit will be shown as a big creation event. This is
>> equivalent to a diff against an empty tree. Tools like git-log(1) or git-
>> whatchanged(1), which normally hide the root commit will now show it. True by
>> default.
>> This could be changed to:
>> If true (the default), the root commit will be shown as a big creation
>> event --- a diff against an empty tree. This diff can be very large for
>> a project which was imported into git after some development history.
>> If log.showroot is false tools like git-log(1), git-whatchanged(1), or
>> gitk(1) will not display the added files.
>
> I agree, but that feels like something that could be made into a
> separate patch. Or should I include that too?
Please make it a separate patch. A patch to Documentation/config.txt
should go to git.git project, but gitk patch (whose "diff --git" line
should read "diff --git a/gitk b/gitk") should go first to gitk.git
project and then merged to my tree.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Martin Fick @ 2011-10-03 18:12 UTC (permalink / raw)
To: git
Cc: Christian Couder, Thomas Rast, René Scharfe, Julian Phillips,
Michael Haggerty
In-Reply-To: <201109301606.31748.mfick@codeaurora.org>
On Friday, September 30, 2011 04:06:31 pm Martin Fick wrote:
>
> OK, I narrowed it down I believe. If I comment out the
> invalidate_cached_refs() line in write_ref_sha1(), it
> speeds through this section.
>
> I guess this makes sense, we invalidate the cache and
> have to rebuild it after every new ref is added?
> Perhaps a simple fix would be to move the invalidation
> right after all the refs are updated? Maybe
> write_ref_sha1 could take in a flag to tell it to not
> invalidate the cache so that during iterative updates it
> could be disabled and then run manually after the
> update?
Would this solution be acceptable if I submitted a patch to
do it? My test shows that this will make a full fetch of
~80K changes go from 4:50min to 1:50min,
-Martin
--
Employee of Qualcomm Innovation Center, Inc. which is a
member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH/RFC] remote: support --all for the prune-subcommand
From: Jacob Helwig @ 2011-10-03 18:13 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git
In-Reply-To: <1317644168-5808-1-git-send-email-kusmabite@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
On Mon, 03 Oct 2011 14:16:08 +0200, Erik Faye-Lund wrote:
>
> While we're at it, wrap a long line to fit on a 80 char terminal.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
>
> I recently needed to prune remote branches in a repo with a lot
> of remotes, and to my surprise "git remote prune" didn't support
> the --all option. So I added it. Perhaps this is useful for other
> people as well?
>
Can't really comment on the implementation (especially since I didn't
actually look at it), but having "git remote prune --all" work would be
_tremendously_ helpful to me. Thanks for doing this!
--
Jacob Helwig
http://about.me/jhelwig
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 665 bytes --]
^ permalink raw reply
* Re: [PATCH] transport: do not allow to push over git:// protocol
From: Nguyen Thai Ngoc Duy @ 2011-10-03 18:13 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Jeff King, git
In-Reply-To: <20111003110159.GA13064@LK-Perkele-VI.localdomain>
On Mon, Oct 03, 2011 at 02:01:59PM +0300, Ilari Liusvaara wrote:
> On Mon, Oct 03, 2011 at 03:42:51AM -0400, Jeff King wrote:
> > On Sat, Oct 01, 2011 at 11:26:55AM +1000, Nguyen Thai Ngoc Duy wrote:
> >
> > The real problem here seems to be that instead of communicating "no, we
> > don't support that", git-daemon just hangs up. It would be a much nicer
> > fix if we could change that. I'm not sure it's possible, though. There's
> > not much room in the beginning of the room to make that communication in
> > a way that's backwards compatible.
>
> Oh, sure it is possible (except for remote snapshot):
>
> $ /usr/bin/git fetch git://localhost/foobar
> fatal: remote error: R access for foobar DENIED to anonymous
> $ /usr/bin/git push git://localhost/foobar
> fatal: remote error: W access for foobar DENIED to anonymous
> $ /usr/bin/git archive --remote=git://localhost/foobar HEAD
> fatal: git archive: protocol error
> $ /usr/bin/git --version
> git version 1.7.6.3
>
> Supported for fetch and push since 1.6.1-rc1 (And 1.6.1 was over
> 2.5 years ago). Oh, and even before that, but with slightly more
> ugly error message.
>
> Oh, and adding interpretation of ERR packets to git archive is easy
> (and I even happen to have git:// server that can send those to
> test against):
>
> $ git archive --remote=git://localhost/foobar HEAD
> fatal: remote error: R access for foobar DENIED to anonymous
>
> (I also tested that remote snapshotting of repository that should be
> readable succeeds, it does).
>
> --- >8 ----
> From ce3a402e4fa72cf603f92801d6f021ff89d3ac35 Mon Sep 17 00:00:00 2001
> From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> Date: Mon, 3 Oct 2011 13:55:37 +0300
> Subject: [PATCH] Support ERR in remote archive like in fetch/push
>
> Make ERR as first packet of remote snapshot reply work like it does in
> fetch/push. Lets servers decline remote snapshot with message the same
> way as declining fetch/push with a message.
>
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Yeah, maybe with this patch also?
-- 8< --
Subject: [PATCH] pack-protocol: document "ERR" line
Since a807328 (connect.c: add a way for git-daemon to pass an error
back to client), git client recognizes "ERR" line and prints a
friendly message to user if an error happens at server side.
Document this.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/technical/pack-protocol.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index a7004c6..546980c 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -60,6 +60,13 @@ process on the server side over the Git protocol is this:
"0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" |
nc -v example.com 9418
+If the server refuses the request for some reasons, it could abort
+gracefully with an error message.
+
+----
+ error-line = PKT-LINE("ERR" SP explanation-text)
+----
+
SSH Transport
-------------
--
-- 8< --
^ permalink raw reply related
* Re: [PATCH] po/pl.po: Eliminate fuzzy translations
From: Ævar Arnfjörð Bjarmason @ 2011-10-03 18:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List, Marcin Cieślak
In-Reply-To: <m3ipre4dtf.fsf@localhost.localdomain>
2011/7/7 Jakub Narebski <jnareb@gmail.com>:
> Remove all fuzzy translations by either correcting them where trivial,
> or removing them altogether.
I was about to try to submit this (better late than never) but I can't
get git-am to accept this mail which has quoted-printable format.
Can you perchance send this as a git:// URL or as a *.patch file attachment?
^ 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