* why no "git fetch --dry-run" ?
From: Leo Razoumov @ 2008-11-21 21:41 UTC (permalink / raw)
To: Git Mailing List
Hello List,
I am curious why there is "git push --dry-run" and no "git fetch
--dry-run" nor "git pull --dry-run". It would make sense to keep
push/pull/fetch as symmetric as possible.
For example, I just want to see which branches, if any, changed on a
remote repository since my last fetch. "git fetch -v --dry-run" would
be handy in this case.
--Leo--
^ permalink raw reply
* Re: [PATCH] mmap implementation for mingw.
From: Johannes Schindelin @ 2008-11-21 20:51 UTC (permalink / raw)
To: Bryan Donlan; +Cc: Vasyl' Vavrychuk, git, Johannes Sixt
In-Reply-To: <3e8340490811211225g6e479dcbyeeb793eb0f825441@mail.gmail.com>
Hi,
On Fri, 21 Nov 2008, Bryan Donlan wrote:
> I'm not overly familiar with the windows API, but wouldn't passing
> FILE_SHARE_DELETE | FILE_SHARE_READ in the dwShareMode argument of
> CreateFile() be enough to allow rename/deletion of the file in question
> while it is mapped?
A very quick Google research already revealed that your suggestion has any
meaning _only_ for NTFS.
So that leaves FAT behind.
I could also imagine that Windows 2K does not even bother heeding those
flags (it speaks volumes about Microsoft's documentation that you cannot
find out if that is the case spending less than 15 minutes, and possibly
more than that).
So I think your objection is irrelevant, sorry,
Dscho
^ permalink raw reply
* Re: [PATCH] mmap implementation for mingw.
From: Bryan Donlan @ 2008-11-21 20:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Vasyl' Vavrychuk, git, Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0811211143550.30769@pacific.mpi-cbg.de>
On Fri, Nov 21, 2008 at 5:48 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> [re-Cc:ed j6t]
>
> On Fri, 21 Nov 2008, Vasyl' Vavrychuk wrote:
>
>> [Dscho knows that j6t wrote this:]
>>
>> > It doesn't pass the test suite, for example t5301-sliding-window.sh
>> > fails.
>>
>> I will investigate.
>
> Note that I quickly discarded the idea of mmap() on MinGW because at least
> in the past, we used to rename files that were mmap()ed. That is a no-go
> with CreateFile().
Hi,
I'm not overly familiar with the windows API, but wouldn't passing
FILE_SHARE_DELETE | FILE_SHARE_READ in the dwShareMode argument of
CreateFile() be enough to allow rename/deletion of the file in
question while it is mapped?
Thanks,
Bryan Donlan
^ permalink raw reply
* Re: Bad git status performance
From: Jean-Luc Herren @ 2008-11-21 20:07 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Glenn Griffin, Git Mailing List, Junio C Hamano
In-Reply-To: <4926D196.3000301@drmicha.warpmail.net>
Michael J Gruber wrote:
> Experimenting further: Using 10 files with 10MB each (rather than 100
> times 1MB) brings down the time by a factor 10 roughly - and so does
> using 100 files with 100k each. Huh? Latter may be expected (10MB
> total), but former (100MB total)?
100 files at each 100k gives me 1.73s, so about 10x speed up. So
it seems git indeed looks at the content of the files and having a
tenth of the content means it's ten times as fast.
Interestingly, using only a single file of 100MB gives me 0.6s.
Which is still very slow for the job of telling that a 100MB file
is not equal to a 1 byte file. And certainly there's no renaming
going on with a single file.
> Now it's getting funny: Changing your "echo >" to "echo ">>" (in your
> 100 files 1MB case) makes things "almost fast" again (1.3s).
Same here and that's pretty interesting, because in this situation
I can understand the slow down: Comparing two 1MB files that
differ only at their ends is expected to take some time, as you
have to go through the entire file until you notice they're not
the same.
jlh
^ permalink raw reply
* Re: How to setup a public reposistory?
From: Gary Yang @ 2008-11-21 20:04 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4926853A.6080009@op5.se>
I followed the steps outlined by the links below. But, I am still not able to setup the public repository. I got, fatal: unable to connect a socket (Connection refused). What I did wrong? Please help.
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#setting-up-a-public-repository
http://dtcsupport.gplhost.com/Git/Public-Repo-Howto
0. Prepare your name and email address
cat ~gyang/.gitconfig
[user]
email = gyang@mycompany.com
name = Gary Yang
1. Create an archive to send to the server
/home/gyang% git clone http://git.gplhost.com/dtc-xen.git
/home/gyang% git clone --bare dtc-xen dtc-xen.git
/home/gyang% touch dtc-xen.git/git-daemon-export-ok
/home/gyang% tar -cvzf dtc-xen.git.tar.gz dtc-xen.git
2. Install the archive on the web server
/pub/git% tar -xvzf /home/gyang/dtc-xen.git.tar.gz
/pub/git/dtc-xen.git% git --bare update-server-info
/pub/git/dtc-xen.git% mv hooks/post-update.sample hooks/post-update
/pub/git/dtc-xen.git% chmod +x hooks/post-update
/pub/git/dtc-xen.git% cat hooks/post-update
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".
exec git-update-server-info
3. Configure and start git daemon at the web server
/pub/git/dtc-xen.git% grep 9418 /etc/services
git 9418/tcp # Git Version Control System
/pub/git/dtc-xen.git% sudo git daemon --verbose --inetd --export-all /pub/git &
4. At my local machine. I did
/home/gyang% git clone git://git.mycompany.com/pub/git/dtc-xen.git test-git
Initialized empty Git repository in //home/gyang/test-git/.git/
git.mycompany.com[0: 10.66.4.168]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
ps -efww | grep git
root 9626 22321 0 11:31 pts/1 00:00:00 git-daemon --verbose --inetd --export-all /pub/git
--- On Fri, 11/21/08, Andreas Ericsson <ae@op5.se> wrote:
> From: Andreas Ericsson <ae@op5.se>
> Subject: Re: Cannot git pull using http from my git.mycompany.com
> To: garyyang6@yahoo.com
> Cc: git@vger.kernel.org
> Date: Friday, November 21, 2008, 1:54 AM
> Gary Yang wrote:
> > git pull http://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > fatal:
> http://git.mycompany.com/pub/git/u-boot.git/info/refs not
> found: did you run git update-server-info on the server?
> >
> > Below are related gitweb configs. What did I do wrong?
> >
> >
> > httpd.confg
> >
> > <VirtualHost 10.66.4.168>
> > ServerName svdcgit01
> > DocumentRoot /pub/git
> > <Directory /var/www/cgi-bin>
> > Allow from all
> > AllowOverride all
> > Order allow,deny
> > Options ExecCGI
> > <Files gitweb.cgi>
> > SetHandler cgi-script
> > </Files>
> > </Directory>
> > DirectoryIndex /cgi-bin/gitweb.cgi
> > SetEnv GITWEB_CONFIG /etc/gitweb.conf
> > # RewriteEngine on
> > # RewriteRule
> ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$
> /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
> >
> >
> > cat /etc/gitweb.conf
>
>
> You seem slightly confused. gitweb is not used for cloning
> over http.
> The following documents would almost certainly be
> beneficial for you
> to read. Please don't ask any questions that are
> already answered in
> those documents. If, by following the steps outlined in
> those docs,
> you still cannot get things to work, please let us know
> what you fail
> to understand so the texts can be amended.
>
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#setting-up-a-public-repository
> http://dtcsupport.gplhost.com/Git/Public-Repo-Howto
>
> -- Andreas Ericsson
> andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* git-svn and svn branches
From: Ryan Phillips @ 2008-11-21 19:58 UTC (permalink / raw)
To: git
I followed the following instructions on adding a remote svn branch to my
local git-svn repository. http://www.dmo.ca/blog/20070608113513
Are these still accurate?
I started the repository with
# git svn init [url/trunk]`
# cd project.git
# git svn fetch -r[HEAD revision]
which works fine. I added something like Snippet 1 to the .git/config and
issued a `git svn fetch -r[HEAD revision of the branch]` and nothing
happens. It takes git-svn a few seconds to run, but the git-remote svn
branch doesn't get initialized.
Does this procedure only work with a full mirror of a git-svn repository?
or perhaps I'm doing something wrong. Any help would be appreciated.
Thanks,
Ryan
Snippet 1
=========
[svn-remote "svn34"]
url = svn+ssh://your-server/home/svn/project-name/branches/3.4.x
fetch = :refs/remotes/git-svn-3.4
^ permalink raw reply
* Submodule complaint
From: Johannes Schindelin @ 2008-11-21 19:51 UTC (permalink / raw)
To: git
Hi,
just to let you know (those who are capable of coding, that is):
submodules are _still_ a 2nd-class citizen, and very much so.
With a commit where you _know_ that a submodule has a different version
than the current one, try this:
$ git checkout $COMMIT -- $SUBMODULE
You will realize that it does not change the "git status" output (i.e. it
does not change the index), which is wrong, wrong, wrong.
Ciao,
Dscho
P.S.: If I would not have enjoyed my rightfully deserved weekend beers, I
would have taken take care of this myself, depriving _you_ of
commit-karma. So, in a way I am giving you the chance to increase your
value ;-)
^ permalink raw reply
* Re: Cannot git pull using http from my git.mycompany.com
From: Gary Yang @ 2008-11-21 17:34 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20811210043v1f3af6c5l6f5a25c12d697d2d@mail.gmail.com>
Yes
--- On Fri, 11/21/08, David Symonds <dsymonds@gmail.com> wrote:
> From: David Symonds <dsymonds@gmail.com>
> Subject: Re: Cannot git pull using http from my git.mycompany.com
> To: garyyang6@yahoo.com
> Cc: git@vger.kernel.org
> Date: Friday, November 21, 2008, 12:43 AM
> On Fri, Nov 21, 2008 at 12:13 PM, Gary Yang
> <garyyang6@yahoo.com> wrote:
>
> > git pull http://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > fatal:
> http://git.mycompany.com/pub/git/u-boot.git/info/refs not
> found: did you run git update-server-info on the server?
> >
> > Below are related gitweb configs. What did I do wrong?
>
> As the error message asks, did you run git
> update-server-info on the server?
>
>
> Dave.
^ permalink raw reply
* Re: git-status for submodules
From: Johan Herland @ 2008-11-21 15:27 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Chris Frey
In-Reply-To: <7vabbtqga8.fsf@gitster.siamese.dyndns.org>
On Friday 21 November 2008, Junio C Hamano wrote:
> Chris Frey <cdfrey@foursquare.net> writes:
> > I'm using git 1.6.0.4 and trying to make submodules work for me.
> > The init/add/update steps are a bit tedious, but workable. The
> > problem I have is when I make a change in a submodule, then
> > git-status does not show the change.
>
> My understanding is that this is exactly by design. The supermodule
> tracks which commit in the subproject is bound to the tree location.
>
> A mere act of changing something in the subproject directory is just
> a single, incomplete step to create a new commit in the subproject
> and will
>
> not be seen by the superproject's status. Instead of this workflow:
> > cd super
> > vi newsuper
> > vi existing_file
> > cd sub
> > vi newsub
> > cd ..
> > git status
>
> the submodule support is geared toward supporting this layout:
>
> - "super" has a subproject X at "sub"
>
> - When you do a real work on the subproject X, you do so as
> if there is no supermodule. IOW, subproject X has to be able to
> stand on its own.
Chris' workflow is farily easily supported by running git-status within
each submodule, like this:
git submodule foreach "git status; true"
If the above is too cumbersome to type, one can easily wrap an alias
around it:
git config alias.substatus 'submodule foreach "git status; true"'
git substatus
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Bad git status performance
From: Michael J Gruber @ 2008-11-21 15:19 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: Glenn Griffin, Git Mailing List, Junio C Hamano
In-Reply-To: <4926ADB8.5000307@gmx.ch>
Jean-Luc Herren venit, vidit, dixit 21.11.2008 13:46:
> Glenn Griffin wrote:
>> On Thu, Nov 20, 2008 at 4:28 PM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>>> The first 'git status' shows the same difference as the second,
>>> just the second time it's staged instead of unstaged. Why does it
>>> take 16 seconds the second time when it's instant the first time?
>> I believe the two runs of git status need to do very different things.
>> When run the first time, git knows the files in your working
>> directory are not in the index so it can easily say those files are
>> 'Changed but not updated' just from their existence.
>
> I might be mistaken about how the index works, but those paths
> *are* in the index at that time. They just have the old content,
> i.e. the same content as in HEAD. When HEAD == index, then
> nothing is staged.
>
> But the presence of those files alone doesn't tell you that they
> have changed. You have to look at the content and compare it to
> the index (== HEAD in this situation) to see whether they have
> changed or not and for some reason git can do this very quickly.
>
>> The second run
>> those files do exist in both the index and the working directory, so
>> git status first shows the files that are 'Changes to be committed'
>> and that should be fast, but additionally git status will check to see
>> if those files in your working directory have changed since you added
>> them to the index.
>
> Which is basically the same comparision as above, just it turns
> out that they have not changed. But even then, we're talking
> about comparing a 1 byte file in the index to a 1 byte file in the
> work tree. That doesn't take 16 seconds, even for 100 files.
>
> So this makes me believe it's the first step (comparing HEAD to
> the index to show staged changes) that is slow. And when you
> compare a 1MB file to a 1 byte file, you don't need to read all of
> the big file, you can tell they're not the same right after the
> first byte. (Even an doing stat() is enough, since the size is
> not the same.)
>
> Another thing that came to my mind is maybe rename detection kicks
> in, even though no path vanished and none is new. I believe
> rename detection doesn't happen for unstaged changes, which might
> explain the difference in speed.
>
> btw, I forgot to mention that I get this with branches maint,
> master, next and pu.
Interestingly, all of
git diff --stat
git diff --stat --cached
git diff --stat HEAD
are "fast" (0.2s or so), i.e. diffing index-wtree, HEAD-index,
HEAD-wtree. Linus' threaded stat doesn't help either for status, btw (20s).
Experimenting further: Using 10 files with 10MB each (rather than 100
times 1MB) brings down the time by a factor 10 roughly - and so does
using 100 files with 100k each. Huh? Latter may be expected (10MB
total), but former (100MB total)?
Now it's getting funny: Changing your "echo >" to "echo ">>" (in your
100 files 1MB case) makes things "almost fast" again (1.3s).
OK, it's "use the source, Luke" time... Actually the part you don't see
takes the most time:
wt_status_print_updated()
And in fact I can confirm your suspicion: wt_status_print_updated()
enforces rename detection (ignoring any config). Forcing it off
(rev.diffopt.detect_rename = 0;) cuts down the 20s to 0.75s.
How about a config option status.renames (or something like -M) for status?
Michael
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: Rogan Dawes @ 2008-11-21 14:56 UTC (permalink / raw)
To: Marc Weber, git
In-Reply-To: <20081121133828.GB5912@gmx.de>
Marc Weber wrote:
> Use case:
>
> I've been reading parts of the topGit code. And it does make for it to
> add its own checks. However having to change the existing scripts
> insterting a call to the tg hooks isn't the best way.
> Why? one is using #/bin/sh the next is using #/bin/ruby maybe..
>
> So what about allowing (or even enforcing) ths directory layout?
>
> .git/hooks/pre-commit/hook1.sh
> .git/hooks/pre-commit/hook2.sh
> .git/hooks/pre-commit/topGitcheck.sh
I second Martin's suggestion, that you implement:
.git/hooks/pre-commit
.git/hooks/pre-commit.d/hook1.sh
where hooks/pre-commit is e.g. a shell script much like the init scripts
that iterate over the executables in the corresponding .d/ directory,
and execute them one at a time. Basing your script on initscripts will
likely save you some time, since they have already considered things
like script ordering, backups, etc.
I'm also inclined to think that this is likely to be a local
customisation, because you need to decide what makes sense in your
context, aborting if a script exits with a non-zero result, or
continuing to see if the next script manages to exit with a zero result.
e.g. in the pre-commit case, it *probably* makes sense to allow any
script to abort the commit, but your site-specific requirements might be
that all hooks must fail to abort the commit.
Regards,
Rogan
^ permalink raw reply
* Re: git-status for submodules
From: Junio C Hamano @ 2008-11-21 14:56 UTC (permalink / raw)
To: Chris Frey; +Cc: git
In-Reply-To: <20081120033615.GA21128@foursquare.net>
Chris Frey <cdfrey@foursquare.net> writes:
> I'm using git 1.6.0.4 and trying to make submodules work for me. The
> init/add/update steps are a bit tedious, but workable. The problem I have
> is when I make a change in a submodule, then git-status does not show
> the change.
My understanding is that this is exactly by design. The supermodule
tracks which commit in the subproject is bound to the tree location.
A mere act of changing something in the subproject directory is just a
single, incomplete step to create a new commit in the subproject and will
not be seen by the superproject's status. Instead of this workflow:
> cd super
> vi newsuper
> vi existing_file
> cd sub
> vi newsub
> cd ..
> git status
the submodule support is geared toward supporting this layout:
- "super" has a subproject X at "sub"
- When you do a real work on the subproject X, you do so as if
there is no supermodule. IOW, subproject X has to be able to
stand on its own.
One extreme case is you have a(nother) clone of subproject X that is
independent from "super", do the real work there and create new commit,
and update the subproject X inside "super". In such a workflow, "super"
will never see an intermediate state between commits in the subproject
directory.
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Jeff King @ 2008-11-21 14:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Andy Shevchenko, git
In-Reply-To: <4926AE4E.5000604@drmicha.warpmail.net>
On Fri, Nov 21, 2008 at 01:49:18PM +0100, Michael J Gruber wrote:
> In fact it is documented in git-send-email.txt:
>
> --[no-]validate::
> Perform sanity checks on patches.
> Currently, validation means the following:
Oh, right. Sorry, I stupidly looked at an older installed manpage
instead of going right to the source. So yes, it is documented.
-Peff
^ permalink raw reply
* Re: [TopGit PATCH] put die() messages to stderr
From: martin f krafft @ 2008-11-21 13:56 UTC (permalink / raw)
To: Marc Weber, git
In-Reply-To: <20081121132801.GA5912@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
also sprach Marc Weber <marco-oweber@gmx.de> [2008.11.21.1428 +0100]:
> > Shouldn't info also output to stderr?
>
> die is calling info. So this patch is enough.
Sure, I was just wondering whether info() shouldn't also print to
stderr. Or only die(). I think info() prints status messages, which
are not standard operation and thus don't go to stdout, but go to
stderr. No?
> You should just send this patch to the author. I think he'll apply
> it instantly. I've send a small patch to him yesterday as well.
Yes, but I applied that. :)
(I am Petr's apprentice, learning to help him a bit with TopGit).
--
martin | http://madduck.net/ | http://two.sentenc.es/
"wovon man nicht sprechen kann, darüber muß man schweigen."
-- wittgenstein
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What about allowing multiple hooks?
From: martin f krafft @ 2008-11-21 13:55 UTC (permalink / raw)
To: Marc Weber, git
In-Reply-To: <20081121133828.GB5912@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
also sprach Marc Weber <marco-oweber@gmx.de> [2008.11.21.1438 +0100]:
> So what about allowing (or even enforcing) ths directory layout?
>
> .git/hooks/pre-commit/hook1.sh
> .git/hooks/pre-commit/hook2.sh
> .git/hooks/pre-commit/topGitcheck.sh
>
> instead of
> .git/hooks/pre-commit # <- the one and only pre-commit hook
If you do this, I strongly suggest .git/hooks/pre-commit.d, and to
use .git/hooks/pre-commit to invoke it, which adds to transparency.
Debian does this all over the place. You need to ignore backup files
and/or only execute *.hook files, to be able to have other files in
there. Or the +x flag, as it is used now.
> The hook direcotry list apporach is better because you've more
> control about order of execution..
It's also way more transparent and natural.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"america may be unique in being a country which has leapt
from barbarism to decadence without touching civilization."
-- john o'hara
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* What about allowing multiple hooks?
From: Marc Weber @ 2008-11-21 13:38 UTC (permalink / raw)
To: git
Use case:
I've been reading parts of the topGit code. And it does make for it to
add its own checks. However having to change the existing scripts
insterting a call to the tg hooks isn't the best way.
Why? one is using #/bin/sh the next is using #/bin/ruby maybe..
So what about allowing (or even enforcing) ths directory layout?
.git/hooks/pre-commit/hook1.sh
.git/hooks/pre-commit/hook2.sh
.git/hooks/pre-commit/topGitcheck.sh
instead of
.git/hooks/pre-commit # <- the one and only pre-commit hook
so that all can be run in squence?
This way you can keep the original git sample files and update them
while adding you very own checks more easily.
But maybe this isn't the best choice either and the way to go is
.git/hooks/list-of-hook-directories # eg containing ".git/hooks/samples\n.git/hooks/topgit" ?
.git/hooks/sample/<all the sample hook files>
.git/hooks/topgit/pro-commit
?
Then you can actually link in your own personal check script directories
easily *and* you can add them to the repository eg by using
comitted-repo-hooks instead of .git/hooks
?
This way you could provide different hook directories for different
platforms and all you have to do is enabling them by adding the path to
.git/list-of-hook-directories ?
I guess the second approach of defining kind of overlays is better
because it doesn't interfer with the existiing scheme?
Maybe it should be implemented as git config option instead of a file
containing the list of directories?
The hook direcotry list apporach is better because you've more control
about order of execution..
Thoughts?
Marc Weber
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Andy Shevchenko @ 2008-11-21 13:29 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <4926AE4E.5000604@drmicha.warpmail.net>
On Fri, Nov 21, 2008 at 2:49 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> In fact it is documented in git-send-email.txt:
> --[no-]validate::
That is I found just after I have sent the first email.
P.S. Thanks for all, patch is wrong.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [TopGit PATCH] put die() messages to stderr
From: Marc Weber @ 2008-11-21 13:28 UTC (permalink / raw)
To: git
In-Reply-To: <20081121123654.GB20537@piper.oerlikon.madduck.net>
On Fri, Nov 21, 2008 at 01:36:54PM +0100, martin f krafft wrote:
> also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1105 +0100]:
> > - info "fatal: $*"
> > + info "fatal: $*" >&2
>
> Shouldn't info also output to stderr?
die is calling info. So this patch is enough.
You should just send this patch to the author. I think he'll apply it
instantly. I've send a small patch to him yesterday as well.
Marc Weber
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Arafangion @ 2008-11-21 10:34 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: git
In-Reply-To: <1227261564-13268-1-git-send-email-andy.shevchenko@gmail.com>
On Fri, 2008-11-21 at 11:59 +0200, Andy Shevchenko wrote:
> By default git-send-email does not accept patch which is contain lines longer
> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
> variable in shell script. So, define environment variable
> GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.
As a curiosity, why is such a check even neccessary?
^ permalink raw reply
* Re: [PATCH] git-send-email: provide hook to send lines more than 998 symbols
From: Michael J Gruber @ 2008-11-21 12:49 UTC (permalink / raw)
To: Jeff King; +Cc: Andy Shevchenko, git
In-Reply-To: <20081121115813.GB3747@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 21.11.2008 12:58:
> On Fri, Nov 21, 2008 at 11:59:24AM +0200, Andy Shevchenko wrote:
>
>> By default git-send-email does not accept patch which is contain lines longer
>> than 998 symbols. Sometime it's inconvenient, i.e. you have a long list in one
>> variable in shell script. So, define environment variable
>> GIT_SEND_EMAIL_LONGLINE to something to avoid that restriction.
>
> This already exists as "git send-email --no-validate", which
> unfortunately doesn't seem to be documented. Care to send in a
> documentation patch instead?
In fact it is documented in git-send-email.txt:
--[no-]validate::
Perform sanity checks on patches.
Currently, validation means the following:
+
--
* Warn of patches that contain lines longer than
998 characters; this
is due to SMTP limits as described by
http://www.ietf.org/rfc/rfc2821.txt.
--
+
Default is the value of 'sendemail.validate'; if this is not set,
default to '--validate'.
Cheers,
Michael
^ permalink raw reply
* Re: Bad git status performance
From: Jean-Luc Herren @ 2008-11-21 12:46 UTC (permalink / raw)
To: Glenn Griffin, Git Mailing List
In-Reply-To: <c9e534200811201711y887ddd2t33013ec4a7db3c9a@mail.gmail.com>
Glenn Griffin wrote:
> On Thu, Nov 20, 2008 at 4:28 PM, Jean-Luc Herren <jlh@gmx.ch> wrote:
>> The first 'git status' shows the same difference as the second,
>> just the second time it's staged instead of unstaged. Why does it
>> take 16 seconds the second time when it's instant the first time?
>
> I believe the two runs of git status need to do very different things.
> When run the first time, git knows the files in your working
> directory are not in the index so it can easily say those files are
> 'Changed but not updated' just from their existence.
I might be mistaken about how the index works, but those paths
*are* in the index at that time. They just have the old content,
i.e. the same content as in HEAD. When HEAD == index, then
nothing is staged.
But the presence of those files alone doesn't tell you that they
have changed. You have to look at the content and compare it to
the index (== HEAD in this situation) to see whether they have
changed or not and for some reason git can do this very quickly.
> The second run
> those files do exist in both the index and the working directory, so
> git status first shows the files that are 'Changes to be committed'
> and that should be fast, but additionally git status will check to see
> if those files in your working directory have changed since you added
> them to the index.
Which is basically the same comparision as above, just it turns
out that they have not changed. But even then, we're talking
about comparing a 1 byte file in the index to a 1 byte file in the
work tree. That doesn't take 16 seconds, even for 100 files.
So this makes me believe it's the first step (comparing HEAD to
the index to show staged changes) that is slow. And when you
compare a 1MB file to a 1 byte file, you don't need to read all of
the big file, you can tell they're not the same right after the
first byte. (Even an doing stat() is enough, since the size is
not the same.)
Another thing that came to my mind is maybe rename detection kicks
in, even though no path vanished and none is new. I believe
rename detection doesn't happen for unstaged changes, which might
explain the difference in speed.
btw, I forgot to mention that I get this with branches maint,
master, next and pu.
(And I hope you don't mind I take this back to the list.)
jlh
^ permalink raw reply
* Re: [TopGit PATCH] put die() messages to stderr
From: martin f krafft @ 2008-11-21 12:36 UTC (permalink / raw)
To: Bert Wesarg, Petr Baudis, git
In-Reply-To: <1227261900-23420-1-git-send-email-bert.wesarg@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1105 +0100]:
> - info "fatal: $*"
> + info "fatal: $*" >&2
Shouldn't info also output to stderr?
--
martin | http://madduck.net/ | http://two.sentenc.es/
"i have made good judgments in the past.
i have made good judgments in the future."
- george w. bush
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: martin f krafft @ 2008-11-21 12:31 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, petr baudis
In-Reply-To: <36ca99e90811210418i5ae14a42t882988aed289d534@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 622 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1318 +0100]:
> Oh, I send a patch only to petr, but forgot to cc the list ;-)
Maybe you can try to remember to CC me on topgit stuff in the future
too, since I am helping Petr out a bit as his release apprentice. :)
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
i stopped fighting my inner demons.. we're all on the same side now.
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: martin f krafft @ 2008-11-21 12:23 UTC (permalink / raw)
To: Bert Wesarg; +Cc: git, petr baudis, 501982
In-Reply-To: <36ca99e90811210415g7b50c5c1m3185bf19cab104aa@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1504 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2008.11.21.1315 +0100]:
> I CC'ed Junio, because I think this git rev-parse --git-dir is
> a bug. For example you can try starting git gui inside a .git dir.
You might want to let him know of your intention. :)
> A patch would depent on your --help patch, Because help should
> work everywhere. So either I wait for you or do do it.
No, not depend, but the patch makes the --help situation slightly
worse, for now you cannot call --help inside .git anymore either.
This will force us to fix the --help situation quicker.
I've run out of time, for a while at least. If you want to pick up
the pieces and convert argument parsing to POSIX getopt, or maybe
even better, git-rev-parse --parseopt, then please go for it. You
can find my current TopGit branch at
http://git.debian.org/?p=collab-maint/topgit.git;a=shortlog;h=refs/heads/fixes/independent-help
git://git.debian.org/git/collab-maint/topgit.git, branch fixes/independent-help
If you use Debian: debcheckout topgit (requires devscripts 2.10.40)
Thanks,
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"heuristic is computer science jargon for 'doesn't actually work.'"
-- charlie reiman
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: TopGit: ensure worktree (was: [TopGit PATCH] Check for help invocation before setup)
From: Bert Wesarg @ 2008-11-21 12:18 UTC (permalink / raw)
To: martin f krafft; +Cc: git, petr baudis, 501982
In-Reply-To: <36ca99e90811210415g7b50c5c1m3185bf19cab104aa@mail.gmail.com>
On Fri, Nov 21, 2008 at 13:15, Bert Wesarg <bert.wesarg@googlemail.com> wrote:
> On Fri, Nov 21, 2008 at 13:06, martin f krafft <madduck@debian.org> wrote:
>> I think you wanted to CC Petr, not Junio. It's also useful to CC
>> Debian bugs if you know of them. :)
> I CC'ed Junio, because I think this git rev-parse --git-dir is a bug.
> For example you can try starting git gui inside a .git dir.
Oh, I send a patch only to petr, but forgot to cc the list ;-)
But your patch should be fine, thanks.
Bert
^ 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