* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-12 18:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121755460.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 12 Nov 2007, Matthieu Moy wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > So you need to populate the repository before starting _anyway_.
>>
>> Last time I checked, the thread was talking about bare repository.
>
> Wrong. Wrong, wrong, wrong.
Repeating it 4 times doesn't make it correct. You can even try 5
times, it won't change.
Grep for "bare" in the following text:
,----
| Hi,
|
| 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?
|
| Ciao,
| Dscho
`----
And then, guess how I ended-up with that text (hint : cut-and-paste).
>> Perhaps you have a magic formula to populate a bare repository without
>> pushing to it from another repo, but I don't.
>
> No, but that was not what I was questioning. No, sir, not at all.
Perhaps you can reconsider this after reading the above.
--
Matthieu
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-12 18:06 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Bill Lear, Jan Wielemaker, git
In-Reply-To: <vpqy7d3pck0.fsf@bauges.imag.fr>
Hi,
> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
> >
> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >>
> >> > So you need to populate the repository before starting _anyway_.
> >>
> >> Last time I checked, the thread was talking about bare repository.
Look at the subject. "Cloning empty repositories."
Nuff said,
Dscho who sighs
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-12 18:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121804400.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
>> > On Mon, 12 Nov 2007, Matthieu Moy wrote:
>> >
>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >>
>> >> > So you need to populate the repository before starting _anyway_.
>> >>
>> >> Last time I checked, the thread was talking about bare repository.
>
> Look at the subject. "Cloning empty repositories."
Look at the content. "cloning a empty bare repository".
I insist that the content is the content that _YOU_ quoted, which is
the starting point of the discussion.
--
Matthieu -- who finds it hard to discuss with people only reading
subject in emails.
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Nicolas Pitre @ 2007-11-12 18:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121751100.4362@racer.site>
On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Nicolas Pitre wrote:
>
> > On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> >
> > > 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.
Well, that's an orthogonal question and I'm not providing any opinion
about that.
> 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.
So? Why couldn't you just do the 'git remote add' dance implicitly in
that case anyway?
Nicolas
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Matthieu Moy @ 2007-11-12 17:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121727130.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I don't see what is soooo hard with using git-remote in the repo you are
> pushing from. It's just a "git remote add origin <url>", and you can even
> use this to push right afterwards: "git push --all origin".
If "git remote add" is so easy, why does "git clone" set up the remote
for you?
And don't tell me that you didn't notice that "git clone" does more
than your proposed "git remote add origin ...".
> Besides, if you really want to work together, chances are that you do
> _not_ want to start with <n> independent initial commits.
So, what?
> So you need to populate the repository before starting _anyway_.
Last time I checked, the thread was talking about bare repository.
Perhaps you have a magic formula to populate a bare repository without
pushing to it from another repo, but I don't.
--
Matthieu
^ permalink raw reply
* Re: [PATCH v3] Make GIT_INDEX_FILE apply to git-commit
From: Remi Vanicat @ 2007-11-12 18:41 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vlk94d043.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Rémi Vanicat <vanicat@debian.org> writes:
>
>> @@ -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 () {
>
> This is just a "purist" question, but I wonder if we want to
> differentiate the case where GIT_INDEX_FILE is set to empty and
> GIT_INDEX_FILE is not set at all?
Well, It's my first patch to git, and I overlook it
> So, what I would suggest is:
>
> * Your "GIT_INDEX_FILE=... git-commit" test -- git-commit
> should not fail;
>
> + Test that the path you modified in the above commit (in this
> case, 'file') matches between index you used in the commit
> and the resulting commit;
>
> * Test that the path you modified in the above commit matches
> between the HEAD, the alternate index and the work tree (your
> latter test).
>
> + Test that the original index the above wanted to preserve was
> not clobbered by git-commit;
>
> + Test git-commit runs sensibly even when it is given a
> nonexistent file as GIT_INDEX_FILE.
>
> Perhaps like this, instead of your patch to t/t7500:
>
> 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
>
> '
Seem, good, I will use this.
--
Rémi Vanicat
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Jan Wielemaker @ 2007-11-12 18:55 UTC (permalink / raw)
To: git
In-Reply-To: <vpq7iknqrtp.fsf@bauges.imag.fr>
On Monday 12 November 2007 18:47:14 Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > I don't see what is soooo hard with using git-remote in the repo you are
> > pushing from. It's just a "git remote add origin <url>", and you can
> > even use this to push right afterwards: "git push --all origin".
>
> If "git remote add" is so easy, why does "git clone" set up the remote
> for you?
>
> And don't tell me that you didn't notice that "git clone" does more
> than your proposed "git remote add origin ...".
>
> > Besides, if you really want to work together, chances are that you do
> > _not_ want to start with <n> independent initial commits.
>
> So, what?
>
> > So you need to populate the repository before starting _anyway_.
>
> Last time I checked, the thread was talking about bare repository.
> Perhaps you have a magic formula to populate a bare repository without
> pushing to it from another repo, but I don't.
Hey guys, don't fight about the details. Just stick to
* Creating a bare empty repositiory is possible and a perfectly
valid way to create a shared repositiory.
* Clone and push is the natural way to modify it. At least to
me this was the obvious thing to do. Explicitely playing with
remotes is -as far as i'm concerned- lesson 2.
* If this cannot be done (but, what is wrong with an empty tree?)
at least
- git clone should *not* say it created a repository
- The documentation should have a note on that
Cheers --- Jan
^ permalink raw reply
* 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
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