* [PATCH 3/5] optimize parse_sha1_header() a little by detecting object type
From: Liu Yubao @ 2008-12-02 1:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
---
sha1_file.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index dccc455..79062f0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1099,7 +1099,8 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
if (!fstat(fd, &st)) {
*size = xsize_t(st.st_size);
- map = xmmap(NULL, *size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (*size > 0)
+ map = xmmap(NULL, *size, PROT_READ, MAP_PRIVATE, fd, 0);
}
close(fd);
}
@@ -1257,6 +1258,8 @@ static int parse_sha1_header(const char *hdr, unsigned long length, unsigned lon
* terminating '\0' that we add), and is followed by
* a space, at least one byte for size, and a '\0'.
*/
+ if ('b' != *hdr && 'c' != *hdr && 't' != *hdr) /* blob/commit/tag/tree */
+ return -1;
i = 0;
while (hdr < hdr_end - 2) {
char c = *hdr++;
--
1.6.1.rc1.5.gde86c
^ permalink raw reply related
* [PATCH 2/5] don't die immediately when convert an invalid type name
From: Liu Yubao @ 2008-12-02 1:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
---
object.c | 14 +++++++++++++-
object.h | 1 +
sha1_file.c | 2 +-
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/object.c b/object.c
index 50b6528..0a18db6 100644
--- a/object.c
+++ b/object.c
@@ -33,13 +33,25 @@ const char *typename(unsigned int type)
return object_type_strings[type];
}
-int type_from_string(const char *str)
+int type_from_string_gently(const char *str)
{
int i;
for (i = 1; i < ARRAY_SIZE(object_type_strings); i++)
if (!strcmp(str, object_type_strings[i]))
return i;
+
+ return -1;
+}
+
+int type_from_string(const char *str)
+{
+ int i;
+
+ i = type_from_string_gently(str);
+ if (i > 0)
+ return i;
+
die("invalid object type \"%s\"", str);
}
diff --git a/object.h b/object.h
index d962ff1..88baf2b 100644
--- a/object.h
+++ b/object.h
@@ -36,6 +36,7 @@ struct object {
};
extern const char *typename(unsigned int type);
+extern int type_from_string_gently(const char *str);
extern int type_from_string(const char *str);
extern unsigned int get_max_object_index(void);
diff --git a/sha1_file.c b/sha1_file.c
index efe6967..dccc455 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1291,7 +1291,7 @@ static int parse_sha1_header(const char *hdr, unsigned long length, unsigned lon
/*
* The length must be followed by a zero byte
*/
- return *hdr ? -1 : type_from_string(type);
+ return *hdr ? -1 : type_from_string_gently(type);
}
static void *unpack_sha1_file(void *map, unsigned long mapsize, enum object_type *type, unsigned long *size, const unsigned char *sha1)
--
1.6.1.rc1.5.gde86c
^ permalink raw reply related
* Re: [PATCH] gitweb: fixes to gitweb feature check code
From: Jakub Narebski @ 2008-12-02 1:53 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1228008844-12506-1-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 30 Nov 2008, Giuseppe Bilotta wrote:
> The gitweb_check_feature routine was being used for two different
> purposes: retrieving the actual feature value (such as the list of
> snapshot formats or the list of additional actions), and checking if a
> feature was enabled.
>
> This led to subtle bugs in feature checking code: gitweb_check_feature
> would return (0) for disabled features, so its use in scalar context
> would return true instead of false.
>
> To fix this issue and future-proof the code, we split feature value
> retrieval into its own gitweb_get_feature()function , and ensure that
retrieval into its own gitweb_get_feature() function, and ensure that
> the boolean feature check function gitweb_check_feature() always returns
> a scalar (precisely, the first/only item in the feature value list).
>
> Usage of gitweb_check_feature() across gitweb is replaced with
> gitweb_get_feature() where appropriate, and list evaluation of
> gitweb_check_feature() is demoted to scalar evaluation to prevent
> ambiguity. The few previously incorrect uses of gitweb_check_feature()
> in scalar context are left untouched because they are now correct.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
What I like about having all this, i.e. fix, futureproof and style
correction in one single patch is the fact that fix doesn't introduce
strange looking (gitweb_check_feature('bool_feat'))[0]... well, except
encapsulated in a subroutine.
>From all possible splits of this feature into series of up to three
patches I think I like the one with pure subroutine rename from *check*
to *get* least...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 1/5] avoid parse_sha1_header() accessing memory out of bound
From: Liu Yubao @ 2008-12-02 1:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
---
sha1_file.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 6c0e251..efe6967 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1245,8 +1245,9 @@ static void *unpack_sha1_rest(z_stream *stream, void *buffer, unsigned long size
* too permissive for what we want to check. So do an anal
* object header parse by hand.
*/
-static int parse_sha1_header(const char *hdr, unsigned long *sizep)
+static int parse_sha1_header(const char *hdr, unsigned long length, unsigned long *sizep)
{
+ const char *hdr_end = hdr + length;
char type[10];
int i;
unsigned long size;
@@ -1254,10 +1255,10 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
/*
* The type can be at most ten bytes (including the
* terminating '\0' that we add), and is followed by
- * a space.
+ * a space, at least one byte for size, and a '\0'.
*/
i = 0;
- for (;;) {
+ while (hdr < hdr_end - 2) {
char c = *hdr++;
if (c == ' ')
break;
@@ -1265,6 +1266,8 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
if (i >= sizeof(type))
return -1;
}
+ if (' ' != *(hdr - 1))
+ return -1;
type[i] = 0;
/*
@@ -1275,7 +1278,7 @@ static int parse_sha1_header(const char *hdr, unsigned long *sizep)
if (size > 9)
return -1;
if (size) {
- for (;;) {
+ while (hdr < hdr_end - 1) {
unsigned long c = *hdr - '0';
if (c > 9)
break;
@@ -1298,7 +1301,7 @@ static void *unpack_sha1_file(void *map, unsigned long mapsize, enum object_type
char hdr[8192];
ret = unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr));
- if (ret < Z_OK || (*type = parse_sha1_header(hdr, size)) < 0)
+ if (ret < Z_OK || (*type = parse_sha1_header(hdr, stream.total_out, size)) < 0)
return NULL;
return unpack_sha1_rest(&stream, hdr, *size, sha1);
@@ -1982,7 +1985,7 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
if (unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr)) < 0)
status = error("unable to unpack %s header",
sha1_to_hex(sha1));
- else if ((status = parse_sha1_header(hdr, &size)) < 0)
+ else if ((status = parse_sha1_header(hdr, stream.total_out, &size)) < 0)
status = error("unable to parse %s header", sha1_to_hex(sha1));
else if (sizep)
*sizep = size;
--
1.6.1.rc1.5.gde86c
^ permalink raw reply related
* [PATCH 0/5] support reading and writing uncompressed loose object
From: Liu Yubao @ 2008-12-02 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Hi,
In original implementation, git stores loose object like this:
loose object = deflate(typename + <space> + size + data)
The patches below add support to read and write uncompressed loose
object:
loose object = typename + <space> + size + data
The cons and pros to use uncompressed loose object:
cons
* old git can't read these uncompressed loose objects
(I think it's not a big problem because old git can read
pack files generated by new git)
* uncompressed loose objects occupy more disk space
(I also think it's not a big problem because loose objects
aren't too many in general)
pros
* avoid compressing and uncompressing loose objects that are likely
frequently used when coding/merging with git add/diff/diff --cached/
merge/rebase/log.
* the code to read and write uncompressed loose objects is
simpler, although there are now more code paths for compatibility.
* better to share loose objects among multiple git processes because
sha1 files can be used directly after mmapped. The original git
uncompresses loose objects into heap memory area so that they
can't be shared by other processes.
(NOTICE: The patches below doesn't use mmapped sha1 files directly
because I find parse_object() requires a buffer terminated with
zero.)
* easy to grep objects in .git/objects (...stupid use case :-)
If these patches are worth being included into upstream branch,
I will add a new config variable core.uncompressedLooseObject.
Explanation to the patches:
1) avoid parse_sha1_header() accessing memory out of bound
Just for more safety, no inflateInit() to detect errors for
uncompressed loose objects.
2) don't die immediately when convert an invalid type name
So we can fall back to compressed loose objects.
3) optimize parse_sha1_header() a little by detecting object type
To quickly detect whether it seems an uncompressed loose object.
4) support reading uncompressed loose object
The new feature.
5) support writing uncompressed loose object
The new feature, need a git-config variable yet.
The patches are generated against git-1.6.1-rc, I have run the test cases
and it seems ok.
object.c | 14 +++++++++++++-
object.h | 1 +
sha1_file.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-------------
3 files changed, 59 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH] Modified the default git help message to be grouped by topic
From: Junio C Hamano @ 2008-12-02 1:45 UTC (permalink / raw)
To: Jeff King; +Cc: Scott Chacon, git, gitster
In-Reply-To: <20081201183258.GB24443@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:
>
>> It's difficult to process 21 commands (which is what is output
>> by default for git when no command is given). I've re-grouped
>> them into 4 groups of 5 or 6 commands each, which I think is
>> clearer and easier for new users to process.
>
> I like it (and I think the categorizations look reasonable, which is
> something that I recall caused some discussion at the GitTogether).
>
> The only downside I see is that we're now >24 lines.
If this list is meant to show "the most commonly used" basics, then you
can trim the list somewhat. For example, "rm" and "mv" can be safely
discarded, "status" can be replaced with "diff", and "diff" can be removed
from "History Commands".
^ permalink raw reply
* Re: [PATCH] added a built-in alias for 'stage' to the 'add' command
From: Junio C Hamano @ 2008-12-02 1:38 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, gitster
In-Reply-To: <20081201172902.GA41963@agadorsparticus>
Scott Chacon <schacon@gmail.com> writes:
> Subject: Re: [PATCH] added a built-in alias for 'stage' to the 'add' command
s/added/Add/;
Write your commit log message in present tense (recall David Brown's talk
at GitTogether '08? ;-)
> this comes from conversation at the GitTogether where we thought it would
s/this/This/;
> be helpful to be able to teach people to 'stage' files because it tends
> to cause confusion when told that they have to keep 'add'ing them.
>
> This continues the movement to start referring to the index as a
> staging area (eg: the --staged alias to 'git diff'). Also added a
> doc file for 'git stage' that basically points to the docs for
> 'git add'.
>
> Signed-off-by: Scott Chacon <schacon@gmail.com>
I think this is fine but I'd rather not risk the documentation getting
stale over time, so...
> +SYNOPSIS
> +--------
> +[verse]
> +'git stage' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
> + [--all | [--update | -u]] [--intent-to-add | -N]
> + [--refresh] [--ignore-errors] [--] <filepattern>...
...I think this should read something like
'git stage' args...
^ permalink raw reply
* Re: Managing websites with git
From: Leo Razoumov @ 2008-12-02 1:36 UTC (permalink / raw)
To: Jason Riedy, git; +Cc: Jeff King, David Bryson, Felix Andersen
In-Reply-To: <87k5ajflp0.fsf@sparse.dyndns.org>
On 12/1/08, Jason Riedy <jason@acm.org> wrote:
> And David Bryson writes:
> > One really should not push to a non-bare repo.
>
>
> WHAT?!?!?!
>
> And Jeff King responds:
>
> > It's in master and should be in 1.6.1, but it is a config option that
> > defaults to "warn" for now, so as not to break existing setups.
>
>
> WHAT?!?!?!
>
> I do this all the time. I clone from my main working directory
> onto some cluster / MPP where the build system is all wonky.
> Once I get everything building, I push back to a branch (often
> new) in my main working directory. Then I can merge the build
> changes whenever I get a chance.
>
> Pushing from these systems often is much, much easier than
> pulling from the origin. Sometimes you're working in temporary
> space on a back-end node; you can connect out but you cannot
> connect in.
>
> I've gotten a few people interested in git for managing these
> nearly one-off build problems. git is the first system that has
> "just worked" for them. Their having to configure each repo
> eliminates the "just works" factor.
>
> It feels like newer gits make more and more decisions about what
> I shouldn't do.
>
>
> Jason
>
I second Jason's opinion. I also frequently push to non-bare
intermediary repos. This functionality is essential for several of my
work flows. Please, please, do not handicap git-push operation!!
--Leo--
^ permalink raw reply
* Re: [PATCH 0/6 (v2)] Detecting HEAD more reliably while cloning
From: Junio C Hamano @ 2008-12-02 1:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4934082B.5050802@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> Instead of introducing a full-fledged protocol extension, this round hides
>> the new information in the same place as the server capabilities list that
>> is used to implement protocol extension is hidden from older clients.
>
> Not that it makes a lot of difference, but why do you want to *hide* the
> information? Can't we just have a capability-with-parameter:
>
> ... shallow no-progress include-tag head=refs/heads/foo\ bar ...
>
> (with spaces and backslashes escaped)?
The ref namespace is reasonably tight (most importantly I do not think you
can have space) so there is no need for quoting. If we were to go that
route of making them extended "capabilities", the right syntax would be
... symref-HEAD=refs/heads/master symref-refs/remotes/origin/HEAD=refs/remotes/origin/master ...
or something like that.
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Junio C Hamano @ 2008-12-02 1:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081201174414.GA22185@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 01, 2008 at 06:12:54AM -0800, Junio C Hamano wrote:
>
>> + packet_write(1, "%s %s%c%s%c%s\n", sha1_to_hex(sha1), refname,
>> + 0, capabilities, 0, target);
>
> Yuck. My two complaints are:
>
> (1) this implicitly handles only the HEAD symref.
But this information *is* on the "40-hex name" line that describes the
HEAD ;-)
You can trivially extend it to add this to other symbolic refs if you are
interested. I wasn't.
^ permalink raw reply
* Re: Managing websites with git
From: Jason Riedy @ 2008-12-02 0:46 UTC (permalink / raw)
To: Jeff King; +Cc: David Bryson, Felix Andersen, git
In-Reply-To: <20081130172717.GA7047@coredump.intra.peff.net>
And David Bryson writes:
> One really should not push to a non-bare repo.
WHAT?!?!?!
And Jeff King responds:
> It's in master and should be in 1.6.1, but it is a config option that
> defaults to "warn" for now, so as not to break existing setups.
WHAT?!?!?!
I do this all the time. I clone from my main working directory
onto some cluster / MPP where the build system is all wonky.
Once I get everything building, I push back to a branch (often
new) in my main working directory. Then I can merge the build
changes whenever I get a chance.
Pushing from these systems often is much, much easier than
pulling from the origin. Sometimes you're working in temporary
space on a back-end node; you can connect out but you cannot
connect in.
I've gotten a few people interested in git for managing these
nearly one-off build problems. git is the first system that has
"just worked" for them. Their having to configure each repo
eliminates the "just works" factor.
It feels like newer gits make more and more decisions about what
I shouldn't do.
Jason
^ permalink raw reply
* [PATCH] gitk: map / to focus the search box
From: Giuseppe Bilotta @ 2008-12-02 1:19 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <18740.26151.55900.953153@cargo.ozlabs.ibm.com>
The / key is often used to initiate searches (less, vim, some web
browsers). We change the binding for the / (slash) key from 'find next'
to 'focus the search box' to follow this convention.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Like this?
gitk-git/gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 6b671a6..0c0350b 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2271,7 +2271,7 @@ proc makewindow {} {
bindkey b prevfile
bindkey d "$ctext yview scroll 18 units"
bindkey u "$ctext yview scroll -18 units"
- bindkey / {dofind 1 1}
+ bindkey / {focus $fstring}
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
@@ -2652,7 +2652,7 @@ proc keys {} {
[mc "<%s-F> Find" $M1T]
[mc "<%s-G> Move to next find hit" $M1T]
[mc "<Return> Move to next find hit"]
-[mc "/ Move to next find hit, or redo find"]
+[mc "/ Focus the search box"]
[mc "? Move to previous find hit"]
[mc "f Scroll diff view to next file"]
[mc "<%s-S> Search for next hit in diff view" $M1T]
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitk: map / to focus the search box
From: Giuseppe Bilotta @ 2008-12-02 1:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
The / key is often used to initiate searches (less, vim, some web
browsers). We change the binding for the / (slash) key from 'find next'
to 'focus the search box' to follow this convention.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Like this?
gitk-git/gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 6b671a6..0c0350b 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2271,7 +2271,7 @@ proc makewindow {} {
bindkey b prevfile
bindkey d "$ctext yview scroll 18 units"
bindkey u "$ctext yview scroll -18 units"
- bindkey / {dofind 1 1}
+ bindkey / {focus $fstring}
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
@@ -2652,7 +2652,7 @@ proc keys {} {
[mc "<%s-F> Find" $M1T]
[mc "<%s-G> Move to next find hit" $M1T]
[mc "<Return> Move to next find hit"]
-[mc "/ Move to next find hit, or redo find"]
+[mc "/ Focus the search box"]
[mc "? Move to previous find hit"]
[mc "f Scroll diff view to next file"]
[mc "<%s-S> Search for next hit in diff view" $M1T]
--
1.5.6.5
^ permalink raw reply related
* Re: Managing websites with git
From: Jeff King @ 2008-12-02 1:11 UTC (permalink / raw)
To: Jason Riedy; +Cc: David Bryson, Felix Andersen, git
In-Reply-To: <87k5ajflp0.fsf@sparse.dyndns.org>
On Mon, Dec 01, 2008 at 07:46:35PM -0500, Jason Riedy wrote:
> And David Bryson writes:
> > One really should not push to a non-bare repo.
> WHAT?!?!?!
To clarify: one should not push to the _current branch_ of a non-bare
repo...
> And Jeff King responds:
> > It's in master and should be in 1.6.1, but it is a config option that
> > defaults to "warn" for now, so as not to break existing setups.
> WHAT?!?!?!
...and that is what 1.6.1 will warn about.
> I do this all the time. I clone from my main working directory
> onto some cluster / MPP where the build system is all wonky.
> Once I get everything building, I push back to a branch (often
> new) in my main working directory. Then I can merge the build
> changes whenever I get a chance.
As long as you are not pushing to the currently checked-out branch, then
you will see no change in behavior. If you are pushing to the currently
checked-out branch, then what are you doing to reconcile the resulting
mismatch between the index and HEAD?
> Pushing from these systems often is much, much easier than
> pulling from the origin. Sometimes you're working in temporary
> space on a back-end node; you can connect out but you cannot
> connect in.
Of course. The recommended thing to do is:
# on pusher
git push $remote HEAD:some-branch-that-is-not-checked-out
# on $remote
git merge some-branch-that-is-not-checked-out
where an obvious choice for branch name is "incoming/master" or whatever
suits your workflow. You can also do:
# on pusher
git push $remote HEAD:branch-that-is-checked-out
# on $remote
git reset --hard
but that throws away anything else going on in that branch on $remote.
> It feels like newer gits make more and more decisions about what
> I shouldn't do.
Doing
git push $remote HEAD:branch-that-is-checked-out
has _never_ worked without further action on $remote. Now we're warning
about it.
If you have other specific complaints about new git behavior, I'm sure
the list would be happy to hear about it. Almost every behavior change
is in response to user complaints, and a lot of effort is put into
maintaining backwards compatibility. If we've screwed up somewhere, it
would be good to know.
-Peff
^ permalink raw reply
* [PATCH] git-stash: use git rev-parse -q
From: Miklos Vajna @ 2008-12-02 0:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Don't redirect stderr to /dev/null, use -q to suppress the output on
stderr.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
git-stash.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index b9ace99..c0532e8 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -30,7 +30,7 @@ clear_stash () {
then
die "git stash clear with parameters is unimplemented"
fi
- if current=$(git rev-parse --verify $ref_stash 2>/dev/null)
+ if current=$(git rev-parse -q --verify $ref_stash)
then
git update-ref -d $ref_stash $current
fi
@@ -129,7 +129,7 @@ save_stash () {
}
have_stash () {
- git rev-parse --verify $ref_stash >/dev/null 2>&1
+ git rev-parse -q --verify $ref_stash >/dev/null
}
list_stash () {
@@ -229,16 +229,16 @@ drop_stash () {
fi
# Verify supplied argument looks like a stash entry
s=$(git rev-parse --verify "$@") &&
- git rev-parse --verify "$s:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^1:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^2:" > /dev/null 2>&1 ||
+ git rev-parse -q --verify "$s:" > /dev/null &&
+ git rev-parse -q --verify "$s^1:" > /dev/null &&
+ git rev-parse -q --verify "$s^2:" > /dev/null ||
die "$*: not a valid stashed state"
git reflog delete --updateref --rewrite "$@" &&
echo "Dropped $* ($s)" || die "$*: Could not drop stash entry"
# clear_stash if we just dropped the last stash entry
- git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+ git rev-parse -q --verify "$ref_stash@{0}" > /dev/null || clear_stash
}
apply_to_branch () {
--
1.6.0.4
^ permalink raw reply related
* Re: [JGIT PATCH 0/4] RepositoryTestCase cleanups
From: Johannes Schindelin @ 2008-12-01 23:18 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git, fonseca
In-Reply-To: <200811291301.12095.robin.rosenberg@dewire.com>
Hi,
On Sat, 29 Nov 2008, Robin Rosenberg wrote:
> [Repository refactoring] Would be cool, but having that diff engine is
> more important to me.
Stay tuned. I have something that outputs something resembling a diff
now. Of course, the output is not correct yet, due to bugs I introduced
cunnily when trying to fix another bug.
I'll keep you posted,
Dscho
^ permalink raw reply
* Re: [PATCH (GITK FIX)] gitk: Fix the "notflag: no such variable" error in --not processing.
From: Paul Mackerras @ 2008-12-01 22:45 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <200812012025.25286.angavrilov@gmail.com>
Alexander Gavrilov writes:
> This patch initializes it. Note that actually it is also possible to
> remove it completely, because currently nobody uses the value.
Thanks. I actually committed a change to remove it completely.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: map / to focus the search box
From: Paul Mackerras @ 2008-12-01 22:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1227459690-9896-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta writes:
> The / key is often used to initiate searches (less, vim, some web
> browsers). We change the binding for the / (slash) key from 'find next'
> to 'focus the search box' to follow this convention.
I think that's reasonable, but the patch needs to update the key
bindings help text as well.
Thanks,
Paul.
^ permalink raw reply
* Re: Is rebase always destructive?
From: Robin Rosenberg @ 2008-12-01 20:19 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrngj8884.2srb.csaba-ml@beastie.creo.hu>
måndag 01 december 2008 18:37:43 skrev Csaba Henk:
> On 2008-12-01, Nick Andrew <nick@nick-andrew.net> wrote:
> > On Mon, Dec 01, 2008 at 11:41:39AM +0000, Csaba Henk wrote:
> >> I can't see any option for rebase which would yield this cp-like
> >> behaviour. Am I missing something?
> >
> > How about this:
> >
> > git checkout topic
> > git branch keepme
> > git rebase master
>
> OK, thanks guys, now I'm enlightened (a little bit more than before).
And if you forgot to create the keepme branch you can access the previous
version using the topic@{1} or topic@{'1 hour ago'} etc. This uses the reflog
that tracks all "versions" of your branch. Keeping gitk running is nice way
to see previous versions (press F5 after rebase).
-- robin
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Junio C Hamano @ 2008-12-01 19:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081201162011.GI23984@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Maybe we put on the first capability line a flag that lets the
> client know we have symref data in the advertised list, and then
> instead of sticking only HEAD into that first ref we put the names
> of the symrefs after the ref they point to.
>
> So we might see something like:
>
> xxxx......................... refs/heads/boo\0with-symref\0
> xxxx......................... refs/heads/master\0HEAD\0
> xxxx......................... refs/remotes/origin/HEAD\0refs/remotes/origin/master\0
>
> etc. Its probably harder to produce the output for, but it permits
> advertising all of the symrefs on the remote side, which may be good
> for --mirror, among other uses. It also should make it easier to put
> multiple symrefs down pointing at the same real ref, they could just
> be a space delimited list stored after the ref name, and if its the
> first ref in the stream, after the other capability advertisement.
It certainly is possible, and I think the arrangement v2 code makes
already keeps that option to talk about symrefs other than HEAD open. If
you want to send all the symref information, you would show something
like:
xxxx... HEAD\0<caps>\0refs/heads/master\n
xxxx... refs/heads/master\n
xxxx... refs/remotes/origin/HEAD\0<caps>\0refs/remotes/origin/master\n
xxxx... refs/remotes/origin/master\n
But in this round I am not interested in giving any "random symref"
information but "HEAD", so I omitted it from the code.
Notice that you need to repeat the capabilities list on each and every
line that describes a symbolic ref for that to work (and you do not need
"with-symref"), though. See what ll. 80-84 in connect.c does.
if (len != name_len + 41) {
free(server_capabilities);
server_capabilities = xstrdup(name + name_len + 1);
}
Historical accident mandates that the first hidden piece of information on
each and all of these lines _must_ be the capabilities list.
^ permalink raw reply
* Re: git configure script
From: Neale T. Pickett @ 2008-12-01 19:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq7i6q8azp.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> 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.
This gave me the tip I needed. I was doing this in my Makefile:
make -C git-1.6.0.4 install
Instead of this:
cd git-1.6.0.4 && make install
Since the include was prefixed with "-", I didn't get any warnings or
errors about not being able to find config.mak.autogen, and it fell back
to the default.
I'm not sure using the -C option to make is "something wrong", but then
again I am apparently the first person to run into this problem, so it's
probably not a big deal.
Thanks for your help :)
Neale
^ permalink raw reply
* [PATCH] User's Manual: remove duplicated url at the end of Appendix B
From: Miklos Vajna @ 2008-12-01 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/user-manual.txt | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index da9c6b2..9f527d3 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4572,4 +4572,3 @@ Alternates, clone -reference, etc.
More on recovery from repository corruption. See:
http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2
http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
- http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Modified the default git help message to be grouped by topic
From: Jeff King @ 2008-12-01 18:32 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, gitster
In-Reply-To: <20081201173037.GA41967@agadorsparticus>
On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:
> It's difficult to process 21 commands (which is what is output
> by default for git when no command is given). I've re-grouped
> them into 4 groups of 5 or 6 commands each, which I think is
> clearer and easier for new users to process.
I like it (and I think the categorizations look reasonable, which is
something that I recall caused some discussion at the GitTogether).
The only downside I see is that we're now >24 lines.
> This won't automatically update with the common-commands.txt file,
> but I think it is easier to parse for the command you may be looking
> for.
Personally, I don't see a big problem. This is not a list that should
change very frequently, and there is extra information here that would
be annoying to encode in the list. But since the "common" flag in
command-list.txt and the common-cmds.h file would no longer be used,
they should probably be removed.
-Peff
^ permalink raw reply
* Re: [PATCH] added a built-in alias for 'stage' to the 'add' command
From: Jeff King @ 2008-12-01 18:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, gitster
In-Reply-To: <20081201172902.GA41963@agadorsparticus>
On Mon, Dec 01, 2008 at 09:29:02AM -0800, Scott Chacon wrote:
> this comes from conversation at the GitTogether where we thought it would
> be helpful to be able to teach people to 'stage' files because it tends
> to cause confusion when told that they have to keep 'add'ing them.
>
> This continues the movement to start referring to the index as a
> staging area (eg: the --staged alias to 'git diff'). Also added a
> doc file for 'git stage' that basically points to the docs for
> 'git add'.
FWIW, I think this is a step in the right direction. Or at least if it's
the wrong direction, I don't think we're actually _hurting_ anybody,
since we're not changing existing commands.
Out of curiosity, have you had any experiences referring to this as "git
stage" (maybe just by setting a per-user alias) with new users?
> +SYNOPSIS
> +--------
> +[verse]
> +'git stage' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
> + [--all | [--update | -u]] [--intent-to-add | -N]
> + [--refresh] [--ignore-errors] [--] <filepattern>...
It seems like this might get stale with respect to git-add(1). Since
we're not hiding the fact that this is really an alias for "add", maybe
it would be better to just have "git stage [options] [--]
<filepattern>" (or maybe even something simpler).
-Peff
^ permalink raw reply
* Re: Add 'sane' mode to 'git reset'
From: Linus Torvalds @ 2008-12-01 18:06 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <32541b130812010944k3dd825e4pfa8c270ecc75d539@mail.gmail.com>
On Mon, 1 Dec 2008, Avery Pennarun wrote:
>
> For reference, I advised someone just yesterday to use "git reset
> HEAD^" to undo an accidental "commit -a" instead of just "commit".
Yeah, I guess the --mixed default of "git reset" is occasionally useful.
> Also, as far as I know, "git reset HEAD filename" is the only
> recommended way to undo an accidental "git add".
The path-name based ones are actually a totally different animal than the
non-pathname version of "git reset". With pathnames, it won't change the
actual HEAD, so it's really a totally different class of command, just
sharing a name.
But:
> How about calling it --merge instead? That's really what it does:
> merges the diffs from (your current index) to (the requested index)
> into (your working tree and your index).
Sure, "git reset --merge" would probably be a fine form.
Linus
^ 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