* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Pau Garcia i Quiles @ 2009-09-25 21:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0909250810270.4985@pacific.mpi-cbg.de>
Hello,
Sorry if I'm asking something obvious but, what's the
"offical"language of Gittogether Europe ? English ? German ?
On Fri, Sep 25, 2009 at 8:19 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> as some of you already know, I will be unable to Git Together with other
> Gits in California this year. So the only version of such a Git Together
> I will have this year is the Berlin one.
>
> Details: it will take place on October 3rd, 2009, at the Zuse-Institut
> Berlin: http://www.zib.de/besucher/index.en.html (graciously offered by
> Steffen Prohaska).
>
> We will have a room with fast internet connection and a beamer.
>
> As for the schedule: I had something like this in mind:
>
> 10:00 Saying hello to everybody
> 10:30 Dscho says something about the history of msysGit
> 11:00 Somebody else talks about something else
> 11:30 ...
> ...
>
> After the talks, maybe a little hackathon-style coding (I know what I
> would like to implement, but let's just see what happens).
>
> In the evening, we probably order pizza or go to a restaurant nearby.
>
> See also http://git.or.cz/gitwiki/GitTogether
>
> Ciao,
> Dscho
>
> --
> 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
>
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* [PATCH] fix obscure perl message when encryption=tls and smtp cannot connect.
From: iler.ml @ 2009-09-25 21:30 UTC (permalink / raw)
To: git; +Cc: iler.ml
When encryption=tls and smtp cannot connect, git-send-email prints following perl error:
Can't call method "command" on an undefined value at /usr/local/libexec/git-core/git-send-email line 927.
(ithis is when smtp host orport is misspelled, or network is down, and encryption is tls).
We expect some familiar "Cannot connect to SERVER:PORT" message.
Fix it to print normal "smtp can't connect" diagnostics.
--- /usr/local/libexec/git-core/git-send-email.000 2009-09-26 00:10:01.000000000 +0300
+++ /usr/local/libexec/git-core/git-send-email 2009-09-26 00:11:39.000000000 +0300
@@ -922,7 +922,7 @@
$smtp ||= Net::SMTP->new((defined $smtp_server_port)
? "$smtp_server:$smtp_server_port"
: $smtp_server);
- if ($smtp_encryption eq 'tls') {
+ if ($smtp_encryption eq 'tls' && $smtp) {
require Net::SMTP::SSL;
$smtp->command('STARTTLS');
$smtp->response();
^ permalink raw reply
* Re: [JGIT PATCH 1/9] mavenizing step 1: moved over the initial poms from Jasons branch Signed-off-by: Mark Struberg <struberg@yahoo.de>
From: Robin Rosenberg @ 2009-09-25 21:33 UTC (permalink / raw)
To: Mark Struberg; +Cc: git, spearce, Jason van Zyl
In-Reply-To: <1253740570-10718-1-git-send-email-struberg@yahoo.de>
Where are the 0/9 and 2/9 mails?
-- robin
^ permalink raw reply
* Re: [PATCH] fix obscure perl message when encryption=tls and smtp cannot connect.
From: Shawn O. Pearce @ 2009-09-25 21:34 UTC (permalink / raw)
To: iler.ml; +Cc: git
In-Reply-To: <1253914213-22274-1-git-send-email-iler.ml@gmail.com>
iler.ml@gmail.com wrote:
> When encryption=tls and smtp cannot connect, git-send-email prints following perl error:
>
> Can't call method "command" on an undefined value at /usr/local/libexec/git-core/git-send-email line 927.
>
> (ithis is when smtp host orport is misspelled, or network is down, and encryption is tls).
> We expect some familiar "Cannot connect to SERVER:PORT" message.
> Fix it to print normal "smtp can't connect" diagnostics.
Thanks, looks reasonable. Signed-off-by line, per the Developer's
Certificate of Origin in Documentation/SubmittingPatches ?
> --- /usr/local/libexec/git-core/git-send-email.000 2009-09-26 00:10:01.000000000 +0300
> +++ /usr/local/libexec/git-core/git-send-email 2009-09-26 00:11:39.000000000 +0300
> @@ -922,7 +922,7 @@
> $smtp ||= Net::SMTP->new((defined $smtp_server_port)
> ? "$smtp_server:$smtp_server_port"
> : $smtp_server);
> - if ($smtp_encryption eq 'tls') {
> + if ($smtp_encryption eq 'tls' && $smtp) {
> require Net::SMTP::SSL;
> $smtp->command('STARTTLS');
> $smtp->response();
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fix obscure perl message when encryption=tls and smtp cannot connect.
From: Yakov Lerner @ 2009-09-25 21:39 UTC (permalink / raw)
To: Git Mailing List, Shawn O. Pearce
In-Reply-To: <20090925213440.GX14660@spearce.org>
On Sat, Sep 26, 2009 at 00:34, Shawn O. Pearce <spearce@spearce.org> wrote:
>
> iler.ml@gmail.com wrote:
> > When encryption=tls and smtp cannot connect, git-send-email prints following perl error:
> >
> > Can't call method "command" on an undefined value at /usr/local/libexec/git-core/git-send-email line 927.
> >
> > (ithis is when smtp host orport is misspelled, or network is down, and encryption is tls).
> > We expect some familiar "Cannot connect to SERVER:PORT" message.
> > Fix it to print normal "smtp can't connect" diagnostics.
>
> Thanks, looks reasonable. Signed-off-by line, per the Developer's
> Certificate of Origin in Documentation/SubmittingPatches ?
Signed-off-by: Yakov Lerner <iler.ml@gmail.com>
>
> > --- /usr/local/libexec/git-core/git-send-email.000 2009-09-26 00:10:01.000000000 +0300
> > +++ /usr/local/libexec/git-core/git-send-email 2009-09-26 00:11:39.000000000 +0300
> > @@ -922,7 +922,7 @@
> > $smtp ||= Net::SMTP->new((defined $smtp_server_port)
> > ? "$smtp_server:$smtp_server_port"
> > : $smtp_server);
> > - if ($smtp_encryption eq 'tls') {
> > + if ($smtp_encryption eq 'tls' && $smtp) {
> > require Net::SMTP::SSL;
> > $smtp->command('STARTTLS');
> > $smtp->response();
>
Yakov
^ permalink raw reply
* Re: [JGIT PATCH 7/9] removing eclipse project files
From: Robin Rosenberg @ 2009-09-25 21:40 UTC (permalink / raw)
To: Mark Struberg; +Cc: Ferry Huberts, git, spearce
In-Reply-To: <314006.37617.qm@web27808.mail.ukl.yahoo.com>
torsdag 24 september 2009 08:55:16 skrev Mark Struberg <struberg@yahoo.de>:
> Hi Ferry!
>
> I work on a lot of projects and having eclipse (or any other IDEs) project files in the SCM is almost ever causing a problem. In praxis those files are always dirty. There are so many settings which may be different from user to user
>
> * different versions of eclipse create different project settings
> * different JVM settings
> * changing profiler settings
> * using different version of various plugins
> etc, etc
>
> And with maven in place we don't need to have them in our SCM anymore. Plus: it works for a lot of IDEs
>
> You can easily create the project files for a few IDEs with maven e.g.:
> $> mvn eclipse:eclipse for creating the eclipse project files
> $> mvn idea:idea for creating the idea project files
>
> Additionally, plugins are available for Eclipse [1], Intellij Idea (native, builtin) and NetBeans (native, builtin).
>
> So most of the time it is enough to simply import the parent pom.xml and you get all things setup properly in your IDE.
I want compiler warnings/error and formatting settings to be enforced. Until recently we had roughly zero problems with non-confirming submissions
Is there some means for this, even if that would mean having access to only
a subset of possible settings. Maybe using checkstyle would do it for the
style checks. Not sure how we'd control formatting.
-- robin
^ permalink raw reply
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Sverre Rabbelier @ 2009-09-25 21:59 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Johannes Schindelin, git
In-Reply-To: <3af572ac0909251429n3d002b58y9815711a258a2b90@mail.gmail.com>
Heya,
On Fri, Sep 25, 2009 at 23:29, Pau Garcia i Quiles <pgquiles@elpauer.org> wrote:
> Sorry if I'm asking something obvious but, what's the
> "offical"language of Gittogether Europe ? English ? German ?
English methinks, as you probably don't want to hear me speaking German :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Robin Rosenberg @ 2009-09-25 22:03 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: Johannes Schindelin, git
In-Reply-To: <3af572ac0909251429n3d002b58y9815711a258a2b90@mail.gmail.com>
fredag 25 september 2009 23:29:37 skrev Pau Garcia i Quiles <pgquiles@elpauer.org>:
> Hello,
>
> Sorry if I'm asking something obvious but, what's the
> "offical"language of Gittogether Europe ? English ? German ?
Something that ends with -ish seems natural, doesn't it?
-- robin
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Shawn O. Pearce @ 2009-09-25 22:05 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, mstormo
In-Reply-To: <4ABB84F4.7080403@gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> wrote:
> From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
> From: Sebastian Schuberth <sschuberth@gmail.com>
> Date: Thu, 24 Sep 2009 15:52:25 +0200
> Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
>
> In order to be able to open the generated solution file by double-clicking it
> in Windows Explorer, all project files need to use DOS line-endings and a
> comment about the Visual Studio version needs to be added to the header of the
> solution file. This also fixes the icon that is displayed for the solution file
> in Windows Explorer.
> Note that opening the solution file from a running instance of Visual Studio
> already worked before.
Something is wrong with both patches; neither applies. It looks
to be an issue with whitespace, like context lines are gaining an
extra space at the start of the line.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Alex Riesen @ 2009-09-25 22:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sebastian Schuberth, git, mstormo
In-Reply-To: <20090925220510.GY14660@spearce.org>
On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>> In order to be able to open the generated solution file by double-clicking it
>> in Windows Explorer, all project files need to use DOS line-endings and a
>> comment about the Visual Studio version needs to be added to the header of the
>> solution file. This also fixes the icon that is displayed for the solution file
>> in Windows Explorer.
>> Note that opening the solution file from a running instance of Visual Studio
>> already worked before.
>
> Something is wrong with both patches; neither applies. It looks
> to be an issue with whitespace, like context lines are gaining an
> extra space at the start of the line.
Besides, there is PERLIO environment variable. Try setting it to
PERLIO=':perlio'
^ permalink raw reply
* Re: git stash list shows timestamp in stead of "stash number", when setting date = local for log in config
From: Shawn O. Pearce @ 2009-09-25 22:29 UTC (permalink / raw)
To: Jeff King; +Cc: Alf Kristian St??yle, git
In-Reply-To: <20090924070121.GD24486@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Tue, Sep 15, 2009 at 04:56:41PM +0200, Alf Kristian St??yle wrote:
> > When doing a "git stash list" I get this strange stash record:
> > stash@{Tue Sep 15 16:28:12 2009}: WIP on master: 2262276 ...
> >
> > I have a global config setting on log:
> >
> > [log]
> > date = local
> >
> > If setting the date config to default or removing the setting, the
> > stash record looks correct:
> > stash@{0}: WIP on master: 2262276 ...
>
> The patch below implements the former. The only downside I can think of
> is if somebody is relying on "log.date" to set the output format for
> reflogs, because they really like the date version better. In that case,
> I think we should wait for them to complain (which I doubt will happen),
> and then add a log.reflogDates config option to appease them.
>
> Shawn, reflogs are your thing. Any comments?
I agree. I doubt anyone is relying on log.date to reformat the
output of `git reflog show` or `git stash list`, so this is probably
a reasonable change to make. Even if they were trying to use that,
its a bug.
Care to wrap this up in a patch?
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-25 22:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, mstormo
In-Reply-To: <20090925220510.GY14660@spearce.org>
On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>> From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
>> From: Sebastian Schuberth <sschuberth@gmail.com>
>> Date: Thu, 24 Sep 2009 15:52:25 +0200
>> Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
>>
>> In order to be able to open the generated solution file by double-clicking it
>> in Windows Explorer, all project files need to use DOS line-endings and a
>> comment about the Visual Studio version needs to be added to the header of the
>> solution file. This also fixes the icon that is displayed for the solution file
>> in Windows Explorer.
>> Note that opening the solution file from a running instance of Visual Studio
>> already worked before.
>
> Something is wrong with both patches; neither applies. It looks
> to be an issue with whitespace, like context lines are gaining an
> extra space at the start of the line.
Hmm, the patches apply fine onto master for me.
As a side note, I've never liked sending patches via mail. It just
feels like writing a text on a computer just to print it out, scan in
the sheet again, and then sending the scanned image as an attachment
via email. Isn't there a better way to contribute patches to Git, like
pushing to a mob branch as for the msysGit project?
--
Sebastian Schuberth
^ permalink raw reply
* Re: [JGIT PATCH 1/2] add support for core.logAllRefUpdates configuration parameter
From: Robin Rosenberg @ 2009-09-25 22:45 UTC (permalink / raw)
To: Halstrick, Christian; +Cc: Shawn O. Pearce, git@vger.kernel.org
In-Reply-To: <D35B4A582834DC418CCF9AF41AB69B70016953F62F@DEWDFECCR04.wdf.sap.corp>
onsdag 23 september 2009 18:42:29 skrev "Halstrick, Christian" <christian.halstrick@sap.com>:
> From: Christian Halstrick <christian.halstrick@sap.com>
>
> JGit should understand configuration parameter logAllRefUpdates and should
> only log updates of refs when
> either the log file for this ref is already present
> or this configuration parameter is set to true
> Before this commit JGit was always writing logs, regardless of this
> parameter or existence of logfiles.
A few minor things:
Format the comment nicely and space betwee paragraphs.
Start the comment with a capital letter
A cover letter for multiple patches is nice, though in this case you could
actually just squash there patches into one patch.
and one major.
RefUpdateTest broke.
Probably because of this.
> + logAllRefUpdates = rc.getBoolean("core", "logAllRefUpdates", false);
According to the git-config man page logAllRefUpdates is true by default for non-bare
repos and false for bare repos.
I had some trouble applying these patches as git-am did not like them. Apparently
git-am doesn't like base64. Could you set your mailer to use a more plain-ish format
or use git-send-email.
-- robin
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-25 22:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: Shawn O. Pearce, git, mstormo
In-Reply-To: <81b0412b0909251511m24e5c6bcg3f8c4e3576ad3bd3@mail.gmail.com>
On Sat, Sep 26, 2009 at 00:11, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>>> In order to be able to open the generated solution file by double-clicking it
>>> in Windows Explorer, all project files need to use DOS line-endings and a
>>> comment about the Visual Studio version needs to be added to the header of the
>>> solution file. This also fixes the icon that is displayed for the solution file
>>> in Windows Explorer.
>>> Note that opening the solution file from a running instance of Visual Studio
>>> already worked before.
>>
>> Something is wrong with both patches; neither applies. It looks
>> to be an issue with whitespace, like context lines are gaining an
>> extra space at the start of the line.
>
> Besides, there is PERLIO environment variable. Try setting it to
> PERLIO=':perlio'
But I don't feel like using it here would be the right thing to do.
Visual Studio project files should never ever be written out with Unix
line-endings, not even if someone created them under Unix. So instead
of relying on the environment variable to be set correctly, I believe
it's better to always enforce the correct line-endings here.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [JGIT PATCH 1/2] add support for core.logAllRefUpdates configuration parameter
From: Robin Rosenberg @ 2009-09-25 22:52 UTC (permalink / raw)
To: Halstrick, Christian; +Cc: Shawn O. Pearce, git@vger.kernel.org
In-Reply-To: <200909260045.21171.robin.rosenberg@dewire.com>
lördag 26 september 2009 00:45:20 skrev Robin Rosenberg <robin.rosenberg@dewire.com>:
> onsdag 23 september 2009 18:42:29 skrev "Halstrick, Christian" <christian.halstrick@sap.com>:
> > From: Christian Halstrick <christian.halstrick@sap.com>
> >
> > JGit should understand configuration parameter logAllRefUpdates and should
> > only log updates of refs when
> > either the log file for this ref is already present
> > or this configuration parameter is set to true
> > Before this commit JGit was always writing logs, regardless of this
> > parameter or existence of logfiles.
>
> A few minor things:
Forgot: Please:
> Format the comment nicely and space betwee paragraphs.
[...]
-- robin
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Shawn O. Pearce @ 2009-09-25 22:59 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, mstormo
In-Reply-To: <bdca99240909251541h2e9932a3r67c1d8604e56a8df@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> wrote:
> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Something is wrong with both patches; neither applies. ??It looks
> > to be an issue with whitespace, like context lines are gaining an
> > extra space at the start of the line.
>
> Hmm, the patches apply fine onto master for me.
After going through your client and the GMane email gateway?
Or before you pasted it into the message?
> As a side note, I've never liked sending patches via mail. It just
> feels like writing a text on a computer just to print it out, scan in
> the sheet again, and then sending the scanned image as an attachment
> via email. Isn't there a better way to contribute patches to Git, like
> pushing to a mob branch as for the msysGit project?
It works fine, so long as the tools in the chain leave the body
of the message alone and don't try to outsmart the human who put
it there.
The git project in particular as rules about only applying patches
off the mailing list, because then all contributions are in a
permanent, public archive. Its also the form of communication most
contributors prefer for code reviews.
--
Shawn.
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Jason Merrill @ 2009-09-25 23:17 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Matthieu Moy, git, Hin-Tak Leung
In-Reply-To: <alpine.LFD.2.00.0909251629330.4997@xanadu.home>
On 09/25/2009 04:47 PM, Nicolas Pitre wrote:
> Do you have access to the remote machine? Is it possible to have a
> tarball of the gcc.git directory from there?
http://gcc.gnu.org/gcc-git.tar.gz
I'll leave it there for a few days.
Jason
^ permalink raw reply
* how optparse can go horribly wrong
From: Shawn O. Pearce @ 2009-09-25 23:32 UTC (permalink / raw)
To: git
*sigh*. Someone just ran into this today:
$ git commit -a -ammend
[work ce38944] mend
1 files changed, 2 insertions(+), 0 deletions(-)
Omit one - and include an extra 'm', and instead of --amend you
have -a -m mend. Which isn't exactly what you wanted.
We do catch -amend with an error though:
$ git commit -amend
error: did you mean `--amend` (with two dashes ?)
I wonder, should the -m flag on commit not allow cuddling its
value against the switch when its combined in short form with
other switches?
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-25 23:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, mstormo
In-Reply-To: <20090925225940.GB14660@spearce.org>
On Sat, Sep 26, 2009 at 00:59, Shawn O. Pearce <spearce@spearce.org> wrote:
> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > Something is wrong with both patches; neither applies. ??It looks
>> > to be an issue with whitespace, like context lines are gaining an
>> > extra space at the start of the line.
>>
>> Hmm, the patches apply fine onto master for me.
>
> After going through your client and the GMane email gateway?
> Or before you pasted it into the message?
Both. As a test for the first, I've copied & pasted my mail as it
appears for me in gmane.comp.version-control.git to a new file and
successfully applied that file via "git apply". I had to do it this
way, as on Windows I cannot really use "git am" with Thunderbird.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Shawn O. Pearce @ 2009-09-26 0:05 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git, mstormo
In-Reply-To: <bdca99240909251658q395a62b6r8d5998382ac3fc7b@mail.gmail.com>
Sebastian Schuberth <sschuberth@gmail.com> wrote:
> On Sat, Sep 26, 2009 at 00:59, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Sebastian Schuberth <sschuberth@gmail.com> wrote:
> >> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
> >> > Something is wrong with both patches; neither applies.
> >>
> >> Hmm, the patches apply fine onto master for me.
> >
> > After going through your client and the GMane email gateway?
> > Or before you pasted it into the message?
>
> Both. As a test for the first, I've copied & pasted my mail as it
> appears for me in gmane.comp.version-control.git to a new file and
> successfully applied that file via "git apply". I had to do it this
> way, as on Windows I cannot really use "git am" with Thunderbird.
Odd. If I copy and paste from Thunderbird, its fine. But if I
save the body out as an attachment from mutt, it fails.
I wonder if it has to do with the From header appearing in the top
of the body; this header has to be escaped with a leading space in
mbox format. It looks like Thunderbird might be doing some magic to
remove that leading space from the context lines, while mutt isn't.
Next time, don't include the first From line?
--
Shawn.
^ permalink raw reply
* [PATCH] git branch -D: give a better error message when lockfile creation fails
From: Miklos Vajna @ 2009-09-26 0:06 UTC (permalink / raw)
To: git
Previously the old error message just told the user that it was not
possible to delete the ref from the packed-refs file. Give instructions
on how to resolve the problem.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
refs.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 24865cf..221d49c 100644
--- a/refs.c
+++ b/refs.c
@@ -972,8 +972,10 @@ static int repack_without_ref(const char *refname)
if (!found)
return 0;
fd = hold_lock_file_for_update(&packlock, git_path("packed-refs"), 0);
- if (fd < 0)
+ if (fd < 0) {
+ unable_to_lock_index_die(git_path("packed-refs"), errno);
return error("cannot delete '%s' from packed refs", refname);
+ }
for (list = packed_ref_list; list; list = list->next) {
char line[PATH_MAX + 100];
--
1.6.5.rc1.44.ga1675.dirty
^ permalink raw reply related
* Re: git clone sending unneeded objects
From: Hin-Tak Leung @ 2009-09-26 0:43 UTC (permalink / raw)
To: Jason Merrill; +Cc: Nicolas Pitre, Matthieu Moy, git
In-Reply-To: <4ABD25FE.2040902@redhat.com>
On Fri, Sep 25, 2009 at 9:20 PM, Jason Merrill <jason@redhat.com> wrote:
> On 09/25/2009 03:53 PM, Nicolas Pitre wrote:
>>
>> I did reproduce the issue with git:// back when this discussion started.
>> I also asked for more information about the remote which didn't come
>> forth.
>
> Looking back, I only see you asking about the git version on the server,
> which is 1.6.4.
Hmm, I was under the impression from the previous thread that the
server is a bit older and/or have more backward compatible settings to
cater for older git clients?
>
> So again:
>
> git clone git://gcc.gnu.org/git/gcc.git
> (1399509 objects, ~600MB .git dir)
> git gc --prune=now (988906 objects, ~450MB .git dir)
>
> ...then
>
> git clone git://gcc.gnu.org/git/gcc.git --reference $firstclone
> (573401 objects, ~550MB .git dir)
> git fsck (clean)
> git gc --prune=now (5 objects, ~7MB .git dir)
>
> What's going on here?
FWIW, I still have my clone (git://) and do my periodic 'git fetch'
and 'git gc prune=now' (learned my lessons!) and it is currently .git
dir is about 350MB. (from previous discussion the optimal at the time
was about 300MB, so it has grown a bit in the last couple of months).
And thanks everybody for all the discussion and advice. git is a great
tool. (and I have essentially stopped using svn, prefering git-svn!).
^ permalink raw reply
* Re: git clone sending unneeded objects
From: Nicolas Pitre @ 2009-09-26 0:49 UTC (permalink / raw)
To: Jason Merrill; +Cc: Matthieu Moy, git, Hin-Tak Leung
In-Reply-To: <4ABD4F7B.4030701@redhat.com>
On Fri, 25 Sep 2009, Jason Merrill wrote:
> On 09/25/2009 04:47 PM, Nicolas Pitre wrote:
> > Do you have access to the remote machine? Is it possible to have a
> > tarball of the gcc.git directory from there?
>
> http://gcc.gnu.org/gcc-git.tar.gz
>
> I'll leave it there for a few days.
Thanks, I got it now. And I was able to reproduce the issue locally.
Cloning the original repository does transfer objects which become
unreferenced in the clone. But cloning that cloned repository (before
pruning the unreferenced objects) does not transfer those objects again.
Just need to find out why.
Nicolas
^ permalink raw reply
* Re: how optparse can go horribly wrong
From: Nicolas Sebrecht @ 2009-09-26 1:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Nicolas Sebrecht
In-Reply-To: <20090925233226.GC14660@spearce.org>
The 25/09/09, Shawn O. Pearce wrote:
> *sigh*. Someone just ran into this today:
>
> $ git commit -a -ammend
> [work ce38944] mend
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> Omit one - and include an extra 'm', and instead of --amend you
> have -a -m mend. Which isn't exactly what you wanted.
>
> We do catch -amend with an error though:
>
> $ git commit -amend
> error: did you mean `--amend` (with two dashes ?)
OTOH, this is a bit odd because a commit with the message "end" makes
perfect sense for a "fast and crappy commit local workflow".
And we allow -ammend (with two 'm')
$ git commit -ammend
[next 101f014] mend
1 files changed, 1 insertions(+), 0 deletions(-)
$
> I wonder, should the -m flag on commit not allow cuddling its
> value against the switch when its combined in short form with
> other switches?
Doing this only to -m flag would break consistency. That said, I don't
have any opinion in disallowing the sticked form for _all_ short
options.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] git branch -D: give a better error message when lockfile creation fails
From: Jeff King @ 2009-09-26 3:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1253923602-17818-1-git-send-email-vmiklos@frugalware.org>
On Sat, Sep 26, 2009 at 02:06:42AM +0200, Miklos Vajna wrote:
> diff --git a/refs.c b/refs.c
> index 24865cf..221d49c 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -972,8 +972,10 @@ static int repack_without_ref(const char *refname)
> if (!found)
> return 0;
> fd = hold_lock_file_for_update(&packlock, git_path("packed-refs"), 0);
> - if (fd < 0)
> + if (fd < 0) {
> + unable_to_lock_index_die(git_path("packed-refs"), errno);
> return error("cannot delete '%s' from packed refs", refname);
> + }
>
> for (list = packed_ref_list; list; list = list->next) {
> char line[PATH_MAX + 100];
I have several concerns about this patch:
1. We used to return error(), but now we die. Are there any callers
which care about the difference?
2. If we did want to die, then the "return error()" just below is
unreachable, and should be removed.
3. If we did want to die, should we not just pass LOCK_DIE_ON_ERROR to
hold_lock_file_for_update?
I suspect (2) and (3) are irrelevant because the answer to (1) is that
yes, some callers do care (e.g., it looks like builtin-remote calls
delete_ref, and notes an error but continues to do useful work
afterwards). So probably you would need to first refactor
unable_to_lock_index_die() to handle just printing the error without
dying.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox