* 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: [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: 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 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
* 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: 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
* 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: 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: 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
* [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: 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
* [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: 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
* 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: 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: Deciding between Git/Mercurial
From: Steven Noonan @ 2009-09-28 21:09 UTC (permalink / raw)
To: Damien Wyart; +Cc: Anteru, git
In-Reply-To: <20090928205458.GA2669@brouette>
On Mon, Sep 28, 2009 at 1:54 PM, Damien Wyart <damien.wyart@gmail.com> wrote:
> 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/
>
The interface looks very similar to Google Code's. I wonder, is this
the same thing that Google is using, or is it just mimicking the
interface?
- Steven
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Sverre Rabbelier @ 2009-09-28 21:33 UTC (permalink / raw)
To: Steven Noonan; +Cc: Damien Wyart, Anteru, git
In-Reply-To: <f488382f0909281409n1c1f7e5ex64a10147a14e39a@mail.gmail.com>
Heya,
On Mon, Sep 28, 2009 at 23:09, Steven Noonan <steven@uplinklabs.net> wrote:
> The interface looks very similar to Google Code's. I wonder, is this
> the same thing that Google is using, or is it just mimicking the
> interface?
Whow, it _does_ look a lot like Google Code, I doubt it's the same
code as I don't think Google Code's verison is open source, pretty
good copy either way.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [JGIT] patch-id
From: Nasser Grainawi @ 2009-09-28 22:21 UTC (permalink / raw)
To: Shawn O. Pearce, Robin Rosenberg; +Cc: Git Mailing List
Hello again,
I'm trying to add a public getPatchId method to the jgit Patch class and I
came up with some questions. Shawn previously mentioned that Patch already
does the parsing of the patch; however, I can't quite wrap my head around
how/where/if data from that parsing is stored.
It seems Patch does some statistical number gathering, but at no point does
it store a 'slimmed-down' version of a patch. I had the idea to just iterate
over the FileHeader's and get the byte buffer of each, but I don't think
those buffers have the parsed data.
If I've mis-read the code (quite possible), someone please let me know.
Short of that, suggestions for how to go about acquiring/storing a parsed
representation of the data with maximal existing code re-use would be
appreciated.
Thanks,
Nasser
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Jakub Narebski @ 2009-09-28 23:11 UTC (permalink / raw)
To: Anteru; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
Anteru <newsgroups@catchall.shelter13.net> writes:
> 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 ...
On one hand side Git relies quite a bit on POSIX features; also some
of git commands are implemented as shell scripts, or are written in
Perl. Nevertheless even if people stopped working on msysGit
("native" Windows port), which I don't see happening, there is always
and will be git from Cygwin. But the msysGit team is active, and I
predict that it soon would be full equivalent of Git on Linux (there
are some corner cases yet). Lately there was even some work on
support infrastructore for having Git be developed in MSVC.
On the other hand side Mercurial does have some parts of its code
rewritten in C for efficiency. I do wonder how portable it is, and
what is more important how portable is the interface between C and
Python.
But I do not use MS Windows for development, and I do not use
Mercurial...
> 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?
First, you have to remember that this 'number of commit' thingy is
*local* to your repository, so you cannot use commit numbers to
communicate with other developers. This is inherent and unavoidable
property of 'revision numbering': commit identifiers must be derivable
from commit contents (e.g. SHA-1 used by Git), or must be local to
clone of repository (e.g. Mercurial), or there must be some central
numbering authority (like in centralized SCMs like Subversion).
Second, I think advantages of revision numbering (running number) are
overemphasized. I don't see how numbers such as 12678 and 12687 are
easier to use than even abbreviated SHA-1 IDs like f06e7eb, never mind
the "<branch>~<n>" syntax Git uses to refer to n-th ancestor of
current tip of given branch. Besides with nonlinear history with
revision numbers such as 12678 and 12687 you know that 12678 is older
than 12687 if and only if 12678 and 12687 are on the same line of
development.
Third, I think it would be possible to emulate mercurial behaviour
with using lightweight 'number' tags for numbering, created from a
hook.
> 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?
Well, I think that the problem with implementing bindings to other
programming languages is that there is currently no such thing like
the Git library (well, there are beginnings of one). This is caused
by the fact that originally git commands were written in run-once
philosophy, and e.g. rely on operating system to do the cleanups.
So far bindings to other languages either call Git commands (like
Git.pm Perl interface from Git, or JavaGit), or are native Git
(re)implementations relying not on stable API, but on stable
repository format (JGit for Java, Dulwich for Python, partially Grit
for Ruby).
The emphasisis in Git was (and is) for it to be *scriptable*, rather
than extensible through plugins.
BTW. the fact that JGit is reimplementation allows it to be use
different license than Git itself; license which makes JGit and EGit
to be license-compatibile with Eclipse, and allow to distribute EGit
as full Eclipse project.
>
> 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).
hgmercurial? or hgsubversion?
There is also fact that git has superior support for multi-branch
development, which I think is the workflow most suited for distributed
development.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Randal L. Schwartz @ 2009-09-28 23:56 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Steven Noonan, Damien Wyart, Anteru, git
In-Reply-To: <fabb9a1e0909281433l461086e3k93a138ad4b9b86c6@mail.gmail.com>
>>>>> "Sverre" == Sverre Rabbelier <srabbelier@gmail.com> writes:
Sverre> Whow, it _does_ look a lot like Google Code, I doubt it's the same
Sverre> code as I don't think Google Code's verison is open source, pretty
Sverre> good copy either way.
I gotta get these guys on FLOSS Weekly. Is anyone here a member of
the team?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Sverre Rabbelier @ 2009-09-29 0:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Steven Noonan, Damien Wyart, Anteru, git
In-Reply-To: <86iqf2r5ch.fsf@blue.stonehenge.com>
Heya,
On Tue, Sep 29, 2009 at 01:56, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> I gotta get these guys on FLOSS Weekly. Is anyone here a member of
> the team?
There is of course the possiblity that the codesite team liked their
design so much that they based theirs off of the Indefero thing :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Jakub Narebski @ 2009-09-29 0:32 UTC (permalink / raw)
To: Anteru; +Cc: git
In-Reply-To: <m33a66br69.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Anteru <newsgroups@catchall.shelter13.net> writes:
>
> > 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 ...
[...]
> > 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).
>
> hgmercurial? or hgsubversion?
>
> There is also fact that git has superior support for multi-branch
> development, which I think is the workflow most suited for distributed
> development.
See also http://whygitisbetterthanx.com/#hg
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Paolo Bonzini @ 2009-09-29 1:55 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
On 09/27/2009 02:24 PM, Anteru wrote:
> What's
> the rationale behind this decision for git, and is it possible to
> emulate Mercurial's behavior somehow?
While not exactly the same thing, 'git describe' is very helpful in
comparing versions (if you know that one is an ancestor of the other).
Paolo
^ permalink raw reply
* Funds Collection Agent Needed
From: DY Toolling (HK) Co., Ltd @ 2009-09-29 2:47 UTC (permalink / raw)
--
DY Toolling (HK) Co., Ltd
Shenzhen Factory:
D Building G District, Third Industrial Park, Gonghe Village Shajing Town,
Baoan District, Shenzhen, Guangdong Province China
Fax: +85-230-177486
info@dytoolling.com
Web: www.dytoolling.com
Dear Agent,
DY Toolling (HK) Co., Ltd is urgently in need of a collection Agency that will
assist us in the collection of our outstanding debts in some parts of the US
and Canada.
We have gone through your profile and think you might be able to assist us in
this area. Details will be provided upon request. Please respond quickly as we
want this resolved urgently.
Sincerely Yours,
Mr. Tanaka Wong
President CEO
E-Mail : Info@dytoolling.com
www.dytoolling.com
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* [PATCH] typo fix: Directory `...' exist, ...: s/exist/exists/
From: Jim Meyering @ 2009-09-29 5:43 UTC (permalink / raw)
To: git list
Using next, I saw this:
Directory 'gnulib' exist, but is neither empty nor a git repository
>From 438a7c3a41f0e829779cccd901cf894300b6683e Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyering@redhat.com>
Date: Tue, 29 Sep 2009 07:42:25 +0200
Subject: [PATCH] typo fix: Directory `...' exist, ...: s/exist/exists/
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index bfbd36b..0462e52 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -98,7 +98,7 @@ module_clone()
if test -d "$path"
then
rmdir "$path" 2>/dev/null ||
- die "Directory '$path' exist, but is neither empty nor a git repository"
+ die "Directory '$path' exists, but is neither empty nor a git repository"
fi
test -e "$path" &&
--
1.6.5.rc2.177.ga9dd6
^ 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