* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 3:47 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.185203.262588544.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 21:41:19 -0500
>
> > It is true I gave up quickly, but this is mainly because i don't like
> > to fight with my tools.
> > I am quite fine with a distributed workflow, I now use 8 or so gcc
> > branches in mercurial (auto synced from svn) and merge a lot between
> > them. I wanted to see if git would sanely let me manage the commits
> > back to svn. After fighting with it, i gave up and just wrote a
> > python extension to hg that lets me commit non-svn changesets back to
> > svn directly from hg.
>
> I find it ironic that you were even willing to write tools to
> facilitate your hg based gcc workflow.
Why?
> That really shows what your
> thinking is on this matter, in that you're willing to put effort
> towards making hg work better for you but you're not willing to expend
> that level of effort to see if git can do so as well.
See, now you claim to know my thinking.
I went back to hg because the GIT's space usage wasn't even in the
ballpark, i couldn't get git-svn rebase to update the revs after the
initial import (even though i had properly used a rewriteRoot).
The size is clearly not just svn data, it's in the git pack itself.
I spent a long time working on SVN to reduce it's space usage (repo
side and cleaning up the client side and giving a path to svn devs to
reduce it further), as well as ui issues, and I really don't feel like
having to do the same for GIT.
I'm tired of having to spend a large amount of effort to get my tools
to work. If the community wants to find and fix the problem, i've
already said repeatedly i'll happily give over my repo, data,
whatever. You are correct i am not going to spend even more effort
when i can be productive with something else much quicker. The devil
i know (committing to svn) is better than the devil i don't (diving
into git source code and finding/fixing what is causing this space
blowup).
The python extension took me a few hours (< 4).
In git, i spent these hours waiting for git-gc to finish.
> This is what really eats me from the inside about your dissatisfaction
> with git. Your analysis seems to be a self-fullfilling prophecy, and
> that's totally unfair to both hg and git.
Oh?
You seem to be taking this awfully personally.
I came into this completely open minded. Really, I did (i'm sure
you'll claim otherwise).
GIT people told me it would work great and i'd have a really small git
repo and be able to commit back to svn.
I tried it.
It didn't work out.
It doesn't seem to be usable for whatever reason.
I'm happy to give details, data, whatever.
I made the engineering decision that my effort would be better spent
doing something I knew i could do quickly (make hg commit back to svn
for my purposes) then trying to improve larger issues in GIT (UI and
space usage). That took me a few hours, and I was happy again.
I would have been incredibly happy to have git just have come up with
a 400 meg gcc repository, and to be happily committing away from
git-svn to gcc's repository ...
But it didn't happen.
So far, you have yet to actually do anything but incorrectly tell me
what I am thinking.
I'll probably try again in 6 months, and maybe it will be better.
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-06 4:20 UTC (permalink / raw)
To: dberlin; +Cc: ismail, gcc, git
In-Reply-To: <4aca3dc20712051947t5fbbb383ua1727c652eb25d7e@mail.gmail.com>
From: "Daniel Berlin" <dberlin@dberlin.org>
Date: Wed, 5 Dec 2007 22:47:01 -0500
> The size is clearly not just svn data, it's in the git pack itself.
And other users have shown much smaller metadata from a GIT import,
and yes those are including all of the repository history and branches
not just the trunk.
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 4:25 UTC (permalink / raw)
To: Daniel Berlin; +Cc: David Miller, ismail, gcc, git
In-Reply-To: <4aca3dc20712051947t5fbbb383ua1727c652eb25d7e@mail.gmail.com>
I fought with this a few months ago when I did my own clone of gcc svn.
My bad for only discussing this on #git at the time. Should have put
this to the list as well.
If anyone recalls my report was something along the lines of
git gc --aggressive explodes pack size.
git repack -a -d --depth=100 --window=100 produced a ~550MB packfile
immediately afterwards a git gc --aggressive produces a 1.5G packfile.
This was for all branches/tags, not just trunk like Daniel's repo.
The best theory I had at the time was that the gc doesn't find as good
deltas or doesn't allow the same delta chain depth and so generates a
new object in the pack, rather the reusing a good delta it already has
in the well-packed pack.
Cheers,
Harvey
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 4:28 UTC (permalink / raw)
To: David Miller; +Cc: dberlin, ismail, gcc, git
In-Reply-To: <20071205.202047.58135920.davem@davemloft.net>
On Wed, 2007-12-05 at 20:20 -0800, David Miller wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes those are including all of the repository history and branches
> not just the trunk.
David, I think it is actually a bug in git gc with the --aggressive
option...mind you, even if he solves that the format git svn uses
for its bi-directional metadata is so space-inefficient Daniel will
be crying for other reasons immediately afterwards...4MB for every
branch and tag in gcc svn (more than a few thousand).
You only need it around for any branches you are planning on committing
to but it is all created during the default git svn import.
FYI
Harvey
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-12-06 4:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlwps8zf.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 05, 2007 at 02:59:16AM -0800, Junio C Hamano wrote:
> * jc/clean-fix (Tue Dec 4 23:55:41 2007 -0800) 1 commit
> - git-clean: Honor pathspec.
>
> This does fix limited test cases I tried, but I didn't check the
> directory related options at all. Sanity checking appreciated. We need
> a regression fix before v1.5.4
Hrm, I took a look at this and I'm a bit stumped.
I think the logic in builtin-clean is a bit suspect, and I have a patch
below that fixes it.
However, I still can't get something as simple as:
mkdir dir.clean &&
touch dir.clean/file &&
git clean -d "*.clean/"
to work, and I think the pathspec matching is to blame. If I use
"*.clean/", then read_directory assumes that "*.clean" is a directory to
be opened, without considering that it might be a wildcard, which is
just wrong. If I use "*.clean", then I get the correct directory
listing, but match_pathspec fails because read_directory returns
"dir.clean/". We could fix this by passing match_pathspec ent->len - 1,
but that actually ends up getting ignored! It ends up handing the string
to fnmatch, which treats it like a C string.
Am I crazy, or do we need to fix the wildcard semantics for directories
with both read_directory and with match_pathspec?
Below is my partial patch for reference.
-Peff
---
diff --git a/builtin-clean.c b/builtin-clean.c
index 61ae851..f4cf39f 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -117,7 +117,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
}
if (!lstat(ent->name, &st) && (S_ISDIR(st.st_mode))) {
- int matched_path = 0;
+ int matched_path = !pathspec;
strbuf_addstr(&directory, ent->name);
if (pathspec) {
/*
@@ -128,11 +128,11 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
baselen, seen))
matched_path = 1;
}
- if (show_only && (remove_directories || matched_path)) {
+ if (show_only && (remove_directories && matched_path)) {
printf("Would remove %s\n", directory.buf);
- } else if (quiet && (remove_directories || matched_path)) {
+ } else if (quiet && (remove_directories && matched_path)) {
remove_dir_recursively(&directory, 0);
- } else if (remove_directories || matched_path) {
+ } else if (remove_directories && matched_path) {
printf("Removing %s\n", directory.buf);
remove_dir_recursively(&directory, 0);
} else if (show_only) {
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index dfd1188..f204a50 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -192,6 +192,34 @@ test_expect_success 'git-clean -d src/ examples/' '
'
+test_expect_success 'git-clean with directory wildcards' '
+
+ mkdir -p dir.clean dir.stay &&
+ touch dir.clean/file dir.stay/file &&
+ git clean "*.clean" &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f dir.stay/file &&
+ test -f dir.clean/file
+
+'
+
+test_expect_success 'git-clean -d with directory wildcards' '
+
+ mkdir -p dir.clean dir.stay &&
+ touch dir.clean/file dir.stay/file &&
+ git clean -d "*.clean" &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test -f dir.stay/file &&
+ test ! -f dir.clean/file
+
+'
+
test_expect_success 'git-clean -x' '
mkdir -p build docs &&
^ permalink raw reply related
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 4:32 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.202047.58135920.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 22:47:01 -0500
>
> > The size is clearly not just svn data, it's in the git pack itself.
>
> And other users have shown much smaller metadata from a GIT import,
> and yes those are including all of the repository history and branches
> not just the trunk.
I followed the instructions in the tutorials.
I followed the instructions given to by people who created these.
I came up with a 1.5 gig pack file.
You want to help, or you want to argue with me.
Right now it sounds like you are trying to blame me or make it look
like i did something wrong.
You are of course, welcome to try it yourself.
I can give you the absolute exactly commands I gave, and with git
1.5.3.7, it will give you a 1.5 gig pack file.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jeff King @ 2007-12-06 4:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fj60uc$er$2@ger.gmane.org>
On Wed, Dec 05, 2007 at 12:10:04PM +0100, Jakub Narebski wrote:
> Junio C Hamano wrote:
>
> > * jk/builtin-alias (Fri Nov 30 11:22:58 2007 -0500) 1 commit
> > + Support builtin aliases
> >
> > Cute hack. I'd like to have "git less" here.
>
> I guess that "git whatchanged" can be implemented also as builtin alias.
If you are thinking of
[alias]
whatchanged = log --raw --full-history
it does not quite work. git-log unconditionally sets --always, and there
is no command line option to turn it off. In most cases you could get an
approximation by using --no-merges, but it would still show commits that
actually have no tree change (there are 2 in git.git).
-Peff
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-06 4:48 UTC (permalink / raw)
To: dberlin; +Cc: ismail, gcc, git
In-Reply-To: <4aca3dc20712052032n521c344cla07a5df1f2c26cb8@mail.gmail.com>
From: "Daniel Berlin" <dberlin@dberlin.org>
Date: Wed, 5 Dec 2007 23:32:52 -0500
> On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > From: "Daniel Berlin" <dberlin@dberlin.org>
> > Date: Wed, 5 Dec 2007 22:47:01 -0500
> >
> > > The size is clearly not just svn data, it's in the git pack itself.
> >
> > And other users have shown much smaller metadata from a GIT import,
> > and yes those are including all of the repository history and branches
> > not just the trunk.
> I followed the instructions in the tutorials.
> I followed the instructions given to by people who created these.
> I came up with a 1.5 gig pack file.
> You want to help, or you want to argue with me.
Several people replied in this thread showing what options can lead to
smaller pack files.
They also listed what the GIT limitations are that would effect the
kind of work you are doing, which seemed to mostly deal with the high
space cost of branching and tags when converting to/from SVN repos.
^ permalink raw reply
* When a merge turns into a conflict
From: Anand Kumria @ 2007-12-06 4:49 UTC (permalink / raw)
To: git
Hi,
I've just had an odd experience with git (1.5.3.1) and wondered if this
was a known issue.
One of my co-developers has a project, with a README.txt file. I branch
from it and begin some edits:
- make it more AsciiDoc like (ala git)
- put in the README.txt a few patches that need to be applied
I had no issues 'git add' the file, and performing changes.
However when my colleague came to merge my patches in; git complained
that the file had conflict because:
a. it found the ========= AsciiDoc header line
b. it found the diff markers in the file
I do not know git well enough to know if this is a heurestic that can be
tweaked via the config file or something else. I am presently learning
git-filter-branch so I can prepare something to show -- but I just wanted
to flag and see if anyone else had had the same issue.
Thanks,
Anand
^ permalink raw reply
* Re: [PATCH] Soft aliases: add "less" and minimal documentation
From: Jeff King @ 2007-12-06 4:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vd4tlorho.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 05, 2007 at 11:45:23AM -0800, Junio C Hamano wrote:
> I actually regret to have suggested "git less". Not only because you
> can always say "git show" instead, but because the error message you
> would get with usage string will _not_ say "git-less", but some other
> command's name if you say "git less nonsense".
>
> I on the other hand find the "view" alias moderately less problematic.
> As long as the future direction for the "view" alias is to allow it to
> notice user preference and launch something other than the default
> "gitk", iow, it is crystal clear that "git view" is just a short-hand
> for launching a history browser and the users are free to choose
> whichever viewer available, it won't feel inconsistent if underlying
> "gitk" barfed on malformed input using its own name.
The pattern I see here is that we get into trouble when we _pretend_
that builtin aliases are real commands, and not just handy shortcuts for
the real commands.
IOW, if a user is told that "git less" is the command to look at
objects, then they will:
1. get confused when "git less" claims to be "git cat-file" or "git
show" in error messages
2. get confused when there is no "git less" manpage
3. get confused when their coworker's "git less" behaves completely
differently
OTOH, if a user is told that "git less" is an alias for the user's
preferred method for viewing objects, that the default is "git show",
and that they can customize it themselves using alias.less, then I don't
think any of the above will be surprising.
So I think it is a bad idea to use such aliases to satisfy user requests
for simple commands, even when they can obviously be implemented as such
an alias.
That being said...
> By extension to this reasoning, I am not too keen on adding "update",
> "up", "checkin", "ci", nor "co". I do not think of any alternative
I think "checkin", "ci", and "co" are well-understood as aliases (and
will be doubly so if they are presented in the documentation as such).
After all, they come from CVS, which treats them this way:
$ cvs co
cvs checkout: No CVSROOT specified! Please use the `-d' option
^^^^^^^^
-Peff
^ permalink raw reply
* Re: Git and GCC
From: Linus Torvalds @ 2007-12-06 4:54 UTC (permalink / raw)
To: Harvey Harrison; +Cc: Daniel Berlin, David Miller, ismail, gcc, git
In-Reply-To: <1196915112.10408.66.camel@brick>
On Wed, 5 Dec 2007, Harvey Harrison wrote:
>
> If anyone recalls my report was something along the lines of
> git gc --aggressive explodes pack size.
Yes, --aggressive is generally a bad idea. I think we should remove it or
at least fix it. It doesn't do what the name implies, because it actually
throws away potentially good packing, and re-does it all from a clean
slate.
That said, it's totally pointless for a person who isn't a git proponent
to do an initial import, and in that sense I agree with Daniel: he
shouldn't waste his time with tools that he doesn't know or care about,
since there are people who *can* do a better job, and who know what they
are doing, and understand and like the tool.
While you can do a half-assed job with just mindlessly running "git
svnimport" (which is deprecated these days) or "git svn clone" (better),
the fact is, to do a *good* import does likely mean spending some effort
on it. Trying to make the user names / emails to be better with a mailmap,
for example.
[ By default, for example, "git svn clone/fetch" seems to create those
horrible fake email addresses that contain the ID of the SVN repo in
each commit - I'm not talking about the "git-svn-id", I'm talking about
the "user@hex-string-goes-here" thing for the author. Maybe people don't
really care, but isn't that ugly as hell? I'd think it's worth it doing
a really nice import, spending some effort on it.
But maybe those things come from the older CVS->SVN import, I don't
really know. I've done a few SVN imports, but I've done them just for
stuff where I didn't want to touch SVN, but just wanted to track some
project like libgpod. For things like *that*, a totally mindless "git
svn" thing is fine ]
Of course, that does require there to be git people in the gcc crowd who
are motivated enough to do the proper import and then make sure it's
up-to-date and hosted somewhere. If those people don't exist, I'm not sure
there's much idea to it.
The point being, you cannot ask a non-git person to do a major git import
for an actual switch-over. Yes, it *can* be as simple as just doing a
git svn clone --stdlayout svn://svn://gcc.gnu.org/svn/gcc gcc
but the fact remains, you want to spend more effort and expertise on it if
you actually want the result to be used as a basis for future work (as
opposed to just tracking somebody elses SVN tree).
That includes:
- do the historic import with good packing (and no, "--aggressive"
is not it, never mind the misleading name and man-page)
- probably mailmap entries, certainly spending some time validating the
results.
- hosting it
and perhaps most importantly
- helping people who are *not* git users get up to speed.
because doing a good job at it is like asking a CVS newbie to set up a
branch in CVS. I'm sure you can do it from man-pages, but I'm also sure
you sure as hell won't like the end result.
Linus
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 5:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Berlin, David Miller, ismail, gcc, git
In-Reply-To: <alpine.LFD.0.9999.0712052033570.13796@woody.linux-foundation.org>
On Wed, 2007-12-05 at 20:54 -0800, Linus Torvalds wrote:
>
> On Wed, 5 Dec 2007, Harvey Harrison wrote:
> >
> > If anyone recalls my report was something along the lines of
> > git gc --aggressive explodes pack size.
> [ By default, for example, "git svn clone/fetch" seems to create those
> horrible fake email addresses that contain the ID of the SVN repo in
> each commit - I'm not talking about the "git-svn-id", I'm talking about
> the "user@hex-string-goes-here" thing for the author. Maybe people don't
> really care, but isn't that ugly as hell? I'd think it's worth it doing
> a really nice import, spending some effort on it.
>
> But maybe those things come from the older CVS->SVN import, I don't
> really know. I've done a few SVN imports, but I've done them just for
> stuff where I didn't want to touch SVN, but just wanted to track some
> project like libgpod. For things like *that*, a totally mindless "git
> svn" thing is fine ]
>
git svn does accept a mailmap at import time with the same format as the
cvs importer I think. But for someone that just wants a repo to check
out this was easiest. I'd be willing to spend the time to do a nicer
job if there was any interest from the gcc side, but I'm not that
invested (other than owing them for an often-used tool).
Harvey
^ permalink raw reply
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 5:11 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.204848.227521641.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 23:32:52 -0500
>
> > On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > > From: "Daniel Berlin" <dberlin@dberlin.org>
> > > Date: Wed, 5 Dec 2007 22:47:01 -0500
> > >
> > > > The size is clearly not just svn data, it's in the git pack itself.
> > >
> > > And other users have shown much smaller metadata from a GIT import,
> > > and yes those are including all of the repository history and branches
> > > not just the trunk.
> > I followed the instructions in the tutorials.
> > I followed the instructions given to by people who created these.
> > I came up with a 1.5 gig pack file.
> > You want to help, or you want to argue with me.
>
> Several people replied in this thread showing what options can lead to
> smaller pack files.
Actually, one person did, but that's okay, let's assume it was several.
I am currently trying Harvey's options.
I asked about using the pre-existing repos so i didn't have to do
this, but they were all
1. Done using read-only imports or
2. Don't contain full history
(IE the one that contains full history that is often posted here was
done as a read only import and thus doesn't have the metadata).
> They also listed what the GIT limitations are that would effect the
> kind of work you are doing, which seemed to mostly deal with the high
> space cost of branching and tags when converting to/from SVN repos.
Actually, it turns out that git-gc --aggressive does this dumb thing
to pack files sometimes regardless of whether you converted from an
SVN repo or not.
^ permalink raw reply
* git-p4: Import not at root of tree.
From: David Brown @ 2007-12-06 5:15 UTC (permalink / raw)
To: Git
I'm trying to mirror a directory deep down in a very chaotically organized
Perforce repo. I'd like the git tree to contains the contents of this
directory, but not at the root of my tree.
In other words I'd like to have something like
git-p4 clone --strip=//depot/a/b/c --destination=foo //depot/a/b/c/d
Result in:
foo/d/...
and have only a single directory 'd' at the top of the resulting git repo.
My current choices seem to be to put the contents of 'd' at the root, or
have the whole 'a/b/c/d' tree visible as what the '--keep-path' option does.
If this isn't implemented, any suggestions on the best way to go about
implementing this, or another way to do this.
What I'm trying to do is emulate the behavior of a P4 client spec. There
is a single directory (now, there will probably be others later) that is in
a different place in Perforce and it needs to be in this directory in order
to build. I've tried working with a submodule, but it is cumbersome to do
things like bisections when there are dependencies between the trees.
Thanks,
Dave
^ permalink raw reply
* Re: Git and GCC
From: Harvey Harrison @ 2007-12-06 5:15 UTC (permalink / raw)
To: Daniel Berlin; +Cc: David Miller, ismail, gcc, git
In-Reply-To: <4aca3dc20712052111o730f6fb6h7a329ee811a70f28@mail.gmail.com>
On Thu, 2007-12-06 at 00:11 -0500, Daniel Berlin wrote:
> On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > From: "Daniel Berlin" <dberlin@dberlin.org>
> > Date: Wed, 5 Dec 2007 23:32:52 -0500
> >
> > > On 12/5/07, David Miller <davem@davemloft.net> wrote:
> > > > From: "Daniel Berlin" <dberlin@dberlin.org>
> > > > Date: Wed, 5 Dec 2007 22:47:01 -0500
> > > >
> > > > > The size is clearly not just svn data, it's in the git pack itself.
> > > >
> > > > And other users have shown much smaller metadata from a GIT import,
> > > > and yes those are including all of the repository history and branches
> > > > not just the trunk.
> > > I followed the instructions in the tutorials.
> > > I followed the instructions given to by people who created these.
> > > I came up with a 1.5 gig pack file.
> > > You want to help, or you want to argue with me.
> >
> > Several people replied in this thread showing what options can lead to
> > smaller pack files.
>
> Actually, one person did, but that's okay, let's assume it was several.
> I am currently trying Harvey's options.
>
> I asked about using the pre-existing repos so i didn't have to do
> this, but they were all
> 1. Done using read-only imports or
> 2. Don't contain full history
> (IE the one that contains full history that is often posted here was
> done as a read only import and thus doesn't have the metadata).
While you won't get the git svn metadata if you clone the infradead
repo, it can be recreated on the fly by git svn if you want to start
commiting directly to gcc svn.
Harvey
^ permalink raw reply
* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 5:17 UTC (permalink / raw)
To: Harvey Harrison; +Cc: David Miller, ismail, gcc, git
In-Reply-To: <1196918132.10408.85.camel@brick>
> While you won't get the git svn metadata if you clone the infradead
> repo, it can be recreated on the fly by git svn if you want to start
> commiting directly to gcc svn.
>
I will give this a try :)
^ permalink raw reply
* Re: [PATCH 2/3] git config --get-colorbool
From: Jeff King @ 2007-12-06 5:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <1196906706-11170-2-git-send-email-gitster@pobox.com>
[Eric Wong cc'd because of git-svn relevance]
On Wed, Dec 05, 2007 at 06:05:04PM -0800, Junio C Hamano wrote:
> This adds an option to help scripts find out color settings from
> the configuration file.
>
> git config --get-colorbool color.diff
>
> inspects color.diff variable, and exits with status 0 (i.e. success) if
> color is to be used. It exits with status 1 otherwise.
There is no way to differentiate between "do not use color" and "no
value found". This makes it impossible to use this to implement the
required "try color.diff, fallback to diff.color" behavior.
We could simply make it
git config --get-colorbool diff
which would check both (and when diff.color support is finally dropped,
just remove it from there).
git-svn should probably be moved to this interface (it still has the
color.diff == true means "always" behavior), but it can't be until the
fallback behavior is implemented.
Also, your patch doesn't seem to implement the color.pager/pager.color
behavior, either (which is probably not important for git-add -i, but is
used by git-svn).
Anyway, below is a totally untested (I don't even have svn installed,
but it passes perl -wc!) patch for git-svn to use the new "true means
auto" behavior for color.diff. It would be nice to replace this with
a working --get-colorbool, but we should at least unify the behavior
before v1.5.4.
-Peff
---
diff --git a/git-svn.perl b/git-svn.perl
index 9f884eb..71f6e93 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3979,7 +3979,12 @@ sub log_use_color {
$dc = `git-config --get $dcvar`;
}
chomp($dc);
- if ($dc eq 'auto') {
+ return 0 if $dc eq 'never';
+ return 1 if $dc eq 'always';
+ if ($dc ne 'auto') {
+ chomp($dc = `git-config --bool --get $dcvar`);
+ }
+ if ($dc eq 'auto' || $dc eq 'true') {
my $pc;
$pc = `git-config --get color.pager`;
if ($pc eq '') {
@@ -3998,10 +4003,7 @@ sub log_use_color {
}
return 0;
}
- return 0 if $dc eq 'never';
- return 1 if $dc eq 'always';
- chomp($dc = `git-config --bool --get $dcvar`);
- return ($dc eq 'true');
+ return 0;
}
sub git_svn_log_cmd {
^ permalink raw reply related
* Re: [PATCH 2/3] git config --get-colorbool
From: Jeff King @ 2007-12-06 5:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <20071206053059.GF5499@coredump.intra.peff.net>
On Thu, Dec 06, 2007 at 12:30:59AM -0500, Jeff King wrote:
> Also, your patch doesn't seem to implement the color.pager/pager.color
> behavior, either (which is probably not important for git-add -i, but is
> used by git-svn).
Oops, maybe I should actually read your patch more carefully before
criticizing. I see that you do handle pager_use_color in
git_config_colorbool, but I think that for --get-colorbool usage,
pager_in_use is going to be useless (wow, three forms of "use" in one
clause).
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] Color support for "git-add -i"
From: Jeff King @ 2007-12-06 5:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1196906706-11170-3-git-send-email-gitster@pobox.com>
On Wed, Dec 05, 2007 at 06:05:05PM -0800, Junio C Hamano wrote:
> This is mostly lifted from earlier series by Dan Zwell, but updated to
> use "git config --get-color" and "git config --get-colorbool" to make it
> simpler and more consistent with commands written in C.
Looks mostly sane, except for the colorbool issues I mentioned in
response to 2/3.
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 335c2c6..1019a72 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> [...]
> + # Do we also set diff colors?
> + $diff_use_color = $repo->get_colorbool('color.diff');
> + if ($diff_use_color) {
> + $new_color = $repo->get_color("color.diff.new", "green");
> + $old_color = $repo->get_color("color.diff.old", "red");
> + $fraginfo_color = $repo->get_color("color.diff.frag", "cyan");
> + $metainfo_color = $repo->get_color("color.diff.meta", "bold");
> + $whitespace_color = $repo->get_color("color.diff.whitespace", "normal red");
diff.color support?
BTW, I am nagging about this because we never resolved what should
happen. I am fine with the answer being "we are dropping support now."
> +sub colored {
> + my $color = shift;
> + my $string = join("", @_);
> +
> + if ($use_color) {
> + # Put a color code at the beginning of each line, a reset at the end
> + # color after newlines that are not at the end of the string
> + $string =~ s/(\n+)(.)/$1$color$2/g;
> + # reset before newlines
> + $string =~ s/(\n+)/$normal_color$1/g;
> + # codes at beginning and end (if necessary):
> + $string =~ s/^/$color/;
> + $string =~ s/$/$normal_color/ unless $string =~ /\n$/;
> + }
> + return $string;
> +}
I still think this should go into Git.pm; I believe git-svn could make
use of it.
> sub highlight_prefix {
> my $prefix = shift;
> my $remainder = shift;
> - return $remainder unless defined $prefix;
> - return is_valid_prefix($prefix) ?
> - "[$prefix]$remainder" :
> - "$prefix$remainder";
> +
> + if (!defined $prefix) {
> + return $remainder;
> + }
> +
> + if (!is_valid_prefix($prefix)) {
> + return "$prefix$remainder";
> + }
> +
> + if (!$use_color) {
> + return "[$prefix]$remainder";
> + }
> +
> + return "$prompt_color$prefix$normal_color$remainder";
Honestly, I find this blue+white coloring of the prefixes a bit ugly,
but that is not your fault. :)
-Peff
^ permalink raw reply
* Re: When a merge turns into a conflict
From: Junio C Hamano @ 2007-12-06 5:51 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <pan.2007.12.06.04.49.25@progsoc.org>
Anand Kumria <wildfire@progsoc.org> writes:
> However when my colleague came to merge my patches in; git complained
> that the file had conflict because:
>
> a. it found the ========= AsciiDoc header line
Perhaps .git/hooks/pre-commit hook is enabled for the person who needed
to merge, fix conflicts and make a commit.
We ship the hook _disabled_ by default, but that hook inspects the
change (relative to the HEAD, which means "difference this merge brings
in relative to the state before I started the merge") and complains if
it finds lines that:
* have trailing whitespaces,
* have a SP immediately before HT in the indentation, or
* matches 7 or more <, >, or = at the beginning (i.e. <<<<<<<, =======,
or >>>>>>>, typically are conflict markers).
And the last heuristics does trigger on an AsciiDoc text.
The easiest (and standard) workaround in such a case is, after
inspecting the change yourself to make sure you are bitten by false
positive, to commit with --no-verify option:
git commit --no-verify
This bypasses the pre-commit hook.
^ permalink raw reply
* Re: [PATCH/RFC] Use regex for :/ matching
From: Jeff King @ 2007-12-06 5:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vbq97iqxd.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 03, 2007 at 10:17:18AM -0800, Junio C Hamano wrote:
> So in short:
>
> * I do not think extending it to mean a set of commits (with some
> definition of how the set is computed) is a good idea. It can stay
> "name one commit that matches this string" without losing usefulness,
> and I think it should;
>
> * The definition of the "match" can be tweaked and introducing regexp
> might be a good way;
>
> * The definition of the "match" may become more useful if we can limit
> which refs to dig from.
Obviously the overall design and usage of :/ is going to take some
thinking and is not 1.5.4 material. However, we do have it in its
current form, and I think regex versus prefix string matching is
orthogonal to the range issues. Should I post my rebased :/ regex patch,
or do you want to just leave it for post-1.5.4?
-Peff
^ permalink raw reply
* Re: [PATCH v4] Allow update hooks to update refs on their own.
From: Jeff King @ 2007-12-06 5:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, git
In-Reply-To: <7vhciwn5rl.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 05, 2007 at 02:19:58PM -0800, Junio C Hamano wrote:
> > what rewriting was done by the server, and if another push happened in
> > the meantime, the client will have to basically guess about which
> > commits correspond to the ones it pushed.
>
> Ok, but the output from fetch is meant to be human readable and we do
> not promise parsability, so if we go this route (which I think you made
> a sensible argument for) we would need a hook on the pushing end to act
> on this (perhaps record the correspondence of pushed and rewritten sha1
> somewhere for the hook's own use).
I am not clear on what you mean. Are you saying that the send-pack code
should _not_ recognize the "ok, but I rewrote your commit" status?
Because that is how we will avoid updating the tracking ref, which I
think is a good goal.
Or are you saying "it's ok to understand the 'ok, but...' response and
not update the tracking ref, but pulling the new hash from the message
is up to a hook on the pushing side"? Which I think it reasonable.
Or alternatively, "there should be a hook on the pushing side which is
allowed to set the ref status to 'ok, but don't bother updating the
tracking ref' or 'ok, but here is the actual thing to put in the
tracking ref'"? Which is also fine by me.
-Peff
^ permalink raw reply
* Re: Git and GCC
From: Linus Torvalds @ 2007-12-06 6:09 UTC (permalink / raw)
To: Daniel Berlin; +Cc: David Miller, ismail, gcc, git
In-Reply-To: <4aca3dc20712052111o730f6fb6h7a329ee811a70f28@mail.gmail.com>
On Thu, 6 Dec 2007, Daniel Berlin wrote:
>
> Actually, it turns out that git-gc --aggressive does this dumb thing
> to pack files sometimes regardless of whether you converted from an
> SVN repo or not.
Absolutely. git --aggressive is mostly dumb. It's really only useful for
the case of "I know I have a *really* bad pack, and I want to throw away
all the bad packing decisions I have done".
To explain this, it's worth explaining (you are probably aware of it, but
let me go through the basics anyway) how git delta-chains work, and how
they are so different from most other systems.
In other SCM's, a delta-chain is generally fixed. It might be "forwards"
or "backwards", and it might evolve a bit as you work with the repository,
but generally it's a chain of changes to a single file represented as some
kind of single SCM entity. In CVS, it's obviously the *,v file, and a lot
of other systems do rather similar things.
Git also does delta-chains, but it does them a lot more "loosely". There
is no fixed entity. Delta's are generated against any random other version
that git deems to be a good delta candidate (with various fairly
successful heursitics), and there are absolutely no hard grouping rules.
This is generally a very good thing. It's good for various conceptual
reasons (ie git internally never really even needs to care about the whole
revision chain - it doesn't really think in terms of deltas at all), but
it's also great because getting rid of the inflexible delta rules means
that git doesn't have any problems at all with merging two files together,
for example - there simply are no arbitrary *,v "revision files" that have
some hidden meaning.
It also means that the choice of deltas is a much more open-ended
question. If you limit the delta chain to just one file, you really don't
have a lot of choices on what to do about deltas, but in git, it really
can be a totally different issue.
And this is where the really badly named "--aggressive" comes in. While
git generally tries to re-use delta information (because it's a good idea,
and it doesn't waste CPU time re-finding all the good deltas we found
earlier), sometimes you want to say "let's start all over, with a blank
slate, and ignore all the previous delta information, and try to generate
a new set of deltas".
So "--aggressive" is not really about being aggressive, but about wasting
CPU time re-doing a decision we already did earlier!
*Sometimes* that is a good thing. Some import tools in particular could
generate really horribly bad deltas. Anything that uses "git fast-import",
for example, likely doesn't have much of a great delta layout, so it might
be worth saying "I want to start from a clean slate".
But almost always, in other cases, it's actually a really bad thing to do.
It's going to waste CPU time, and especially if you had actually done a
good job at deltaing earlier, the end result isn't going to re-use all
those *good* deltas you already found, so you'll actually end up with a
much worse end result too!
I'll send a patch to Junio to just remove the "git gc --aggressive"
documentation. It can be useful, but it generally is useful only when you
really understand at a very deep level what it's doing, and that
documentation doesn't help you do that.
Generally, doing incremental "git gc" is the right approach, and better
than doing "git gc --aggressive". It's going to re-use old deltas, and
when those old deltas can't be found (the reason for doing incremental GC
in the first place!) it's going to create new ones.
On the other hand, it's definitely true that an "initial import of a long
and involved history" is a point where it can be worth spending a lot of
time finding the *really*good* deltas. Then, every user ever after (as
long as they don't use "git gc --aggressive" to undo it!) will get the
advantage of that one-time event. So especially for big projects with a
long history, it's probably worth doing some extra work, telling the delta
finding code to go wild.
So the equivalent of "git gc --aggressive" - but done *properly* - is to
do (overnight) something like
git repack -a -d --depth=250 --window=250
where that depth thing is just about how deep the delta chains can be
(make them longer for old history - it's worth the space overhead), and
the window thing is about how big an object window we want each delta
candidate to scan.
And here, you might well want to add the "-f" flag (which is the "drop all
old deltas", since you now are actually trying to make sure that this one
actually finds good candidates.
And then it's going to take forever and a day (ie a "do it overnight"
thing). But the end result is that everybody downstream from that
repository will get much better packs, without having to spend any effort
on it themselves.
Linus
^ permalink raw reply
* Re: [PATCH 2/3] git config --get-colorbool
From: Junio C Hamano @ 2007-12-06 6:12 UTC (permalink / raw)
To: Jeff King; +Cc: Eric Wong, git
In-Reply-To: <20071206053059.GF5499@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [Eric Wong cc'd because of git-svn relevance]
>
> On Wed, Dec 05, 2007 at 06:05:04PM -0800, Junio C Hamano wrote:
>
>> This adds an option to help scripts find out color settings from
>> the configuration file.
>>
>> git config --get-colorbool color.diff
>>
>> inspects color.diff variable, and exits with status 0 (i.e. success) if
>> color is to be used. It exits with status 1 otherwise.
>
> There is no way to differentiate between "do not use color" and "no
> value found". This makes it impossible to use this to implement the
> required "try color.diff, fallback to diff.color" behavior.
>
> We could simply make it
>
> git config --get-colorbool diff
>
> which would check both (and when diff.color support is finally dropped,
> just remove it from there).
I thought about this a bit and thought that it would probably be a good
workaround to teach "--get-colorbool that diff.color is a deprecated
synonym to color.diff, like this.
-- >8 --
config --get-colorbool: diff.color is a deprecated synonym to color.diff
The applications can ask for color.diff but the configuration of old
timer users can still instruct it to use color with diff.color this
way.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-config.c | 18 ++++++++++++++++--
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index d10b03f..e4a12e3 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -210,11 +210,17 @@ static int get_color(int argc, const char **argv)
static int stdout_is_tty;
static int get_colorbool_found;
+static int get_diff_color_found;
static int git_get_colorbool_config(const char *var, const char *value)
{
- if (!strcmp(var, get_color_slot))
+ if (!strcmp(var, get_color_slot)) {
get_colorbool_found =
git_config_colorbool(var, value, stdout_is_tty);
+ }
+ if (!strcmp(var, "diff.color")) {
+ get_diff_color_found =
+ git_config_colorbool(var, value, stdout_is_tty);
+ }
return 0;
}
@@ -233,10 +239,18 @@ static int get_colorbool(int argc, const char **argv)
stdout_is_tty = isatty(1);
else
usage(git_config_set_usage);
- get_colorbool_found = 0;
+ get_colorbool_found = -1;
+ get_diff_color_found = -1;
get_color_slot = argv[0];
git_config(git_get_colorbool_config);
+ if (get_colorbool_found < 0) {
+ if (!strcmp(get_color_slot, "color.diff"))
+ get_colorbool_found = get_diff_color_found;
+ if (get_colorbool_found < 0)
+ get_colorbool_found = 0;
+ }
+
if (argc == 1) {
return get_colorbool_found ? 0 : 1;
} else {
^ permalink raw reply related
* Re: [PATCH] Make Git accept absolute path names for files within the work tree
From: Jeff King @ 2007-12-06 6:12 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Robin Rosenberg, Junio C Hamano,
Anatol Pomozov, git
In-Reply-To: <alpine.LFD.0.9999.0712041444090.13796@woody.linux-foundation.org>
On Tue, Dec 04, 2007 at 02:52:15PM -0800, Linus Torvalds wrote:
> IOW, that whole thing is simply a bug waiting to happen. The fact that it
> apparently *always* runs whether needed or not just seems to make it worse
> (ie if we already know our cwd, and the absolute path we have already has
> that as a prefix, just strip it off, don't try to do anything complex, and
> leave the complex and fragile cases for the odd-ball when the simple
> approach doesn't work)
Fair enough. Something like this then? It gets called only as a
last-ditch (though I think the 'return path' should simply be a die
-- what is the point of getting a pathspec that isn't in the repo?).
---
diff --git a/setup.c b/setup.c
index 4ee8024..fbb956e 100644
--- a/setup.c
+++ b/setup.c
@@ -5,13 +5,17 @@ static int inside_git_dir = -1;
static int inside_work_tree = -1;
static
-const char *strip_work_tree_path(const char *prefix, int len, const char *path)
+const char *strip_work_tree_path(const char *prefix, int len, const char *path,
+ int canonicalized)
{
const char *work_tree = get_git_work_tree();
int n = strlen(work_tree);
if (strncmp(path, work_tree, n))
- return path;
+ return canonicalized ?
+ path :
+ strip_work_tree_path(prefix, len,
+ xstrdup(make_absolute_path(path)), 1);
if (!prefix && !path[n])
return path + n;
@@ -58,7 +62,7 @@ const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
if (is_absolute_path(path))
- path = strip_work_tree_path(prefix, len, path);
+ path = strip_work_tree_path(prefix, len, path, 0);
for (;;) {
char c;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox