* 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
* Re: cygwin, 44k files: how to commit only index?
From: Junio C Hamano @ 2006-12-07 22:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20061207221503.GA4990@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> But aside from me trying ignoreState, can anyone help me with that
> question regarding checking if the index is any different from HEAD?
Comparing index and HEAD should be cheap on a system with slow
lstat(), I think, as "git-diff-index --cached HEAD" should just
ignore the working tree altogether. Is that what you want?
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Junio C Hamano @ 2006-12-07 22:36 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, Alex Riesen
In-Reply-To: <86ejrbihnr.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "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.
Yes, perl/Makefile is getting overwritten by what Makefile.PL
generates. I thought the point of Alex's patch was to have it
muck with perl.mak and leave the tracked Makefile alone?
^ permalink raw reply
* Re: git pull and merging.
From: Josef Weidendorfer @ 2006-12-07 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <7vhcw7ttj9.fsf@assigned-by-dhcp.cox.net>
On Thursday 07 December 2006 20:06, you wrote:
> Once you place something like "branch.*.merge" in configuration
> file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> are talking about other repositories you regularly interact
> with, so it might be probably Ok to require the user to use a
> tracking branch if he wants the convenience of "branch.*.merge",
> and make its value name the local tracking branch instead of the
> remote branch.
>
> But that means I would never be able to benefit from the
> convenience of "branch.*.merge";
Hmm... that's true; actually, I did not thought about people
which do not want to have any tracking branches (again!). So
[remote "repo"]
url = ...
fetch = branch1
fetch = branch2
[branch "mybranch1"]
remote = repo
merge = branch1
actually looks fine, and is the only possible way.
But still, this does not work. You have to specify
merge = refs/heads/branch1
That's confusing (perhaps I can come up with a patch
to allow "branch1" alone).
So probably the best way is to write some more detailed
explanation into the docu ...
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Junio C Hamano @ 2006-12-07 22:55 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, Alex Riesen
In-Reply-To: <7vmz5zqqo7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
>>>>>>> "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.
>
> Yes, perl/Makefile is getting overwritten by what Makefile.PL
> generates. I thought the point of Alex's patch was to have it
> muck with perl.mak and leave the tracked Makefile alone?
Now, I am CLUELESS about what MakeMaker does, but would this
help?
---
diff --git a/perl/Makefile b/perl/Makefile
index bd483b0..099beda 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -29,7 +29,7 @@ $(makfile): ../GIT-CFLAGS Makefile
echo ' echo $(instdir_SQ)' >> $@
else
$(makfile): Makefile.PL ../GIT-CFLAGS
- '$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
+ '$(PERL_PATH_SQ)' $< PREFIX='$(prefix_SQ)'
endif
# this is just added comfort for calling make directly in perl dir
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index de73235..4168775 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -24,5 +24,6 @@ WriteMakefile(
NAME => 'Git',
VERSION_FROM => 'Git.pm',
PM => \%pm,
+ MAKEFILE => 'perl.mak',
%extra
);
^ permalink raw reply related
* Re: [PATCH 2/2] Optionally check for uncommitted changes before switching branches.
From: Junio C Hamano @ 2006-12-07 23:01 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207194358.GF12143@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> 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?
Wouldn't --force be more appropriate?
^ permalink raw reply
* Re: git pull and merging.
From: Junio C Hamano @ 2006-12-07 23:06 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <7vhcw7ttj9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Once you place something like "branch.*.merge" in configuration
> file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> are talking about other repositories you regularly interact
> with, so it might be probably Ok to require the user to use a
> tracking branch if he wants the convenience of "branch.*.merge",
> and make its value name the local tracking branch instead of the
> remote branch.
In other words, I am all for fixing this.
Although it may not hurt too much if we just redefine the
meaning of it to name the local tracking branch, using a
different name "branch.*.defaultmerge" is safer and would not
break existing repositories.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Michael K. Edwards @ 2006-12-07 23:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Shawn Pearce, H. Peter Anvin, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612071152410.3615@woody.osdl.org>
On 12/7/06, Linus Torvalds <torvalds@osdl.org> wrote:
> 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?
Squid in "transparent reverse proxy" mode isn't a bad choice, although
I don't know offhand whether it queues/clusters concurrent requests
for the same URL in the way you want. I suggest the "transparent"
deployment (netfilter/netlink integration) because you can slap it in
with no changes to the origin server and yank it out again if you have
a problem. The challenge is in getting conntrack to scale to a
zillion concurrent sessions, but you could probably find someone in
your crowd who knows something about that. :-)
Ignore any documentation that talks about httpd_accel_*. Configuring
transparent mode is a great deal simpler and saner in squid 2.6 than
it used to be; you just add a "transparent" parameter to the http_port
tag. With or without this tag, you set up what used to be called
"accelerator mode" using some parameters to http_port and cache_peer,
as described in
http://www.squid-cache.org/mail-archive/squid-users/200607/0162.html.
If transparent mode looks like the right thing for kernel.org, you
might be interested in some netfilter hackery to offload part of the
conntrack session lookup load to a front-end box that blocks DDoS and
acts more or less as an L4 switch plus session context cache. I've
been banging on a proof of concept implementation for a while, and am
currently working on integrating against 2.6.19 by splitting
nf_conntrack into front and back halves that interact via a sort of
Layer 2+ header. I have no idea yet whether it will have any
scalability benefit on dual-x86_64 class hardware (it was originally
conceived for rigid cache architectures where the random access
patterns of session lookups have drastic cache effects).
Cheers,
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Olivier Galibert @ 2006-12-07 23:50 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <4578722E.9030402@zytor.com>
On Thu, Dec 07, 2006 at 11:57:34AM -0800, H. Peter Anvin wrote:
> 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.
Hmmm, maybe you could have the summaries and rss feed generated on
push, which could also generate elementary files with lines of the
front page. That would make these top offenders static page serving.
OG.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-07 23:56 UTC (permalink / raw)
To: Olivier Galibert
Cc: Linus Torvalds, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <20061207235039.GA423@dspnet.fr.eu.org>
Olivier Galibert wrote:
> On Thu, Dec 07, 2006 at 11:57:34AM -0800, H. Peter Anvin wrote:
>> 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.
>
> Hmmm, maybe you could have the summaries and rss feed generated on
> push, which could also generate elementary files with lines of the
> front page. That would make these top offenders static page serving.
>
There are a lot of things which "could be done" given the proper cache
infrastructure and gitweb support.
^ permalink raw reply
* Re: git pull and merging.
From: Santi Béjar @ 2006-12-08 1:56 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Junio C Hamano, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612072354.01830.Josef.Weidendorfer@gmx.de>
On 12/7/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Thursday 07 December 2006 20:06, you wrote:
> > Once you place something like "branch.*.merge" in configuration
> > file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> > are talking about other repositories you regularly interact
> > with, so it might be probably Ok to require the user to use a
> > tracking branch if he wants the convenience of "branch.*.merge",
> > and make its value name the local tracking branch instead of the
> > remote branch.
> >
> > But that means I would never be able to benefit from the
> > convenience of "branch.*.merge";
>
> Hmm... that's true; actually, I did not thought about people
> which do not want to have any tracking branches (again!). So
>
> [remote "repo"]
> url = ...
> fetch = branch1
> fetch = branch2
>
> [branch "mybranch1"]
> remote = repo
> merge = branch1
>
> actually looks fine, and is the only possible way.
> But still, this does not work.
It works for me.
> You have to specify
>
> merge = refs/heads/branch1
It does not.
The merge line must match exactly the remote part of the refspec.
>
> That's confusing (perhaps I can come up with a patch
> to allow "branch1" alone).
>
> So probably the best way is to write some more detailed
> explanation into the docu ...
Perhaps that the branch.<name>.remote and branch.<name>.merge have the
equivalent meaning as the parameters of git-pull?
>
> Josef
> -
> 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
* Re: git pull and merging.
From: Santi Béjar @ 2006-12-08 2:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Josef Weidendorfer, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <7vac1zqpa3.fsf@assigned-by-dhcp.cox.net>
On 12/8/06, Junio C Hamano <junkio@cox.net> wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Once you place something like "branch.*.merge" in configuration
> > file (either $GIT_DIR/config, or a $GIT_DIR/remotes/* file), you
> > are talking about other repositories you regularly interact
> > with, so it might be probably Ok to require the user to use a
> > tracking branch if he wants the convenience of "branch.*.merge",
> > and make its value name the local tracking branch instead of the
> > remote branch.
>
> In other words, I am all for fixing this.
>
> Although it may not hurt too much if we just redefine the
> meaning of it to name the local tracking branch, using a
> different name "branch.*.defaultmerge" is safer and would not
> break existing repositories.
Or branch.*.localmerge?
^ permalink raw reply
* Re: Bug in merge-recursive in virtual commit corner case
From: Johannes Schindelin @ 2006-12-08 3:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061207192401.GB12143@spearce.org>
Hi,
can you send me at least the output of
$ git-rev-list --parents branch1 branch2
preferrably packed? There is nothing you can do legally wrong, since you
are not sending any data, only metadata.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: J. Bruce Fields @ 2006-12-08 3:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612071849340.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Dec 07, 2006 at 06:50:50PM +0100, Johannes Schindelin wrote:
> Even easier:
>
> $ mkdir /pub/my-repo.git
> $ cd /pub/my-repo.git
> $ git --bare init-db --shared
> $ git --bare fetch /home/alice/myproject master:master
>
> (Totally untested, of course.)
Of course--for some reason I didn't think of doing init-db with --bare.
Thanks again.
--b.
From 22e5bdd9de398f29dfb11125a0921bb4529e2ab7 Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Thu, 7 Dec 2006 22:32:28 -0500
Subject: [PATCH] Documentation: simpler shared repository creation
Take Johannes Schindelin's suggestion for a further simplification of the
shared repository creation using git --bare init-db --shared.
Also fix a mistake from the previous patch: I forgot to remove the manual setup
which the --shared does for us.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/cvs-migration.txt | 27 ++++++++-------------------
1 files changed, 8 insertions(+), 19 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 4fab0d7..20c5719 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -76,23 +76,15 @@ possibly created from scratch or from a tarball (see the
link:tutorial.html[tutorial]), or imported from an already existing CVS
repository (see the next section).
-Assume your existing repo is at /home/alice/myproject. Create a temporary
-empty shared repository and fetch your project into it:
+Assume your existing repo is at /home/alice/myproject. Create a new "bare"
+repository (a repository without a working tree) and fetch your project into
+it:
------------------------------------------------
-$ mkdir /pub/temporary
-$ cd /pub/temporary
-$ git init-db --shared
-$ git fetch /home/alice/myproject master:master
-------------------------------------------------
-
-Then create a "bare" repository at /pub/repo.git by just moving the contents of
-the .git directory there. The temporary repository can then be discarded.
-
-------------------------------------------------
-$ mv .git /pub/repo.git
-$ cd ..
-$ rm -rf temporary
+$ mkdir /pub/my-repo.git
+$ cd /pub/my-repo.git
+$ git --bare init-db --shared
+$ git --bare fetch /home/alice/myproject master:master
------------------------------------------------
Next, give every team member read/write access to this repository. One
@@ -105,10 +97,7 @@ Put all the committers in the same group, and make the repository
writable by that group:
------------------------------------------------
-$ cd /pub
-$ chgrp -R $group repo.git
-$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
-$ GIT_DIR=repo.git git repo-config core.sharedrepository true
+$ chgrp -R $group /pub/my-repo.git
------------------------------------------------
Make sure committers have a umask of at most 027, so that the directories
--
1.4.4.1.GIT
^ permalink raw reply related
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: J. Bruce Fields @ 2006-12-08 4:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061207215914.GC12502@spearce.org>
On Thu, Dec 07, 2006 at 04:59:14PM -0500, Shawn Pearce wrote:
> 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.
Well, it's true that "git branch" is the first thing I type whenever I
sit down, just to remember where I am....
Would the trick of putting the branch name in the shell prompt work?
> 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.
But my main complaint is just that I wouldn't want to see the behavior
of defaulting to HEAD--behavior which is simple, easy to explain, and
shared by most other git commands--by something significantly more
complicated. That's more a complaint about Junio's suggestion than
yours, though.
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Alex Riesen @ 2006-12-08 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6vbqqzh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Thu, Dec 07, 2006 23:29:54 +0100:
> > But aside from me trying ignoreState, can anyone help me with that
> > question regarding checking if the index is any different from HEAD?
>
> Comparing index and HEAD should be cheap on a system with slow
> lstat(), I think, as "git-diff-index --cached HEAD" should just
> ignore the working tree altogether. Is that what you want?
>
yes, except that it'll compare the whole trees. Could I make it stop
at first mismatch? "-q|--quiet" for git-diff-index perhaps?
It's just not only stat, but also, open, read, mmap (yes, I try to use
it for packs) and close are really slow here as well.
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: Shawn Pearce @ 2006-12-08 5:59 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20061208044516.GC5939@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Thu, Dec 07, 2006 at 04:59:14PM -0500, Shawn Pearce wrote:
> > 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.
>
> Would the trick of putting the branch name in the shell prompt work?
Its in the prompt for all of these users; I forced it in as part of
the system's /etc/profile.d. They just forget that they should think
about where they should start their branch from before they make it.
> But my main complaint is just that I wouldn't want to see the behavior
> of defaulting to HEAD--behavior which is simple, easy to explain, and
> shared by most other git commands--by something significantly more
> complicated. That's more a complaint about Junio's suggestion than
> yours, though.
True, defaulting to HEAD is something that is done almost everywhere.
Changing it for `git checkout -b` may surprise a lot of people,
almost as much as --index vs. --cached.
Maybe what I should do is stop whining about the command line
Porcelain-ish and get branch controls working in git-gui. Then I
can take away the command line from these users who are causing me
so much grief.
--
^ permalink raw reply
* Re: Bug in merge-recursive in virtual commit corner case
From: Junio C Hamano @ 2006-12-08 6:01 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, Johannes Schindelin
In-Reply-To: <20061207192401.GB12143@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Although Junio mentioned he recently saw something like this in
> git.git when he merged in your xdl_merge() code. I wonder if its
> the same issue.
No, that is not related at all. My initial attempt (which is
not in any commit that survives til today) used hash_sha1_file()
on the result from xdl_merge() where I should have used
write_sha1_file(), and I saw the same "oh, the required object
is not there" errors from everywhere.
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: J. Bruce Fields @ 2006-12-08 6:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061208055938.GB13999@spearce.org>
On Fri, Dec 08, 2006 at 12:59:38AM -0500, Shawn Pearce wrote:
> Its in the prompt for all of these users; I forced it in as part of
> the system's /etc/profile.d. They just forget that they should think
> about where they should start their branch from before they make it.
Maybe they don't really want to use topic branches at all? Could they
get away with just committing everything to master? Seems like kind of
a shame, though. Hm.
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: Shawn Pearce @ 2006-12-08 6:19 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
In-Reply-To: <20061208060850.GE5939@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Fri, Dec 08, 2006 at 12:59:38AM -0500, Shawn Pearce wrote:
> > Its in the prompt for all of these users; I forced it in as part of
> > the system's /etc/profile.d. They just forget that they should think
> > about where they should start their branch from before they make it.
>
> Maybe they don't really want to use topic branches at all? Could they
> get away with just committing everything to master? Seems like kind of
> a shame, though. Hm.
Good idea. But...
No, because they are working on at least two different unrelated
changes at once, and we aren't sure which will graduate into the
testing environment first. If the unrelated changes are intermingled
on the same branch then moving one moves both; and often at least
one of those unrelated changes isn't functioning right and could
cause headaches for the testing team.
--
^ permalink raw reply
* [PATCH] Documentation: update git-clone man page with new behavior
From: J. Bruce Fields @ 2006-12-08 6:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Update git-clone man page to reflect recent changes
(--use-separate-remote default and use of .git/config instead of
remotes files), and rewrite introduction.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-clone.txt | 25 ++++++++++++-------------
1 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index d5efa00..985043f 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -16,22 +16,21 @@ SYNOPSIS
DESCRIPTION
-----------
-Clones a repository into a newly created directory. All remote
-branch heads are copied under `$GIT_DIR/refs/heads/`, except
-that the remote `master` is also copied to `origin` branch.
-In addition, `$GIT_DIR/remotes/origin` file is set up to have
-this line:
+Clones a repository into a newly created directory, creates
+remote-tracking branches for each branch in the cloned repository
+(visible using `git branch -r`), and creates and checks out a master
+branch equal to the cloned repository's master branch.
- Pull: master:origin
-
-This is to help the typical workflow of working off of the
-remote `master` branch. Every time `git pull` without argument
-is run, the progress on the remote `master` branch is tracked by
-copying it into the local `origin` branch, and merged into the
-branch you are currently working on. Remote branches other than
-`master` are also added there to be tracked.
+After the clone, a plain `git fetch` without arguments will update
+all the remote-tracking branches, and a `git pull` without
+arguments will in addition merge the remote master branch into the
+current branch.
+This default configuration is achieved by creating references to
+the remote branch heads under `$GIT_DIR/refs/remotes/origin` and
+by initializing `remote.origin.url` and `remote.origin.fetch`
+configuration variables.
OPTIONS
-------
--
1.4.4.2.ga3cbd
^ permalink raw reply related
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: Junio C Hamano @ 2006-12-08 6:31 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git, J. Bruce Fields
In-Reply-To: <20061208055938.GB13999@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
>> But my main complaint is just that I wouldn't want to see the behavior
>> of defaulting to HEAD--behavior which is simple, easy to explain, and
>> shared by most other git commands--by something significantly more
>> complicated. That's more a complaint about Junio's suggestion than
>> yours, though.
>
> True, defaulting to HEAD is something that is done almost everywhere.
> Changing it for `git checkout -b` may surprise a lot of people,
> almost as much as --index vs. --cached.
I did not mean to change the default to something other than
HEAD depending on the configuration.
> (0) proceed if there is an explicit branch point specified on
> the command like, just like now;
... which is the same as before.
> (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;
... which allows people to do the same as before, but only on
selected "primary" branches;
> (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;
... which allows people to keep using the current behaviour in
existing repositories;
> (3) otherwise, it barfs if you do not give an explicit
> branch-point.
... but a newly created repositories would have an
allowbranchbydefault entry on "master" (and only on "master"),
which means new people would be prevented from making mistakes
when on a non-master branch 'foo':
$ git branch bar
and end up a foobar branch that is not based on 'master'. They
will instead get an error message that says "Hey, are you sure
you want to fork off of this branch 'foo'?"
But I do not deeply care about this. An option to disable
"default to HEAD" altogether is fine.
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Junio C Hamano @ 2006-12-08 6:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20061208052705.GA4318@steel.home>
fork0@t-online.de (Alex Riesen) writes:
> yes, except that it'll compare the whole trees. Could I make it stop
> at first mismatch? "-q|--quiet" for git-diff-index perhaps?
> It's just not only stat, but also, open, read, mmap (yes, I try to use
> it for packs) and close are really slow here as well.
That sounds like optimizing for a wrong case -- you expect the
index to match HEAD and trying to catch mistakes by detecting
a mismatch, right?
Having said that, I should point out that it is a low hanging
fruit to optimize "diff-index --cached" for cases where index
is expected to mostly match HEAD.
The current code for "diff-index --cached" reads the whole tree
into the index as stage #1 entries (diff-lib.c::run_diff_index),
and then compares stage #0 (from the original index contents)
and stage #1 (the tree parameter from the command line). Even
if you stop at the first mismatch, you would already have paid
the overhead to open and read all tree objects before even
starting the comparison.
However, this code is from the ancient time before cache-tree
was introduced in the index. If the index is expected to mostly
match HEAD, most of the cache-tree nodes are up-to-date, and
whole subtree can be skipped with a single comparison between
two tree SHA-1s at a shallower level of the directory tree.
In 'pu' (jc/diff topic), I have a very generic code to walk the
index, working tree and zero or more trees in parallel, taking
advantage of cache-tree. If somebody is interested to learn the
internals of git, some of the code could be lifted from there
and simplified to walk just the index and a single tree, and I
think that would optimize "diff-index --cached" quite a bit.
A very unscientific test of running in the kernel repository I
just pulled (hot cache) on my box is:
$ /usr/bin/time git diff-index -r --cached --abbrev v2.6.19 >/tmp/1
0.91user 0.20system 0:01.12elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+10949minor)pagefaults 0swaps
while the para-walk to produce the moral equivalent is:
$ /usr/bin/time test-para --no-work v2.6.19 >/tmp/2
0.11user 0.02system 0:00.13elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+4524minor)pagefaults 0swaps
^ permalink raw reply
* Re: git pull and merging.
From: Junio C Hamano @ 2006-12-08 7:07 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200612072354.01830.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> But that means I would never be able to benefit from the
>> convenience of "branch.*.merge";
>
> Hmm... that's true; actually, I did not thought about people
> which do not want to have any tracking branches (again!). So
>
> [remote "repo"]
> url = ...
> fetch = branch1
> fetch = branch2
>
> [branch "mybranch1"]
> remote = repo
> merge = branch1
>
> actually looks fine, and is the only possible way.
Yeah, when you lay it out that way, it absolutely makes sense to
have "branch1" which is the name of the remote branch, not the
local counterpart that tracks it, as the value of the "merge"
configuration.
> But still, this does not work. You have to specify
>
> merge = refs/heads/branch1
>
> That's confusing (perhaps I can come up with a patch
> to allow "branch1" alone).
I think that might make things easier to read, but it might
introduce ambiguities, especially you do not control the set of
remote branches and tags.
^ permalink raw reply
* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: Junio C Hamano @ 2006-12-08 7:25 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20061208033400.GD30129@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> From 22e5bdd9de398f29dfb11125a0921bb4529e2ab7 Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Thu, 7 Dec 2006 22:32:28 -0500
> Subject: [PATCH] Documentation: simpler shared repository creation
>
> Take Johannes Schindelin's suggestion for a further simplification of the
> shared repository creation using git --bare init-db --shared.
>
> Also fix a mistake from the previous patch: I forgot to remove the manual setup
> which the --shared does for us.
>
> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
> ---
> Documentation/cvs-migration.txt | 27 ++++++++-------------------
> 1 files changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
> index 4fab0d7..20c5719 100644
Well, this does not apply at all, as I do not have a commit with
4fab0d7 blob and already applied the reordering patch from you.
Could you fix up and send again after I push out the latest? I
could try to coax into the documentation, but since I am not
even a CVS migrant myself and am known to be very bad at
documentation, I _really_ don't think you want me to do so.
;-)
^ 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