* Re: problem using jgit
From: Marek Zawirski @ 2008-07-22 11:51 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git, Robin Rosenberg, Shawn O. Pearce
In-Reply-To: <p0624080dc4aa78c93ffe@[192.168.1.106]>
Stephen Bannasch wrote:
> At 2:35 PM +0200 7/21/08, Marek Zawirski wrote:
>
>> Marek Zawirski wrote:
>>
>>> Stephen Bannasch wrote:
>>>
>>>> I've setup a simple test class that integrates jgit to clone a git repository. However I'm getting a NullPointerError when RevWalk.parseAny ends up producing a null object id.
>>>>
>>>> The code and the stack trace for the error are here:
>>>>
>>>> http://pastie.org/237711
>>>>
>>>> This problem occurs using the jgit from the master branch from this repo:
>>>>
>>>> git://repo.or.cz/egit.git
>>>>
>>> Hello Stephen,
>>>
>>> I think you've experienced error caused by the same bug as me, during my latest fetch/push GUI works few days ago.
>>> Your code looks fine, probably it's actually bug in jgit. I think it's some regression. Thanks for reporting.
>>>
>> It's caused by 14a630c3: Cached modification times for symbolic refs too
>> Changes introduced by this patch made Repository#getAllRefs() including Ref objects with null ObjectId in case of unresolvable (invalid?) HEAD symbolic ref, and null Ref for HEAD when it doesn't exist. Previous behavior was just not including such refs in result.
>>
>> Fix for null Ref is just a matter of simple filtering out null Ref object for HEAD, if it doesn't exist (just is it considered to be legal state of repository when HEAD doesn't exist?).
>>
>> To fix null ObjectId issue, we have to either change all clients of this method or revert method to previous behavior. Now it's just unspecified in javadoc.
>> Robin, Shawn, what do you think? If we want to have unresolvable refs included, IMO it may be sensible to provide argument includeUnresolbable for Repository#getAllRefs() to let clients avoid burden of filtering them out when they don't need them (most cases, perhaps).
>> I can prepare fix for it (rather easy one) as you are unavailable now, let me now what's your opinion.
>>
>
> Thanks for looking at this problem Marek.
>
> If you get a change working for jgit that might not be available in a branch on git://repo.or.cz/egit.gi will you send a patch.
>
> I am looking forward to continuing my tests using jgit from Java and JRuby.
>
You can find temporary workaround for that in "workaround" branch at
git://repo.or.cz/egit/zawir.git
It's rather not a final solution (disables unresolvable HEADs), but I
hope it let you continue using jgit for a while, as it does for me ;)
^ permalink raw reply
* Re: Git Documentation
From: Johannes Schindelin @ 2008-07-22 11:40 UTC (permalink / raw)
To: Johan Herland; +Cc: david, Scott Chacon, git
In-Reply-To: <200807221121.22520.johan@herland.net>
Hi,
On Tue, 22 Jul 2008, Johan Herland wrote:
> Many Git users will not be VCS geeks like us; they will be "regular"
> people that use Git because it's useful for them (or because they're
> forced to use Git at $dayjob).
Exactly. But it seems a concept hard to understand to some people. It
also seems that VCS geeks like scripting, and assume everybody else does,
too. Not so.
Most people hate to know the internals. They buy the car, and never want
to look inside the motor compartment. They buy wine, and never want to
know how it is made. They buy an iPod and never want to know who
assembles it, and how, and in what environment.
You cannot teach those people to be more interested/interesting by showing
them how things work internally. But you can give Git a bad reputation in
the process.
This, amongst other reasons, was why a company I worked at had a policy to
never _ever_ have presentations or tutorials by technical staff. Never.
Ciao,
Dscho
^ permalink raw reply
* Re: git status in clean working dir
From: Johannes Schindelin @ 2008-07-22 11:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, David Bremner
In-Reply-To: <20080722045223.GC20787@sigill.intra.peff.net>
Hi,
On Tue, 22 Jul 2008, Jeff King wrote:
> On Tue, Jul 22, 2008 at 12:44:00AM -0400, Jeff King wrote:
>
> > We could also swap the parent/child relationship, and have the pager
> > as child. But I assume that it is done the way we have it because
> > otherwise the shell gets confused about when the command ends (i.e.,
> > we want it to run until pager completion). I didn't test, though.
>
> Hmm, it looks like the MINGW32 codepath already _does_ spawn in that
> order, but has a "wait_for_child" atexit handler. I wonder if there is a
> reason all platforms can't use that trick (though the mingw approach
> uses run_command, which makes it harder to do the "wait for input before
> starting less" trick).
I recently suggested exactly that already, to catch SIGSEGVs in the paged
process, amongst other things.
Ciao,
Dscho
^ permalink raw reply
* Re: How to find the first commit belonging to any branch
From: Kristian Amlie @ 2008-07-22 11:18 UTC (permalink / raw)
To: git
In-Reply-To: <7vej5mmfp9.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Kristian Amlie <kristian.amlie@trolltech.com> writes:
>
>> I have a question about git: I have one commit sha1, and I would like
>> to know the nearest commit that appears in *any* other branch. The
>> sha1 that I have does not belong to any branch.
>>
>> The obvious thing to do would be to make a for loop and iterate over
>> existing branches while calling git merge-base, but I'm wondering if
>> there's a more clever method.
>
> If the $commit does not belong to any branch, then:
>
> $ git rev-list --bounardy $commit^0 --not --branches | sed -ne 's/^-//p'
>
> would give you boundary commits of the above traversal, which says:
>
> Traverse from $commit following the parents, but stop at anything that
> is reachable from any breanch.
>
> which means that the ones that are output are the candidates that are on
> some branch.
>
> So pipe that to name-rev like this, perhaps (untested)?
>
> $ git rev-list --bounardy $commit^0 --not --branches |
> sed -ne 's/^-//p' |
> git name-rev --stdin
>
>
Thanks! That did the trick!
Kristian
^ permalink raw reply
* Re: [PATCH for master] Rename path_list to string_list
From: Johannes Schindelin @ 2008-07-22 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3am2sldy.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, 21 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > @@ -64,9 +65,10 @@ Functions
> >
> > `string_list_clear`::
> >
> > - Free a string_list. The `path` pointer of the items will be freed in case
> > - the `strdup_strings` member of the string_list is set. The second parameter
> > - controls if the `util` pointer of the items should be freed or not.
> > + Free a string_list. The `path` pointer of the items will be freed in
> > + case the `strdup_strings` member of the string_list is set. The second
> > + parameter controls if the `util` pointer of the items should be freed
> > + or not.
>
> Missed 's/path/string/' here?
Good catch. I clearly forgot to grep for "path" in all the files that I
touched. I did that now, but only looked at comments (in the hope that
the compiler would have caught the other ones).
-- snipsnap --
[PATCH] Fix two leftovers from path_list->string_list
In the documentation, where you cannot get compile errors for using the
wrong member name, there were two mentions of 'path' left.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/technical/api-string-list.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/api-string-list.txt b/Documentation/technical/api-string-list.txt
index 92b3ecd..293bb15 100644
--- a/Documentation/technical/api-string-list.txt
+++ b/Documentation/technical/api-string-list.txt
@@ -41,7 +41,7 @@ memset(&list, 0, sizeof(struct string_list));
string_list_append("foo", &list);
string_list_append("bar", &list);
for (i = 0; i < list.nr; i++)
- printf("%s\n", list.items[i].path)
+ printf("%s\n", list.items[i].string)
----
NOTE: It is more efficient to build an unsorted list and sort it
@@ -113,7 +113,7 @@ Data structures
* `struct string_list_item`
-Represents an item of the list. The `path` member is a pointer to the
+Represents an item of the list. The `string` member is a pointer to the
string, and you may use the `util` member for any purpose, if you want.
* `struct string_list`
--
1.5.6.2.516.g22071
^ permalink raw reply related
* Re: post-receive-hook emailer
From: Abhijit Menon-Sen @ 2008-07-22 10:40 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <00AEED4D-BD34-4584-B303-32C5F587EF0F@develooper.com>
Hi Ask.
At 2008-07-22 02:34:35 -0700, ask@develooper.com wrote:
>
> Anyway - anyone have a mailer that sends diffs and such? :-)
Not quite what you want, but I wrote the attached post-receive hook/hack
to send change notifications by Jabber. "hooks.notify.recipients" should
contain a list of jabber IDs; and you can change the "git log" line, for
example by adding "-p --stat" or something, to change what gets sent.
It should be trivial to change the last twenty-odd lines to send email
instead.
-- ams
#!/usr/bin/perl
# Abhijit Menon-Sen <ams@oryx.com>
use Net::Jabber;
my $dir;
chomp( $dir = qx(git rev-parse --git-dir 2>/dev/null) );
die "GIT_DIR not defined.\n" unless $dir;
$ENV{GIT_DIR} = $dir;
my $r;
chomp( $r = qx(git config hooks.notify.recipients) );
my @recipients = split /,\s*/, $r;
my @changes;
while ( <> ) {
chomp;
my ( $old, $new, $ref ) = split / /;
$ref =~ s!refs/heads/!!;
next unless $ref eq "some/branch";
my $s = qx(git log --no-merges --reverse --find-copies-harder --raw -r $old..$new);
$s =~ s/^:.*?\t/\t/gsm;
push @changes, $s;
}
exit unless @changes;
exit unless @recipients;
my $client = new Net::Jabber::Client ();
$client->Connect(
hostname => 'example.com',
) or die "Cannot connect to jabber server: $!.\n";
my @r = $client->AuthSend(
username => 'git',
password => 'some-password',
resource => 'git'
);
die "Cannot authenticate (@r).\n" if $r[0] ne "ok";
foreach my $c (@changes) {
for my $r (@recipients) {
my $msg = new Net::Jabber::Message ();
$msg->SetMessage(
to => $r,
subject => 'Changes pushed to x:y.git/some/branch',
body => $c
);
$client->Send( $msg );
}
}
$client->Disconnect();
^ permalink raw reply
* Re: [PATCH] mailinfo: better parse email adresses containg parentheses
From: Philippe Bruhat (BooK) @ 2008-07-22 10:24 UTC (permalink / raw)
To: git
In-Reply-To: <7v63qyr4kk.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 21, 2008 at 08:16:43PM -0700, Junio C Hamano wrote:
> >
> > Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
>
> Hmm, tests?
>
> By the way, that second form parses like this:
>
> mailbox =
> name-addr =
> display-name angle-addr = "User Name (me) <user@host>"
>
> display-name =
> phrase = "User Name"
>
> angle-addr = CFWS "<" addr-spec ">" = "(me) <user@host>"
>
> So strictly speaking, shouldn't we be stripping the whole (me) as garbage?
> It is not even part of the display-name but is a whitespace equivalent
> comment.
Well, I use this:
"Philippe Bruhat (BooK)" <book@cpan.org>
as my From: line, and I would like to be able to use it so in git.
As git knows the difference between user name and user email, it should
be able to keep the information separate all the way.
Which makes me think that since it seems that rebase goes through a
patch-file step, the problem with my username may actually lie with
creating the patch file (no quotes around a user name containing parens)
rather than with parsing the patch From: line.
--
Philippe Bruhat (BooK)
Everyone's life seems easier from the outside.
(Moral from Groo The Wanderer #45 (Epic))
^ permalink raw reply
* Re: Git Documentation
From: Pedro Melo @ 2008-07-22 10:15 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807212035v68c2ed95m93b77c1e61cfec9e@mail.gmail.com>
Hi,
On Jul 22, 2008, at 4:35 AM, Scott Chacon wrote:
> I'm starting a project to host a really nice, user-friendly, easy to
> use Git learning materials website for Git newbies to get new users
> started and make it as easy to learn as possible. I'll be redoing or
> editing some of my screencasts from gitcasts.com and starting an open
> book at github and putting it all in one place for new users to get
> started easily. Anyone will be free to submit changes, additions,
> etc.
>
> If anyone has any tips on how they think git should be taught, issues
> they are asked a lot, problems newbies tend to have, something they
> wish there were a screencast for or was better documented, etc -
> please do contact me so I can incorporate it. I would contribute to
> git itself, but my C-foo is seriously wanting, so if by teaching
> people properly I can free up some time for you guys, I would love to
> do so.
>
> Please let me know if you have any pointers or think anything should
> really be better documented for end-users. I plan to do a lot of
> graphics, screencasts and whatever else makes it as simple as
> possible.
A section on usual workflows and setups would be most useful. Some
like a pull/push workflow, others a email based workflow.
As for learning git stuff, I usually point new users to your stuff :).
I also point them to Tommi Virtanen "Git for Computer Scientists":http://eagain.net/articles/git-for-computer-scientists/
. It was that article that made it all "click" for me regarding git.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* [PATCH v2] parse-options: fix segmentation fault when a required value is missing
From: Olivier Marin @ 2008-07-22 10:11 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20080721190709.GD2718@artemis.madism.org>
From: Olivier Marin <dkr@freesurf.fr>
p->argc represent the number of arguments that have not been parsed yet,
_including_ the one we are currently parsing. If it is not greater than
one then there is no more argument.
Signed-off-by: Olivier Marin <dkr@freesurf.fr>
Acked-by: Pierre Habouzit <madcoder@debian.org>
---
The same, not whitespace damaged! Sorry for the noise.
parse-options.c | 2 +-
t/t0040-parse-options.sh | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/parse-options.c b/parse-options.c
index 987b015..71a7acf 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -22,7 +22,7 @@ static int get_arg(struct parse_opt_ctx_t *p, const struct option *opt,
p->opt = NULL;
} else if (p->argc == 1 && (opt->flags & PARSE_OPT_LASTARG_DEFAULT)) {
*arg = (const char *)opt->defval;
- } else if (p->argc) {
+ } else if (p->argc > 1) {
p->argc--;
*arg = *++p->argv;
} else
diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh
index 6309aed..03dbe00 100755
--- a/t/t0040-parse-options.sh
+++ b/t/t0040-parse-options.sh
@@ -78,6 +78,13 @@ test_expect_success 'long options' '
test_cmp expect output
'
+test_expect_success 'missing required value' '
+ test-parse-options -s;
+ test $? = 129 &&
+ test-parse-options --string;
+ test $? = 129
+'
+
cat > expect << EOF
boolean: 1
integer: 13
--
1.6.0.rc0.136.g55999
^ permalink raw reply related
* post-receive-hook emailer
From: Ask Bjørn Hansen @ 2008-07-22 9:34 UTC (permalink / raw)
To: git
Hi everyone,
Anyone know what is used to send the http://marc.info/?l=git-commits-head
mails?
The post-receive contrib hook in the repository isn't working for us -
we want diffs and such in our mails. I started working on patching
the script in contrib; but it's not really clear to me if the current
state of that script is as it should be and I just have a different
use case.
Anyway - anyone have a mailer that sends diffs and such? :-) Or
should I just write a wrapper around format-patch and send-email?
(To handle branches well it gets slightly complicated, quick - or
maybe I just haven't understood how the post-receive hook works).
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* Re: git status in clean working dir
From: Jeff King @ 2008-07-22 9:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Hommey, git, David Bremner
In-Reply-To: <7viquymg5k.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 22, 2008 at 02:17:43AM -0700, Junio C Hamano wrote:
> Another slight worry I have is if the now-parent git process does the
> right thing when the user kills the pager without viewing the output to
> the end. git itself will get stuck with write() while the user is
> reading, and then notice that the pipe does not have any more reader when
> the pager is killed. This fact itself won't change by swapping the
> parent-child relationship, but would we get a sensible behaviour after
> that, or have we been ignoring what happens afterwards only because our
> exit status has been hidden behind the pager? Running "git log" and
> killing it by "q" (my pager is "less") makes it exit with 141.
Hmm, good point. Though previously in this case, we were getting
whatever code the pager provided. Which means nobody probably cared that
much. Though I suppose that people who use "$?" in their prompt might
see scariness.
> I shouldn't worry, if everything is written correctly in the other parts
> of the system, this swap should not have much ill effect.
I am a little unhappy about the git process hanging around, but I don't
know if it is worth making a meta-process just to manage the pager.
Also, I think people with a pager that has spaces in in it will now need
to quote it (e.g., PAGER="/path with space/less" used to work, but now
is passed to the shell). Arguably, this brings it in line with other
spawned programs, like EDITOR, but it is a difference, and we are in
release freeze. That could be fixed with some magic in run_command.
(Note that it has always been run by the shell under Windows, so again,
this is making things more consistent).
> By the way [2/2] was not signed-off. Just forgotten?
Yes, forgotten. If you are planning on applying, please forge (and
squash the portability fix).
-Peff
^ permalink raw reply
* Re: How to find the first commit belonging to any branch
From: Junio C Hamano @ 2008-07-22 9:27 UTC (permalink / raw)
To: Kristian Amlie; +Cc: git
In-Reply-To: <4885A39F.5080209@trolltech.com>
Kristian Amlie <kristian.amlie@trolltech.com> writes:
> I have a question about git: I have one commit sha1, and I would like
> to know the nearest commit that appears in *any* other branch. The
> sha1 that I have does not belong to any branch.
>
> The obvious thing to do would be to make a for loop and iterate over
> existing branches while calling git merge-base, but I'm wondering if
> there's a more clever method.
If the $commit does not belong to any branch, then:
$ git rev-list --bounardy $commit^0 --not --branches | sed -ne 's/^-//p'
would give you boundary commits of the above traversal, which says:
Traverse from $commit following the parents, but stop at anything that
is reachable from any breanch.
which means that the ones that are output are the candidates that are on
some branch.
So pipe that to name-rev like this, perhaps (untested)?
$ git rev-list --bounardy $commit^0 --not --branches |
sed -ne 's/^-//p' |
git name-rev --stdin
^ permalink raw reply
* Re: Git Documentation
From: Johan Herland @ 2008-07-22 9:21 UTC (permalink / raw)
To: david; +Cc: Scott Chacon, git
In-Reply-To: <alpine.DEB.1.10.0807220035110.1125@asgard.lang.hm>
On Tuesday 22 July 2008, david@lang.hm wrote:
> On Tue, 22 Jul 2008, Johan Herland wrote:
> > It seems there are primarily two ways to teach Git:
> >
> > 1. Top-down: Start with simple use cases and commands. Teach people a
> > minimal, but necessary set of porcelain commands to get them started.
> > Stay _far_ away from plumbing commands and most of the command options.
> >
> > 2. Bottom-up: Start with how Git structures the data. Talk about blobs,
> > trees, commits, refs, how everything is connected, and how various Git
> > commands query and manipulate this structure. This _may_ involve a fair
> > amount of plumbing commands, especially when discovering how the more
> > complicated high-level commands manipulate the structure.
> >
> > Some people seem to prefer the first approach, other people prefer the
> > other approach. Both paths lead to enlightenment ;). In many cases a
> > bit of both may be useful. HOWEVER, I think it is _very_ important to
> > keep in mind that these are two _different_ approaches, and the
> > contexts in which they are taught should be kept separate. I would
> > almost suggest splitting your website down the middle and make the
> > difference between top-down and bottom-up immediately visible with,
> > say, a different background color, or something else that immediately
> > tells the user what "track" they are following...
>
> possibly a combination of the two?
>
> under the covers the git data-structures are pretty simple and explaining
> them (and the minimal tools to manipulate them) isn't that bad.
Not sure. In both cases one will need _some_ kind of model to work with, but
I think that for the top-down approach, it will suffice with a very
simple/simplified model along the lines of:
- A commit contains the state of some repo at some point in time (plus some
metadata)
- A commit points to its direct parents (zero or more). A collection of
commits make up a DAG, representing the history of a project.
- Refs point to select commits. Tags are static, branches are dynamic, etc.
Specifically, for the top-down approach I do NOT think it is necessary to
teach:
- blobs and trees
- plumbing tools
> what gets ugly is when you then try to use the plumbing to do the
> non-trivial things.
Certainly. We should only use plumbing tools in the bottom-up approach, and
even then we should only use them when it _simplifies_ or otherwise nicely
_illustrates_ the concepts being taught.
> so how about an optional 'under the covers' primer, covering just the
> trivial plumbing, then the high-level minimal introduction with a link on
> each of the commands as they are introduced (so that a person can dig
> into deeper detail if they want to, possibly including 'up until version
> X this command was implemented by the following script'), followed by
> links to sample work-flows and a full dive into the plumbing (because at
> this point the person should know enough to get by, now they need
> reference material and examples more then a tutorial).
Nope. A primer (i.e. a document to be read before the "real" teaching
starts) should not cover more than the simplest/simplified model (see
above).
Of course, the courses should reference manual pages and more in-depth
documentation wherever it makes sense, but we should make sure to note that
such knowledge is not _required_ to follow the course.
> ideally this would let people dive as deep as they are comfortable with,
> or skim the explanation for the functionality
>
> I think one reason the 'plumbing first' approach gets a bad rap is that
> it's so easy to get caught up into how clever you can get with the
> plumbing. it's like teaching someone programming by spending a day
> introducing them to concepts and language syntax, and then giving them
> the entries in the obfuscated C contests as examples of how someone can
> use them to get work done, but skipping any mention of libc or other
> standard libraries.
I see your point, but I still don't think teaching plumbing have any value
in and of itself (unless you need to specifically learn plumbing to write
porcelain code/scripts, in which case you'd better already know how to
navigate the existing manual pages and other documentation).
For newbies, I think plumbing should only be taught/mentioned when it
simplifies or illustrates a concept in the bottom-up approach.
> on the other hand, teaching only porcelain is like teaching them <insert
> high-level *th generation buzzword language> without teaching any concept
> of what they computer is doing under the covers, they can work, and even
> get useful work done, but they will be limited on how effective they can
> be.
I don't agree that teaching only porcelain will not give them any concept of
what their computer does "under the covers". I think we can teach porcelain
with reference to the simplified object model, and still achieve a
(simplified, but still rewarding) understanding of what happens at an
object level.
When I use Git myself, I normally only think in terms of the simplified
model, and I have no problem getting things done without paying attention
to the full object model (blobs, trees, etc) or the plumbing tools that are
implicitly involved in the process.
> you can't be a great programmer until you can understand both levels, the
> under-the-covers 'plumbing' and the high level libraries of the
> 'porcelain', trying to ignore either will limit you.
Agreed. But we shouldn't need every Git user to be a great programmer. At
least I hope not. Otherwise, there will be few Git users, indeed... ;)
Many Git users will not be VCS geeks like us; they will be "regular" people
that use Git because it's useful for them (or because they're forced to use
Git at $dayjob). They will not be interested in how Git manages their data,
and how a complex Git operation can be split into simple plumbing
components. We should not require them to learn such details in order to
become good Git users. Instead we should teach them Git using porcelain
commands with reference to the simplified object model. They should learn
how to use Git in a simple, yet still rewarding manner.
...and _that_ is how we achieve world domination ;)
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git status in clean working dir
From: Junio C Hamano @ 2008-07-22 9:17 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Hommey, git, David Bremner
In-Reply-To: <20080722071009.GA3610@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jul 22, 2008 at 02:46:04AM -0400, Jeff King wrote:
>
>> I am tempted by the "order switching" I mentioned, but that would entail
>> the git process waiting to clean the pager, during which time it may be
>> consuming memory. But maybe that isn't worth worrying about.
>
> It feels very wrong proposing this during release freeze, but here is
> the "pager is child of git" implementation.
Another slight worry I have is if the now-parent git process does the
right thing when the user kills the pager without viewing the output to
the end. git itself will get stuck with write() while the user is
reading, and then notice that the pipe does not have any more reader when
the pager is killed. This fact itself won't change by swapping the
parent-child relationship, but would we get a sensible behaviour after
that, or have we been ignoring what happens afterwards only because our
exit status has been hidden behind the pager? Running "git log" and
killing it by "q" (my pager is "less") makes it exit with 141.
I shouldn't worry, if everything is written correctly in the other parts
of the system, this swap should not have much ill effect.
By the way [2/2] was not signed-off. Just forgotten?
^ permalink raw reply
* Re: Error: "You have some suspicious patch lines"
From: Jakub Narebski @ 2008-07-22 9:13 UTC (permalink / raw)
To: Ben Aurel; +Cc: git
In-Reply-To: <4885895C.5050108@gmail.com>
Ben Aurel <ben.aurel@gmail.com> writes:
> I working on mac os x 10.5.4 (intel) with git version 1.5.5.3 and I
> always get this message for most of my perl scripts and also for
> "Makefile.pre" files:
>
> ----------- Message ---------------
> * You have some suspicious patch lines:
> *
> * In src/scripts/trunk/3rdparty/file_sanity.pl
> * trailing whitespace (line 52)
> ...
> ------------------------------------------
> The question now is: Is it really necessary to edit the git script
> everytime? Is there a urgent reason why git refuses to commit because
> of "suspicious" lines? Is it really necessary?
.git/hooks/pre-commit is example hook which helps to keep Coding Style,
and prevents from accidentally comitting nonresolved file-level merge
conflict (file with conflict markers).
If you want to skip running this hook once (or once upon a time), you
can use '-n'/'--no-verify' option to "git commit". Or you can turn this
example hook off, either by removing execute permission from it, by
removing it alltogether (you can still find it in templates, usually at
/usr/share/git-core/templates/hooks/pre-commit), or rename it adding for
example '.sample' or '.nonactive' suffix.
This hook should not be turned on by default, but if your filesystem is
executing bit challenged it could be turned on at repository creation
time unintentionally. Newer version of git use '.sample' suffix (for
example pre-commit.sample) instead of relying on not always reliable
execute bit being unset.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* How to find the first commit belonging to any branch
From: Kristian Amlie @ 2008-07-22 9:08 UTC (permalink / raw)
To: git
Hi all!
I have a question about git: I have one commit sha1, and I would like to
know the nearest commit that appears in *any* other branch. The sha1
that I have does not belong to any branch.
The obvious thing to do would be to make a for loop and iterate over
existing branches while calling git merge-base, but I'm wondering if
there's a more clever method.
Regards
Kristian Amlie
^ permalink raw reply
* Re: [PATCH] builtin-merge-recursive.c: make merge_recursive() static
From: Junio C Hamano @ 2008-07-22 8:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807201403070.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Of course, we could apply this patch now, and revert it later, increasing
> your commit count in the process :-)
Heh, don't tempt people, especially when we would have an interesting
set of tools for statistics just around the corner ;-)
^ permalink raw reply
* Re: [PATCH 2/2] spawn pager via run_command interface
From: Johannes Sixt @ 2008-07-22 8:29 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Hommey, Junio C Hamano, git, David Bremner
In-Reply-To: <20080722075035.GC3999@sigill.intra.peff.net>
Jeff King schrieb:
> On Tue, Jul 22, 2008 at 09:48:09AM +0200, Johannes Sixt wrote:
>
>> BTW, you could remove the #ifndef __MINGW32__ around both the definition
>> and the use of pager_preexec. We have everything on mingw to compile and
>> link this function.
>
> Ah, OK. I left it around the function because I was worried about fd_set
> needing some magic for compilation.
I do not expect you to know the intricacies of the mingw port. Hence,
staying on the safe side, like you did, is of course highly appreciated.
> However, it still won't be _used_ on Windows, because there is no
> opportunity to use the pre-exec callback (it is silently ignored).
That's fine.
-- Hannes
^ permalink raw reply
* Re: [PATCH] builtin-merge: give a proper error message for invalid strategies in config
From: Junio C Hamano @ 2008-07-22 8:24 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080722073912.GN32057@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> ... I
> would like to send a patch that changes the config parsing as well, so
> that pull.twohead "foo bar" would be invalid, and the user would have to
> have two pull.twohead entries: one for foo and one for bar.
Don't. pull.* has always been defined as "list of strategies", and -s has
always been defined to take "a" strategy.
IOW, you don't need to break anything further.
^ permalink raw reply
* Re: [PATCH] Fix update-index --refresh for submodules if stat(2) returns st_size 0
From: Junio C Hamano @ 2008-07-22 8:07 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git
In-Reply-To: <20080721194322.GA4013@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200:
>> Hi,
>>
>> On Mon, 21 Jul 2008, Alex Riesen wrote:
>>
>> > For example - Cygwin.
>>
>> Please enhance: your oneline is too long, and your commit message body too
>> short.
>
> Well, I'm really not sure. I just found this difference between linux
> and cygwin (st_stat is 0 for dirs on cygwin). Than I noticed that the
> routine where I made the change explicitely checks for st_size not
> being 0. I must admit I can't make much out of comment, and hope this
> discussion will help to clear the check up.
The cached stat information in the index is used to speed up comparison
between "the last staged data" and what is in the working tree.
ie_match_stat() compares ce_xxx fields with the result from lstat(2) we
just did, and if there are differences, we take it as a sign that what's
in the working tree is different from what we saw when we updated the
index entry.
But there is a twist.
Ordinarily, when an entry enteres the index, the hash of the blob contents
goes along with the lstat(2) information taken from the file that supplied
the contents. However there are some cases we populate the index without
lstat(2). update-index --cacheinfo, update-index --index-info are two
examples, and when they add index entries, they leave ce_size field to
zero. ie_match_stat() will compare that zero ce_size with the size
information obtained from the working tree, and declare (falsely) that
"what's in the working tree is different -- it can never match, and there
is no point trying to re-index to see if they actually match", even though
the reason ce_size is zero is *not* because we observed the size of the
working tree file *was* zero when we indexed it the last time (it is zero
merely because we haven't looked at it yet). The ce_modified_check_fs()
call is there to deal with this "we cannot trust the ce_xxx fields" case.
I however have to wonder if you also need to touch the end of
ce_match_stat_basic() that checks for zero sized cache entry.
^ permalink raw reply
* Re: Git Documentation
From: david @ 2008-07-22 7:56 UTC (permalink / raw)
To: Johan Herland; +Cc: Scott Chacon, git
In-Reply-To: <200807220917.57363.johan@herland.net>
On Tue, 22 Jul 2008, Johan Herland wrote:
> On Tuesday 22 July 2008, Scott Chacon wrote:
>> If anyone has any tips on how they think git should be taught, issues
>> they are asked a lot, problems newbies tend to have, something they
>> wish there were a screencast for or was better documented, etc -
>> please do contact me so I can incorporate it.
>
> You should at least take a look at this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/88698
>
> (even though it goes off-topic after a while...)
>
>> If anyone has any tips on how they think git should be taught...
>
> It seems there are primarily two ways to teach Git:
>
> 1. Top-down: Start with simple use cases and commands. Teach people a
> minimal, but necessary set of porcelain commands to get them started. Stay
> _far_ away from plumbing commands and most of the command options.
>
> 2. Bottom-up: Start with how Git structures the data. Talk about blobs,
> trees, commits, refs, how everything is connected, and how various Git
> commands query and manipulate this structure. This _may_ involve a fair
> amount of plumbing commands, especially when discovering how the more
> complicated high-level commands manipulate the structure.
>
> Some people seem to prefer the first approach, other people prefer the other
> approach. Both paths lead to enlightenment ;). In many cases a bit of both
> may be useful. HOWEVER, I think it is _very_ important to keep in mind that
> these are two _different_ approaches, and the contexts in which they are
> taught should be kept separate. I would almost suggest splitting your
> website down the middle and make the difference between top-down and
> bottom-up immediately visible with, say, a different background color, or
> something else that immediately tells the user what "track" they are
> following...
possibly a combination of the two?
under the covers the git data-structures are pretty simple and explaining
them (and the minimal tools to manipulate them) isn't that bad.
what gets ugly is when you then try to use the plumbing to do the
non-trivial things.
so how about an optional 'under the covers' primer, covering just the
trivial plumbing, then the high-level minimal introduction with a link on
each of the commands as they are introduced (so that a person can dig into
deeper detail if they want to, possibly including 'up until version X
this command was implemented by the following script'), followed by links
to sample work-flows and a full dive into the plumbing (because at this
point the person should know enough to get by, now they need reference
material and examples more then a tutorial).
ideally this would let people dive as deep as they are comfortable with, or
skim the explanation for the functionality
I think one reason the 'plumbing first' approach gets a bad rap is that
it's so easy to get caught up into how clever you can get with the
plumbing. it's like teaching someone programming by spending a day
introducing them to concepts and language syntax, and then giving them the
entries in the obfuscated C contests as examples of how someone can use
them to get work done, but skipping any mention of libc or other standard
libraries.
on the other hand, teaching only porcelain is like teaching them <insert
high-level *th generation buzzword language> without teaching any concept
of what they computer is doing under the covers, they can work, and even
get useful work done, but they will be limited on how effective they can
be.
you can't be a great programmer until you can understand both levels, the
under-the-covers 'plumbing' and the high level libraries of the
'porcelain', trying to ignore either will limit you.
David Lang
^ permalink raw reply
* Re: git status in clean working dir
From: Johannes Sixt @ 2008-07-22 7:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, David Bremner
In-Reply-To: <20080722074632.GA3999@sigill.intra.peff.net>
Jeff King schrieb:
> On Tue, Jul 22, 2008 at 09:34:45AM +0200, Johannes Sixt wrote:
>
>>> - { "diff-files", cmd_diff_files, RUN_SETUP },
>>> + { "diff-files", cmd_diff_files, RUN_SETUP | FORBID_PAGER },
>> Every now and then I want to use 'git -p diff-files', and I think that is
>> a valid use-case. But your suggested patch seems to forbid the pager even
>> in this case. :-(
>
> Actually, it doesn't. If you read earlier in the message, this applies
> only to pager.* config. That being said, I think Junio's ultimate goal
> was to not allow stupid people to accidentally set the pager on
> plumbing, at the expense of any smart people who might want to do it for
> a good reason.
>
> Though I have to wonder why "git diff --raw" is not enough for you.
Usually, I use plumbing with a pager while I'm writing or debugging a
script, and I'm studying its output. So, no, I'm not interested in "git
diff --raw". ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH 2/2] spawn pager via run_command interface
From: Jeff King @ 2008-07-22 7:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Mike Hommey, Junio C Hamano, git, David Bremner
In-Reply-To: <488590B9.1080804@viscovery.net>
On Tue, Jul 22, 2008 at 09:48:09AM +0200, Johannes Sixt wrote:
> BTW, you could remove the #ifndef __MINGW32__ around both the definition
> and the use of pager_preexec. We have everything on mingw to compile and
> link this function.
Ah, OK. I left it around the function because I was worried about fd_set
needing some magic for compilation.
However, it still won't be _used_ on Windows, because there is no
opportunity to use the pre-exec callback (it is silently ignored).
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] spawn pager via run_command interface
From: Jeff King @ 2008-07-22 7:49 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Mike Hommey, Junio C Hamano, git, David Bremner
In-Reply-To: <20080722073108.GA9714@artemis.madism.org>
On Tue, Jul 22, 2008 at 09:31:08AM +0200, Pierre Habouzit wrote:
> > I couldn't recall if this initializer style is portable enough for us.
> > It was already there wrapped in ifdefs, but perhaps it was only ok
> > because the mingw version always uses the same compiler?
>
> it's not, I asked long time ago, and it's C99, which mingw supports
> indeed, and we don't want to require a C99 compiler.
OK, then this should be squashed in.
diff --git a/pager.c b/pager.c
index 7743742..aa0966c 100644
--- a/pager.c
+++ b/pager.c
@@ -26,13 +26,8 @@ static void pager_preexec(void)
#endif
static const char *pager_argv[] = { "sh", "-c", NULL, NULL };
-static struct child_process pager_process = {
- .argv = pager_argv,
- .in = -1,
-#ifndef __MINGW32__
- .preexec_cb = pager_preexec,
-#endif
-};
+static struct child_process pager_process;
+
static void wait_for_pager(void)
{
fflush(stdout);
@@ -65,6 +60,11 @@ void setup_pager(void)
/* spawn the pager */
pager_argv[2] = pager;
+ pager_process.argv = pager_argv;
+ pager_process.in = -1;
+#ifndef __MINGW32__
+ pager_process.preexec_cb = pager_preexec;
+#endif
if (start_command(&pager_process))
return;
^ permalink raw reply related
* Re: [PATCH 2/2] spawn pager via run_command interface
From: Johannes Sixt @ 2008-07-22 7:48 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Hommey, Junio C Hamano, git, David Bremner
In-Reply-To: <20080722071630.GA3669@sigill.intra.peff.net>
Jeff King schrieb:
> On Tue, Jul 22, 2008 at 03:14:12AM -0400, Jeff King wrote:
>
>> static struct child_process pager_process = {
>> .argv = pager_argv,
>> - .in = -1
>> + .in = -1,
>> +#ifndef __MINGW32__
>> + .preexec_cb = pager_preexec,
>> +#endif
>
> I couldn't recall if this initializer style is portable enough for us.
> It was already there wrapped in ifdefs, but perhaps it was only ok
> because the mingw version always uses the same compiler?
Yes, that's because on mingw we know that we use gcc. This really must be
changed for portability.
BTW, you could remove the #ifndef __MINGW32__ around both the definition
and the use of pager_preexec. We have everything on mingw to compile and
link this function.
-- Hannes
^ 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