* Re: The MIT error
From: Andreas Ericsson @ 2005-10-25 13:52 UTC (permalink / raw)
To: GIT Mailing List
In-Reply-To: <200510251340.j9PDeGGt006248@laptop11.inf.utfsm.cl>
Horst von Brand wrote:
> Morten Welinder <mwelinder@gmail.com> wrote:
>
>>After the isspace/BSD conflict I looked into what reserved symbols are
>>being used by git. Quite a few, it turns out.
>
>
> [...]
>
>
>>Just as isspace is reserved by the C implementation...
>>
>> 7.26.2 Character handling <ctype.h>
>>
>> [#1] Function names that begin with either is or to, and a
>> lowercase letter (possibly followed by any combination of
>> digits, letters, and underscore) may be added to the
>> declarations in the <ctype.h> header.
>
>
> There go is_space(), etc as suggested by the relevant patches...
No they don't. "begin with either is or to and a lowercase letter",
meaning (is|to)[a-z].*, just as Morten wrote. is_.* doesn't fall into
this category. The underscore exemption is so that users can write their
own is_file(), is_whatever() str_replace() and such. Some thought has
gone into the standard.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: The MIT error
From: Horst von Brand @ 2005-10-25 13:40 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc0510241157j39d5ff2cib2ccea50d15210d4@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> wrote:
> After the isspace/BSD conflict I looked into what reserved symbols are
> being used by git. Quite a few, it turns out.
[...]
> Just as isspace is reserved by the C implementation...
>
> 7.26.2 Character handling <ctype.h>
>
> [#1] Function names that begin with either is or to, and a
> lowercase letter (possibly followed by any combination of
> digits, letters, and underscore) may be added to the
> declarations in the <ctype.h> header.
There go is_space(), etc as suggested by the relevant patches... in any
case, if you /don't/ #include <ctype.h>, you are safe (standardwise),
aren't you? [Yes, idiots who #include that in system headers are way
broken, but...]
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] git_progname
From: Petr Baudis @ 2005-10-25 13:32 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <435E2ABA.8030907@op5.se>
Dear diary, on Tue, Oct 25, 2005 at 02:53:14PM CEST, I got a letter
where Andreas Ericsson <ae@op5.se> told me that...
> Andreas Ericsson wrote:
> >Petr Baudis wrote:
> >>Urgh. Now this is ugly. What about making it a bit more intrusive while
> >>quite more saner?
> >
> >I'm not sure what you're referring to. The one-liner is a one-liner.
> >It's sort of supposed to be ugly.
>
> Oh. I saw what you meant now. Lots of main.h included. :)
No, I didn't mean the oneliner at all, actually - just the notion that
you stealthily hijack main(). We'll see what Junio thinks about it. ;)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Convention for help in git commands?
From: Josef Weidendorfer @ 2005-10-25 13:08 UTC (permalink / raw)
To: git
Hi,
is there a commonly accepted way how to handle help messages
in git commands? In git-mv/git-rename, there is a full help
message with description of options when "-h" is given.
This seems to be the Cogito way; git commands seem to be used
to output an one-liner usage only, and rely on the man
page otherwise.
This should be more consistent. Proposal:
* All git commands should react on command line option "-h"
for help, dumping a few lines to stderr, prefixed by "usage:", giving
the command usage without further descriptions. For the usage
output, use the base name of the command, and not the absolute
path to the binary.
* For commands which need at least one argument, the usage
is also printed, if the command is run without argument
* On a error condition, prefix the message with "error:", and
do not print out anything else (like the usage line, or things
produced by the PERL "die", which appends "at scriptname line nn").
Perhaps these things should be done only for commands of the
git lightwight porcelain?
Josef
^ permalink raw reply
* Re: [PATCH] git_progname
From: Andreas Ericsson @ 2005-10-25 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <435E1307.3090209@op5.se>
Andreas Ericsson wrote:
> Petr Baudis wrote:
>
>>> grep -l "int main" *.c | xargs -- sed -i '/^#include/i#include "main.h"'
>>
>>
>> Urgh. Now this is ugly. What about making it a bit more intrusive while
>> quite more saner?
>>
>
> I'm not sure what you're referring to. The one-liner is a one-liner.
> It's sort of supposed to be ugly.
>
Oh. I saw what you meant now. Lots of main.h included. :)
Silly me. Sorry about that.
I guess some manual editing could be done.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] GIT paths
From: Andreas Ericsson @ 2005-10-25 12:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vhdb7qown.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Our networking commands can take either URL or non URL to
> specify remote repository. This note first attempts to clarify
> what <path> means in the current implementation, and then
> discusses two possible enhancements.
>
> For connections over plain TCP talking with git-daemon, or over
> SSH in this form, path is always relative to the root directory
> on the remote site, because '/' that terminate either <host> or
> <port> starts the <path> = '/' + <rest-of-path>.
>
> There are two things I would like to discuss here.
>
> - It might make sense to have SERVER_ROOT (similar to
> DOCUMENT_ROOT in Apache) for git-daemon, so <path> does not
> have to be relative to the true filesystem root. Note that
> this is not a security measure, but meant for administration
> convenience [*1*].
>
> - Over a git-daemon connection, supporting ~user expansion
> makes sense. E.g git://host.xz/~junio/ refers to my home
> directory on that machine. It would make it impossible to
> have a directory literally named '~junio' directly underneath
> the root directory, but that is a good limitation anyway.
>
I like this idea, although I'd extend it with a Userdir-like config
option in git-daemon (like ~/public_html for apache). This makes it a
bit easier to see what's published and what isn't.
About the literally named /~junio directory, it would be possible with
this syntax;
git fetch host.xz:/~junio
The userdir is (with my previous patch) only expanded if the path starts
with a tilde.
> The above enhancements, especially SERVER_ROOT, however make
> paths inconsistent between non URL form and URL form. This
> probably is OK -- people are used to using different paths when
> uploading to HTTP server and testing a download from it. That
> leaves one issue. Do we want to support ~user expansion, and if
> so how, on non git-daemon connections?
>
> I would propose that
>
> git fetch host.xz:~junio/repo
> git fetch ssh://host.xz/~junio/repo
>
> mean the same thing (i.e. both understand ~user expansion).
> Also these are equivalent (i.e. no ~user expansion; both mean
> absolute filesystem path without SERVER_ROOT prefixing):
>
> git fetch host.xz:/frotz/repo
> git fetch ssh://host.xz/frotz/repo
>
> While these two might not mean the same thing (the former is
> prefixed with SERVER_ROOT, but not the latter):
>
> git fetch git://host.xz/frotz/repo
> git fetch ssh://host.xz/frotz/repo
>
> There are small technical issues.
>
> - connect.c should not be affected at all, since it does not
> know how the remote site arranges SERVER_ROOT (if we support
> it) or user home directories.
>
It must remove the leading slash for this syntax:
ssh://host.xz/~junio/repo
Otherwise it would be passed as /~junio/repo to the remote end and no
~user interpolation would be done.
>
> - git-daemon needs to validate the incoming requested path and
> in order to avoid aliasing issues, we should resolve ~user
> expansion and SERVER_ROOT prefixing first, then validate the
> resulting path against white/black list, before calling
> upload-pack or receive-pack. However, after git-daemon
> decides to run these programs, they could find out some
> problems with the specified repository and may need to report
> them. Arguably, this reporting should not reveal the real
> path used to address the repository [*2*].
>
This could be done by writing the relative path in the error message;
.git/foo/bar: failed to do something nifty
The user or the admin should know where that path is and will know what
to do. Messages logged on the server-side should ofcourse hold the full
path.
> Although we _could_ forget about the "error reporting exposing
> real path" issue for now, I think we should at least have a plan
> to make things consistent and well defined. Here is a strawman:
>
> - Have a common library code that takes user supplied path and
> does SERVER_ROOT prefixing and ~user expansion.
>
> - Have git-daemon use it to canonicalize the requested path
> before validating. Make it invoke the programs with the path
> received from the other end (before SERVER_ROOT prefixing, or
> ~user expansion).
>
I'd say make it invoke the programs with the canonicalized path. As you
say, git-daemon has to verify that it's a proper git repo and in the
whitelist anyway so I think it would be silly to add extra complexity to
upload-pack and receive-pack.
git-daemon could ofcourse present some uniform error message if
git-upload-pack or git-receive-pack fails but this wouldn't really be
necessary if they use relative paths as mentioned above (someone who
makes one of those two fail while working will already know the path).
> - Give --server-root=/path/to/root flag to programs that can be
> called by git-daemon, and have git-daemon run them with this
> flag. Have them use the same library to canonicalize the
> requested path to the real path. When these programs are run
> via direct SSH connection (i.e. ssh://host/path and
> host:path), this flag is not given so they see filesystem
> path as-is, but make the ~user expansion still available.
>
If we stick with canonicalized paths I suppose this can be dropped.
>
> [Footnote]
>
> *2* This is theoretical right now, since packed transfer
> protocols cannot report errors back, but Andreas' patch
> addresses this issue by dying carefully in srvside_chdir(). It
> falls into security-by-obscurity category, so we may choose not
> to worry about it, though.
>
Keeping valid usernames hidden is normally considered best practice.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: How to clone faster via ssh ?
From: Alexander Litvinov @ 2005-10-25 11:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510251103110.24174@wbgn013.biozentrum.uni-wuerzburg.de>
> If you have a working git on the other side, you could do
>
> time git-clone lan@lan:/home/lan/tmp/git/billing/repo r3
>
> which would utilize git-clone-pack. Way faster.
I have tried this command:
lan@lan> time git-clone lan@lan:/home/lan/tmp/git/billing/repo r3
defaulting to local storage area
lan@lan's password:
Packing 204607 objects
Unpacking 204607 objects
Killed by signal 2.) done
real 4m0.874s
user 0m0.013s
sys 0m0.120s
I have killed it at ~ 20%. As I understand it does exactly what ssh git thru
ssh transport does: git-rev-list | git-pack | ssh | git-unpack or something
like this. So it is not faster.
^ permalink raw reply
* Re: [PATCH] git_progname
From: Andreas Ericsson @ 2005-10-25 11:12 UTC (permalink / raw)
To: git
In-Reply-To: <20051025093150.GB30889@pasky.or.cz>
Petr Baudis wrote:
> Could you please also trim the mails you are replying to a bit?
>
Aye.
> Dear diary, on Tue, Oct 25, 2005 at 11:11:54AM CEST, I got a letter
> where Andreas Ericsson <ae@op5.se> told me that...
>
>>grep -l "int main" *.c | xargs -- sed -i '/^#include/i#include "main.h"'
>
>
> Urgh. Now this is ugly. What about making it a bit more intrusive while
> quite more saner?
>
I'm not sure what you're referring to. The one-liner is a one-liner.
It's sort of supposed to be ugly.
Including main.h is a fairly sane option for common initialization code.
>
> Also, when you already solve this for non-__GLIBC__ systems, I doubt
> that there is any win in keeping the __GLIBC__-specific hack, except
> that most developers won't see any bugs in the generic solution since
> they are using glibc.
>
True. I'll rework it if someone thinks it's worth it.
>
> Someone said that converting main()s to git_main()s would help the
> libification effort,
I had some thoughts along those lines as well, especially for reading
configuration files.
> but I suspect that you actually want to set the
> progname to whatever you call when you call its git_main().
>
This I don't understand. Do you mean "set the progname to whatever you
call" as in "set the progname to whatever the program author calls the
program" or as in "set the progname to whatever it's called as from the
command-line"?
> We can make it go into the init section, but that won't be too portable
> either.
>
> So I'd say just add setup_progname("foo") at the start of your main().
>
Set the progname to whatever the author calls it then.
If so, I'd put
const char *git_progname = GIT_PROGNAME;
anywhere in the main() file and expanding the %.o: rule to include
-DGIT_PROGNAME=\"git-$*\"
This would bark if there's a program that doesn't have it that's linked
against something that uses it, which the setup_progname() approach
wouldn't do.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: 0.99.9 on Saturday next week.
From: Catalin Marinas @ 2005-10-25 10:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvezpetpv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> I am sure both Pasky and Catalin want to start updating Cogito and
> StGIT to take advantage of what the new core offers, but they cannot
> just randomly use new features only available in the "master" branch
> and expect people to use 0.99.8.GIT version of unknown vintage.
The "master" branch in StGIT uses, in general, the latest features in
the "master" branch of GIT. I have a "stable" one which is restricted
to a specific GIT version (0.99.8 at the moment).
> - Configuration files (Linus).
Since the configuration files use the .ini like syntax, is it OK for
StGIT to use the same file, with an "[stgit]" section?
--
Catalin
^ permalink raw reply
* Re: [PATCH] Make fetch-pack play nicer with servers which do not speak multi_ack
From: Johannes Schindelin @ 2005-10-25 9:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy84igfrl.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4290 bytes --]
Hi,
On Tue, 25 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > + if (insert)
> > + insert_by_date(commit, &rev_list);
> > + else
> > commit_list_insert(commit, &rev_list);
>
> Hmph. I do not think insert_by_date and commit_list_insert on
> the same commit_list would play well together, since the former
> assumes that the list is already sorted by age (i.e. younger ones
> near the head, older ones close to the tail).
I´m sorry. The 2nd time, it should be &(rev_list_end->next), not
&rev_list. (See my reply to myself). In effect, rev_list would be filled
first by insert_by_date() with the refs we have and the known-to-be-common
refs from the other side. From then on, only commit_list_insert would
effectively *append* the ancestors. So it does play nicely. If there´s not
yet another bug.
> But you are right. If you made 20 commits on top of my "master"
> branch head, we should send those 20 (and the commit you based
> on your changes, which the other end has), way before sending
> the ancient v0.99 tag. Probably, we should never be sending
> v0.99 tag as "have" if we are going to send your "master" branch
> head, since the commit that tag refers to is reachable by your
> "master" branch head but there are a lot more commit between
> them, some of which will give us better "common" selected, and
> that v0.99 tag is what the other end said they have so is known
> to be ACKed if sent.
You´re right. Complete common refs are sent even if they are ancestors of
other complete common refs. I´ll think about that.
> Although we are doing a traversal on the fetch side to figure
> out the commit ancestry chain, I think we are not fully
> utilizing the information we receive from the other end.
> Typically we pull specific heads only, so get_remote_heads()
> culls the information about remote refs and you would not have a
> chance to know that v0.99 tag you have in your .git/refs/tags is
> something the remote also has, unless you asked for that
> particular tag. I wonder if we can take advantage of that
> information without discarding it. For example,
> get_remote_heads() itself knows the object name of v0.99.8 tag
> and the object name of the commit the tag refers to, and you
> have those objects locally already. If you have many local
> branches, and v0.99.8 commit is reachable from the heads of all
> of your local branches, then you should be able to tell that you
> do not have to (and you do not want to) send "have" for v0.99.7
> and older tags even though they are also in your .git/refs/,
> since you know they are all reachable from v0.99.8 commit and
> likely to be worse common than v0.99.8. The best common is
> somewhere between v0.99.8 and the tips of your local branches.
IOW v0.99.7 is an ancestor of v0.99.8, which is complete. Therefore, the
former should not be sent. Remember that we do not have to send the
optimal edges:
If v0.99.7 were the optimal common rev for some_branch, but we send
v0.99.8, the server side will do a "git-rev-list some_branch ^v0.99.8",
which has the same effect as if passing "^v0.99.7" instead.
So let´s change the definition of COMMON_REF to not include COMMON. Then,
do not mark the COMMON_REFs in find_common, but before that. And mark
their ancestors (as far as they were already parsed in everything_local())
as COMMON.
Oh, and pass nr_match=0 to get_remote_heads() and do the culling after
using the information.
> This is a minor nit but I think you no longer need to have the
> rev_list_end in this version. It is only used to maintain
> itself and not for any other purpose as far as I can see.
My mistake: the revs should be appended, not unshifted into rev_list.
If they got unshifted, that would mean that we first send all the
ancestors of the youngest refs until we get a common rev, then all the
ancestors of the 2nd youngest, etc.
When the revs are appended instead, first all the refs get sent (sorted by
date), then the parents of them (sorted by the date of the refs), then
their grand parents, etc.
While writing this, I cannot remember why I decided not to
insert_by_date() all the time.
Ciao,
Dscho
^ permalink raw reply
* Re: How to clone faster via ssh ?
From: Johannes Schindelin @ 2005-10-25 9:04 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200510251454.35202.lan@ac-sw.com>
Hi,
On Tue, 25 Oct 2005, Alexander Litvinov wrote:
> Forgot to tell:
> clone via ssh was made using this command:
> time git-clone -n ssh://lan@lan/home/lan/tmp/git/billing/repo r3
If you have a working git on the other side, you could do
time git-clone lan@lan:/home/lan/tmp/git/billing/repo r3
which would utilize git-clone-pack. Way faster.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git_progname (was: Re: User-relative paths)
From: Petr Baudis @ 2005-10-25 9:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <435DF6DA.6010205@op5.se>
Could you please also trim the mails you are replying to a bit?
Dear diary, on Tue, Oct 25, 2005 at 11:11:54AM CEST, I got a letter
where Andreas Ericsson <ae@op5.se> told me that...
> See the attached patch, which adds git_progname as a global variable to
> daemon.c with a minimum of fuzz. The one-liner below will add it to the
> rest of the programs. GNU sed >= 4.0.9 required.
>
> grep -l "int main" *.c | xargs -- sed -i '/^#include/i#include "main.h"'
Urgh. Now this is ugly. What about making it a bit more intrusive while
quite more saner?
> diff --git a/cache.h b/cache.h
> index d776016..db5d667 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -45,6 +45,13 @@
> #endif
> #endif
>
> +#if defined(__GLIBC__)
> +extern const char *__progname;
> +#define git_progname __progname
> +#else
> +extern const char *git_progname;
> +#endif
> +
> /*
> * Intensive research over the course of many years has shown that
> * port 9418 is totally unused by anything else. Or
Also, when you already solve this for non-__GLIBC__ systems, I doubt
that there is any win in keeping the __GLIBC__-specific hack, except
that most developers won't see any bugs in the generic solution since
they are using glibc.
> diff --git a/main.h b/main.h
> new file mode 100644
> index 0000000..472f134
> --- /dev/null
> +++ b/main.h
> @@ -0,0 +1,22 @@
> +/* unistd.h must be available and the glibc version includes features.h
> + * from it which #defines __GLIBC__ and friends */
> +#include <unistd.h>
> +#ifndef __GLIBC__
> +const char *git_progname;
> +static int git_main(int, char **);
> +
> +int main(int argc, char **argv)
> +{
> + char *p;
> + git_progname = p = *argv;
> +
> + /* don't use any library functions. We won't have the headers */
> + while(*p)
> + if(*p++ == '/')
> + git_progname = p;
> +
> + return git_main(argc, argv);
> +}
> +
> +#define main(argc, argv) git_main(argc, argv)
> +#endif /* __GLIBC__ */
Someone said that converting main()s to git_main()s would help the
libification effort, but I suspect that you actually want to set the
progname to whatever you call when you call its git_main().
We can make it go into the init section, but that won't be too portable
either.
So I'd say just add setup_progname("foo") at the start of your main().
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] git_progname (was: Re: User-relative paths)
From: Andreas Ericsson @ 2005-10-25 9:11 UTC (permalink / raw)
To: git
In-Reply-To: <7v1x2cyplw.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Junio C Hamano wrote:
>>
>>>Andreas Ericsson <ae@op5.se> writes:
>>>...
>>>At one point, Linus posted an outline of "restricted login shell
>>>for use with git over ssh". I think you could start from there,
>>>perhaps extend it so that it checks the binaries *and* pathnames
>>>the user can specify (e.g. only under your own $HOME is allowed,
>>>and no /../ in them, or something silly like that).
>>>
>>
>>I found this in the archives:
>>http://article.gmane.org/gmane.comp.version-control.git/5784/match=restricted+login
>>
>>Is that what you're referring to?
>
>
> No, it is this one:
>
> http://marc.theaimsgroup.com/?l=git&m=112681457828137&w=2
>
> But it is orthogonal to what you are doing in this patch.
>
>
>>Let me know if you want things done differently.
>
>
> I think srvside_chdir() should not do the userdir expansion
> under --strict (otherwise you would need a matching change in
> daemon.c as well, but I would rather not).
>
True. I'll rework it.
> The --strict flag in upload-pack is to make sure git-daemon can
> see what is being accessed and make its policy decision even
> before it calls upload-pack. In a pathological case, somebody
> can create a directory "/~foo/bar/.git", where the "/~foo"
> directory is different from "/home/foo", and have git-daemon
> check that the former is OK and call your upload-pack. Your
> upload-pack uses srvside_chdir() and exposes /home/foo/bar/.git;
It shouldn't, because srvside_chdir() will only user-expand paths that
start with a tilde.
> this circumvents git-daemon's policy decision, doesn't it?
>
> I also agree with everything Pasky already said.
>
> * In a URL, a colon after hostname means "port number
> follows". So it was a good intention to make these
> consistent:
>
> git fetch ssh://kernel.org:git
> git fetch kernel.org:git
>
> it should not be done. IOW, if I wanted to use the former
> form (which I do not think I'd use myself), I should say either one
> of:
>
> git fetch ssh://kernel.org:~/git
> git fetch ssh://kernel.org:~junio/git
>
> Oh, I just noticed you do not handle the former, because you
> did not have to, but now you need to.
>
> * Use of "extern const char *__progname" is questionable. I
> could be easily talked into:
>
> - have "extern const char *git_program_name" in cache.h or
> somewhere;
>
> - convert programs (gradually) to set that at the beginning
> of main();
>
See the attached patch, which adds git_progname as a global variable to
daemon.c with a minimum of fuzz. The one-liner below will add it to the
rest of the programs. GNU sed >= 4.0.9 required.
grep -l "int main" *.c | xargs -- sed -i '/^#include/i#include "main.h"'
> - update die() and error() to use that variable when
> reporting (both callers and implementation) -- this is
> optional.
>
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
[-- Attachment #2: git_progname.diff --]
[-- Type: text/plain, Size: 1666 bytes --]
diff --git a/Makefile b/Makefile
index 5b0306d..f8e4511 100644
--- a/Makefile
+++ b/Makefile
@@ -147,7 +147,7 @@ LIB_FILE=libgit.a
LIB_H = \
blob.h cache.h commit.h count-delta.h csum-file.h delta.h \
diff.h epoch.h object.h pack.h pkt-line.h quote.h refs.h \
- run-command.h strbuf.h tag.h tree.h
+ run-command.h strbuf.h tag.h tree.h main.h
DIFF_OBJS = \
diff.o diffcore-break.o diffcore-order.o diffcore-pathspec.o \
diff --git a/cache.h b/cache.h
index d776016..db5d667 100644
--- a/cache.h
+++ b/cache.h
@@ -45,6 +45,13 @@
#endif
#endif
+#if defined(__GLIBC__)
+extern const char *__progname;
+#define git_progname __progname
+#else
+extern const char *git_progname;
+#endif
+
/*
* Intensive research over the course of many years has shown that
* port 9418 is totally unused by anything else. Or
diff --git a/daemon.c b/daemon.c
index 0c6182f..c197ee5 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1,3 +1,4 @@
+#include "main.h"
#include "cache.h"
#include "pkt-line.h"
#include <signal.h>
diff --git a/main.h b/main.h
new file mode 100644
index 0000000..472f134
--- /dev/null
+++ b/main.h
@@ -0,0 +1,22 @@
+/* unistd.h must be available and the glibc version includes features.h
+ * from it which #defines __GLIBC__ and friends */
+#include <unistd.h>
+#ifndef __GLIBC__
+const char *git_progname;
+static int git_main(int, char **);
+
+int main(int argc, char **argv)
+{
+ char *p;
+ git_progname = p = *argv;
+
+ /* don't use any library functions. We won't have the headers */
+ while(*p)
+ if(*p++ == '/')
+ git_progname = p;
+
+ return git_main(argc, argv);
+}
+
+#define main(argc, argv) git_main(argc, argv)
+#endif /* __GLIBC__ */
^ permalink raw reply related
* Re: [PATCH] Add a --prefix option to git-daemon
From: Petr Baudis @ 2005-10-25 9:10 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <200510250708.j9P78pG3024087@gameboy2.puremagic.com>
Dear diary, on Tue, Oct 25, 2005 at 09:08:51AM CEST, I got a letter
where Brad Roberts <braddr@gameboy2.puremagic.com> told me that...
> Add a --prefix option to git-daemon. This path is prepended to the search
> path for repositories. In other words, git://hostname/path/to/gitdir will
> result in looking for /prefix/path/to/gitdir.
>
> Signed-off-by: Brad Roberts <braddr@puremagic.com>
You forgot to document the option. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] Documentation for git-shell
From: Petr Baudis @ 2005-10-25 9:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This adds some simple documentation for git-shell.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-shell.txt | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-shell.txt b/Documentation/git-shell.txt
new file mode 100644
index 0000000..dfdfbf6
--- /dev/null
+++ b/Documentation/git-shell.txt
@@ -0,0 +1,32 @@
+git-shell(1)
+============
+
+NAME
+----
+git-shell - Restricted login shell for GIT over SSH only
+
+
+SYNOPSIS
+--------
+'git-shell -c <command> <argument>'
+
+DESCRIPTION
+-----------
+This is meant to be used as a login shell for SSH accounts you want
+to restrict to GIT pull/push access only. It permits execution only
+of two commands (`git-receive-pack` and `git-upload-pack`) with
+a single argument. The commands can be executed only by the '-c'
+option; the shell is not interactive.
+
+Author
+------
+Written by Linus Torvalds <torvalds@osdl.org>
+
+Documentation
+--------------
+Documentation by Petr Baudis and the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
^ permalink raw reply related
* Re: [PATCH] Make fetch-pack play nicer with servers which do not speak multi_ack
From: Junio C Hamano @ 2005-10-25 8:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0510250854240.22398@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> + if (insert)
> + insert_by_date(commit, &rev_list);
> + else
> commit_list_insert(commit, &rev_list);
Hmph. I do not think insert_by_date and commit_list_insert on
the same commit_list would play well together, since the former
assumes that the list is already sorted by age (i.e. younger ones
near the head, older ones close to the tail).
But you are right. If you made 20 commits on top of my "master"
branch head, we should send those 20 (and the commit you based
on your changes, which the other end has), way before sending
the ancient v0.99 tag. Probably, we should never be sending
v0.99 tag as "have" if we are going to send your "master" branch
head, since the commit that tag refers to is reachable by your
"master" branch head but there are a lot more commit between
them, some of which will give us better "common" selected, and
that v0.99 tag is what the other end said they have so is known
to be ACKed if sent.
Although we are doing a traversal on the fetch side to figure
out the commit ancestry chain, I think we are not fully
utilizing the information we receive from the other end.
Typically we pull specific heads only, so get_remote_heads()
culls the information about remote refs and you would not have a
chance to know that v0.99 tag you have in your .git/refs/tags is
something the remote also has, unless you asked for that
particular tag. I wonder if we can take advantage of that
information without discarding it. For example,
get_remote_heads() itself knows the object name of v0.99.8 tag
and the object name of the commit the tag refers to, and you
have those objects locally already. If you have many local
branches, and v0.99.8 commit is reachable from the heads of all
of your local branches, then you should be able to tell that you
do not have to (and you do not want to) send "have" for v0.99.7
and older tags even though they are also in your .git/refs/,
since you know they are all reachable from v0.99.8 commit and
likely to be worse common than v0.99.8. The best common is
somewhere between v0.99.8 and the tips of your local branches.
This is a minor nit but I think you no longer need to have the
rev_list_end in this version. It is only used to maintain
itself and not for any other purpose as far as I can see.
^ permalink raw reply
* Re: How to clone faster via ssh ?
From: Alexander Litvinov @ 2005-10-25 7:54 UTC (permalink / raw)
To: git
In-Reply-To: <200510251449.15302.lan@ac-sw.com>
Forgot to tell:
clone via ssh was made using this command:
time git-clone -n ssh://lan@lan/home/lan/tmp/git/billing/repo r3
> When I do cloning via ssh it takes more than 10 minutes and horde of
> unpacked objects:
> Packing 204607 objects
> Unpacking 204607 objects
> 100% (204607/204607) done
>
> real 13m41.510s
> user 1m52.655s
> sys 1m5.057s
^ permalink raw reply
* How to clone faster via ssh ?
From: Alexander Litvinov @ 2005-10-25 7:49 UTC (permalink / raw)
To: git
Hello,
I have cvs project imported into git. When unpacked it contains about 205000
objects. I have made one pack and daily rerun cvsimport to get new changes.
When I do cloning via http it takes less than 3 minutes:
time git-clone -n http://127.0.0.1:8080/git/r/.git r2
real 2m31.062s
user 1m33.562s
sys 0m5.462s
When I do cloning via ssh it takes more than 10 minutes and horde of unpacked
objects:
Packing 204607 objects
Unpacking 204607 objects
100% (204607/204607) done
real 13m41.510s
user 1m52.655s
sys 1m5.057s
There are no packs in cloned repo:
ls -la r3/.git/objects/pack/
total 6
drwxr-xr-x 2 lan users 48 Oct 25 13:51 .
drwxr-xr-x 260 lan users 6240 Oct 25 14:05 ..
lan@lan:~/tmp/git/billing
We can't share our project via http - we need authorization for it. Is is
possible to clone this repo via ssh as http clone does ? Its will be much
faster and will simplify work with such directory - it is hard to delete it
after cloning - takes from 5 up to 10 minutes ! Filesystem is reiserfs.
Thanks for help,
Alexander Litvinov.
^ permalink raw reply
* Re: User-relative paths
From: Andreas Ericsson @ 2005-10-25 7:47 UTC (permalink / raw)
To: git
In-Reply-To: <20051023183757.GS30889@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sun, Oct 23, 2005 at 11:41:52AM CEST, I got a letter
> where Andreas Ericsson <ae@op5.se> told me that...
>
>>Anyways, the attached patch does this. I've tested all the various
>>syntaxes and they work as expected. rsync, http and local files take the
>>same syntax as before. I haven't added support for user-relative paths
>>to the git-daemon (can't see the point, really) although that can be
>>done easily enough.
>
>
> It would be useful to add a [PATCH] tag to subject when you submit a
> patch, so that we notice it better. ;-)
>
Will do in the future. I thought it was auto-imported for buildtest if
it was.
> You don't update the documentation even though there seem to be some
> syntactic changes. You should at least update
>
> Documentation/pull-fetch-param.txt
>
True. I'll need to re-work the patch a bit to take Junio's RFC on paths
into account. I'll do this then.
> Also before Junio asks you, in the followup patches, you might want to
> sign off the patch if you want it integrated.
>
>
>>diff --git a/Makefile b/Makefile
>>index 903c57c..87188ea 100644
>>--- a/Makefile
>>+++ b/Makefile
>>@@ -359,6 +362,9 @@ git-cherry-pick: git-revert
>> %.o: %.S
>> $(CC) -o $*.o -c $(ALL_CFLAGS) $<
>>
>>+$(SERVERSIDE_PROGRAMS) : git-%$X : %.o srvside-ssh.o $(LIB_FILE)
>>+ $(CC) $(ALL_CFLAGS) -o $@ $(filter %o,$^) $(LIBS)
>>+
>> git-%$X: %.o $(LIB_FILE)
>> $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
>>
>
>
> Why are you adding own compilation command, and why is it inconsistent
> with the git-%$X's one?
>
Mainly because I'm really no good at Makefiles and just noticed that
this seems to do what I want. My own projects rarely stretch over 15
files and it's usually just one or two binaries, so I haven't gotten
round to learning the finer points of make.
>
>>diff --git a/connect.c b/connect.c
>>index b171c5d..0d78b3e 100644
>>--- a/connect.c
>>+++ b/connect.c
>>@@ -436,33 +436,44 @@ static int git_tcp_connect(int fd[2], co
>>+ /* leading colon marks relative path for ssh.
>>+ * Check for host == url and default to PROTO_SSH to allow
>>+ * $ git fetch kernel.org:git
>>+ */
>>+ if(ptr && (!path || ptr < path)) {
>>+ if(host == url)
>>+ protocol = PROTO_SSH;
>>+
>>+ if(protocol == PROTO_SSH) {
>>+ *ptr = '\0';
>>+ path = ptr + 1;
>> }
>> }
>
>
> If I understand this right,
>
> ssh://foo.bar:baz/quux
>
> will make foo.bar the host and baz/quux the path. Please, do NOT do
> this! It is supposed to be a URL, dammit! And you know, URLs have
> defined _syntax_, and that's important at least every time the URL gets
> out of GIT's context. Or stop it calling URL altogether, to prevent any
> confusion. But in URLs, the space between : and / is a port definition.
> See also RFC3986 (aka STD066) and RFC2718.
>
> Thanks.
>
Right you are. I was thinking scp like syntax rather than url.
>
>>diff --git a/receive-pack.c b/receive-pack.c
>>index 8f157bc..9a040ff 100644
>>--- a/receive-pack.c
>>+++ b/receive-pack.c
>>@@ -265,18 +267,9 @@ int main(int argc, char **argv)
>> if (!dir)
>> usage(receive_pack_usage);
>>
>>- /* chdir to the directory. If that fails, try appending ".git" */
>>- if (chdir(dir) < 0) {
>>- if (chdir(mkpath("%s.git", dir)) < 0)
>>- die("unable to cd to %s", dir);
>>- }
>>-
>>- /* If we have a ".git" directory, chdir to it */
>>- chdir(".git");
>>- putenv("GIT_DIR=.");
>>+ /* Find the right directory */
>>+ srvside_chdir(dir, 0);
>>
>>- if (access("objects", X_OK) < 0 || access("refs/heads", X_OK) < 0)
>>- die("%s doesn't appear to be a git directory", dir);
>> write_head_info();
>>
>> /* EOF */
>
>
> No srvside_chdir() declaration?
>
>
>>diff --git a/srvside-ssh.c b/srvside-ssh.c
>>new file mode 100644
>>index 0000000..0ed5d30
>>--- /dev/null
>>+++ b/srvside-ssh.c
>>@@ -0,0 +1,63 @@
>>+#include "cache.h"
>>+#include <unistd.h>
>>+#include <pwd.h>
>>+
>>+extern const char *__progname;
>
>
> How portable is this? It appears that no standard really defines this,
> and Google faintly hints at least some Cygwin-related problems...
>
Somewhat, but not very. It was more of a quick hack since the old code
had hardcoded program names. If this gets supported in git-daemon as
well it should say "git-daemon" in the error message, so I think either
pass it as a parameter or invent some git_progname variable and use some
small init-code for all programs.
>
>>diff --git a/upload-pack.c b/upload-pack.c
>>index accdba6..356c9b1 100644
>>--- a/upload-pack.c
>>+++ b/upload-pack.c
>>@@ -5,6 +5,7 @@
>> #include "object.h"
>>
>> static const char upload_pack_usage[] = "git-upload-pack [--strict] [--timeout=nn] <dir>";
>>+extern void srvside_chdir(const char *path, int strict);
>>
>> #define MAX_HAS 256
>> #define MAX_NEEDS 256
>
>
> What about a .h file?
>
Prototype patch, sort of, and since it's only one function I thought
it'd be better to keep it as unobtrusive as possible.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Add a --prefix option to git-daemon
From: Junio C Hamano @ 2005-10-25 7:42 UTC (permalink / raw)
To: Brad Roberts; +Cc: git
In-Reply-To: <200510250708.j9P78pG3024087@gameboy2.puremagic.com>
Brad Roberts <braddr@gameboy2.puremagic.com> writes:
> Add a --prefix option to git-daemon.
What is your thought about my RFC last night [*1*], and how does
this patch address the concern raised in it, specifically what
is the plan for this --prefix option to work together with
upload-pack?
[Reference]
*1* http://marc.theaimsgroup.com/?l=git&m=113014402715697&w=2
^ permalink raw reply
* [PATCH] Add a --prefix option to git-daemon
From: Brad Roberts @ 2005-10-25 7:08 UTC (permalink / raw)
To: git
Add a --prefix option to git-daemon. This path is prepended to the search
path for repositories. In other words, git://hostname/path/to/gitdir will
result in looking for /prefix/path/to/gitdir.
Signed-off-by: Brad Roberts <braddr@puremagic.com>
---
daemon.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
applies-to: ccef5ac580c68a9714f37dcd8ee433e9691b640a
4ab5253ba31370d151843ca14a8cabcadc37c974
diff --git a/daemon.c b/daemon.c
index 0c6182f..566bec6 100644
--- a/daemon.c
+++ b/daemon.c
@@ -15,7 +15,7 @@ static int verbose;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
-" [--timeout=n] [--init-timeout=n] [directory...]";
+" [--timeout=n] [--init-timeout=n] [--prefix=directory] [directory...]";
/* List of acceptable pathname prefixes */
static char **ok_paths = NULL;
@@ -27,6 +27,9 @@ static int export_all_trees = 0;
static unsigned int timeout = 0;
static unsigned int init_timeout = 0;
+/* directory prefix for all repositories */
+static const char *directory_prefix = "";
+
static void logreport(int priority, const char *err, va_list params)
{
/* We should do a single write so that it is atomic and output
@@ -170,10 +173,10 @@ static int set_dir(const char *dir)
static int upload(char *dir)
{
/* Try paths in this order */
- static const char *paths[] = { "%s", "%s/.git", "%s.git", "%s.git/.git", NULL };
+ static const char *paths[] = { "%s%s", "%s%s/.git", "%s%s.git", "%s%s.git/.git", NULL };
const char **pp;
/* Enough for the longest path above including final null */
- int buflen = strlen(dir)+10;
+ int buflen = strlen(dir)+strlen(directory_prefix)+10;
char *dirbuf = xmalloc(buflen);
/* Timeout as string */
char timeout_buf[64];
@@ -181,7 +184,7 @@ static int upload(char *dir)
loginfo("Request for '%s'", dir);
for ( pp = paths ; *pp ; pp++ ) {
- snprintf(dirbuf, buflen, *pp, dir);
+ snprintf(dirbuf, buflen, *pp, directory_prefix, dir);
if ( !set_dir(dirbuf) )
break;
}
@@ -615,6 +618,10 @@ int main(int argc, char **argv)
if (!strncmp(arg, "--init-timeout=", 15)) {
init_timeout = atoi(arg+15);
}
+ if (!strncmp(arg, "--prefix=", 9)) {
+ directory_prefix = arg+9;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
---
0.99.8.GIT
^ permalink raw reply related
* [PATCH] Make fetch-pack play nicer with servers which do not speak multi_ack
From: Johannes Schindelin @ 2005-10-25 6:59 UTC (permalink / raw)
To: git, junkio
Sort the refs by date again (but only the refs). This helps when the
server does not support multi_ack, since the more likely candidates for
common revs are the younger ones.
Also, it helps avoid traffic, as younger revs can have older revs as
ancestors, but not vice versa. Therefore, when the server ack's a younger
rev, chances are that the older rev never gets sent.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Yesterday, I pulled from the git repository, and it wanted to give
me 961 objects! When analyzing this, I found out that my version
of git-fetch-pack sent the oldest refs first. The newest was never
sent, because the oldest was ack'ed right away.
fetch-pack.c | 35 +++++++++++++++++++++++------------
1 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 57602b9..3efa652 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -22,30 +22,41 @@ static struct commit_list *rev_list = NU
static struct commit_list *rev_list_end = NULL;
static unsigned long non_common_revs = 0;
-static void rev_list_append(struct commit *commit, int mark)
+static void rev_list_push(struct commit *commit, int mark,
+ int insert)
{
if (!(commit->object.flags & mark)) {
commit->object.flags |= mark;
- if (rev_list == NULL) {
+ if (insert)
+ insert_by_date(commit, &rev_list);
+ else
commit_list_insert(commit, &rev_list);
+
+ if (!rev_list_end)
rev_list_end = rev_list;
- } else {
- commit_list_insert(commit, &(rev_list_end->next));
+ else if (rev_list_end->next)
rev_list_end = rev_list_end->next;
- }
if (!(commit->object.flags & COMMON))
non_common_revs++;
}
}
-static int rev_list_append_sha1(const char *path, const unsigned char *sha1)
+/*
+ The refs are not just appended to the rev_list, but rather inserted
+ by date. It is just more efficient that way, since the edges of the
+ common commits are more likely to be recent than not.
+ Also, it makes fetch-pack plays nice with servers which do not
+ understand the multi_ack extension.
+*/
+
+static int rev_list_insert_ref(const char *path, const unsigned char *sha1)
{
struct object *o = deref_tag(parse_object(sha1));
if (o->type == commit_type)
- rev_list_append((struct commit *)o, SEEN);
+ rev_list_push((struct commit *)o, SEEN, 1);
return 0;
}
@@ -56,7 +67,7 @@ static void mark_common(struct commit *c
struct object *o = (struct object *)commit;
o->flags |= COMMON;
if (!(o->flags & SEEN))
- rev_list_append(commit, SEEN);
+ rev_list_push(commit, SEEN, 0);
else {
struct commit_list *parents;
@@ -111,7 +122,7 @@ static const unsigned char* get_rev()
if (mark & COMMON)
mark_common(parents->item);
else
- rev_list_append(parents->item, mark);
+ rev_list_push(parents->item, mark, 0);
parents = parents->next;
}
@@ -128,7 +139,7 @@ static int find_common(int fd[2], unsign
int count = 0, flushes = 0, multi_ack = 0, retval;
const unsigned char *sha1;
- for_each_ref(rev_list_append_sha1);
+ for_each_ref(rev_list_insert_ref);
fetching = 0;
for ( ; refs ; refs = refs->next) {
@@ -150,8 +161,8 @@ static int find_common(int fd[2], unsign
o = deref_tag(o);
if (o->type == commit_type)
- rev_list_append((struct commit *)o,
- COMMON_REF | SEEN);
+ rev_list_push((struct commit *)o,
+ COMMON_REF | SEEN, 1);
continue;
}
^ permalink raw reply related
* Re: gitweb: charset problem
From: Junio C Hamano @ 2005-10-24 22:39 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510241743280.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Mon, 24 Oct 2005, Horst von Brand wrote:
>
>> I believe the Emperor Penguin decreed messages have to be
>> ASCII, or else UTF-8. Please don't add to the mess by using
>> non-portable encodings!
>
> Should we possibly reject non-UTF-8 input to commits?
Please, don't.
> IIRC, we actually define that to be UTF-8, unlike most of the
> other stuff, for which we don't actually insist on a policy.
No, we do not define nor insist on a particluar policy as far as
I know. We suggest the use of UTF-8 merely from common sense to
help interoperability, and make UTF-8 slightly easier to use
than other encodings by giving specific support for it in some
tools, namely -u flag in git-mailinfo.
It is perfectly reasonable if a company internal project that
works in Russia to standardize on KOI, or in Japan on EUC-JP.
We simply allow it without encouraging nor discouraging it. If
gitweb can take a configuration mechanism to override the
built-in UTF-8 header, that is perfectly a valid thing to do to
help such an environment.
However, we suggest UTF-8 if the project does not have a
compelling reason to do otherwise [*1*]. If you want to be
prepared for the day your project might have wider participants
than you originally envisioned, that is the most sensible thing
to do. This is especially true because the commit logs cannot
be re-encoded after the fact.
[Footnote]
*1* For example, I've never made GNU emacs to work well with
Japanese in UTF-8 , so if people in my company internal project
wanted to use Japanese in commit logs, I would probably
standardize on EUC-JP for such a project. Luckily so far I have
not been forced to make that decision.
^ permalink raw reply
* Re: RFE: git rm
From: Daniel Barkalow @ 2005-10-24 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7aalg57.fsf@assigned-by-dhcp.cox.net>
On Mon, 24 Oct 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > I often do "git add something" when I happen to think of it, not
> > necessarily right before committing, which means that I have these files
> > changed in my index while working. I may quit this, however, now that git
> > status lists the ones I missed.
>
> Oh, I do 'git add' myself; otherwise I'd surely forget by the
> time I commit.
>
> And I did not mean to tell you to quit doing it. If any of you
> took what I said as "Linus does not do it, I do not do it, so
> you should not be doing update-index in the middle", then that
> was not my intention and I apologize for causing confusion.
Actually, I'm thinking of quitting that because I'm actually more likely
to realize I need to add something when I see it in the untracked list
than any other time. Now that the untracked list is right there, I
probably won't bother to think about it until that point. That is, the new
feature makes my old habit unnecessary. (I obviously don't care what other
people do; I'm still using multiple working trees with the same
repository, which AFAIK nobody else has done for months.)
For that matter, it helps, if I find I've done two things that I want to
commit separately in the same working tree if the first commit doesn't
have to include the addition of all the new files.
> > Incidentally, the new git status entry for --others really ought to say
> > something different from "Ignored files", like "Exist but not tracked",
> > since it doesn't include the contents of .gitignore, which you'd expect to
> > be "Ignored". (And, of course, any files it lists are hardly being
> > ignored.)
>
> Good point. Something like this?
Looks like what I was thinking, yes.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: RFE: git rm
From: Junio C Hamano @ 2005-10-24 22:11 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0510241725370.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> I often do "git add something" when I happen to think of it, not
> necessarily right before committing, which means that I have these files
> changed in my index while working. I may quit this, however, now that git
> status lists the ones I missed.
Oh, I do 'git add' myself; otherwise I'd surely forget by the
time I commit.
And I did not mean to tell you to quit doing it. If any of you
took what I said as "Linus does not do it, I do not do it, so
you should not be doing update-index in the middle", then that
was not my intention and I apologize for causing confusion.
I think update-index in the middle is a valid workflow. The
only drawback I can think of is that you cannot merge or apply
others' patches once you do it until you commit. I was just
curious how people use git, weighing the pros and cons of that
(pros: git-diff-files is easier to read and the index gives you
a good anchoring point; cons: you cannot do merge or patch
application).
> Incidentally, the new git status entry for --others really ought to say
> something different from "Ignored files", like "Exist but not tracked",
> since it doesn't include the contents of .gitignore, which you'd expect to
> be "Ignored". (And, of course, any files it lists are hardly being
> ignored.)
Good point. Something like this?
------------
Clarify git status output.
What we list as "Ignored files" are not "ignored". Rather, it
is the list of "not listed in the to-be-ignored files, but
exists -- you may be forgetting to add them".
Pointed out by Daniel.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-status.sh b/git-status.sh
index 29c2b11..62a24a9 100755
--- a/git-status.sh
+++ b/git-status.sh
@@ -90,7 +90,7 @@ perl -e '$/ = "\0";
s|\n|\\n|g;
s/^/# /;
if (!$shown) {
- print "#\n# Ignored files:\n";
+ print "#\n# Untracked files:\n";
print "# (use \"git add\" to add to commit)\n#\n";
$shown = 1;
}
^ permalink raw reply related
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