* Re: Dangling blob after git gc
From: Miklos Vajna @ 2008-11-27 13:53 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqzljlnuwo.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
On Thu, Nov 27, 2008 at 02:46:47PM +0100, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> from man git-gc:
>
> The optional configuration variable gc.pruneExpire controls
> how old the unreferenced loose objects have to be before
> they are pruned. The default is "2 weeks ago".
>
> Git can hardly know for sure whether a dangling object is actually a
> temporary object used by another instance of git or actually an unused
> object. Older versions of Git required you to explicitely say --prune
> to mean "OK, _I_ am sure, you can prune the objects", newer do it the
> safe way by removing only objects old enough.
So it was a user error, thanks for pointing out the relevant
documentation. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Dangling blob after git gc
From: Matthieu Moy @ 2008-11-27 13:46 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20081127133027.GW4746@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> The commits are probably due to reflogs, that's OK. But why do I have a
> dangling blob after git gc? The interesting part is that as you can see
> most of them is removed, but not all.
>
> Any ideas? :)
from man git-gc:
The optional configuration variable gc.pruneExpire controls
how old the unreferenced loose objects have to be before
they are pruned. The default is "2 weeks ago".
Git can hardly know for sure whether a dangling object is actually a
temporary object used by another instance of git or actually an unused
object. Older versions of Git required you to explicitely say --prune
to mean "OK, _I_ am sure, you can prune the objects", newer do it the
safe way by removing only objects old enough.
--
Matthieu
^ permalink raw reply
* [PATCH] bash: offer refs instead of filenames for 'git revert'
From: SZEDER Gábor @ 2008-11-27 13:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
The completion script for 'git revert' currently offers options and
filenames. However, 'git revert' doesn't take any filenames from the
command line, but a single commit. Therefore, it's more sane to offer
refs instead.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
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 39bf18b..7e668d5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1348,7 +1348,7 @@ _git_revert ()
return
;;
esac
- COMPREPLY=()
+ __gitcomp "$(__git_refs)"
}
_git_rm ()
--
1.6.0.4.814.gfe502
^ permalink raw reply related
* [PATCH] bash: complete full refs
From: SZEDER Gábor @ 2008-11-27 13:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Sometimes it's handy to complete full refs, e.g. the user has some
refs outside of refs/{heads,remotes,tags} or the user wants to
complete some git command's special refs (like 'git show
refs/bisect/bad').
To do that, we check whether the ref to be completed starts with
'refs'. If it does, then we offer full refs for completion; otherwise
everything works as usual.
This way the impact on the common case is fairly small (hopefully not
many users have branches or tags starting with 'refs'), and in the
special case the cost of typing out 'refs' is bearable.
While at it, also remove the unused 'cmd' variable from '__git_refs'.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0ee071b..39bf18b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -188,11 +188,22 @@ __git_tags ()
__git_refs ()
{
- local cmd i is_hash=y dir="$(__gitdir "$1")"
+ local i is_hash=y dir="$(__gitdir "$1")"
+ local cur="${COMP_WORDS[COMP_CWORD]}" format refs
if [ -d "$dir" ]; then
- if [ -e "$dir/HEAD" ]; then echo HEAD; fi
- git --git-dir="$dir" for-each-ref --format='%(refname:short)' \
- refs/tags refs/heads refs/remotes
+ case "$cur" in
+ refs*)
+ format="refname"
+ refs="${cur%/*}"
+ ;;
+ *)
+ if [ -e "$dir/HEAD" ]; then echo HEAD; fi
+ format="refname:short"
+ refs="refs/tags refs/heads refs/remotes"
+ ;;
+ esac
+ git --git-dir="$dir" for-each-ref --format="%($format)" \
+ $refs
return
fi
for i in $(git ls-remote "$dir" 2>/dev/null); do
--
1.6.0.4.814.gfe502
^ permalink raw reply related
* [PATCH] bash: remove dashed command leftovers
From: SZEDER Gábor @ 2008-11-27 13:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Commit 5a625b07 (bash: remove fetch, push, pull dashed form leftovers,
2008-10-03) did that already, but there were still some git-cmd left
here and there.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 41 ++++++-------------------------
1 files changed, 8 insertions(+), 33 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 35e8ff7..0ee071b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -635,21 +635,12 @@ _git_branch ()
_git_bundle ()
{
- local mycword="$COMP_CWORD"
- case "${COMP_WORDS[0]}" in
- git)
- local cmd="${COMP_WORDS[2]}"
- mycword="$((mycword-1))"
- ;;
- git-bundle*)
- local cmd="${COMP_WORDS[1]}"
- ;;
- esac
- case "$mycword" in
- 1)
+ local cmd="${COMP_WORDS[2]}"
+ case "$COMP_CWORD" in
+ 2)
__gitcomp "create list-heads verify unbundle"
;;
- 2)
+ 3)
# looking for a file
;;
*)
@@ -797,12 +788,7 @@ _git_fetch ()
__gitcomp "$(__git_refs)" "$pfx" "${cur#*:}"
;;
*)
- local remote
- case "${COMP_WORDS[0]}" in
- git-fetch) remote="${COMP_WORDS[1]}" ;;
- git) remote="${COMP_WORDS[2]}" ;;
- esac
- __gitcomp "$(__git_refs2 "$remote")"
+ __gitcomp "$(__git_refs2 "${COMP_WORDS[2]}")"
;;
esac
fi
@@ -1049,12 +1035,7 @@ _git_pull ()
if [ "$COMP_CWORD" = 2 ]; then
__gitcomp "$(__git_remotes)"
else
- local remote
- case "${COMP_WORDS[0]}" in
- git-pull) remote="${COMP_WORDS[1]}" ;;
- git) remote="${COMP_WORDS[2]}" ;;
- esac
- __gitcomp "$(__git_refs "$remote")"
+ __gitcomp "$(__git_refs "${COMP_WORDS[2]}")"
fi
}
@@ -1067,19 +1048,13 @@ _git_push ()
else
case "$cur" in
*:*)
- local remote
- case "${COMP_WORDS[0]}" in
- git-push) remote="${COMP_WORDS[1]}" ;;
- git) remote="${COMP_WORDS[2]}" ;;
- esac
-
local pfx=""
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) pfx="${cur%%:*}:" ;;
esac
- __gitcomp "$(__git_refs "$remote")" "$pfx" "${cur#*:}"
+ __gitcomp "$(__git_refs "${COMP_WORDS[2]}")" "$pfx" "${cur#*:}"
;;
+*)
__gitcomp "$(__git_refs)" + "${cur#+}"
@@ -1584,7 +1559,7 @@ _git_tag ()
-m|-F)
COMPREPLY=()
;;
- -*|tag|git-tag)
+ -*|tag)
if [ $f = 1 ]; then
__gitcomp "$(__git_tags)"
else
--
1.6.0.4.814.gfe502
^ permalink raw reply related
* Dangling blob after git gc
From: Miklos Vajna @ 2008-11-27 13:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 976 bytes --]
Hi,
$ git version
git version 1.6.0.4
$ git fsck
dangling blob 070011dddba40fe0066cbebfe51ea6d160f95af8
dangling blob 3ec00c535bbac37f738971a5ad14bb11892c5863
dangling commit c180face4d2451f9e77f41d4f9d4f3ad7cbd51c0
(...)
So I have multiple dangling blobs/trees/commits, let's do a gc.
$ git gc
Counting objects: 96978, done.
Compressing objects: 100% (25044/25044), done.
Writing objects: 100% (96978/96978), done.
Total 96978 (delta 70392), reused 96978 (delta 70392)
$ git fsck
dangling commit 2302e3fd37e808d3240ffa887ea1c22cac9cb770
dangling commit 0a2bc7013d49e0695242ffc2d57360d0396c22ea
dangling blob c330f89bcc20b1c9ca689e66062d086562e0633d
dangling commit ac319ab8d187e818f2dd05774175a2a7feb9696e
dangling commit a5f5b7956f7d63bab13d3f2c45c7315cfbea28b8
The commits are probably due to reflogs, that's OK. But why do I have a
dangling blob after git gc? The interesting part is that as you can see
most of them is removed, but not all.
Any ideas? :)
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-svn and svn branches
From: Michael J Gruber @ 2008-11-27 10:02 UTC (permalink / raw)
To: Eric Wong; +Cc: Ryan Phillips, git
In-Reply-To: <20081125230823.GA6664@mayonaise>
Eric Wong venit, vidit, dixit 26.11.2008 00:08:
> Ryan Phillips <ryan@trolocsis.com> wrote:
>> I followed the following instructions on adding a remote svn branch to my
>> local git-svn repository. http://www.dmo.ca/blog/20070608113513
>>
>> Are these still accurate?
>>
>> I started the repository with
>> # git svn init [url/trunk]`
>> # cd project.git
>> # git svn fetch -r[HEAD revision]
>> which works fine. I added something like Snippet 1 to the .git/config and
>> issued a `git svn fetch -r[HEAD revision of the branch]` and nothing
>> happens. It takes git-svn a few seconds to run, but the git-remote svn
>> branch doesn't get initialized.
>>
>> Does this procedure only work with a full mirror of a git-svn repository?
>> or perhaps I'm doing something wrong. Any help would be appreciated.
>>
>> Thanks,
>> Ryan
>>
>> Snippet 1
>> =========
>>
>> [svn-remote "svn34"]
>> url = svn+ssh://your-server/home/svn/project-name/branches/3.4.x
>> fetch = :refs/remotes/git-svn-3.4
>
> Try this:
>
> git svn fetch -i svn34
>
> It's been a while since I've used this, but I believe a test
> case covers it so it probably still works :)
>
Uhm, I think it's rather "-R svn34" which tells git-svn to use the svn
remote config "svn34". -i sets GIT_SVN_ID.
Michael
^ permalink raw reply
* Re: git-svn clone behaves non-deterministic
From: Michael J Gruber @ 2008-11-27 9:55 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20081127075351.GA12716@raven.wolf.lan>
Josef Wolf venit, vidit, dixit 27.11.2008 08:53:
> Hello,
>
> I am new to git and decided to get my feet wet by first cloning and
> playing with my existing svn repositories. Thus, I've done this:
>
> cd /my/test/repos
> for i in repo1 repo2 repo3; do
> repos=https://my.repos.server/repos/$i/trunk
> svn co $repos svn/$i
> git-svn clone $repos git/$i
> done
>
> for i in `cd svn; echo *`; do diff --exclude /.svn -Nruw */$i; done
>
> With this, I see that four of the repositories are cloned as expected,
> but the fifth has only the .git directory in it. It appears that
> the clone command stopped cloning at r2008, while the repository is
> currently at r3761. So almost the half of the history was not
> cloned at all. I've investigated the offending revision and the
> revisions around it, but I can't see anything special about them.
> The effect is perfectly reproducible and it stops always on the very
> same revision. I get no error message at all. I've attached the
> last lines of the clone operation at the end of this mail.
First of all: What does git --version say? Is it self-compiled git or
git as it comes with U 8.10?
Then: I assume the above is not quite what you did, otherwise I would be
surprised you see a 4th and 5th clone...
Your repo is probably one giant svn repo. In any case, the fact that the
repo is at $rev does not imply that the last commit on trunk is at $rev.
What is the last commit on trunk?
Other than that: There are so many sins you can commit (!) in an svn
repo that it it is hard to tell which one threw git-svn off. Can you
share the repo?
> Then I go to another machine and enter exactly the same commands as
> above. Both machines are fresh ubuntu-8.10 default installs.
>
> To my surprise, on this other machine the clone operation seems to
> have worked for all the repositories. But the diff command shows
> me that arbitrary files are missing in _all_ of the repositories.
I don't think computers behave deterministically, at least not according
to my experience. After all they rely on quantum mechanics, and who has
ever understood the measurement process, the collapsing of the wave
function?
OK: Whenever I got 2 different results after doing the same twice I
found that indeed some hidden/forgotten variable was not the same... Any
chance you find one?
Michael
^ permalink raw reply
* Re: [PATCH] Fix typos in the documentation.
From: Junio C Hamano @ 2008-11-27 9:48 UTC (permalink / raw)
To: Ralf Wildenhues; +Cc: git
In-Reply-To: <20081127073201.GD8267@ins.uni-bonn.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de> writes:
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> ---
>
> This patch is against pu.
While I appreciate your fix, it would have been nicer to have at least
three patches in this case, organized like this:
* patch 1 applies to 'maint'. Let's call the result of such application
'maint plus fix';
In other words:
$ git checkout -b rw/maint-typofix maint
$ git am -s patch-1
* patch 2 is to be applied on top of the result of merging 'maint plus
fix' into 'master';
In other words:
$ git checkout -b rw/typofix master
$ git merge rw/maint-typofix
$ git am -s patch-2
* patch 3 is to contain everything else (it would be even nicer if they
are split up to apply to individual topic branches that are responsible
for introducing the typos, but I realize that it would be asking too
much).
In other words:
$ git checkout pu
$ git merge rw/typofix
$ git am -s patch-3
I've done the above splitting myself and further did:
$ git checkout maint
$ git merge rw/maint-typofix
$ git branch -d rw/maint-typofix
$ git checkout master
$ git merge rw/typofix
$ git branch -d rw/typofix
I did not create a single "patch-3" but squashed the fixes in to the
respective commits on the topic branches, as they are only on 'pu' and not
part of 'next' (hence I am free to amend and rebase them).
Thanks.
^ permalink raw reply
* Re: How to know where a reference name comes from?
From: Junio C Hamano @ 2008-11-27 9:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqk5ap5xy1.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> (I ended up doing "strace -e open git rev-parse git-svn", and found
> out I had a .git/git-svn file lying around)
This has been proposed for a couple of times now but I think it might be
time to start insisting on a ref directly underneath $GIT_DIR to be in all
caps (plus underscore) to avoid issues like this while still allowing
traditional MERGE_HEAD, ORIG_HEAD and friends.
^ permalink raw reply
* Re: format-patch problem when using relative
From: Björn Steinbrink @ 2008-11-27 9:42 UTC (permalink / raw)
To: Nikola Knežević; +Cc: Jeff King, git
In-Reply-To: <06D676E3-6C24-4ACC-9874-8B19549BC3A1@gmail.com>
On 2008.11.26 19:58:34 +0100, Nikola Knežević wrote:
> On 26 Nov 2008, at 19:01 , Jeff King wrote:
>
>> So I think what you really want is:
>>
>> git format-patch --relative=click click/master myclick -- click
>>
>> to limit the path pruning to the 'click' directory.
>
> Yes, that did the trick. Also, when I think about it, it makes sense -
> do checks relative to a path, but prune using path.
Ah, now that makes sense to me, too. You just didn't use the actual
command I told you on IRC ;-)
<doener> git format-patch --relative=click/ click/master click
That already had the path limiting "click" in it, I really meant "click"
there, not "myclick" ;-) I guess the confusion was caused by how
format-patch takes the range it's supposed to work on. If you only give
it a single committish, that is interpreted as "since". So the above is
equal to
git format-patch --relative=click/ click/master..HEAD click
Björn
^ permalink raw reply
* Re: git configure script
From: Mike Ralphson @ 2008-11-27 9:25 UTC (permalink / raw)
To: Neale T. Pickett; +Cc: git, Matthieu Moy
In-Reply-To: <vpq7i6q8azp.fsf@bauges.imag.fr>
2008/11/26 Matthieu Moy <Matthieu.Moy@imag.fr>
>
> neale@lanl.gov (Neale T. Pickett) writes:
>
> > But it installed everything in $HOME/bin and $HOME/libexec. Looking
> > into it, it seems the shipped Makefile doesn't look to see what --prefix
> > is, despite the configure script claiming that "make install" would
> > honor this.
>
> It does, since it includes config.mak.autogen which overrides prefix
> defined in Makefile.
>
> I'm 99% sure you did something wrong. You should investigate by
> looking into config.mak.autogen after running configure.
Indeed. I believe something goes a little funny if you build as root.
Can you try again running ./configure and (g)make as a non-root user,
then only (g)make install as root / under sudo etc.
Cheers, Mike
^ permalink raw reply
* How to know where a reference name comes from?
From: Matthieu Moy @ 2008-11-27 9:18 UTC (permalink / raw)
To: git
Hi,
I faced a simple problem: on a repository, doing almost anything with
the reference "git-svn" complained about ambiguous reference. I know I
have a remotes/git-svn branch, but I didn't know what the other
reference could be.
I didn't find a command telling me _why_ this "git-svn" was ambiguous.
I'd have loved a
$ git rev-parse --all-symbolic-full-names git-svn
or so, but I couldn't find one.
Did I miss anything obvious? (not that the problem was big, I'm just
curious).
(I ended up doing "strace -e open git rev-parse git-svn", and found
out I had a .git/git-svn file lying around)
Thanks,
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Fix typos in the documentation.
From: Andreas Ericsson @ 2008-11-27 9:10 UTC (permalink / raw)
To: Ralf Wildenhues, git
In-Reply-To: <20081127073201.GD8267@ins.uni-bonn.de>
Ralf Wildenhues wrote:
> Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
> ---
>
> This patch is against pu.
>
'pu' is a moving target in git. For future reference, it's
better to send patches against 'master'.
Other than that:
Acked-by: Andreas Ericsson <ae@op5.se>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: know wget URL, need git-clone URL
From: Andreas Ericsson @ 2008-11-27 9:00 UTC (permalink / raw)
To: jidanni; +Cc: git, smartphones-userland
In-Reply-To: <87bpw1hkqx.fsf@jidanni.org>
jidanni@jidanni.org wrote:
> I wish the git beginner documentation would tell one how to translate
> e.g., http://git.debian.org/?p=pkg-fso/files.git&a=blob_plain&f=install.sh
> which is good for wget, to the URL one needs for git-clone to get the
> same file.
You can't use "git clone" to get a single file. You can only get the
entire repository using "git clone". Usually, the clone-url is written
somewhere on the projects gitweb page, and that is also the case for
this repository.
If you visit http://git.debian.org/?p=pkg-fso/files.git;a=summary you'll
find this section on that page:
URL git://git.debian.org/git/pkg-fso/files.git
http://git.debian.org/git/pkg-fso/files.git
It's impossible to infer the clone url from the gitweb url, because there's
absolutely no connection between them (that will change if gitweb gains
fetch/clone support), and the paths/urls depends on the servers configuration
which we cannot know.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Andreas Ericsson @ 2008-11-27 8:18 UTC (permalink / raw)
To: Ondrej Certik
Cc: Johannes Schindelin, Michael J Gruber, Git Mailing List,
Fabian Seoane
In-Reply-To: <85b5c3130811260921s474bc724hb74b54e21e8be912@mail.gmail.com>
Ondrej Certik wrote:
> On Wed, Nov 26, 2008 at 5:40 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>> On Wed, 26 Nov 2008, Ondrej Certik wrote:
>>
>>> I am also trying to make the example simpler. I tried to squash the
>>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
>>> fails after squashing about 600 commits. Still investigating.
>> 1500... wow.
>>
>> The best idea would probably be to just "edit" the first, delete the rest
>> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
>> the command line (when git rebase stops after the "edit" command).
>
> That worked, thanks! My original repo:
>
> A -- B -- ... --- D --- E --- ...
>
> where E and the rest of the commits (there are branches and merges in
> there) are the ones that I need to preserve, but all the commits
> between B and D can be squashed (~1500 of them). So I created a
> branch:
>
> A -- B -- ... --- D
>
> then squashed the commits using the technique you described above, so
> now I have:
>
> A -- BD --
>
> and now I would like to append "E -- ..." to it -- is there any way to
> do that? I tried rebase, but that destroys all the branches and merges
> and those are necessary to reproduce the fast-export bug.
>
git rebase -p
If your git is old, you'll need
git rebase -i -p
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-svn clone behaves non-deterministic
From: Josef Wolf @ 2008-11-27 7:53 UTC (permalink / raw)
To: git
Hello,
I am new to git and decided to get my feet wet by first cloning and
playing with my existing svn repositories. Thus, I've done this:
cd /my/test/repos
for i in repo1 repo2 repo3; do
repos=https://my.repos.server/repos/$i/trunk
svn co $repos svn/$i
git-svn clone $repos git/$i
done
for i in `cd svn; echo *`; do diff --exclude /.svn -Nruw */$i; done
With this, I see that four of the repositories are cloned as expected,
but the fifth has only the .git directory in it. It appears that
the clone command stopped cloning at r2008, while the repository is
currently at r3761. So almost the half of the history was not
cloned at all. I've investigated the offending revision and the
revisions around it, but I can't see anything special about them.
The effect is perfectly reproducible and it stops always on the very
same revision. I get no error message at all. I've attached the
last lines of the clone operation at the end of this mail.
Then I go to another machine and enter exactly the same commands as
above. Both machines are fresh ubuntu-8.10 default installs.
To my surprise, on this other machine the clone operation seems to
have worked for all the repositories. But the diff command shows
me that arbitrary files are missing in _all_ of the repositories.
Since the repositories were not modified in the mean time, it looks
to me like there's a problem with the "git-svn clone" command.
Any ideas?
r2005 = e487699eb8f94d6c5e9b732ba75e1c50cae3bb5e (git-svn)
A misc/ubuntu-remaster/Rakefile
r2006 = 8b15a1a5bdc8e6a3bfd7e6eb717ef4c2db0f1dbf (git-svn)
M misc/ubuntu-remaster/Rakefile
r2007 = 27678a3bd98400abdaaaf9af543f9558593fc224 (git-svn)
M misc/ubuntu-remaster/Rakefile
r2008 = bbc2d0cbe4419a499d29afda281b85b5e744a5e6 (git-svn)
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 12446, done.
Compressing objects: 100% (11999/11999), done.
Writing objects: 100% (12446/12446), done.
Total 12446 (delta 7657), reused 0 (delta 0)
jw@vdr1:/my/test/repos$ l git/misc/
total 12
drwxr-xr-x 3 jw jw 4096 Nov 27 08:27 ./
drwxr-xr-x 3 jw jw 4096 Nov 27 08:27 ../
drwxr-xr-x 9 jw jw 4096 Nov 27 08:38 .git/
^ permalink raw reply
* [PATCH] Fix typos in the documentation.
From: Ralf Wildenhues @ 2008-11-27 7:32 UTC (permalink / raw)
To: git
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
This patch is against pu.
Cheers, and thanks for git,
Ralf
Documentation/RelNotes-1.6.0.4.txt | 2 +-
Documentation/RelNotes-1.6.1.txt | 6 +++---
Documentation/config.txt | 2 +-
Documentation/git-add.txt | 2 +-
Documentation/git-bisect.txt | 6 +++---
Documentation/git-commit.txt | 2 +-
Documentation/git-svn.txt | 2 +-
Documentation/technical/pack-protocol.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
9 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/RelNotes-1.6.0.4.txt b/Documentation/RelNotes-1.6.0.4.txt
index fba3f30..d522661 100644
--- a/Documentation/RelNotes-1.6.0.4.txt
+++ b/Documentation/RelNotes-1.6.0.4.txt
@@ -30,7 +30,7 @@ Fixes since v1.6.0.3
* 'git status' incorrectly reported a submodule directory as an untracked
directory.
-* 'git svn' used deprecated 'git-foo' form of subcommand invocaition.
+* 'git svn' used deprecated 'git-foo' form of subcommand invocation.
* 'git update-ref -d' to remove a reference did not honor --no-deref option.
diff --git a/Documentation/RelNotes-1.6.1.txt b/Documentation/RelNotes-1.6.1.txt
index 7fdf83f..848541a 100644
--- a/Documentation/RelNotes-1.6.1.txt
+++ b/Documentation/RelNotes-1.6.1.txt
@@ -55,9 +55,9 @@ on.
to a non-zero value to accept the suggestion when git can uniquely
guess.
-* The packfile machinery hopefully is more robust when dealilng with
+* The packfile machinery hopefully is more robust when dealing with
corrupt packs if redundant objects involved in the corruption are
- available elsehwere.
+ available elsewhere.
* "git add -N path..." adds the named paths as an empty blob, so that
subsequent "git diff" will show a diff as if they are creation events.
@@ -157,7 +157,7 @@ on.
* "git log" learned "--source" to show what ref each commit was reached
from.
-* "git log" also learned "--simplify-by-decration" to show the
+* "git log" also learned "--simplify-by-decoration" to show the
birds-eye-view of the topology of the history.
* "git log --pretty=format:" learned "%d" format element that inserts
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 2283300..6d51967 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -841,7 +841,7 @@ gui.fastcopyblame::
repositories at the expense of less thorough copy detection.
gui.copyblamethreshold::
- Specifies the theshold to use in 'git gui blame' original location
+ Specifies the threshold to use in 'git gui blame' original location
detection, measured in alphanumeric characters. See the
linkgit:git-blame[1] manual for more information on copy detection.
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 6fc20b0..7c129cb 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -98,7 +98,7 @@ OPTIONS
Record only the fact that the path will be added later. An entry
for the path is placed in the index with no content. This is
useful for, among other things, showing the unstaged content of
- such files with 'git diff' and commiting them with 'git commit
+ such files with 'git diff' and committing them with 'git commit
-a'.
--refresh::
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 2ac77fb..75083e6 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -192,10 +192,10 @@ Bisect replace
This subcommand can help when you have a branch or a part of a
branch that isn't easily bisectable because of a bug that has been
-fixed latter.
+fixed later.
We suppose that a bug as been introduced at some point, say A, and
-that it has been fixed latter at another point, say B, but that
+that it has been fixed later at another point, say B, but that
between these points the code is not easily testable because of the
bug, so it's not easy to bisect between these points.
@@ -244,7 +244,7 @@ because the bug introduced by commit A and fixed by commit B will not
annoy you anymore.
As the refs created by "git bisect replace" can be shared between
-developers, this feature might be especially usefull on big projects
+developers, this feature might be especially useful on big projects
where many people often bisect the same code base.
If you give the `--no-replace` to "git bisect start", then the
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index a1ce9a8..6203461 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -95,7 +95,7 @@ OPTIONS
-s::
--signoff::
- Add Signed-off-by line by the commiter at the end of the commit
+ Add Signed-off-by line by the committer at the end of the commit
log message.
-n::
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index ba94cd1..8d0c421 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -109,7 +109,7 @@ COMMANDS
This works similarly to `svn update` or 'git-pull' except that
it preserves linear history with 'git-rebase' instead of
-'git-merge' for ease of dcommiting with 'git-svn'.
+'git-merge' for ease of dcommitting with 'git-svn'.
This accepts all options that 'git-svn fetch' and 'git-rebase'
accept. However, '--fetch-all' only fetches from the current
diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt
index 7396f69..696dd00 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -59,13 +59,13 @@ When tellme-more extension is used:
C: SHA1 old-SHA1 -- This is ancestor of that, you might know
C: SHA1 old-SHA1
C: ...
- C: # flush -- have you heard ehough?
+ C: # flush -- have you heard enough?
S: tellme-more old-SHA1' -- I still want to know more about this one
S: # flush -- please give me more
C: SHA1 old-SHA1'
C: SHA1 old-SHA1'
C: ...
- C: # flush -- have you heard ehough?
+ C: # flush -- have you heard enough?
S: # flush -- yes, thanks, we've heard enough
S: XXXXXXX --- packfile contents.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c0d8caf..da9c6b2 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -546,7 +546,7 @@ $ git bisect skip
-------------------------------------------------
In this case, though, git may not eventually be able to tell the first
-bad one between some first skipped commits and a latter bad commit.
+bad one between some first skipped commits and a later bad commit.
There are also ways to automate the bisecting process if you have a
test script that can tell a good from a bad commit. See
--
1.6.0.4.766.g6fc4a
^ permalink raw reply related
* Re: [PATCH] Print hunk number in prompt of add --patch.
From: Junio C Hamano @ 2008-11-27 7:14 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <492E3B6D.9090309@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index b0223c3..7974cd1 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -919,7 +919,7 @@ sub patch_update_file {
> for (@{$hunk[$ix]{DISPLAY}}) {
> print;
> }
> - print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
> + print colored $prompt_color, "Stage hunk $ix [y/n/a/d$other/?]? ";
> my $line = <STDIN>;
> if ($line) {
> if ($line =~ /^y/i) {
Do we know how many hunks we have at this point (and remember we need to
adjust the number of hunks after splitting)?
The original one was unfriendly in that it asked "Do you want this or not?
We'd rather not to say where you are nor how many more there are". Your
update is slightly better but not enough: "Do you want this one or not?
It is the second one but we still won't tell you how many more there are".
I'd prefer it to ask "Stage hunk 2 (of 35)?" if you are adding more words
here.
I doubt "jump to hunk specified by hunk number" is useful in general. You
wouldn't know what hunk number the hunk you are interested in has, until
you scroll through them all.
"Jump to hunk around line number X in the preimage", or "jump to a hunk in
function Y" may be useful (the latter you can do with "/^@@.*funcname"
with your slash-search patch).
^ permalink raw reply
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: Junio C Hamano @ 2008-11-27 6:41 UTC (permalink / raw)
To: William Pursell; +Cc: Jeff King, git
In-Reply-To: <492E3811.6050603@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> Before working on patches, I'd like some ideas on
> functionality:
>
> 1) If a hunk doesn't match, should it be as if the user
> selected 'n', or 'j'?
Is it an option to tell "nothing matched", stay at the same hunk and ask
the user to make the choice again?
^ permalink raw reply
* [PATCH] Print hunk number in prompt of add --patch.
From: William Pursell @ 2008-11-27 6:17 UTC (permalink / raw)
To: git
I'm considering adding a command to skip to a hunk, and
just generally find myself confused about which hunk I'm
looking at, so having the number in the prompt is helpful.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..7974cd1 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -919,7 +919,7 @@ sub patch_update_file {
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
- print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored $prompt_color, "Stage hunk $ix [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* Re: [PATCH 1/2] Add / command in add --patch (feature request)
From: William Pursell @ 2008-11-27 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vod02cd3p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>
> Use of eval is a good way to protect against this kind of breakage, but it
> should be done close to where the string is given by the user, perhaps in
> here:
>
>
> + elsif ($line =~ m|^/(.*)|) {
> + $search_s = $1;
> + }
>
> Something like...
>
> elsif ($line =~ m|^/(.*)|) {
> $search_string = $1;
> eval {
> $search_string =~ /$search_string/;
> };
> if ($@) {
> print STDERR "Regexp error in $search_string: $@";
> next;
> }
> ...
Thanks. The second set of patches that I just sent
up is fatally flawed--by changing to skip unmatched
hunks instead of deselecting them, it enters a loop
if no hunks match.
Before working on patches, I'd like some ideas on
functionality:
1) If a hunk doesn't match, should it be as if the user
selected 'n', or 'j'?
2) If no hunks match it is easiest to simply move to
the last hunk and display it, but I'm not sure that
is acceptable. Probably better to return to the
hunk that was being viewed when the search string
is entered, but that seems to require some restructuring
of the code. What would be the preferred behavior?
--
William Pursell
^ permalink raw reply
* know wget URL, need git-clone URL
From: jidanni @ 2008-11-27 4:10 UTC (permalink / raw)
To: git; +Cc: smartphones-userland
I wish the git beginner documentation would tell one how to translate
e.g., http://git.debian.org/?p=pkg-fso/files.git&a=blob_plain&f=install.sh
which is good for wget, to the URL one needs for git-clone to get the
same file.
^ permalink raw reply
* [PATCH 3/3] In add --patch, Handle K,k,J,j slightly more gracefully.
From: William Pursell @ 2008-11-27 4:08 UTC (permalink / raw)
To: git
Instead of printing the help menu, this will print
"No next hunk" and then process the given hunk again.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 43 ++++++++++++++++++++++++++++---------------
1 files changed, 28 insertions(+), 15 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 547b5c8..66f6629 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -965,29 +965,42 @@ sub patch_update_file {
elsif ($line =~ m|^/(.*)|) {
$search_s = qr{$1}m;
}
- elsif ($other =~ /K/ && $line =~ /^K/) {
- $ix--;
+ elsif ($line =~ /^K/) {
+ if ($other =~ /K/) {
+ $ix--;
+ }
+ else {
+ print STDERR "No previous hunk\n";
+ }
next;
}
- elsif ($other =~ /J/ && $line =~ /^J/) {
- $ix++;
+ elsif ($line =~ /^J/) {
+ if ($other =~ /J/) {
+ $ix++;
+ }
+ else {
+ print STDERR "No next hunk\n";
+ }
next;
}
- elsif ($other =~ /k/ && $line =~ /^k/) {
- while (1) {
- $ix--;
- last if (!$ix ||
- !defined $hunk[$ix]{USE});
+ elsif ($line =~ /^k/) {
+ if ($other =~ /k/) {
+ while (1) {
+ $ix--;
+ last if (!$ix ||
+ !defined $hunk[$ix]{USE});
+ }
+ }
+ else {
+ print STDERR "No previous hunk\n";
}
next;
}
- elsif ($other =~ /j/ && $line =~ /^j/) {
- while (1) {
- $ix++;
- last if ($ix >= $num ||
- !defined $hunk[$ix]{USE});
+ elsif ($line =~ /^j/) {
+ if ($other !~ /j/) {
+ print STDERR "No next hunk\n";
+ next;
}
- next;
}
elsif ($other =~ /s/ && $line =~ /^s/) {
my @split = split_hunk($hunk[$ix]{TEXT}, $hunk[$ix]{DISPLAY});
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
* [PATCH 2/3] Add / command in add --patch
From: William Pursell @ 2008-11-27 4:07 UTC (permalink / raw)
To: git
This command allows the user to skip hunks that don't
match the specified regex.
BUG: if the user enters an invalid regex, perl will abort.
For example: /+\s*foo will abort with:
Quantifier follows nothing in regex
I am not a Perl hacker and would welcome suggestions
on the easiest way to deal with this.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 27 +++++++++++++++++++++++----
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index f20b880..547b5c8 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -800,6 +800,7 @@ y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks in the file
d - do not stage this hunk nor any of the remaining hunks in the file
+/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
@@ -876,12 +877,14 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ my $search_s; # User entered string to match a hunk.
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
if ($num <= $ix) {
+ undef $search_s;
$ix = 0;
}
for ($i = 0; $i < $ix; $i++) {
@@ -916,11 +919,24 @@ sub patch_update_file {
$other .= ',s';
}
$other .= ',e';
- for (@{$hunk[$ix]{DISPLAY}}) {
- print;
+
+ my $line;
+ if (defined $search_s) {
+ my $text = join ("", @{$hunk[$ix]{DISPLAY}});
+ if ($text !~ $search_s) {
+ $line = "j\n";
+ } else {
+ print $text;
+ }
+ } else {
+ for (@{$hunk[$ix]{DISPLAY}}) {
+ print;
+ }
+ }
+ if (!$line) {
+ print colored $prompt_color, "Stage this hunk [y,n,a,d,/$other,?]? ";
+ $line = <STDIN>;
}
- print colored $prompt_color, "Stage this hunk [y,n,a,d$other,?]? ";
- my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
@@ -946,6 +962,9 @@ sub patch_update_file {
}
next;
}
+ elsif ($line =~ m|^/(.*)|) {
+ $search_s = qr{$1}m;
+ }
elsif ($other =~ /K/ && $line =~ /^K/) {
$ix--;
next;
--
1.6.0.4.782.geea74.dirty
--
William Pursell
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox