* Re: Git and GCC
From: Daniel Berlin @ 2007-12-06 2:41 UTC (permalink / raw)
To: David Miller; +Cc: ismail, gcc, git
In-Reply-To: <20071205.182815.249974508.davem@davemloft.net>
On 12/5/07, David Miller <davem@davemloft.net> wrote:
> From: "Daniel Berlin" <dberlin@dberlin.org>
> Date: Wed, 5 Dec 2007 14:08:41 -0500
>
> > So I tried a full history conversion using git-svn of the gcc
> > repository (IE every trunk revision from 1-HEAD as of yesterday)
> > The git-svn import was done using repacks every 1000 revisions.
> > After it finished, I used git-gc --aggressive --prune. Two hours
> > later, it finished.
> > The final size after this is 1.5 gig for all of the history of gcc for
> > just trunk.
> >
> > dberlin@home:/compilerstuff/gitgcc/gccrepo/.git/objects/pack$ ls -trl
> > total 1568899
> > -r--r--r-- 1 dberlin dberlin 1585972834 2007-12-05 14:01
> > pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.pack
> > -r--r--r-- 1 dberlin dberlin 19008488 2007-12-05 14:01
> > pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.idx
> >
> > This is 3x bigger than hg *and* hg doesn't require me to waste my life
> > repacking every so often.
> > The hg operations run roughly as fast as the git ones
> >
> > I'm sure there are magic options, magic command lines, etc, i could
> > use to make it smaller.
> >
> > I'm sure if i spent the next few weeks fucking around with git, it may
> > even be usable!
> >
> > But given that git is harder to use, requires manual repacking to get
> > any kind of sane space usage, and is 3x bigger anyway, i don't see any
> > advantage to continuing to experiment with git and gcc.
>
> I would really appreciate it if you would share experiences
> like this with the GIT community, who have been now CC:'d.
>
> That's the only way this situation is going to improve.
>
> When you don't CC: the people who can fix the problem, I can only
> speculate that perhaps at least subconsciously you don't care if
> the situation improves or not.
>
I didn't cc the git community for three reasons
1. It's not the nicest message in the world, and thus, more likely to
get bad responses than constructive ones.
2. Based on the level of usability, I simply assume it is too young
for regular developers to use. At least, I hope this is the case.
3. People i know have had bad experiences talking usability issues
with the git community in the past. I am not likely to fare any
better, so I would rather have someone who is involved with both our
community and theirs, raise these issues, rather than a complete
newcomer.
But hey, whatever floats your boat :)
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.
--Dan
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-06 2:52 UTC (permalink / raw)
To: dberlin; +Cc: ismail, gcc, git
In-Reply-To: <4aca3dc20712051841o71ab773ft6dd0714ebc355dd5@mail.gmail.com>
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. 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.
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.
^ permalink raw reply
* Re: * [BUG] "git clean" does not pay attention to its parameters
From: Jeff King @ 2007-12-06 3:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Shawn Bohrer, git
In-Reply-To: <7veje1zibm.fsf@gitster.siamese.dyndns.org>
On Tue, Dec 04, 2007 at 11:55:41PM -0800, Junio C Hamano wrote:
> [PATCH] git-clean: Honor pathspec.
>
> git-clean "*.rej" should attempt to look at only paths that match
> pattern "*.rej", but rewrite to C broke it.
And here is a test that fails without your patch (probably the commit
message should say "fixed in XX" once the commit id is known, or it
should be squashed in with your patch).
-- >8 --
t7300: add test for clean with wildcard pathspec
Signed-off-by: Jeff King <peff@peff.net>
---
t/t7300-clean.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index f013c17..dfd1188 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -126,6 +126,20 @@ test_expect_success 'git-clean symbolic link' '
'
+test_expect_success 'git-clean with wildcard' '
+
+ touch a.clean b.clean other.c &&
+ git-clean "*.clean" &&
+ test -f Makefile &&
+ test -f README &&
+ test -f src/part1.c &&
+ test -f src/part2.c &&
+ test ! -f a.clean &&
+ test ! -f b.clean &&
+ test -f other.c
+
+'
+
test_expect_success 'git-clean -n' '
mkdir -p build docs &&
--
1.5.3.7.2099.gd6d7-dirty
^ permalink raw reply related
* 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
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