* Re: Deprecate git-fetch-pack?
From: Jon Loeliger @ 2007-11-12 18:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Git List
In-Reply-To: <Pine.LNX.4.64.0711121732000.4362@racer.site>
On Mon, 2007-11-12 at 11:33, Johannes Schindelin wrote:
> > I disagree; we should keep it.
>
> We keep it. We just don't advertise it. The whole thread was not about
> removing commands, but removing them from the output of "git help".
Yes, I can read an understand English; I know the context.
> > It is a very useful command, and usable on systems where GUI isn't an
> > option.
>
> Yes, and those systems are the majority nowadays. Oh, wait...
I remotely log into my server machines frequently.
Again, though, that is just my opinion.
jdl
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Johannes Schindelin @ 2007-11-12 19:08 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Jakub Narebski, Git List
In-Reply-To: <1194893799.1335.4.camel@ld0161-tx32>
Hi,
On Mon, 12 Nov 2007, Jon Loeliger wrote:
> On Mon, 2007-11-12 at 11:33, Johannes Schindelin wrote:
>
> > Jon wrote:
> >
> > > It [git show-branch] is a very useful command, and usable on systems
> > > where GUI isn't an option.
> >
> > Yes, and those systems are the majority nowadays. Oh, wait...
>
> I remotely log into my server machines frequently.
Okay, sorry. I was in a bad mood (you know why, I guess), and I was a
little tongue-in-cheek here. I apologise.
The thing is, show-branch might be mighty useful for you, but I agree with
another poster that its output is not for the faint of heart, if it goes
without an explanation.
So I vote for keeping relatively quiet about it in the output of "git
help" which is -- according to some people -- the first thing new git
users see.
Power users, such as yourself, will read in the user manual or in the FAQ
about the existence of this nice tool, and do not need to be reminded of
it by git-help.
Fair enough?
Dscho
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Jon Loeliger @ 2007-11-12 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Git List
In-Reply-To: <Pine.LNX.4.64.0711121905300.4362@racer.site>
On Mon, 2007-11-12 at 13:08, Johannes Schindelin wrote:
> Okay, sorry. I was in a bad mood (you know why, I guess), and I was a
> little tongue-in-cheek here. I apologise.
And accepted.
> Fair enough?
Yes.
> Dscho
Thanks,
jdl
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Andreas Ericsson @ 2007-11-12 19:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, Matthieu Moy, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121751100.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Nicolas Pitre wrote:
>
>> On Mon, 12 Nov 2007, Johannes Schindelin wrote:
>>
>>> On Mon, 12 Nov 2007, Matthieu Moy wrote:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> On Mon, 12 Nov 2007, Jan Wielemaker wrote:
>>>>>
>>>>>> I found out that cloning a empty bare repository produces nothing
>>>>>> at all, [...]
>>>>> If they are empty, what exactly do you mean to clone?
>>>> I'd expect an empty repository, with the git remote configured
>>>> correctly.
>>> Yeah, right.
>>>
>>> Last time I checked, those geneticists did not clone thin air. They
>>> always waited until they had something to clone.
>> But we're not geneticists, and I think the above usage should "just work
>> (tm)".
>
> I am still convinced that it is not very intelligent to start your
> development from a non-existing branch.
>
That's what happens with every new project though. The question is if
something starts with making space for things to be in, or if it starts
with things appearing in that space.
> But since you're one of the people knowing git _internals_ pretty well,
> here's another reason just for you why this cannot be done: There is no
> way to find out where the HEAD points to.
>
$ mkdir foo; cd foo; git init; git symbolic-ref -q HEAD
refs/heads/master
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/6] builtin-commit: fix author date with --amend --author=<author>
From: Kristian Høgsberg @ 2007-11-12 19:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0711111735100.4362@racer.site>
On Sun, 2007-11-11 at 17:35 +0000, Johannes Schindelin wrote:
> When amending a commit with a new author, the author date is taken
> from the original commit.
The new determine_author_info() should fix this. There was a problem
earlier that Junio pointed out and I sent a patch to update
determine_author_info() to do the right thing for amend commits. The
test suite still pass without this patch, and if you look carefully a
determine_author_info(), you can see it does the right thing:
1) Default to getenv for name, email and date
2) If a commit has been specified (-c, -C or --amend), we parse the
author name, email and date from use_message_buffer, which holds the
commit, overriding the values from getenv.
3) If --author has be passed, we parse name and email from the
argument and override whatever name and email the two previous steps
came up with.
Then we add the author line to the commit buffer under construction
based on these values.
I suggest we back this patch out.
cheers,
Kristian
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> builtin-commit.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-commit.c b/builtin-commit.c
> index a84a729..6be6def 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -527,6 +527,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> } else if (amend) {
> struct commit_list *c;
> struct commit *commit;
> + const char *author;
>
> reflog_msg = "commit (amend)";
> commit = lookup_commit(head_sha1);
> @@ -536,6 +537,21 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> for (c = commit->parents; c; c = c->next)
> strbuf_addf(&sb, "parent %s\n",
> sha1_to_hex(c->item->object.sha1));
> +
> + /* determine author date */
> + author = strstr(commit->buffer, "\nauthor");
> + if (author && !memmem(commit->buffer,
> + author + 1 - commit->buffer,
> + "\n\n", 2)) {
> + const char *email_end = strchr(author + 1, '>');
> + const char *line_end = strchr(author + 1, '\n');
> + if (email_end && line_end && email_end < line_end) {
> + char *date = xstrndup(email_end + 1,
> + line_end - email_end - 1);
> + setenv("GIT_AUTHOR_DATE", date, 1);
> + free(date);
> + }
> + }
> } else if (in_merge) {
> struct strbuf m;
> FILE *fp;
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Kristian Høgsberg @ 2007-11-12 19:48 UTC (permalink / raw)
To: Carlos Rica; +Cc: Junio C Hamano, git, Pierre Habouzit
In-Reply-To: <1b46aba20711120509l104792ebo4ea9a51c710510f3@mail.gmail.com>
On Mon, 2007-11-12 at 14:09 +0100, Carlos Rica wrote:
> 2007/11/10, Junio C Hamano <gitster@pobox.com>:
> > Carlos Rica <jasampler@gmail.com> writes:
...
> Then, Kristian, what are you willing to do in such case?
> It seems easier for me to concatenate of -m and -F options, even when
> both types are given. I don't know why "people" want multiple -m options,
> but I think that mixing -m and -F options could be interesting for them too.
> If someone know if this have been discussed and decided already,
> please give me the link.
I should be pretty easy to just append the contents of multiple fies,
even inter-mingled with -m options. We just do a callback like Johannes
just did for -m in builtin-commit.c for -F and append to the same
strbuf. strbuf_read() already appends, so the callback could look
something like:
static int opt_parse_F(const struct option *opt, const char *arg, int
unset)
{
struct strbuf *buf = opt->value;
if (!strcmp(arg, "-")) {
if (isatty(0))
fprintf(stderr, "(reading log message from
standard input)\n");
if (strbuf_read(&sb, 0, 0) < 0)
die("could not read log from standard input");
} else {
if (strbuf_read_file(&sb, logfile, 0) < 0)
die("could not read log file '%s': %s",
logfile, strerror(errno));
}
}
Shouldn't be too hard :)
Kristian
^ permalink raw reply
* Re: [PATCH 5/6] push: use same rules as git-rev-parse to resolve refspecs
From: Junio C Hamano @ 2007-11-12 19:51 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1194789709671-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> diff --git a/remote.c b/remote.c
> index bec2ba1..28d8eb7 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -519,10 +519,7 @@ static int count_refspec_match(const char *pattern,
> char *name = refs->name;
> int namelen = strlen(name);
>
> - if (namelen < patlen ||
> - memcmp(name + namelen - patlen, pattern, patlen))
> - continue;
> - if (namelen != patlen && name[namelen - patlen - 1] != '/')
> + if (!ref_abbrev_matches_full_with_rules(pattern, name, ref_rev_parse_rules))
> continue;
I vaguely recall that in the old round this check used to be
without negation '!' in the front. I think this version is
correct.
^ permalink raw reply
* Re: [PATCH 4/6] add ref_abbrev_matches_full_with_rules()
From: Junio C Hamano @ 2007-11-12 19:51 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11947897083265-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> +int ref_abbrev_matches_full_with_rules(const char *abbrev_name, const char *full_name, const char **rules)
> +{
> + const char **p;
> + const int abbrev_name_len = strlen(abbrev_name);
> +
> + for (p = rules; *p; p++) {
> + if (!strcmp(full_name, mkpath(*p, abbrev_name_len, abbrev_name))) {
> + return 1;
> + }
> + }
> +
> + return 0;
> +}
> +
How about calling this simply "ref_abbrev_matches()" or
"refname_match()" which is even shorter?
^ permalink raw reply
* Re: [PATCH 2/3] Implement --dirty for git-rebase--interactive.
From: Junio C Hamano @ 2007-11-12 19:51 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git
In-Reply-To: <1193952624-608-3-git-send-email-Simon.Sasburg@gmail.com>
Simon Sasburg <simon.sasburg@gmail.com> writes:
> +restore_dirty_state () {
> + lastmsg=$(git-rev-list HEAD^..HEAD --pretty=oneline | sed "s:[^ ]* ::")
> + if test "$lastmsg" = "REBASE--dirty: store index..workingtree diff"
> + then
> + echo "Restoring dirty index state"
> + git reset --mixed HEAD^
> + fi
> + lastmsg=$(git-rev-list HEAD^..HEAD --pretty=oneline | sed "s:[^ ]* ::")
> + if test "$lastmsg" = "REBASE--dirty: store HEAD..index diff"
> + then
> + echo "Restoring dirty working dir state"
> + git reset --soft HEAD^
> + fi
> +}
This forces the user to pay the two rev-list overhead, even when
running rebase without --dirty option. Can we avoid paying any,
when not giving the option?
Also it pollutes the reflog of the branch, but that won't be a
huge issue with Dscho's "detach HEAD while rebasing" patch.
^ permalink raw reply
* Re: [PATCH] Fix rev-list when showing objects involving submodules
From: Sam Vilain @ 2007-11-12 19:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0711112335020.4362@racer.site>
Johannes Schindelin wrote:
> The function mark_tree_uninteresting() assumed that the tree entries
> are blob when they are not trees. This is not so. Since we do
> not traverse into submodules (yet), the gitlinks should be ignored.
>
> diff --git a/revision.c b/revision.c
> index 931f978..81b5a93 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -69,7 +69,7 @@ void mark_tree_uninteresting(struct tree *tree)
> while (tree_entry(&desc, &entry)) {
> if (S_ISDIR(entry.mode))
> mark_tree_uninteresting(lookup_tree(entry.sha1));
> - else
> + else if (!S_ISGITLINK(entry.mode))
> mark_blob_uninteresting(lookup_blob(entry.sha1));
> }
>
>
Wouldn't it be better to check for what it is, rather than what it is not?
Sam.
^ permalink raw reply
* [PATCH] Make GIT_INDEX_FILE apply to git-commit
From: Remi Vanicat @ 2007-11-12 18:45 UTC (permalink / raw)
To: git
Currently, when committing, git-commit ignore the value of
GIT_INDEX_FILE, and always use $GIT_DIR/index. This patch
fix it.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
---
git-commit.sh | 2 +-
t/t7500-commit.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..7022e6c 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -26,7 +26,7 @@ refuse_partial () {
}
TMP_INDEX=
-THIS_INDEX="$GIT_DIR/index"
+THIS_INDEX="${GIT_INDEX_FILE-$GIT_DIR/index}"
NEXT_INDEX="$GIT_DIR/next-index$$"
rm -f "$NEXT_INDEX"
save_index () {
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index abbf54b..2aa6faf 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -93,4 +93,36 @@ test_expect_success 'commit message from file should override template' '
commit_msg_is "standard input msg"
'
+test_expect_success 'using alternate GIT_INDEX_FILE (1)' '
+
+ cp .git/index saved-index &&
+ (
+ echo some new content >file &&
+ GIT_INDEX_FILE=.git/another_index &&
+ export GIT_INDEX_FILE &&
+ git add file &&
+ git commit -m "commit using another index" &&
+ git diff-index --exit-code HEAD &&
+ git diff-files --exit-code
+ ) &&
+ cmp .git/index saved-index >/dev/null
+
+'
+
+test_expect_success 'using alternate GIT_INDEX_FILE (2)' '
+
+ cp .git/index saved-index &&
+ (
+ rm -f .git/no-such-index &&
+ GIT_INDEX_FILE=.git/no-such-index &&
+ export GIT_INDEX_FILE &&
+ git commit -m "commit using nonexistent index" &&
+ test -z "$(git ls-files)" &&
+ test -z "$(git ls-tree HEAD)"
+
+ ) &&
+ cmp .git/index saved-index >/dev/null
+
+'
+
test_done
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH 1/6] builtin-commit: fix author date with --amend --author=<author>
From: Johannes Schindelin @ 2007-11-12 20:12 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, gitster
In-Reply-To: <1194896334.2869.7.camel@hinata.boston.redhat.com>
Hi,
On Mon, 12 Nov 2007, Kristian H?gsberg wrote:
> On Sun, 2007-11-11 at 17:35 +0000, Johannes Schindelin wrote:
> > When amending a commit with a new author, the author date is taken
> > from the original commit.
>
> The new determine_author_info() should fix this. There was a problem
> earlier that Junio pointed out and I sent a patch to update
> determine_author_info() to do the right thing for amend commits. The
> test suite still pass without this patch, and if you look carefully a
> determine_author_info(), you can see it does the right thing:
>
> 1) Default to getenv for name, email and date
>
> 2) If a commit has been specified (-c, -C or --amend), we parse the
> author name, email and date from use_message_buffer, which holds the
> commit, overriding the values from getenv.
>
> 3) If --author has be passed, we parse name and email from the
> argument and override whatever name and email the two previous steps
> came up with.
>
> Then we add the author line to the commit buffer under construction
> based on these values.
>
> I suggest we back this patch out.
I agree.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix rev-list when showing objects involving submodules
From: Johannes Schindelin @ 2007-11-12 20:21 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, gitster
In-Reply-To: <4738AF60.90207@vilain.net>
Hi,
On Tue, 13 Nov 2007, Sam Vilain wrote:
> Johannes Schindelin wrote:
> > The function mark_tree_uninteresting() assumed that the tree entries
> > are blob when they are not trees. This is not so. Since we do
> > not traverse into submodules (yet), the gitlinks should be ignored.
> >
> > diff --git a/revision.c b/revision.c
> > index 931f978..81b5a93 100644
> > --- a/revision.c
> > +++ b/revision.c
> > @@ -69,7 +69,7 @@ void mark_tree_uninteresting(struct tree *tree)
> > while (tree_entry(&desc, &entry)) {
> > if (S_ISDIR(entry.mode))
> > mark_tree_uninteresting(lookup_tree(entry.sha1));
> > - else
> > + else if (!S_ISGITLINK(entry.mode))
> > mark_blob_uninteresting(lookup_blob(entry.sha1));
> > }
> >
> >
>
> Wouldn't it be better to check for what it is, rather than what it is not?
You mean something like
else if (S_ISREG(entry.mod) || S_ISLNK(entry.mod))
Hmm? Sure, I have no preference there.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] fast-import producing very deep tree deltas
From: Linus Torvalds @ 2007-11-12 20:26 UTC (permalink / raw)
To: Brian Downing; +Cc: Shawn O. Pearce, git
In-Reply-To: <20071112110354.GP6212@lavos.net>
On Mon, 12 Nov 2007, Brian Downing wrote:
>
> depths: count 135970 total 120567366 min 0 max 6035 mean 886.72 median 3 std_dev 1653.48
>
> Needless to say the pack that resulted was just about useless. Trying to
> repack it resulted in the "counting objects" phase running at about five
> objects per second.
Hmm. Quick hack: increase the delta cache window. The reason (I think) why
performance turns glacial with really deep delta chains is that it turns
into an O(n^2) thing when you don't hit in the delta cache, and your delta
depth is so deep that following a *single* delta chain will flush the
cache.
So I bet that making the delta cache bigger will "fix" it. You probably
don't have to make it 6000+ entries, but with the *median* being that
deep, making it 2k entries should improve it for most cases.
Obviously fastimport should be fixed to not do those insanely deep chains
too, but it might be a good idea to at least make the delta cache a bit
bigger by default, and perhaps have some config option for setting it.
Linus
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Linus Torvalds @ 2007-11-12 20:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711121412410.4362@racer.site>
On Mon, 12 Nov 2007, Johannes Schindelin wrote:
>
> On Mon, 12 Nov 2007, Jon Smirl wrote:
>
> > I'd like to do this sequence, but I can't figure out how without editing
> > the config file. There doesn't seem to be a simple command to move the
> > origin.
> >
> > git clone linus
> > move origin to digispeaker.git
>
> AKA "git config remote.origin.url <your-digispeaker-url-here>"
I really think people should at least also mention:
"Or just edit your .git/config file by hand"
Quite frankly, the latter is *easier* to do. It's really hard to remember
all the config entry names and then run "git config <entry> <value>". The
command itself may be fairly simple, but rememberign the options is *not*.
In contrast, when you open up .git/config in your editor, it's all almost
totally *obvious*.
So telling people to edit the config file is usually much more helpful in
the long run.
Linus
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Johannes Schindelin @ 2007-11-12 20:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jon Smirl, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711121229090.3062@woody.linux-foundation.org>
Hi,
On Mon, 12 Nov 2007, Linus Torvalds wrote:
> On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> >
> > On Mon, 12 Nov 2007, Jon Smirl wrote:
> >
> > > I'd like to do this sequence, but I can't figure out how without
> > > editing the config file. There doesn't seem to be a simple command
> > > to move the origin.
> > >
> > > git clone linus
> > > move origin to digispeaker.git
> >
> > AKA "git config remote.origin.url <your-digispeaker-url-here>"
>
> I really think people should at least also mention:
>
> "Or just edit your .git/config file by hand"
FWIW I agree. The intent of git-repo-config (as it was named then) was to
have a program for _scripts_ to use.
But for some reasons, people on IRC refuse to edit .git/config by hand.
*sigh* Will have to relearn giving proper help.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix rev-list when showing objects involving submodules
From: Linus Torvalds @ 2007-11-12 20:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Sam Vilain, git, gitster
In-Reply-To: <Pine.LNX.4.64.0711122020270.4362@racer.site>
On Mon, 12 Nov 2007, Johannes Schindelin wrote:
>
> You mean something like
>
> else if (S_ISREG(entry.mod) || S_ISLNK(entry.mod))
>
> Hmm? Sure, I have no preference there.
Maybe more along the line of something like this?
In general, I suspect we should try to start moving away from using the
"S_ISLNK()" like things for internal git state. It was a mistake to just
assume the numbers all were same across all systems in the first place.
So this just converts to the "object_type", and then uses a case
statement.
Linus
---
builtin-pack-objects.c | 2 +-
revision.c | 11 +++++++++--
tree-walk.h | 7 +++++++
3 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 545ece5..4f44658 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -990,7 +990,7 @@ static void add_pbase_object(struct tree_desc *tree,
return;
if (name[cmplen] != '/') {
add_object_entry(entry.sha1,
- S_ISDIR(entry.mode) ? OBJ_TREE : OBJ_BLOB,
+ object_type(entry.mode),
fullname, 1);
return;
}
diff --git a/revision.c b/revision.c
index 931f978..c054a82 100644
--- a/revision.c
+++ b/revision.c
@@ -67,10 +67,17 @@ void mark_tree_uninteresting(struct tree *tree)
init_tree_desc(&desc, tree->buffer, tree->size);
while (tree_entry(&desc, &entry)) {
- if (S_ISDIR(entry.mode))
+ switch (object_type(entry.mode)) {
+ case OBJ_TREE:
mark_tree_uninteresting(lookup_tree(entry.sha1));
- else
+ break;
+ case OBJ_BLOB:
mark_blob_uninteresting(lookup_blob(entry.sha1));
+ break;
+ default:
+ /* Subproject commit - not in this repository */
+ break;
+ }
}
/*
diff --git a/tree-walk.h b/tree-walk.h
index db0fbdc..903a7b0 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -7,6 +7,13 @@ struct name_entry {
unsigned int mode;
};
+static inline enum object_type object_type(unsigned int mode)
+{
+ return S_ISDIR(mode) ? OBJ_TREE :
+ S_ISGITLINK(mode) ? OBJ_COMMIT :
+ OBJ_BLOB;
+}
+
struct tree_desc {
const void *buffer;
struct name_entry entry;
^ permalink raw reply related
* wishlist: git info
From: Thomas Neumann @ 2007-11-12 20:30 UTC (permalink / raw)
To: git
Hi,
while git is pleasant to use in everyday work, there is one svn feature
which is miss dearly, namely "svn info". svn info can give information
about specific file objects, but I think its main feature is to use it
without any path and thus just describe the current project.
I use this a lot to quickly find out to which remote repository the
current directory belongs (yes, some work projects tend to look very
similar...) and what is the current state of the directory.
As a crude approximation, "git info" should print something like:
cat .git/config | grep url
git show | head -3
Probably not the most intelligent way to compute it, but you get the
idea. git info should give a brief overview over the current working
directory.
If there is consensus that this is a useful feature I can try to suggest
a patch (although honestly I would prefer that someone else does it, I
am not familiar with the git internals).
Thomas
^ permalink raw reply
* Re: [PATCH 5/6] push: use same rules as git-rev-parse to resolve refspecs
From: Steffen Prohaska @ 2007-11-12 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wav44z8.fsf@gitster.siamese.dyndns.org>
On Nov 12, 2007, at 8:51 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> diff --git a/remote.c b/remote.c
>> index bec2ba1..28d8eb7 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -519,10 +519,7 @@ static int count_refspec_match(const char
>> *pattern,
>> char *name = refs->name;
>> int namelen = strlen(name);
>>
>> - if (namelen < patlen ||
>> - memcmp(name + namelen - patlen, pattern, patlen))
>> - continue;
>> - if (namelen != patlen && name[namelen - patlen - 1] != '/')
>> + if (!ref_abbrev_matches_full_with_rules(pattern, name,
>> ref_rev_parse_rules))
>> continue;
>
> I vaguely recall that in the old round this check used to be
> without negation '!' in the front. I think this version is
> correct.
Yes. I started with a syntax inspired by strcmp. But later
the function got match in its name. I think returning a
match with 'true' is more natural; and reserving '-1, 0, 1'
for compare (as in strcmp). Therefore I changed the return
value.
With '!' is correct now. Without '!' was correct before.
Steffen
^ permalink raw reply
* [PATCH] Call refresh_cache() when updating the user index for --only commits.
From: Kristian Høgsberg @ 2007-11-12 20:48 UTC (permalink / raw)
To: gitster; +Cc: git, Kristian Høgsberg
We're guaranteeing the user that the index will be stat-clean after
git commit. Thus, we need to call refresh_cache() for the user index too,
in the 'git commit <paths>' case.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-commit.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 5011b8b..35205ef 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -109,6 +109,7 @@ static char *prepare_index(const char **files, const char *prefix)
/* update the user index file */
add_files_to_cache(verbose, prefix, files);
+ refresh_cache(REFRESH_QUIET);
if (write_cache(fd, active_cache, active_nr) || close(fd))
die("unable to write new_index file");
--
1.5.3.5.1762.g9a09d-dirty
^ permalink raw reply related
* Re: [PATCH 4/6] add ref_abbrev_matches_full_with_rules()
From: Steffen Prohaska @ 2007-11-12 20:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vve872qen.fsf@gitster.siamese.dyndns.org>
On Nov 12, 2007, at 8:51 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> +int ref_abbrev_matches_full_with_rules(const char *abbrev_name,
>> const char *full_name, const char **rules)
>> +{
>> + const char **p;
>> + const int abbrev_name_len = strlen(abbrev_name);
>> +
>> + for (p = rules; *p; p++) {
>> + if (!strcmp(full_name, mkpath(*p, abbrev_name_len,
>> abbrev_name))) {
>> + return 1;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>
> How about calling this simply "ref_abbrev_matches()" or
> "refname_match()" which is even shorter?
Yes. As you already did on pu. Thanks for cleaning up.
Steffen
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-12 20:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <alpine.LFD.0.9999.0711121229090.3062@woody.linux-foundation.org>
On 11/12/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> >
> > On Mon, 12 Nov 2007, Jon Smirl wrote:
> >
> > > I'd like to do this sequence, but I can't figure out how without editing
> > > the config file. There doesn't seem to be a simple command to move the
> > > origin.
> > >
> > > git clone linus
> > > move origin to digispeaker.git
> >
> > AKA "git config remote.origin.url <your-digispeaker-url-here>"
>
> I really think people should at least also mention:
>
> "Or just edit your .git/config file by hand"
>
> Quite frankly, the latter is *easier* to do. It's really hard to remember
> all the config entry names and then run "git config <entry> <value>". The
> command itself may be fairly simple, but rememberign the options is *not*.
I finally got everything working. There is still some issue where I
need to run update-server-info manually. The error messages at the
client side when update-server-info needs to be run are not useful.
This sequence does work:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
digispeaker
cd digispeaker
git config remote.origin.url
http://git.digispeaker.com/projects/digispeaker-kernel.git
git pull
Should we allow this instead:
git remote add origin
http://git.digispeaker.com/projects/digispeaker-kernel.git
and print a message saying the origin was changed? That would teach
people more about how remotes work.
I did need to go back to my server and clone kernel.org first, then
push my changes into it. That step is necessary so that my changes
don't end up in the giant pack along with the base kernel.
It is also a requirement to compile the git tools with NO_MMAP if
there are going to work in a shared hosting environment like
dreamhost. NO_MMAP is the key, changing git config doesn't help.
After my initial clone from kernel.org it only takes a minute now to
pull my in changes.
>
> In contrast, when you open up .git/config in your editor, it's all almost
> totally *obvious*.
>
> So telling people to edit the config file is usually much more helpful in
> the long run.
>
> Linus
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-12 20:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711122040350.4362@racer.site>
On 11/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Linus Torvalds wrote:
>
> > On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> > >
> > > On Mon, 12 Nov 2007, Jon Smirl wrote:
> > >
> > > > I'd like to do this sequence, but I can't figure out how without
> > > > editing the config file. There doesn't seem to be a simple command
> > > > to move the origin.
> > > >
> > > > git clone linus
> > > > move origin to digispeaker.git
> > >
> > > AKA "git config remote.origin.url <your-digispeaker-url-here>"
> >
> > I really think people should at least also mention:
> >
> > "Or just edit your .git/config file by hand"
>
> FWIW I agree. The intent of git-repo-config (as it was named then) was to
> have a program for _scripts_ to use.
>
> But for some reasons, people on IRC refuse to edit .git/config by hand.
> *sigh* Will have to relearn giving proper help.
It is eaiser to put
git config remote.origin.url
http://git.digispeaker.com/projects/digispeaker-kernel.git
in a cookbook web page sequence than say edit the config file by hand.
I added the cookbook sequence to my git project page.
http://git.digispeaker.com/
Without cloning from kernel.org first it takes an hour to clone from
dreamhost, but what do you want for $5/mth. I'll more to a better host
when traffic picks up.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Fix a strchrnul() related build error
From: Emil Medve @ 2007-11-12 21:01 UTC (permalink / raw)
To: gitster, ae, git; +Cc: Emil Medve
Systems/environments without glibc (such as CygWin), and as a consequence whithout the
__GLIBC_PREREQ() macro, fail to build with the following error message:
CC git.o
In file included from builtin.h:4,
from git.c:1:
git-compat-util.h:187:48: missing binary operator before token "("
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
Here is a relevant comment from my Linux box features.h:
/* Convenience macros to test the versions of glibc and gcc.
Use them like this:
#if __GNUC_PREREQ (2,8)
... code requiring gcc 2.8 or later ...
#endif
Note - they won't work for gcc1 or glibc1, since the _MINOR macros
were not defined then. */
My CygWin gcc version is:
$ gcc -dumpversion
3.4.4
This applies to next
git-compat-util.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 3d147b6..c4ed308 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -184,7 +184,13 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
const void *needle, size_t needlelen);
#endif
-#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
+#ifndef __GLIBC_PREREQ
+#define NO_STRCHRNUL
+#elif !__GLIBC_PREREQ(2, 1)
+#define NO_STRCHRNUL
+#endif
+
+#ifdef NO_STRCHRNUL
#define strchrnul gitstrchrnul
static inline char *gitstrchrnul(const char *s, int c)
{
--
1.5.3.5.1466.gfa36
^ permalink raw reply related
* Re: [PATCH] Fix rev-list when showing objects involving submodules
From: Johannes Schindelin @ 2007-11-12 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Sam Vilain, git, gitster
In-Reply-To: <alpine.LFD.0.9999.0711121231570.3062@woody.linux-foundation.org>
Hi,
On Mon, 12 Nov 2007, Linus Torvalds wrote:
> On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> >
> > You mean something like
> >
> > else if (S_ISREG(entry.mod) || S_ISLNK(entry.mod))
> >
> > Hmm? Sure, I have no preference there.
>
> Maybe more along the line of something like this?
>
> In general, I suspect we should try to start moving away from using the
> "S_ISLNK()" like things for internal git state. It was a mistake to just
> assume the numbers all were same across all systems in the first place.
>
> So this just converts to the "object_type", and then uses a case
> statement.
Sure. Just add the test from my patch, and we're fixed.
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