* Re: [PATCH] Fix memory leak in transport-helper
From: Daniel Barkalow @ 2009-10-27 19:05 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, Johan Herland, Nanako Shiraishi,
Sverre Rabbelier, git
In-Reply-To: <alpine.DEB.1.00.0910271954020.11562@felix-maschine>
On Tue, 27 Oct 2009, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Oct 2009, Daniel Barkalow wrote:
>
> > On Tue, 27 Oct 2009, Johannes Schindelin wrote:
> >
> > > Hi,
> > >
> > > On Tue, 27 Oct 2009, Daniel Barkalow wrote:
> > >
> > > > diff --git a/transport-helper.c b/transport-helper.c
> > > > index f57e84c..479539d 100644
> > > > --- a/transport-helper.c
> > > > +++ b/transport-helper.c
> > > > @@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
> > > > return 0;
> > > > }
> > > >
> > > > +static int close_helper(struct transport *transport)
> > > > +{
> > > > + disconnect_helper(transport);
> > > > + free(transport->data);
> > > > + return 0;
> > > > +}
> > >
> > > Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> > > patch?
> >
> > Because this code is only called just before transport itself is freed by
> > the caller, and, in general, a transport with these methods is invalid
> > without a valid transport->data. I expect that's also why Peff called it a
> > hack not appropriate for actual application.
>
> So you mean to imply that this method is not about closing, but about
> releasing the structure. Right?
Yes, that's the word I was failing to come up with last night, thanks.
Junio, "s/close/release/g" on that patch should improve comprehensibility
greatly. (And changing the transport method name would probably also
improve matters)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Problems with git am
From: Jeff King @ 2009-10-27 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: alan, git
In-Reply-To: <7veiopbm9l.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 07:31:34PM -0700, Junio C Hamano wrote:
> alan <alan@clueserver.org> writes:
>
> > The other question is what the proper behaviour when git-am in unable
> > to process a patch. Under git 1.6.0, it exits with a non-zero error
> > code. Under the current git in the git repo it issues and error and
> > exits with a non-error exit code.
>
> Hmph, that sounds like a recent regression to me. I'll try to find time
> to look into it myself sometime tonight but no promises.
I'm having trouble reproducing, either with a totally bogus input format
or with "git log -p" output (which is what it sounds like the OP has).
Both of these tests already pass on 'next':
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 8296605..2d5e32a 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -346,4 +346,17 @@ test_expect_success 'am -q is quiet' '
! test -s output.out
'
+test_expect_success 'am properly reports error' '
+ echo excellent > bogus &&
+ test_must_fail git am bogus
+'
+
+test_expect_success 'am properly reports error (git log output)' '
+ echo more content >>file &&
+ git commit -m content file &&
+ git log -1 -p > bogus &&
+ git reset --hard HEAD^ &&
+ test_must_fail git am bogus
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] Fix memory leak in transport-helper
From: Johannes Schindelin @ 2009-10-27 18:54 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Shawn O. Pearce, Junio C Hamano, Johan Herland, Nanako Shiraishi,
Sverre Rabbelier, git
In-Reply-To: <alpine.LNX.2.00.0910271329510.14365@iabervon.org>
Hi,
On Tue, 27 Oct 2009, Daniel Barkalow wrote:
> On Tue, 27 Oct 2009, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Tue, 27 Oct 2009, Daniel Barkalow wrote:
> >
> > > diff --git a/transport-helper.c b/transport-helper.c
> > > index f57e84c..479539d 100644
> > > --- a/transport-helper.c
> > > +++ b/transport-helper.c
> > > @@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
> > > return 0;
> > > }
> > >
> > > +static int close_helper(struct transport *transport)
> > > +{
> > > + disconnect_helper(transport);
> > > + free(transport->data);
> > > + return 0;
> > > +}
> >
> > Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> > patch?
>
> Because this code is only called just before transport itself is freed by
> the caller, and, in general, a transport with these methods is invalid
> without a valid transport->data. I expect that's also why Peff called it a
> hack not appropriate for actual application.
So you mean to imply that this method is not about closing, but about
releasing the structure. Right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Shawn O. Pearce @ 2009-10-27 18:52 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Junio C Hamano, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <1256589116-6998-3-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> wrote:
> Some users don't want to compile their completion, even when the build
> generated completion is 10x faster to load. For example, in my bashrc I
> source the completion script directly so I can stay up to date with the
> latest completion by merely pulling changes.
>
> Do this by generating the lists dynamically when the merge strategy and
> command lists still have their initial values (__GIT_MERGE_STRATEGYLIST,
> __GIT_ALL_COMMANDLIST).
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> This duplicates code, but I don't know of a way to re-use the dynamic
> code without sourcing a bash script and possibly breaking someone's build.
NAK on code duplication, especially this much. As Junio already
pointed out in this thread we need an approach that doesn't cause
this sort of redundant code.
I'm trying to catch up on email right now. I have no great
suggestions on how to implement this to avoid the code duplication
and still be able to support both compile-time and on-the-fly
computation, but I do know I don't want this code twice.
--
Shawn.
^ permalink raw reply
* Re: git update --prune issue
From: Jeff King @ 2009-10-27 18:46 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeffrey Middleton, Michael J Gruber, git
In-Reply-To: <20091027165054.GA8554@sigill.intra.peff.net>
On Tue, Oct 27, 2009 at 12:50:55PM -0400, Jeff King wrote:
> > Actually, it's beta_gc_dev_old and beta_gc_dev, not the same refs.
>
> OK, I'm a bit blind. Thanks for pointing it out. I'll still see if I can
> replicate it.
I'm not having any luck reproducing here with a simple case. :( I'm
trying:
-- >8 --
#!/bin/sh
rm -rf parent* child
commit() {
echo $1 >file && git add file && git commit -m $1
}
mkdir parent1 && (
cd parent1 &&
git init &&
commit one &&
commit two &&
git checkout -b other
) &&
mkdir parent2 && (
cd parent2 &&
git init &&
commit three
) &&
mkdir child && (
cd child &&
git init &&
git remote add parent1 ../parent1 &&
git remote add parent2 ../parent2 &&
git remote update
) &&
(
cd parent1 &&
git checkout master &&
git branch -d other &&
git reset --hard HEAD^ &&
commit four
) && (
cd child &&
git remote update --prune
)
^ permalink raw reply
* Re: jp/dirty-describe topic
From: Shawn O. Pearce @ 2009-10-27 18:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> * jp/dirty-describe (2009-10-21) 1 commit.
> - Teach "git describe" --dirty option
>
> Ack?
Yup,
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fix memory leak in transport-helper
From: Jeff King @ 2009-10-27 18:31 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Johannes Schindelin, Shawn O. Pearce, Junio C Hamano,
Johan Herland, Nanako Shiraishi, Sverre Rabbelier, git
In-Reply-To: <alpine.LNX.2.00.0910271329510.14365@iabervon.org>
On Tue, Oct 27, 2009 at 01:37:19PM -0400, Daniel Barkalow wrote:
> > Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> > patch?
>
> Because this code is only called just before transport itself is freed by
> the caller, and, in general, a transport with these methods is invalid
> without a valid transport->data. I expect that's also why Peff called it a
> hack not appropriate for actual application.
More or less. I called it a hack because I didn't even look far enough
to know whether or not that was the case. I was just trying to get it to
stop segfaulting so Sverre could continue his work.
-Peff
^ permalink raw reply
* Add '--bisect' revision machinery argument
From: Linus Torvalds @ 2009-10-27 18:28 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
I personally use "git bisect visualize" all the time when I bisect, but it
turns out that that is not a very flexible model. Sometimes I want to do
bisection based on all commits (no pathname limiting), but then visualize
the current bisection tree with just a few pathnames because I _suspect_
those pathnames are involved in the problem but am not totally sure about
them.
And at other times, I want to use other revision parsing logic, none of
which is available with "git bisect visualize".
So this adds "--bisect" as a revision parsing argument, and as a result it
just works with all the normal logging tools. So now I can just do
gitk --bisect --simplify-by-decoration filename-here
etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
builtin-rev-parse.c | 11 +++++++++++
revision.c | 18 +++++++++++++++++-
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 45bead6..9526aaf 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -180,6 +180,12 @@ static int show_reference(const char *refname, const unsigned char *sha1, int fl
return 0;
}
+static int anti_reference(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ show_rev(REVERSED, sha1, refname);
+ return 0;
+}
+
static void show_datestring(const char *flag, const char *datestr)
{
static char buffer[100];
@@ -548,6 +554,11 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
for_each_ref(show_reference, NULL);
continue;
}
+ if (!strcmp(arg, "--bisect")) {
+ for_each_ref_in("refs/bisect/bad", show_reference, NULL);
+ for_each_ref_in("refs/bisect/good", anti_reference, NULL);
+ continue;
+ }
if (!strcmp(arg, "--branches")) {
for_each_branch_ref(show_reference, NULL);
continue;
diff --git a/revision.c b/revision.c
index 9fc4e8d..80a0528 100644
--- a/revision.c
+++ b/revision.c
@@ -994,7 +994,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
if (!strcmp(arg, "--all") || !strcmp(arg, "--branches") ||
!strcmp(arg, "--tags") || !strcmp(arg, "--remotes") ||
!strcmp(arg, "--reflog") || !strcmp(arg, "--not") ||
- !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk"))
+ !strcmp(arg, "--no-walk") || !strcmp(arg, "--do-walk") ||
+ !strcmp(arg, "--bisect"))
{
unkv[(*unkc)++] = arg;
return 1;
@@ -1218,6 +1219,16 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
ctx->argc -= n;
}
+static int for_each_bad_bisect_ref(each_ref_fn fn, void *cb_data)
+{
+ return for_each_ref_in("refs/bisect/bad", fn, cb_data);
+}
+
+static int for_each_good_bisect_ref(each_ref_fn fn, void *cb_data)
+{
+ return for_each_ref_in("refs/bisect/good", fn, cb_data);
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -1259,6 +1270,11 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
handle_refs(revs, flags, for_each_branch_ref);
continue;
}
+ if (!strcmp(arg, "--bisect")) {
+ handle_refs(revs, flags, for_each_bad_bisect_ref);
+ handle_refs(revs, flags ^ UNINTERESTING, for_each_good_bisect_ref);
+ continue;
+ }
if (!strcmp(arg, "--tags")) {
handle_refs(revs, flags, for_each_tag_ref);
continue;
^ permalink raw reply related
* Re: vl/git-gui topic
From: Shawn O. Pearce @ 2009-10-27 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> * vl/git-gui (2009-10-16) 1 commit.
> - git-gui: adjust the minimum height of diff pane for shorter screen height
>
> Shawn?
Applied to git-gui tree.
--
Shawn.
^ permalink raw reply
* Re: Making Git easy to use -- without RTFM, was Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Avery Pennarun @ 2009-10-27 17:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0910271118470.4985@pacific.mpi-cbg.de>
On Tue, Oct 27, 2009 at 6:33 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Anyhow, here it is: one of my users refused to touch SCMs _at all_, for
> decades. There was only one choice: have a Git branch with a purely
> linear history that contains the copy of the working tree at the end of
> the day, with whatever changes accumulated over the day, or no history at
> all.
[...]
> You know, when there is a hurdle half of the people you see cannot get
> over, there are some who make the hurdle half as high, and there are
> others who put more hurdles there and call it a sport.
>
> In this case, I would have preferred to make the hurdle half as high, but
> I think I just have to wait a couple of years; reality will take care of
> things.
In this case, what would you have preferred to change in order to make
the hurdle half as high?
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] Fix memory leak in transport-helper
From: Daniel Barkalow @ 2009-10-27 17:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, Johan Herland, Nanako Shiraishi,
Sverre Rabbelier, git
In-Reply-To: <alpine.DEB.1.00.0910271510430.4985@pacific.mpi-cbg.de>
On Tue, 27 Oct 2009, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 27 Oct 2009, Daniel Barkalow wrote:
>
> > diff --git a/transport-helper.c b/transport-helper.c
> > index f57e84c..479539d 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -67,6 +67,13 @@ static int disconnect_helper(struct transport *transport)
> > return 0;
> > }
> >
> > +static int close_helper(struct transport *transport)
> > +{
> > + disconnect_helper(transport);
> > + free(transport->data);
> > + return 0;
> > +}
>
> Why did you not leech the transport->data = NULL; part from Peff/Sverre's
> patch?
Because this code is only called just before transport itself is freed by
the caller, and, in general, a transport with these methods is invalid
without a valid transport->data. I expect that's also why Peff called it a
hack not appropriate for actual application.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-svn changing file:// to svn+ssh://
From: Sam Vilain @ 2009-10-27 17:17 UTC (permalink / raw)
To: Avery Pennarun; +Cc: pascal, git list
In-Reply-To: <32541b130910261218x5fdc0233jcce7c5769aad73ec@mail.gmail.com>
On Mon, 2009-10-26 at 15:18 -0400, Avery Pennarun wrote:
> > Now I have converted the file:// to svn+ssh:// using:
>
> I'm not sure about the actual bug you're experiencing, but you could
> have done this more simply using the --rewrite-root option to git-svn.
> It might still save you time to just do that from scratch.
Another thing: if your file:// repository was copied from the original
location using SVN::Mirror or svnsync, then git-svn is capable of
reading the breadcrumbs left by those tools with a switch and rewriting
the git-svn-id: lines accordingly.
Sam
^ permalink raw reply
* [PATCH] gitk: fix typo when diffing committed -> staged
From: Jens Lehmann @ 2009-10-27 17:13 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Git Mailing List
When highlighting a commit, using the context menu over the staged changes
and then selecting "Diff this -> selected" the diff was empty. The same
happened when highlighting the staged changes and using "Diff selected ->
this" over a commit.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
I became aware of this issue while testing the submodule patch sent
earlier. Looks just like a copy & paste typo.
gitk-git/gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..8e892b3 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7224,7 +7224,7 @@ proc diffcmd {ids flags} {
set cmd [concat | git diff-index --cached $flags]
if {[llength $ids] > 1} {
# comparing index with specific revision
- if {$i == 0} {
+ if {$j == 0} {
lappend cmd -R [lindex $ids 1]
} else {
lappend cmd [lindex $ids 0]
--
1.6.5.2.181.gd6f41.dirty
^ permalink raw reply related
* Re: From 200 to 404 to 407.
From: Avery Pennarun @ 2009-10-27 16:53 UTC (permalink / raw)
To: Peter Odéus; +Cc: git
In-Reply-To: <82fd2c5d0910270318wc30bc44tfd3362933d3f62cf@mail.gmail.com>
On Tue, Oct 27, 2009 at 6:18 AM, Peter Odéus <peter.odeus@gmail.com> wrote:
> Doing a "git clone..." using authenticated proxy (set in $http_proxy):
>
> Upon initial success (HTTP 200) and receiving a single HTTP 404 (not
> found), every GET after that renders a HTTP 407 (Proxy authentication
> required).
>
> curl -I "url_giving_http_407" comes out just fine as a HTTP 200.
The easiest way to track this down is to log it using ethereal, and
compare the http session dumps. There may be differences in headers
or something that git is providing vs. the command-line curl.
If you don't know how to analyze http dumps, then just log them to a
file using tcpdump's -w option and email them to me, and I'll take a
look. (I probably won't fix the bug in git, but I can at least tell
you what/if the bug is :)) Please don't send the binary dumpfiles to
the mailing list, though.
Have fun,
Avery
^ permalink raw reply
* Re: git update --prune issue
From: Jeff King @ 2009-10-27 16:50 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Jeffrey Middleton, Michael J Gruber, git
In-Reply-To: <20091027164040.GB12464@localhost>
On Tue, Oct 27, 2009 at 05:40:40PM +0100, Clemens Buchacher wrote:
> On Tue, Oct 27, 2009 at 12:29:36PM -0400, Jeff King wrote:
>
> > > Pruning steph
> > > URL: /users/sdewet/CxTF_DEV/CxTF_DB/
> > > * [pruned] steph/beta_gc_dev_old
> > > Updating kevin
> > > error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
> > > error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
> >
> > The "pruned" line basically means that we are deleting that ref, and
> > then we complain immediately about that very ref (which is probably
> > pointing to the null sha1 or something at this point).
>
> Actually, it's beta_gc_dev_old and beta_gc_dev, not the same refs.
OK, I'm a bit blind. Thanks for pointing it out. I'll still see if I can
replicate it.
-Peff
^ permalink raw reply
* Re: git update --prune issue
From: Clemens Buchacher @ 2009-10-27 16:40 UTC (permalink / raw)
To: Jeff King; +Cc: Jeffrey Middleton, Michael J Gruber, git
In-Reply-To: <20091027162936.GA8130@sigill.intra.peff.net>
On Tue, Oct 27, 2009 at 12:29:36PM -0400, Jeff King wrote:
> > Pruning steph
> > URL: /users/sdewet/CxTF_DEV/CxTF_DB/
> > * [pruned] steph/beta_gc_dev_old
> > Updating kevin
> > error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
> > error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
>
> The "pruned" line basically means that we are deleting that ref, and
> then we complain immediately about that very ref (which is probably
> pointing to the null sha1 or something at this point).
Actually, it's beta_gc_dev_old and beta_gc_dev, not the same refs.
Clemens
^ permalink raw reply
* Re: git update --prune issue
From: Jeffrey Middleton @ 2009-10-27 16:39 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20091027162936.GA8130@sigill.intra.peff.net>
On Tue, Oct 27, 2009 at 11:29 AM, Jeff King <peff@peff.net> wrote:
> The "pruned" line basically means that we are deleting that ref, and
> then we complain immediately about that very ref (which is probably
> pointing to the null sha1 or something at this point). We tend to cache
> packed refs, so that may be the cause.
Actually, it force updated two refs, created one, and deleted one, and
then immediately complained about the force-updated refs - but only
after moving on into the next remote update. My best guess would
still be that as you suggest there's an out of date cache - it gets
updated within the "update steph" part, but when it moves on to
"update kevin" it doesn't have all the new information.
> So either we need to invalidate that ref from the cache when it gets
> deleted, or perhaps we are already invalidating it and we need to be
> respecting that invalidation in other parts of the code. I'll take a
> look.
>
> -Peff
>
^ permalink raw reply
* Re: Getting Ensimag students to work on Git for a few weeks
From: Matthieu Moy @ 2009-10-27 16:39 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20091027144405.GA12464@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> That's not much time to get familiar with a complex project like git. So you
> will have to do something extremely simple,
That very much depends on which students. Some of our students are
already experienced programmers when the enter the school. If I manage
to attract such students, a group of 4 can do a bit more than
"extremely simple".
> which probably means that it won't be anything exciting.
Depending "exiting for who" ... my first contributions to free
software were very trivial code, and I found it very exciting the day
I got 20 trivial lines of code of mine into GNU Emacs ;-).
So, the feature may not be exciting, but I think the experience for
students could be.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Getting Ensimag students to work on Git for a few weeks
From: Matthieu Moy @ 2009-10-27 16:32 UTC (permalink / raw)
To: Hervé Cauwelier; +Cc: git
In-Reply-To: <4AE71629.6050208@itaapy.com>
Hervé Cauwelier <herve@itaapy.com> writes:
> Have you considered projects contributing to libgit2?
Right now, the project is just an idea, so I didn't consider an idea
in particular. But I'd love to get people to work on libgit2 (I really
think this is _the_ thing that SVN has and that Git lacks), and
therefore, I'd love my students to work on this.
But as much as possible, I'll wait and decide the exact project with
the students.
> The students at ULCO [1] will be mentored by Andreas Ericsson.
Thanks for the pointer.
> Given that libgit2 is quite empty, there are many small tasks like
> starting commits, trees, tags, etc. objects.
OTOH, I don't know whether we'd get as much feedback working on
libgit2 than working on Git itself.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: git update --prune issue
From: Jeff King @ 2009-10-27 16:29 UTC (permalink / raw)
To: Jeffrey Middleton; +Cc: Michael J Gruber, git
In-Reply-To: <4389ce950910270807o69d51155xb083f34bb31e1dae@mail.gmail.com>
On Tue, Oct 27, 2009 at 10:07:27AM -0500, Jeffrey Middleton wrote:
> > Do you get the same problem if you do the steps individually, i.e.:
> >
> > git remote update steph
> > git remote prune steph
> > git remote update kevin
>
> I don't *think* I'll see it this way - I was doing essentially this
> prior to introduction of the --prune option, and never saw it then.
I suspect you are seeing git keeping an invalid cache of the set of refs
within a single program. Your original report had:
> Pruning steph
> URL: /users/sdewet/CxTF_DEV/CxTF_DB/
> * [pruned] steph/beta_gc_dev_old
> Updating kevin
> error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
> error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
The "pruned" line basically means that we are deleting that ref, and
then we complain immediately about that very ref (which is probably
pointing to the null sha1 or something at this point). We tend to cache
packed refs, so that may be the cause.
So either we need to invalidate that ref from the cache when it gets
deleted, or perhaps we are already invalidating it and we need to be
respecting that invalidation in other parts of the code. I'll take a
look.
-Peff
^ permalink raw reply
* Re: Getting Ensimag students to work on Git for a few weeks
From: Matthieu Moy @ 2009-10-27 15:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910271456490.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Tue, 27 Oct 2009, Matthieu Moy wrote:
>
>> I'd like to propose a kind of mini-google summer of code to the students
>> of the the school where I teach, i.e. Ensimag, France (
>> http://ensimag.grenoble-inp.fr/ ). In short, this means having a few
>> students working for Git for a month at no cost ;-).
>
> Do not underestimate the cost of time and nerves, both on the student's
> and the mentor's part.
Hey, you're talking to a teacher ;-).
Yes, for sure, this takes a lot of time. But on my side that's my job,
the school gives me time to mentor the students. And I'll be
geographically close to the students, having regular physical
meetings, ... I'd appreciate a co-mentor, but the feedback from the
mailing list (like the one for non-school-related contributors) plus
my mentoring can be sufficient.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Erik Faye-Lund @ 2009-10-27 15:50 UTC (permalink / raw)
To: Baz; +Cc: Git Mailing List
In-Reply-To: <2faad3050910270817l71394722nda55265ed96722df@mail.gmail.com>
On Tue, Oct 27, 2009 at 4:17 PM, Baz <brian.ewins@gmail.com> wrote:
> I've got a somewhat related minor usability issue with rebase -i. I
> accidentally typed something like 'git rebase -i -z' and got this
> message:
>
> error: unknown switch `z'
> usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
> or: git-rebase [-i] (--continue | --abort | --skip)
>
> Available options are
> -v, --verbose display a diffstat of what changed upstream
> --onto ... rebase onto given branch instead of upstream
> -p, --preserve-merges
> try to recreate merges instead of ignoring them
> -s, --strategy ... use the given merge strategy
> -m, --merge always used (no-op)
> -i, --interactive always used (no-op)
>
> The last two lines were the surprise. It suggested to me that '-i' and
> '-m' were now the defaults for git-rebase - which of course they're
> not. A user would not know that this is actually reporting the flags
> that work for git-rebase--interactive, especially since that's not
> what the command calls itself. I wasn't sure about the best approach
> to fixing this - the only comparable commands that pass arbitrary
> flags down to an exec'd program make it clear what program is going to
> be called (usually git merge) and so interpreting errors is easier.
>
> It seems the intent here was to signal that the flags are different
> once a rebase is in progress, but this usage message is shown when
> rebase -i -z is called in any state.
If that is the case, my instinct tells me that this information should
be reflected in the usage-string (instead of the parameter
description). Something like this?
--->8---
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..3ed5f94 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -13,15 +13,15 @@
OPTIONS_KEEPDASHDASH=
OPTIONS_SPEC="\
git-rebase [-i] [options] [--] <upstream> [<branch>]
-git-rebase [-i] (--continue | --abort | --skip)
+git-rebase [-i] [-m] (--continue | --abort | --skip)
--
Available options are
v,verbose display a diffstat of what changed upstream
onto= rebase onto given branch instead of upstream
p,preserve-merges try to recreate merges instead of ignoring them
s,strategy= use the given merge strategy
-m,merge always used (no-op)
-i,interactive always used (no-op)
+m,merge use merging strategies
+i,interactive interactively edit commits
Actions:
continue continue rebasing process
abort abort rebasing process and restore original branch
--
Erik "kusma" Faye-Lund
^ permalink raw reply related
* Re: Getting Ensimag students to work on Git for a few weeks
From: Hervé Cauwelier @ 2009-10-27 15:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqocntxhzv.fsf@bauges.imag.fr>
On 27/10/2009 11:12, Matthieu Moy wrote:
> Hi,
>
> I'd like to propose a kind of mini-google summer of code to the
> students of the the school where I teach, i.e. Ensimag, France
> ( http://ensimag.grenoble-inp.fr/ ). In short, this means having a few
> students working for Git for a month at no cost ;-).
Have you considered projects contributing to libgit2? The students at
ULCO [1] will be mentored by Andreas Ericsson.
Given that libgit2 is quite empty, there are many small tasks like
starting commits, trees, tags, etc. objects.
But I guess he won't have time for mentoring more students.
[1]
http://dpt-info.univ-littoral.fr/mediawiki/index.php/I2L:Projet#libgit2_-_Herv.C3.A9_Cauwelier_-_itaapy
--
Hervé Cauwelier - ITAAPY - 9 rue Darwin 75018 Paris
Tél. 01 42 23 67 45 - Fax 01 53 28 27 88
http://www.itaapy.com/ - http://www.cms-migration.com
^ permalink raw reply
* Re: [PATCH] gitk: Use the --submodule option for diffs
From: Johannes Schindelin @ 2009-10-27 15:41 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Paul Mackerras, Junio C Hamano, Git Mailing List
In-Reply-To: <4AE70AC9.6040302@web.de>
Hi,
On Tue, 27 Oct 2009, Jens Lehmann wrote:
> Instead of just showing not-quite-helpful SHA-1 pairs display the first
> lines of the corresponding commit messages in the submodule (similar to
> the output of 'git submodule summary').
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> This patch applies to 'next' and uses the new --submodule option of git
> diff to achieve a more meaningful output of submodule differences in
> gitk.
>
> Any objections against making this the default?
Certainly not from me. It would help people in my day-job project.
Ciao,
Dscho
^ permalink raw reply
* Re: possible usability issue in rebase -i?
From: Baz @ 2009-10-27 15:17 UTC (permalink / raw)
To: kusmabite; +Cc: Git Mailing List
In-Reply-To: <40aa078e0910270313j5dc68576v86a3947f0dc7f9f@mail.gmail.com>
2009/10/27 Erik Faye-Lund <kusmabite@googlemail.com>:
> I recently came over a not-overly-helpful error in git rebase -i, when
> a line got wrapped by the editor so that a part of the commit-message
> was interpreted as a command:
>
> ---
> $ git rebase -i HEAD~20
> <edit file>
> Unknown command: .
> fatal: ambiguous argument 'Please fix this in the file C:/msysgit/git/.git/rebas
> e-merge/git-rebase-todo.': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
> fatal: Not a valid object name Please fix this in the file C:/msysgit/git/.git/r
> ebase-merge/git-rebase-todo.
> fatal: bad revision 'Please fix this in the file C:/msysgit/git/.git/rebase-merg
> e/git-rebase-todo.'
>
> $ git --version
> git version 1.6.5.1386.g43a7a.dirty
> ---
>
> In this particular case, the first character on the new line was '.',
> so the first line of the error message makes perfect sense, but the
> lines that followed the real error got me pretty confused. Perhaps
> this is something that could be cleaned away? I'd think that an
> unknown command always should be fatal, and not need to propagate
> further. But I might be wrong, as I'm not familiar with the inner
> workings of rebase -i.
I've got a somewhat related minor usability issue with rebase -i. I
accidentally typed something like 'git rebase -i -z' and got this
message:
error: unknown switch `z'
usage: git-rebase [-i] [options] [--] <upstream> [<branch>]
or: git-rebase [-i] (--continue | --abort | --skip)
Available options are
-v, --verbose display a diffstat of what changed upstream
--onto ... rebase onto given branch instead of upstream
-p, --preserve-merges
try to recreate merges instead of ignoring them
-s, --strategy ... use the given merge strategy
-m, --merge always used (no-op)
-i, --interactive always used (no-op)
The last two lines were the surprise. It suggested to me that '-i' and
'-m' were now the defaults for git-rebase - which of course they're
not. A user would not know that this is actually reporting the flags
that work for git-rebase--interactive, especially since that's not
what the command calls itself. I wasn't sure about the best approach
to fixing this - the only comparable commands that pass arbitrary
flags down to an exec'd program make it clear what program is going to
be called (usually git merge) and so interpreting errors is easier.
It seems the intent here was to signal that the flags are different
once a rebase is in progress, but this usage message is shown when
rebase -i -z is called in any state.
Cheers,
Brian
>
> --
> Erik "kusma" Faye-Lund
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
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