* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Johannes Sixt @ 2007-11-12 16:51 UTC (permalink / raw)
To: Ping Yin; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <46dff0320711120839q7fc0542frd90a396237c144bf@mail.gmail.com>
Ping Yin schrieb:
> On Nov 13, 2007 12:13 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
>>> There is already 'status.color', I suggest the configuration to become
>>> 'status.submoduleSummary'.
>> You could make this variable even a numeric one. Saying how many lines
>> you want to have maximally (-1 meaning unlimited).
> Good idea.
> However, there is a problem about limiting the lines of commit
> summary: if there are 50 backwards and 50 forwards, and summary lines
> are limited to 50 lines. How to display? 25 backwards, 25 forwards or
> only 50 backwards?
Just use git log --left-right --topo-order, then you can easily insert -$n,
and git-log will decide where it cuts off the lists.
However, --left-right won't reverse one of the list, like you did.
-- Hannes
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Brian Gernhardt @ 2007-11-12 16:53 UTC (permalink / raw)
To: Ping Yin; +Cc: Ralf Wildenhues, git
In-Reply-To: <46dff0320711120717gf8a67cdn2b6bdaa9cfa29218@mail.gmail.com>
On Nov 12, 2007, at 10:17 AM, Ping Yin wrote:
> I just guess '\r' is need for Mac OS because i havn't Mac OS
> environment.
> BTW, how to add a literal carriage return?
OS X's command line environment is modeled after BSD and uses the nice
and sane \n as a line ending. And since earlier Mac OS versions (that
did use \r) don't have a command line, I don't see people using git on
them.
~~ Brian
^ permalink raw reply
* Re: What is the idea for bare repositories?
From: David Kastrup @ 2007-11-12 16:54 UTC (permalink / raw)
To: git
In-Reply-To: <fh9vgu$u75$1@ger.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> David Kastrup wrote:
>
>> Bruno Cesar Ribas <ribas@c3sl.ufpr.br> writes:
>>
>>> A bare repository is the way to publish your changes to the public.
>>> git-daemon and http-clones use a bare repository that only contains
>>> adminsitrative files.
> [...]
>>
>> Fine. So why don't the following commands complain? Apart from
>> git-reset without arguments (which could probably get along without a
>> working dir), they are supposed to employ a working directory.
>>
>>> On Mon, Nov 12, 2007 at 02:11:58PM +0100, David Kastrup wrote:
>>>>
>>>> I have a repository declared as bare. Some commands treat it as such,
>>>> other's don't. For example, I get
>>>>
>>>> git-diff [no complaint]
>>>> git-reset [no complaint]
>>>> git-reset --hard
>>>> HEAD is now at db862c1... installmanager.sh: setze GIT_WORK_TREE
>
> git-diff can compare tree and tree, or tree and index; only for
> comparing tree and files of index and files it needs working dir.
Well, if called without arguments (as above), it compares tree and
index. So it should complain about not having a tree. It doesn't.
> git-reset resets only refs and index. git-reset --hard resets also
> files, so it needs working directory. Perhaps it should fail
> completely and not only after doing mixed (non-hard) reset if we are
> in bare repository.
Please reread the above: it does not fail at all. Neither before nor
after the mixed reset.
--
David Kastrup
^ permalink raw reply
* [PATCH] git-svn: Document the `create-ignore', `propget' and `proplist' subcommands.
From: Benoit Sigoure @ 2007-11-12 17:13 UTC (permalink / raw)
To: git; +Cc: normalperson, Benoit Sigoure
In-Reply-To: <1192545412-10929-4-git-send-email-tsuna@lrde.epita.fr>
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
I forgot to do this when I added these options to git-svn, my bad, sorry about
that. I think mentioning the current limitation of the implementation of
propget and proplist is worthwhile, I wouldn't like to be surprised by this.
Moreover, this is the kind of thing that's going to be fixed (or rather
"enhanced" I should say), one day or another.
Documentation/git-svn.txt | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 488e4b1..0d5406d 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -182,6 +182,9 @@ Any other arguments are passed directly to `git log'
directories. The output is suitable for appending to
the $GIT_DIR/info/exclude file.
+'create-ignore'::
+ Create a .gitignore file per svn:ignore.
+
'commit-diff'::
Commits the diff of two tree-ish arguments from the
command-line. This command is intended for interoperability with
@@ -193,6 +196,16 @@ Any other arguments are passed directly to `git log'
repository (that has been init-ed with git-svn).
The -r<revision> option is required for this.
+'propget'::
+ Print the value of a property on a file or directory.
+ The current implementation needs access to the SVN repository to
+ perform this operation.
+
+'proplist'::
+ List all properties of a file or directory.
+ The current implementation needs access to the SVN repository to
+ perform this operation.
+
--
OPTIONS
--
1.5.3.5.654.gdd5ec
^ permalink raw reply related
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-12 17:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jan Wielemaker, git
In-Reply-To: <vpq3avbv2ju.fsf@bauges.imag.fr>
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.
Ciao,
Dscho
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-12 17:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711121635130.4362@racer.site>
On 11/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Jon Smirl wrote:
>
> > On 11/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > On Mon, 12 Nov 2007, Jon Smirl wrote:
> > >
> > > > jonsmirl@terra:~/foo$ git clone
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git ds
> > > > clone.....
> > >
> > > This sets up branch.master.{remote,merge} to {origin,master}.
>
> You haven't shown me that this is set correctly in your set up, and if it
> is, when it stops being correctly set up.
Running git update-server-info at the remote end fixed it.
I am using 'git push' to send changes, I though that was supposed to
update the server info automatically.
>
> Ciao,
> Dscho
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Bill Lear @ 2007-11-12 17:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Matthieu Moy, Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711121715090.4362@racer.site>
On Monday, November 12, 2007 at 17:15:51 (+0000) Johannes Schindelin 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.
We have wanted this behavior; I don't think it's so foolish. 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.
Bill
^ permalink raw reply
* Re: Cloning from kernel.org, then switching to another repo
From: Jon Smirl @ 2007-11-12 17:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <9e4733910711120921q651208cby1276426ccd4b5fa4@mail.gmail.com>
Actually, fetching from kernel.org first and then switching the origin
isn't helping. The host is http only since I can't get access to the
git network port. When I pushed up my local repo it ends up in one big
pack.
I do this:
git clone kernel.org
move the origin
git pull
-- it still pulls down the entire pack and takes an hour
Will this fix it?
at my remote host, first clone from kernel.org
then push my local changes?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Jon Loeliger @ 2007-11-12 17:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git List
In-Reply-To: <fh8609$umn$1@ger.gmane.org>
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. It is a very useful command,
and usable on systems where GUI isn't an option.
Thanks,
jdl
^ permalink raw reply
* 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
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