* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-12 17:30 UTC (permalink / raw)
To: Bill Lear; +Cc: Matthieu Moy, Jan Wielemaker, git
In-Reply-To: <18232.35893.243300.179076@lisa.zopyra.com>
Hi,
On Mon, 12 Nov 2007, Bill Lear wrote:
> We have an administrator create a new bare repo for us, and we populate
> it by pushing into it. It wold be nice if the administrator could
> create a bare repo and we could clone from it, and push to it to
> populate it, instead of cloning the bare repo from another repo that has
> already been (partly) populated.
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".
Besides, if you really want to work together, chances are that you do
_not_ want to start with <n> independent initial commits. So you need to
populate the repository before starting _anyway_.
Why are easy solutions so unattractive?
Ciao,
Dscho
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: David Kastrup @ 2007-11-12 17:32 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0?= =?ISO-8859-1?Q?711121715090.436?= =?ISO-8859-1?Q?2@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:
>>
>> > 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.
>> >> 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.
git-init does not perform sexual intercourse, either. I don't see why
geneticists should be relevant for determining what git-clone does.
--
David Kastrup
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Johannes Schindelin @ 2007-11-12 17:33 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Jakub Narebski, Git List
In-Reply-To: <1194888565.1335.1.camel@ld0161-tx32>
Hi,
On Mon, 12 Nov 2007, Jon Loeliger wrote:
> On Sun, 2007-11-11 at 18:16, Jakub Narebski wrote:
>
> > > c) show-branch: The output is terrifying without explanation
> >
> > I agree. I would replace it by gitk, or gui (git-gui / "git gui").
>
> 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".
> 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...
Ciao,
Dscho
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Nicolas Pitre @ 2007-11-12 17:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121715090.4362@racer.site>
On Mon, 12 Nov 2007, Johannes Schindelin wrote:
> Hi,
>
> 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)".
Nicolas
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Lars Hjemli @ 2007-11-12 17:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ping Yin, Git Mailing List
In-Reply-To: <47388344.6010008@viscovery.net>
On Nov 12, 2007 5:45 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Ping Yin schrieb:
> > On Nov 12, 2007 11:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >
> >> But at this time git-commit is about to be made a builtin, and since your
> >> implementation contains a lot of non-portable constructs ($'', >&) and a new
> >> dependency on awk (and, hence, has little chances of being accepted), I
> >> suggest that you stay tuned, and implement this in the forth-coming
> >> builtin-commit.c.
> > Implement this in shell scripts is just a piece of cake, but not so
> > easy in builtin-commit.c.
>
> I'm with you. But git-commit.sh is a dead horse, no matter how hard you beat it.
>
> BTW, maybe you can keep the log generation in a helper script,
> git-status--submodulesummary, and invoke that from builtin-commit.c. This
> way you get both: integration and ease of implementation.
Sorry for repeating myself, but IMVHO this belong in git-submodule.sh:
It can be useful as a standalone command, we get all submodule-related
commands isolated in a single place, and builtin-commit.c can of
course exec git-submodule to get the summary.
--
larsh
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-12 17:54 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matthieu Moy, Jan Wielemaker, git
In-Reply-To: <alpine.LFD.0.9999.0711121231150.21255@xanadu.home>
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.
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.
Try it. Create an empty repository. Then call "git ls-remote <path>" on
it. It's _empty_.
Ciao,
Dscho "who is bored with this discussion"
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Bill Lear @ 2007-11-12 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121727130.4362@racer.site>
On Monday, November 12, 2007 at 17:30:10 (+0000) Johannes Schindelin writes:
>Hi,
>
>On Mon, 12 Nov 2007, Bill Lear wrote:
>
>> We have an administrator create a new bare repo for us, and we populate
>> it by pushing into it. It wold be nice if the administrator could
>> create a bare repo and we could clone from it, and push to it to
>> populate it, instead of cloning the bare repo from another repo that has
>> already been (partly) populated.
>
>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".
>
>Besides, if you really want to work together, chances are that you do
>_not_ want to start with <n> independent initial commits. So you need to
>populate the repository before starting _anyway_.
>
>Why are easy solutions so unattractive?
Well, 1) to answer your first point: it's not soooo hard, but it's an
extra step that just seems unnecessary. 2) It's not the *easiest*
solution that one can think of, so people naturally complain: "why do
I have to push in the clutch AND select the gear"?
Bill
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-12 17:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Bill Lear, Jan Wielemaker, git
In-Reply-To: <vpq7iknqrtp.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.
Wrong. Wrong, wrong, wrong.
It was talking about _cloning_ an _empty_ repository. (Bare or not is not
interesting in this context.)
> 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.
Ciao,
Dscho
^ permalink raw reply
* 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
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