* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Shawn Pearce @ 2006-12-07 19:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612071121410.3615@woody.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
> I'm surprised that Apache can't do that. Or maybe it can, and it just
> needs some configuration entry? I don't know apache.. I realize that
> because Apache doesn't know before-hand whether something is cacheable or
> not, it must probably _default_ to running the CGI scripts to the same
> address in parallel, but it would be stupid to not have the option to
> serialize.
AFAIK it doesn't have such an option, for basically the reason
you describe. I worked on a project which had much more difficult
to answer queries than gitweb and were also very popular. Yes,
the system died under any load, no matter how much money was thrown
at it. :-)
> That said, from some of the other horrors I've heard about, "stupid" may
> be just scratching at the surface.
It is. :-)
--
^ permalink raw reply
* Re: [PATCH 2/2] Optionally check for uncommitted changes before switching branches.
From: Shawn Pearce @ 2006-12-07 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu007sdhp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Git shouldn't cause the user to make mistakes when it can help to
> > prevent them. So now users may set checkout.requireCleanDirectory
> > to true in their config file to have git-checkout verify the working
> > directory is clean before switching branches.
[...snip...]
> People with this new configuration set and has to override it
> with a command line switch will lose this ability if you
> overload that on '-m'.
Yes. That's a problem with this patch.
What about when this option is enabled then -m means do what we
did before, and -m -m (or -mm, or -m2) does what -m does when the
option is false?
--
^ permalink raw reply
* Re: Locked down (but still shared) repositories
From: Rogan Dawes @ 2006-12-07 19:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207191730.GA12143@spearce.org>
Shawn Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Thu, 7 Dec 2006, Shawn Pearce wrote:
>>
>>> For various auditing reasons the repositories need to be tightly
>>> controlled. That is the following cannot be permitted:
>>>
>>> [...]
>> How about just one such user? After all, you already have this user: the
>> repo owner. Of course, people have to push via ssh, even on the same
>> machine.
>
> How do I know which SSH key the client used to connect? Remember I'm
> looking at the real uid to determine who is performing the operation.
> In the situation you describe everyone looks the same to the
> update hook...
>
> For (probably stupid) reasons the server is the commerial F-Secure
> SSH server, btw. So OpenSSH based things wouldn't apply. And best
> that I can tell, F-Secure SSH won't tell me which key was used
> to authenticate.
>
See Section 8.2.6.1
http://www.unix.org.ua/orelly/networking_2ndEd/ssh/ch08_02.htm
You should be able to do something similar for git as they do for SSH.
Rogan
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: Junio C Hamano @ 2006-12-07 19:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061207100152.GA12966@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I have recently observed a rather large number of users who forget
> to specify the base revision when they start a new branch with
> git-checkout -b. Many of these users are shocked many hours and
> commits later when their prior branch is now also part of the new
> branch. Nasty words about Git usually follow the discovery.
>
> This introduces a new config option: checkout.requireSourceBranch,
I'm not sure about this.
Often after you started to code something while on 'master' you
realize that work is not trivial and needs its own branch and
then "checkout -b" without having to say 'master' (or HEAD) is
very handy.
I think requring an explicit fork-point when you are _not_ on
'master' might be a better behaviour.
In other words, you allow "checkout -b" (and "branch") to
default to HEAD only while on the branches marked in your
configuration file:
Then:
[branch]
allowbranchbydefault = main
allowbranchbydefault = test
can be used to say "while on 'main' and 'test' branch, 'git
checkout -b' and 'git branch' without branch point defaults to
the current branch".
You could turn it around and make it a per-branch configuration,
like:
[branch "main"]
allowbranchbydefault = true
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: Shawn Pearce @ 2006-12-07 19:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkljsd1k.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > This introduces a new config option: checkout.requireSourceBranch,
>
> You could turn it around and make it a per-branch configuration,
> like:
>
> [branch "main"]
> allowbranchbydefault = true
Are you suggesting that we change "git-checkout -b" to by default
require the source branch, but the user can restore the original
behavior by setting the above per-branch configuration option?
I'm OK with that version too. Most of these users want to be
required to enter the source branch, and their topic branches (which
are always their current branches btw) are so transient they won't
bother with a per-branch setting. So they get what they want:
the tool reminding them to select their source revision.
--
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Junio C Hamano @ 2006-12-07 19:57 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207192632.GC12143@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> I am not sure what you are trying. Do you mean stat() is slow
>> on your filesystem?
>
> Its Cygwin/NTFS. lstat() is slow. readdir() is slow. I have the
> same problem on my Cygwin systems.
>
>> > Is there any simple way to modify git commit for such a workflow?
>> > Failing that, any simple and _fast_ way to find out if the index
>> > is any different from HEAD? (so that I don't produce empty commits).
>>
>> Maybe you want "assume unchanged"?
>
> Yes, basically.
Then maybe "git grep assume.unchanged" would help?
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-07 19:58 UTC (permalink / raw)
To: Shawn Pearce
Cc: Linus Torvalds, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <20061207193903.GE12143@spearce.org>
Shawn Pearce wrote:
> Linus Torvalds <torvalds@osdl.org> wrote:
>> I'm surprised that Apache can't do that. Or maybe it can, and it just
>> needs some configuration entry? I don't know apache.. I realize that
>> because Apache doesn't know before-hand whether something is cacheable or
>> not, it must probably _default_ to running the CGI scripts to the same
>> address in parallel, but it would be stupid to not have the option to
>> serialize.
>
> AFAIK it doesn't have such an option, for basically the reason
> you describe. I worked on a project which had much more difficult
> to answer queries than gitweb and were also very popular. Yes,
> the system died under any load, no matter how much money was thrown
> at it. :-)
You certainly can be smarter about it when you know the nature of the
query, though. I do that with the patch viewer scripts.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-07 19:57 UTC (permalink / raw)
To: Olivier Galibert
Cc: Linus Torvalds, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <20061207193012.GA84678@dspnet.fr.eu.org>
Olivier Galibert wrote:
> On Thu, Dec 07, 2006 at 11:16:58AM -0800, H. Peter Anvin wrote:
>> Unfortunately, the most common queries are also extremely expensive.
>
> Do you have a top-ten of queries ? That would be the ones to optimize
> for.
The front page, summary page of each project, and the RSS feed for each
project.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-07 19:58 UTC (permalink / raw)
To: Shawn Pearce
Cc: H. Peter Anvin, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <20061207193903.GE12143@spearce.org>
On Thu, 7 Dec 2006, Shawn Pearce wrote:
>
> AFAIK it doesn't have such an option, for basically the reason
> you describe. I worked on a project which had much more difficult
> to answer queries than gitweb and were also very popular. Yes,
> the system died under any load, no matter how much money was thrown
> at it. :-)
>
> > That said, from some of the other horrors I've heard about, "stupid" may
> > be just scratching at the surface.
>
> It is. :-)
Gaah. That's just stupid. This is such a _basic_ issue for caching ("if
concurrent requests come in, only handle _one_ and give everybody the same
result") that I claim that any cache that doesn't handle it isn't a cache
at all, but a total disaster written by incompetent people.
Sure, you may want to disable it for certain kinds of truly dynamic
content, but that doesn't mean you shouldn't be able to do it at all.
Does anybody who is web-server clueful know if there is some simple
front-end (squid?) that is easy to set up and can just act as a caching
proxy in front of such an incompetent server?
Or maybe there is some competent Apache module, not just the default
mod_cache (which is what I assume kernel.org uses now)?
^ permalink raw reply
* Re: How to conver no branches/tags svn repo to git ?
From: Eric Wong @ 2006-12-07 19:59 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Shawn O. Pearce, git
In-Reply-To: <4b3406f0612070531p13611c68lf65a172c5e4e7b@mail.gmail.com>
Dongsheng Song <dongsheng.song@gmail.com> wrote:
> e.g.
> http://svn.berlios.de/viewcvs/open-iscsi/
> http://svn.berlios.de/svnroot/repos/open-iscsi
git svn init http://svn.berlios.de/svnroot/repos/open-iscsi
git svn fetch
--
^ permalink raw reply
* Re: [PATCH 5/5] git-svn: re-map repository URLs and UUIDs on SVK mirror paths
From: Eric Wong @ 2006-12-07 20:02 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <45775E52.90102@vilain.net>
Sam Vilain <sam@vilain.net> wrote:
> Eric Wong wrote:
> > Also, incremental fetches (or fetching more than 1k sequential
> > revisions) would probably fail. To fix this, read the offset of last
> > entry in .rev_db instead of git-svn-id: from the last commit to get the
> > last revision. But since rebuild won't work as expected; losing the
> > .rev_db file means you wouldn't be able to fetch from the SVK repo
> > anymore (but the original upstream one will be fine).
> >
> > One last thing: feature should be made optional. I actually work
> > day-to-day on a repository that was created with svm/SVN::Mirror,
> > the original repository no longer exists; but the mirrored one
> > still has these properties (I suppose I could remove the props
> > server-side, but some people may not have the permissions).
>
> ok, I'll work on that and the other issues you highlighted... possibly
> the overhead of fetching the revprops during mirroring might hurt a
> little for people not doing this, too. Thanks for reviewing the patch!
For the git-svn in master using the delta fetcher; there's no additional
overhead to fetch properties. I want to ditch the old non-delta
fetching code (it's only a mild performance benefit when using local
repositories) if I could get do_switch() working correctly.
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Junio C Hamano @ 2006-12-07 20:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Kernel Org Admin, H. Peter Anvin
In-Reply-To: <Pine.LNX.4.64.0612071121410.3615@woody.osdl.org>
If I understand correctly, kernel.org is still running the
version of gitweb Kay last installed there (I am too busy to
take over the gitweb installation maintenance at kernel.org, and
I did not ask the $DOCUMENTROOT/git/ directory to be transferred
to me when I rolled gitweb into the git.git repository).
I do not know what queries are most popular, but I think a newer
gitweb is more efficient in the summary page (getting list of
branches and tags). It might be worth a try.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-07 20:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Kernel Org Admin
In-Reply-To: <7vac1zsc8z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> If I understand correctly, kernel.org is still running the
> version of gitweb Kay last installed there (I am too busy to
> take over the gitweb installation maintenance at kernel.org, and
> I did not ask the $DOCUMENTROOT/git/ directory to be transferred
> to me when I rolled gitweb into the git.git repository).
That's correct. I can transfer that directory to you if you want; I
can't realistically track gitweb well enough to do this myself (in fact,
it was pretty much a condition of having it up there that Kay would keep
maintaining it.)
> I do not know what queries are most popular, but I think a newer
> gitweb is more efficient in the summary page (getting list of
> branches and tags). It might be worth a try.
How do you want to handle it?
-hpa
^ permalink raw reply
* Re: Locked down (but still shared) repositories
From: Shawn Pearce @ 2006-12-07 20:16 UTC (permalink / raw)
To: Rogan Dawes; +Cc: git
In-Reply-To: <45786F5A.6020400@dawes.za.net>
Rogan Dawes <discard@dawes.za.net> wrote:
> Shawn Pearce wrote:
> >In the situation you describe everyone looks the same to the
> >update hook...
>
> See Section 8.2.6.1
>
> http://www.unix.org.ua/orelly/networking_2ndEd/ssh/ch08_02.htm
>
> You should be able to do something similar for git as they do for SSH.
Ok, I just learned something new. Thank you!
Forced commands on a per-key basis would certainly work. I'm not
settled on the idea as the end solution, but it does seem to be
perhaps slightly better than the setuid approach.
--
^ permalink raw reply
* Re: Locked down (but still shared) repositories
From: Randal L. Schwartz @ 2006-12-07 20:16 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Shawn Pearce, git
In-Reply-To: <45786F5A.6020400@dawes.za.net>
>>>>> "Rogan" == Rogan Dawes <discard@dawes.za.net> writes:
Rogan> See Section 8.2.6.1
Rogan> http://[deleted]/orelly/networking_2ndEd/ssh/ch08_02.htm
Please don't point to pirated copies of O'Reilly (or other) books
on the web, especially when there are authors (like me) present.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Randal L. Schwartz @ 2006-12-07 20:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: Brian Gernhardt, git
In-Reply-To: <81b0412b0612070633i7aec43dse7a8beda64437103@mail.gmail.com>
>>>>> "Alex" == Alex Riesen <raa.lkml@gmail.com> writes:
Alex> Strange. You seem to have the old, generated Makefile you perl/
Alex> directory. Haven't your pull failed? If so, I suspect that
Alex> rm perl/Makefile
Alex> git reset --hard
Alex> git pull git...
I ended up having to do another reset afterward.
Definitely something went weird when Makefile was removed
from .gitignore.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Shawn Pearce @ 2006-12-07 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcw7scln.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> >> I am not sure what you are trying. Do you mean stat() is slow
> >> on your filesystem?
> >>
> >> Maybe you want "assume unchanged"?
> >
> > Yes, basically.
>
> Then maybe "git grep assume.unchanged" would help?
Hmm. OK, maybe I should have answered "No"" to your first question.
I keep looking at the assume unchanaged feature of update-index,
but refuse to use it because I'm a lazy guy who will forget to tell
the index a file has been modified. Consequently I'm going to miss
a change during a commit.
What may help (and without using assume unchanged) is:
* skip the `update-index --refresh` part of git-status/git-commit
* skip the status template in COMMIT_MSG when using the editor
As Git will still at least make sure a `commit -a` includes
everything that is dirty.
Files whose modification dates may have been messed with (but
whose content are unchanged) will just go through expensive SHA1
computation to arrive at the same value, which is fine.
Users skipping the first part are doing so under the assumption that
their modification dates are usually always correct, and that then
they aren't the SHA1 computation of a handful of files is cheap
compared to stat'ing the entire set of files.
Users skipping the second part are doing so under the assumption
that knowing the names of the files they are committing doesn't
really improve their odds of writing a good commit message.
--
^ permalink raw reply
* Re: Locked down (but still shared) repositories
From: Rogan Dawes @ 2006-12-07 20:32 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Shawn Pearce, git
In-Reply-To: <86irgnihqf.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
>>>>>> "Rogan" == Rogan Dawes <discard@dawes.za.net> writes:
>
> Rogan> See Section 8.2.6.1
>
> Rogan> http://[deleted]/orelly/networking_2ndEd/ssh/ch08_02.htm
>
> Please don't point to pirated copies of O'Reilly (or other) books
> on the web, especially when there are authors (like me) present.
>
Oops. I didn't realise/think. I just googled for the keywords I needed . . .
Not a very good excuse, I admit.
Sorry.
Rogan
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: Junio C Hamano @ 2006-12-07 21:23 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207195715.GG12143@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> > This introduces a new config option: checkout.requireSourceBranch,
>>
>> You could turn it around and make it a per-branch configuration,
>> like:
>>
>> [branch "main"]
>> allowbranchbydefault = true
>
> Are you suggesting that we change "git-checkout -b" to by default
> require the source branch, but the user can restore the original
> behavior by setting the above per-branch configuration option?
Under my suggestion, the new git-checkout -b (and git-branch)
would:
(0) proceed if there is an explicit branch point specified on
the command like, just like now;
(1) allow omission of branch-point if the current branch has
allowbranchbydefault configuration set as in above. A new
branch is created forking off of the current HEAD;
(2) allow omission of branch-point if no branch has such
configuration; in other words, existing repositories that
do not have the allowbranchbydefault configuration anywhere
are not affected. A new branch is created forking off of
the current HEAD;
(3) otherwise, it barfs if you do not give an explicit
branch-point.
and a newly created repository that is newbie friendly has one
such configuration automatically set for 'master' (if created
with git-init) or whatever the primary branch is (if created
with git-clone).
Note that (2) is rather important, although I think the current
implementation of repo-config is cumbersome to use for this
purpose and probably needs to be enhanced.
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Christian MICHON @ 2006-12-07 21:26 UTC (permalink / raw)
To: git
In-Reply-To: <20061207193555.GD12143@spearce.org>
On 12/7/06, Shawn Pearce <spearce@spearce.org> wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
> > Its Cygwin/NTFS. lstat() is slow. readdir() is slow. I have the
> > same problem on my Cygwin systems.
>
> Just to be clear, I'm not trying to blame Cygwin here.
>
> Windows' dir command is slow. Windows Explorer is slow while
> browsing directories. Eclipse chugs hard while doing any directory
> scans (it normally runs very fast if its not rescanning the entire
> directory structure). The drive is just plain slow.
> (...)
before buying any new hardware, you could easily imagine the
following scenario (I'm also "stuck" with windows, so it's an idea
I've been toying around for a week or so).
There're virtualizers around, on which networking capabilities can
be activated. And we could easily create a vm with linux+git
inside, using ext2/ext3/ext4 fs virtual disks (you'd benefit from
windows cache actually...)
example: YTech_Subversion_Appliance_v1.1 (ubuntu + subversion).
I've no prototype yet, but I've 2 scenario possible:
1) use vmplayer and a minimal uclibc initramfs with git onboard
2) use qemu+kqemu and a similar mini-distro (but right now networking
is an issue on windows hosts: I'm exploring tunneling)
The 1st scenario is "easy". And I start to prefer this idea over
even mingw porting of git (I tried and it's hard, really).
But again, maybe jgit would be a better universal solution.
--
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: J. Bruce Fields @ 2006-12-07 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7v64cns8nf.fsf@assigned-by-dhcp.cox.net>
On Thu, Dec 07, 2006 at 01:23:00PM -0800, Junio C Hamano wrote:
> Under my suggestion, the new git-checkout -b (and git-branch)
> would:
>
> (0) proceed if there is an explicit branch point specified on
> the command like, just like now;
>
> (1) allow omission of branch-point if the current branch has
> allowbranchbydefault configuration set as in above. A new
> branch is created forking off of the current HEAD;
>
> (2) allow omission of branch-point if no branch has such
> configuration; in other words, existing repositories that
> do not have the allowbranchbydefault configuration anywhere
> are not affected. A new branch is created forking off of
> the current HEAD;
>
> (3) otherwise, it barfs if you do not give an explicit
> branch-point.
>
> and a newly created repository that is newbie friendly has one
> such configuration automatically set for 'master' (if created
> with git-init) or whatever the primary branch is (if created
> with git-clone).
That makes the default behavior more complicated to explain. Is there
really sufficient evidence that this a serious problem?
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Junio C Hamano @ 2006-12-07 21:53 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207202931.GB12502@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> What may help (and without using assume unchanged) is:
>
> * skip the `update-index --refresh` part of git-status/git-commit
> * skip the status template in COMMIT_MSG when using the editor
>
> As Git will still at least make sure a `commit -a` includes
> everything that is dirty.
>
> Files whose modification dates may have been messed with (but
> whose content are unchanged) will just go through expensive SHA1
> computation to arrive at the same value, which is fine.
>
> Users skipping the first part are doing so under the assumption that
> their modification dates are usually always correct, and that then
> they aren't the SHA1 computation of a handful of files is cheap
> compared to stat'ing the entire set of files.
>
> Users skipping the second part are doing so under the assumption
> that knowing the names of the files they are committing doesn't
> really improve their odds of writing a good commit message.
The second part is not about a good commit message but more
about a path that should have been updated but forgotten (the
same mistake you would be likely to make and that is the reason
assume-unchanged is not good for you).
I do not mind too much if you added a new --quick option to "git
commit" for this rather specialized need.
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: Shawn Pearce @ 2006-12-07 21:59 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20061207214053.GC31035@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Dec 07, 2006 at 01:23:00PM -0800, Junio C Hamano wrote:
> > Under my suggestion, the new git-checkout -b (and git-branch)
> > would:
> >
[snip]
>
> That makes the default behavior more complicated to explain. Is there
> really sufficient evidence that this a serious problem?
I'm seeing bad branches all to often with some of the folks I have
to work with. They apparently have been unable to learn the new
trick of either remembering what branch they are currently on and
what changes it has, or to always supply the branch they want to
start from with their new branch.
Consequently they are cussing at Git rather often, as "this damn
Git crap always does the wrong with my files". Despite it being
their own fault for not thinking before doing...
Of course many of these users also don't understand the value of a
good short diff for a simple change. *sigh* But right now I just
want to stop them from creating branches off the wrong branch point
95% of the time.
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Junio C Hamano @ 2006-12-07 22:11 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, git, Kernel Org Admin
In-Reply-To: <45787515.4010200@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Junio C Hamano wrote:
>> If I understand correctly, kernel.org is still running the
>> version of gitweb Kay last installed there (I am too busy to
>> take over the gitweb installation maintenance at kernel.org, and
>> I did not ask the $DOCUMENTROOT/git/ directory to be transferred
>> to me when I rolled gitweb into the git.git repository).
>
> That's correct. I can transfer that directory to you if you want; I
> can't realistically track gitweb well enough to do this myself...
Well, the reason I haven't asked to is because I don't have
enough time myself, so....
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Alex Riesen @ 2006-12-07 22:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd56vtt2g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Thu, Dec 07, 2006 20:16:39 +0100:
> > I have a kind of awkward project to work with (~44k files, many binaries).
> >
> > The normal "git commit", which seem to be more than enough
> > for anything and anyone else, is a really annoying procedure
> > in my context. It spend too much time refreshing index and
> > generating list of the files for the commit message.
> >
> > At first I stopped using git commit -a (doing only update-index),
>
> I am not sure what you are trying. Do you mean stat() is slow
> on your filesystem?
incredibly slow. That and the matter of having 44000 files to process
with that slow stat().
> > Is there any simple way to modify git commit for such a workflow?
> > Failing that, any simple and _fast_ way to find out if the index
> > is any different from HEAD? (so that I don't produce empty commits).
>
> Maybe you want "assume unchanged"?
>
If that is core.ignoreState you mean, than maybe this is what I mean.
I haven't tried it yet (now I wonder myself why I haven't tried it).
But (I'm repeating myself, in <81b0412b0612060235l5d5f93d0hd1aaf34924f7783@mail.gmail.com>)
I do not really understand how it _can_ help: "I ask because it does
not ignore stat info, as the name implies. Because if it would,
there'd be no point of calling lstat at all, wouldn't it?" That last
question was about refresh_cache_entry - it calls lstat
unconditionally.
Still, I guess I'll have to try it.
But aside from me trying ignoreState, can anyone help me with that
question regarding checking if the index is any different from HEAD?
Because even on a very brocken filesystem and 40k files in a repo you
sometimes do want to call git-update-index --refresh just to be sure
you haven't missed anything. And than it'll quickly become annoying
flicking ignoreState back and forth.
^ 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