* Re: git export to svn
From: Björn Steinbrink @ 2008-10-26 17:15 UTC (permalink / raw)
To: Warren Harris; +Cc: J.H., git
In-Reply-To: <8ED0030A-E55E-4082-87C9-53B11F763E1B@gmail.com>
On 2008.10.26 09:24:07 -0700, Warren Harris wrote:
>
> On Oct 26, 2008, at 2:15 AM, Björn Steinbrink wrote:
>
>> On 2008.10.25 13:29:50 -0700, Warren Harris wrote:
>>> I tried a fetch, but still no luck:
>>>
>>> $ git svn fetch
>>> W: Ignoring error from SVN, path probably does not exist: (175002):
>>> RA
>>> layer request failed: REPORT of '/svn/!svn/bc/100': Could not read
>>> chunk
>>> size: Secure connection truncated (https://svn)
>>> W: Do not be alarmed at the above message git-svn is just searching
>>> aggressively for old history.
>>> This may take a while on large repositories
>>> r58084 = c01dadf89b552077da132273485e7569d8694518 (trunk)
>>> A ...
>>> r58088 = 7916f3a02ad6c759985bd9fb886423c373a72125 (trunk)
>>>
>>> $ git svn rebase
>>> Unable to determine upstream SVN information from working tree
>>> history
>>
>> Means that your current branch is not based on what git-svn has
>> fetched,
>> which is expected when you use "svn init" + "svn fetch" after you
>> already started working.
>>
>> What's the actual relationship between your local history and the
>> history you fetched from svn?
>
> Since I'm trying to export my git repo to svn, the svn repo is
> completely empty.
OK, the "r58084" made me think that your code is based on something that
is already in the SVN repo. But apperently, that's just a shared svn
repo, right?
> I may not have been clear about what I'm trying to do: I have a git
> repository, and I'd like to put it (either the head of the master, or
> the entire revision history if possible) into svn. From then on, I would
> like to be able to use 'git svn' commands to manage the two repos.
> (Initially I don't expect anyone else to be committing to svn -- it's
> just an archive and something for others to pull from.)
>
> Here's a complete transcript of how I tried to do this, which seems to
> be missing some crucial step:
>
> $ mkdir test2-git-clone
> $ git clone ../test2/ # clone my working repo which is unrelated to
> svn at this point
> $ cd test2-git-clone/test2
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2 -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/trunk -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/branches -m "test2"
> $ svn mkdir https://svn/svn/SANDBOX/warren/test2/tags -m "test2"
> $ git svn init https://svn/svn/SANDBOX/warren/test2 -T trunk -t tags -b
> branches
> Initialized empty Git repository in /Users/warren/projects/tmp/test2-
> git-clone/test2/.git/
> Using higher level of URL: https://svn/svn/SANDBOX/warren/test2 => https://svn/svn
> $ git svn dcommit
> Can't call method "full_url" on an undefined value at /opt/local/
> libexec/git-core/git-svn line 425.
Can't work yet, your local stuff is not yet connected to the svn commit
(which you didn't even fetch yet). Same for the other dcommit calls you
did.
> $ git merge --no-ff master
> Already up-to-date.
That tries to merge master into itself ;-) The blog entry assumed that
you have a svn-based branch checked out, and applies to quite a
different situation.
This should do and uses a graft to simplify the process a bit:
Initialize git-svn:
git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
The --prefix gives you remote tracking branches like "svn/trunk" which
is nice because you don't get ambiguous names if you call your local
branch just "trunk" then. And -s is a shortcut for the standard
trunk/tags/branches layout.
Fetch the initial stuff from svn:
git svn fetch
Now look up the hash of your root commit (should show a single commit):
git rev-list --parents master | grep '^.\{40\}$'
Then get the hash of the empty trunk commit:
git rev-parse svn/trunk
Create the graft:
echo <root-commit-hash> <svn-trunk-commit-hash> >> .git/info/grafts
Now, "gitk" should show svn/trunk as the first commit on which your
master branch is based.
Make the graft permanent:
git filter-branch -- ^svn/trunk --all
Drop the graft:
rm .git/info/grafts
gitk should still show svn/trunk in the ancestry of master
Linearize your history on top of trunk:
git svn rebase
And now "git svn dcommit -n" should tell you that it is going to commit
to trunk.
Alternatively, if rebase gives just too many conflicts, you can do:
git svn init -s --prefix=svn/ https://svn/svn/SANDBOX/warren/test2
git svn fetch
git checkout -b trunk svn/trunk
git merge master
git svn dcommit
That will just create a single huge commit in svn. But the history will
be retained in git. You can then work on the new "trunk" branch or move
your master branch, so it points to the same commit as trunk and then
drop the "trunk" branch or whatever. It just matters that your new work
is based upon the dcommited merge commit, so "svn/trunk" is in your
branch's history.
HTH
Björn
^ permalink raw reply
* Re: Weird problem with long $PATH and alternates (bisected)
From: René Scharfe @ 2008-10-26 17:53 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <7vljwb5o4p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "Mikael Magnusson" <mikachu@gmail.com> writes:
>
>> % mkdir 1; cd 1
>> % echo > a; git add a; git commit -m a
>> % cd ..
>> % git clone -s 1 2
>> % git push . master:master
>> fatal: Could not switch to
>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>> fatal: The remote end hung up unexpectedly
>
> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
> callchain, but I cannot explain why the contents of $PATH leaks to the
> error message.
With the following patch, I can no longer reproduce the problem. Does it
work fo you, too?
Thanks,
René
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..8044e9c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -269,7 +269,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
entlen += base_len;
pfxlen += base_len;
}
- ent = xmalloc(sizeof(*ent) + entlen);
+ ent = xcalloc(1, sizeof(*ent) + entlen);
if (!is_absolute_path(entry) && relative_base) {
memcpy(ent->base, relative_base, base_len - 1);
^ permalink raw reply related
* Re: Weird problem with long $PATH and alternates (bisected)
From: Junio C Hamano @ 2008-10-26 18:07 UTC (permalink / raw)
To: René Scharfe; +Cc: Mikael Magnusson, Git Mailing List
In-Reply-To: <4904AE8D.9090706@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Junio C Hamano schrieb:
>> "Mikael Magnusson" <mikachu@gmail.com> writes:
>>
>>> % mkdir 1; cd 1
>>> % echo > a; git add a; git commit -m a
>>> % cd ..
>>> % git clone -s 1 2
>>> % git push . master:master
>>> fatal: Could not switch to
>>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>>> fatal: The remote end hung up unexpectedly
>>
>> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
>> callchain, but I cannot explain why the contents of $PATH leaks to the
>> error message.
>
> With the following patch, I can no longer reproduce the problem. Does it
> work fo you, too?
>
> Thanks,
> René
>
> diff --git a/sha1_file.c b/sha1_file.c
> index ab2b520..8044e9c 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -269,7 +269,7 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
> entlen += base_len;
> pfxlen += base_len;
> }
> - ent = xmalloc(sizeof(*ent) + entlen);
> + ent = xcalloc(1, sizeof(*ent) + entlen);
Ah, that would explain the "filled with garbage from $PATH" issue, but I
don't think it fixes the fundamental issue.
In the alternate_object_database structure, ent->base[] is a buffer the
users can use to form pathnames to loose objects, and ent->name is a
pointer into that buffer (it points at one beyond ".git/objects/"). If
you get a call to add_refs_from_alternate() after somebody used the entry
(has_loose_object() has been called, for example), *ent->name would not be
NUL, and ent->base[] won't be the path to the object store.
This caller is expecting to read the path to the object store in ent->base[];
it needs to NUL terminate the buffer if it wants to.
I think the previous patch to sha1_file.c, while it may fix the issue, is
not quite nice. Here is a replacement that should work.
builtin-receive-pack.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git c/builtin-receive-pack.c w/builtin-receive-pack.c
index 45e3cd9..9f60f31 100644
--- c/builtin-receive-pack.c
+++ w/builtin-receive-pack.c
@@ -466,12 +466,17 @@ static int delete_only(struct command *cmd)
static int add_refs_from_alternate(struct alternate_object_database *e, void *unused)
{
- char *other = xstrdup(make_absolute_path(e->base));
- size_t len = strlen(other);
+ char *other;
+ size_t len;
struct remote *remote;
struct transport *transport;
const struct ref *extra;
+ e->name[-1] = '\0';
+ other = xstrdup(make_absolute_path(e->base));
+ e->name[-1] = '/';
+ len = strlen(other);
+
while (other[len-1] == '/')
other[--len] = '\0';
if (len < 8 || memcmp(other + len - 8, "/objects", 8))
^ permalink raw reply related
* Re: Weird problem with long $PATH and alternates (bisected)
From: Mikael Magnusson @ 2008-10-26 18:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Git Mailing List
In-Reply-To: <7v63nf5iy1.fsf@gitster.siamese.dyndns.org>
2008/10/26 Junio C Hamano <gitster@pobox.com>:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb:
>>> "Mikael Magnusson" <mikachu@gmail.com> writes:
>>>
>>>> % mkdir 1; cd 1
>>>> % echo > a; git add a; git commit -m a
>>>> % cd ..
>>>> % git clone -s 1 2
>>>> % git push . master:master
>>>> fatal: Could not switch to
>>>> '/tmp/a/1/.git/objects/n:/usr/games/bin:/usr/local/ipod-chain'
>>>> fatal: The remote end hung up unexpectedly
>>>
>>> I think I see a bug in foreach_alt_odb() to add_refs_from_alternate()
>>> callchain, but I cannot explain why the contents of $PATH leaks to the
>>> error message.
>
> I think the previous patch to sha1_file.c, while it may fix the issue, is
> not quite nice. Here is a replacement that should work.
It does.
--
Mikael Magnusson
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 18:55 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Maxim Vuets, mercurial, git
In-Reply-To: <ee2a733e0810260805n35c3a637v4739dda938a22518@mail.gmail.com>
I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
On Sun, 26 Oct 2008, Leo Razoumov wrote:
> On 10/26/08, Maxim Vuets <maxim.vuets@gmail.com> wrote:
>> On 26 Oct 2008 15:15:57 +0100, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> 1. Documentation and ease of use.
>>>
>>> Mercurial is supposedly better documented and easier to use; I
>>> think this descends from the early days of Git, where it was not
>>> very user friendly. IMHO Git has much improved since. Mercurial
>>> had 'hgbook' from the beginning; Git User's Manual is more recent.
>>
>> Also, there is http://book.git-scm.com/ that is similar to hgbook, I think.
>>
>> Thanks for the comprarision!
>
> I have been using Mercurial for about two years and am very
> comfortable with it. Here are some cons and pros
>
> Mercurial PROS:
> * Easier and more consistent UI. Newbie friendly.
I think that _might_ be example of "Worse is better" scenario, with Git
having UI which evolved rather than was designed, and therefore less
consistent.
Also if you are limiting to what is described in main chapters of
'hgbook', namely one branch (one "fork") per repository paradigm
everything is simpler.
> * Better documentation. IMHO, hgbook is by far better than
> http://book.git-scm.com/
And probably better than "Git User's Manual". There are lot of various
git-related documentation: "Git Magic", "Git for Computer Scientists",
"Git from bottoms up"...
> * Windows support (personally, I do not care)
And I think it is not important for DragonflyBSD.
Besides git _has_ MS Windows support, in the form of Cygwin and in the
form of msysGit project. It is still not as full as Linux support (for
example git-svn comes to mind), but it is not bad. Well, Mercurial
has TortiouseHg, while Git-Cheetah is in very early stages...
>
> Mercurial CONS:
> * Less potential than git. Once Ted Tso even said that "git has more
> legs than mercurial", see
> http://thunk.org/tytso/blog/2007/03/24/git-and-hg/
I agree, and I think it is at least partially because of Git having
cleaner design, even if you have to understand more terms at first.
> * Hg is strictly an SCM system while GIT is a content addressable file
> system that can be used in other ways, hence the name Global
> Information Tracker (GIT)
Errr... I think you are mislead by tongue-in-cheek backronym, which was
created in the beginning, when git had very weak porcelain (i.e. SCM UI).
> * Recently, Hg development seems to have somewhat slowed down. To
> simply put it, there is not enough room in the world for several
> similar SCM systems. With git's pace and momentum the other SCMs
> including Hg are fighting an uphill battle.
The competing _distributed_ version control systems left seems to be
Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,
Freedesktop.org, Ruby on Rails people). There are many IDEs, many
editors, many web browsers; there is Linux and there are *BSD; I hope
that Mercurial would continue to be developed, and not vanish in
obscurity like Arch and clones...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-26 19:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, mercurial
In-Reply-To: <94a0d4530810260857u7c0cb122g8147b9484108f539@mail.gmail.com>
I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
On Sun, 26 Sep 2008, Felipe Contreras wrote:
> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > [Cc: gmane.comp.version-control.git,
> > gmane.comp.version-control.mercurial.general]
> > 3. Repository design and performance.
> > Git and Mercurial have similar performance, although it is thought
> > that due to design Mercurial has faster patch applying and is
> > optimized for cold cache case, while Git has faster merging and is
> > optimized for warm cache case.
> >
> > Mercurial may have (or had) problems with larger binary files, from
> > what I have heard.
>
> The fact that hg is changeset based means that certain operations are
> slower, like checkout a specific commit. In hg my bet is you would
> need to gather a bunch of changesets while in git the operation is
> done in a single step.
Actually from what I have read Mercurial stores current version
(snapshot) from time to time, so time to resolve specific commit is
limited. Also if you have packed your Git repository (good idea not
only to limit size, but also for performance (I/O performance)), then
resolving specific commit also might require some delta resolution
(by default delta chain length is limited to 50, see pack.depth).
> It also means that bare clones are not possible in hg, or at least
> very complicated.
I think it is things like .hgtags which make bare clones (without
working directory) to be hard or even impossible in Mercurial.
> Note: I'm not sure if what I'm claiming is correct.
Hmmm...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2] add -p: warn if only binary changes present
From: Thomas Rast @ 2008-10-26 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, szeder
In-Reply-To: <20081026104006.GA18969@neumann>
Current 'git add -p' will say "No changes." if there are no changes to
text files, which can be confusing if there _are_ changes to binary
files. Add some code to distinguish the two cases, and give a
different message in the latter one.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
SZEDER Gábor wrote:
> What about
>
> Only binary files changed.
>
> or something of the sort?
Yes, why not.
git-add--interactive.perl | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index da768ee..b0223c3 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -811,11 +811,16 @@ EOF
}
sub patch_update_cmd {
- my @mods = grep { !($_->{BINARY}) } list_modified('file-only');
+ my @all_mods = list_modified('file-only');
+ my @mods = grep { !($_->{BINARY}) } @all_mods;
my @them;
if (!@mods) {
- print STDERR "No changes.\n";
+ if (@all_mods) {
+ print STDERR "Only binary files changed.\n";
+ } else {
+ print STDERR "No changes.\n";
+ }
return 0;
}
if ($patch_mode) {
--
tg: (759ad19..) t/add-p-binary-warn (depends on: origin/master)
^ permalink raw reply related
* Re: [PATCH v2] add -p: warn if only binary changes present
From: Jeff King @ 2008-10-26 19:38 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, szeder
In-Reply-To: <1225049826-14941-1-git-send-email-trast@student.ethz.ch>
On Sun, Oct 26, 2008 at 08:37:06PM +0100, Thomas Rast wrote:
> > What about
> >
> > Only binary files changed.
> >
> > or something of the sort?
>
> Yes, why not.
That is better, IMHO.
-Peff
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Felipe Contreras @ 2008-10-26 19:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, mercurial
In-Reply-To: <200810262007.30148.jnareb@gmail.com>
On Sun, Oct 26, 2008 at 9:07 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> I'm not sure if Mercurial mailing list is not subscribe only. Git isn't.
>
> On Sun, 26 Sep 2008, Felipe Contreras wrote:
>> On Sun, Oct 26, 2008 at 4:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> > [Cc: gmane.comp.version-control.git,
>> > gmane.comp.version-control.mercurial.general]
>
>> > 3. Repository design and performance.
>
>> > Git and Mercurial have similar performance, although it is thought
>> > that due to design Mercurial has faster patch applying and is
>> > optimized for cold cache case, while Git has faster merging and is
>> > optimized for warm cache case.
>> >
>> > Mercurial may have (or had) problems with larger binary files, from
>> > what I have heard.
>>
>> The fact that hg is changeset based means that certain operations are
>> slower, like checkout a specific commit. In hg my bet is you would
>> need to gather a bunch of changesets while in git the operation is
>> done in a single step.
>
> Actually from what I have read Mercurial stores current version
> (snapshot) from time to time, so time to resolve specific commit is
> limited. Also if you have packed your Git repository (good idea not
> only to limit size, but also for performance (I/O performance)), then
> resolving specific commit also might require some delta resolution
> (by default delta chain length is limited to 50, see pack.depth).
Ah, ok, good to know.
>> It also means that bare clones are not possible in hg, or at least
>> very complicated.
>
> I think it is things like .hgtags which make bare clones (without
> working directory) to be hard or even impossible in Mercurial.
Oops, I meant shallow clones (git clone --depth=1).
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-26 21:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3k5bvgz83.fsf@localhost.localdomain>
On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> Ah, good idea. Done, in Version Control Interface layers section
>
> Thanks.
>
> I have added link to repositoy, as you didn't configure your gitweb to
> display those URL links (see gitweb/README and gitweb/INSTALL).
Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
computed automatically? Judging by the docs, it seems that I have to
set it manually for each project, like the description.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* git working tree status
From: Mike Clarke @ 2008-10-26 21:54 UTC (permalink / raw)
To: git
Hi all,
I'd like a way of getting a simple summary of the status of a working
tree, for consumption by other programs rather than humans.
Specifically, I'd like to know whether the working tree is:
a) fully 'clean' -- i.e., all changes checked in, no stashes;
b) all changes checked in, but there are some stashes; or
c) 'dirty' in some way -- new files, uncommitted changes, etc.
The logical way to do this seems to be via an exit code, but the exit
code of git status is not currently rich enough. As a result, I'm
considering the addition of an option to git status -- perhaps
'--is-clean' -- that would provide the required information.
My questions are:
1) Is there already some way of doing this that I've overlooked?
2) Would the preferred approach be an option (git status --is-clean)
or a sub-command (git is-clean)? A sub-command would probably result
in cleaner internal code, but would also clutter the interface.
3) Is a patch for such a feature likely to be accepted?
Thanks,
--
Mike Clarke
^ permalink raw reply
* [PATCH] Add mksnpath and git_snpath which allow to specify the output buffer
From: Alex Riesen @ 2008-10-26 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Both are actually just vsnprintf's but additionally call cleanup_path
on the result. To be used as alternatives to mkpath and git_path where
the buffer for the created path may not be reused by subsequent calls
of the same formatting function.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
cache.h | 4 ++++
path.c | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index b0edbf9..a9024db 100644
--- a/cache.h
+++ b/cache.h
@@ -495,6 +495,10 @@ extern int check_repository_format(void);
#define DATA_CHANGED 0x0020
#define TYPE_CHANGED 0x0040
+extern char *mksnpath(char *buf, size_t n, const char *fmt, ...)
+ __attribute__((format (printf, 3, 4)));
+extern char *git_snpath(char *buf, size_t n, const char *fmt, ...)
+ __attribute__((format (printf, 3, 4)));
/* Return a statically allocated filename matching the sha1 signature */
extern char *mkpath(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern char *git_path(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
diff --git a/path.c b/path.c
index 76e8872..85ab28a 100644
--- a/path.c
+++ b/path.c
@@ -32,6 +32,44 @@ static char *cleanup_path(char *path)
return path;
}
+char *mksnpath(char *buf, size_t n, const char *fmt, ...)
+{
+ va_list args;
+ unsigned len;
+
+ va_start(args, fmt);
+ len = vsnprintf(buf, n, fmt, args);
+ va_end(args);
+ if (len >= n) {
+ snprintf(buf, n, bad_path);
+ return buf;
+ }
+ return cleanup_path(buf);
+}
+
+char *git_snpath(char *buf, size_t n, const char *fmt, ...)
+{
+ const char *git_dir = get_git_dir();
+ va_list args;
+ size_t len;
+
+ len = strlen(git_dir);
+ if (n < len + 1)
+ goto bad;
+ memcpy(buf, git_dir, len);
+ if (len && !is_dir_sep(git_dir[len-1]))
+ buf[len++] = '/';
+ va_start(args, fmt);
+ len += vsnprintf(buf + len, n - len, fmt, args);
+ va_end(args);
+ if (len >= n)
+ goto bad;
+ return cleanup_path(buf);
+bad:
+ snprintf(buf, n, bad_path);
+ return buf;
+}
+
char *mkpath(const char *fmt, ...)
{
va_list args;
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Jakub Narebski @ 2008-10-26 22:04 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <cb7bb73a0810261418y3b114e2ag81cbb75c4a80603c@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sun, Oct 26, 2008 at 4:20 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>>
>>> Ah, good idea. Done, in Version Control Interface layers section
>>
>> Thanks.
>>
>> I have added link to repositoy, as you didn't configure your gitweb to
>> display those URL links (see gitweb/README and gitweb/INSTALL).
>
> Oops, right, thanks. BTW, isn't there a way to have the git:// URL be
> computed automatically? Judging by the docs, it seems that I have to
> set it manually for each project, like the description.
gitweb/README:
How to configure gitweb for your local system
---------------------------------------------
[...]
* GITWEB_BASE_URL
Git base URLs used for URL to where fetch project from, i.e. full
URL is "$git_base_url/$project". Shown on projects summary page.
Repository URL for project can be also configured per repository; this
takes precedence over URLs composed from base URL and a project name.
Note that you can setup multiple base URLs (for example one for
git:// protocol access, another for http:// access) from the gitweb
config file. [No default]
[...]
Runtime gitweb configuration
----------------------------
[...]
Gitweb config file variables
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
* @git_base_url_list
List of git base URLs used for URL to where fetch project from, shown
in project summary page. Full URL is "$git_base_url/$project".
You can setup multiple base URLs (for example one for git:// protocol
access, and one for http:// "dumb" protocol access). Note that per
repository configuration in 'cloneurl' file, or as values of gitweb.url
project config.
Ooops, there seems to be a type in above...
Per-repository gitweb configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
* cloneurl (or multiple-valued gitweb.url)
File with repository URL (used for clone and fetch), one per line.
Displayed in the project summary page. You can use multiple-valued
gitweb.url repository configuration variable for that, but the file
takes precedence.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Fix mkpath abuse in dwim_ref and dwim_log of sha1_name.c
From: Alex Riesen @ 2008-10-26 22:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Otherwise the function sometimes fail to resolve obviously correct
refnames, because the string data pointed to by "str" argument were
reused.
The change in dwim_log does not fix anything, just optimizes away
strcpy code as the path can be created directly in the available
buffer.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Was noticed in cygwin port, which somehow (supposedly by excessive
calling of git_config from lstat stub setup) managed to reuse the
just returned buffer.
sha1_name.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 41b6809..159c2ab 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -245,11 +245,13 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
*ref = NULL;
for (p = ref_rev_parse_rules; *p; p++) {
+ char fullref[PATH_MAX];
unsigned char sha1_from_ref[20];
unsigned char *this_result;
this_result = refs_found ? sha1_from_ref : sha1;
- r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
+ mksnpath(fullref, sizeof(fullref), *p, len, str);
+ r = resolve_ref(fullref, this_result, 1, NULL);
if (r) {
if (!refs_found++)
*ref = xstrdup(r);
@@ -272,7 +274,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
char path[PATH_MAX];
const char *ref, *it;
- strcpy(path, mkpath(*p, len, str));
+ mksnpath(path, sizeof(path), *p, len, str);
ref = resolve_ref(path, hash, 1, NULL);
if (!ref)
continue;
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* [PATCH] Fix potentially dangerous uses of mkpath and git_path
From: Alex Riesen @ 2008-10-26 22:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20081026215913.GA18594@blimp.localdomain>
Replace them with mksnpath/git_snpath and a local buffer
for the resulting string.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-apply.c | 4 ++--
builtin-for-each-ref.c | 6 ++++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index cfd8fce..4c4d1e1 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2841,8 +2841,8 @@ static void create_one_file(char *path, unsigned mode, const char *buf, unsigned
unsigned int nr = getpid();
for (;;) {
- const char *newpath;
- newpath = mkpath("%s~%u", path, nr);
+ char newpath[PATH_MAX];
+ mksnpath(newpath, sizeof(newpath), "%s~%u", path, nr);
if (!try_create_file(newpath, mode, buf, size)) {
if (!rename(newpath, path))
return;
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index fa6c1ed..e46b7ad 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -620,14 +620,16 @@ static char *get_short_ref(struct refinfo *ref)
for (j = 0; j < i; j++) {
const char *rule = ref_rev_parse_rules[j];
unsigned char short_objectname[20];
+ char refname[PATH_MAX];
/*
* the short name is ambiguous, if it resolves
* (with this previous rule) to a valid ref
* read_ref() returns 0 on success
*/
- if (!read_ref(mkpath(rule, short_name_len, short_name),
- short_objectname))
+ mksnpath(refname, sizeof(refname),
+ rule, short_name_len, short_name);
+ if (!read_ref(refname, short_objectname))
break;
}
--
1.6.0.3.540.g3f8b
^ permalink raw reply related
* Re: [RFC] Zit (v2): the git-based single file content tracker
From: Giuseppe Bilotta @ 2008-10-26 22:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200810262304.13582.jnareb@gmail.com>
On Sun, Oct 26, 2008 at 11:04 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Gitweb config file variables
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [...]
> * @git_base_url_list
> List of git base URLs used for URL to where fetch project from, shown
> in project summary page. Full URL is "$git_base_url/$project".
> You can setup multiple base URLs (for example one for git:// protocol
> access, and one for http:// "dumb" protocol access). Note that per
> repository configuration in 'cloneurl' file, or as values of gitweb.url
> project config.
Doh, thanks, I had totally overlooked it. Done 8-)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH 5/5] blame: use xdi_diff_hunks(), get rid of struct patch
From: René Scharfe @ 2008-10-26 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Downing, git
In-Reply-To: <7vhc708o1v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Perhaps revision.c in our history would be more interesting than cache.h
> or Makefile, as there are more line migrations from different places to
> that file.
Indeed:
# master
$ /usr/bin/time $blame revision.c >/dev/null
2.15user 0.27system 0:02.58elapsed 94%CPU (0avgtext+0avgdata 0maxresident)k
3544inputs+0outputs (29major+13835minor)pagefaults 0swaps
# this patch series
$ /usr/bin/time $blame revision.c >/dev/null
1.88user 0.14system 0:02.03elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+14068minor)pagefaults 0swaps
René
^ permalink raw reply
* Re: git working tree status
From: Miklos Vajna @ 2008-10-26 22:23 UTC (permalink / raw)
To: Mike Clarke; +Cc: git
In-Reply-To: <73f525b90810261454wb902edfk3a696c06ef2148d1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]
On Sun, Oct 26, 2008 at 09:54:03PM +0000, Mike Clarke <clarkema@gmail.com> wrote:
> a) fully 'clean' -- i.e., all changes checked in, no stashes;
In case you want to ignore ignores:
$ git ls-files -o
otherwise:
git ls-files -o --exclude-standard
by 'stashes', I guess you mean those extra files, but using that term is
confusing, given that stashes can be listed with git stash list and they
are actually merge commits (so something totally different).
> b) all changes checked in, but there are some stashes; or
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" && echo "everything committed"
> c) 'dirty' in some way -- new files, uncommitted changes, etc.
git update-index -q --refresh
test -z "$(git diff-index --name-only HEAD --)" && echo "dirty"
see GIT-VERSION-GEN in git.git
> 1) Is there already some way of doing this that I've overlooked?
> 2) Would the preferred approach be an option (git status --is-clean)
> or a sub-command (git is-clean)? A sub-command would probably result
> in cleaner internal code, but would also clutter the interface.
I guess you overlooked the fact that plumbing is supposed to be used
from scripts and porcelain by the users. git status is porcelain, so
in general just don't use it from scripts.
> 3) Is a patch for such a feature likely to be accepted?
I don't think so, see above.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git working tree status
From: Miklos Vajna @ 2008-10-26 22:26 UTC (permalink / raw)
To: Mike Clarke; +Cc: git
In-Reply-To: <20081026222335.GJ2273@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 307 bytes --]
On Sun, Oct 26, 2008 at 11:23:35PM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > c) 'dirty' in some way -- new files, uncommitted changes, etc.
>
> git update-index -q --refresh
> test -z "$(git diff-index --name-only HEAD --)" && echo "dirty"
I wanted to write '|| echo "dirty"', sorry.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 0:20 UTC (permalink / raw)
To: mercurial; +Cc: Jakub Narebski, SLONIK.AZ, git
In-Reply-To: <200810261955.10536.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> > * Recently, Hg development seems to have somewhat slowed down. To
> > simply put it, there is not enough room in the world for several
> > similar SCM systems. With git's pace and momentum the other SCMs
> > including Hg are fighting an uphill battle.
>
> The competing _distributed_ version control systems left seems to be
> Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel,
> Freedesktop.org, Ruby on Rails people). There are many IDEs, many
> editors, many web browsers; there is Linux and there are *BSD; I hope
> that Mercurial would continue to be developed, and not vanish in
> obscurity like Arch and clones...
Before we get tangled in this train of thought:
I created a head-to-head code_swarm of Mercurial and Git and it clearly shows
that Mercurial development didn't slow down.
The code_swarm isn't a fancy one with music and annotations, but I think
you'll directly see for yourself what I mean:
- http://www.rakjar.de/shared_codeswarm/hg-vs-git-short.avi
red is git,
blue is Mercurial.
It is a result of my shared_codeswarm project with which you can create
code_swarms from more than one repository automatically - and update them
incrementally, creating new code_swarms of only the new commits in the
repositories:
- http://www.rakjar.de/shared_codeswarm/project_activity_battle_swarm.html
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-cvsimport produces different (broken) repos when using pserver or local repo access
From: Roger Leigh @ 2008-10-27 0:25 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 3350 bytes --]
Hi,
I've noticed that git-cvsimport can under some circumstances produce broken
repositories. This appears to only occur when using pserver access to the CVS
repo; running with a local repo is apparently fine, with all tested versions
giving the same repo (master head has same hash for the last commit).
In all cases cvsps version 2.1 was used.
Repo source:
pserver :pserver:anonymous@gimp-print.cvs.sourceforge.net:/cvsroot/gimp-print
local rsync -av 'rsync://gimp-print.cvs.sourceforge.net/cvsroot/gimp-print/*' cvs-backup
I've tested with a number of git versions, including git.git as of yesterday:
git version repo last commit URI
1.5.5.GIT local a51c479826 git://git.debian.org/git/users/rleigh/gutenprint-upstream.git
1.5.5.GIT (2 failures) pserver bfa6f8248a git://git.debian.org/git/users/rleigh/gutenprint-upstream-broken.git
1.5.5.GIT (no failure) pserver bfa6f8248a git://git.debian.org/git/users/rleigh/gutenprint-upstream-pserver.git
1.5.6.5 local a51c479826 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.5.6.5-local.git
1.5.6.5 pserver 6f0950c097 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.5.6.5-pserver.git
git.git 1.6.0.3.517.g759a local a51c479826 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.6-local.git
git.git 1.6.0.3.517.g759a pserver 6f0950c097 git://git.debian.org/git/users/rleigh/gutenprint-upstream-git1.6-pserver.git
With git 1.5.5 I'm tracking the CVS repo running git-cvsimport every 20 mins
from a cron job. A few months ago it managed to botch, resulting in a broken
repo (it didn't delete files deleted from CVS). I think this occurs when
git-cvsimport fails (I get a perl error, though I'm afraid I don't have the log
anymore); running again results in successful completion, but the repo is
screwed, I think due to that commit being incomplete or something. This
occured twice during the import in the second line in the above table, in this
case resulting in missing files (src/cups/i18n.*). Again, I'm afraid I don't
have the logs, but I can repeat again if this is not an already known/fixed
issue. The repo is quite big, taking several hours to import, so it might
possibly be a network connection problem and it's not handling that correctly
on failure. However, even when the import comples successfully (line 3), the
hash is still the same as line 2 where it failed twice and needed restarting.
So, it looks like depending on if I use a local repo directly or remove via
pserver, I get a different repo. 1.5.5 using pserver is different to later
versions, presumably this is a buggy version because it's broken whether or not
I get a failure. Later versions always completed without failure; while the
local and pserver using repos differ, they do both seem OK. However, I would
have expected identical results, given that they are all created from the
same data.
The script I used to do the import is attached.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
[-- Attachment #1.2: gutenprint-bootstrap --]
[-- Type: text/plain, Size: 577 bytes --]
#!/bin/bash
CVSROOT=:pserver:anonymous@gimp-print.cvs.sourceforge.net:/cvsroot/gimp-print
CVSMODULE=print
HOME=/home/users/rleigh
GIT_DIR=/var/lib/gforge/chroot/home/users/rleigh/public_git/gutenprint-upstream.git
LOGDIR=${HOME}/log
LOCKFILE=${HOME}/gutenprint-cvs.lock
AUTHORS=${HOME}/gutenprint-auth
#date -R
lockfile -2 -r 2 ${LOCKFILE}
# If we managed to lock the file
if [ $? -eq 0 ]; then
# echo "Running git-cvsimport"
export GIT_DIR
export CVSROOT
git-cvsimport -A $AUTHORS -i -v print
rm -f ${LOCKFILE}
else
echo "Couldn't get lock for cvssuck"
fi
#date -R
[-- Attachment #1.3: gutenprint-auth --]
[-- Type: text/plain, Size: 1881 bytes --]
andystewart=Andy Stewart <andystewart@attbi.com>
anikin=Eugene Anikin <eugene@anikin.com>
cpbs=Charles Briscoe-Smith <cpbs@debian.org>
daberti=Daniele Berti <daberti@users.sourceforge.net>
davehill=Dave Hill <dave@minnie.demon.co.uk>
degger=Daniel Egger <degger@users.sourceforge.net>
doctormo=Martin Owens <doctormo@users.sourceforge.net>
dpace=David Pace <dpace@echo-on.net>
easysw=Mike Sweet <msweet@apple.com>
faust3=Sascha Sommer <saschasommer@freenet.de>
gandy=Andy Thaller <thaller@ph.tum.de>
gtaylor=Grant Taylor <gtaylor@users.sourceforge.net>
iay=Ian Young <ian@iay.org.uk>
jmv=Jean-Marc Verbavatz <verbavatz@ifrance.fr>
julianbradfield=Julian Bradfield <julianbradfield@users.sourceforge.net>
khk=Karl Heinz Kremer <khk@khk.net>
m0m=Michael Mraka <michael.mraka@linux.cz>
mbroughtn=mbroughtn <mbroughtn@users.sourceforge.net>
menthos=Christian Rose <menthos@users.sourceforge.net>
mitsch=Michael Natterer <mitschel@cs.tu-berlin.de>
mtomlinson=Mark Tomlinson <mark.tomlinson@xtra.co.nz>
nestordi=nestor di <nestordi@users.sourceforge.net>
nicholas=nicholas <nicholas@users.sourceforge.net>
peter_missel=Peter Missel <peter_missel@users.sourceforge.net>
rblancha=Richard Blanchard <rblancha@users.sourceforge.net>
rleigh=Roger Leigh <rleigh@debian.org>
rlk=Robert Krawitz <rlk@alum.mit.edu>
rwisi=Richard Wisenoecker <Richard.Wisenoecker@gmx.at>
sharkey=Eric Sharkey <sharkey@debian.org>
smiller=Steve Miller <smiller@rni.net>
spa=Salvador Abreu <spa@users.sourceforge.net>
stevek=Steve Kann <stevek@stevek.com>
tillkamppeter=Till Kamppeter <till.kamppeter@gmail.com>
ttonino=Thomas Tonino <ttonino@bio.vu.nl>
tylerb=Tyler Blessing <tylerb@users.sourceforge.net>
uid21630=uid21630 <uid21630@users.sourceforge.net>
wiz=Joseph S. Wisniewski <wiz@users.sourceforge.net>
wollvieh=Wolfgang Bauer <wollvieh@users.sourceforge.net>
zoopa =Pete Parks <zoopa@users.sourceforge.net>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Arne Babenhauserheide @ 2008-10-27 0:47 UTC (permalink / raw)
To: mercurial; +Cc: Jakub Narebski, SLONIK.AZ, git
In-Reply-To: <200810261955.10536.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1820 bytes --]
Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> I agree, and I think it is at least partially because of Git having
> cleaner design, even if you have to understand more terms at first.
What do you mean by "cleaner design"?
From what I see (and in my definition of "design"), Mercurial is designed as
VCS with very clear and clean design, which even keeps things like streaming
disk access in mind.
Also, looking at git, git users still have to garbage collect regularly, which
shows to me that the design wasn't really cleaner.
As an example: If I want some revision in hg, my repository just reads the
files in the store, jumps to the latest snapshots, adds the changes after
these and has the data.
In git is has to check all changesets which affect the file.
If you read the hgbook, you'll find one especially nice comment:
"Unlike many revision control systems, the concepts upon which Mercurial is
built are simple enough that it’s easy to understand how the software really
works. Knowing this certainly isn’t necessary, but I find it useful to have a
“mental model” of what’s going on."
- http://hgbook.red-bean.com/hgbookch4.html
I really like that, and in my opinion it is a great compliment to hg, for two
reasons:
1) Hg is easy to understand
2) You don't have to understand it to use it
And both are indications of a good design, the first of the core, the second
of the UI.
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 1:52 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: mercurial, SLONIK.AZ, git
In-Reply-To: <200810270147.52490.arne_bab@web.de>
On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> >
> > I agree, and I think it is at least partially because of Git having
> > cleaner design, even if you have to understand more terms at first.
>
> What do you mean by "cleaner design"?
Clean _underlying_ design. Git has very nice underlying model of graph
(DAG) of commits (revisions), and branches and tags as pointers to this
graph.
> From what I see (and in my definition of "design"), Mercurial is designed as
> VCS with very clear and clean design, which even keeps things like streaming
> disk access in mind.
I have read description of Mercurial's repository format, and it is not
very clear in my opinion. File changesets, bound using manifest, bound
using changerev / changelog.
Mercurial relies on transactions and O_TRUNC support, while Git relies
on atomic write and on updating data then updating reference to data.
I don't quite understand comment about streaming disk access...
> Also, looking at git, git users still have to garbage collect regularly, which
> shows to me that the design wasn't really cleaner.
Well, they have to a lot less than they used to, and there is
"git gc --auto" that can be put in crontab safely.
Explicit garbage collection was a design _decision_, not a sign of not
clear design. We can argue if it was good or bad decision, but one
should consider the following issues:
* Rolling back last commit to correct it, or equivalently amending
last commit (for example because we forgot some last minute change,
or forgot to signoff a commit), or backing out of changes to the
last commit in Mercurial relies on transactions (and locking) and
correct O_TRUNC, while in Git it leaves dangling objects to be
garbage collected later.
* Mercurial relies on transaction support. Git relies on atomic write
support and on the fact that objects are immutable; those that are
not needed are garbage collected later. Beside IIRC some of ways of
implementing transaction in databases leads to garbage collecting.
* Explicit packing and having two repository "formats": loose and
packed is a bit of historical reason: at the beginning there was
only loose format. Pack format was IIRC invented for network
transport, and was used for on disk storage (the same format!) for
better I/O patterns[1]. Having packs as 'rewrite to pack' instead
of 'append to pack' allows to prefer recency order, which result in
faster access as objects from newer commits are earlier in delta
chain and reduction in size in usual case of size growing with time
as recency order allows to use delete deltas. Also _choosing_ base
object allows further reduce size, especially in presence of
nonlinear history.
* From what I understand Mercurial by default uses packed format for
branches and tags; Git uses "loose" format for recent branches
(meaning one file per branch), while packing older references.
Using loose affects performance (and size) only for insane number of
references, and only for some operations like listing all references,
while using packed format is IMHO a bit error prone when updating.
* Git has reflogs which are pruned (expired) during garbage collecting
to not grow them without bounds; AFAIK Mercurial doesn't have
equivalent of this feature.
(Reflogs store _local_ history of branch tip, noting commits,
fetches, merges, rewinding branch, switching branches, etc._
[1] You wrote about "streaming disk access". Git relies (for reading)
on good mmap implementation.
> As an example: If I want some revision in hg, my repository just reads the
> files in the store, jumps to the latest snapshots, adds the changes after
> these and has the data.
If you want to show some revision in Git, meaning commit message and
diff in patch format (result of "git show"), Git just reads the commit,
outputs commit message, reads parent, reads trees and performs diff.
If you want to checkout to specific revision, Git just reads commit,
reads tree, and writes this tree (via index) to working area.
> In git is has to check all changesets which affect the file.
I don't understand you here... if I understand correctly above,
then you are wrong about Git.
> If you read the hgbook, you'll find one especially nice comment:
>
> "Unlike many revision control systems, the concepts upon which Mercurial is
> built are simple enough that it’s easy to understand how the software really
> works. Knowing this certainly isn’t necessary, but I find it useful to have a
> “mental model” of what’s going on."
> - http://hgbook.red-bean.com/hgbookch4.html
>
> I really like that, and in my opinion it is a great compliment to hg, for two
> reasons:
>
> 1) Hg is easy to understand
Because it is simple... and less feature rich, c.f. multiple local
branches in single repository.
> 2) You don't have to understand it to use it
You don't have to understand details of Git design (pack format, index,
stages, refs,...) to use it either.
>
> And both are indications of a good design, the first of the core, the second
> of the UI.
Well, Git is built around concept of DAG of commits and branches as
references to it. Without it you can use Git, but it is hard. But
if you understand it, you can understand easily most advanced Git
features.
I agree that Mercurial UI is better; as usually in "Worse is Better"
case... :-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [ANNOUNCE] intergit repository-linking tool (early release)
From: Christian Jaeger @ 2008-10-27 2:22 UTC (permalink / raw)
To: Git Mailing List; +Cc: gambit-list
Hello
Ten days ago I started a thread about "Separating generated files?" [1],
and suggested in the end that instead of using git submodule
functionality, one might be better off using a tool which can, upon
committing files in the repository containing generated files, add a
link ("reference") pointing to the commit in the source repository which
represents the source files they have been generated from, and then when
someone is checking out some revision of the source files later, use
this information to find the (best-)matching commit in the repository
with the generated files. This may also be useful in other situations
where one likes to keep repositories separate but they have a version
dependency on each other.
I've now written a first version of a pair of these two programs, which
accomplishes this. You can get them from:
http://www.christianjaeger.ch/dyn/pubgit/gitweb?p=intergit.git;a=summary
git clone http://christianjaeger.ch/pubgit/intergit.git
This will need some finish before really being production ready; it will
mainly need some experimentation on how it is to be used exactly, so
that possibly missing features in the search and indexing algorithms can
be added (like whether it should understand merges between two commits
containing references as a commit having both references even if the
merge commit doesn't specify a reference), and I'm also keen on some
feedback implementation-wise (building the index is currently slow, and
some of the problems that I'm listing in the docs (Implementation.txt
and TODO.txt) may have solutions I've not been aware of). I've tried to
add some useful documentation (see *.txt files), so I'm hoping this
helps anyone interested to understand how it works, or just give me some
feedback on how it may or may not be useful.
I've developed and tested it on Linux. Hints on whether it works under
other systems and how to make it work with msysgit would be very
appreciated.
Christian
[1] http://marc.info/?l=git&m=122415845625044&w=2
PS. I've just noticed the thread about "repo - The Multiple Git
Repository Tool". I'll have to take a look first to see how it is
related to my program--it may take me a few days as I'll be busy.
--
My OpenPGP fingerprint: F033 D030 F75D E445 05A1 1865 4ECB DF80 1FE6 92DA
^ permalink raw reply
* Problems during upgrade git from 1.5.3.2 to latest
From: horry @ 2008-10-27 2:29 UTC (permalink / raw)
To: git
Hello ,
My previous git version is 1.5.3.2 and i perform the suggested commands :
git clone http://www.kernel.org/pub/scm/git/git.git and it goes well , end
up with :
....................................................................
got d00da833cbeec16da9415e0ac11269594279545a
Checking 1480 files out...
100% (1480/1480) done
Then i checked git version , it still shows previous version without any
change .
XXXXXXX:/apps/mds_lrt/git/git> git version
git version 1.5.3.2
Is there additional command which i should perform after clone ?
thanks,
Horry
--
View this message in context: http://www.nabble.com/Problems-during-upgrade-git-from-1.5.3.2-to-latest-tp20180862p20180862.html
Sent from the git mailing list archive at Nabble.com.
^ 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