* Re: git vs hg commit counts?
From: Marti Raudsepp @ 2009-10-27 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joe Perches, LKML, git, mercurial
In-Reply-To: <7v8wexd6zq.fsf@alter.siamese.dyndns.org>
On Tue, Oct 27, 2009 at 2:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> We simplify a merge history by discarding one branch when the merge result
> matches one of the parents. Does "hg" know how to do that as well?
57 of the differing changesets are normal merges (probably what Junio explained)
3 are duplicate changesets in hg, probably also related to that
27 changesets are octopus merge fixups
wrt octopus merges: in git, one merge commit can have an arbitrary
number of parents, but in hg a merge changeset always has 2 parents --
so a octopus merge is represented as multiple distinct changesets.
Marti
^ permalink raw reply
* Re: [PATCH] push: support remote branches in guess_ref DWIM
From: Jeff King @ 2009-10-27 1:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wexn34i.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 04:31:57PM -0700, Junio C Hamano wrote:
> As _our_ origin can never be _their_ origin if we are clone of them, I do
> not think anybody sane would expect it to push into refs/remotes/origin/
> to begin with.
OK, I agree.
> But "not in refs/remotes/" does not automatically mean "the only sensible
> place is refs/heads", does it? "We do not know what kind of mistake the
> user is trying to make" could be more plausible answer, and in that case,
> "complain and die" may be a more valid course of action.
The thing is that I can't think of another sensible place. And this
sensible place is useful for one particular action: renaming a remote
branch, like this:
$ git fetch ;# presumably gets origin/branch
$ git push origin/branch:renamed-branch
which is much nicer than exposing clueless users to
":refs/heads/renamed-branch".
> For example,
>
> git push origin origin/master:refs/heads/master
>
> is most likely to be a mistake. The only situation something similar to
> this makes sense is where you pushed out a bogus commit earlier and are
> trying to correct it perhaps with
I'm not sure why it's likely to be a mistake. I've given the one use
case I can think of where you _do_ want to do it. But I'm not sure why
you would accidentally provide something in refs/remotes, or not want to
be pushing to refs/heads. Where _else_ do you push, except for tags?
Am I missing some part of your argument?
> > A related issue (which exists even without this patch) is that doing
> > this:
> >
> > master:remotes/incoming/master
> >
> > will create "refs/heads/remotes/incoming/master". Perhaps we should DWYM
> > a little more and recognize "heads", "remotes", and "tags" as special.
>
> Yes, it is an independent issue; I think correcting this DWIM (or at least
> "warning" if not refusing to create remotes/ under refs/heads/) might be a
> good idea.
OK, I'll try to work up a patch.
-Peff
^ permalink raw reply
* Re: Problems with git am
From: alan @ 2009-10-27 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdi1bqv8.fsf@alter.siamese.dyndns.org>
On Mon, 26 Oct 2009, Junio C Hamano wrote:
> "Alan" <alan@clueserver.org> writes:
>
>> The header of the patch looks like:
>>
>> commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
>> Author: Joe Example <joe@example.com>
>> Date: Wed Sep 19 10:03:47 2009 -0600
>
> It shouldn't.
>
> The format "git am" understands is a mbox file and format-patch is the
> command to write commits out in that form. It should begin with lines
> that look like:
>
> From 610f99ec7d22b5750f12350f67c1341d6be8030f Mon Sep 17 00:00:00 2001
> From: Junio C Hamano <gitster@pobox.com>
> Date: Sun, 25 Oct 2009 18:41:09 -0700
> Subject: [PATCH] Update draft release notes to 1.6.6
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> .... patch follows here ...
>
> I do not think it is particularly hard to add a new case arm in "am" to
> support "git log" output. It is different from a mbox format in that it
>
> * begins each commit with "commit " marker;
> * has Author: and Date: header that is different from a mailbox;
> * lacks Subject: but makes it part of the message body; and
> * indents the message by 4 places.
>
> Nobody has bothered to do so, probably because nobody needed it.
[Insert long string of profanity cut and pasted from Linus' description of
CVS and Subversion.]
> The easiest, safest and quickest for you right now (meaning, before
> waiting for anybody to help you by adding a new feature to "am") would be
> to see if it is possible for you to get the commits re-exported in an
> appropriate format.
I can get them reexported. I may have problems getting them to do that
correctly on a regular basis...
I may have to write the am branch myself.
> I say the "safest" in the above because you _could_ massage what you have
> into a format that looks like a mbox with some Perl script, but it risks
> mismassaging.
Yeah.
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.
What should the correct behaviour be in this case?
--
Truth is stranger than fiction because fiction has to make sense.
^ permalink raw reply
* [PATCH] Prevent git-remote-cvs from segfaulting
From: Sverre Rabbelier @ 2009-10-27 1:43 UTC (permalink / raw)
To: Git List, Junio C Hamano, Jeff King, Daniel Barkalow,
Shawn O. Pearce
Cc: Sverre Rabbelier
In [0] Shawn identified what caused git-remote-cvs from segfaulting,
which should be fixed as desribed in Daniel's reply to that [1].
In the meanwhile, the current patch fixes the issue until Daniel
submits a patch to fix it properly.
[0] http://thread.gmane.org/gmane.comp.version-control.git/130357/focus=130421
[1] http://thread.gmane.org/gmane.comp.version-control.git/130357/focus=131021
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Not-Signed-off-by: Jeff King <peff@peff.net>
---
Jeff wrote this total hack but wants no credit, responsibility or
anything else to do with it whatsoever.
I think it might be nice to have this on top of pu until Daniel
submits a proper patch, so that until that time the test suite
does not segfault.
transport-helper.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 410aa49..d867abb 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -68,6 +68,8 @@ static struct child_process *get_helper(struct transport *transport)
static int disconnect_helper(struct transport *transport)
{
struct helper_data *data = transport->data;
+ if(!data)
+ return 0;
if (data->helper) {
write_str_in_full(data->helper->in, "\n");
close(data->helper->in);
@@ -78,6 +80,7 @@ static int disconnect_helper(struct transport *transport)
free(data->helper);
data->helper = NULL;
}
+ transport->data = NULL;
free(data);
return 0;
}
--
1.6.5.1.125.g76b2.dirty
^ permalink raw reply related
* Re: Problems with git am
From: Junio C Hamano @ 2009-10-27 2:31 UTC (permalink / raw)
To: alan; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0910261836570.15106@blackbox.fnordora.org>
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.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Stephen Boyd @ 2009-10-27 2:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <7vocntd7vt.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> If we are going to do this, wouldn't it make more sense to revert the
> rename of the script, so that people can keep relying on the name of the
> script being "git-completion.bash", _but_ make it produce a pre-compiled
> form to a separate file when invoked in some particular way?
Wouldn't relying on "git-completion.bash" to produce the pre-compiled
form cause problems if someone is running the build on a bash-less
system? I thought this issue was already raised by Shawn.
I guess we could ignore that issue now, and just say that you have to
build the pre-compiled form on systems with bash?
>
> Then at the runtime:
>
> (0) If the script notices that it has already learned the command list
> it uses it; otherwise,
>
> (1) If the script notices that there is a file that contains the command
> list, it sources it; otherwise,
>
> (2) The script lazily builds the command list for its own use.
>
> And at the buildtime, Makefile can run the script in "generation mode",
> and install the output to where (1) above expects to see.
I assume you're suggesting this to ease the upgrade path for users. It
works nicely, we could just install the generated lists in the same path
(contrib/completion/) and then users would be free to copy the two files
anywhere as long as they're in the same directory. The only downside I
see is there's now two files, but that's ok with me.
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Nanako Shiraishi @ 2009-10-27 3:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Sam Vilain, git
In-Reply-To: <20091020211637.GA32474@dcvr.yhbt.net>
Quoting Eric Wong <normalperson@yhbt.net>
> Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
>> This series adds support for converting SVN merges - in the two
>> popular formats, SVK and SVN 1.5+, into git parents.
>
> Thanks Sam,
>
> There's a couple of whitespace issues with lines being too long (using 8
> character wide tabs). Otherwise I'm happy to Ack and get them out for
> more testing/exposure; especially since I'm unlikely to exercise the
> functionality myself[1] and doesn't appear to break anything.
>
> Thanks again.
What is the status of this series and what should happen now?
Will Eric add his Ack and send you a pull request, or will you fix
them up, forge Eric's Ack and start cooking in your 'next' branch?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Nanako Shiraishi @ 2009-10-27 3:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sean Estabrooks, Nicolas Pitre, Jeff King, Junio C Hamano,
Daniel Barkalow, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910262317430.4985@pacific.mpi-cbg.de>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>
> On Sat, 17 Oct 2009, Sean Estabrooks wrote:
>
>> On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> > Just recently, I had a user request (a very valid one, mind you) where
>> > the user does not want to provide a commit message, and wants to just
>> > commit all the current changes. In that particular case, it is very
>> > sensible to ask for these things. It is something utterly simple to
>> > ask for. Yet, it is utterly hard with Git, especially if I have to
>> > explain it.
>>
>> Hey Johannes,
>>
>> It's actually easy, but maybe hard to find:
>>
>> $ git commit --cleanup=verbatim -m ""
>
> Of course that leaves out the main part. But it is simple once you
> know it (I did not): git add -A (we even went out of our way _not_ to name
> the long option --addremove, but --all -- it does not seem to be an
> expressive-enough option name to me, but what does my impression
> matter...)
>
> So I retract my claim that it is utterly hard to do with Git (but not the
> rest).
Last week, Junio gave this comment to your message.
> I suspect the above is another example of your needing to do
> a better job explaining yourself here, but from "just commit
> all the changes without saying message", my knee-jerk
> reaction is "git commit -a -m 'no message'".
> You would need to justify why -m 'no message' does not fit
> the bill better than just saying "is very sensible to ask for
> these things", as I highly suspect that I misunderstood what
> "these things" are in your five lines to come up with that
> "solution" that you are now going to explain why that is not
> what the end user wanted. And in this case, I do not think
> it is that me being disconnected from the real world, but
> that your explanation is insufficient.
I'm also curious about the situation when a commit with no message
is useful, but unfortunately I don't think I saw you explained
clearly enough what this user request wanted to achieve or what
"these things" in your message were for us to understand why it is
a sensible and valid thing to ask. Did I miss some messages in the
thread?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] Fix resource leaks in wrapper.c
From: Laszlo Papp @ 2009-10-27 3:53 UTC (permalink / raw)
To: git; +Cc: Laszlo Papp
Fix the following issues with the desired close tags:
[wrapper.c:276]: (error) Resource leak: fd
[wrapper.c:291]: (error) Resource leak: fd
Signed-off-by: Laszlo Papp <djszapi@archlinux.us>
---
wrapper.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/wrapper.c b/wrapper.c
index c9be140..76ecf0a 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit, const char *pattern)
fd = mkstemp(template);
if (0 <= fd)
return fd;
-
+ close(fd);
/* slow path */
/* some mkstemp implementations erase template on failure */
snprintf(template, limit, "%s/%s",
@@ -284,7 +284,7 @@ int odb_pack_keep(char *name, size_t namesz, unsigned char *sha1)
fd = open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
if (0 <= fd)
return fd;
-
+ close(fd);
/* slow path */
safe_create_leading_directories(name);
return open(name, O_RDWR|O_CREAT|O_EXCL, 0600);
--
1.6.5
^ permalink raw reply related
* Re: git vs hg commit counts?
From: Joe Perches @ 2009-10-27 4:14 UTC (permalink / raw)
To: Marti Raudsepp; +Cc: Junio C Hamano, LKML, git, mercurial
In-Reply-To: <54b33ccd0910261816x3c49d4ccr60a80a88dd4cfac9@mail.gmail.com>
On Tue, 2009-10-27 at 03:16 +0200, Marti Raudsepp wrote:
> On Tue, Oct 27, 2009 at 2:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > We simplify a merge history by discarding one branch when the merge result
> > matches one of the parents. Does "hg" know how to do that as well?
>
> 57 of the differing changesets are normal merges (probably what Junio explained)
> 3 are duplicate changesets in hg, probably also related to that
> 27 changesets are octopus merge fixups
>
> wrt octopus merges: in git, one merge commit can have an arbitrary
> number of parents, but in hg a merge changeset always has 2 parents --
> so a octopus merge is represented as multiple distinct changesets.
Thanks.
For hg support in get_maintainers, it's probably
simplest to ignore the delta in number of commits
as "close enough".
^ permalink raw reply
* Re: gti push interface inconsistency
From: Eugene Sajine @ 2009-10-27 4:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veiopd7gs.fsf@alter.siamese.dyndns.org>
>
> Probably because git is not smart enough to understand the human language
> to notice 't' 'a' 'g' is a tag and cannot be a remote name spelled
> incorrectly, or git cannot read your mind and find out that you spelled
> a name of the remote correctly but forgot to add the remote first.
>
;)
did you mean It is not smart enough yet?
My question was caused only by the fact that in both situations same
object type is transmitted to the origin repo. As understand that it
was done this way in order to avoid specifying keys for remote...
I.e. "git push origin master" is kinda easier then something like "git
push -r origin master" (-r for remote).
But if for "git push --tags" the remote is not important (uses origin
by default) why it is important for "git push my_tag" or for "git push
origin master"?
Do you think
$ git push master
Which would default to origin have a chance to exist? (I would vote for this)
Or the correct aproach is to have
$ git push origin --tags
IMHO, In any case the push operation interface should be consistent.
Else it is a bit confusing (untill you didn't step on it and didn't
learn the difference).
Best regards,
Eugene
^ permalink raw reply
* [PATCH] Fix memory leak in transport-helper
From: Daniel Barkalow @ 2009-10-27 4:55 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, Johan Herland, Nanako Shiraishi, Sverre Rabbelier,
git
In-Reply-To: <20091015204543.GP10505@spearce.org>
On Thu, 15 Oct 2009, Shawn O. Pearce wrote:
> The disconnect_helper function is not prepared to be called twice:
>
> static int disconnect_helper(struct transport *transport)
> {
> struct helper_data *data = transport->data;
> if (data->helper) {
> ...
> }
> free(data);
> return 0;
> }
Actually, my version just leaks transport->data; it looks like the
"free(data);" line comes from your patch "remote-helpers: Support custom
transport options". Here's a version (against origin/master) that neither
leaks memory nor frees too much for disconnecting temporarily.
commit 8731d804c20828d20130e286f088613b5d33d57a
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Tue Oct 27 00:42:16 2009 -0400
Fix memory leak in helper method for disconnect.
Since some cases may need to disconnect from the helper and reconnect,
wrap the function that just disconnects in a function that also frees
transport->data.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
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;
+}
+
static int fetch_with_fetch(struct transport *transport,
int nr_heads, const struct ref **to_fetch)
{
@@ -163,6 +170,6 @@ int transport_helper_init(struct transport *transport, const char *name)
transport->data = data;
transport->get_refs_list = get_refs_list;
transport->fetch = fetch;
- transport->disconnect = disconnect_helper;
+ transport->disconnect = close_helper;
return 0;
}
^ permalink raw reply related
* Re: [PATCH ef/msys-imap] mingw: use BLK_SHA1 again
From: Johannes Sixt @ 2009-10-27 6:56 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano
Cc: msysgit, git, Erik Faye-Lund, Junio C Hamano, Marius Storm-Olsen
In-Reply-To: <alpine.DEB.1.00.0910262324350.4985@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> For better visibility, I pushed it to the work/msys-imap branch in
> 4msysgit.git (but I could not even compile-test it today, due to lack of
> access to a Windows machine).
>
> If nobody complains by the end of the week, I will merge it into
> 4msysgit.git's 'devel' branch (I can only compile-test by then).
Ugh, I totally forgot: I have this branch ready for Junio to pull:
git://repo.or.cz/git/mingw/j6t.git ef/imap-send-windows
Only the top 3 commits are different from what is currently in pu: I added
my ACK, and reworded the commit message of my patch that is at the tip.
Content-wise it is identical to the series in pu.
I haven't seen an ACK from Marius regarding the changes that touch MSVC
parts, but there was plenty of time to test, and the changes look obvious
enough.
Junio, please pull.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Fix resource leaks in wrapper.c
From: Johannes Sixt @ 2009-10-27 7:13 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git, Laszlo Papp
In-Reply-To: <1256615635-4940-1-git-send-email-djszapi@archlinux.us>
Laszlo Papp schrieb:
> @@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit, const char *pattern)
> fd = mkstemp(template);
> if (0 <= fd)
> return fd;
> -
> + close(fd);
Sorry, where is here a resource leak? You are "closing" something that was
never opened because fd is less than zero.
Ditto for the other case.
-- Hannes
^ permalink raw reply
* Re: git-svn: add support for merges during 'git svn fetch'
From: Eric Wong @ 2009-10-27 7:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Sam Vilain, git
In-Reply-To: <20091027124056.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Eric Wong <normalperson@yhbt.net>
> > Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> >> This series adds support for converting SVN merges - in the two
> >> popular formats, SVK and SVN 1.5+, into git parents.
> >
> > Thanks Sam,
> >
> > There's a couple of whitespace issues with lines being too long (using 8
> > character wide tabs). Otherwise I'm happy to Ack and get them out for
> > more testing/exposure; especially since I'm unlikely to exercise the
> > functionality myself[1] and doesn't appear to break anything.
> >
> > Thanks again.
>
> What is the status of this series and what should happen now?
>
> Will Eric add his Ack and send you a pull request, or will you fix
> them up, forge Eric's Ack and start cooking in your 'next' branch?
Thanks for the ping, I got sidetracked and forgot about this. I've
fixed up minor formatting details, acked and pushed out Sam's changes to
git://git.bogomips.org/git-svn along with one I small fix I originally
sent out a bad patch for.
Eric Wong (1):
git svn: fix fetch where glob is on the top-level URL
Sam Vilain (5):
git-svn: add test data for SVK merge, with script.
git-svn: allow test setup script to support PERL env. var
git-svn: convert SVK merge tickets to extra parents
git-svn: add test data for SVN 1.5+ merge, with script.
git-svn: convert SVN 1.5+ / svnmerge.py svn:mergeinfo props to parents
(tests pass on the same box where I have my latest code this time :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix resource leaks in wrapper.c
From: Michael J Gruber @ 2009-10-27 8:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Laszlo Papp, git, Laszlo Papp
In-Reply-To: <4AE69DA7.6030704@viscovery.net>
Johannes Sixt venit, vidit, dixit 27.10.2009 08:13:
> Laszlo Papp schrieb:
>> @@ -266,7 +266,7 @@ int odb_mkstemp(char *template, size_t limit, const char *pattern)
>> fd = mkstemp(template);
>> if (0 <= fd)
>> return fd;
>> -
>> + close(fd);
>
> Sorry, where is here a resource leak? You are "closing" something that was
> never opened because fd is less than zero.
>
> Ditto for the other case.
I guess it's about silencing some challenged code analysis tool. I
recall that last time we had something like this we decided that coders
are smarter than tools... and also that clean up like this (for real
leaks) would be something for libgit.
Michael
^ permalink raw reply
* Re: git update --prune issue
From: Michael J Gruber @ 2009-10-27 8:42 UTC (permalink / raw)
To: Jeffrey Middleton; +Cc: git
In-Reply-To: <4389ce950910261508p7eca354el77bad07305a80952@mail.gmail.com>
Jeffrey Middleton venit, vidit, dixit 26.10.2009 23:08:
> I have an unreliable problem when using "git remote update --prune".
> git claims that many refs from a particular remote do not point to a
> valid object, but only after finishing another update. I've included
> a shortened version of the output from one particular instance of the
> issue. Note that the errors are printed for every subsequent remote
> as well. However, after the update is completed, everything is fine.
>
> It seems to only happen when there are non-fast-forward changes (new
> branch, forced update, pruned branch). The issue only happens with
> this particular remote, which I've tried removing and recreating, and
> is the same type of remote as all my others (another user's
> NFS-mounted home directory). However, my remotes are all individual
> developers, and this developer is the only one who ever rebases her
> working branches. (recloning the repo from origin and setting up my
> config and remotes all over again has also had no effect)
>
> Unfortunately, I have been unable to reproduce the problem in any test
> repos - for example, though a forced update and a pruned branch in the
> problematic remote along with an update in another remote seems to
> fairly reliably produce the problem in this repo, recreating that
> situation in another repo doesn't cause any problems. Sorry for the
> incomplete bug report, but perhaps this will be enough to go on!
>
> Thanks,
> Jeffrey
>
>
> I've seen the issue in previous versions built from git.git master, as
> well as v1.6.3.3, but for this particular one:
>
> $ git --version
> git version 1.6.5.1.61.ge79999
>
> $ git remote update --prune
> Updating origin
> remote: Counting objects: 42, done.
> remote: Compressing objects: 100% (9/9), done.
> remote: Total 15 (delta 9), reused 12 (delta 6)
> Unpacking objects: 100% (15/15), done.
> From /users/cxtfcm/CxTF_DB
> 88b8613..d40f26d 2009.Q4 -> origin/2009.Q4
> d40f26d..56305b8 dev -> origin/dev
> Updating steph
> remote: Counting objects: 299, done.
> remote: Compressing objects: 100% (241/241), done.
> remote: Total 276 (delta 186), reused 19 (delta 6)
> Receiving objects: 100% (276/276), 41.09 KiB | 10 KiB/s, done.
> Resolving deltas: 100% (186/186), completed with 17 local objects.
> From /users/sdewet/CxTF_DEV/CxTF_DB
> + c2439dd...69cb5c3 beta_gc_dev -> steph/beta_gc_dev (forced update)
> + fb25173...f0e4963 beta_veh_dev -> steph/beta_veh_dev (forced update)
> * [new branch] beta_veh_dev_old -> steph/beta_veh_dev_old
> 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!
> Updating jose
> 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!
> ### many more remotes with the same errors ###
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
Does it depend on the order, i.e.:
git remote update steph
git remote update kevin
git remote prune steph
Does "git fsck --full" say anything special?
Michael
^ permalink raw reply
* more fancy ignoring of files ('if' in .gitignore?)
From: Sebastian Schubert @ 2009-10-27 9:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Hi,
I would like to ignore files if certain other files are present. In my
special case, I want to ignore foo.pdf and foo.eps if foo.fig is
present (both pdf and eps are generated on the fly but don't belong
into repository). In general, I do NOT want to ignore pdf or eps. There
are a lot of foos so I would like to have a general solution.
Is this possible?
Cheers
Sebastian
PS: Please CC my personal email address.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: date change of commit?
From: Alex K @ 2009-10-27 9:41 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq1vkrqttt.fsf@bauges.imag.fr>
Thank you. And how would you use git-filter-branch to create another
branch with a different time stamp? Is it possible to commit under a
different time stamp than the one provided by your default local time?
2009/10/25 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> Alex K <spaceoutlet@gmail.com> writes:
>
>> Hello,
>>
>> Is it possible to change the date of a commit?
>
> See git-filter-branch. This won't change the date of the existing
> commit (which is impossible in Git), but will create another commit
> where only the date has been changed.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
> --
> 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
* Re: more fancy ignoring of files ('if' in .gitignore?)
From: Michael J Gruber @ 2009-10-27 9:56 UTC (permalink / raw)
To: Sebastian Schubert; +Cc: git
In-Reply-To: <200910271030.54571.schubert.seb@googlemail.com>
Sebastian Schubert venit, vidit, dixit 27.10.2009 10:30:
> Hi,
>
> I would like to ignore files if certain other files are present. In my
> special case, I want to ignore foo.pdf and foo.eps if foo.fig is
> present (both pdf and eps are generated on the fly but don't belong
> into repository). In general, I do NOT want to ignore pdf or eps. There
> are a lot of foos so I would like to have a general solution.
>
> Is this possible?
No.
You can script around it by making e.g. your build process (which
generated pdf/eps from fig) add a specific foo.pdf etc to .gitignore.
In fact, at the the time you add a fig to your repo you should add (&
commit) corresponding lines to .gitignore. This is the common approach.
Alternatively, you can update your ignore with
rm -f .gitignore;find . -name \*.fig | while read i;do echo -e
${i%fig}pdf "\n" ${i%fig}eps >>.gitignore;done
if you have no other ignore patterns in there. (This is q&d, adjust if
you have spaces in file names or such.)
Michael
^ permalink raw reply
* Re: more fancy ignoring of files ('if' in .gitignore?)
From: Paolo Bonzini @ 2009-10-27 10:00 UTC (permalink / raw)
To: Sebastian Schubert; +Cc: git
In-Reply-To: <200910271030.54571.schubert.seb@googlemail.com>
On 10/27/2009 10:30 AM, Sebastian Schubert wrote:
> Hi,
>
> I would like to ignore files if certain other files are present. In my
> special case, I want to ignore foo.pdf and foo.eps if foo.fig is
> present (both pdf and eps are generated on the fly but don't belong
> into repository). In general, I do NOT want to ignore pdf or eps. There
> are a lot of foos so I would like to have a general solution.
>
> Is this possible?
I suggesting adding to your makefile a rule like
.gitignore: $(wildcard *.fig)
(grep -ve \.pdf$ \.eps$ .gitignore;
for i in $^; do echo $i; done | \
sed -n 's/fig$/eps/p; s/eps$/pdf/p') > .gitignore.tmp
mv .gitignore.tmp .gitignore
Paolo
^ permalink raw reply
* Getting Ensimag students to work on Git for a few weeks
From: Matthieu Moy @ 2009-10-27 10:12 UTC (permalink / raw)
To: git
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 ;-).
Currently, the students have an end-of-year project (in equivalent of
master 1) with the choice between many subjects, some of them being
somehow "real-life" (i.e. actually usefull things), and other being
artificial (i.e. enjoy doing it, and throw it away afterwards).
This year, I'd like to propose a subject "contribution to an existing
free software", and since the one I know best currently is Git, this
would take the form of "contribution to the Git project". I'd see the
practical organization a bit like the google summer of code: chose a
feature (the GSoC proposals on the wiki can be a good source of
inspiration), and implement it with the goal of being eventually
merged upstream. There would be no money involved, but the students
get a grade at the end. I would anyway follow the work of the
students, but a co-mentoring from a Git expert would be great.
The students work full-time for about 3 weeks (May 20th to June 16th),
and are grouped by teams of 2 to 4 students. Given my bandwidth, I
plan to propose only one group of 4 students this year, but we may
scale up later, who knows.
We have plenty of time before this starts, but I'm just sending this
email to get your feeling on it.
Any opinion? Do you like the idea?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* possible usability issue in rebase -i?
From: Erik Faye-Lund @ 2009-10-27 10:13 UTC (permalink / raw)
To: Git Mailing List
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.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* From 200 to 404 to 407.
From: Peter Odéus @ 2009-10-27 10:18 UTC (permalink / raw)
To: git
Hi,
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.
Bug or just me?
^ permalink raw reply
* Making Git easy to use -- without RTFM, was Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-27 10:33 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20091027124156.6117@nanako3.lavabit.com>
Hi,
[culling the Cc: list, as this subthread is probably irrelevant most of
the previous members]
On Tue, 27 Oct 2009, Nanako Shiraishi wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> [actually not, Nanako quoted Junio here, I guess]
>
> > I suspect the above is another example of your needing to do a better
> > job explaining yourself here, but from "just commit all the changes
> > without saying message", my knee-jerk reaction is "git commit -a -m
> > 'no message'".
>
> > You would need to justify why -m 'no message' does not fit the bill
> > better than just saying "is very sensible to ask for these things", as
> > I highly suspect that I misunderstood what "these things" are in your
> > five lines to come up with that "solution" that you are now going to
> > explain why that is not what the end user wanted. And in this case, I
> > do not think it is that me being disconnected from the real world, but
> > that your explanation is insufficient.
>
> I'm also curious about the situation when a commit with no message is
> useful, but unfortunately I don't think I saw you explained clearly
> enough what this user request wanted to achieve or what "these things"
> in your message were for us to understand why it is a sensible and valid
> thing to ask.
I am sure that your creative mind does not need my concrete example to
come up with a situation where an empty commit message is useful.
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.
Sure, some people will now argue that it should be easy to educate that
user to use Git properly. But that is as naive as it would be to try to
educate those people so they know how unrealistic educating users is.
Not because users are not intelligent -- they are -- but because they want
to spend their time in a more efficient manner than to learn how to
operate a version control system.
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.
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