* Re: [RFC (take 3)] Git User's Survey 2007
From: Asger Ottar Alstrup @ 2007-08-05 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <200708040250.55180.jnareb@gmail.com>
Jakub Narebski wrote:
> Open forum
>
> 1. What other comments or suggestions do you have that are not
> covered by the questions above?
I believe there is a need for hosting services of Git repositories for
commercial use.
With the Windows Git installer coming along, I know that I'd like to
switch our company from a SVN hosted at cvsdude.com or svnrepository.com
to a Git hosting service.
Maybe you could include a question about this?
Regards,
Asger Ottar Alstrup
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 9:32 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85myx6ba8n.fsf@lola.goethe.zz>
On Sun, Aug 05, 2007 at 11:29:12AM +0200, David Kastrup wrote:
> The main question is why I can't find this explained in this manner in
> the documentation. Are you going to put it in yourself, or should I
> attempt doing it?
I guess because nobody complained it wasn't there before. :) Some of the
information is a bit under-the-hood for most end-users, but obviously in
your case the lack of information was creating confusion about the
terms.
Why don't you take a stab at updating the documentation (since you are
the one who knows which parts were confusing you), and I will be more
than happy to help with making sure the changes are accurate.
-Peff
^ permalink raw reply
* Re: [PATCH] git-clone: use cpio's --quiet flag
From: Jeff King @ 2007-08-05 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v4pjefkdu.fsf@assigned-by-dhcp.cox.net>
On Sun, Aug 05, 2007 at 01:36:29AM -0700, Junio C Hamano wrote:
> > I see, though the hardlink warning is a bit much.
> >
> > $ git-clone /path/on/fs/one /path/on/fs/two
> > Initialized empty Git repository in /path/on/fs/two/.git/
> > Warning: -l asked but cannot hardlink to /path/on/fs/one/.git
> > 36634 blocks
>
> True; -l is not given explicitly in your example. Should be
> trivial to fix.
Ah, indeed, I had assumed that it came from cpio (which also uses the -l
flag!), but reading the code, it's us. Given that "-l" is now the
default, and we silently downgrade to copying anyway, I don't see the
point of having any warning at all. Unless, I guess, for those people
who are still using "-l" even though it's a noop.
-Peff
^ permalink raw reply
* GIT push to sftp (feature request)
From: pavlix @ 2007-08-05 9:05 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Hello
It would be very useful if git supported sftp urls to push to remote
repositories.
The use cases are obvious... you would only need ssh run on the other side,
which is usually available. One cannot or doesn't want to install git on
every machine where he wants his remote repository.
Git would also have to be able to create a remote repository (maybe an option
to push?).
Did I miss something?
Pavel Šimerda
P.S.: I am switching from bazaar-ng which can save so sftp and other protocols
--
Web: http://www.pavlix.net/
Jabber & E-mail: pavlix@pavlix.net
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Jeff King @ 2007-08-05 9:42 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <85myx7dwb3.fsf@lola.goethe.zz>
On Sat, Aug 04, 2007 at 07:49:36PM +0200, David Kastrup wrote:
> I can specify something like
>
> (info "(gcc) Extended Asm")
>
> and when you are reading mail in Emacs, you can click on that line and
> get to the respective page in a manual comprising hundreds of pages.
Ugh. A documentation referencing system that works only in one
particular editor, or with one particular documentation format?
Please, the net decided on a standard for referencing resources long
ago, and they are called URLs.
-Peff
^ permalink raw reply
* Re: Terminology question about remote branches.
From: David Kastrup @ 2007-08-05 9:44 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20070805093232.GC12507@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Aug 05, 2007 at 11:29:12AM +0200, David Kastrup wrote:
>
>> The main question is why I can't find this explained in this manner in
>> the documentation. Are you going to put it in yourself, or should I
>> attempt doing it?
>
> I guess because nobody complained it wasn't there before. :) Some of the
> information is a bit under-the-hood for most end-users, but obviously in
> your case the lack of information was creating confusion about the
> terms.
>
> Why don't you take a stab at updating the documentation (since you are
> the one who knows which parts were confusing you),
Well, one problem is that there simply _is_ no part of the
documentation where such an explanation would have a place. It does
not fit in the man pages of git-branch/git-commit, it has some passing
relation to the repository layout explanation (even though the latter
should not be something that the user has to read and understand for
basic operation), it may have some place in the user manual, but may
be a bit technical/long for that. Or one places it into another
isolated file and hopes that a user will stumble across it when in
need of the information.
Hm. Probably the usermanual is the best option in the current scheme
of things.
> and I will be more than happy to help with making sure the changes
> are accurate.
Thanks.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 9:46 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85fy2yb9jn.fsf@lola.goethe.zz>
On Sun, Aug 05, 2007 at 11:44:12AM +0200, David Kastrup wrote:
> Well, one problem is that there simply _is_ no part of the
> documentation where such an explanation would have a place. It does
> [...]
> Hm. Probably the usermanual is the best option in the current scheme
> of things.
I'm not too familiar with the usermanual, it having come about long
after I started with git. But I wonder if a subsection on "refs" under
the "Git internals" section might make sense.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Jeff King @ 2007-08-05 9:50 UTC (permalink / raw)
To: Steven Grimm
Cc: David Kastrup, Sam Ravnborg, Junio C Hamano, Linus Torvalds,
Ismail Dönmez, git
In-Reply-To: <46B4A35E.5040601@midwinter.com>
On Sun, Aug 05, 2007 at 12:03:42AM +0800, Steven Grimm wrote:
> Really? I find info a huge pain in the butt most of the time. I can't
> just do a simple text search for the information I want in the
> relevant manpage; I have to go navigating around to the appropriate
> subsection (and that's assuming I know where it is) and am forced to
> use the emacs-style pager whether I like it or not (not a big emacs
> fan here). It always ticks me off when I go to read the manpage for
> some command and it tells me to go read the info page if I want
> complete documentation.
I also find 'info' pages very painful to read. However, if you haven't
tried it, the "pinfo" viewer gives a much friendlier (IMHO) interface.
It's more or less based on the lynx interface.
http://pinfo.alioth.debian.org/
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 9:54 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <20070805094247.GE12507@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Aug 04, 2007 at 07:49:36PM +0200, David Kastrup wrote:
>
>> I can specify something like
>>
>> (info "(gcc) Extended Asm")
>>
>> and when you are reading mail in Emacs, you can click on that line
>> and get to the respective page in a manual comprising hundreds of
>> pages.
>
> Ugh. A documentation referencing system that works only in one
> particular editor,
That works in readers of the info format. Do HTML references work
outside of HTML readers?
> or with one particular documentation format?
>
> Please, the net decided on a standard for referencing resources long
> ago, and they are called URLs.
The last time I looked, URLs were not a common way to implement
bookmarks except in HTML, namely "with one particular documentation
format".
And you don't need an HTML reader to use those "resources" in HTML?
Get real.
Anyway, the referencing in _Texinfo_ gets translated into info
references in info formats, URL bookmarks in HTML, PDF links in PDF
and a textual description (since you can't let a URL point into a
section of a plain text file) in plain text output. All those are
_common_ ways of making references, and certainly "the net" has not
decided to pick any of those exclusively.
That the particular format "info" _also_ is able to represent the
respective information originally written into _Texinfo_ source is
hardly a disadvantage.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Jeff King @ 2007-08-05 9:59 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <85abt6b91w.fsf@lola.goethe.zz>
On Sun, Aug 05, 2007 at 11:54:51AM +0200, David Kastrup wrote:
> >> (info "(gcc) Extended Asm")
> >>
> >> and when you are reading mail in Emacs, you can click on that line
> >> and get to the respective page in a manual comprising hundreds of
> >> pages.
> >
> > Ugh. A documentation referencing system that works only in one
> > particular editor,
>
> That works in readers of the info format. Do HTML references work
> outside of HTML readers?
I'm not talking about the _format_, I'm talking about the _referencing
system_. In other words, because URLs are a standard, there are
thousands of programs which recognize them and can find the resource
they mention (which in turn, may spawn an info reader, an html reader,
or some other interpreter).
What software is going to recognize (info "(gcc) Extended Asm") in your
email and realize that it's a reference to another document? None,
except emacs.
Though I don't especially like the info format or readers, my argument
here isn't against it. It is against the feature you mentioned being a
substantial benefit, since a large part of the world isn't reading their
email in emacs.
-Peff
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 10:05 UTC (permalink / raw)
To: David Kastrup; +Cc: Sean, git
In-Reply-To: <85ejijgzzg.fsf@lola.goethe.zz>
On Sat, Aug 04, 2007 at 04:01:55PM +0200, David Kastrup wrote:
> So --track does not set up a tracking branch, but makes a local
> _following_ branch _refer_ to a tracking branch.
A minor nit, but --track sets up a local following branch to refer to a
remote's branch, _not_ to the tracking branch. In other words, if you
look at the config:
[branch "master"]
remote = origin
merge = refs/heads/master
It does _not_ reference the tracking branch
"refs/remotes/origin/master", but rather the remote's name for the
branch "refs/heads/master".
There was much discussion of this topic, but the general idea was not to
require remote tracking branches for this feature to be used (a position
I somewhat disagree with, but then I'm not the maintainer).
-Peff
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Steffen Prohaska @ 2007-08-05 10:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Kastrup, git
In-Reply-To: <7v8x8qfnev.fsf@assigned-by-dhcp.cox.net>
On Aug 5, 2007, at 9:31 AM, Junio C Hamano wrote:
> David Kastrup <dak@gnu.org> writes:
>
>> I am trying to dig through man-pages and user manual and trying to
>> match them with reality. I seem to have a hard time. My current
>> understanding (which definitely differs from the documented state) is
>> that there are two types of branches, local and remote branches, and
>> both types of branches can be remote-tracking (it may not be possible
>> to have a non-remote-tracking remote branch, though).
>
> I think we have a brief discussion on #git before you brought
> this up ;-)
>
> - local branches -- we know what they are.
>
> - remote tracking branches -- refs that appear in refs/remotes/
> in the current world order; they are updated only by copying
> the corresponding local branches at the remote site, and are
> meant to "keep track of what _they_ are doing". In olden
> days before 1.5.0 with non separate remote layout,
> 'refs/heads/origin' branch, and all the non default branches,
> were treated this way as well. You were not supposed to make
> commit on them (because of the above "keep track of" reason),
> and having them under refs/heads were too confusing, which
> was the reason the separate remote layout was invented.
The current user manual defines this case in the glossary as
'tracking branch' (without remote), but mostly uses
'remote-tracking branch' at other places. Tracking branch
and remote-tracking branch seem to be equivalent. And I think
we should leave it this way.
> You can have a local branch that is created by forking off of a
> remote tracking branch, with the intention to "build on top" of
> the corresponding remote tracking brach. You can create such a
> branch and mark it as such with --track option introduced in
> v1.5.1 timeperiod. This is a relatively new concept, but many
> people find it useful. We do not have the official term to call
> this concept, and some people have misused the term "remote
> tracking branches" to describe this, which made things very
> confusing.
>
> We would need an official terminology for it.
Something like 'automerging branch', and replace options with
'--automerge/--no-automerge'?
I'm not fully convinced of this idea because it may be
technically correct but doesn't really reflect the intention of
'building on top' of the remote tracking branch.
Steffen
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 10:10 UTC (permalink / raw)
To: Sean; +Cc: David Kastrup, git
In-Reply-To: <20070804104851.162d7e00.seanlkml@sympatico.ca>
On Sat, Aug 04, 2007 at 10:48:51AM -0400, Sean wrote:
> The config file does not record the remote-tracking-branch, instead
> it explicitly records the remote repository information. So it sure
> appears that if you add the --track option, it _does_ make the local
> branch track a remote directly. Thus it's hard to call it anything
> but what you labelled it, a local tracking-branch.
>
> While I thought i had a handle on this, i'm now officially more
> confused than you; hopefully someone with knowledge of the guts
> of Git will speak up. Junio Help!
There is some discussion in this thread:
http://thread.gmane.org/gmane.comp.version-control.git/35090/focus=35265
-Peff
^ permalink raw reply
* Re: git-gui console app ?
From: Jeff King @ 2007-08-05 10:19 UTC (permalink / raw)
To: Erik Colson; +Cc: Jonas Fonseca, git
In-Reply-To: <20070804123834.GA3036@Mac2.local>
On Sat, Aug 04, 2007 at 02:38:34PM +0200, Erik Colson wrote:
> > By default, it will show the changes between your working tree and the
> > index (i.e., changed but not updated). You can show the diff of "updated
> > but not commited" with "git-diff --cached".
>
> yep that is the info I would like to browse in a way git-gui does it...
> showing a list of the files in the diff, and letting the user select a
> file to show the part of the diff for that file.
Ah, I see. There is a status mode for tig (tig -S), but you can't jump
to the diff of a particular file. It shouldn't be that difficult to add
for somebody familiar with the tig codebase, but I am not such a
somebody.
Jonas, am I right that this should be a one-liner? If you can point me
in the right direction, I can try to take a closer look, but I'm having
trouble following the code.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 10:20 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <20070805095928.GA15949@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Aug 05, 2007 at 11:54:51AM +0200, David Kastrup wrote:
>
>> >> (info "(gcc) Extended Asm")
>> >>
>> >> and when you are reading mail in Emacs, you can click on that line
>> >> and get to the respective page in a manual comprising hundreds of
>> >> pages.
>> >
>> > Ugh. A documentation referencing system that works only in one
>> > particular editor,
>>
>> That works in readers of the info format. Do HTML references work
>> outside of HTML readers?
>
> I'm not talking about the _format_, I'm talking about the _referencing
> system_. In other words, because URLs are a standard, there are
> thousands of programs which recognize them and can find the resource
> they mention (which in turn, may spawn an info reader, an html reader,
> or some other interpreter).
Well, just for kicks I let firefox loose on
info:gcc#Extended Asm
It passed this off to the GNOME help browser, which displayed
"Loading...", used up 4 seconds of CPU time and 100M of memory, and
then hanged itself with a spinning cursor.
Interesting. Starting the help browser manually and typing the URL
in, however, works. It just seems to suicide when firefox tells it
about URLs.
> What software is going to recognize (info "(gcc) Extended Asm") in
> your email and realize that it's a reference to another document?
> None, except emacs.
Sure. So use the above syntax.
> Though I don't especially like the info format or readers, my
> argument here isn't against it. It is against the feature you
> mentioned being a substantial benefit, since a large part of the
> world isn't reading their email in emacs.
So write it as a URL, if you want to.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: Jeff King @ 2007-08-05 10:22 UTC (permalink / raw)
To: David Kastrup
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <851weib7v3.fsf@lola.goethe.zz>
On Sun, Aug 05, 2007 at 12:20:32PM +0200, David Kastrup wrote:
> Well, just for kicks I let firefox loose on
>
> info:gcc#Extended Asm
OK, I didn't know there was a URL style defined for info. Thanks for
pointing it out.
-Peff
^ permalink raw reply
* Benchmarking git-add vs git-ls-files+update-index (was: way to automatically add untracked files?)
From: David Kastrup @ 2007-08-05 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, git
In-Reply-To: <85fy2ycu7n.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>>> ... (except, as we found out last week, we've had a huge
>>> performance regression, so that's actually a really slow way to do it, and
>>> so it's actually faster to do
>>>
>>> git ls-files -o | git update-index --add --stdin
>>> git commit -a
>>>
>>> instead...
>>
>> Is it still the case after the fix in rc4? Other than the
>> theoretical "on multi-core, ls-files and update-index can run in
>> parallel" performance boost potential,
dak@lola:/home/tmp/texlive$ git-init
Initialized empty Git repository in .git/
dak@lola:/home/tmp/texlive$ time git --work-tree=/usr/local/texlive/2007/texmf-dist add .
real 9m36.256s
user 2m2.408s
sys 0m25.874s
dak@lola:/home/tmp/texlive$ time git --work-tree=/usr/local/texlive/2007/texmf-dist add .
real 0m34.161s
user 0m0.448s
sys 0m2.212s
[So the rc4 fix seems to have made it.]
dak@lola:/home/tmp/texlive$ rm -rf .git;git-init
Initialized empty Git repository in .git/
dak@lola:/home/tmp/texlive$ time git --work-tree=/usr/local/texlive/2007/texmf-dist ls-files -z -m -o .|(cd /usr/local/texlive/2007/texmf-dist;git --git-dir=/home/tmp/texlive/.git update-index --add -z --stdin)
real 8m9.370s
user 2m1.172s
sys 0m25.138s
dak@lola:/home/tmp/texlive$ time git --work-tree=/usr/local/texlive/2007/texmf-dist ls-files -z -m -o .|(cd /usr/local/texlive/2007/texmf-dist;git --git-dir=/home/tmp/texlive/.git update-index --add -z --stdin)
real 6m4.447s
user 0m16.801s
sys 0m12.333s
dak@lola:/home/tmp/texlive$
[Hm. Maybe "modified" files are not what I think they are?]
dak@lola:/home/tmp/texlive$ time git --work-tree=/usr/local/texlive/2007/texmf-dist ls-files -z -o .|(cd /usr/local/texlive/2007/texmf-dist;git --git-dir=/home/tmp/texlive/.git update-index --add -z --stdin)
real 6m0.120s
user 0m16.977s
sys 0m12.653s
[No, doesn't help.]
[Just for kicks, let's try getting the Linux scheduler out of our hair
in the initial case.]
dak@lola:/home/tmp/texlive$ time git --work-tree=/usr/local/texlive/2007/texmf-dist ls-files -z -m -o .|dd bs=8k|(cd /usr/local/texlive/2007/texmf-dist;git --git-dir=/home/tmp/texlive/.git update-index --add -z --stdin)
201+1 records in
201+1 records out
1650230 bytes (1.7 MB) copied, 513.125 seconds, 3.2 kB/s
real 8m45.088s
user 2m2.052s
sys 0m25.870s
[Hm, does more damage than it helps.]
So in summary: git-ls-files -m is apparently lacking the optimization
of git-add for unchanged inodes. Bad. Using it together with
git-update-index in the initial case saves some time over git-add, but
not breathtakingly so. This is on a single core.
Most of the time is spent waiting for I/O. Threaded execution should
supposedly help in having less waiting time, but at least in this
combination, the payoff does not seem overwhelming.
One should mention that the stuff I tested it on is actually sitting
on a reiserfs file system (though the repository is on ext3).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 10:40 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <20070805102242.GA17000@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Aug 05, 2007 at 12:20:32PM +0200, David Kastrup wrote:
>
>> Well, just for kicks I let firefox loose on
>>
>> info:gcc#Extended Asm
>
> OK, I didn't know there was a URL style defined for info.
Neither did I, actually. If anybody would actually use them, I'd have
to teach firefox to pass them off to Emacs.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Steffen Prohaska @ 2007-08-05 10:56 UTC (permalink / raw)
To: Jeff King; +Cc: David Kastrup, Sean, git
In-Reply-To: <20070805100532.GG12507@coredump.intra.peff.net>
On Aug 5, 2007, at 12:05 PM, Jeff King wrote:
> On Sat, Aug 04, 2007 at 04:01:55PM +0200, David Kastrup wrote:
>
>> So --track does not set up a tracking branch, but makes a local
>> _following_ branch _refer_ to a tracking branch.
>
> A minor nit, but --track sets up a local following branch to refer
> to a
> remote's branch, _not_ to the tracking branch. In other words, if you
> look at the config:
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> It does _not_ reference the tracking branch
> "refs/remotes/origin/master", but rather the remote's name for the
> branch "refs/heads/master".
>
> There was much discussion of this topic, but the general idea was
> not to
> require remote tracking branches for this feature to be used (a
> position
> I somewhat disagree with, but then I'm not the maintainer).
Interesting. I didn't even recognize this detail up to know. It was
somewhat
beyond my imagination that I could have a local following/automerging
branch that is directly referring to a branch in a remote repo, without
have a remote-tracking branch.
How could I create such a setup in the first place?
git branch --track something origin/something
git checkout --track -b something origin/something
are obvious, but what to say if I don't have origin/something?
Steffen
^ permalink raw reply
* $GIT_DIR usage
From: Dan Zwell @ 2007-08-05 9:58 UTC (permalink / raw)
To: git
Hi, I had a question about $GIT_DIR. That is to say, it doesn't seem to
work. I am using Git 1.5.2.4. See the following: (all the commands I
tried besides "git-init" failed).
$ export GIT_DIR="`pwd`/.git_public"
$ git init
warning: templates not found /usr/share//git-core/templates/
Initialized empty Git repository in /home/user/temp/.git_public/
$ echo > new_file
$ git add new_file
fatal: add must be run in a work tree
$ git commit -a
fatal: /usr/bin/git-commit cannot be used without a working tree.
$ git commit
fatal: /usr/bin/git-commit cannot be used without a working tree.
$
Is $GIT_DIR not meant to be used this way? Does it have a different
purpose / use case, or is this just a bug?
Thanks,
Dan
^ permalink raw reply
* Bootstraper for Git Dev Environment for Windows (Light version)
From: Dmitry Kakurin @ 2007-08-05 11:00 UTC (permalink / raw)
To: git
Please give it a try and tell me how it works for you:
http://msysgit.googlecode.com/files/GitMe-1.exe (1.6 MB)
Here is the idea that this installer implements:
Now that we have both msysGit and mingw git as .git repositories here is what we can do:
* Create a small bootstrap download with git-clone and it's dependencies
* After you download and run it, it will first clone msysGit repository
* Then it will clone mingw.git repository
* Start msys and run 'make install' for git
* Clear leftovers of bootstrap
There are huge advantages IMHO:
* the bootstrap download is very small (1.6MB) and will (almost) never change
* msysGit will not contain git sources at all (this causes very inconvenient overlap between 2 repositories right now)
* after initial setup process user will be left with 2 fully-functioning repositories (msysGit and git), so staying up to date with
both mingw.git and msys dev/build environment will be trivial: just use git pull for both.
If we want to stick with this installer here is what we need to do:
* Remove /git directory from msysGit.git
* Bring mingw.git up to date so we can remove patching step from installer
If you want to change it/see how it works internally do the following:
* start the GitMe.exe
* answer yes to popup dialog
* cmd window will open and ask you for installation directory, don't enter anything, just leave this window alone
At this point all installer files will be unpacked in %temp%\RarSFX0\GitMe.
Setup.cmd is the one to look at/tweak.
To repack just use any compressor that can create SFX archives that can also start a file execution. I've used WinRAR.
But the whole idea is that this bootstrap download should require very little/no tweaking. All changes should happen in msysgit.git
and mingw.git.
- Dmitry
^ permalink raw reply
* Re: Terminology question about remote branches.
From: Jeff King @ 2007-08-05 11:02 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: David Kastrup, Sean, git
In-Reply-To: <85172807-B7EB-47DD-813E-FAF5894E1190@zib.de>
On Sun, Aug 05, 2007 at 12:56:49PM +0200, Steffen Prohaska wrote:
> beyond my imagination that I could have a local following/automerging
> branch that is directly referring to a branch in a remote repo, without
> have a remote-tracking branch.
>
> How could I create such a setup in the first place?
>
> git branch --track something origin/something
> git checkout --track -b something origin/something
>
> are obvious, but what to say if I don't have origin/something?
I believe the --track setup uses the tracking branches to figure out
which remote/branch combo to track. To do it without a remote tracking
branch, you would have to add the lines to your .git/config manually.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kastrup @ 2007-08-05 11:23 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, Steven Grimm, Sam Ravnborg, Junio C Hamano,
Ismail D?nmez, git
In-Reply-To: <85ps229sck.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Aug 05, 2007 at 12:20:32PM +0200, David Kastrup wrote:
>>
>>> Well, just for kicks I let firefox loose on
>>>
>>> info:gcc#Extended Asm
>>
>> OK, I didn't know there was a URL style defined for info.
>
> Neither did I, actually. If anybody would actually use them, I'd have
> to teach firefox to pass them off to Emacs.
The details can be found in <URL:man:uri(7)>.
If you find this syntax referring to a man page weird, you should
probably not complain about me writing (info "(gcc) Extended Asm") as
a reference.
When there are few readers of a format, it is easier to use a
"natural" spelling.
Anyway, I have seen in a posting about mathematics someone write an
equation including sqrt(3) and saw Emacs highlight this expression.
So I clicked on it. And Emacs opened the man-page. Definitely not
what I had expected...
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: way to automatically add untracked files?
From: Steffen Prohaska @ 2007-08-05 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, git
In-Reply-To: <7v4pjeioi6.fsf@assigned-by-dhcp.cox.net>
On Aug 5, 2007, at 6:39 AM, Junio C Hamano wrote:
>
> Adding _new_ files, unless you are just beginning a new project,
> are much more rare than updating modified files that you are
> already tracking; and "git add new-file..." is what people
> usually use for the former. "git add ." is almost always the
> "initial import" and not used later (after all you ought to know
> what files you are creating and controlling ;-)). You get into
> an illusion that that is often used, only when you have just
> started. As your project progresses, that feeling will fade
> away.
I exactly need the functionality that Miles is describing for
the following good reason:
Mac OS X has the notion of a bundle, which is a directory that
contains related files that are fully controlled by the application
that is writing that bundle. The bundle functionality is
directly supported by the OS and most applications save their
data as bundles. For example on Mac OS X, the Openoffice format,
which packs related files in a zip file, would just be a directory
with all related files grouped together (no ZIP archive needed).
So here is what I need: I want to be able to track a directory
with all its contents. The data inside the directory are not
under my control. It's only the directory that matters for me.
Git is already quite good at that because it doesn't need to
place anything inside the opaque directory! Subversion for example
has no chance because it clutters the directory with .svn
directories, which will be removed by the next Save (an
application first creates a new temporary directory, stores
all data there, moves the old directory to a backup location,
and renames the new directory to the final destination only
if no problems occurred).
When I started with git I figured out that
git-ls-files -z --others dir | git-update-index --add -z --stdin
git commit -a
does the job for me. Would
git add dir
git add -u dir
git commit
be equivalent, but restricted to the changes in dir?
Steffen
^ permalink raw reply
* How to figure out what 'git push' would do?
From: Steffen Prohaska @ 2007-08-05 11:37 UTC (permalink / raw)
To: Git Mailing List
How can I check what a 'git push' would do, without
actually doing it?
Is there something like 'git push --dry-run', similar
to 'rsync --dry-run'?
Steffen
^ 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