* Re: git-reflog 70 minutes at 100% cpu and counting
From: Sverre Rabbelier @ 2009-12-14 20:41 UTC (permalink / raw)
To: Eric Paris; +Cc: git
In-Reply-To: <1260822484.9379.53.camel@localhost>
Heya,
On Mon, Dec 14, 2009 at 21:28, Eric Paris <eparis@redhat.com> wrote:
> What can I collect, do, whatever?
If this really is a case that we end up wanting to optimize somehow,
it would probably be very helpful to make a copy of the repository
state _before_ the gc is done.
Also, 1.5.5 is really really old in git terms, consider compiling your
own. Something post 1.6.4 might be a good idea :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Help: approach for rebasing to older commits after merging more recent commits
From: Jay Soffian @ 2009-12-14 20:38 UTC (permalink / raw)
To: git
In-Reply-To: <76718490912091204u3a4596fdi504005624d5a5bce@mail.gmail.com>
[He asks again...]
I have an interesting problem I'm not sure how best to tackle.
A small development team is basing its product on an upstream git repo that is
itself an svn clone. Currently the process looks like this:
r1--r2--r3--r4--r5 upstream trunk (git svn clone)
\ \ \
A---B---C---D---E local trunk (git clone of upstream)
\ /
F---G developerN trunk (git clones of local)
So local trunk has both daily merges from the local developers, as well as
less periodic (typically weekly) merges from upstream trunk. The reason being
that it is necessary to remain on top of the upstream bleeding edge.
This works out okay, but there is a minor problem and a major problem.
The minor problem is that the local trunk is cluttered with the developerN
merges. That is easy to solve by having local developers rebase before pushing
to local trunk. That would look like:
r1--r2--r3--r4--r5 upstream trunk
\ \ \
A---B---C---D---E---F'---G' local trunk
The major problem is that local trunk is also cluttered with merges from
upstream. The is a problem because at some point in the future, upstream
is going to declare some rN as being officially blessed. And we're going to
want to rewind any rN changes past that point.
So the question is, what's the best way to do this? Say r2 is blessed by
upstream. The obvious thing to do (I think...) is:
(local-trunk)$ git rebase -i r2
removing C and E from the pick list.
But, occassionally the merges from upstream require much conflict resolution.
Would enabling rerere during merges help with the rebasing? I would want to
reuse as much conflict resolution as possible.
Is there a better approach altogether? Should we be doing something other
than merging to stay atop upstream?
Suggestions/comments greatly appreciated.
j.
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Junio C Hamano @ 2009-12-14 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, jk, git, Brandon Casey
In-Reply-To: <7vvdg9i9mn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
>> Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF line-endings"
>> seems to be responsible.
>
> Yes, that commit is not only responsible but was deliberate. For a better
> backstory, see:
>
> http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
>
> You'd notice that I was one of the people who didn't want to have this
> change, so you don't need to convince _me_ that this was not a change to
> keep everybody happy, but you'd need to try a better job than I did back
> then to convince people who thought that "am" should directly work on
> "Thunderbird saved mails" that what they want was a bad idea X-<.
Having said that, I think you can tell "format-patch" to emit it as mime
attachment to work this around. It _might_ even make sense to do so
automatically when the payload contains CRLF but that is a separate issue.
^ permalink raw reply
* git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-14 20:28 UTC (permalink / raw)
To: git
So I have no idea what is interesting or relevant what I can collect,
what you want to know or anything like that, so this is a bit of a dump
of info and I'm sorry to whoever tries to pick anything useful out of
it. Somone who understands git might glean some interesting information
(or tell me what a fool I am) I'm going to lay out my whole working
process here and maybe people will even point out how to improve what I
do....
git-1.5.5.6-4.el5 (git in extras for RHEL5)
I have about 5 local trees that way I can work on different things
without having to rebuild quite a much especially as I go back and
change history so often with stgit. Each local tree has a .git/config
file that has about 5 different kernel trees set up as remotes. They
look something like this.
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "linus"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/remotes/linus/master
[remote "linux-next"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
fetch = +refs/heads/*:refs/remotes/linux-next/*
{snipped}
Each of these trees also has a .git/objects/info/alternatives file which
looks like so (am I using alternatives right?)
/export/kernel/kernel-1/.git/objects
/storage/kernel/kernel-1/.git/objects
On this particular machine (a very beefy dual quad core
Nehalem) /storage is a bind mount of /export. On other machines I will
mount these using NFS in which case /export doesn't exist and /storage
is the mount point. Typically (but not always) the only thing I do over
the NFS mount point is 'make install'.
In this particular tree I use stgit and on a daily basis will update my
remotes and rebase my stgit patch series on top of linux-next. I don't
know the details of the git commands going on under the covers, I just
do git remote update; stg rebase remotes/linux-next/master; I don't
know if that's relevant, but it might leave me lots of crap in the tree?
Today I decided to make a clean branch to ask Linus to pull. I exported
a patch series (about 80 patches) to an mbox file from one of my other 5
trees and I did the following
git remote update
git checkout -b working remotes/linus/master
git-am -3 -k mbox.file
all 80 or so patches in the mbox file applied and then I got
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
I waited for a while, but it still hasn't come back.
#ps -ef | grep git
paris 24134 22057 0 14:09 pts/12 00:00:00 /bin/sh /usr/bin/git-am -3 -k /tmp/fanotify.mbox
paris 25638 24134 0 14:09 pts/12 00:00:00 git gc --auto
paris 25640 25638 99 14:09 pts/12 00:58:07 git-reflog expire --all
#top
25640 paris 25 0 920m 211m 149m R 99.8 2.1 69:09.55 git-reflog
#ls -ld /proc/pid/cwd
lrwxrwxrwx 1 paris paris 0 Dec 14 15:02 /proc/25640/cwd -> /storage/kernel/kernel-2
#strace -p -T -ttt
1260821793.751746 stat(".git/objects/b2/ad3c1470e751c53bf7a4d3d53514e0debab1fc", {st_mode=S_IFREG|0444, st_size=291, ...}) = 0 <0.000043>
1260821793.751917 open(".git/objects/b2/ad3c1470e751c53bf7a4d3d53514e0debab1fc", O_RDONLY|O_NOATIME) = 40 <0.000041>
1260821793.752032 mmap(NULL, 291, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000041>
1260821793.752148 close(40) = 0 <0.000026>
1260821793.752286 munmap(0x2b4d6a90e000, 291) = 0 <0.000035>
1260821793.752538 stat(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", {st_mode=S_IFREG|0444, st_size=330, ...}) = 0 <0.000138>
1260821793.752743 open(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", O_RDONLY|O_NOATIME) = 40 <0.000027>
1260821793.752942 mmap(NULL, 330, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000024>
1260821793.753018 close(40) = 0 <0.000038>
1260821793.753289 munmap(0x2b4d6a90e000, 330) = 0 <0.000040>
1260821796.796243 stat(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", {st_mode=S_IFREG|0444, st_size=330, ...}) = 0 <0.000076>
1260821796.796440 open(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", O_RDONLY|O_NOATIME) = 40 <0.000036>
1260821796.796553 mmap(NULL, 330, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000031>
1260821796.796624 close(40) = 0 <0.000017>
1260821796.796828 munmap(0x2b4d6a90e000, 330) = 0 <0.000042>
1260821796.797124 stat(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", {st_mode=S_IFREG|0444, st_size=293, ...}) = 0 <0.008584>
1260821796.805844 open(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", O_RDONLY|O_NOATIME) = 40 <0.000114>
1260821796.806062 mmap(NULL, 293, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000041>
1260821796.806144 close(40) = 0 <0.000018>
1260821796.806341 munmap(0x2b4d6a90e000, 293) = 0 <0.000023>
1260821799.863480 stat(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", {st_mode=S_IFREG|0444, st_size=293, ...}) = 0 <0.000118>
1260821799.863737 open(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", O_RDONLY|O_NOATIME) = 40 <0.000042>
1260821799.863855 mmap(NULL, 293, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000075>
1260821799.863973 close(40) = 0 <0.000021>
1260821799.864101 munmap(0x2b4d6a90e000, 293) = 0 <0.000033>
1260821799.864306 stat(".git/objects/43/77e6fe8ac62e7b3a1b65a83665f172550440b6", {st_mode=S_IFREG|0444, st_size=272, ...}) = 0 <0.000177>
1260821799.864551 open(".git/objects/43/77e6fe8ac62e7b3a1b65a83665f172550440b6", O_RDONLY|O_NOATIME) = 40 <0.000025>
1260821799.864635 mmap(NULL, 272, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000041>
1260821799.864729 close(40) = 0 <0.000058>
1260821799.865064 munmap(0x2b4d6a90e000, 272) = 0 <0.000031>
First things I notice in the strace is that git is opening the same
objects multiple times, and there are seconds between the munmap of the
last object and the second stat of that same object....
What can I collect, do, whatever?
-Eric
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Junio C Hamano @ 2009-12-14 20:27 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: jk, git, Brandon Casey
In-Reply-To: <20091214183337.GA25462@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF line-endings"
> seems to be responsible.
Yes, that commit is not only responsible but was deliberate. For a better
backstory, see:
http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
You'd notice that I was one of the people who didn't want to have this
change, so you don't need to convince _me_ that this was not a change to
keep everybody happy, but you'd need to try a better job than I did back
then to convince people who thought that "am" should directly work on
"Thunderbird saved mails" that what they want was a bad idea X-<.
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Junio C Hamano @ 2009-12-14 20:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Git Mailing List, Alex Riesen
In-Reply-To: <4B263797.5070808@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> If a given command is not found, then help.c tries to guess which one the
> user could have meant. If help.autocorrect is 0 or unset, then a list of
> suggestions is given as long as the dissimilarity between the given command
> and the candidates is not excessively high. But if help.autocorrect was
> non-zero (i.e., a delay after which the command is run automatically), the
> latter restriction on dissimilarity was not obeyed.
>
> In my case, this happened:
>
> $ git ..daab02
> WARNING: You called a Git command named '..daab02', which does not exist.
> Continuing under the assumption that you meant 'read-tree'
> in 4.0 seconds automatically...
>
> The similarity limit that this patch introduces is already used a few lines
> later where the list of suggested commands is printed.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> help.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks. Will apply to 'maint'.
But I am curious about and would prefer to see the story behind '6'
someday.
This is not entirely a new problem that you are introducing, as the same
comparison-with-six appears in a later part of the code, but this patch
duplicates the magic number whose two instances need to match, so in that
sense it makes it more necessary than before to document the choice of
magic number somewhere in a comment in the code.
Did 8af84da (git wrapper: DWIM mistyped commands, 2008-08-31) made up just
a random number out of thin-air? What bad things would happen if we used
'600' (or '1') instead of '6'? What kind of correlation does the cut-off
value we use here should have with some intrinsic numbers your git
installation has (e.g. perhaps "must be at least 80% of average length of
available commands" or something like that)?
In the meantime, I think squashing the following in would help us keep the
two magic numbers in sync.
diff --git a/help.c b/help.c
index db888cf..fbf80d9 100644
--- a/help.c
+++ b/help.c
@@ -297,6 +297,9 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
old->names = NULL;
}
+/* how did we decide this is a good cutoff??? */
+#define SIMILAR_ENOUGH(x) ((x) < 6)
+
const char *help_unknown_cmd(const char *cmd)
{
int i, n, best_similarity = 0;
@@ -331,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
n = 1;
while (n < main_cmds.cnt && best_similarity == main_cmds.names[n]->len)
++n;
- if (autocorrect && n == 1 && best_similarity < 6) {
+ if (autocorrect && n == 1 && SIMILAR_ENOUGH(best_similarity)) {
const char *assumed = main_cmds.names[0]->name;
main_cmds.names[0] = NULL;
clean_cmdnames(&main_cmds);
@@ -349,7 +352,7 @@ const char *help_unknown_cmd(const char *cmd)
fprintf(stderr, "git: '%s' is not a git-command. See 'git --help'.\n", cmd);
- if (best_similarity < 6) {
+ if (SIMILAR_ENOUGH(best_similarity)) {
fprintf(stderr, "\nDid you mean %s?\n",
n < 2 ? "this": "one of these");
^ permalink raw reply related
* Re: git --version wrong
From: B Smith-Mannschott @ 2009-12-14 18:41 UTC (permalink / raw)
To: Brad Hutchins; +Cc: git
In-Reply-To: <4b308ad10912140852k15b5b815ge77c54525634d454@mail.gmail.com>
> On Sun, Dec 13, 2009 at 10:17 PM, B Smith-Mannschott <bsmith.occs@gmail.com>
> wrote:
>>
>> On Sun, Dec 13, 2009 at 23:51, oshybrid <oshybrid@gmail.com> wrote:
>> >
>> > After i Instal 1.6.5.5 my "git --version" still shows 1.6.0.5
>> >
>>
>> How, exactly, did you install it?
>> What's the output when you type "which git" at the command line?
>>
>> // Ben
On Mon, Dec 14, 2009 at 17:52, Brad Hutchins <oshybrid@gmail.com> wrote:
> /opt/local/bin/git
Judging by the path, it looks like the git that is actually running on
your machine was installed through macports. Is that accurate? The
current version of git offered by macports, however, is 1.6.5.3
<http://trac.macports.org/browser/trunk/dports/devel/git-core/Portfile>
which is neither the version you are expecting, nor the version you
actually have installed.
Here's my guess, based on insufficient information:
(1) You have macports package manager installed.
(2) It's been a while since you've updated it, so...
(3) The git installed by macports is outdated (1.6.0.5)
(4) You tried to install git 1.6.5.5 via some other mechanism other
than macports. Maybe one of the stand-alone git installers floating
around. Maybe you built it from source. I can't tell, because you
haven't told me.
(5) Where ever that install placed your new git, it wasn't in /opt/local/bin
(6) Your PATH environment variable either does not contain the
directory where the newer git is installed or it contains it, but said
directory is after /opt/local/bin in PATH.
(type "echo $PATH" in the shell to see what's in PATH).
I'd look in /usr/local/bin and /usr/local/git/bin to see if you can't
find the newer git there.
Failing that, please come back with an answer to the question "How,
exactly, did you install it?" from my first reply and I'll see if I
can help you further.
// Ben
^ permalink raw reply
* am fails to apply patches for files with CRLF lineendings
From: Björn Steinbrink @ 2009-12-14 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jk, git
Hi,
Jason King (cc'd) reported that a patch for a file with CRLF lineendings
fails to apply, even if generated and applied in the same repo.
doener@atjola:x $ git init
doener@atjola:x (master) $ for x in $(seq 10); do echo -e "$x\r" >> foo; done
doener@atjola:x (master) $ vim foo
doener@atjola:x (master) $ git add foo; git commit -m init
[master (root-commit) b59b963] init
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 foo
doener@atjola:x (master) $ sed -ie s/5/changed/ foo
doener@atjola:x (master) $ git commit -am changed
[master fe4ee44] changed
1 files changed, 1 insertions(+), 1 deletions(-)
doener@atjola:x (master) $ git format-patch HEAD^
0001-changed.patch
doener@atjola:x (master) $ git checkout HEAD^
Note: moving to 'HEAD^' which isn't a local branch
doener@atjola:x ((b59b963...)) $ git am 0001-changed.patch
Applying: changed
error: patch failed: foo:2
error: foo: patch does not apply
Patch failed at 0001 changed
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Using "--whitespace=fix" makes the patch apply, but converts the changed
line and the context area from CRLF to LF.
Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF line-endings"
seems to be responsible. Using "git am --rebasing" to trigger the
--keep-cr flag to mailsplit makes things work:
doener@atjola:x ((b59b963...)) $ git am --rebasing 0001-changed.patch
Applying: changed
And reverting that commit also gives the expected whitespace warning
(which is somehow squelched by the --rebasing flag it seems).
doener@atjola:x ((b59b963...)) $ git am 0001-changed.patch
Applying: changed
/home/doener/x/.git/rebase-apply/patch:14: trailing whitespace.
changed
warning: 1 line adds whitespace errors.
Björn
^ permalink raw reply
* Re: b5227d8 changes meaning of "ls-files -x 'pattern'"
From: Jeff King @ 2009-12-14 18:25 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90912140751y5d769f15pa6782914bdb04dbd@mail.gmail.com>
On Mon, Dec 14, 2009 at 09:21:06PM +0530, Sitaram Chamarty wrote:
> Before b5227d8, the following two commands would produce different
> outputs (say on git.git):
>
> git ls-files
> git ls-files -x '*.c'
>
> From b5227d8 onward, they produce the same output. The second command
> no longer excludes *.c files.
>
> I was unable to understand the commit message completely but it sounds
> like this was intentionally changed to do this.
Yes, it was intentional. Excludes are about untracked files, not about
restricting parts of the index. The point of the change was to bring
"ls-files" in harmony with other parts of git. For example, prior to
b5227d8, you could do:
$ git init
$ echo content >file && git add . && git commit -m base
$ echo changes >file
$ echo file >.gitignore
$ git ls-files --exclude-standard -m
<no output>
$ git diff-files --name-only
file
But both "ls-files --exclude-standard" and "diff-files" should
produce the same list (and they do post-b5227d8).
However, for your use case, I can see the utility of an option to limit
the output of ls-files for a particular invocation. It's just that "-x"
is tied into the excludes mechanism, which doesn't do that.
I would not be opposed to a patch to add an option that means "exclude
these index entries from the output list." And for the sake of backwards
compatibility, it may even be reasonable to call that option "-x". The
change in b5227d8 was really about ls-files mis-using .gitignore and
.git/info/exclude; people providing "-x" for a particular invocation
probably want to limit everything.
-Peff
^ permalink raw reply
* Re: git gc logs to standard error
From: Jacob Helwig @ 2009-12-14 16:46 UTC (permalink / raw)
To: Richard Rossel; +Cc: git
In-Reply-To: <4B2669CD.9020505@inf.utfsm.cl>
On Mon, Dec 14, 2009 at 08:37, Richard Rossel <rrossel@inf.utfsm.cl> wrote:
>>
>> On Mon, Dec 14, 2009 at 08:23, Richard Rossel<rrossel@inf.utfsm.cl>
>> wrote:
>>
>>>
>>> $ git --version
>>> git version 1.5.4.3
>>>
>>> And when there is no change in the repo
>>>
>>> $ git fetch --q; echo $?
>>> 0
>>>
>>> no messages and no error , but when there is a change to syncronize
>>>
>>> $ git fetch --q; echo $?
>>> remote: Counting objects: 7, done.
>>> remote: Compressing objects: 100% (5/5), done.
>>> remote: Total 5 (delta remote: 2), reused 0 (delta 0)
>>> Unpacking objects: 100% (5/5), done.
>>> From git@boss:sandbox
>>> 3e4df7f..b92d27c master -> origin/master
>>> 0
>>>
>>>
>>
>> Don't use a double dash, if you're using the short option.
>>
>> git fetch -q
>> OR
>> git fetch --quiet
>>
>> git fetch --q<--- This is not what you think it is.
>>
>> -Jacob
>>
>>
>
> doh, sorry, my mistake
>
> $ git fetch -q; echo $?
> remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 3 (delta 1), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From git@boss:sandbox
> b92d27c..17b8b5d master -> origin/master
> 0
>
> These is the output when there is a change to be syncronized
>
> BTW, in crontab the commands are using -q option, the mistake was made just
> here :)
>
It looks like you want to upgrade to at least 1.6.0.3 (I know that
with 1.6.5.5 I get no output with 'git fetch -q', whether or not there
are pending updates). There's a fix (fe8aa148) for the issue[1] it
looks like you're having.
[1] http://marc.info/?l=git&m=121529226023180&w=2
^ permalink raw reply
* Re: git gc logs to standard error
From: Richard Rossel @ 2009-12-14 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060912140828p3b05972lf9abc82c7b0f9bc1@mail.gmail.com>
>
> On Mon, Dec 14, 2009 at 08:23, Richard Rossel<rrossel@inf.utfsm.cl> wrote:
>
>> $ git --version
>> git version 1.5.4.3
>>
>> And when there is no change in the repo
>>
>> $ git fetch --q; echo $?
>> 0
>>
>> no messages and no error , but when there is a change to syncronize
>>
>> $ git fetch --q; echo $?
>> remote: Counting objects: 7, done.
>> remote: Compressing objects: 100% (5/5), done.
>> remote: Total 5 (delta remote: 2), reused 0 (delta 0)
>> Unpacking objects: 100% (5/5), done.
>> From git@boss:sandbox
>> 3e4df7f..b92d27c master -> origin/master
>> 0
>>
>>
> Don't use a double dash, if you're using the short option.
>
> git fetch -q
> OR
> git fetch --quiet
>
> git fetch --q<--- This is not what you think it is.
>
> -Jacob
>
>
doh, sorry, my mistake
$ git fetch -q; echo $?
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git@boss:sandbox
b92d27c..17b8b5d master -> origin/master
0
These is the output when there is a change to be syncronized
BTW, in crontab the commands are using -q option, the mistake was made
just here :)
--
Richard Rossel
Softare Engineer at Airsage Inc.
Valparaiso - Chile
^ permalink raw reply
* Re: git gc logs to standard error
From: Jacob Helwig @ 2009-12-14 16:28 UTC (permalink / raw)
To: Richard Rossel; +Cc: git
In-Reply-To: <4B26669A.8020806@inf.utfsm.cl>
On Mon, Dec 14, 2009 at 08:23, Richard Rossel <rrossel@inf.utfsm.cl> wrote:
>
> $ git --version
> git version 1.5.4.3
>
> And when there is no change in the repo
>
> $ git fetch --q; echo $?
> 0
>
> no messages and no error , but when there is a change to syncronize
>
> $ git fetch --q; echo $?
> remote: Counting objects: 7, done.
> remote: Compressing objects: 100% (5/5), done.
> remote: Total 5 (delta remote: 2), reused 0 (delta 0)
> Unpacking objects: 100% (5/5), done.
> From git@boss:sandbox
> 3e4df7f..b92d27c master -> origin/master
> 0
>
Don't use a double dash, if you're using the short option.
git fetch -q
OR
git fetch --quiet
git fetch --q <--- This is not what you think it is.
-Jacob
^ permalink raw reply
* Re: git gc logs to standard error
From: Richard Rossel @ 2009-12-14 16:23 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060912140804t409030b4g168014bd80a0b88c@mail.gmail.com>
>
> On Mon, Dec 14, 2009 at 07:55, Johan Herland<johan@herland.net> wrote:
>
>> On Monday 14 December 2009, Richard Rossel wrote:
>>
>>> Hi,
>>> I have a question related to the output of git gc logs. Let me
>>> explain,
>>>
>>> [...]
>>>
>>> I realized that the message are sent to standard error,
>>> so the question is why is the reason to do that?
>>>
>>> The quick solution to my problem of annoying mails is send the output
>>> error to /dev/null
>>> but what happens when an error really occur, there will be no message
>>> to alert me.
>>>
>> Try the --quiet parameter to "git gc" (and other git commands).
>>
>>
>> ...Johan
>>
>> --
>> Johan Herland,<johan@herland.net>
>> www.herland.net
>>
> I think the real problem that Richard is experiencing is that git
> fetch isn't respecting the --quiet option. The output being similar
> to git gc, and also being on STDERR seems to be a red-herring.
>
> Richard,
>
> What version of git are you using?
>
> Also, what is the output from 'git fetch --q; echo $?' if you just run
> that in your repo? If the last line you see is '0', then that should
> be the only output you see.
>
> -Jacob
>
$ git --version
git version 1.5.4.3
And when there is no change in the repo
$ git fetch --q; echo $?
0
no messages and no error , but when there is a change to syncronize
$ git fetch --q; echo $?
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta remote: 2), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From git@boss:sandbox
3e4df7f..b92d27c master -> origin/master
0
here come the messages but the return value is still 0
I will try to update git to v1.6.5.6 and see what happend
--
Richard Rossel
Airsage Inc.
Valparaiso - Chile
^ permalink raw reply
* Re: b5227d8 changes meaning of "ls-files -x 'pattern'"
From: Michael J Gruber @ 2009-12-14 16:15 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90912140751y5d769f15pa6782914bdb04dbd@mail.gmail.com>
Sitaram Chamarty venit, vidit, dixit 14.12.2009 16:51:
> Hello,
>
> Before b5227d8, the following two commands would produce different
> outputs (say on git.git):
>
> git ls-files
> git ls-files -x '*.c'
>
> From b5227d8 onward, they produce the same output. The second command
> no longer excludes *.c files.
>
> I was unable to understand the commit message completely but it sounds
> like this was intentionally changed to do this.
Yes. Generally, git commands never ignore tracked files, and this patch
reintroduces this for git ls-files
> I've never been real clear on ls-files, and was wondering if someone
> would be able to clarify the various ways of using it, including why
> this change was made and is there a way (using some other combination of
> flags perhaps) to get a list of files without *.c (to continue this
> example).
You can still use file glob patterns as the file argument, such as
git ls-files '*.[^c]'
Michael
^ permalink raw reply
* Re: git gc logs to standard error
From: Richard Rossel @ 2009-12-14 16:10 UTC (permalink / raw)
To: git
In-Reply-To: <200912141655.01268.johan@herland.net>
>
> On Monday 14 December 2009, Richard Rossel wrote:
>
>> Hi,
>> I have a question related to the output of git gc logs. Let me
>> explain,
>>
>> [...]
>>
>> I realized that the message are sent to standard error,
>> so the question is why is the reason to do that?
>>
>> The quick solution to my problem of annoying mails is send the output
>> error to /dev/null
>> but what happens when an error really occur, there will be no message
>> to alert me.
>>
> Try the --quiet parameter to "git gc" (and other git commands).
>
>
> ...Johan
>
>
Yes, the quiet option works when I do 'git gc', but in the cron file
there is no
git-gc command, only fetch and reset. I suppose that those commands
calls (internally)
to git-gc.
Also I try with -q option in fetch and reset but without results, the
only thing that
works was with 2>/dev/null, but as I mention before, is not a good idea
because
I will miss the real errors messages.
The real question here is why git-gc send those logs to the standard
error instead of
standard output?
--
Richard Rossel
Airsage Inc.
Valparaiso - Chile
^ permalink raw reply
* Re: git gc logs to standard error
From: Jacob Helwig @ 2009-12-14 16:04 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Richard Rossel
In-Reply-To: <200912141655.01268.johan@herland.net>
On Mon, Dec 14, 2009 at 07:55, Johan Herland <johan@herland.net> wrote:
> On Monday 14 December 2009, Richard Rossel wrote:
>> Hi,
>> I have a question related to the output of git gc logs. Let me
>> explain,
>>
>> [...]
>>
>> I realized that the message are sent to standard error,
>> so the question is why is the reason to do that?
>>
>> The quick solution to my problem of annoying mails is send the output
>> error to /dev/null
>> but what happens when an error really occur, there will be no message
>> to alert me.
>
> Try the --quiet parameter to "git gc" (and other git commands).
>
>
> ...Johan
>
> --
> Johan Herland, <johan@herland.net>
> www.herland.net
I think the real problem that Richard is experiencing is that git
fetch isn't respecting the --quiet option. The output being similar
to git gc, and also being on STDERR seems to be a red-herring.
Richard,
What version of git are you using?
Also, what is the output from 'git fetch --q; echo $?' if you just run
that in your repo? If the last line you see is '0', then that should
be the only output you see.
-Jacob
^ permalink raw reply
* Re: git gc logs to standard error
From: Johan Herland @ 2009-12-14 15:55 UTC (permalink / raw)
To: git; +Cc: Richard Rossel
In-Reply-To: <4B264F7B.8070504@inf.utfsm.cl>
On Monday 14 December 2009, Richard Rossel wrote:
> Hi,
> I have a question related to the output of git gc logs. Let me
> explain,
>
> [...]
>
> I realized that the message are sent to standard error,
> so the question is why is the reason to do that?
>
> The quick solution to my problem of annoying mails is send the output
> error to /dev/null
> but what happens when an error really occur, there will be no message
> to alert me.
Try the --quiet parameter to "git gc" (and other git commands).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* b5227d8 changes meaning of "ls-files -x 'pattern'"
From: Sitaram Chamarty @ 2009-12-14 15:51 UTC (permalink / raw)
To: Git Mailing List
Hello,
Before b5227d8, the following two commands would produce different
outputs (say on git.git):
git ls-files
git ls-files -x '*.c'
>From b5227d8 onward, they produce the same output. The second command
no longer excludes *.c files.
I was unable to understand the commit message completely but it sounds
like this was intentionally changed to do this.
I've never been real clear on ls-files, and was wondering if someone
would be able to clarify the various ways of using it, including why
this change was made and is there a way (using some other combination of
flags perhaps) to get a list of files without *.c (to continue this
example).
Thanks,
Sitaram
^ permalink raw reply
* Re: Can't handle renamed resources on case insensitive filesystems.
From: Erik Faye-Lund @ 2009-12-14 15:42 UTC (permalink / raw)
To: Lhunath (Maarten B.); +Cc: Git Mailing List
In-Reply-To: <40aa078e0912140650t7e061da0nfc75955cb584f3ba@mail.gmail.com>
On Mon, Dec 14, 2009 at 3:50 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> On Mon, Dec 14, 2009 at 3:27 PM, Lhunath (Maarten B.) <lhunath@gmail.com> wrote:
>> GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.
>>
>> For instance:
>>
>> lhunath@Myst t $ git mv Foo foo
>> fatal: destination exists, source=Foo, destination=foo
>>
>> Moreover, when a repository contains Foo and foo in one commit and in a subsequent commit, "foo" is removed; "Foo" will also disappear when checking out the latter.
>>
>> Most of these issues are likely just a result of the underlying file system's handling of GIT's commands; though considering that Mac OS X's default fs is case insensitive by default, and the Mac and Windows userbases combined are quite large; it might be very much appropriate to do a check for this (if needed) and handle renames (and other operations?) in a way that they would not cause conflicts on these file systems (eg. rename to a temporary filename first and then rename to destination).
>>
>> In particular; these issues make it awfully painful to refactor Java class names from things like JndiUtils -> JNDIUtils. Not only is it hard to get the commit INTO the repository correctly; it is also hard to check the commit OUT for somebody who has no idea any of this is needed.--
>
> Actually, you have only discovered the tip of the iceberg that is git
> and case insensitivity. However, it is probably also the most annoying
> part of it. Changing git mv to skip moving (or moving in a way that
> works better) the file when core.ignorecase is enabled and the source
> and destination are the same when compared in a case insensitive
> fashion might make sense.
>
After doing a quick test, it seems no change are required for the git
mv case: use the -f flag when renaming to turn the error into a
warning. Of course, you should only do this when you know that you
really want to rename the file. The following worked for me:
$ git init
$ touch.exe test.txt
$ git add test.txt
$ git commit -m "initial commit"
[master (root-commit) 5acb06f] initial commit
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 test.txt
$ git mv test.txt Test.txt
fatal: destination exists, source=test.txt, destination=Test.txt
$ git mv test.txt Test.txt -f
Warning: destination exists; will overwrite!
$ ls
Test.txt
I've only tested this on Windows, but I guess it should work on OSX as well.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* git gc logs to standard error
From: Richard Rossel @ 2009-12-14 14:45 UTC (permalink / raw)
To: git
Hi,
I have a question related to the output of git gc logs. Let me explain,
I have a git commands in crontab (for redmine purpose) doing this stuff:
' git fetch -q origin && git reset -q --soft refs/remotes/origin/master '
for each project.
The problem is that am getting mail from crontab each time that somebody
do a push to the central server. Its really annoying. I try to avoid
those messages
redirecting the standard output with no results, then adding a quiet
option and no results.
This is the kind of mails that am receiving:
remote: Counting objects: 6, done.
remote: Compressing objects: 25% (1/4)
remote: Compressing objects: 50% (2/4)
remote: Compressing objects: 75% (3/4 )remote:
remote: Compressing objects: 100% (4/4)
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 2), reused 0 (delta 0)
From git@boss:drivings
0f35f06..5bc8866 master -> origin/master
Then I realized that the message is git gc logs looks like, so I did:
$ git gc
Counting objects: 51, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (35/35), done.
Writing objects: 100% (51/51), done.
Total 51 (delta 12), reused 51 (delta 12)
The message are pretty similar, so I sent the logs to dev/null but:
$ git gc >/dev/null
Counting objects: 51, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (35/35), done.
Writing objects: 100% (51/51), done.
Total 51 (delta 12), reused 51 (delta 12)
I realized that the message are sent to standard error,
so the question is why is the reason to do that?
The quick solution to my problem of annoying mails is send the output
error to /dev/null
but what happens when an error really occur, there will be no message to
alert me.
thanks for your help
saludos.-
--
Richard Rossel
Software Engineer at Airsage Inc.
Valparaiso - Chile
^ permalink raw reply
* Re: Can't handle renamed resources on case insensitive filesystems.
From: Tomas Carnecky @ 2009-12-14 14:52 UTC (permalink / raw)
To: Lhunath (Maarten B.); +Cc: Git Mailing List
In-Reply-To: <63135FDB-C8EF-4DBC-AEF5-4B0636C8D349@gmail.com>
On 12/14/09 3:27 PM, Lhunath (Maarten B.) wrote:
> GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.
>
> For instance:
>
> lhunath@Myst t $ git mv Foo foo
> fatal: destination exists, source=Foo, destination=foo
>
> Moreover, when a repository contains Foo and foo in one commit and in a subsequent commit, "foo" is removed; "Foo" will also disappear when checking out the latter.
>
> Most of these issues are likely just a result of the underlying file system's handling of GIT's commands; though considering that Mac OS X's default fs is case insensitive by default, and the Mac and Windows userbases combined are quite large; it might be very much appropriate to do a check for this (if needed) and handle renames (and other operations?) in a way that they would not cause conflicts on these file systems (eg. rename to a temporary filename first and then rename to destination).
>
> In particular; these issues make it awfully painful to refactor Java class names from things like JndiUtils -> JNDIUtils. Not only is it hard to get the commit INTO the repository correctly; it is also hard to check the commit OUT for somebody who has no idea any of this is needed.--
Create a disk image and format it with case-sensitive HFS+, create a new
partition and format it with case-sensitive HFS+, or reinstall Mac OS X
and choose case-sensitive HFS+ as the filesystem for the system partition.
After I found out that the default install of Mac OS X uses
case-insensitive filesystem, the first thing I did was reinstall the OS.
tom
^ permalink raw reply
* Re: Can't handle renamed resources on case insensitive filesystems.
From: Erik Faye-Lund @ 2009-12-14 14:50 UTC (permalink / raw)
To: Lhunath (Maarten B.); +Cc: Git Mailing List
In-Reply-To: <63135FDB-C8EF-4DBC-AEF5-4B0636C8D349@gmail.com>
On Mon, Dec 14, 2009 at 3:27 PM, Lhunath (Maarten B.) <lhunath@gmail.com> wrote:
> GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.
>
> For instance:
>
> lhunath@Myst t $ git mv Foo foo
> fatal: destination exists, source=Foo, destination=foo
>
> Moreover, when a repository contains Foo and foo in one commit and in a subsequent commit, "foo" is removed; "Foo" will also disappear when checking out the latter.
>
> Most of these issues are likely just a result of the underlying file system's handling of GIT's commands; though considering that Mac OS X's default fs is case insensitive by default, and the Mac and Windows userbases combined are quite large; it might be very much appropriate to do a check for this (if needed) and handle renames (and other operations?) in a way that they would not cause conflicts on these file systems (eg. rename to a temporary filename first and then rename to destination).
>
> In particular; these issues make it awfully painful to refactor Java class names from things like JndiUtils -> JNDIUtils. Not only is it hard to get the commit INTO the repository correctly; it is also hard to check the commit OUT for somebody who has no idea any of this is needed.--
Actually, you have only discovered the tip of the iceberg that is git
and case insensitivity. However, it is probably also the most annoying
part of it. Changing git mv to skip moving (or moving in a way that
works better) the file when core.ignorecase is enabled and the source
and destination are the same when compared in a case insensitive
fashion might make sense.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Can't handle renamed resources on case insensitive filesystems.
From: Lhunath (Maarten B.) @ 2009-12-14 14:27 UTC (permalink / raw)
To: Git Mailing List
GIT has quite a few issues concerning renamed files on case insensitive filesystems, such as Mac OS X's default HFS+.
For instance:
lhunath@Myst t $ git mv Foo foo
fatal: destination exists, source=Foo, destination=foo
Moreover, when a repository contains Foo and foo in one commit and in a subsequent commit, "foo" is removed; "Foo" will also disappear when checking out the latter.
Most of these issues are likely just a result of the underlying file system's handling of GIT's commands; though considering that Mac OS X's default fs is case insensitive by default, and the Mac and Windows userbases combined are quite large; it might be very much appropriate to do a check for this (if needed) and handle renames (and other operations?) in a way that they would not cause conflicts on these file systems (eg. rename to a temporary filename first and then rename to destination).
In particular; these issues make it awfully painful to refactor Java class names from things like JndiUtils -> JNDIUtils. Not only is it hard to get the commit INTO the repository correctly; it is also hard to check the commit OUT for somebody who has no idea any of this is needed.
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Johannes Schindelin @ 2009-12-14 14:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b0912140529w4a15418ewf304b9d6f4c1f007@mail.gmail.com>
Hi,
On Mon, 14 Dec 2009, Alex Riesen wrote:
> I don't use autocorrect myself apart from the testing. I assume Johannes
> doesn't, too
As a matter of fact, I do. But my common mistakes are not in forgetting
the subcommand, rather in mispelign them. So I never hit the problem.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Johannes Schindelin @ 2009-12-14 14:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List, Alex Riesen
In-Reply-To: <4B263797.5070808@viscovery.net>
Hi,
On Mon, 14 Dec 2009, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> If a given command is not found, then help.c tries to guess which one the
> user could have meant. If help.autocorrect is 0 or unset, then a list of
> suggestions is given as long as the dissimilarity between the given command
> and the candidates is not excessively high. But if help.autocorrect was
> non-zero (i.e., a delay after which the command is run automatically), the
> latter restriction on dissimilarity was not obeyed.
>
> In my case, this happened:
>
> $ git ..daab02
> WARNING: You called a Git command named '..daab02', which does not exist.
> Continuing under the assumption that you meant 'read-tree'
> in 4.0 seconds automatically...
>
> The similarity limit that this patch introduces is already used a few lines
> later where the list of suggested commands is printed.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
Obvious ACK from me.
^ 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