* 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
* Re: Deciding between Git/Mercurial
From: Anteru @ 2009-09-29 6:32 UTC (permalink / raw)
To: git
In-Reply-To: <m33a66br69.fsf@localhost.localdomain>
> 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
Ah cool, thanks for clarifying this.
>> 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?
hgsubversion of course, which is supposed to be what git-svn is already.
At the moment, I already use git with our SVN server, so I can show some
of the advantages (for instance, renaming works much better than with
SVN itself :) ), and I guess it also makes the migration easier as
everyone can try with Git locally and we switch from SVN to Git once
everyone has switched locally.
Thanks for all the input so far!
Cheers,
Anteru
^ permalink raw reply
* [PATCH 2/2] fast-import.c::validate_raw_date(): really validate the value
From: Junio C Hamano @ 2009-09-29 6:40 UTC (permalink / raw)
To: git
In-Reply-To: <1254206409-13256-1-git-send-email-gitster@pobox.com>
When reading the "raw format" timestamp from the input stream, make sure
that the timezone offset is a reasonable value by imitating 7122f82
(date.c: improve guess between timezone offset and year., 2006-06-08).
We _might_ want to also check if the timestamp itself is reasonable, but
that is left for a separate commit.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
fast-import.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 7ef9865..6faaaac 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1744,10 +1744,12 @@ static int validate_raw_date(const char *src, char *result, int maxlen)
{
const char *orig_src = src;
char *endp;
+ unsigned long num;
errno = 0;
- strtoul(src, &endp, 10);
+ num = strtoul(src, &endp, 10);
+ /* NEEDSWORK: perhaps check for reasonable values? */
if (errno || endp == src || *endp != ' ')
return -1;
@@ -1755,8 +1757,9 @@ static int validate_raw_date(const char *src, char *result, int maxlen)
if (*src != '-' && *src != '+')
return -1;
- strtoul(src + 1, &endp, 10);
- if (errno || endp == src || *endp || (endp - orig_src) >= maxlen)
+ num = strtoul(src + 1, &endp, 10);
+ if (errno || endp == src + 1 || *endp || (endp - orig_src) >= maxlen ||
+ 1400 < num)
return -1;
strcpy(result, orig_src);
--
1.6.3
^ permalink raw reply related
* [PATCH 1/2] builtin-mailinfo.c: check error status from rewind and ftruncate
From: Junio C Hamano @ 2009-09-29 6:40 UTC (permalink / raw)
To: git
A recent "cut at scissors" implementation rewinds and truncates the output
file to store the message when it sees a scissors mark, but it did not
check if these library calls succeeded.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-mailinfo.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index d498b1c..3306d9e 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -785,8 +785,10 @@ static int handle_commit_msg(struct strbuf *line)
if (use_scissors && is_scissors_line(line)) {
int i;
- rewind(cmitmsg);
- ftruncate(fileno(cmitmsg), 0);
+ if (rewind(cmitmsg))
+ die_errno("Could not rewind output message file");
+ if (ftruncate(fileno(cmitmsg), 0))
+ die_errno("Could not truncate output message file at scissors");
still_looking = 1;
/*
--
1.6.3
^ permalink raw reply related
* Re: Deciding between Git/Mercurial
From: Mike Ralphson @ 2009-09-29 7:44 UTC (permalink / raw)
To: Randal L. Schwartz, loic
Cc: Sverre Rabbelier, Steven Noonan, Damien Wyart, Anteru, git
In-Reply-To: <86iqf2r5ch.fsf@blue.stonehenge.com>
2009/9/29 Randal L. Schwartz <merlyn@stonehenge.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?
Not a member of the team, just a user (and bug reporter!), but I
believe Indefero is almost all the work of one pretty amazing guy, Dr
Loïc d'Anterroches, cc'd above.
Mike
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Matthieu Moy @ 2009-09-29 8:21 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Steven Noonan, Damien Wyart, Anteru, git
In-Reply-To: <fabb9a1e0909281433l461086e3k93a138ad4b9b86c6@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> 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.
Indefero is a clone of Google code.
http://www.google.com/search?q=indefero+clone+google+code
(most links are in French, but this is what they say)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Sverre Rabbelier @ 2009-09-29 8:22 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Steven Noonan, Damien Wyart, Anteru, git
In-Reply-To: <vpqljjykvpf.fsf@bauges.imag.fr>
Heya,
On Tue, Sep 29, 2009 at 10:21, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> http://www.google.com/search?q=indefero+clone+google+code
>
> (most links are in French, but this is what they say)
Might I suggest for those that are no masters of the french language:
http://translate.google.com/translate_s?hl=en&clss=&q=indefero+clone+google+code&sl=en&tl=fr
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Daniele Segato @ 2009-09-29 8:44 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <h9nlhj$heq$1@ger.gmane.org>
On Sun, Sep 27, 2009 at 2:24 PM, Anteru
<newsgroups@catchall.shelter13.net> wrote:
> 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 ...
Can I propose to make this discussion cross-mailing list adding the hg
mailing list to the CC?
I think it would be a good discussion if we don't end up flaming.
Let me know what you think about it
about the Windows+Git compatibility, you may consider TortoiseGit too
for the not-CLI-oriented guys; I've seen it a while ago and it seems
pettry well integrated with windows
> 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?
If you tag a commit then you should be able to see how many commits
there are from that one issuing a git describe
(found on the internet)
git commit -m'Commit One.'
git tag -a -m'Tag One.' 1.2.3
git describe # => 1.2.3
git commit -m'Commit Two.'
git describe # => 1.2.3-1-gaac161d
git commit -m'Commit Three.'
git describe # => 1.2.3-2-g462715d
git tag -a -m'Tag Two.' 2.0.0
git describe # => 2.0.0
> 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).
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Dilip M @ 2009-09-29 8:54 UTC (permalink / raw)
To: Daniele Segato; +Cc: newsgroups, git
In-Reply-To: <9accb4400909290144t1363b5c6t8886bfa01e486c94@mail.gmail.com>
On Tue, Sep 29, 2009 at 2:14 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:
> Can I propose to make this discussion cross-mailing list adding the hg
> mailing list to the CC? I think it would be a good discussion if we don't
> end up flaming. Let me know what you think about it
We will probably end in flames. Its same as comparing Vim and Emacs, Python
and Perl...
...this comparison is all ver web. Checkout!
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/
My *personnel* opinion is, If it is for project _only_ on UNIX, than GIT and
repo tool from Google will be killing combination.
If project is on both Windows & UNIX (But consider where do you compile your
code), than hg doesn't have matching!
--
Dilip
^ permalink raw reply
* Re: Distribution size
From: Thomas Singer @ 2009-09-29 9:06 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git, Johannes Schindelin, Marc Weber
In-Reply-To: <4AC0B088.9090101@gmail.com>
Hi Marius,
> Also, you don't need everything in msysgit to distribute, only for development.
How should I find out what is required to *run* all git commands, except of
trying it myself? Is there a document available somewhere?
--
Best regards,
Thomas Singer
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
Marius Storm-Olsen wrote:
> 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
* Git problems with adding files (first use)
From: A. S. Budden @ 2009-09-29 9:17 UTC (permalink / raw)
To: git
Dear all,
I have just installed Git from the msysgit distribution
(Git-1.6.4-preview20090730.exe). I've also installed TortoiseGit
(1.0.2.0). I've been having a few problems adding files (either using
tortoise or the command line tools).
What I did (copied and pasted directly from the command window):
=============================================================
Z:\>mkdir testproject
Z:\>cd testproject
Z:\testproject>echo "test file" > file1.c
Z:\testproject>echo "test file" > file2.c
Z:\testproject>git init
Initialized empty Git repository in Z:/testproject/.git/
Z:\testproject>git add file1.c
error: unable to create temporary sha1 filename .git/objects/f7/tmp_obj_a02340:
No such file or directory
error: file1.c: failed to insert into database
error: unable to index file file1.c
fatal: adding files failed
=============================================================
Can anyone tell me what I'm doing wrong? I've tried using tortoise
git and I've tried it on an existing project (rather than a bunch of
random files), but I can't seem to add files to the repository: I
always get the "No such file or directory" error.
Thanks in advance for your help.
Al
^ permalink raw reply
* Re: Alles wird Git, Berlin, Oct 3rd, 2009
From: Christian Halstrick @ 2009-09-29 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0909282019160.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
> As far as I am concerned, it is open to everyone who wants to meet some
> Gits, even top-posters
sorry for top-posting. It's so easy to top-post if you are forced to use
outlook. And sending a jgit patch with outlook and exchange servers is hell.
Thank god msysgit has learned git send-email.
^ permalink raw reply
* Re: Distribution size
From: Johannes Schindelin @ 2009-09-29 10:47 UTC (permalink / raw)
To: Thomas Singer; +Cc: Marius Storm-Olsen, git, Marc Weber
In-Reply-To: <4AC1CE12.8040406@syntevo.com>
Hi,
On Tue, 29 Sep 2009, Thomas Singer wrote:
> > Also, you don't need everything in msysgit to distribute, only for
> > development.
>
> How should I find out what is required to *run* all git commands, except
> of trying it myself? Is there a document available somewhere?
Thomas, are you seriously asking to work for you for free? What's in it
for us?
Ciao,
Dscho
^ permalink raw reply
* Compact view of history in gitk
From: Yakup Akbay @ 2009-09-29 11:49 UTC (permalink / raw)
To: git
Hi,
imagine a git history with many branches and many many commits in it,
which you cannot have a bird's eye view to the whole git history
(consider linux kernel). What I'm looking for is to see is a graphical
history representation with only the tip of all branches plus all merge
bases drwan like a molecul shape, where all intermediate commits are
replaced by a single symbol like '~'.
Think of the gitk version of the history below:
E-*-*-*-F
/
A-*-*-*-*-*-*-B-C-*-*-*-D
\
G-*-*-H-*-*-*-I
\
J-*-*-*-*-*-K
I want an output like this:
E-~-F
/
A-~-B-C-~-D
\
G-~-H-~-I
\
J-~-K
Is there an option in gitk (or in any other tool) to get such a view?
Yakup
^ permalink raw reply
* Re: Compact view of history in gitk
From: Johannes Sixt @ 2009-09-29 12:07 UTC (permalink / raw)
To: Yakup Akbay; +Cc: git
In-Reply-To: <4AC1F435.4030802@ubicom.com>
Yakup Akbay schrieb:
> Think of the gitk version of the history below:
>
> E-*-*-*-F
> /
> A-*-*-*-*-*-*-B-C-*-*-*-D
> \
> G-*-*-H-*-*-*-I
> \
> J-*-*-*-*-*-K
>
>
> I want an output like this:
>
> E-~-F
> /
> A-~-B-C-~-D
> \
> G-~-H-~-I
> \
> J-~-K
>
> Is there an option in gitk (or in any other tool) to get such a view?
I think, --simplify-by-decoration comes close, even though it may not be
100% what you describe.
-- Hannes
^ 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