* Re: [PATCH] Fix config lockfile handling.
From: Junio C Hamano @ 2007-12-14 21:57 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git
In-Reply-To: <1197665998-32386-2-git-send-email-krh@redhat.com>
Kristian Høgsberg <krh@redhat.com> writes:
> When we commit or roll back the lock file the fd is automatically closed,
> so don't do that again.
With your change, we do not check the return status from close(2)
anymore, which means that we may have run out of diskspace without
noticing and renamed the incomplete file into the real place. Oops?
At least the original code wouldn't have had that problem.
The right fix in the longer term would be to check the return value from
the close(2) in commit_lock_file(), but it currently does not check on
purpose, because the callers may have already closed the fd.
^ permalink raw reply
* [RFE/PATCH] git-fetch-rebase
From: José Fonseca @ 2007-12-14 22:12 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
Hi,
For those who use git as a better centralized SCM, it became a common
practice to do git-fetch + git-rebase instead of just git-pull, so that
the history is linear, instead of being full of tiny merges.
However, there is no git command for such common procedure (at least
AFAIK). Attached is a variation of the git-pull porcelain (taken from
git version debian.1.5.3.7.1-dirty) that instead of doing git-fetch +
git-merge, it does git-fetch + git-rebase.
I've been using this git-fetch-rebase script frequently, and it really
boosts my productivity (I use it when updating from the main repository,
and before pushing my changes to the main repository).
I'd like see this script, or an equivalent command, included the git
distribution.
Cheers,
José Fonseca
[-- Attachment #2: git-fetch-rebase --]
[-- Type: text/plain, Size: 2564 bytes --]
#!/bin/sh
#
# Copyright (c) 2007 José Fonseca
# Copyright (c) 2005 Junio C Hamano
#
# Fetch a remote ref and rebase the current HEAD on top of it.
USAGE='[-s strategy]... [<fetch-options>] <repo> <head>'
LONG_USAGE='Fetch a remote ref and rebase the current HEAD onto it.'
SUBDIRECTORY_OK=Yes
. git-sh-setup
set_reflog_action "fetch-rebase $*"
require_work_tree
cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
strategy_args=
while :
do
case "$1" in
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
case "$#,$1" in
*,*=*)
strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
1,*)
usage ;;
*)
strategy="$2"
shift ;;
esac
strategy_args="${strategy_args}-s $strategy "
;;
-h|--h|--he|--hel|--help)
usage
;;
*)
# Pass thru anything that may be meant for fetch.
break
;;
esac
shift
done
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
git-fetch "$@" || exit 1
merge_head=$(sed -e '/ not-for-merge /d' \
-e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
tr '\012' ' ')
case "$merge_head" in
'')
curr_branch=$(git symbolic-ref -q HEAD)
case $? in
0) ;;
1) echo >&2 "You are not currently on a branch; you must explicitly"
echo >&2 "specify which branch you wish to rebase onto:"
echo >&2 " git fetch-rebase <remote> <branch>"
exit 1;;
*) exit $?;;
esac
curr_branch=${curr_branch#refs/heads/}
echo >&2 "You asked me to rebase without telling me which branch you"
echo >&2 "want to rebase, and 'branch.${curr_branch}.merge' in"
echo >&2 "your configuration file does not tell me either. Please"
echo >&2 "name which branch you want to rebase on the command line and"
echo >&2 "try again (e.g. 'git fetch-rebase <repository> <refspec>')."
echo >&2 "See git-pull(1) for details on the refspec."
echo >&2
echo >&2 "If you often rebase to the same branch, you may want to"
echo >&2 "configure the following variables in your configuration"
echo >&2 "file:"
echo >&2
echo >&2 " branch.${curr_branch}.remote = <nickname>"
echo >&2 " branch.${curr_branch}.merge = <remote-ref>"
echo >&2 " remote.<nickname>.url = <url>"
echo >&2 " remote.<nickname>.fetch = <refspec>"
echo >&2
echo >&2 "See git-config(1) for details."
exit 1
;;
?*' '?*)
echo >&2 "Cannot rebase onto multiple branches"
exit 1
;;
esac
if test -z "$orig_head"
then
echo >&2 "Cannot rebase empty head"
exit 1
fi
exec git-rebase $strategy_args $merge_head
[-- Attachment #3: git-pull_to_git-fetch-rebase.diff --]
[-- Type: text/x-patch, Size: 4436 bytes --]
--- /usr/bin/git-pull 2007-12-04 09:46:21.000000000 +0000
+++ git-fetch-rebase 2007-12-13 12:38:52.000000000 +0000
@@ -1,34 +1,25 @@
#!/bin/sh
#
+# Copyright (c) 2007 José Fonseca
# Copyright (c) 2005 Junio C Hamano
#
-# Fetch one or more remote refs and merge it/them into the current HEAD.
+# Fetch a remote ref and rebase the current HEAD on top of it.
-USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [<fetch-options>] <repo> <head>...'
-LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
+USAGE='[-s strategy]... [<fetch-options>] <repo> <head>'
+LONG_USAGE='Fetch a remote ref and rebase the current HEAD onto it.'
SUBDIRECTORY_OK=Yes
. git-sh-setup
-set_reflog_action "pull $*"
+set_reflog_action "fetch-rebase $*"
require_work_tree
cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_summary= no_commit= squash=
+strategy_args=
while :
do
case "$1" in
- -n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
- --no-summa|--no-summar|--no-summary)
- no_summary=-n ;;
- --summary)
- no_summary=$1
- ;;
- --no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
- no_commit=--no-commit ;;
- --sq|--squ|--squa|--squas|--squash)
- squash=--squash ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -55,30 +46,7 @@
done
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git-fetch --update-head-ok "$@" || exit 1
-
-curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
-if test "$curr_head" != "$orig_head"
-then
- # The fetch involved updating the current branch.
-
- # The working tree and the index file is still based on the
- # $orig_head commit, but we are merging into $curr_head.
- # First update the working tree to match $curr_head.
-
- echo >&2 "Warning: fetch updated the current branch head."
- echo >&2 "Warning: fast forwarding your working tree from"
- echo >&2 "Warning: commit $orig_head."
- git update-index --refresh 2>/dev/null
- git read-tree -u -m "$orig_head" "$curr_head" ||
- die 'Cannot fast-forward your working tree.
-After making sure that you saved anything precious from
-$ git diff '$orig_head'
-output, run
-$ git reset --hard
-to recover.'
-
-fi
+git-fetch "$@" || exit 1
merge_head=$(sed -e '/ not-for-merge /d' \
-e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
@@ -90,21 +58,21 @@
case $? in
0) ;;
1) echo >&2 "You are not currently on a branch; you must explicitly"
- echo >&2 "specify which branch you wish to merge:"
- echo >&2 " git pull <remote> <branch>"
+ echo >&2 "specify which branch you wish to rebase onto:"
+ echo >&2 " git fetch-rebase <remote> <branch>"
exit 1;;
*) exit $?;;
esac
curr_branch=${curr_branch#refs/heads/}
- echo >&2 "You asked me to pull without telling me which branch you"
- echo >&2 "want to merge with, and 'branch.${curr_branch}.merge' in"
+ echo >&2 "You asked me to rebase without telling me which branch you"
+ echo >&2 "want to rebase, and 'branch.${curr_branch}.merge' in"
echo >&2 "your configuration file does not tell me either. Please"
- echo >&2 "name which branch you want to merge on the command line and"
- echo >&2 "try again (e.g. 'git pull <repository> <refspec>')."
+ echo >&2 "name which branch you want to rebase on the command line and"
+ echo >&2 "try again (e.g. 'git fetch-rebase <repository> <refspec>')."
echo >&2 "See git-pull(1) for details on the refspec."
echo >&2
- echo >&2 "If you often merge with the same branch, you may want to"
+ echo >&2 "If you often rebase to the same branch, you may want to"
echo >&2 "configure the following variables in your configuration"
echo >&2 "file:"
echo >&2
@@ -117,21 +85,15 @@
exit 1
;;
?*' '?*)
- if test -z "$orig_head"
- then
- echo >&2 "Cannot merge multiple branches into empty head"
- exit 1
- fi
+ echo >&2 "Cannot rebase onto multiple branches"
+ exit 1
;;
esac
if test -z "$orig_head"
then
- git update-ref -m "initial pull" HEAD $merge_head "" &&
- git read-tree --reset -u HEAD || exit 1
- exit
+ echo >&2 "Cannot rebase empty head"
+ exit 1
fi
-merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-exec git-merge $no_summary $no_commit $squash $strategy_args \
- "$merge_name" HEAD $merge_head
+exec git-rebase $strategy_args $merge_head
^ permalink raw reply
* Re: [PATCH 2/2] Fix random sha1 in error message in http-fetch and http-push
From: Junio C Hamano @ 2007-12-14 22:17 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1197667081-9909-2-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> Please note that this is already fixed in my strbuf patch for these files,
> which had been applied in pu, but it seems to have disappeared from pu's
> history. This also means the strbuf patch conflicts with this one. Please
> tell me if you want a new strbuf patch made after this one.
The branch 'pu' almost always rewind and gets rebuilt from the tip of
'next'. Since I am more worried about master and next, even more so
than usual these days, most of the backburnered topics are not even in
'pu' but I still keep tips of them not to lose (they are found in
'offcuts').
Give me a few days to get back to your series. I think it is a series
of good clean-up patches, (I just read [1/2] which was trivially correct
although I am not sure if it is the optimum fix to sprinkle free(url) to
everywhere we have return), but I just haven't got around to them.
^ permalink raw reply
* Re: testsuite failures in mainline...
From: David Miller @ 2007-12-14 22:24 UTC (permalink / raw)
To: raa.lkml; +Cc: gitster, git
In-Reply-To: <20071214214533.GA4943@steel.home>
From: Alex Riesen <raa.lkml@gmail.com>
Date: Fri, 14 Dec 2007 22:45:33 +0100
> David Miller, Fri, Dec 14, 2007 20:17:36 +0100:
> > ++ git show-ref -q refs/remotes/local/master
> > ++ git branch my3 local/master
> > fatal: Out of memory, malloc failed
>
> Something unusual about the system? Like a malloc debugger in
> LD_PRELOAD configuration?
No, I'm not doing anything fancy like that.
> Maybe you could retry with a little bit instrumentation?
> (The program last failed (git-branch) is normally very benign...)
>
> Something like this:
Here is the output from the debugging patch:
++ git branch my3 local/master
fatal: Out of memory, malloc(4293963242) at git-compat-util.h:256 failed
This bogus size value in hex is 0xfff0adea, FWIW.
I added similar diags to xmemdupz() and xstrndup() and that gives us:
fatal: Out of memory, xstrndup(0x103ebf:4293902657:4293902657) at remote.c:112 failed
(the first three values are xstrndup() vars 'str', 'len', and
the computed second argument to xmemdupz).
That bogus length is being generated via the length argument
passed to make_branch() by handle_config() in remote.c:
if (!prefixcmp(key, "branch.")) {
name = key + 7;
subkey = strrchr(name, '.');
branch = make_branch(name, subkey - name);
What if 'subkey' is NULL? I bet that's what happening here.
I added a debugging check for this and indeed, subkey is NULL
in handle_condig() and that's why 'subkey - name' generates that
bogus negative length.
The string 'key' is "branch.autosetupmerge" in this case.
^ permalink raw reply
* Re: gitk graph routing problem
From: Alex Riesen @ 2007-12-14 22:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
In-Reply-To: <18271.3714.731136.272491@cargo.ozlabs.ibm.com>
Paul Mackerras, Tue, Dec 11, 2007 23:26:10 +0100:
> Alex Riesen writes:
>
> > To reproduce, try running in git repo:
> >
> > gitk 02f630448e5d48e..06ea6ba9cf46ef5
> >
> > Than go some pages (around 5) forward. You should notice system load
> > going up rapidly. Now try paging back - and graph starts stretching
> > to the right, to the point nothing fits on the screen anymore.
>
> I finally got back to look at this. The problem is not so much the
> layout algorithm per se as the fact that I haven't worked out a good
> way to pack lots of downward-pointing arrows in without using up
> arbitrarily large amounts of horizontal space. You have managed to
> find an example where just about every commit is a merge needing one
> or more downward-pointing arrows.
>
> Incidentally, gitk from the dev branch of my gitk.git repo does much
> better on this example, since it is able to hoist the open-circle
> (excluded) commits up to the row below their merge children, which
> looks much nicer.
could you point to a specific commit where it does that?
Because the current head of dev branch at //git.kernel.org/pub/scm/gitk/gitk
(3de07118f0993e6f7bc7ce02276751795d80b877) does not look any
different and still almost locks up drawing all the horizontal lines.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-14 22:34 UTC (permalink / raw)
To: Joel Becker; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071214215206.GB7300@mail.oracle.com>
On Fri, 14 Dec 2007, Joel Becker wrote:
> On Fri, Dec 14, 2007 at 08:38:51AM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Jakub Narebski wrote:
> > > Which means what? Local clone with shortcut (hardlinking and remotes)?
> > > Dumb protocols (http, ftp, rsync)?
> >
> > Right, or simply shared repo over NFS or the like.
> >
> > The 1.5.5 release notes will contain a note reminding people to set the
> > corresponding config variables if they wish to retain the legacy
> > behaviors.
>
> We've seen that release notes are a poor way to communicate
> this. What will happen to a 1.4.4 user when they try to access the
> repository? Corruption, cryptic error message, or clean "this repo is
> not compatible" message?
There won't be any corruption.
In the best case there will be a message along "x is not supported by
this version of Git -- please consider upgrading". In the worst case
it'll say "x is bad".
But you know what? repositories with the change affecting 1.4.4 users
are _already_ out there and no one complained recently. Anyone pushing
changes over the native Git protocol is already using deltabaseoffset as
the native protocol negociate that capability in its handshake, and
these days we keep packs as is on the receiving side when they're large
enough.
Nicolas
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Joel Becker @ 2007-12-14 22:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712141724260.8467@xanadu.home>
On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Joel Becker wrote:
> > We've seen that release notes are a poor way to communicate
> > this. What will happen to a 1.4.4 user when they try to access the
> > repository? Corruption, cryptic error message, or clean "this repo is
> > not compatible" message?
>
> There won't be any corruption.
>
> In the best case there will be a message along "x is not supported by
> this version of Git -- please consider upgrading". In the worst case
> it'll say "x is bad".
That would be excellent, especially the former message.
> But you know what? repositories with the change affecting 1.4.4 users
> are _already_ out there and no one complained recently. Anyone pushing
I did, as did people I work with. It's on git-list, even. I'm
pretty sure it corrupted too.
Joel
--
"Practice random acts of kindness and senseless acts of beauty."
Oh, and don't forget where your towel is.
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-14 22:46 UTC (permalink / raw)
To: Joel Becker; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071214223957.GC7300@mail.oracle.com>
On Fri, 14 Dec 2007, Joel Becker wrote:
> On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > But you know what? repositories with the change affecting 1.4.4 users
> > are _already_ out there and no one complained recently. Anyone pushing
>
> I did, as did people I work with. It's on git-list, even. I'm
> pretty sure it corrupted too.
Could you please give me a reference to such message, so to verify that
we're actually talking about the same thing?
Nicolas
^ permalink raw reply
* Re: testsuite failures in mainline...
From: Junio C Hamano @ 2007-12-14 23:18 UTC (permalink / raw)
To: David Miller; +Cc: raa.lkml, git
In-Reply-To: <20071214.142448.52660507.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> if (!prefixcmp(key, "branch.")) {
> name = key + 7;
> subkey = strrchr(name, '.');
> branch = make_branch(name, subkey - name);
>
> What if 'subkey' is NULL? I bet that's what happening here.
Wow, good eyes.
It makes me wonder what my C library has been returning during the
tests...
---
remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/remote.c b/remote.c
index 3fb0f99..0e00680 100644
--- a/remote.c
+++ b/remote.c
@@ -220,11 +220,11 @@ static int handle_config(const char *key, const char *value)
if (!prefixcmp(key, "branch.")) {
name = key + 7;
subkey = strrchr(name, '.');
- branch = make_branch(name, subkey - name);
if (!subkey)
return 0;
if (!value)
return 0;
+ branch = make_branch(name, subkey - name);
if (!strcmp(subkey, ".remote")) {
branch->remote_name = xstrdup(value);
if (branch == current_branch)
^ permalink raw reply related
* Re: [RFE/PATCH] git-fetch-rebase
From: Junio C Hamano @ 2007-12-14 23:50 UTC (permalink / raw)
To: José Fonseca; +Cc: git
In-Reply-To: <1197670351.21175.33.camel@localhost>
José Fonseca <jrfonseca@tungstengraphics.com> writes:
> For those who use git as a better centralized SCM, it became a common
> practice to do git-fetch + git-rebase instead of just git-pull, so that
> the history is linear, instead of being full of tiny merges.
"git pull --rebase"?
^ permalink raw reply
* Re: testsuite failures in mainline...
From: David Miller @ 2007-12-15 0:08 UTC (permalink / raw)
To: gitster; +Cc: raa.lkml, git
In-Reply-To: <7v7ijgq311.fsf@gitster.siamese.dyndns.org>
From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 14 Dec 2007 15:18:02 -0800
> It makes me wonder what my C library has been returning during the
> tests...
If the 'name' string is high enough in the address space, the
'NULL - name' is still small enough to keep malloc() from
failing.
It might be neat to defeat bugs like this by making a
pointer_diff(a,b) macro or similar, that abort()'s when
one of the arguments is NULL. Otherwise these bugs are
so hard to find.
I tested your patch and that part of the testsuite passes now.
It now fails on t9301-fast-export.sh
+ eval '
MASTER=$(git rev-parse --verify master) &&
REIN=$(git rev-parse --verify rein) &&
WER=$(git rev-parse --verify wer) &&
MUSS=$(git rev-parse --verify muss) &&
mkdir new &&
git --git-dir=new/.git init &&
git fast-export --all |
(cd new &&
git fast-import &&
test $MASTER = $(git rev-parse --verify refs/heads/master) &&
test $REIN = $(git rev-parse --verify refs/tags/rein) &&
test $WER = $(git rev-parse --verify refs/heads/wer) &&
test $MUSS = $(git rev-parse --verify refs/tags/muss))
'
+++ git rev-parse --verify master
++ MASTER=e529bca54909ee82f6ed442ef855ff541aec034c
+++ git rev-parse --verify rein
++ REIN=e529bca54909ee82f6ed442ef855ff541aec034c
+++ git rev-parse --verify wer
++ WER=ce754ded7a378a51278b2ff76d6898ec20093068
+++ git rev-parse --verify muss
++ MUSS=d85ef2305117d94969d4990d3c752752d4719be1
++ mkdir new
++ git --git-dir=new/.git init
Initialized empty Git repository in new/.git/
++ git fast-export --all
++ cd new
++ git fast-import
./test-lib.sh: line 194: 17409 Bus error (core dumped) git fast-import
This usually indicates an unaligned memory access on sparc,
which is where I'm running this.
The problem is the pool allocator in fast-import.c, it aligned objects
on the size of a pointer. But this is insufficient, it needs to be at
least "uintmax_t" aligned.
Also, mem_pool->space needs to be suitably aligned for a uintmax_t
as well.
The following patch fixes the bug, and together with your patch all
test cases now pass for me on sparc.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/fast-import.c b/fast-import.c
index 98c2bd5..4646c05 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -196,7 +196,7 @@ struct mem_pool
struct mem_pool *next_pool;
char *next_free;
char *end;
- char space[FLEX_ARRAY]; /* more */
+ uintmax_t space[FLEX_ARRAY]; /* more */
};
struct atom_str
@@ -534,15 +534,15 @@ static void *pool_alloc(size_t len)
total_allocd += sizeof(struct mem_pool) + mem_pool_alloc;
p = xmalloc(sizeof(struct mem_pool) + mem_pool_alloc);
p->next_pool = mem_pool;
- p->next_free = p->space;
+ p->next_free = (char *) p->space;
p->end = p->next_free + mem_pool_alloc;
mem_pool = p;
}
r = p->next_free;
- /* round out to a pointer alignment */
- if (len & (sizeof(void*) - 1))
- len += sizeof(void*) - (len & (sizeof(void*) - 1));
+ /* round out to a 'uintmax_t' alignment */
+ if (len & (sizeof(uintmax_t) - 1))
+ len += sizeof(uintmax_t) - (len & (sizeof(uintmax_t) - 1));
p->next_free += len;
return r;
}
^ permalink raw reply related
* Re: Git and GCC
From: Nix @ 2007-12-15 0:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: J.C. Pizarro, Linus Torvalds, David Miller, gcc, git
In-Reply-To: <Pine.LNX.4.64.0712081223070.27959@racer.site>
On 8 Dec 2007, Johannes Schindelin said:
> Hi,
>
> On Sat, 8 Dec 2007, J.C. Pizarro wrote:
>
>> On 2007/12/07, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
>>
>> > SHA1 is almost totally insignificant on x86. It hardly shows up. But
>> > we have a good optimized version there.
>>
>> If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds)
>> that it's faster than SHA1? And to optimize still more it with SIMD
>> instructions in kernelspace and userland.
>
> He said SHA-1 is insignificant.
Actually davem also said it *is* significant on SPARC. But of course
J. C. Pizarro's suggested solution won't work because you can't just go
around replacing SHA-1 in git with something else :) you could *add* new
hashing methods, but you couldn't avoid SHA-1, and adding a new hashing
method would bloat every object and every hash in objects like commits
with an indication of which hashing method was in use.
(But you know this.)
>> 1. "Don't compress this repo but compact this uncompressed repo
>> using minimal spanning forest and deltas"
... and then you do a git-gc. Oops, now what?
... or perhaps you want to look something up in the pack. Now you have to
unpack a large hunk of the whole damn thing.
>> 2. "After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before
>> burning it to DVD for backup reasons or before replicating it to
>> internet".
>
> Patches? ;-)
Replicating a pack to the internet is almost invariably replicating
*parts* of a pack anyway, which reduces to the problem with option 1
above...
--
`The rest is a tale of post and counter-post.' --- Ian Rawlings
describes USENET
^ permalink raw reply
* Re: [PATCH] git-svn: handle our top-level path is deleted and later re-added
From: cho @ 2007-12-15 0:24 UTC (permalink / raw)
To: git
In-Reply-To: <20071214163909.GA18300@soma>
Thanks, this fixes a problem I had reported previously:
http://permalink.gmane.org/gmane.comp.version-control.git/61516
I'm not sure how I get to keep the git repository (branches) I previously
had, but it's not too bad.
^ permalink raw reply
* Re: [RFE/PATCH] git-fetch-rebase
From: José Fonseca @ 2007-12-15 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7bwomza.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-12-14 at 15:50 -0800, Junio C Hamano wrote:
> José Fonseca <jrfonseca@tungstengraphics.com> writes:
>
> > For those who use git as a better centralized SCM, it became a common
> > practice to do git-fetch + git-rebase instead of just git-pull, so that
> > the history is linear, instead of being full of tiny merges.
>
> "git pull --rebase"?
I didn't find it before. It seems a very recent functionality. Anyway,
I'm glad it exists now.
Cheers,
José Fonseca
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Joel Becker @ 2007-12-15 0:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712141744460.8467@xanadu.home>
On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Joel Becker wrote:
>
> > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > But you know what? repositories with the change affecting 1.4.4 users
> > > are _already_ out there and no one complained recently. Anyone pushing
> >
> > I did, as did people I work with. It's on git-list, even. I'm
> > pretty sure it corrupted too.
>
> Could you please give me a reference to such message, so to verify that
> we're actually talking about the same thing?
The relevant message is:
Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
See the paragraphs at the bottom. The thread, started by me, begins
with:
Message-ID: <20070910205429.GE27837@tasint.org>
Joel
--
"You must remember this:
A kiss is just a kiss,
A sigh is just a sigh.
The fundamental rules apply
As time goes by."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-15 1:08 UTC (permalink / raw)
To: Joel Becker; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071215004230.GF7300@mail.oracle.com>
On Fri, 14 Dec 2007, Joel Becker wrote:
> On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Joel Becker wrote:
> >
> > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > > But you know what? repositories with the change affecting 1.4.4 users
> > > > are _already_ out there and no one complained recently. Anyone pushing
> > >
> > > I did, as did people I work with. It's on git-list, even. I'm
> > > pretty sure it corrupted too.
> >
> > Could you please give me a reference to such message, so to verify that
> > we're actually talking about the same thing?
>
> The relevant message is:
>
> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
>
> See the paragraphs at the bottom. The thread, started by me, begins
> with:
>
> Message-ID: <20070910205429.GE27837@tasint.org>
I don't have such emails in my mail folders anymore.
Nicolas
^ permalink raw reply
* Re: testsuite failures in mainline...
From: Johannes Schindelin @ 2007-12-15 1:18 UTC (permalink / raw)
To: David Miller; +Cc: gitster, raa.lkml, git
In-Reply-To: <20071214.160845.185161708.davem@davemloft.net>
Hi,
On Fri, 14 Dec 2007, David Miller wrote:
> - char space[FLEX_ARRAY]; /* more */
> + uintmax_t space[FLEX_ARRAY]; /* more */
Usually, a much better idea is to use
union {
char cp[FLEX_ARRAY];
uintmax_t up[FLEX_ARRAY];
}
because that is exactly the reason union was invented for.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Johannes Schindelin @ 2007-12-15 1:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712142004480.8467@xanadu.home>
Hi,
On Fri, 14 Dec 2007, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Joel Becker wrote:
>
> > On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> > > On Fri, 14 Dec 2007, Joel Becker wrote:
> > >
> > > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > > > But you know what? repositories with the change affecting 1.4.4 users
> > > > > are _already_ out there and no one complained recently. Anyone pushing
> > > >
> > > > I did, as did people I work with. It's on git-list, even. I'm
> > > > pretty sure it corrupted too.
> > >
> > > Could you please give me a reference to such message, so to verify that
> > > we're actually talking about the same thing?
> >
> > The relevant message is:
> >
> > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> >
> > See the paragraphs at the bottom. The thread, started by me, begins
> > with:
> >
> > Message-ID: <20070910205429.GE27837@tasint.org>
>
> I don't have such emails in my mail folders anymore.
GMane does not seem to have it, either:
http://mid.gmane.org/20070910205429.GE27837@tasint.org
returns "No such article".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-15 1:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999999.0712142004480.8467@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Fri, 14 Dec 2007, Joel Becker wrote:
>
>> > Could you please give me a reference to such message, so to verify that
>> > we're actually talking about the same thing?
>>
>> The relevant message is:
>>
>> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
>>
>> See the paragraphs at the bottom. The thread, started by me, begins
>> with:
>>
>> Message-ID: <20070910205429.GE27837@tasint.org>
>
> I don't have such emails in my mail folders anymore.
-- >8 --
Date: Mon, 10 Sep 2007 13:54:29 -0700
From: Joel Becker <Joel.Becker@oracle.com>
To: git@vger.kernel.org
Subject: Remote branches and better documentation
Message-ID: <20070910205429.GE27837@tasint.org>
Sender: git-owner@vger.kernel.org
Junio et al,
Git is a fast moving target, so some of this obviously needs a
grain of salt. However, I'd like to make a couple of humble suggestions
and ask one simple question.
First, the question: Is there a syntax to git clone that
creates the old-style branches? That is, you get all the branches
locally, for people that either haven't learned "git branch -r" or have
existing scripts that expect the branch to exist? I can't find anything
in the git clone manpage.
The suggestions are pretty simple. First, when behavior is
changed invisibly (as the remote branch stuff was), can we note it in
the documentation? I don't mean the ChangeLog, I mean the manpage. I
personally already knew about "branch -r" because I read this list. A
coworker of mine, who just uses git, spent an hour trying to find his
branches after a clone with git 1.5. He thought his clone had failed.
He read the manpage, and there was no big "Hey, those of you used to
the old behavior, it changed!". The single sentence about "remote
tracking branches" clearly isn't enough for folks that don't follow the
development side. If we're going to take the liberty of changing
expected behavior silently, we should be giving it its own section in
the manpage.
The second suggestion is related. When an invisible change has
made the repository incompatible with older versions, we should make
sure that things behave. We had some repositories cloned via 1.4.2. Do
some work with 1.5.0.6 (on a different machine), then go back to the
machine with 1.4.2, and 1.4.2 doesn't work. In fact, it can mess things
up. He was doing simple things: pull from Linus, switch branches, etc.
If this is going to be incompatible, then the newer stuff should at
least warn about it, if not outright prevent 1.4 from running.
These sorts of things make fast-moving changes workable.
Joel
-- >8 --
Date: Mon, 10 Sep 2007 19:27:34 -0700
Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
Sender: git-owner@vger.kernel.org
Joel Becker <Joel.Becker@oracle.com> writes:
> On Tue, Sep 11, 2007 at 02:05:34AM +0200, Wincent Colaiuta wrote:
>> But that's precisely the group release notes are for; existing users who
>> need to be informed of any changes to the way things work.
>
> No one reads the changelogs of 100 packages updated via "yum
> update". Heck, they don't even see the list of packages. They just
> switch to a different desktop while it runs.
Distros are not something under my control, so I cannot help you
much there.
> Then there's the user that doesn't administer the system. They
> don't even know the version changed. It Just Breaks, and they don't
> know why.
That's a valid concern, but I am not sure how you would want to
address that issue. Design constraints are:
- you cannot change the old software that is not updated on the
user's box;
- you cannot afford to write something to the repository to
mark the latest version that mucked with the repository every
time any operation happens;
We _could_ check presence of $HOME/.knows-git-version-X.Y.Z file
every time we run (that's just a single stat(2) call that cannot
be too expensive) and if there isn't one, ask the user if he has
read the release notes and understood the backward compatibility
issues if there is any, and refuse to run until getting a
satisfactory answer.
But I personally do not think that would be an improvement.
After reviewing Release Notes for v1.5.0, I do not think we
could have done much better, unfortunately.
As of git v1.5.0 there are some optional features that changes
the repository to allow data to be stored and transferred more
efficiently. These features are not enabled by default, as they
will make the repository unusable with older versions of git.
Specifically, the available options are:
- There is a configuration variable core.legacyheaders that
changes the format of loose objects so that they are more
efficient to pack and to send out of the repository over git
native protocol, since v1.4.2. However, loose objects
written in the new format cannot be read by git older than
that version; people fetching from your repository using
older clients over dumb transports (e.g. http) using older
versions of git will also be affected.
To let git use the new loose object format, you have to
set core.legacyheaders to false.
- Since v1.4.3, configuration repack.usedeltabaseoffset allows
packfile to be created in more space efficient format, which
cannot be read by git older than that version.
To let git use the new format for packfiles, you have to
set repack.usedeltabaseoffset to true.
The above two new features are not enabled by default and you
have to explicitly ask for them, because they make repositories
unreadable by older versions of git, and in v1.5.0 we still do
not enable them by default for the same reason. We will change
this default probably 1 year after 1.4.2's release, when it is
reasonable to expect everybody to have new enough version of
git.
- 'git pack-refs' appeared in v1.4.4; this command allows tags
to be accessed much more efficiently than the traditional
'one-file-per-tag' format. Older git-native clients can
still fetch from a repository that packed and pruned refs
(the server side needs to run the up-to-date version of git),
but older dumb transports cannot. Packing of refs is done by
an explicit user action, either by use of "git pack-refs
--prune" command or by use of "git gc" command.
So everything was opt in and clearly marked as such. You may
not have read it, distros may not have shown it, but then that
is something we cannot do much about, unfortunately.
I think there was _one_ honest slippage though. Fetching from
1.5.0 peer by 1.5.0 client could (after doing content
negotiation between both ends as a protection measure) create a
packfile that cannot be read by older 1.4 clients. Obviously
you cannot expect that kind of "protection" to work across set
of machines with mixed versions sharing a repository over NFS,
and that probably is a mistake we can learn from.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-15 2:23 UTC (permalink / raw)
To: Joel Becker; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071215004230.GF7300@mail.oracle.com>
On Fri, 14 Dec 2007, Joel Becker wrote:
> On Fri, Dec 14, 2007 at 05:46:14PM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Joel Becker wrote:
> >
> > > On Fri, Dec 14, 2007 at 05:34:49PM -0500, Nicolas Pitre wrote:
> > > > But you know what? repositories with the change affecting 1.4.4 users
> > > > are _already_ out there and no one complained recently. Anyone pushing
> > >
> > > I did, as did people I work with. It's on git-list, even. I'm
> > > pretty sure it corrupted too.
> >
> > Could you please give me a reference to such message, so to verify that
> > we're actually talking about the same thing?
>
> The relevant message is:
>
> Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
>
> See the paragraphs at the bottom. The thread, started by me, begins
> with:
>
> Message-ID: <20070910205429.GE27837@tasint.org>
OK. From those emails Junio forwarded to me, I don't see any case for
actual _corruptions_. Git does indeed refuse to work with unknown pack
index or unknown objects in a pack. Really old versions were not overly
clueful as to why they refused to work, but they should never corrupt a
pack which, for all purposes, is always read-only anyway.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/2] git-help: add "help.format" config variable.
From: Christian Couder @ 2007-12-15 4:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63z374nf.fsf@gitster.siamese.dyndns.org>
Le jeudi 13 décembre 2007, Junio C Hamano a écrit :
> Junio C Hamano <gitster@pobox.com> writes:
> > Christian Couder <chriscool@tuxfamily.org> writes:
> >> diff --git a/git.c b/git.c
> >> index 4f9876e..d46b63d 100644
> >> --- a/git.c
> >> +++ b/git.c
> >> @@ -324,7 +324,7 @@ static void handle_internal_command(int argc,
> >> const char **argv) { "gc", cmd_gc, RUN_SETUP },
> >> { "get-tar-commit-id", cmd_get_tar_commit_id },
> >> { "grep", cmd_grep, RUN_SETUP | USE_PAGER },
> >> - { "help", cmd_help },
> >> + { "help", cmd_help, RUN_SETUP },
> >> #ifndef NO_CURL
> >> { "http-fetch", cmd_http_fetch, RUN_SETUP },
> >> #endif
> >
> > It would be _NICE_ if we read configuration when we are in a git
> > repository, but I am afraid this change is unnice -- the users used to
> > be able to say "git help" from anywhere didn't they? Now they will get
> > "Not a git repository". It needs to do an optional repository
> > discovery, not a mandatory one RUN_SETUP causes.
>
> It turns out that the earlier git-browse-help is already broken with
> respect to this.
You are right, I did not test outside a git repository.
I reworked the patch and will send it after this email.
While testing my new patch it seemed to me that some of your changes in the
patch quoted below prevent some configuration variables to be used when
they are set in the "global" config file (~/.gitconfig). So I reverted them
in my new patch. But thanks to your other changes, it seems to work fine
now.
> -- >8 --
> [PATCH] git-help -w: do not require to be in git repository
[...]
> @@ -37,7 +39,7 @@ valid_tool() {
> }
>
> init_browser_path() {
> - browser_path=`git config browser.$1.path`
> + test -z "$GIT_DIR" || browser_path=`git config browser.$1.path`
> test -z "$browser_path" && browser_path=$1
> }
This seems to prevent using global configuration when outside a git repo.
> @@ -69,7 +71,8 @@ do
> shift
> done
>
> -if test -z "$browser"; then
> +if test -z "$browser" && test -n "$GIT_DIR"
> +then
> for opt in "help.browser" "web.browser"
> do
> browser="`git config $opt`"
This also.
Thanks,
Christian.
^ permalink raw reply
* [PATCH v2] git-help: add "help.format" config variable.
From: Christian Couder @ 2007-12-15 4:57 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
This config variable makes it possible to choose the default format
used to display help. This format will be used only if no option
like -a|--all|-i|--info|-m|--man|-w|--web is passed to "git-help".
The following values are possible for this variable:
- "man" --> "man" program is used
- "info" --> "info" program is used
- "web" --> "git-browse-help" is used
By default we still show help using "man".
By the way, this patch also adds -m|--man command line option to
use "man" even if something else is set in the "help.format"
config variable.
Note that this patch also revert some recent changes in
"git-browse-help" because they prevented to look for config
variables in the global configuration file.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-help.txt | 37 +++++++++++++++++++++++++-
git-browse-help.sh | 10 +++---
help.c | 61 ++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 99 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-help.txt b/Documentation/git-help.txt
index ac9e15d..31ec403 100644
--- a/Documentation/git-help.txt
+++ b/Documentation/git-help.txt
@@ -7,7 +7,7 @@ git-help - display help information about git
SYNOPSIS
--------
-'git help' [-a|--all|-i|--info|-w|--web] [COMMAND]
+'git help' [-a|--all|-i|--info|-m|--man|-w|--web] [COMMAND]
DESCRIPTION
-----------
@@ -21,7 +21,7 @@ printed on the standard output.
If a git command is named, a manual page for that command is brought
up. The 'man' program is used by default for this purpose, but this
-can be overriden by other options.
+can be overriden by other options or configuration variables.
Note that 'git --help ...' is identical as 'git help ...' because the
former is internally converted into the latter.
@@ -36,6 +36,11 @@ OPTIONS
Use the 'info' program to display the manual page, instead of
the 'man' program that is used by default.
+-m|--man::
+ Use the 'man' program to display the manual page. This may be
+ used to override a value set in the 'help.format'
+ configuration variable.
+
-w|--web::
Use a web browser to display the HTML manual page, instead of
the 'man' program that is used by default.
@@ -54,6 +59,34 @@ is available in PATH.
Note that the script tries, as much as possible, to display the HTML
page in a new tab on an already opened browser.
+CONFIGURATION VARIABLES
+-----------------------
+
+If no command line option is passed, the 'help.format' configuration
+variable will be checked. The following values are supported for this
+variable; they make 'git-help' behave as their corresponding command
+line option:
+
+* "man" corresponds to '-m|--man',
+* "info" corresponds to '-i|--info',
+* "web" or "html" correspond to '-w|--web',
+
+The 'help.browser', 'web.browser' and 'browser.<tool>.path' will also
+be checked if the 'web' format is choosen (either by command line
+option or configuration variable). See '-w|--web' in the OPTIONS
+section above.
+
+Note that these configuration variables should probably be set using
+the '--global' flag, for example like this:
+
+------------------------------------------------
+$ git config --global help.format web
+$ git config --global web.browser firefox
+------------------------------------------------
+
+as they are probably more user specific than repository specific.
+See gitlink:git-config[1] for more information about this.
+
Author
------
Written by Junio C Hamano <gitster@pobox.com> and the git-list
diff --git a/git-browse-help.sh b/git-browse-help.sh
index b465911..6fdf041 100755
--- a/git-browse-help.sh
+++ b/git-browse-help.sh
@@ -39,7 +39,7 @@ valid_tool() {
}
init_browser_path() {
- test -z "$GIT_DIR" || browser_path=`git config browser.$1.path`
+ browser_path=`git config browser.$1.path`
test -z "$browser_path" && browser_path=$1
}
@@ -71,7 +71,7 @@ do
shift
done
-if test -z "$browser" && test -n "$GIT_DIR"
+if test -z "$browser"
then
for opt in "help.browser" "web.browser"
do
@@ -79,9 +79,9 @@ then
test -z "$browser" || break
done
if test -n "$browser" && ! valid_tool "$browser"; then
- echo >&2 "git config option $opt set to unknown browser: $browser"
- echo >&2 "Resetting to default..."
- unset browser
+ echo >&2 "git config option $opt set to unknown browser: $browser"
+ echo >&2 "Resetting to default..."
+ unset browser
fi
fi
diff --git a/help.c b/help.c
index c96b167..af0a433 100644
--- a/help.c
+++ b/help.c
@@ -8,6 +8,44 @@
#include "exec_cmd.h"
#include "common-cmds.h"
+static const char *help_default_format;
+
+static enum help_format {
+ man_format,
+ info_format,
+ web_format,
+} help_format = man_format;
+
+static void parse_help_format(const char *format)
+{
+ if (!format) {
+ help_format = man_format;
+ return;
+ }
+ if (!strcmp(format, "man")) {
+ help_format = man_format;
+ return;
+ }
+ if (!strcmp(format, "info")) {
+ help_format = info_format;
+ return;
+ }
+ if (!strcmp(format, "web") || !strcmp(format, "html")) {
+ help_format = web_format;
+ return;
+ }
+ die("unrecognized help format '%s'", format);
+}
+
+static int git_help_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "help.format")) {
+ help_default_format = xstrdup(value);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
/* most GUI terminals set COLUMNS (although some don't export it) */
static int term_columns(void)
{
@@ -331,8 +369,27 @@ int cmd_help(int argc, const char **argv, const char *prefix)
show_info_page(argc > 2 ? argv[2] : NULL);
}
- else
- show_man_page(help_cmd);
+ else if (!strcmp(help_cmd, "--man") || !strcmp(help_cmd, "-m")) {
+ show_man_page(argc > 2 ? argv[2] : NULL);
+ }
+
+ else {
+ git_config(git_help_config);
+ if (help_default_format)
+ parse_help_format(help_default_format);
+
+ switch (help_format) {
+ case man_format:
+ show_man_page(help_cmd);
+ break;
+ case info_format:
+ show_info_page(help_cmd);
+ break;
+ case web_format:
+ show_html_page(help_cmd);
+ break;
+ }
+ }
return 0;
}
--
1.5.4.rc0.1099.ga9f2-dirty
^ permalink raw reply related
* [PATCH] Replace the cryptic messages from "git stash show".
From: Jing Xue @ 2007-12-15 5:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vir32xdn3.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 13, 2007 at 05:34:40PM -0800, Junio C Hamano wrote:
>
> I agree "git stash show" should not give cryptic error message, but I
> think you should do this only when the user did not explicitly say which
> stash to show (that is, we should still give error message if the user
> said "git stash show garbage").
Good point. Actually I found out that if there _are_ some stashes and an
invalid name is given, the current behavior is still printing
refs/stash, which I think is not quite right. So I also try to fix that
while I'm at it.
Now "git stash show" will keep quiet and just exit if there are no
stashes at all. "git stash show some-non-existent-stash" will always
print a clear message indicating the case.
---
git-stash.sh | 23 ++++++++++++++++++++---
1 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index f16fd9c..40e93dd 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -116,13 +116,30 @@ show_stash () {
flags=$(git rev-parse --no-revs --flags "$@")
if test -z "$flags"
then
- flags=--stat
+ diff_flags=--stat
+ else
+ diff_flags=$flags
+ fi
+ s=$(git rev-parse --revs-only --no-flags "$@")
+ if test -z "$s"
+ then
+ arguments=$@
+ if test "${flags}" = "${arguments}"
+ then
+ s=$(git rev-parse --revs-only --no-flags $ref_stash)
+ if test -z "$s"
+ then
+ return 0
+ fi
+ else
+ eval stash_name=\$$#
+ die "Can't find any stash with name $stash_name"
+ fi
fi
- s=$(git rev-parse --revs-only --no-flags --default $ref_stash "$@")
w_commit=$(git rev-parse --verify "$s") &&
b_commit=$(git rev-parse --verify "$s^") &&
- git diff $flags $b_commit $w_commit
+ git diff $diff_flags $b_commit $w_commit
}
apply_stash () {
--
1.5.4.rc0.8.gd381b
^ permalink raw reply related
* Re: git-send-email doesn't like me+git ML
From: Jing Xue @ 2007-12-15 5:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <476244C5.2090205@op5.se>
On Fri, Dec 14, 2007 at 09:54:29AM +0100, Andreas Ericsson wrote:
>
> I've had similar problems. I think it's actually a filtering issue on the
> receiving end though, as some seem to see the mails on the list (while
> most don't). Looking at the headers, I see the hostname of my laptop as
> originating host when using git-send-email, which obviously will fail
> for any receiving host that tries to connect back to verify that the
> originating sender is indeed a real SMTP server.
Quite possibly so. What puzzles me is that when I compare the headers
between the one I sent from mutt (which made it to the list) and the one
from send-email (which made it to gmail), I can't find any differences
(other than message ids and timestamps of course).
Ah well...
--
Jing Xue
^ permalink raw reply
* Re: [PATCH v2] git-help: add "help.format" config variable.
From: Junio C Hamano @ 2007-12-15 5:20 UTC (permalink / raw)
To: Christian Couder; +Cc: git
In-Reply-To: <20071215055728.857b1924.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Note that this patch also revert some recent changes in
> "git-browse-help" because they prevented to look for config
> variables in the global configuration file.
You are right, but I think git-sh-setup can further be simplified, as
NONGIT_OK users would just rely on the default behaviour of underlying
plumbing (most notably "git config").
I do not think your change to help.c is sufficient to work inside a
subdirectory. Here is an attempt to fix it on top of yours.
---
git-sh-setup.sh | 7 +------
help.c | 3 +++
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index b366761..270d559 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -124,13 +124,8 @@ get_author_ident_from_commit () {
# Make sure we are in a valid repository of a vintage we understand,
# if we require to be in a git repository.
-if test -n "$NONGIT_OK"
+if test -z "$NONGIT_OK"
then
- if git rev-parse --git-dir >/dev/null 2>&1
- then
- : ${GIT_DIR=.git}
- fi
-else
if [ -z "$SUBDIRECTORY_OK" ]
then
: ${GIT_DIR=.git}
diff --git a/help.c b/help.c
index af0a433..551b5b9 100644
--- a/help.c
+++ b/help.c
@@ -374,6 +374,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
}
else {
+ int nongit;
+
+ setup_git_directory_gently(&nongit);
git_config(git_help_config);
if (help_default_format)
parse_help_format(help_default_format);
^ 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