* [PATCH 2/9] add missing long options to 'git difftool' completion
From: Emmanuel Trillaud @ 2009-08-08 8:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
according to its man page, git-difftool has 3 long options :
--tools=, --no-prompt and --prompt. The last 2 options are missing.
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bc5427f..9e86d28 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -960,7 +960,7 @@ _git_difftool ()
return
;;
--*)
- __gitcomp "--tool="
+ __gitcomp "--tool= --no-prompt --prompt"
return
;;
esac
--
1.6.4
^ permalink raw reply related
* [PATCH 3/9] add missing long options to 'git mergetool' completion
From: Emmanuel Trillaud @ 2009-08-08 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
according to the git-mergetool man page, '--no-prompt' and '--prompt' are
missing from the 'git mergetool' completion
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 9e86d28..f56733b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1232,7 +1232,7 @@ _git_mergetool ()
return
;;
--*)
- __gitcomp "--tool="
+ __gitcomp "--tool= --no-prompt --prompt"
return
;;
esac
--
1.6.4
^ permalink raw reply related
* [PATCH 4/9] add missing long option to 'git grep' bash competion
From: Emmanuel Trillaud @ 2009-08-08 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
according to the 'git-grep' man page, the following long options are missing
from the 'git grep' bash completion :
--null
--color
--no-color
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index f56733b..a4e78d5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1057,7 +1057,9 @@ _git_grep ()
--extended-regexp --basic-regexp --fixed-strings
--files-with-matches --name-only
--files-without-match
+ --null
--count
+ --color --no-color
--and --or --not --all-match
"
return
--
1.6.4
^ permalink raw reply related
* [PATCH 5/9] add missing long options to 'git push bash completion'
From: Emmanuel Trillaud @ 2009-08-08 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
according to git-push(1), the following long-options are missing to the bash
completion :
--porcelain
--thin
--no-thin
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
contrib/completion/git-completion.bash | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index a4e78d5..98e1185 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1296,8 +1296,10 @@ _git_push ()
;;
--*)
__gitcomp "
- --all --mirror --tags --dry-run --force --verbose
+ --all --mirror --dry-run --porcelain --tags --force --verbose
--receive-pack= --repo=
+ --thin
+ --no-thin
"
return
;;
--
1.6.4
^ permalink raw reply related
* [PATCH 6/9] update 'git-rm' bash completion according to the man page
From: Emmanuel Trillaud @ 2009-08-08 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 98e1185..4746eee 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1828,7 +1828,7 @@ _git_rm ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
- __gitcomp "--cached --dry-run --ignore-unmatch --quiet"
+ __gitcomp "--force --cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
--
1.6.4
^ permalink raw reply related
* [PATCH 7/9] update 'git-show' bash completion to match the man page
From: Emmanuel Trillaud @ 2009-08-08 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Signed-off-by: Emmanuel Trillaud <etrillaud@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 4746eee..1e3efe3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1870,7 +1870,7 @@ _git_show ()
return
;;
--*)
- __gitcomp "--pretty= --format= --abbrev-commit --oneline
+ __gitcomp "--pretty= --format= --abbrev-commit --oneline --encoding
$__git_diff_common_options
"
return
--
1.6.4
^ permalink raw reply related
* [PATCH 8/9] update the 'git am' bash completion according to the man page
From: Emmanuel Trillaud @ 2009-08-08 8:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
---
contrib/completion/git-completion.bash | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 1e3efe3..8ba1249 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -675,7 +675,8 @@ _git_am ()
__gitcomp "
--3way --committer-date-is-author-date --ignore-date
--interactive --keep --no-utf8 --signoff --utf8
- --whitespace=
+ --whitespace= --directory=
+ --reject --quiet
"
return
esac
--
1.6.4
^ permalink raw reply related
* [PATCH 9/9] update 'git apply' bash-completion according to its man page
From: Emmanuel Trillaud @ 2009-08-08 8:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
---
contrib/completion/git-completion.bash | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 8ba1249..c08422c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -694,9 +694,15 @@ _git_apply ()
--*)
__gitcomp "
--stat --numstat --summary --check --index
- --cached --index-info --reverse --reject --unidiff-zero
- --apply --no-add --exclude=
+ --cached
+ --build-fake-ancestor=
+ --index-info --reverse --reject --unidiff-zero
+ --apply --no-add
+ --exclude=
+ --include=
--whitespace= --inaccurate-eof --verbose
+ --recount
+ --directory=
"
return
esac
--
1.6.4
^ permalink raw reply related
* [PATCH] git-pull: fix fetch-options.txt to not document --quiet and --verbose twice
From: Emmanuel Trillaud @ 2009-08-08 10:09 UTC (permalink / raw)
To: git
git-pull.txt includes fetch-options.txt and merge-options.txt which both
document the --quiet and --verbose parameters. So we supress the
--quiet and --verbose paragraphs if fetch-options.txt is included by
git-pull.txt
---
Documentation/fetch-options.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index d313795..525ce88 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,3 +1,6 @@
+//git-pull.txt includes merge-options.txt which documents --quiet and
+//--verbose
+ifndef::git-pull[]
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
@@ -6,6 +9,7 @@
-v::
--verbose::
Be verbose.
+endif::git-pull[]
-a::
--append::
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Erik Faye-Lund @ 2009-08-08 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ori Avtalion, git
In-Reply-To: <7v4osj1odt.fsf@alter.siamese.dyndns.org>
On Fri, Aug 7, 2009 at 8:15 PM, Junio C Hamano<gitster@pobox.com> wrote:
>> -'git-rev-list' is a very essential git program, since it
>> +'git-rev-list' is a very essential git command, since it
>> provides the ability to build and traverse commit ancestry graphs. For
>> this reason, it has a lot of different options that enables it to be
>> used by commands as different as 'git-bisect' and
>
> Ok, but probably we would want to say "git rev-list" here.
...or maybe just "rev-list", as we're now talking about a git-command
(and not how you invoke it)?
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: git gc expanding packed data?
From: Hin-Tak Leung @ 2009-08-08 13:05 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Nicolas Pitre, git
In-Reply-To: <m2tz0j154o.fsf@igel.home>
On Sat, Aug 8, 2009 at 2:11 AM, Andreas Schwab<schwab@linux-m68k.org> wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
>> It appears that the git installation serving clone requests for
>> git://gcc.gnu.org/git/gcc.git generates lots of unreferenced objects. I
>> just cloned it and the pack I was sent contains 1383356 objects (can be
>> determined with 'git show-index < .git/objects/pack/*.idx | wc -l').
>> However, there are only 978501 actually referenced objects in that
>> cloned repository ( 'git rev-list --all --objects | wc -l'). That makes
>> for 404855 useless objects in the cloned repository.
>
> Those objects are not useless. They are referenced by the remote refs
> on the remote side, which are not fetched by default. If you clone a
> mirror of the repository you'll see no unreferenced objects.
>
> 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."
>
Thanks... It is a difference between svn and git mentality probably -
one only pushes reasonably reliable code to a public git repository,
whereas anything transient is recorded in svn - I think many of the
unreferenced objects are svn user-branches (which are probably of use
to people who intend to work on gcc for fairly extended periods,
rather than casual users like me).
The case with gcc is probably quite extreme - many user branches, and
very large code base - but is there anything on the git side with git
gc which can lessen this kind of pathological behavior (expanding
packs)?
Thanks a lot for the explanation and the discussion.
Hin-Tak
^ permalink raw reply
* Re: git gc expanding packed data?
From: Andreas Schwab @ 2009-08-08 13:25 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Nicolas Pitre, git
In-Reply-To: <3ace41890908080605k4ec6661bmcb4c87e10bc5fd87@mail.gmail.com>
Hin-Tak Leung <hintak.leung@gmail.com> writes:
> Thanks... It is a difference between svn and git mentality probably -
It is just that the remote is a git-svn tree, with only a few branches
created as local branches.
> The case with gcc is probably quite extreme - many user branches, and
> very large code base - but is there anything on the git side with git
> gc which can lessen this kind of pathological behavior (expanding
> packs)?
If you fetch all refs, not only refs/heads/*, all objects will be
referenced.
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: [PATCH] Change mentions of "git programs" to "git commands"
From: Ori Avtalion @ 2009-08-08 13:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4osj1odt.fsf@alter.siamese.dyndns.org>
On 08/07/2009 09:15 PM, Junio C Hamano wrote:
> Ori Avtalion<ori@avtalion.name> writes:
>
>> Most of the docs and printouts refer to "commands".
>> This patch changes the other terminology to be consistent.
>
> Thanks, but not really.
>
>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
>> index d313795..20bf512 100644
>> --- a/Documentation/fetch-options.txt
>> +++ b/Documentation/fetch-options.txt
>> @@ -1,7 +1,7 @@
>> -q::
>> --quiet::
>> Pass --quiet to git-fetch-pack and silence any other internally
>> - used programs.
>> + used utilities.
>
> This does not have much to do with what you claim to have done in the
> commit log message nor the title. Probably "utilities" is a slightly
> better word than "programs" in this context but not by a wide margin.
>
I picked the word from the glossary definition of "core git":
"Fundamental data structures and utilities of git. [...]"
If that doesn't fit, how about:
"Pass --quiet to git-fetch-pack and silence other output" ?
>> -'git-rev-list' is a very essential git program, since it
>> +'git-rev-list' is a very essential git command, since it
>> provides the ability to build and traverse commit ancestry graphs. For
>> this reason, it has a lot of different options that enables it to be
>> used by commands as different as 'git-bisect' and
>
> Ok, but probably we would want to say "git rev-list" here.
In that case, shouldn't all of the manpages be changed to say "git foo"
instead of "git-foo" under the NAME section?
I see the "git-foo" notation as a convention for git commands.
It may be for historical reasons, but the manpage for the "pull" git
command is "git-pull", and that is how commands are mentioned all over
the documentation.
>
>> --exec-path::
>> - Path to wherever your core git programs are installed.
>> + Path to wherever your core git commands are installed.
>
> I do not think this is a good change.
>
> When you talk about git "command", e.g. "'git rev-list' is an essential
> command", you are talking about an abstract concept. In the reader's
> world view, there is one single toplevel program called "git" and it has
> various commands, one of which is 'rev-list'. But this description is not
> about an abstract concept of command, but is about a particular
> implementation detail. For every git command, there is a corresponding
> git _program_ that implements that command, and --exec-path tells you (or
> you use --exec-path to tell the git toplevel program) where they are.
>
> You kept this intact in gitcore-tutorial:
>
> ... Also
> you need to make sure that you have the 'git-receive-pack'
> program on the `$PATH`.
>
> and I think you did the right thing. This is about a concrete instance of
> a program. If you really really want to say _command_, you would probably
> want to do something like this instead:
>
> --exec-path::
> - Path to wherever your core git programs are installed.
> + Path to the directory that holds programs that implements git commands.
>
I agree with the suggestion.
I found a few other instances that should probably be changed.
In git.txt:
"The following are helper programs used by the above"
^^^^^^^^
commands
In git-mailsplit.txt (and cmds-purehelpers.txt):
"Simple UNIX mbox splitter program."
Maybe the word "program" should just be dropped.
I'll submit a new patch once there's an agreement on the changes.
-Ori
^ permalink raw reply
* [PATCH] gitk: parse arbitrary commit-ish in SHA1 field
From: Thomas Rast @ 2009-08-08 14:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
We only accepted either SHA1s or heads/tags that have been read. This
meant the user could not, e.g., enter HEAD to go back to the current
commit.
Add code to call out to git-rev-parse with the string entered if all
other methods of interpreting it failed. The error paths change
slighly, because we now know from the rev-parse invocation whether the
expression was valid at all. The previous "unknown" path is now only
triggered if the revision does exist, but is not in the current view
display.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Of course, *ideally* we'd resort to *changing* the current view so
that it also lists the requested commit. But my Tk-fu is currently
not up to that task.
gitk | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 4604c83..4b27886 100755
--- a/gitk
+++ b/gitk
@@ -7906,6 +7906,11 @@ proc gotocommit {} {
}
set id [lindex $matches 0]
}
+ } else {
+ if {[catch {set id [exec git rev-parse $sha1string]}]} {
+ error_popup [mc "Revision %s is not known" $sha1string]
+ return
+ }
}
}
if {[commitinview $id $curview]} {
@@ -7915,7 +7920,7 @@ proc gotocommit {} {
if {[regexp {^[0-9a-fA-F]{4,}$} $sha1string]} {
set msg [mc "SHA1 id %s is not known" $sha1string]
} else {
- set msg [mc "Tag/Head %s is not known" $sha1string]
+ set msg [mc "Revision %s is not in the current view" $sha1string]
}
error_popup $msg
}
--
1.6.4.199.g24c3
^ permalink raw reply related
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Johannes Schindelin @ 2009-08-08 15:18 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sam Vilain, Nick Edelen, Michael J Gruber, Junio C Hamano,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.LFD.2.00.0908071010580.16073@xanadu.home>
Hi,
On Fri, 7 Aug 2009, Nicolas Pitre wrote:
> On Fri, 7 Aug 2009, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Fri, 7 Aug 2009, Nicolas Pitre wrote:
> >
> > > On Fri, 7 Aug 2009, Sam Vilain wrote:
> > >
> > > > Johannes Schindelin wrote:
> > > > >> the short answer is that cache slices are totally independant of
> > > > >> pack files.
> > > > >>
> > > > >
> > > > > My idea with that was that you already have a SHA-1 map in the pack
> > > > > index, and if all you want to be able to accelerate the revision
> > > > > walker, you'd probably need something that adds yet another mapping,
> > > > > from commit to parents and tree, and from tree to sub-tree and blob
> > > > > (so you can avoid unpacking commit and tree objects).
> > > > >
> > > >
> > > > Tying indexes together like that is not a good idea in the database
> > > > world. Especially as in this case as Nick mentions, the domain is
> > > > subtly different (ie pack vs dag). Unfortunately you just can't try to
> > > > pretend that they will always be the same; you can't force a full
> > > > repack on every ref change!
> > >
> > > Right. And the rev cache must work even if the repository is not
> > > packed.
> >
> > Umm, why? AFAICT the principal purpose of the rev cache is to help work
> > loads on, say, www.kernel.org.
>
> So what?
>
> Speeding up rev-list with a rev cache is completely orthogonal to
> whether the repository is packed or not.
No, it is not.
For both technical and practical reasons, caching revision walker data is
very closely related to packing.
You are _very_ unlikely helped by speeding up revision walking in the
general case, _especially_ when you do stuff like blame or -S that needs
to unpack tons of objects _anyway_.
The one big kicker argument for speeding up revision walking _is_ to
relieve the loads on big ass servers, and they _should_ be as packed as
possible (as I will patiently explain over and over again).
> It is like having a "git diff" result cache: no one would think of
> stuffing that in the pack index.
Do you want to try to kid me? You'll have to try harder. Caching "git
diff" results... no, really!
> If we want to improve on the repository packing format, that must be
> doable without bothering with an independent concept such as a rev
> cache.
I would love to tell you that you're right, but the single fact that
pack v4 is startig to compete with Duke Nukem Forever just prevents me
from doing that.
> > I am unlikely to notice the improvements in my regular "git log" calls
> > that only show a couple of pages before I quit the pager.
>
> Indeed. But what is your point again?
Oh? My point? Being that the rev cache has a certain target audience,
and that the regular user is not part of that audience, and that it just
so happens that the _technical_ similarities with the pack index can be
exploited in those scenarios?
IOW we can be pretty certain that a heavy-load server has a fully (or
next-to-fully) packed object database. The pack indices already contain a
SHA-1 table that we can simply reuse. And it should not be hard (or
fragile) at all to put the "cached" information about parents,
referenced tree and blob objects into that file, into a different section.
After all, the parents, referenced tree and blob objects to change as
often as the objects in the pack: never.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Matthieu Moy @ 2009-08-08 15:22 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git, gitster
In-Reply-To: <87prb6r9d1.fsf@iki.fi>
Teemu Likonen <tlikonen@iki.fi> writes:
> On 2009-08-08 09:51 (+0200), Matthieu Moy wrote:
>> 'git push' failing because of non-fast forward is a very common situation,
>> and a beginner does not necessarily understand "fast forward" immediately.
>
>> + if (nonfastforward) {
>> + printf("Push was rejected because it would not result in a fast forward:\n"
>> + "Merge in the remote changes (using git pull) before pushing yours,\n"
>> + "or use git push --force to discard the remote changes.\n"
>> + "See 'non-fast forward' section of 'git push --help' for details.\n");
>> + }
>
> I'd like to add that some projects that use Git in (partially)
> centralized manner prefer "git pull --rebase" before "git push".
Right, but I don't think this error message is the place to discuss
that. Anything involving rebasing should be taken with care, and
pointing the user to it in a short sentence sounds like "try shooting
yourself in the foot, and read the man page if it hurts" ;-).
--
Matthieu
^ permalink raw reply
* git failing to create new branches, depending on the name
From: Artur Skawina @ 2009-08-08 15:32 UTC (permalink / raw)
To: Git Mailing List
One of my build scripts, which takes a 'work' git tree, clones it to
make a build tree, then creates an unique branch there and goes on
to do the rest of the work, started mysteriously failing recently
.
Turns out git doesn't like the branch names that my script is
choosing and git-checkout fails with a misleading fatal error.
I don't remember changing the script recently and it used to work
for months, something must have changed.
This is what i did while trying to find why the checkout is failing:
+ git --version
git version 1.6.4
+ rm -rf /tmp/build-tree
+ git clone -l -s -n -o askern --reference /tmp/work-tree /tmp/work-tree /tmp/build-tree
Initialized empty Git repository in /tmp/build-tree/.git/
+ cd /tmp/build-tree
+ git branch -a | grep g90bc1a6
+ git checkout -f -b branch-g90bc1a6 askern/release
fatal: git checkout: branch branch-g90bc1a6 already exists
# WTF?
+ (
+ cd /tmp/work-tree
+ git branch -a | grep g90bc1a6
+ )
# nothing in parent repo either.
+ git checkout -f branch-g90bc1a6
Checking out files: 100% (29109/29109), done.
Note: moving to 'branch-g90bc1a6' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 90bc1a6... Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
# so where is coming from?
+ git branch -a | grep g90bc1a6
+ git status
# Not currently on any branch.
nothing to commit (working directory clean)
+ git show --pretty=short 90bc1a6 | cat
commit 90bc1a658a53f8832ee799685703977a450e5af9
Merge: 6ce90c4 54822de
Author: Linus Torvalds <torvalds@linux-foundation.org>
Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus
# Aha
So what appears to be happening is that the script picks up the
90bc1a6 suffix (it gets it from git-describe), uses it as part
of the branch name and then git misinterprets it.
(the actual names used by the script are much longer, i used
"branch-g90bc1a6" only to figure what was going on)
artur
^ permalink raw reply
* Re: [PATCH 0/5] Suggested for PU: revision caching system to significantly speed up packing/walking
From: Junio C Hamano @ 2009-08-08 16:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicolas Pitre, Sam Vilain, Nick Edelen, Michael J Gruber,
Jeff King, Shawn O. Pearce, Andreas Ericsson, Christian Couder,
git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0908081709380.8306@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> It is like having a "git diff" result cache: no one would think of
>> stuffing that in the pack index.
>
> Do you want to try to kid me? You'll have to try harder. Caching "git
> diff" results... no, really!
I thought Nico meant caching the rename similarity matrix when he said
"git diff" cache. In a narrow context of "log --follow" it may make
sense. It also might help "blame" without -C.
But I do not see how we would gain anything if we had that cache tied to
the pack index.
> After all, the parents, referenced tree and blob objects to change as
> often as the objects in the pack: never.
But I notice that the aspects of objects you listed: the parents,
referenced tree and blob objects. The frequency of them changing does not
depend on where the actual object is, either packed or loose. These
aspects of an object (more specifically, you are talking about a commit
object) never change either way. So I am somewhat puzzled.
It does change if a particular commit and its associated objects are
relevant to the traversal as refs change (especially when they rewind).
Just like an old "kept" pack can suddenly have tons of irrelevant objects
after refs are pruned (e.g. a branch is dropped), cached reachability
data, even though they may stay correct, would become irrelevant when
nobody starts traversing from an object that is no longer reachable.
^ permalink raw reply
* Re: [PATCH] Change mentions of "git programs" to "git commands"
From: Junio C Hamano @ 2009-08-08 16:12 UTC (permalink / raw)
To: Ori Avtalion; +Cc: git
In-Reply-To: <4A7D7CF2.40902@avtalion.name>
Ori Avtalion <ori@avtalion.name> writes:
> On 08/07/2009 09:15 PM, Junio C Hamano wrote:
>> Ori Avtalion<ori@avtalion.name> writes:
>>
>>> Most of the docs and printouts refer to "commands".
>>> This patch changes the other terminology to be consistent.
>>
>> Thanks, but not really.
>>
>>> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
>>> index d313795..20bf512 100644
>>> --- a/Documentation/fetch-options.txt
>>> +++ b/Documentation/fetch-options.txt
>>> @@ -1,7 +1,7 @@
>>> -q::
>>> --quiet::
>>> Pass --quiet to git-fetch-pack and silence any other internally
>>> - used programs.
>>> + used utilities.
>>
>> This does not have much to do with what you claim to have done in the
>> commit log message nor the title. Probably "utilities" is a slightly
>> better word than "programs" in this context but not by a wide margin.
>
> If that doesn't fit,...
My comment on this part was not "Don't change this wording, the original
is much better", but was primarily "you said this commit is about
replacing 'program' with 'command' for consistency, but this change does
not belong to that category. Either make a separate commit for this
change separate from all the rest, or change the wording of the commit log
message to cover this one as well".
> "Pass --quiet to git-fetch-pack and silence other output" ?
>
>>> -'git-rev-list' is a very essential git program, since it
>>> +'git-rev-list' is a very essential git command, since it
>>> provides the ability to build and traverse commit ancestry graphs. For
>>> this reason, it has a lot of different options that enables it to be
>>> used by commands as different as 'git-bisect' and
>>
>> Ok, but probably we would want to say "git rev-list" here.
> ...
> I see the "git-foo" notation as a convention for git commands.
> It may be for historical reasons, but the manpage for the "pull" git
> command is "git-pull", and that is how commands are mentioned all over
> the documentation.
This was "because you are changing the exact sentence anyway, why not do
this while you are at it". But you are probably right. We try to write
"git foo" when we talk about what users would type, but say "git-foo" when
we talk about the command itself. When we talk about the concept of what
the command achieves, we sometimes say just "foo".
> In git.txt:
> "The following are helper programs used by the above"
> ^^^^^^^^
> commands
>
> In git-mailsplit.txt (and cmds-purehelpers.txt):
> "Simple UNIX mbox splitter program."
>
> Maybe the word "program" should just be dropped.
That may be an option and I kind of like it; but I'd rather hear from
others first.
^ permalink raw reply
* Re: Problem compiling git-1.6.4 on OpenServer 6.0
From: Boyd Lynn Gerber @ 2009-08-08 16:14 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git List
In-Reply-To: <DHem56NUSFhg2VqQu1N0qVr3U86qJOp4OZZAEwV2Edz0-YuWJpDtgA@cipher.nrlssc.navy.mil>
On Fri, 7 Aug 2009, Brandon Casey wrote:
> Boyd Lynn Gerber wrote:
>> On Fri, 7 Aug 2009, Brandon Casey wrote:
>>> Boyd Lynn Gerber wrote:
>>>> I just tried to compile the latest git and I get this error.
>>>>
>>>> CC builtin-pack-objects.o
>>>> UX:acomp: ERROR: "builtin-pack-objects.c", line 1602: integral constant
>>>> expression expected
>>>> gmake: *** [builtin-pack-objects.o] Error 1
>>>>
>>>> I will look into it when I have a bit more time, but this is a heads up.
>>>
>>> Did you set THREADED_DELTA_SEARCH=1 when you compiled? That could be the
>>> problem.
>>>
>>> Line 1602 of builtin-pack-objects.c is wrapped in #ifdef
>>> THREADED_DELTA_SEARCH,
>>> so it is only compiled if THREADED_DELTA_SEARCH has been set. Also,
>>> it's not
>>> a new line, it has been around since 2007.
>>
>> Removing it and the -pthread allows it to build. I am now running the
>> tests. The I need to find out why it is being set.
>
> Did you run configure? which generates a config.mak.autogen file?
> There were some changes related to pthreads in configure.ac in March,
> and another back in Nov 2008. Specifically commits 1973b0d7, and
> d937c374.
Yes, I am working through them and will submit a patch once I get it
working properly without breaking someone elses configuration.
Thanks,
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Failing a test on OpenServer 6 t5100-mailinfo.sh
From: Boyd Lynn Gerber @ 2009-08-08 16:17 UTC (permalink / raw)
To: Git List
Hello,
With a config.mak.autogen that is fixed for OpenServer 6.
I now have three tests that fail.
The first is because of the OS does not allow perl to do somethings.
The second is a new problem.
*** t5100-mailinfo.sh ***
* ok 1: split sample box
* ok 2: mailinfo 0001
* ok 3: mailinfo 0002
* ok 4: mailinfo 0003
* ok 5: mailinfo 0004
* ok 6: mailinfo 0005
* ok 7: mailinfo 0006
* ok 8: mailinfo 0007
* ok 9: mailinfo 0008
* ok 10: mailinfo 0009
* ok 11: mailinfo 0010
* FAIL 12: mailinfo 0011
git mailinfo -u msg$mail patch$mail <$mail
>info$mail &&
echo msg &&
test_cmp "$TEST_DIRECTORY"/t5100/msg$mail msg$mail
&&
echo patch &&
test_cmp "$TEST_DIRECTORY"/t5100/patch$mail
patch$mail &&
echo info &&
test_cmp "$TEST_DIRECTORY"/t5100/info$mail
info$mail
* ok 13: mailinfo 0012
* ok 14: mailinfo 0013
* ok 15: split box with rfc2047 samples
* FAIL 16: mailinfo rfc2047/0001
git mailinfo -u $mail-msg $mail-patch <$mail
>$mail-info &&
echo msg &&
test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-msg
&&
echo patch &&
test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-patch
&&
echo info &&
test_cmp
"$TEST_DIRECTORY"/t5100/rfc2047-info-$(basename $mail) $mail-info
* ok 17: mailinfo rfc2047/0002
* ok 18: mailinfo rfc2047/0003
* FAIL 19: mailinfo rfc2047/0004
git mailinfo -u $mail-msg $mail-patch <$mail
>$mail-info &&
echo msg &&
test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-msg
&&
echo patch &&
test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-patch
&&
echo info &&
test_cmp
"$TEST_DIRECTORY"/t5100/rfc2047-info-$(basename $mail) $mail-info
* ok 20: mailinfo rfc2047/0005
* ok 21: mailinfo rfc2047/0006
* ok 22: mailinfo rfc2047/0007
* ok 23: mailinfo rfc2047/0008
* ok 24: mailinfo rfc2047/0009
* ok 25: mailinfo rfc2047/0010
* FAIL 26: mailinfo rfc2047/0011
git mailinfo -u $mail-msg $mail-patch <$mail
>$mail-info &&
echo msg &&
test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-msg
&&
echo patch &&
test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-patch
&&
echo info &&
test_cmp
"$TEST_DIRECTORY"/t5100/rfc2047-info-$(basename $mail) $mail-info
* ok 27: respect NULs
* ok 28: Preserve NULs out of MIME encoded message
* ok 29: mailinfo on from header without name works
* failed 4 among 29 test(s)
gmake[2]: *** [t5100-mailinfo.sh] Error 1
gmake[2]: Leaving directory `/home/zenez/build/osr6/git/t'
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [PATCH v2] push: point to 'git pull' and 'git push --force' in case of non-fast forward
From: Junio C Hamano @ 2009-08-08 16:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Teemu Likonen, git
In-Reply-To: <vpqab2aqqia.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Teemu Likonen <tlikonen@iki.fi> writes:
>
>> On 2009-08-08 09:51 (+0200), Matthieu Moy wrote:
>>> 'git push' failing because of non-fast forward is a very common situation,
>>> and a beginner does not necessarily understand "fast forward" immediately.
>>
>>> + if (nonfastforward) {
>>> + printf("Push was rejected because it would not result in a fast forward:\n"
>>> + "Merge in the remote changes (using git pull) before pushing yours,\n"
>>> + "or use git push --force to discard the remote changes.\n"
>>> + "See 'non-fast forward' section of 'git push --help' for details.\n");
>>> + }
>>
>> I'd like to add that some projects that use Git in (partially)
>> centralized manner prefer "git pull --rebase" before "git push".
>
> Right, but I don't think this error message is the place to discuss
> that. Anything involving rebasing should be taken with care, and
> pointing the user to it in a short sentence sounds like "try shooting
> yourself in the foot, and read the man page if it hurts" ;-).
Instead of saying "Merge in", we could say "Integrate" to cover both
practices. I also happen to think that the mention of --force falls into
the same category as "try shooting and then study if it hurgs".
So how about phrasing it like this?
Non-fast forward pushes were rejected because you would discard remote
changes you have not seen. Integrate them with your changes and then
push again. See 'non-fast forward' section of 'git push --help'.
I think you can throw in a discussion on --force to the manual page, too.
^ permalink raw reply
* [RFC PATCH] Simplify away duplicate commits with --cherry-pick --parents
From: Thomas Rast @ 2009-08-08 16:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Björn Steinbrink, Adam Simpkins
In-Reply-To: <200908060919.27780.trast@student.ethz.ch>
The current --cherry-pick declares commits SHOWN that are found to be
duplicates. Unfortunately this disconnects the history at every such
duplicate, making it quite hard to follow in graphical viewers.
Add an extra stage of parent rewriting after scanning for duplicates,
which simplifies the history to omit all duplicate commits. This
cannot easily be shifted to the existing parent rewriting because
cherry_pick_list() always comes last in the entire filtering process
(presumably because it is the most expensive).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I wrote:
> The problem with [gitk --left-right --cherry-pick A...B] is that it
> disconnects history
[...]
> Sadly, it's really the underlying git-rev-list that is "broken" in the
> sense that it does not fix the parent lists. And git log --graph
> handles it much worse than gitk.
Maybe this is an approach. It unfortunately breaks down if merges can
disappear because of patch-ids too. Can they?
(In the case where a merge is flagged SHOWN, it might have its parent
list reduced to one at some point, and then later filterings would
simplify it away whereas earlier ones didn't.)
Also, I'm not entirely sure we want to do this without any guards
except rewrite_parents.
On the plus side, the issues with git log --graph vanish because
history is again connected :-)
revision.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 9f5dac5..9e24514 100644
--- a/revision.c
+++ b/revision.c
@@ -517,6 +517,8 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
return 0;
}
+static int remove_duplicate_parents(struct commit *commit);
+
static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)
{
struct commit_list *p;
@@ -599,6 +601,25 @@ static void cherry_pick_list(struct commit_list *list, struct rev_info *revs)
commit->util = NULL;
}
+ if (revs->rewrite_parents) {
+ /* Prune away commits we've just found to be duplicates */
+ for (p = list; p; p = p->next) {
+ struct commit *commit = p->item;
+ struct commit_list *pp;
+
+ for (pp = commit->parents; pp; pp = pp->next) {
+ struct commit *parent = pp->item;
+ while (parent->object.flags & SHOWN
+ && parent->parents
+ && !parent->parents->next)
+ parent = parent->parents->item;
+ pp->item = parent;
+ }
+
+ remove_duplicate_parents(commit);
+ }
+ }
+
free_patch_ids(&ids);
}
--
1.6.4.199.g24c3
^ permalink raw reply related
* [PATCH] gitweb: squelch harmless variable scoping errors
From: Mark A Rada @ 2009-08-08 16:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
I fiddled around a bit and this solution seems to work, but is a bit
odd, as
the method is declared obsolete in the Perl documentation (v5.8.8).
What do you think?
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
--->8---
This will use the 'vars' method of declaring global variables instead
of the 'our' method.
Though 'vars' has been obsoleted, it has the advantage of pre-declaring
global symbols; this ensures that those symbols will be available to
routines loaded later, whereas 'our' does not seem to do this.
The result is that when using mod_perl you will no longer get any
warnings printed to your error_log.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
gitweb/gitweb.perl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 37120a3..0544aa2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -57,12 +57,14 @@ if ($path_info) {
our $GIT = "++GIT_BINDIR++/git";
# absolute fs-path which will be prepended to the project path
-#our $projectroot = "/pub/scm";
-our $projectroot = "++GITWEB_PROJECTROOT++";
+use vars qw($projectroot);
+#$projectroot = "/pub/scm";
+$projectroot = "++GITWEB_PROJECTROOT++";
# fs traversing limit for getting project list
# the number is relative to the projectroot
-our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
+use vars qw($project_maxdepth);
+$project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
# target of the home link on top of all pages
our $home_link = $my_uri || "/";
--
1.6.4
^ permalink raw reply related
* Re: git failing to create new branches, depending on the name
From: Thomas Rast @ 2009-08-08 17:04 UTC (permalink / raw)
To: Artur Skawina; +Cc: Git Mailing List, Daniel Barkalow
In-Reply-To: <4A7D9AA7.1030709@gmail.com>
Artur Skawina wrote:
> + git checkout -f -b branch-g90bc1a6 askern/release
> fatal: git checkout: branch branch-g90bc1a6 already exists
This bisects to
commit 352eadc40024b141e1295693654ec20cc123844f
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Sun Sep 21 14:36:06 2008 -0400
Check early that a new branch is new and valid
If you fail to update refs to change branches in checkout, your index
and working tree are left already updated. We don't have an easy way
to undo this, but at least we can check things that would make the
creation of a new branch fail. These checks were in the shell version,
and were lost in the C conversion.
The messages are from the shell version, and should probably be made nicer.
[jc: added test to t7201]
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not sure this is a bug though. If we allow branch names that are
ambiguous to rev-parse, what do they resolve to? E.g., in the
presence of only 'master', 'master-g01234567' is defined to be the
same as 01234567. What is it if you also have a *branch* called
'master-g01234567'?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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