* Re: stgit: cleaning up after using git branch delete commands
From: Karl Hasselström @ 2007-11-08 5:53 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910711070811y72f96a90i4db9acdf93aa765c@mail.gmail.com>
On 2007-11-07 11:11:42 -0500, Jon Smirl wrote:
> how about a 'stg gc' command that gets rid of all the inaccessible
> clutter?
"stg assimilate" already has the job of fixing up stuff after the user
has used git commands to move HEAD around. I think it would make sense
to teach it to do this too -- and then rename it "stg repair" or
something. That way, there's one command to fix every kind of "damage"
that git can do to stgit.
Alternatively, "stg branch --create" and "stg init" and whoever else
is bothered by the clutter could simply remove it themselves. That
would be even more user-friendly, I guess.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [REPLACEMENT PATCH] git-checkout: Add a test case for relative paths use.
From: David Symonds @ 2007-11-08 5:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
These test cases also expose a bug in git-ls-files, where:
git-ls-files t/../
(with or without --full-name) returns no files.
t/t2008-checkout-subdir.sh | 47 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100755 t/t2008-checkout-subdir.sh
diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
new file mode 100755
index 0000000..45833f3
--- /dev/null
+++ b/t/t2008-checkout-subdir.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 David Symonds
+
+test_description='git checkout from subdirectories'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo base > file0 &&
+ git add file0 &&
+ mkdir dir1 &&
+ echo hello > dir1/file1 &&
+ git add dir1/file1 &&
+ test_tick &&
+ mkdir dir2 &&
+ echo bonjour > dir2/file2 &&
+ git add dir2/file2 &&
+ git commit -m "populate tree"
+
+'
+
+test_expect_success 'remove and restore with relative path' '
+
+ cd dir1 &&
+ rm ../file0 &&
+ git checkout HEAD -- ../file0 && test -f ../file0 &&
+ rm ../dir2/file2 &&
+ git checkout HEAD -- ../dir2/file2 && test -f ../dir2/file2 &&
+ rm ../file0 ./file1 &&
+ git checkout HEAD -- .. && test -f ../file0 && test -f ./file1 &&
+ rm file1 &&
+ git checkout HEAD -- ../dir1/../dir1/file1 && test -f ./file1
+
+'
+
+test_expect_failure 'checkout with relative path outside tree should fail (1)' \
+ 'git checkout HEAD - ../file0'
+
+test_expect_failure 'checkout with relative path outside tree should fail (2)' \
+ 'cd dir1 && git checkout HEAD - ./file0'
+
+test_expect_failure 'checkout with relative path outside tree should fail (2)' \
+ 'cd dir1 && git checkout HEAD - ../../file0'
+
+test_done
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] Make git-clean a builtin
From: Shawn Bohrer @ 2007-11-08 5:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, johannes.schindelin
In-Reply-To: <7vabppbxef.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 07, 2007 at 12:42:16PM -0800, Junio C Hamano wrote:
>
> Having said that, I do not particularly agree with the way the
> new implementation resolves the existing inconsistencies.
>
> Wouldn't it be better to remove "dir" when the user explicitly
> told you to clean "dir", with or without the trailing slash?
> That's what the user asked you to do, isn't it?
Yes I suppose I agree. Of course I need to spend some more time staring
at the code to figure out how to do so. Perhaps I can figure out what
is causing the original inconsistency in git-ls-files while I'm at it.
^ permalink raw reply
* Re: [PATCH] git-checkout: Add a test case for relative paths use.
From: Junio C Hamano @ 2007-11-08 5:03 UTC (permalink / raw)
To: David Symonds; +Cc: git, Johannes Schindelin
In-Reply-To: <11944932524072-git-send-email-dsymonds@gmail.com>
David Symonds <dsymonds@gmail.com> writes:
> Signed-off-by: David Symonds <dsymonds@gmail.com>
> ---
> t/t2008-checkout-subdir.sh | 36 ++++++++++++++++++++++++++++++++++++
> 1 files changed, 36 insertions(+), 0 deletions(-)
> create mode 100755 t/t2008-checkout-subdir.sh
>
> diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
> new file mode 100755
> index 0000000..cb9c9eb
> --- /dev/null
> +++ b/t/t2008-checkout-subdir.sh
> @@ -0,0 +1,36 @@
> +#!/bin/sh
> +#
> +# Copyright (c) 2007 David Symonds
> +
> +test_description='git checkout from subdirectories'
> +
> +. ./test-lib.sh
> +
> +test_expect_success setup '
> +
> + echo base > file0 &&
> + git add file0 &&
> + mkdir dir1 &&
> + echo hello > dir1/file1 &&
> + git add dir1/file1 &&
> + test_tick &&
> + mkdir dir2 &&
> + echo bonjour > dir2/file2 &&
> + git add dir2/file2 &&
> + git commit -m "populate tree"
> +
> +'
> +
> +test_expect_success 'remove and restore with relative path' '
> +
> + cd dir1 &&
> + rm ../file0 &&
> + git checkout HEAD -- ../file0 && test -f ../file0 &&
> + rm ../dir2/file2 &&
> + git checkout HEAD -- ../dir2/file2 && test -f ../dir2/file2 &&
> + rm ../file0 ./file1 &&
> + git checkout HEAD -- .. && test -f ../file0 && test -f ./file1
> +
> +'
This is better than not having any test, but we would also want
a negative test. Things like trying to check out "../file"
without going down into a subdirectory, check out "../../file"
in a subdirectory that is only one level deep.
^ permalink raw reply
* Re: missing object on git-gc
From: Christian Couder @ 2007-11-08 5:03 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: git
In-Reply-To: <6C2C79E72C305246B504CBA17B5500C9029A3071@mtlexch01.mtl.com>
There is an entry "How to fix a broken repository?" in the Git Faq on the
wiki:
http://git.or.cz/gitwiki/GitFaq#head-ac11406480d09e2df98588e800e41b7256602074
Maybe it can help you.
The same topic has been discussed at least 3 times on the mailing list.
By the way, if you find these discussions on gmane, please tell us so that
we can add the links to the FAQ entry. (You can also add them yourself.)
Thanks,
Christian.
Le jeudi 8 novembre 2007, Yossi Leybovich a écrit :
> I am running the git-gc tool over my repository and get the following
> error:
>
> > git-gc
>
> ...
> deltifying 3308 objects...
> error: corrupt loose object '<sha1>'
> fatal: object <sha1> cannot be read .
> error: failed to run repack
>
> when sha1 is 40 bytes number
>
> Does any one know how I can solve thus issue?
>
> Thanks
> YOssi
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] git-checkout: Add a test case for relative paths use.
From: David Symonds @ 2007-11-08 3:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
t/t2008-checkout-subdir.sh | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
create mode 100755 t/t2008-checkout-subdir.sh
diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
new file mode 100755
index 0000000..cb9c9eb
--- /dev/null
+++ b/t/t2008-checkout-subdir.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 David Symonds
+
+test_description='git checkout from subdirectories'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo base > file0 &&
+ git add file0 &&
+ mkdir dir1 &&
+ echo hello > dir1/file1 &&
+ git add dir1/file1 &&
+ test_tick &&
+ mkdir dir2 &&
+ echo bonjour > dir2/file2 &&
+ git add dir2/file2 &&
+ git commit -m "populate tree"
+
+'
+
+test_expect_success 'remove and restore with relative path' '
+
+ cd dir1 &&
+ rm ../file0 &&
+ git checkout HEAD -- ../file0 && test -f ../file0 &&
+ rm ../dir2/file2 &&
+ git checkout HEAD -- ../dir2/file2 && test -f ../dir2/file2 &&
+ rm ../file0 ./file1 &&
+ git checkout HEAD -- .. && test -f ../file0 && test -f ./file1
+
+'
+
+test_done
--
1.5.3.1
^ permalink raw reply related
* Re: git rebase --skip
From: Jakub Narebski @ 2007-11-08 3:31 UTC (permalink / raw)
To: git
In-Reply-To: <20071108032308.GA5638@sigill.intra.peff.net>
Jeff King wrote:
> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
>
>> I use git-rebase quite regularly, and I haven't used git-rebase --skip
>> after a failed merge without first resetting the working tree. I was
>> wondering if it wouldn't make sense to automatically do the reset when
>> running git-rebase --skip.
>
> I have often been annoyed by this behavior, too, and I can't think of
> any situation where you _wouldn't_ want the reset to happen. But I
> would be more comfortable hearing confirmation from others that they
> can't think of such a situation.
Perhaps "git rebase --force-skip" or "git rebase --force --skip"
would be the way to fo above...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git rebase --skip
From: Jeff King @ 2007-11-08 3:23 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20071107222105.GA31666@glandium.org>
On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
> I use git-rebase quite regularly, and I haven't used git-rebase --skip
> after a failed merge without first resetting the working tree. I was
> wondering if it wouldn't make sense to automatically do the reset when
> running git-rebase --skip.
I have often been annoyed by this behavior, too, and I can't think of
any situation where you _wouldn't_ want the reset to happen. But I
would be more comfortable hearing confirmation from others that they
can't think of such a situation.
-Peff
^ permalink raw reply
* Re: [PATCH] git-branch --with=commit
From: Johannes Schindelin @ 2007-11-08 3:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5ot7aqz.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 7 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > would it not be better to call it --containing=commit? Besides, I
> > think that the opt_parse_with_commit() function would be better named
> > opt_parse_commit() and be put into parse-options.[ch].
>
> git-describe has "--contains" so that may be a better match.
I just thought what I would understand when reading "git branch
--with=master". I would have expected that it branches off of master.
> I do not know the particular function is generic enough to be in
> parse-options.
Maybe not, you're right. And we can always come back later, and expose
the function if need be.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-checkout: Handle relative paths containing "..".
From: David Symonds @ 2007-11-08 2:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, David Symonds
Based on gitte's idea.
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
git-checkout.sh | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 8993920..b2c50aa 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -134,9 +134,10 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
fi
# Make sure the request is about existing paths.
- git ls-files --error-unmatch -- "$@" >/dev/null || exit
- git ls-files -- "$@" |
- git checkout-index -f -u --stdin
+ git ls-files --full-name --error-unmatch -- "$@" >/dev/null || exit
+ git ls-files --full-name -- "$@" |
+ (cd "$(git-rev-parse --show-cdup)" &&
+ git checkout-index -f -u --stdin)
# Run a post-checkout hook -- the HEAD does not change so the
# current HEAD is passed in for both args
--
1.5.3.5.1529.g69a1-dirty
^ permalink raw reply related
* Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/
From: Jeff King @ 2007-11-08 2:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alex Riesen, Gerrit Pape, Fernando J. Pereda, git, Jakub Narebski
In-Reply-To: <7vfxzh7ajt.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 07, 2007 at 06:09:26PM -0800, Junio C Hamano wrote:
> > When saving patches to a maildir with e.g. mutt, the files are put into
> > the new/ subdirectory of the maildir, not cur/. This makes git-am state
> > "Nothing to do.". This patch lets git-mailsplit additional check new/
> > after reading cur/.
>
> Looks good to me. Final acks please?
Fixed my concerns.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: [PATCH amend] git-mailsplit: with maildirs not only process cur/, but also new/
From: Junio C Hamano @ 2007-11-08 2:09 UTC (permalink / raw)
To: Alex Riesen
Cc: Gerrit Pape, Fernando J. Pereda, git, Jakub Narebski, Jeff King
In-Reply-To: <20071106085418.14211.qmail@54d7c9212e25c5.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> When saving patches to a maildir with e.g. mutt, the files are put into
> the new/ subdirectory of the maildir, not cur/. This makes git-am state
> "Nothing to do.". This patch lets git-mailsplit additional check new/
> after reading cur/.
>
> This was reported by Joey Hess through
> http://bugs.debian.org/447396
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
>
> On Mon, Nov 05, 2007 at 01:58:50PM +0100, Jakub Narebski wrote:
>> > + for (i = 0; i < 2; ++i) {
>> Wouldn't it be better to use sizeof(sub)/sizeof(sub[0]) or it's macro
>> equivalent ARRAY_SIZE(sub) instead of hardcoding 2 to avoid errors?
> I made the array NULL-terminated.
>
> On Mon, Nov 05, 2007 at 04:26:24PM -0500, Jeff King wrote:
>> Isn't the subject line now wrong?
> Yes, thanks.
>
> On Mon, Nov 05, 2007 at 11:52:58PM +0100, Alex Riesen wrote:
>> Why is missing "cur" (or "new", for that matter) a fatal error?
>> Why is it error at all? How about just ignoring the fact?
> As suggested by Jeff, I made it ignore the error on ENOENT.
Looks good to me. Final acks please?
^ permalink raw reply
* Re: [PATCH] git-branch --with=commit
From: Junio C Hamano @ 2007-11-08 2:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711080008050.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> would it not be better to call it --containing=commit? Besides, I think
> that the opt_parse_with_commit() function would be better named
> opt_parse_commit() and be put into parse-options.[ch].
git-describe has "--contains" so that may be a better match. I
do not know the particular function is generic enough to be in
parse-options.
^ permalink raw reply
* Re: [PATCH MISC 1/1] Make gcc warning about empty if body go away.
From: Junio C Hamano @ 2007-11-08 2:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1194430832-6224-2-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> diff --git a/builtin-diff.c b/builtin-diff.c
> index f77352b..80392a8 100644
> --- a/builtin-diff.c
> +++ b/builtin-diff.c
> @@ -204,7 +204,7 @@ static void refresh_index_quietly(void)
> if (write_cache(fd, active_cache, active_nr) ||
> close(fd) ||
> commit_locked_index(lock_file))
> - ; /*
> + (void)0; /*
> * silently ignore it -- we haven't mucked
> * with the real index.
> */
Wouldn't this be much easier to read, by the way?
The point is that if we touched the active_cache, we try to
write it out and make it the index file for later users to use
by calling "commit", but we do not really care about the failure
from this sequence because it is done purely as an optimization.
The original code called three functions primarily for their
side effects, which is admittedly a bad style.
builtin-diff.c | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/builtin-diff.c b/builtin-diff.c
index f77352b..906c924 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -200,15 +200,9 @@ static void refresh_index_quietly(void)
discard_cache();
read_cache();
refresh_cache(REFRESH_QUIET|REFRESH_UNMERGED);
- if (active_cache_changed) {
- if (write_cache(fd, active_cache, active_nr) ||
- close(fd) ||
- commit_locked_index(lock_file))
- ; /*
- * silently ignore it -- we haven't mucked
- * with the real index.
- */
- }
+ if (active_cache_changed &&
+ !write_cache(fd, active_cache, active_nr) && !close(fd))
+ commit_locked_index(lock_file);
rollback_lock_file(lock_file);
}
^ permalink raw reply related
* Re: [PATCH MISC 1/1] Make gcc warning about empty if body go away.
From: Junio C Hamano @ 2007-11-08 1:52 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: gitster, git
In-Reply-To: <1194430832-6224-2-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> @@ -204,7 +204,7 @@ static void refresh_index_quietly(void)
> if (write_cache(fd, active_cache, active_nr) ||
> close(fd) ||
> commit_locked_index(lock_file))
> - ; /*
> + (void)0; /*
> * silently ignore it -- we haven't mucked
> * with the real index.
> */
Ok, will apply after reindenting a bit, and adding a quote to
the description that I could not parse on the first reading:
Make gcc warning about "empty if body" go away.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory
From: Johannes Schindelin @ 2007-11-08 1:00 UTC (permalink / raw)
To: David Symonds; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List, gitster
In-Reply-To: <ee77f5c20711071653x6a1fe8f8peb8ac2714941d2bb@mail.gmail.com>
Hi,
On Thu, 8 Nov 2007, David Symonds wrote:
> On Nov 8, 2007 11:12 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> > This looks a bit ugly because quote_crlf() is now also called
> > on the untracked files, which are not NUL terminated.
> >
> > Maybe someone has an idea how to do this more elegantly.
> >
> > builtin-runstatus.c | 1 +
> > wt-status.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
> > wt-status.h | 1 +
> > 3 files changed, 44 insertions(+), 8 deletions(-)
>
> Tested, and looks good.
>
> Now that I play with it, though, it seems that a few other bits of git
> need updating to handle relative paths okay:
>
> $ cd gitweb/test
> $ rm ../../wt-status.h
> [oops, what a silly thing to do -- better checkout the latest
> revision of it]
> $ git status
> # On branch next
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> #
> # deleted: ../../wt-status.h
> no changes added to commit (use "git add" and/or "git commit -a")
> $ git checkout HEAD ../../wt-status.h
> fatal: git-ls-files: cannot generate relative filenames containing '..'
> [grr....]
> $ cd ../..
> $ git checkout HEAD .
> [that works]
Well, now that I did all the hard work with git-status, I leave this easy
exercise for you ;-)
Ciao,
Dscho
^ permalink raw reply
* missing object on git-gc
From: Yossi Leybovich @ 2007-11-08 0:59 UTC (permalink / raw)
To: git
In-Reply-To: <6C2C79E72C305246B504CBA17B5500C902535D9C@mtlexch01.mtl.com>
I am running the git-gc tool over my repository and get the following error:
> git-gc
...
deltifying 3308 objects...
error: corrupt loose object '<sha1>'
fatal: object <sha1> cannot be read .
error: failed to run repack
when sha1 is 40 bytes number
Does any one know how I can solve thus issue?
Thanks
YOssi
^ permalink raw reply
* Re: [PATCH] hooks--update: allow deleting a tag through git push <remote> :<tag>
From: Junio C Hamano @ 2007-11-08 0:54 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071107103450.29849.qmail@c27a4ce40673ff.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> The update hook interpretes deleting a tag, no matter if annotated or not,
> through git push <remote> :<tag> as unannotated tag, and declines it by
> default:
> ...
> With this patch deleting a tag is allowed unconditionally, just as
> deleting a branch.
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> templates/hooks--update | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
Since you are allowing deletion for anything, wouldn't this be
much simpler, I wonder...
---
templates/hooks--update | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--update b/templates/hooks--update
index d8c7626..e12904a 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -41,9 +41,9 @@ if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file t
fi
# --- Check types
-# if $newrev is 0000...0000, it's a commit to delete a branch
+# if $newrev is 0000...0000, it's a commit to delete a ref.
if [ "$newrev" = "0000000000000000000000000000000000000000" ]; then
- newrev_type=commit
+ exit 0 ;# allow anything to be deleted
else
newrev_type=$(git-cat-file -t $newrev)
fi
^ permalink raw reply related
* Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory
From: David Symonds @ 2007-11-08 0:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List, gitster
In-Reply-To: <Pine.LNX.4.64.0711080011170.4362@racer.site>
On Nov 8, 2007 11:12 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> This looks a bit ugly because quote_crlf() is now also called
> on the untracked files, which are not NUL terminated.
>
> Maybe someone has an idea how to do this more elegantly.
>
> builtin-runstatus.c | 1 +
> wt-status.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
> wt-status.h | 1 +
> 3 files changed, 44 insertions(+), 8 deletions(-)
Tested, and looks good.
Now that I play with it, though, it seems that a few other bits of git
need updating to handle relative paths okay:
$ cd gitweb/test
$ rm ../../wt-status.h
[oops, what a silly thing to do -- better checkout the latest
revision of it]
$ git status
# On branch next
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: ../../wt-status.h
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout HEAD ../../wt-status.h
fatal: git-ls-files: cannot generate relative filenames containing '..'
[grr....]
$ cd ../..
$ git checkout HEAD .
[that works]
Dave.
^ permalink raw reply
* [PATCH] Re: git-svn fetch doesn't like spaces in branch names
From: Michael J. Cohen @ 2007-11-08 0:53 UTC (permalink / raw)
To: Michael J. Cohen; +Cc: Git Mailing List
In-Reply-To: <654A4D1D-712F-4978-9812-E8FA411FAE0D@mac.com>
> mini:TextMateBundles mjc$ git-svn fetch
> Found possible branch point: http://macromates.com/svn/Bundles/trunk/Tools/Dialog
> PlugIn => http://macromates.com/svn/Bundles/branches/Dialog PlugIn
> Completion Menu, 8089
> Initializing parent: Dialog PlugIn Completion Menu@8089
> Bad URL passed to RA layer: Malformed URL for repository at /opt/
> local/bin/git-svn line 1607
>
> looks like that might need to be %20 ?
Hacky, but it works.
Signed-off-by: Michael J. Cohen <mjc@cruiseplanners.com>
diff --git a/git-svn.perl b/git-svn.perl
index dd93e32..5dc3b9c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1976,6 +1976,7 @@ sub find_parent_branch {
my $r = $i->{copyfrom_rev};
my $repos_root = $self->ra->{repos_root};
my $url = $self->ra->{url};
+ $branch_from =~ s@([\s])@sprintf("%%%02X", ord($1))@seg;
my $new_url = $repos_root . $branch_from;
print STDERR "Found possible branch point: ",
"$new_url => ", $self->full_url, ", $r\n";
--
1.5.3.5.1590.gfadfad-dirty
^ permalink raw reply related
* Re: Inconsistencies with git log
From: Brian Gernhardt @ 2007-11-08 0:52 UTC (permalink / raw)
To: David Symonds; +Cc: Johannes Schindelin, Jon Smirl, Git Mailing List
In-Reply-To: <ee77f5c20711071614g7f0b9f84oc419590a586e16b7@mail.gmail.com>
On Nov 7, 2007, at 7:14 PM, David Symonds wrote:
> On Nov 8, 2007 11:09 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de
> > wrote:
>> Too late ;-)
>
> I see that you're revolting against relative paths in git-log; I agree
> with you on that. I'm proposing changing the output to git-status so
> that it produces relative paths
Johannes was referring to the fact that he already produced that
patches for it. :-)
~~ Brian
^ permalink raw reply
* [PATCH v2] Deprecate git-lost-found
From: Johannes Schindelin @ 2007-11-08 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk998u6r.fsf@gitster.siamese.dyndns.org>
"git fsck" learnt the option "--lost-found" in v1.5.3-rc0~5, to make
"git lost-found" obsolete. It is time to deprecate "git lost-found".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/RelNotes-1.5.4.txt | 3 +++
Documentation/git-lost-found.txt | 4 ++++
git-lost-found.sh | 2 ++
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index 133fa64..65dd1b0 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -46,6 +46,9 @@ Updates since v1.5.3
* Various Perforce importer updates.
+ * git-lost-found was deprecated in favor of git-fsck's --lost-found
+ option.
+
Fixes since v1.5.3
------------------
diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt
index bc73911..7f808fc 100644
--- a/Documentation/git-lost-found.txt
+++ b/Documentation/git-lost-found.txt
@@ -11,6 +11,10 @@ SYNOPSIS
DESCRIPTION
-----------
+
+*NOTE*: this command is deprecated. Use gitlink:git-fsck[1] with
+the option '--lost-found' instead.
+
Finds dangling commits and tags from the object database, and
creates refs to them in the .git/lost-found/ directory. Commits and
tags that dereference to commits are stored in .git/lost-found/commit,
diff --git a/git-lost-found.sh b/git-lost-found.sh
index a5a32e7..9cedaf8 100755
--- a/git-lost-found.sh
+++ b/git-lost-found.sh
@@ -5,6 +5,8 @@ SUBDIRECTORY_OK='Yes'
OPTIONS_SPEC=
. git-sh-setup
+echo "WARNING: '$0' is deprecated in favor of 'git fsck --lost-found'" >&2
+
if [ "$#" != "0" ]
then
usage
--
1.5.3.5.1597.g7191
^ permalink raw reply related
* Re: [PATCH v4] Add Documentation/CodingGuidelines
From: Junio C Hamano @ 2007-11-08 0:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Robin Rosenberg, Andreas Ericsson, Ralf Wildenhues, git
In-Reply-To: <Pine.LNX.4.64.0711080033080.4362@racer.site>
Ok, will queue this for 'maint' ;-).
^ permalink raw reply
* Re: [PATCH] Deprecate git-lost-found
From: Johannes Schindelin @ 2007-11-08 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk998u6r.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 7 Nov 2007, Junio C Hamano wrote:
> Makes sort of sense. Add deprecation notice to Documentation/
> as well, please.
Of course. Will resend in a minute.
Ciao,
Dscho
^ permalink raw reply
* Re: Inconsistencies with git log
From: Johannes Schindelin @ 2007-11-08 0:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711071609t3e5412f1mf02e501b2d820bb3@mail.gmail.com>
Hi,
On Wed, 7 Nov 2007, Jon Smirl wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > It is consistent, when you realise that the path arguments are interpreted
> > relative to the project root.
>
> Then why doesn't this work?
>
> jonsmirl@terra:~/mpc5200b$ git log Documentation
> all the log for Documentation....
> jonsmirl@terra:~/mpc5200b$ cd Documentation
> jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
> fatal: ambiguous argument 'Documentation': unknown revision or path
> not in the working tree.
> Use '--' to separate paths from revisions
Because you are in the subdirectory Documentation/, relative to the
project root. So when you say "Documentation", it tries to find the
file/directory Documentation/Documentation.
Therefore, just say "git log ." and you will get what you want.
Ciao,
Dscho
^ 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