* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-13 0:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com>
Hi,
Jakub, thank you very much for doing this. It is a very tedious work, and
I deem it invaluable.
On Sat, 13 Oct 2007, Jakub Narebski wrote:
> * IRC is blocked from work :-( I may try it by tunneling out.
>
> (Any suggestions here?)
I had the same problem, and somebody pointed me to
http://ircatwork.com/cgi-bin/irc/irc.cgi
(But please be nice, or else it will be shut down...)
> * Keep up the UI simplification and make sure the docs start off with
> usage somewhat similar to CVS/SVN. I think many users are scared by
> Git because they see the more powerful commands thrown around too
> early and get scared.
>
> Git is just too complicated for a typical project. I understand
> it's probably great for the Linux kernel but for a smaller project
> like mine (Mesa) it's overkill and a frustration. (...) With git
> everything seems hard. (...) I've _wasted_ hours trying to figure
> out git. That alone is a huge issue. I guess I could go into
> specific details about my problems with git but I've already spent
> enough time on this survey.
I find it always a little strange how people want to use something like
git, but are unwilling to ask. Is this such a big attack on the manliness
to admist one needs help or what?
> Figure out why people find git hard to learn and eliminate those
> barriers to entry. Make git more task-oriented rather than
> data-model-oriented the way it is now.
Frankly, expectations like these make me want to bang somebody's head on
the wall. Why do people expect others to work for them for free? Hard?
> (...) I'm evaluating Mercurial despite its being based on Python
> because it feels cleaner and simpler to use. I would prefer to use
> Git.
You cannot do much about feelings, not with technical means, you can't.
> * No one-pager cheat sheet with the 6 most basic commands on it so
> people can go use git.
>
> (This got corrected. There is git cheat sheet on the Internet;
> there is link on GitWiki to it)
I think it'd be a good idea to put it on git://git.kernel.org/, linked
right before the links to the man pages. Who has permissions to change
that page?
> I'd like to just stress support for windows and central
> repositories. (...) In fact most of my friends really wanted to use
> git but they wanted a solid native port.
If you read what I wrote above, you know exactly what I want to do here.
> * Get a mascot perhaps O'Reilly animal for O'Reilly GitBook
> (Git User's Manual) like the svnbook.
>
> (What animal could Git use for O'Reilly? Herd of horses, or a
> pony?)
OMG Ponies!
Seriously again, is the cheetah taken already?
Speaking of cheetah: there is a project called git-cheetah, its goal being
to provide a TortoiseCVS lookalike for git.
Just wanted to mention it, in case people want it, and are not too shy to
participate in making it closer to the goal.
> * I'm wondering what the overall goal is - git's origin as a neutral
> ground was fine but it hasn't seemed to take off as a viable
> alternative for general use. Do you care about that? Is it ok
> that git is it's own little niche?
>
> (Junio, Linus?)
I am neither, but FWIW I did not have the impression that it is in its own
little niche.
At the GSoC mentor summit, I encountered a rather different stance: people
did not _know_ what distributed SCM means, and were rather afraid of the
concept. Some of them seemed to fight changing their known procedures
tooth and nail. Which is fine by me (I don't have to force anybody to
use git, thankyouverymuch).
A word about the GitFAQ... there was one suggestion that there should be a
FAQ maintainer.
I really have to ask myself why not more people just edit the GitFAQ on
the wiki. I mean, that is the whole purpose of it being on the wiki.
It's not hard either.
Less hard in any case than to find a volunteer for a FAQ maintainer -- I
mean, if most are too busy/lazy/shy to edit the FAQ at all, how do they
expect somebody else to step up?
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: J. Bruce Fields @ 2007-10-13 2:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710130130380.25221@racer.site>
On Sat, Oct 13, 2007 at 01:46:40AM +0100, Johannes Schindelin wrote:
> On Sat, 13 Oct 2007, Jakub Narebski wrote:
... (from survey response:)
> > Figure out why people find git hard to learn and eliminate those
> > barriers to entry. Make git more task-oriented rather than
> > data-model-oriented the way it is now.
>
> Frankly, expectations like these make me want to bang somebody's head on
> the wall. Why do people expect others to work for them for free? Hard?
Well, hey, we asked for suggestions. Think of it as a project someone
might want to work on, rather than as a command.
I don't know what they mean by "make git more task-oriented rather than
data-model-oriented", but the first suggestion ("Find out why people
find git hard to learn...") is certainly something I'd enjoy working on
if I found the time.
--b.
^ permalink raw reply
* Re: Imports without Tariffs
From: Jeff King @ 2007-10-13 2:49 UTC (permalink / raw)
To: mfwitten; +Cc: git
In-Reply-To: <1C0D32ED-59F7-43D4-88B1-D7A9E754D639@mit.edu>
On Fri, Oct 12, 2007 at 04:36:29PM -0400, mfwitten@MIT.EDU wrote:
> (4) Update my git working tree from CVS (at some later time).
>
> => cd ../work
> => git cvsimport -a -k -v -r cvs -C . module
>
> [PROBLEM]
>
> git-cvsimport creates new hash IDs for the same ol' commits.
>
> [...]
> Therefore, when the updated 'cvs' remote branches are merged into
> my local branches, git treats the commits I made with cvsexportcommit
> as separate history; thus, history is duplicated and merge commits
> appear where they shouldn't.
You are presumably doing a 'git-pull' on the cvsimport-ed commits. Try
doing a git-rebase, which will filter out commits which make the same
changes. Yes, it means throwing away your original commits, but the new
ones should be morally equivalent (and are now the "official" upstream
of the CVS repository).
-Peff
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Shawn O. Pearce @ 2007-10-13 2:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710130130380.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sat, 13 Oct 2007, Jakub Narebski wrote:
> > * I'm wondering what the overall goal is - git's origin as a neutral
> > ground was fine but it hasn't seemed to take off as a viable
> > alternative for general use. Do you care about that? Is it ok
> > that git is it's own little niche?
> >
> > (Junio, Linus?)
>
> I am neither, but FWIW I did not have the impression that it is in its own
> little niche.
I'm neither too. But I don't think Git is in a niche. OK, well,
in the overall world of software development its certainly in the
niche of version control, as uh, it doesn't do Enterprise Resource
Planning and Large Scale Embezzlement of Monies (ERPaLSEM).
Actually I've seen a number of people on the interweb saying things
like they were switching their project to Git because they felt
it had more staying power than say Monotone or Mercurial, partly
because the kernel devs were actively using it, partly because the
file formats are so simple and sane, and partly because lots of
other projects are using it or are seriously considering it.
> At the GSoC mentor summit, I encountered a rather different stance: people
> did not _know_ what distributed SCM means, and were rather afraid of the
> concept. Some of them seemed to fight changing their known procedures
> tooth and nail. Which is fine by me (I don't have to force anybody to
> use git, thankyouverymuch).
Yes, this attitude *shocked the hell out of me*. I really did not
expect it. I nearly keeled over and died when I realized what the
folks in the back corner of the room were saying.
WINE uses Git. Some folks were outright pissed off that there
was only one committer in WINE. I think they felt the project
was maybe going to die because there was only one committer who
could apply patches. That may wind up being true (there's only so
far that one human can scale without trusted helpers for different
submodules of a large system) but its not Git's fault, or any other
DVCS's fault for that matter. At least its easy to fork WINE.
On the other hand active participants of two major organizations (KDE
and Eclipse) are starting to seriously look at Git. The interest
in Git is growing in both of those groups, which can only be good
for us. We'll learn more about how these groups do development,
and how we can best help them to accomplish more.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Shawn O. Pearce @ 2007-10-13 3:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <8fe92b430710121508g13917080mac156250abfccf20@mail.gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Other
> * SourceForge / Gna! / Google Projects support
> (free) hosting with git facilities
> FOSS hosting sites supporting git
We may find support for Git on SourceForge in the future, but not
on Google Projects anytime soon, if ever.
At the Google Summer of Code Mentor Summit last Saturday Dscho had a
short chat with someone from the Google Code group. Apparently they
did at least look at Git briefly but concluded that they cannot
implement it on their site as our backend storage database is just
plain files on the local filesystem.
One of the reasons (probably among many but whatever) that I think
Google hired the "SVN guys" as employees is to develop a Google
specific backend for SVN (replaces fsfs and bdb) that stores the
SVN revision data in a Google BigTable cell rather than on the
local filesystem. This allows Google to efficently manage the
entire site, including distributed replication, hot failover, etc...
BigTable is one of their key technologies at this point.
If you don't know about BigTable but want to know more you can
search for details about it via this awesome search engine I have
heard about: http://www.google.com/ :-)
I've managed to glean enough details on BigTable to know that the
Git backend is *not* easily layered on top of it. But the SVN
fsfs backend is actually fairly easy to translate into BigTable,
so I imagine it didn't take the "SVN guys" very long to develop
the new backend, test it, and thus deploy SVN onto Google Projects.
Funny aside: If you really want to know about BigTable apparently
you also need to visit (one of?) the men's room in building 43
on the second floor. There were tutorial posters hanging on the
wall describing how to use BigTable and Sawzall to summerize a
large dataset. Most pubs hang sports pages from the local paper;
Google hangs BigTable documentation. Nerds. All of 'em.
--
Shawn.
^ permalink raw reply
* Re: push fails with unexpected 'matches more than one'
From: Shawn O. Pearce @ 2007-10-13 3:21 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <91A04390-89B2-47B8-9B61-7C7E652670AE@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> I read carefully through the documentation of git-send-pack and
> git-rev-parse. The current implementation of git-send-pack is in line
> with the documented behaviour, as is the implementation of git-rev-
> parse.
>
> So formally everything is correct.
>
> But it is completely against my expectation that git-push <remote>
> <head>
> can successfully resolve a <head> that git-rev-parse fails to parse. I
> understand that refs are not revs ;). But nonetheless, I'd expect that a
> local ref that cannot be parsed by git-rev-parse should also fail to be
> pushed by git-send-pack. I didn't expect that git-send-pack would locate
> <head> as someprefix/<head>.
>
> Why is my expectation wrong?
> Or is the current specification of git-send-pack's ref parsing wrong?
I think its a bug. But I didn't write the original code.
Meaning I think what happened here was someone wanted to enable
git-send-pack to match "master" here with "refs/heads/master" on
the remote side. One easy way to do that was to see if any ref
ended with "/master", as that was what the ref here was called.
Way back when that code was written most Git repositories probably
only ever had that one branch anyway, or maybe two (refs/heads/master
and refs/heads/origin) so matching the trailing suffix never came
up as a bug. Nobody ever had two refs that could possibly match.
Then the documentation got expanded to actually document the behavior
that git-send-pack implemented. Unfortunately that codified the
bug as documented behavior.
So I agree with you Steffen, this is a bug in send-pack, and I run
up against it every once in a while. I've specifically told my
coworkers "NEVER, EVER, EVER, create a branch called 'master' that
isn't exactly refs/heads/master OR ELSE I WILL COME BEAT YOU WITH A
CLUE STICK". They still create "refs/heads/experiments/master".
*sigh*.
I think we should fix it. Anyone that is relying on "git push
$url master" to resolve to "refs/heads/experimental/master" on the
remote side is already playing with fire. But Junio is (rightfully
so) very conservative and doesn't like to break a user's scripts.
We may not be able to fix this until Git 1.6.
--
Shawn.
^ permalink raw reply
* Re: git-fast-import crashes
From: Shawn O. Pearce @ 2007-10-13 3:29 UTC (permalink / raw)
To: Shun Kei Leung; +Cc: git
In-Reply-To: <e66701d40710120242p6fc05148hd40d19d295373ac4@mail.gmail.com>
Shun Kei Leung <kevinlsk@gmail.com> wrote:
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x64617469
> in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
> 701 off_t win_off = win->offset;
...
> (gdb) print win
> $1 = (struct pack_window *) 0x5004d0
> (gdb) print *win
> $2 = {
> next = 0x64617461,
> base = 0x20333936 <Address 0x20333936 out of bounds>,
> offset = 22523564414626158,
> len = 1685026675,
> last_used = 795894075,
> inuse_cnt = 0
> }
Wow. There's no way that struct pack_window is valid anymore.
The base isn't a valid address. The offset cannot possibly be
correct (you don't have that big of a packfile, do you?!
What does `git count-objects -v` give you? I'm specifically
interested in how many packfiles you have. The other thing that
may be interesting to see is the value of pack_open_windows and
peak_pack_open_windows (file scope in sha1_file.c).
Then again, maybe that isn't interesting. This looks like it is
memory corruption (e.g. someone overwriting a free'd segment),
but that sort of memory corruption is very hard to track down.
--
Shawn.
^ permalink raw reply
* Re: git-fast-import crashes
From: Shawn O. Pearce @ 2007-10-13 3:34 UTC (permalink / raw)
To: Shun Kei Leung; +Cc: git
In-Reply-To: <20071013032916.GL27899@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Shun Kei Leung <kevinlsk@gmail.com> wrote:
> > I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4.
...
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > Reason: KERN_INVALID_ADDRESS at address: 0x64617469
...
> This looks like it is
> memory corruption (e.g. someone overwriting a free'd segment),
> but that sort of memory corruption is very hard to track down.
OK, so the version you have (58ba4) is the latest fast-import after
the strbuf.c series went in. The one immediately before that series
was 4bf538 and is probably actually stable.
So I wonder, can you test 4bf538 and then if it is good bisect
between those two commits? There must be a memory corruption
introduced by one of the strbuf changes...
--
Shawn.
^ permalink raw reply
* (unknown),
From: Michael Witten @ 2007-10-13 4:01 UTC (permalink / raw)
To: git; +Cc: Jeff King
I apologize if this is received twice.
I did add some comments, though!
On 12 Oct 2007, at 10:49:10 PM, Jeff King wrote:
> You are presumably doing a 'git-pull' on the cvsimport-ed commits. Try
> doing a git-rebase, which will filter out commits which make the same
> changes. Yes, it means throwing away your original commits, but the
> new
> ones should be morally equivalent (and are now the "official" upstream
> of the CVS repository).
Now that you mention it, I think the best approach would be to:
(1) cvsexportcommit
(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
(3) git cvsimport ..... # and merge
I think this is what you mean; it seems to me that rebasing isn't
quite that.
However, this will not preserve more complicated history such as merges
from another git repository.
Basically, I want to treat my git repository as the official
repository; the CVS
repo is just their for the old farts to get the latest stuff ;-P
Thanks!
Michael
PS
Please send me other opinions.
^ permalink raw reply
* Re: your mail
From: Jeff King @ 2007-10-13 4:07 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <30817A88-4313-4D38-95B0-FEC47C651CB0@mit.edu>
On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:
> Now that you mention it, I think the best approach would be to:
>
> (1) cvsexportcommit
> (2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
> (3) git cvsimport ..... # and merge
>
> I think this is what you mean; it seems to me that rebasing isn't quite
> that.
No, I mean rebasing instead of merge. As in, you have a history like
this:
/--C---D <-- your master
A--B
\--C'--D' <-- cvsimport merge tip
where "C" and "D" are your commits in git, and C' and D' are pulled in
from cvsimport. You want to rebase your work like this:
A--B--C'--D'--C--D
except that git-rebase is smart enough to realize that C == C' and skip
it (so it's a "safe" way of moving forward).
> However, this will not preserve more complicated history such as merges
> from another git repository.
Correct. Rebasing doesn't really handle merges, but I assumed you were
just making simple commits on top of a cvs master.
> Basically, I want to treat my git repository as the official
> repository; the CVS repo is just their for the old farts to get the
> latest stuff ;-P
Then my suggestion doesn't really work. You might consider using git as
the official server and letting the old farts use git-cvsserver.
HTH,
-Peff
^ permalink raw reply
* [PATCH] Color support added to git-add--interactive.
From: Dan Zwell @ 2007-10-13 4:13 UTC (permalink / raw)
To: Git Mailing List
Cc: Jeff King, Jonathan del Strother,
Johannes Schindelin <Johannes.Schindelin@gmx.de>Wincent Colaiuta
[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]
Recently there was some talk of color for git-add--interactive, but the
person who said he already had a patch didn't produce it.
-Reads configuration from git-config (using a new key,
color.add-interactive), respects "auto" if called from a script
-Uses the library Term::ANSIColor, which is included with modern
versions of perl.
There is one problem--a block is commented out, because adding the
"--color" option to git-diff-files somehow breaks git-add--interactive,
and I would love some help from someone who knows a little more about
the rest of the script than I do. Also, this is the first perl I have
written, and criticism is welcome. A gzipped patch is attached, in case
thunderbird mangles the tabs. Feel free to replace the colors that I
chose with something that better conforms to the "git style", if there
is such a thing.
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index be68814..f55d787 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,18 @@
use strict;
+my $use_color;
+my $color_config = qx(git config --get color.add-interactive);
+if ($color_config=~"true" || -t STDOUT && $color_config=~"auto") {
+ $use_color = "true";
+ require Term::ANSIColor;
+}
+sub print_ansi_color {
+ if ($use_color) {
+ print Term::ANSIColor::color($_[0]);
+ }
+}
+
sub run_cmd_pipe {
if ($^O eq 'MSWin32') {
my @invalid = grep {m/[":*]/} @_;
@@ -175,7 +187,9 @@ sub list_and_choose {
if (!$opts->{LIST_FLAT}) {
print " ";
}
+ print_ansi_color "bold";
print "$opts->{HEADER}\n";
+ print_ansi_color "clear";
}
for ($i = 0; $i < @stuff; $i++) {
my $chosen = $chosen[$i] ? '*' : ' ';
@@ -205,7 +219,9 @@ sub list_and_choose {
return if ($opts->{LIST_ONLY});
+ print_ansi_color "bold blue";
print $opts->{PROMPT};
+ print_ansi_color "reset";
if ($opts->{SINGLETON}) {
print "> ";
}
@@ -338,6 +354,16 @@ sub add_untracked_cmd {
sub parse_diff {
my ($path) = @_;
+ # FIXME: the following breaks git, and I'm not sure why. When
+ # the following is uncommented, git no longer asks whether we
+ # want to add given hunks.
+ #my @diff;
+ #if ($use_color) {
+ # #@diff = run_cmd_pipe(qw(git diff-files --color -p --), $path);
+ #}
+ #else {
+ # #@diff = run_cmd_pipe(qw(git diff-files -p --), $path);
+ #}
my @diff = run_cmd_pipe(qw(git diff-files -p --), $path);
my (@hunk) = { TEXT => [] };
@@ -544,6 +570,7 @@ sub coalesce_overlapping_hunks {
}
sub help_patch_cmd {
+ print_ansi_color "blue";
print <<\EOF ;
y - stage this hunk
n - do not stage this hunk
@@ -555,6 +582,7 @@ k - leave this hunk undecided, see previous
undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
EOF
+ print_ansi_color "clear";
}
sub patch_update_cmd {
@@ -619,7 +647,9 @@ sub patch_update_cmd {
for (@{$hunk[$ix]{TEXT}}) {
print;
}
+ print_ansi_color "bold";
print "Stage this hunk [y/n/a/d$other/?]? ";
+ print_ansi_color "reset";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
--
1.5.3.4.207.gc0ee
Dan Zwell
[-- Attachment #2: Color-add-interactive.patch.gz --]
[-- Type: application/gzip, Size: 1354 bytes --]
^ permalink raw reply related
* Re: Imports without Tariffs
From: Michael Witten @ 2007-10-13 4:39 UTC (permalink / raw)
To: git
In-Reply-To: <1240801C-F4CC-4290-8C3D-2038F1957DF3@MIT.EDU>
I apologize if you receive this twice.
I have now changed my email client to
use plain text by default.
On 13 Oct 2007, at 12:07:12 AM, Jeff King wrote:
> except that git-rebase is smart enough to realize that C == C' and
> skip
> it (so it's a "safe" way of moving forward).
This is good to know! The documentation should mention this case!
>> However, this will not preserve more complicated history such as
>> merges
>> from another git repository.
>
> Correct. Rebasing doesn't really handle merges, but I assumed you were
> just making simple commits on top of a cvs master.
Yes, you are quite correct. Your solution will work for me.
However, I think a general solution should be sought out.
Basically, the imported cvs history should be treated like
a remote that's being tracked. It seems like the solution
I proposed kind of does this and would work for other SCM
imports too.
>> Basically, I want to treat my git repository as the official
>> repository; the CVS repo is just their for the old farts to get the
>> latest stuff ;-P
>
> Then my suggestion doesn't really work. You might consider using
> git as
> the official server and letting the old farts use git-cvsserver.
Unfortunately, they are the ones running the servers; I have to do my
git work behind the scenes.
Thanks,
Michael
^ permalink raw reply
* Re: Imports without Tariffs
From: Michael Witten @ 2007-10-13 4:44 UTC (permalink / raw)
To: git
In-Reply-To: <3B7796D6-5901-40B0-B3FC-70642AC50B08@mit.edu>
On 12 Oct 2007, at 4:36:29 PM, mfwitten@MIT.EDU wrote:
> To make things simple, I think all of the necessary machinery
> should be put into git-cvsimport.
>
> The user should first git-cvsexportcommit as necessary.
Now that I have considered, it makes more sense to put the
machinery in git-cvsexportcommit.
The user could use a -b flag to specify the git branch to push
into after the cvs commit occurs, and git-cvsexportcommit would
update the .git/SCM_IMPORT file (changed from CVS_IMPORT).
Of course, this introduces other troubles.
Sometimes I run cvsexportcommit using a git repo on another server.
So perhaps one should also be able to use cvsexportcommit for just
pushing and editing the .git/SCM_IMPORT file.
That way it's possible to update CVS and then notify any other git
repo by hand.
Michael
^ permalink raw reply
* Re: git-fast-import crashes
From: Pierre Habouzit @ 2007-10-13 7:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Shun Kei Leung, git
In-Reply-To: <20071013033407.GM27899@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
On Sat, Oct 13, 2007 at 03:34:07AM +0000, Shawn O. Pearce wrote:
> "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > Shun Kei Leung <kevinlsk@gmail.com> wrote:
> > > I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4.
> ....
> > > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > > Reason: KERN_INVALID_ADDRESS at address: 0x64617469
> ....
> > This looks like it is
> > memory corruption (e.g. someone overwriting a free'd segment),
> > but that sort of memory corruption is very hard to track down.
>
> OK, so the version you have (58ba4) is the latest fast-import after
> the strbuf.c series went in. The one immediately before that series
> was 4bf538 and is probably actually stable.
>
> So I wonder, can you test 4bf538 and then if it is good bisect
> between those two commits? There must be a memory corruption
> introduced by one of the strbuf changes...
Gasp, if you get the offending sha1 commit, don't forget to Cc: me.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-fast-import crashes
From: Pierre Habouzit @ 2007-10-13 7:50 UTC (permalink / raw)
To: Shawn O. Pearce, Shun Kei Leung, git
In-Reply-To: <20071013073640.GC7110@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]
On sam, oct 13, 2007 at 07:36:40 +0000, Pierre Habouzit wrote:
> On Sat, Oct 13, 2007 at 03:34:07AM +0000, Shawn O. Pearce wrote:
> > "Shawn O. Pearce" <spearce@spearce.org> wrote:
> > > Shun Kei Leung <kevinlsk@gmail.com> wrote:
> > > > I am using git 1.5.3.4.206.g58ba4-dirty on Mac OS X 10.4.
> > ....
> > > > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > > > Reason: KERN_INVALID_ADDRESS at address: 0x64617469
> > ....
> > > This looks like it is
> > > memory corruption (e.g. someone overwriting a free'd segment),
> > > but that sort of memory corruption is very hard to track down.
> >
> > OK, so the version you have (58ba4) is the latest fast-import after
> > the strbuf.c series went in. The one immediately before that series
> > was 4bf538 and is probably actually stable.
> >
> > So I wonder, can you test 4bf538 and then if it is good bisect
> > between those two commits? There must be a memory corruption
> > introduced by one of the strbuf changes...
>
> Gasp, if you get the offending sha1 commit, don't forget to Cc: me.
Okay, given that fast-import uses quote_c_style, I believe this is the
same but that the one that was reported already. I've read the full
`git diff 4bf53833dbca666f61b5177977e96d453527db20.. -- fast-import.c`
and nothing alarming shows up.
Please try to apply:
http://git.madism.org/?p=git.git;a=commit;h=7406e83342cd445ac38c1753c5fce75377737e2f
And see if that fixes the issue for you. Else a bisection would be
much appreciated. Thanks.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Imports without Tariffs
From: Jeff King @ 2007-10-13 7:57 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <1240801C-F4CC-4290-8C3D-2038F1957DF3@MIT.EDU>
On Sat, Oct 13, 2007 at 12:30:09AM -0400, Michael Witten wrote:
>> except that git-rebase is smart enough to realize that C == C' and skip
>> it (so it's a "safe" way of moving forward).
>
> This is good to know! The documentation should mention this case!
Yes, it probably should. Can you submit a patch describing the behavior
where you think it ought to go?
> Basically, the imported cvs history should be treated like
> a remote that's being tracked. It seems like the solution
> I proposed kind of does this and would work for other SCM
> imports too.
I think it's an interesting avenue to pursue, though I would worry a
little about robustness. I like the fact that after rebasing, the
commits have done a complete git->cvs->git loop and look identical, so I
am sure everything made it through intact. But perhaps I'm just being
paranoid.
As an alternate idea, why not try to have the CVS commit contain all
information necessary to create a particular git commit. IOW, describe
all of the data that goes into the commit hash as textual comments in
the CVS commit (committer name/time, author name/time). And then
theoretically git-cvsimport can reconstruct the exact same commits
again, and your git->cvs->git merge really _will_ be a fastforward.
> Unfortunately, they are the ones running the servers; I have to do my
> git work behind the scenes.
I've been in the same boat, and just used the rebase trick I described.
Of course it was a very tiny project, so I didn't mind losing some of
the full power of git.
-Peff
^ permalink raw reply
* Re: [PATCH] Color support added to git-add--interactive.
From: Jeff King @ 2007-10-13 8:12 UTC (permalink / raw)
To: Dan Zwell
Cc: Git Mailing List, Jonathan del Strother,
Johannes Schindelin <Johannes.Schindelin@gmx.de>Wincent Colaiuta
In-Reply-To: <471045DA.5050902@gmail.com>
On Fri, Oct 12, 2007 at 11:13:14PM -0500, Dan Zwell wrote:
> Recently there was some talk of color for git-add--interactive, but the
> person who said he already had a patch didn't produce it.
Neat, thanks for working on this.
> There is one problem--a block is commented out, because adding the "--color"
> option to git-diff-files somehow breaks git-add--interactive, and I would
I believe it's because add--interactive parses the output of
git-diff-files, so it expects unadorned diffs. I think you may be stuck
re-coloring the diffs yourself, which is a little ugly.
> tabs. Feel free to replace the colors that I chose with something that
> better conforms to the "git style", if there is such a thing.
Two suggestions:
- every color should be configurable (e.g., see diff color options)
- where possible, use existing color config (e.g., for diffs)
You will never come up with a color scheme that satisfies everyone
(e.g., white text on black background versus black text on white
background), so configurability is a good idea (not to mention that
nobody will ever agree on what looks "good").
> +if ($color_config=~"true" || -t STDOUT && $color_config=~"auto") {
Shouldn't these just be 'eq' instead of a regex?
> + print_ansi_color "bold";
> print "$opts->{HEADER}\n";
> + print_ansi_color "clear";
ISTR some terminals had issues with leaving ANSI attributes set across a
newline. That was the reason for the color_fprintf_ln business in
color.[ch]. You might replace this with something like:
print_color_ln 'bold', $opts->{HEADER};
where "print_color_ln" turns off the attribute before the newline.
> + # FIXME: the following breaks git, and I'm not sure why. When
> + # the following is uncommented, git no longer asks whether we
> + # want to add given hunks.
> + #my @diff;
> + #if ($use_color) {
> + # #@diff = run_cmd_pipe(qw(git diff-files --color -p --), $path);
> + #}
> + #else {
> + # #@diff = run_cmd_pipe(qw(git diff-files -p --), $path);
> + #}
> my @diff = run_cmd_pipe(qw(git diff-files -p --), $path);
See how we are pulling the diff into lines? Look a few lines below and
you will see that we start parsing without regard to the color.
Unfortunately, that parsed form ends up being output to the user, so we
will have to do colorization at that point (fortunately, diff
colorization with regexes isn't _that_ hard).
> + print_ansi_color "blue";
> print <<\EOF ;
> y - stage this hunk
> n - do not stage this hunk
> @@ -555,6 +582,7 @@ k - leave this hunk undecided, see previous undecided
> hunk
> K - leave this hunk undecided, see previous hunk
> s - split the current hunk into smaller hunks
> EOF
> + print_ansi_color "clear";
Hrm, splitting this with print_color_ln as I mentioned above would be a
little painful. Maybe something like this (totally untested):
# Turn on ansi attributes at the beginning of the string and at
# the beginning of each line, but then turn them off before each
# newline. This should give the effect of covering the whole string
# with the attribute, but not have attributes cross newline boundaries.
sub color_print {
my $attr = shift;
local $_ = shift;
if ($use_color) {
s/^/Term::ANSIColor::color($attr)/mge;
s/\n/Term::ANSIColor::color('reset') . $&/ge;
}
print $_;
}
-Peff
^ permalink raw reply
* Re: [PATCH] Color support added to git-add--interactive.
From: Johannes Schindelin @ 2007-10-13 12:25 UTC (permalink / raw)
To: Dan Zwell
Cc: Git Mailing List, Jeff King, Wincent Colaiuta,
Jonathan del Strother
In-Reply-To: <471045DA.5050902@gmail.com>
Hi,
[Cc'ed Wincent correctly]
On Fri, 12 Oct 2007, Dan Zwell wrote:
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index be68814..f55d787 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -2,6 +2,18 @@
>
> use strict;
>
> +my $use_color;
> +my $color_config = qx(git config --get color.add-interactive);
> +if ($color_config=~"true" || -t STDOUT && $color_config=~"auto") {
> + $use_color = "true";
> + require Term::ANSIColor;
> +}
Good. If you do not have color enabled, it does not require that package
that is only default with modern Perl.
> @@ -175,7 +187,9 @@ sub list_and_choose {
> if (!$opts->{LIST_FLAT}) {
> print " ";
> }
> + print_ansi_color "bold";
> print "$opts->{HEADER}\n";
> + print_ansi_color "clear";
Here you say "clear", and ...
> }
> for ($i = 0; $i < @stuff; $i++) {
> my $chosen = $chosen[$i] ? '*' : ' ';
> @@ -205,7 +219,9 @@ sub list_and_choose {
>
> return if ($opts->{LIST_ONLY});
>
> + print_ansi_color "bold blue";
> print $opts->{PROMPT};
> + print_ansi_color "reset";
here you say "reset". Is it because of the added colour?
> @@ -338,6 +354,16 @@ sub add_untracked_cmd {
>
> sub parse_diff {
> my ($path) = @_;
> + # FIXME: the following breaks git, and I'm not sure why. When
> + # the following is uncommented, git no longer asks whether we
> + # want to add given hunks.
> + #my @diff;
> + #if ($use_color) {
> + # #@diff = run_cmd_pipe(qw(git diff-files --color -p --), $path);
> + #}
> + #else {
> + # #@diff = run_cmd_pipe(qw(git diff-files -p --), $path);
> + #}
> my @diff = run_cmd_pipe(qw(git diff-files -p --), $path);
> my (@hunk) = { TEXT => [] };
This fails because of the next two lines:
for (@diff) {
if (/^@@ /) {
Replace the if with "if (/^[^-+ ]*@@ /)", or something even stricter.
--color adds magic sequences to make color.
I cannot comment on the Perl style ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Color support added to git-add--interactive.
From: Frank Lichtenheld @ 2007-10-13 12:49 UTC (permalink / raw)
To: Jeff King
Cc: Dan Zwell, Git Mailing List, Jonathan del Strother,
Johannes Schindelin, Wincent Colaiuta
In-Reply-To: <20071013081205.GB27533@coredump.intra.peff.net>
On Sat, Oct 13, 2007 at 04:12:06AM -0400, Jeff King wrote:
> > +if ($color_config=~"true" || -t STDOUT && $color_config=~"auto") {
>
> Shouldn't these just be 'eq' instead of a regex?
What would mean you have to chomp it first. But it should at least
be written as =~ /.../ to make it clear that using a regex was a
concious decision here and not an accident.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: git-fast-import crashes
From: Johannes Schindelin @ 2007-10-13 12:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Shun Kei Leung, git
In-Reply-To: <20071013032916.GL27899@spearce.org>
Hi,
On Fri, 12 Oct 2007, Shawn O. Pearce wrote:
> Shun Kei Leung <kevinlsk@gmail.com> wrote:
> > Program received signal EXC_BAD_ACCESS, Could not access memory.
> > Reason: KERN_INVALID_ADDRESS at address: 0x64617469
> > in_window (win=0x5004d0, offset=3501) at sha1_file.c:701
> > 701 off_t win_off = win->offset;
> ...
> > (gdb) print win
> > $1 = (struct pack_window *) 0x5004d0
> > (gdb) print *win
> > $2 = {
> > next = 0x64617461,
> > base = 0x20333936 <Address 0x20333936 out of bounds>,
> > offset = 22523564414626158,
> > len = 1685026675,
> > last_used = 795894075,
> > inuse_cnt = 0
> > }
>
> Wow. There's no way that struct pack_window is valid anymore.
>
> [...]
>
> This looks like it is memory corruption (e.g. someone overwriting a
> free'd segment), but that sort of memory corruption is very hard to
> track down.
I found valgrind invaluable to find such errors.
Ciao,
Dscho
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Frank Lichtenheld @ 2007-10-13 12:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0710130130380.25221@racer.site>
On Sat, Oct 13, 2007 at 01:46:40AM +0100, Johannes Schindelin wrote:
> On Sat, 13 Oct 2007, Jakub Narebski wrote:
> > Figure out why people find git hard to learn and eliminate those
> > barriers to entry. Make git more task-oriented rather than
> > data-model-oriented the way it is now.
>
> Frankly, expectations like these make me want to bang somebody's head on
> the wall. Why do people expect others to work for them for free? Hard?
It's called "User". And since this is the Git _User's_ Survey, I guess
you will have to live with that. And anyway, where in the above you find
something about "expectation" rather than "suggestion"?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-13 13:04 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Jakub Narebski, git
In-Reply-To: <20071013125845.GA31659@planck.djpig.de>
Hi,
On Sat, 13 Oct 2007, Frank Lichtenheld wrote:
> On Sat, Oct 13, 2007 at 01:46:40AM +0100, Johannes Schindelin wrote:
> > On Sat, 13 Oct 2007, Jakub Narebski wrote:
> > > Figure out why people find git hard to learn and eliminate those
> > > barriers to entry. Make git more task-oriented rather than
> > > data-model-oriented the way it is now.
> >
> > Frankly, expectations like these make me want to bang somebody's head
> > on the wall. Why do people expect others to work for them for free?
> > Hard?
>
> It's called "User". And since this is the Git _User's_ Survey, I guess
> you will have to live with that. And anyway, where in the above you find
> something about "expectation" rather than "suggestion"?
"Figure out" sounds to me like an imperative.
But my real point is: these guys know exactly what they find hard in git.
Why don't they just come and tell us?
Just like Carl Worth did, way back when. And it worked, didn't it? Git
1.5 is vastly more user friendly than pre 1.5.
Ciao,
Dscho
^ permalink raw reply
* [RFC] CLI option parsing and usage generation for porcelains
From: Pierre Habouzit @ 2007-10-13 13:29 UTC (permalink / raw)
To: git
Following Kristian momentum, I've reworked his parse_option module
quite a lot, and now have some quite interesting features. The series is
available from git://git.madism.org/git.git (branch ph/strbuf).
The following series is open for comments, it's not 100% ready for
inclusion IMHO, as some details may need to be sorted out first, and
that I've not re-read the patches thoroughly yet. Though I uses the tip
of that branch as my everyday git for 2 weeks or so without any
noticeable issues.
And as examples are always easier to grok:
$ git fetch -h
usage: git-fetch [options] [<repository> <refspec>...]
-q, --quiet be quiet
-v, --verbose be verbose
-a, --append append in .git/FETCH_HEAD
-f, --force force non fast-forwards updates
--no-tags don't follow tags at all
-t, --tags fetch all tags
--depth <depth> deepen history of a shallow clone
Advanced Options
-k, --keep keep downloaded pack
-u, --update-head-ok allow to update the head in the current branch
--upload-pack <path> path to git-upload-pack on the remote
$ git rm -rf xdiff # yeah -rf now works !
rm 'xdiff/xdiff.h'
rm 'xdiff/xdiffi.c'
rm 'xdiff/xdiffi.h'
rm 'xdiff/xemit.c'
rm 'xdiff/xemit.h'
rm 'xdiff/xinclude.h'
rm 'xdiff/xmacros.h'
rm 'xdiff/xmerge.c'
rm 'xdiff/xprepare.c'
rm 'xdiff/xprepare.h'
rm 'xdiff/xtypes.h'
rm 'xdiff/xutils.c'
rm 'xdiff/xutils.h'
^ permalink raw reply
* [bug] gitk can not read history if diff color is enabled
From: Mike Sharov @ 2007-10-13 14:18 UTC (permalink / raw)
To: git
Reproduced in git version 1.5.3.4.217.gbfc1, although it's been this way
for a while. To see the bug, enable color diff with
[diff]
color
and launch gitk on any repository (like the Linux kernel tree). The
result is a dialog box "Can't parse git log output '\x1b[33mcommit" etc.
qgit can still view the history without errors, so I guess it must be
possible to somehow turn off color for a specific query.
--
Mike
msharov@users.sourceforge.net
^ permalink raw reply
* Re: [PATCH] Add a simple option parser.
From: Johannes Schindelin @ 2007-10-13 14:39 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Junio C Hamano
In-Reply-To: <1192282153-26684-2-git-send-email-madcoder@debian.org>
Hi,
On Sat, 13 Oct 2007, Pierre Habouzit wrote:
> Aggregation of single switches is allowed:
> -rC0 is the same as -r -C 0 (supposing that -C wants an arg).
I'd be more interested in "-rC 0" working... Is that supported, too?
> diff --git a/parse-options.c b/parse-options.c
> new file mode 100644
> index 0000000..07abb50
> --- /dev/null
> +++ b/parse-options.c
> @@ -0,0 +1,227 @@
> +#include "git-compat-util.h"
> +#include "parse-options.h"
> +#include "strbuf.h"
> +
> +#define OPT_SHORT 1
> +#define OPT_UNSET 2
> +
> +struct optparse_t {
> + const char **argv;
> + int argc;
> + const char *opt;
> +};
> +
> +static inline const char *get_arg(struct optparse_t *p)
> +{
> + if (p->opt) {
> + const char *res = p->opt;
> + p->opt = NULL;
> + return res;
> + }
> + p->argc--;
> + return *++p->argv;
> +}
This is only used once; I wonder if it is really that more readable having
this as a function in its own right.
> +static inline const char *skippfx(const char *str, const char *prefix)
Personally, I do not like abbreviations like that. They do not save that
much screen estate (skip_prefix is only 4 characters longer, but much more
readable). Same goes for "cnt" later.
> +static int get_value(struct optparse_t *p, struct option *opt, int flags)
> +{
> + if (p->opt && (flags & OPT_UNSET))
> + return opterror(opt, "takes no value", flags);
> +
> + switch (opt->type) {
> + case OPTION_BOOLEAN:
> + if (!(flags & OPT_SHORT) && p->opt)
> + return opterror(opt, "takes no value", flags);
> + if (flags & OPT_UNSET) {
> + *(int *)opt->value = 0;
> + } else {
> + (*(int *)opt->value)++;
> + }
> + return 0;
> +
> + case OPTION_STRING:
> + if (flags & OPT_UNSET) {
> + *(const char **)opt->value = (const char *)NULL;
> + } else {
> + if (!p->opt && p->argc < 1)
> + return opterror(opt, "requires a value", flags);
> + *(const char **)opt->value = get_arg(p);
> + }
> + return 0;
> +
> + case OPTION_INTEGER:
> + if (flags & OPT_UNSET) {
> + *(int *)opt->value = 0;
> + } else {
> + const char *s;
> + if (!p->opt && p->argc < 1)
> + return opterror(opt, "requires a value", flags);
> + *(int *)opt->value = strtol(*p->argv, (char **)&s, 10);
> + if (*s)
> + return opterror(opt, "expects a numerical value", flags);
> + }
> + return 0;
> +
> + default:
> + die("should not happen, someone must be hit on the forehead");
:-P
> +static int parse_long_opt(struct optparse_t *p, const char *arg,
> + struct option *options, int count)
> +{
> + int i;
> +
> + for (i = 0; i < count; i++) {
> + const char *rest;
> + int flags = 0;
> +
> + if (!options[i].long_name)
> + continue;
> +
> + rest = skippfx(arg, options[i].long_name);
> + if (!rest && !strncmp(arg, "no-", 3)) {
> + rest = skippfx(arg + 3, options[i].long_name);
> + flags |= OPT_SHORT;
> + }
Would this not be more intuitive as
if (!prefixcmp(arg, "no-")) {
arg += 3;
flags |= OPT_UNSET;
}
rest = skip_prefix(arg, options[i].long_name);
Hm? (Note that I say UNSET, not SHORT... ;-)
> + if (!rest)
> + continue;
> + if (*rest) {
> + if (*rest != '=')
> + continue;
Is this really no error? For example, "git log
--decorate-walls-and-roofs" would not fail...
> +int parse_options(int argc, const char **argv,
> + struct option *options, int count,
> + const char * const usagestr[], int flags)
Please indent by the same amount.
> + if (arg[1] != '-') {
> + optp.opt = arg + 1;
> + do {
> + if (*optp.opt == 'h')
> + make_usage(usagestr, options, count);
How about calling this "usage_with_options()"? With that name I expected
make_usage() to return a strbuf.
> + if (!arg[2]) { /* "--" */
> + if (!(flags & OPT_COPY_DASHDASH))
> + optp.argc--, optp.argv++;
I would prefer this as
if (!(flags & OPT_COPY_DASHDASH)) {
optp.argc--;
optp.argv++;
}
While I'm at it: could you use "args" instead of "optp"? It is misleading
both in that it not only contains options (but other arguments, too) as in
that it is not a pointer (the trailing "p" is used as an indicator of that
very often, including git's source code).
In the same vein, OPT_COPY_DASHDASH should be named
PARSE_OPT_KEEP_DASHDASH.
> + if (opts->short_name) {
> + strbuf_addf(&sb, "-%c", opts->short_name);
> + }
> + if (opts->long_name) {
> + strbuf_addf(&sb, opts->short_name ? ", --%s" : "--%s",
> + opts->long_name);
> + }
Please lose the curly brackets.
> + if (sb.len - pos <= USAGE_OPTS_WIDTH) {
> + int pad = USAGE_OPTS_WIDTH - (sb.len - pos) + USAGE_GAP;
> + strbuf_addf(&sb, "%*s%s\n", pad, "", opts->help);
> + } else {
> + strbuf_addf(&sb, "\n%*s%s\n", USAGE_OPTS_WIDTH + USAGE_GAP, "",
> + opts->help);
> + }
Same here. (And I'd also make sure that the lines are not that long.)
> diff --git a/parse-options.h b/parse-options.h
> new file mode 100644
> index 0000000..4b33d17
> --- /dev/null
> +++ b/parse-options.h
> @@ -0,0 +1,37 @@
> +#ifndef PARSE_OPTIONS_H
> +#define PARSE_OPTIONS_H
> +
> +enum option_type {
> + OPTION_BOOLEAN,
I know that I proposed "BOOLEAN", but actually, you use it more like an
"INCREMENTAL", right?
Other than that: I like it very much.
Ciao,
Dscho
^ 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