* Re: Deciding between Git/Mercurial
From: Damien Wyart @ 2009-09-28 20:54 UTC (permalink / raw)
To: Anteru; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
Hello,
* Anteru <newsgroups@catchall.shelter13.net> [2009-09-27 14:24]:
> Integration into tools: We're using Trac currently, which also has
> a nice binding to Mercurial (well, obviously easy to do as Mercurial
> is written in Python, just as Trac itself), while the git support is
> in development and looks quite alpha'ish. Do you plan to make it
> easier to integrate git with other tools by providing bindings to
> other languages, or is this a low-priority issue?
Trac is one of the the most well-known project management tools, but
Indefero is also interesting, and itegrates Git better than Trac:
http://www.indefero.net/
Best,
--
Damien Wyart
^ permalink raw reply
* RE: Alles wird Git, Berlin, Oct 3rd, 2009
From: Johannes Schindelin @ 2009-09-28 18:19 UTC (permalink / raw)
To: Halstrick, Christian; +Cc: git@vger.kernel.org
In-Reply-To: <D35B4A582834DC418CCF9AF41AB69B70016967F825@DEWDFECCR04.wdf.sap.corp>
Hi,
On Mon, 28 Sep 2009, Halstrick, Christian wrote:
> would this also be interesting for developers working on jgit/egit with
> no experience in standard git development?
As far as I am concerned, it is open to everyone who wants to meet some
Gits, even top-posters ;-)
Ciao,
Dscho
^ permalink raw reply
* RE: Alles wird Git, Berlin, Oct 3rd, 2009
From: Halstrick, Christian @ 2009-09-28 15:54 UTC (permalink / raw)
To: Johannes Schindelin, git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0909250810270.4985@pacific.mpi-cbg.de>
Hi,
would this also be interesting for developers working on jgit/egit with no experience in standard git development?
Ciao
Chris
>-----Original Message-----
>From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On Behalf Of Johannes Schindelin
>Sent: Friday, September 25, 2009 8:20 AM
>To: git@vger.kernel.org
>Subject: Alles wird Git, Berlin, Oct 3rd, 2009
>
>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
^ permalink raw reply
* [JGIT PATCH] Add support for logAllRefUpdates configuration parameter
From: Christian Halstrick @ 2009-09-28 15:25 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg
Cc: christian.halstrick, git, Christian Halstrick, Matthias Sohn
From: Christian Halstrick <christian.halstrick@sap.com>
Honor the configuration parameter core.logAllRefUpdates when writing reflogs.
Instead of writing reflog entries always only write reflogs if this parameter
is set to true or if the corresponding file in the <git-dir>/logs directory
already exists. In other words: if you are updating a ref and this parameter is
set to false and there is no file corresponding to your ref in the
<git-dir>/logs folder then no reflog will be written.
This is a fix for the issue http://code.google.com/p/egit/issues/detail?id=4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
---
.../tst/org/spearce/jgit/lib/ReflogConfigTest.java | 116 ++++++++++++++++++++
.../src/org/spearce/jgit/lib/CoreConfig.java | 10 ++
.../src/org/spearce/jgit/lib/RefLogWriter.java | 18 ++--
.../src/org/spearce/jgit/lib/Repository.java | 1 +
4 files changed, 137 insertions(+), 8 deletions(-)
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java
new file mode 100644
index 0000000..7f067c0
--- /dev/null
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/ReflogConfigTest.java
@@ -0,0 +1,116 @@
+/*
+ * Copyright (C) 2009, Christian Halstrick, Matthias Sohn, SAP AG
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+package org.spearce.jgit.lib;
+
+import java.io.IOException;
+
+public class ReflogConfigTest extends RepositoryTestCase {
+ public void testlogAllRefUpdates() throws Exception {
+ long commitTime = 1154236443000L;
+ int tz = -4 * 60;
+ int nrOfReflogs;
+
+ // check how many entries exist in the reflog and turn off writing
+ // reflogs
+ assertTrue(db.getConfig().getCore().isLogAllRefUpdates());
+ nrOfReflogs = db.getReflogReader(Constants.HEAD).getReverseEntries()
+ .size();
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", false);
+
+ // do one commit and check that reflog size is 0: no reflogs should be
+ // written
+ final Tree t = new Tree(db);
+ addFileToTree(t, "i-am-a-file", "and this is the data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ commitTime += 100;
+ assertTrue(
+ "Reflog for HEAD should contain one entry",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == nrOfReflogs);
+
+ // set the logAllRefUpdates parameter to true and check it
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", true);
+ assertTrue(db.getConfig().getCore().isLogAllRefUpdates());
+
+ // do one commit and check that reflog size is increased
+ addFileToTree(t, "i-am-another-file", "and this is other data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ commitTime += 100;
+ assertTrue(
+ "Reflog for HEAD should contain one additional entry",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == nrOfReflogs + 1);
+
+ // set the logAllRefUpdates parameter to false and check it
+ db.getConfig().setBoolean("core", null, "logAllRefUpdates", false);
+ assertFalse(db.getConfig().getCore().isLogAllRefUpdates());
+
+ // do one commit and check that reflog size is 2
+ addFileToTree(t, "i-am-anotheranother-file",
+ "and this is other other data in me\n");
+ commit(t, "A Commit\n", new PersonIdent(jauthor, commitTime, tz),
+ new PersonIdent(jcommitter, commitTime, tz));
+ assertTrue(
+ "Reflog for HEAD should contain two additional entries",
+ db.getReflogReader(Constants.HEAD).getReverseEntries().size() == nrOfReflogs + 2);
+ }
+
+ private void addFileToTree(final Tree t, String filename, String content)
+ throws IOException {
+ FileTreeEntry f = t.addFile(filename);
+ writeTrashFile(f.getName(), content);
+ t.accept(new WriteTree(trash, db), TreeEntry.MODIFIED_ONLY);
+ }
+
+ private void commit(final Tree t, String commitMsg, PersonIdent author,
+ PersonIdent committer) throws IOException {
+ final Commit commit = new Commit(db);
+ commit.setAuthor(author);
+ commit.setCommitter(committer);
+ commit.setMessage(commitMsg);
+ commit.setTree(t);
+ ObjectWriter writer = new ObjectWriter(db);
+ commit.setCommitId(writer.writeCommit(commit));
+
+ int nl = commitMsg.indexOf('\n');
+ final RefUpdate ru = db.updateRef(Constants.HEAD);
+ ru.setNewObjectId(commit.getCommitId());
+ ru.setRefLogMessage("commit : "
+ + ((nl == -1) ? commitMsg : commitMsg.substring(0, nl)), false);
+ ru.forceUpdate();
+ }
+}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java b/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java
index ed3827b..aa52dd4 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/CoreConfig.java
@@ -57,9 +57,12 @@ public CoreConfig parse(final Config cfg) {
private final int packIndexVersion;
+ private final boolean logAllRefUpdates;
+
private CoreConfig(final Config rc) {
compression = rc.getInt("core", "compression", DEFAULT_COMPRESSION);
packIndexVersion = rc.getInt("pack", "indexversion", 2);
+ logAllRefUpdates = rc.getBoolean("core", "logAllRefUpdates", true);
}
/**
@@ -77,4 +80,11 @@ public int getCompression() {
public int getPackIndexVersion() {
return packIndexVersion;
}
+
+ /**
+ * @return whether to log all refUpdates
+ */
+ public boolean isLogAllRefUpdates() {
+ return logAllRefUpdates;
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java
index 4aad809..1e5155c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefLogWriter.java
@@ -112,16 +112,18 @@ private static void appendOneRecord(final ObjectId oldId,
final byte[] rec = Constants.encode(r.toString());
final File logdir = new File(db.getDirectory(), Constants.LOGS);
final File reflog = new File(logdir, refName);
- final File refdir = reflog.getParentFile();
+ if (reflog.exists() || db.getConfig().getCore().isLogAllRefUpdates()) {
+ final File refdir = reflog.getParentFile();
- if (!refdir.exists() && !refdir.mkdirs())
- throw new IOException("Cannot create directory " + refdir);
+ if (!refdir.exists() && !refdir.mkdirs())
+ throw new IOException("Cannot create directory " + refdir);
- final FileOutputStream out = new FileOutputStream(reflog, true);
- try {
- out.write(rec);
- } finally {
- out.close();
+ final FileOutputStream out = new FileOutputStream(reflog, true);
+ try {
+ out.write(rec);
+ } finally {
+ out.close();
+ }
}
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 46b7804..29f4d3e 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -187,6 +187,7 @@ public void create(boolean bare) throws IOException {
cfg.setBoolean("core", null, "filemode", true);
if (bare)
cfg.setBoolean("core", null, "bare", true);
+ cfg.setBoolean("core", null, "logAllRefupdates", !bare);
cfg.save();
}
--
1.6.4.msysgit.0
^ permalink raw reply related
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Sebastian Pipping @ 2009-09-28 14:44 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Petr Baudis, Robert Buchholz
In-Reply-To: <be6fef0d0909280023x46522d91oc786feef23cb226a@mail.gmail.com>
Tay Ray Chuan wrote:
>> i noticed that the atom feeds generated by repo.or.cz's gitweb (e.g.
>> [1]) show no content in firefox 3.5.2. this seems to be due to invalid
>> xml in it as shown by running [1] through feedvalidator, results at [2].
>
> it's a case of a misspelled tag. In the <author> tag <B> is closed by a </b>.
It's actually a bit more, I just checked against the Relax NG schema of
Atom v11 from RFC 4287.
Neither <span> nor <b>/<B> are allowed inside <name>, and the '\n' isn't
either. This is what we get:
=============================================================================
<author><name>andrea<!-- @
-->@dottout<span><B>.</b></span>com</name></author>\n<icon>/git-favicon.png</icon>
=============================================================================
This would be valid:
=============================================================================
<author>
<name>andrea<!-- @ -->@dottout.com</name>
</author>
<icon>/git-favicon.png</icon>
=============================================================================
Petr, is the e-mail crippling a repo.or.cz-only thing?
Sebastian
^ permalink raw reply
* [PATCH] Documentation/git-gc.txt: default --aggressive window is 250, not 10
From: Brandon Casey @ 2009-09-28 14:56 UTC (permalink / raw)
To: spearce; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
The default --aggressive window has been 250 since 1c192f34 "gc
--aggressive: make it really aggressive", released in git v1.6.3.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Documentation/git-gc.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index dcac8c8..1f6df6a 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -106,7 +106,7 @@ much time is spent optimizing the delta compression of the objects in
the repository when the --aggressive option is specified. The larger
the value, the more time is spent optimizing the delta compression. See
the documentation for the --window' option in linkgit:git-repack[1] for
-more details. This defaults to 10.
+more details. This defaults to 250.
The optional configuration variable 'gc.pruneExpire' controls how old
the unreferenced loose objects have to be before they are pruned. The
--
1.6.4.3
^ permalink raw reply related
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Sverre Rabbelier @ 2009-09-28 14:53 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List, Robin Rosenberg
In-Reply-To: <4AC0C46F.6090605@drmicha.warpmail.net>
Heya,
On Mon, Sep 28, 2009 at 16:13, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Robin Rosenberg venit, vidit, dixit 26.09.2009 00:03:
>> Something that ends with -ish seems natural, doesn't it?
>
> So, Germish it is...
¿Qué hay de español?
(Google translate don't fail me now)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Getting a list of last commit's files and piping them..
From: Christian Himpel @ 2009-09-28 14:13 UTC (permalink / raw)
To: Ahmed Nuaman, Freelance Designer and Developer; +Cc: git
In-Reply-To: <4f302eef91c72cd4583e0aa4707ab4c0@ahmednuaman.com>
On Mon, Sep 28, 2009 at 02:02:52PM +0100, Ahmed Nuaman, Freelance Designer and Developer wrote:
> I use git for a local versioning system and was wondering if there was a
> way that I could write a bash script that would get the paths of the files
> from the latest commit and then pipe them to ftp or ssh for deployment.
For example, to scp a complete file list from branch `topic' to
`user@server', you could use `rsync' and do something like:
git checkout topic &&
git ls-tree -r --name-only |
rsync -a -e ssh --files-from=- user@server:/path/to/dest
Note, that this is completely untested. Use at your own risk.
Regards,
chressie
^ permalink raw reply
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Michael J Gruber @ 2009-09-28 14:13 UTC (permalink / raw)
To: Git Mailing List; +Cc: Robin Rosenberg
In-Reply-To: <200909260003.05041.robin.rosenberg.lists@dewire.com>
Robin Rosenberg venit, vidit, dixit 26.09.2009 00:03:
> 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?
So, Germish it is...
Cheers,
Michael
^ permalink raw reply
* Re: Getting a list of last commit's files and piping them..
From: Johannes Schindelin @ 2009-09-28 14:01 UTC (permalink / raw)
To: Ahmed Nuaman, Freelance Designer and Developer; +Cc: git
In-Reply-To: <4f302eef91c72cd4583e0aa4707ab4c0@ahmednuaman.com>
Hi,
On Mon, 28 Sep 2009, Ahmed Nuaman, Freelance Designer and Developer wrote:
> I use git for a local versioning system and was wondering if there was a
> way that I could write a bash script that would get the paths of the
> files from the latest commit and then pipe them to ftp or ssh for
> deployment.
If you mean all the files that were touched by the last commit:
git diff --name-only HEAD^..
If you mean all the files of the latest revision:
git ls-tree --name-only -r HEAD
Both commands take -z options in which case they delimit the names with
NULs for better parsability.
Hth,
Dscho
^ permalink raw reply
* Getting a list of last commit's files and piping them..
From: Ahmed Nuaman, Freelance Designer and Developer @ 2009-09-28 13:02 UTC (permalink / raw)
To: git
Hey,
I use git for a local versioning system and was wondering if there was a
way that I could write a bash script that would get the paths of the files
from the latest commit and then pipe them to ftp or ssh for deployment.
--
All the best,
Ahmed Nuaman
Freelance Designer and Developer
+44 (0) 7811 184 436
ahmed@ahmednuaman.com
www.ahmednuaman.com
^ permalink raw reply
* Re: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Sebastian Schuberth @ 2009-09-28 13:40 UTC (permalink / raw)
To: Baz; +Cc: Shawn O. Pearce, git, mstormo
In-Reply-To: <2faad3050909280336r61e11b20nb52629a8fe95b0c0@mail.gmail.com>
On Mon, Sep 28, 2009 at 12:36, Baz <brian.ewins@gmail.com> wrote:
>>> 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.
>
> FYI: the Thunderbird version included this header:
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The format=flowed part shows that Thunderbird is reformatting
> whitespace. You can disable that:
> http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email
Thanks, this was indeed helpful. I was relying on the "Toggle Word
Wrap" extension [1] to handle this, but apparently it only changes how
the *sender* sees the message, but does not remove "format=flowed" if
word wrap is turned off. I've sent an according suggestion to the
extension's author.
[1] https://addons.mozilla.org/en-US/firefox/addon/2351
--
Sebastian Schuberth
^ permalink raw reply
* Re: how optparse can go horribly wrong
From: Clemens Buchacher @ 2009-09-28 13:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Sverre Rabbelier, Nicolas Sebrecht, git
In-Reply-To: <20090926192527.GF14660@spearce.org>
On Sat, Sep 26, 2009 at 12:25:27PM -0700, Shawn O. Pearce wrote:
> What I think we should do is not allow cuddling of short options
> when the final option takes more than 1 character worth of argument.
> Thus `git commit -a -mfoo` is OK, but `git commit -amfoo` is not.
I also think that would be the most sensible solution.
A little experimentation with git-log reveals that it does not behave very
well either.
git log -n1asdf -> asdf is ignored
git log -pn1 -> error
git log -p1 -> error
git log -1p -> p is ignored
So I think this should instead behave just like you described above.
git log -n1asdf -> error: unknown option(s) -asdf
git log -pn1 -> git log -p -n1
git log -p1 -> git log -p -n1
git log -1p -> git log -p -n1
Clemens
^ permalink raw reply
* Re: [PATCH 0/2] MSVC generator fixups
From: Sebastian Schuberth @ 2009-09-28 13:01 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git, spearce, msysgit
In-Reply-To: <cover.1254137149.git.mstormo@gmail.com>
> The two patches didn't apply for me in the way they were sent. I
> manually applied them ontop of master, and added an Acked-by.
Thanks for fixing my patches, Marius!
--
Sebastian Schuberth
^ permalink raw reply
* Re: Distribution size
From: Marius Storm-Olsen @ 2009-09-28 12:48 UTC (permalink / raw)
To: Thomas Singer; +Cc: git, Johannes Schindelin, Marc Weber
In-Reply-To: <4ABE3091.5040600@syntevo.com>
Thomas Singer said the following on 26.09.2009 17:17:
>> Funny. Git for Windows is less than 12MB [*1*].
>
> Well, the portable Git bundle compressed with 7zip is approx. 11MB,
> the Git installer (maybe also using 7zip internally) is at approx.
> the same size. Unpacked/installed on disk they are at 138MB/131MB.
> If you try to compress it with zip, it will reduce to approx. 70MB
> which still is quite large.
>
> We are interested, too, in having a small(er) bundle, because we
> want to distribute Git binaries with our Git GUI front-end,
> SmartGit, so the user will (have the option to) get an
> all-inclusive-bundle.
[Please, never ever top-post on the Git mailing list, thanks]
Most of the git-*.exe are identical duplicates, so most of that can be
nuked. Also, you don't need everything in msysgit to distribute, only
for development. You should be able to make a fairly small
distribution for usage only.
--
.marius
^ 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: Jonas Fonseca @ 2009-09-28 12:46 UTC (permalink / raw)
To: Mark Struberg; +Cc: Robin Rosenberg, git, spearce, Jason van Zyl
In-Reply-To: <901099.90084.qm@web27801.mail.ukl.yahoo.com>
On Sat, Sep 26, 2009 at 15:50, Mark Struberg <struberg@yahoo.de> wrote:
> Hi Robin!
>
> a) Actually git-format-patch only created 0001-0009 so there is no 0/9.
For larger patch series, it is good practice (at least on git@vger) to
provide a "cover letter" (see git-format-patch --cover-letter) to give
reviewers of the patch series an idea of what code is touched and for
you to give additional information, such as the state of the patch
series.
> b) 2/9 is the actual directory structure moving. I received it, but since it is pretty large (330k already with -M -l0) it might got filtered out?
> If so then may I ask you to please fetch it from http://github.com/sonatype/JGit branch 'mavenize'? It has the same content I sent to the list.
Some general notes on the patch series. First, I am glad you posted it
to have something to discuss and as I have stated in a private mail I
am glad you are doing this. However, I also think it needs a lot more
polish before being integrated.
While I understand that you want to credit Jason for doing the initial
probe into fully mavenizing JGit, I now think it is wrong to base the
patch series on his patch. My first impression is that it actually
removes features (by not keeping the JGit specific settings), which
you then try to amend later in the patch series.
In terms of making the patch series more manageable for you, I think
the best approach is to start with the patches not relevant to the
mavenizing (renaming PathSuffixTestCase). After this comes patches
which only touch pom.xml files. For example, move
jgit-maven/jgit/pom.xml to the top-level pom.xml, extract relevant
pieces to org.spearce.jgit/pom.xml and org.spearce.jgit.test/pom.xml,
improving the pom.xml`s by adding checkstyle/<scm> integration, and
mavenizing org.spearce.jgit.pgm/. The final and most invasive parts
(renaming/(re)moving code/eclipse files etc) should come last!
Taking this approach Robin and Spearce can start integrating initial
patces and we can all start testing the "mavenization" sooner rather
than after deciding how to rename things and whether or not to remove
certain files.
The above is a proposal and if you and other agree that it is the
right approach _and_ you do not feel you have the time necessary to
realize it, I am willing to work on it.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] generators/vcproj.pm: remove UNICODE from build
From: Marius Storm-Olsen @ 2009-09-28 12:39 UTC (permalink / raw)
To: Michael Wookey; +Cc: git
In-Reply-To: <d2e97e800909280346s12c205f2gf95ff4c135d4625c@mail.gmail.com>
Michael Wookey said the following on 28.09.2009 12:46:
> Defining UNICODE for MSVC IDE builds results in certain Win32 WIDE API's
> receiving ANSI strings. The result of which is an invalid use of the API
> and will end in either data corruption or an application crash.
>
> Prevent the use of WIDE API's when building with the MSVC IDE for
> compatibility with msysGit.
>
> Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
> ---
After manually editing the patch until it applied (some headers which
gt-am didn't like):
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
--
.marius
^ permalink raw reply
* Re: [PATCH] git-am: force egrep to use correct characters set
From: Christian Himpel @ 2009-09-28 12:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Christian Himpel, Jeff King, git
In-Reply-To: <4AC0877E.7020204@viscovery.net>
On Mon, Sep 28, 2009 at 11:53:02AM +0200, Johannes Sixt wrote:
> Christian Himpel schrieb:
> >> The case identified by Christian is certainly important because it is
> >> applied to a file whose contents can be anything, and the purpose of the
> >> check is to identify the text as an mbox file, whose header section can be
> >> only US-ASCII by definition. So, I think it has merit to apply the patch.
> >
> > Yes. It seems that this is the only place where it is important to match
> > just the ASCII printable characters.
>
> There is another place in git-am.sh where a sed expression with a range
> looks at the input file, doesn't it? Isn't it critical, too?
>
> if test -f "$dotest/rebasing" &&
> commit=$(sed -e 's/^From \([0-9a-f]*\) .*/\1/' \
> -e q "$dotest/$msgnum") &&
> test "$(git cat-file -t "$commit")" = commit
> then ...
It seems to be the line generated from 'git format-patch' that is tested
here. It specifies the SHA1 of the commit that is converted into a mbox
patch by 'format-patch'. Hence, I don't see it critical here (until
someone edits this line by hand).
Regards,
chressie
^ permalink raw reply
* [PATCH 2/2] Make just opening the generated MSVC solution file not modify it
From: Marius Storm-Olsen @ 2009-09-28 11:34 UTC (permalink / raw)
To: git, spearce, sschuberth; +Cc: msysgit
In-Reply-To: <cover.1254137149.git.mstormo@gmail.com>
From: Sebastian Schuberth <sschuberth@gmail.com>
The format of the generated MSVC solution file is fixed in a way that
just opening it in Visual Studio and immediately closing it again
without performing any modifications does not trigger a prompt to save
the solution file. This behavior was caused by several minor
incompatibilities between the generated file and what Visual Studio
2008 expected, so Visual Studio transparently fixed the file format,
marking it internally as modified.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 42 +++++++---------------------
1 files changed, 11 insertions(+), 31 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 50daa03..d53ff2c 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -571,45 +571,29 @@ sub createGlueProject {
print F "\"${libname}\", \"${libname}\\${libname}.vcproj\", \"${uuid}\"";
print F "$SLN_POST";
}
+ my $uuid_libgit = $build_structure{"LIBS_libgit_GUID"};
+ my $uuid_xdiff_lib = $build_structure{"LIBS_xdiff_lib_GUID"};
foreach (@apps) {
my $appname = $_;
my $uuid = $build_structure{"APPS_${appname}_GUID"};
print F "$SLN_PRE";
- print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"";
+ print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"\n";
+ print F " ProjectSection(ProjectDependencies) = postProject\n";
+ print F " ${uuid_libgit} = ${uuid_libgit}\n";
+ print F " ${uuid_xdiff_lib} = ${uuid_xdiff_lib}\n";
+ print F " EndProjectSection";
print F "$SLN_POST";
}
print F << "EOM";
Global
- GlobalSection(SolutionConfiguration) = preSolution
- ConfigName.0 = Debug|Win32
- ConfigName.1 = Release|Win32
+ GlobalSection(SolutionConfigurationPlatforms) = preSolution
+ Debug|Win32 = Debug|Win32
+ Release|Win32 = Release|Win32
EndGlobalSection
- GlobalSection(ProjectDependencies) = postSolution
EOM
- foreach (@{$build_structure{"APPS"}}) {
- my $appname = $_;
- my $appname_clean = $_;
- $appname_clean =~ s/\//_/g;
- $appname_clean =~ s/\.exe//;
-
- my $uuid = $build_structure{"APPS_${appname_clean}_GUID"};
- my $dep_index = 0;
- foreach(@{$build_structure{"APPS_${appname}_LIBS"}}) {
- my $libname = $_;
- $libname =~ s/\//_/g;
- $libname =~ s/\.(a|lib)//;
- my $libuuid = $build_structure{"LIBS_${libname}_GUID"};
- if (defined $libuuid) {
- print F "\t\t${uuid}.${dep_index} = ${libuuid}\n";
- $dep_index += 1;
- }
- }
- }
-
print F << "EOM";
- EndGlobalSection
- GlobalSection(ProjectConfiguration) = postSolution
+ GlobalSection(ProjectConfigurationPlatforms) = postSolution
EOM
foreach (@libs) {
my $libname = $_;
@@ -630,10 +614,6 @@ EOM
print F << "EOM";
EndGlobalSection
- GlobalSection(ExtensibilityGlobals) = postSolution
- EndGlobalSection
- GlobalSection(ExtensibilityAddIns) = postSolution
- EndGlobalSection
EndGlobal
EOM
close F;
--
1.6.5.rc2.177.ga9dd6
^ permalink raw reply related
* [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
From: Marius Storm-Olsen @ 2009-09-28 11:34 UTC (permalink / raw)
To: git, spearce, sschuberth; +Cc: msysgit
In-Reply-To: <cover.1254137149.git.mstormo@gmail.com>
From: Sebastian Schuberth <sschuberth@gmail.com>
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.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..50daa03 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -131,6 +131,7 @@ sub createLibProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -353,6 +354,7 @@ sub createAppProject {
$includes =~ s/-I//g;
mkdir "$target" || die "Could not create the directory $target for lib project!\n";
open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+ binmode F, ":crlf";
print F << "EOM";
<?xml version="1.0" encoding = "Windows-1252"?>
<VisualStudioProject
@@ -537,7 +539,7 @@ sub createGlueProject {
print "Generate solutions file\n";
$rel_dir = "..\\$rel_dir";
$rel_dir =~ s/\//\\/g;
- my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n";
+ my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n# Visual Studio 2008\n";
my $SLN_PRE = "Project(\"{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\") = ";
my $SLN_POST = "\nEndProject\n";
@@ -560,6 +562,7 @@ sub createGlueProject {
@apps = @tmp;
open F, ">git.sln" || die "Could not open git.sln for writing!\n";
+ binmode F, ":crlf";
print F "$SLN_HEAD";
foreach (@libs) {
my $libname = $_;
--
1.6.5.rc2.177.ga9dd6
^ permalink raw reply related
* [PATCH 0/2] MSVC generator fixups
From: Marius Storm-Olsen @ 2009-09-28 11:34 UTC (permalink / raw)
To: git, spearce, sschuberth; +Cc: msysgit, Marius Storm-Olsen
In-Reply-To: <4ABB84F4.7080403@gmail.com>
The generated solution file was valid, but not exactly in the way the
2008 IDE wanted them, so the IDE would query to save the solution file
even though the user never touched the solution/projects.
These two patches ensures that the solution file is in the way the IDE
wants them, so we avoid the naging.
The two patches didn't apply for me in the way they were sent. I
manually applied them ontop of master, and added an Acked-by.
Thanks!
Sebastian Schuberth (2):
Make generated MSVC solution file open from Windows Explorer
Make just opening the generated MSVC solution file not modify it
contrib/buildsystems/Generators/Vcproj.pm | 47 +++++++++-------------------
1 files changed, 15 insertions(+), 32 deletions(-)
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Dilip M @ 2009-09-28 11:32 UTC (permalink / raw)
To: newsgroups, git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
You better evaluate yourself on the project you are going to use git
or Hg. Hg and git are used both by big companies. Google uses git to
host android, where as it also uses Hg to host google wave! So don't
go which company uses what, but try to evaluate... Check what is the
kind of operations your developers do often? Is it checkout, diff,
blame, also are they ready to do git gc often? What about developer
who is not interested in using cli? How do u care them for operations
they intended to do? what is the workflow? Which tools supports it to
great extent?
At the end of day, it is a developer who spends much time using tool..
Just my opinion...... you put this question in Hg list, I bet you
will get the different views....
The above is solely my opinion and I am not biased! I think so:)
On 9/27/09, Anteru <newsgroups@catchall.shelter13.net> wrote:
> Hi,
>
> I'm currently evaluating DVCS for a project, and we're at a point where
> it comes down to either Mercurial or Git. Right now, I'm advocating for
> Git, while my co-workers like Mercurial, so I'd like to provide some
> good arguments in favor of git. Unfortunately, I'm not a git expert, so
> I hope I can get some help here ...
>
> First of all, what's the matter with git and Windows, is there some
> long-term commitment to make git work on Windows as well as on Linux?
> I'm using msysgit on Windows, and personally I'm happy with it, but my
> co-workers constantly nag that Mercurial has superior portability ...
>
> Mercurial's revision number system: With git, I get an SHA1 hash for
> every commit, but it's not possible to see whether Hash1 is newer than
> Hash2, while Mecurial also adds a running number to each commit. What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?
>
> Integration into tools: We're using Trac currently, which also has a
> nice binding to Mercurial (well, obviously easy to do as Mercurial is
> written in Python, just as Trac itself), while the git support is in
> development and looks quite alpha'ish. Do you plan to make it easier to
> integrate git with other tools by providing bindings to other languages,
> or is this a low-priority issue?
>
> So far, my key arguments are that git is more robust (more projects
> using it, larger developer base), of course git's excellent performance
> and the much better support for SVN, which is important for us as we can
> slowly migrate from SVN->Git, while hgmercurial is still in the making
> (and Python's SVN->Hg switch is for instance waiting for it).
>
> Cheers,
> Anteru
>
> --
> 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
>
--
Sent from my mobile device
Dilip
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Bruce Stephens @ 2009-09-28 11:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Johannes Schindelin, newsgroups, git
In-Reply-To: <94a0d4530909280401q4a451697re8954320682662f2@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
[...]
> Ok, thanks for pointing that out. I was thinking that maybe 'git
> blame' would also be slightly faster on hg, but I really don't know.
hg (and git) store binary deltas. AFAIK neither attempts to use those
to produce output for blame, diff, etc. (git's deltas may well be
slightly different from mercurial's, in that git's can be deltas with
respect to something arbitrary so even if they had a suitable line-based
format they'd be useless for diff, blame.)
Similarly for the other major systems, with the exception of (I think)
bzr and darcs. (I don't know how bzr or darcs actually work, but IIRC
they both have line-based storage that in principle might be usable in
computing blame and diff.)
[...]
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Felipe Contreras @ 2009-09-28 11:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: newsgroups, git
In-Reply-To: <alpine.DEB.1.00.0909281059180.4985@pacific.mpi-cbg.de>
On Mon, Sep 28, 2009 at 1:08 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> I tried to refrain from commenting in this thread, because I do not want
> to encourage people just to use msysGit and never even attempt to fix
> their own issues.
>
> But I cannot let this go uncommented:
>
> On Mon, 28 Sep 2009, Felipe Contreras wrote:
>
>> IMO the key difference between hg and git is the storage model: hg
>> stores deltas, while git stores snapshots. That would mean that certain
>> operations are theoretically faster in git (e.g. checkout, diff) while
>> others faster in hg, although with git's packed format I guess there's
>> no operation faster in hg. This means that it doesn't matter how much
>> hg's python code improves, or if they even re-write parts in C, they
>> will never be able to match git's performance (unless they change the
>> storage model, which essentially means changing the whole design --
>> won't happen).
>
> That is wrong. "git log -- <file>" will always be slightly faster in
> Mercurial, for all the reasons you mentioned.
Ok, thanks for pointing that out. I was thinking that maybe 'git
blame' would also be slightly faster on hg, but I really don't know.
Anyway, I think for most operations git would always be faster, and
more importantly; some essential operations will be faster (checkout,
diff <committish>).
--
Felipe Contreras
^ permalink raw reply
* [PATCH] generators/vcproj.pm: remove UNICODE from build
From: Michael Wookey @ 2009-09-28 10:46 UTC (permalink / raw)
To: git
Defining UNICODE for MSVC IDE builds results in certain Win32 WIDE API's
receiving ANSI strings. The result of which is an invalid use of the API
and will end in either data corruption or an application crash.
Prevent the use of WIDE API's when building with the MSVC IDE for
compatibility with msysGit.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
contrib/buildsystems/Generators/Vcproj.pm | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/buildsystems/Generators/Vcproj.pm
b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..a215911 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm
@@ -173,7 +173,7 @@ sub createLibProject {
Optimization="0"
InlineFunctionExpansion="1"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,_DEBUG,$defines"
+ PreprocessorDefinitions="WIN32,_DEBUG,$defines"
MinimalRebuild="true"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
@@ -239,7 +239,7 @@ sub createLibProject {
InlineFunctionExpansion="1"
EnableIntrinsicFunctions="true"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,NDEBUG,$defines"
+ PreprocessorDefinitions="WIN32,NDEBUG,$defines"
RuntimeLibrary="0"
EnableFunctionLevelLinking="true"
UsePrecompiledHeader="0"
@@ -395,7 +395,7 @@ sub createAppProject {
Optimization="0"
InlineFunctionExpansion="1"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,_DEBUG,$defines"
+ PreprocessorDefinitions="WIN32,_DEBUG,$defines"
MinimalRebuild="true"
RuntimeLibrary="1"
UsePrecompiledHeader="0"
@@ -466,7 +466,7 @@ sub createAppProject {
InlineFunctionExpansion="1"
EnableIntrinsicFunctions="true"
AdditionalIncludeDirectories="$includes"
- PreprocessorDefinitions="UNICODE,WIN32,NDEBUG,$defines"
+ PreprocessorDefinitions="WIN32,NDEBUG,$defines"
RuntimeLibrary="0"
EnableFunctionLevelLinking="true"
UsePrecompiledHeader="0"
--
1.6.5.rc2
^ permalink raw reply related
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