* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-05 7:56 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, Junio C Hamano
In-Reply-To: <44AAF49F.6090008@gmail.com>
Hi,
On Tue, 4 Jul 2006, A Large Angry SCM wrote:
> Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 4 Jul 2006, Junio C Hamano wrote:
> >
> > > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >
> > > > We could introduce a time.maximumSkew variable, and just walk only that
> > > > much further when traversing the commits.
> > > We could have had "commit generation number" in the commit
> > > object header, and use that instead of commit timestamps for
> > > these traversal purposes. The generation number for a commit is
> > > defined to be max(generation number of its parents)+1 and we
> > > prime the recursive this definition by defining the generation
> > > number for the root commit to be one.
> >
> > Are you really, really sure this is a remedy? I, for one, am quite sure of
> > the opposite. What you propose is just another time scale, only this time,
> > it is not universally true (not even minus local incompetence to keep the
> > clock accurate).
>
> It works[*] and it does what using the timestamp was trying to do. Namely,
> work from "more recent" (or "closer") commits toward "older" (or "farther")
> commits until you've gone past the point you care about.
>
> It's a little late to be changing the structure of a commit and you'd have to
> deal with some size/scale issues, but it's do-able. A better idea may be to
> generate and keep the generation number on a per repository basis, and you'd
> be able to work around changing grafts.
Like, inside the cache? I dunno. IMHO it is way too late to change the
structure of a commit in that particular manner, _plus_ you would get
overflow issues.
> [*] Grafts do _really_ nasty things to this. Just like clock skew does now.
Grafts can do much nastier things to you, for example having a circular
history. _But_ they cannot do that nasty thing outside of your repo. Clock
skews can.
Ciao,
Dscho
^ permalink raw reply
* Re: Experimental "git prune"
From: Johannes Schindelin @ 2006-07-05 7:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607041539550.12404@g5.osdl.org>
Hi,
On Tue, 4 Jul 2006, Linus Torvalds wrote:
> static void process_tag(struct tag *tag, struct object_array *p, const char *name)
> {
> struct object *obj = &tag->object;
> struct name_path me;
AFAICS this variable is set, but not used:
>
> if (obj->flags & SEEN)
> return;
> obj->flags |= SEEN;
>
> me.up = NULL;
> me.elem = "tag:/";
> me.elem_len = 5;
>
> if (parse_tag(tag) < 0)
> die("bad tag object %s", sha1_to_hex(obj->sha1));
> add_object(tag->tagged, p, NULL, name);
> }
As for the rest, I like it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Josef Weidendorfer @ 2006-07-05 8:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8xn9gjh5.fsf@assigned-by-dhcp.cox.net>
On Tuesday 04 July 2006 23:15, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > We could introduce a time.maximumSkew variable, and just walk only
> > that much further when traversing the commits.
>
> We could have had "commit generation number" in the commit
> object header, and use that instead of commit timestamps for
> these traversal purposes.
Isn't this "commit generation number" information that can be
regenerated on the fly, i.e. a perfect fit for data to be stored
in a persistant cache, e.g. in ".git/tmp/virtual-commit-timestamps"?
Josef
^ permalink raw reply
* Re: Strange date format in git-send-email
From: Jakub Narebski @ 2006-07-05 9:00 UTC (permalink / raw)
To: git
In-Reply-To: <200607050817.37366.martijn.kuipers@lx.it.pt>
Martijn Kuipers wrote:
> My email is sorted by date and a number of email-patches list the date format
> as unknown (in kmail, that is).
>
> When checking the headers of these mails I see the following pattern:
>
> Date: mer, 05 jui 2006 00:36:08 +0200
> X-Mailer: git-send-email 1.4.1
>
> Date: wto, 20 cze 2006 17:59:19 +0200
> X-Mailer: git-send-email 1.3.0
>
> Date: Tue, Mar 14 12:12:35 2006 -0500
> User-Agent: send_patch 0.1
>
> Date: Tue Feb 7 18:21:02 2006 +0100
[...]
> Is this my problem (or kmail), or is there something funny with
> git-send-email? I just don't git it.
Yes, there was a problem with git-sen-email, namely it used strftime
to print "Date:" header, but strftime is locale specific setting
$ENV{LC_ALL} = 'C' is not enought.
There were two patches on the list: one hacky adding setlocale
call (not applied), second implementing rfc-822 date in Perl.
Should be in current.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [BUG] git-svn: svn URL is a path to a directory
From: Santi @ 2006-07-05 9:26 UTC (permalink / raw)
To: Git Mailing List
Hi *,
currently it is used as a prefix. So, if you have a repository as:
/path/to/repository/project/file
/path/to/repository/project-2/file
and execute:
git-svn init file:///path/to/repository/project
git-svn fetch
you end up with a project with the following files:
file
-2/file
As a real example you could try:
git-svn init svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6/
git-svn fetch -r5040:5060
See you
Santi
--
Looking for signature...
Looking for signature...done
^ permalink raw reply
* Re[1]:hello from Galia S.
From: Galya S. @ 2006-07-05 9:39 UTC (permalink / raw)
To: bk-commits-head-owner
Ave !
I want to start my first letter from a question: "Is it possible to be happy without LOVE?"
I think that you will agree with me if the answer will be "NO WAY". Love is the most beautiful and exciting thing
that may happen between man and woman! It inspires us only for doing positive things towards each other.
One very famous writer said: "The beauty will rescue the world" i agree with his words but still i would add :
" LOVE and Beauty will rescure the world".
I hope you agree with me that Love is a big notion.
There's love to God, to Mother, to a child to the country where you were born, and there's love that joins a man
and woman for all their life. That is the LOVE i'm looking for! And i'm seeking for the man who is also eager to have
this life long adventure full of surprises and new experience we can share together! Will you join me for this trip?
I do realise that it should be very difficult to say "Yes" from the first letter having no idea about me.
That's why i just offer to get to know each other better though correspondence that will help us to reveal many things
about each other whether we mach perfectly or not. In addition you can look at my pictures and read some info about me here
http://foryou-mydestiny.com/
I hope you'll like what you see and read there.
Well closing my first letter to you i just want to thank you for reading it and i really hope that you'll share
my point of view on what i said above. I do really hope that you'll answer me soon.
Best regards,
Galya S.
^ permalink raw reply
* Re: Can't import Xenomai svn repo
From: llandre @ 2006-07-05 10:04 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: git
In-Reply-To: <20060704101704.G3a844991@leonov.stosberg.net>
Dennis,
thanks a lot for your help.
This command starts fine but ...
git-svnimport -C xenomai2.git svn://svn.gna.org/xenomai
... after a while it fails:
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committing initial tree 77c387d69d2880a9c3f25764b952e821af919755
Network connection closed unexpectedly: Connection closed unexpectedly
at /usr/bin/git-svnimport line 348
--
llandre
DAVE Electronics System House - R&D Department
web: http://www.dave-tech.it
email: r&d2@dave-tech.it
>> I tried to import Xenomai svn repo but the script failed:
>>
>> git-svnimport -v -C xenomai.git http://svn.gna.org/xenomai/trunk
>> RA layer request failed: PROPFIND request failed on '/xenomai/trunk':
>> PROPFIND of '/xenomai/trunk': 405 Method Not Allowed (http://svn.gna.org) at
>> /usr/bin/git-svnimport line 135
>
> Looks like the repository is simply not accessible by http.
>
> $ svn co http://svn.gna.org/xenomai/trunk
> svn: PROPFIND request failed on '/xenomai/trunk'
> svn: PROPFIND of '/xenomai/trunk': 405 Method Not Allowed (http://svn.gna.org)
>
> git-svnimport imports a complete svn repository including its
> branches and tags (as long as the svn repo follows the official
> layout). So you would run it against the repository's root:
>
> git svnimport svn://svn.gna.org/xenomai/
>
> If you want to import/track the trunk only (and maybe commit to it),
> git-svn from git's contrib is probably what you want.
>
> Regards,
> Dennis
>
>
^ permalink raw reply
* [PATCH] git-svn: avoid fetching files outside of the URL we're tracking
From: Eric Wong @ 2006-07-05 12:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi, git, Eric Wong
Thanks to Santi <sbejar@gmail.com> for the bug report and explanation:
> /path/to/repository/project/file
> /path/to/repository/project-2/file
<...>
> you end up with a project with the following files:
>
> file
> -2/file
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 08e36be..6d49109 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -2625,7 +2625,7 @@ sub libsvn_connect {
sub libsvn_get_file {
my ($gui, $f, $rev) = @_;
my $p = $f;
- return unless ($p =~ s#^\Q$SVN_PATH\E/?##);
+ return unless ($p =~ s#^\Q$SVN_PATH\E/##);
my ($hash, $pid, $in, $out);
my $pool = SVN::Pool->new;
--
1.4.1.ge255
^ permalink raw reply related
* [PATCH] git-cvsexportcommit dies on merge commits
From: Peter Baumann @ 2006-07-05 13:25 UTC (permalink / raw)
To: git
Signed-off-by: Peter Baumann <siprbaum@stud.informatik.uni-erlangen.de>
---
git-cvsexportcommit.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-cvsexportcommit.perl b/git-cvsexportcommit.perl
index d1051d0..5dcb2f9 100755
--- a/git-cvsexportcommit.perl
+++ b/git-cvsexportcommit.perl
@@ -63,15 +63,15 @@ foreach my $p (@commit) {
}
if ($parent) {
+ my $found;
# double check that it's a valid parent
foreach my $p (@parents) {
- my $found;
if ($p eq $parent) {
$found = 1;
last;
}; # found it
- die "Did not find $parent in the parents for this commit!";
}
+ die "Did not find $parent in the parents for this commit!" if !$found;
} else { # we don't have a parent from the cmdline...
if (@parents == 1) { # it's safe to get it from the commit
$parent = $parents[0];
--
1.4.0
^ permalink raw reply related
* Re: [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-05 14:28 UTC (permalink / raw)
To: Josef Weidendorfer, git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <200607051039.53288.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> On Tuesday 04 July 2006 23:15, Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> We could introduce a time.maximumSkew variable, and just walk only
>>> that much further when traversing the commits.
>> We could have had "commit generation number" in the commit
>> object header, and use that instead of commit timestamps for
>> these traversal purposes.
>
> Isn't this "commit generation number" information that can be
> regenerated on the fly, i.e. a perfect fit for data to be stored
> in a persistant cache, e.g. in ".git/tmp/virtual-commit-timestamps"?
Yes
^ permalink raw reply
* Re: stgit: bunch of bugreports/wishes
From: Catalin Marinas @ 2006-07-05 14:29 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20060622221425.GA7851@nowhere.earth>
On 22/06/06, Yann Dirson <ydirson@altern.org> wrote:
> - "push --undo" is not robust. On the occasion reproduced below, I
> had to rollback the push myself by hand-modifying the stgit data,
> which took me some effort. I'll have to gather precise info, but the
> issue occurs on patch reordering, on a genuine conflict, and seems to
> be involve a change to a non-existent file, when that file would have
> been added by a non-applied patch originally below the one I attempted
> to apply.
I fixed this bug and I'll push the changes tonight. It was caused by a
"git-diff-index" call with files but without the "--" argument. When
the file was actually missing from the repository, git was confused
and returned an error. The 'status --reset' command was failing in
this situation as well.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: A Large Angry SCM @ 2006-07-05 16:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0607050952140.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Jul 2006, A Large Angry SCM wrote:
>
>> Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Tue, 4 Jul 2006, Junio C Hamano wrote:
>>>
>>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>>>
>>>>> We could introduce a time.maximumSkew variable, and just walk only that
>>>>> much further when traversing the commits.
>>>> We could have had "commit generation number" in the commit
>>>> object header, and use that instead of commit timestamps for
>>>> these traversal purposes. The generation number for a commit is
>>>> defined to be max(generation number of its parents)+1 and we
>>>> prime the recursive this definition by defining the generation
>>>> number for the root commit to be one.
>>> Are you really, really sure this is a remedy? I, for one, am quite sure of
>>> the opposite. What you propose is just another time scale, only this time,
>>> it is not universally true (not even minus local incompetence to keep the
>>> clock accurate).
>> It works[*] and it does what using the timestamp was trying to do. Namely,
>> work from "more recent" (or "closer") commits toward "older" (or "farther")
>> commits until you've gone past the point you care about.
>>
>> It's a little late to be changing the structure of a commit and you'd have to
>> deal with some size/scale issues, but it's do-able. A better idea may be to
>> generate and keep the generation number on a per repository basis, and you'd
>> be able to work around changing grafts.
>
> Like, inside the cache? I dunno. IMHO it is way too late to change the
> structure of a commit in that particular manner, _plus_ you would get
> overflow issues.
Your don't need to change the commit object, create some repository
specific, local, auxiliary information. Overflow should not be a problem
until a path length to a root commit exceeds the machine word size.
But is it really worth the work? Does it help anything other than
merge-base?
>> [*] Grafts do _really_ nasty things to this. Just like clock skew does now.
>
> Grafts can do much nastier things to you, for example having a circular
> history. _But_ they cannot do that nasty thing outside of your repo. Clock
> skews can.
If grafts in your repository create a cycle, the misbehavior of
merge-base should be among the least of your concerns.
^ permalink raw reply
* Re: Experimental "git prune"
From: Linus Torvalds @ 2006-07-05 16:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0607050956240.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, 5 Jul 2006, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 4 Jul 2006, Linus Torvalds wrote:
>
> > static void process_tag(struct tag *tag, struct object_array *p, const char *name)
> > {
> > struct object *obj = &tag->object;
> > struct name_path me;
>
> AFAICS this variable is set, but not used:
>
> >
> > if (obj->flags & SEEN)
> > return;
> > obj->flags |= SEEN;
> >
> > me.up = NULL;
> > me.elem = "tag:/";
> > me.elem_len = 5;
> >
> > if (parse_tag(tag) < 0)
> > die("bad tag object %s", sha1_to_hex(obj->sha1));
> > add_object(tag->tagged, p, NULL, name);
Yeah, that NULL should be "&me".
That said, we don't actually use the object name logic at all, so we could
drop it entirely. Having it _might_ allow some of the error messages to be
better, who knows..
Linus
^ permalink raw reply
* Re: git-fetch per-repository speed issues
From: Linus Torvalds @ 2006-07-05 16:40 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20060705064749.GA3617@segfault.peff.net>
On Wed, 5 Jul 2006, Jeff King wrote:
>
> Either you're wrong or there's a bug in git-fetch.
I was wrong - I forgot the git-ls-remote (which really should be
unnecessary, but the way the git-fetch-pack works, we end up
re-connecting).
Linus
^ permalink raw reply
* Re: [PATCH] Add a custom ./configure script
From: Alex Riesen @ 2006-07-05 16:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20060704215747.GQ29115@pasky.or.cz>
On 7/4/06, Petr Baudis <pasky@suse.cz> wrote:
> >
> > If you named it for example configure.sh, then autoconf generated version,
> > and your by hand created version could coexist.
>
> I'm not opposed to it per se, but I'm just not sure if it makes any
> sense to support them both in parallel, since then you have parallel
> infrastructure doing the exactly same thing, or worse yet - performing
> a subtly different set of tests. The benefit is unclear to me.
The benefit is on user side: he'll take what works for him, without waiting
for you or Jakub to fix it for him.
> Another thing is that it's named *everywhere* ./configure and if I use a
> different name now then it will be hard to rename.
but it not the same configure as "everywhere". It's your very own script.
That said, I like your script better than the autoconf thing.
^ permalink raw reply
* git reset --hard include/linux/config.h
From: Sam Ravnborg @ 2006-07-05 16:58 UTC (permalink / raw)
To: git
While working on something unrelated I just did a quick hack
in include/linux/config.h
When done I wanted to get rid of the changes so I did:
git reset --hard include/linux/config.h
And the changes made to include/linux/config.h was indeed gone, with
all the other changes I had in other files.
Now git reset is maybe supposed to work on commit level only, but it
would have been nice if it erroroed out when it saw an argument that
it did not know about. In this case I assume git reset used
"include/linux/config.h" as <commitish>.
Also what is the right command to bring back a file to the original
state after doing some modifications that was not needed anyway?
Sam
^ permalink raw reply
* Re: [PATCH] Additional merge-base tests
From: Johannes Schindelin @ 2006-07-05 17:04 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, Junio C Hamano
In-Reply-To: <44ABE596.40103@gmail.com>
Hi,
On Wed, 5 Jul 2006, A Large Angry SCM wrote:
> If grafts in your repository create a cycle, the misbehavior of merge-base
> should be among the least of your concerns.
Right. BUT grafts can be very helpful to connect branches which were
independently imported into git. And in these cases, the clockSkew really
is no clockSkew. But in that case, the generation number would have to be
recalculated also.
Anyway, I think that it should be a configurable, which defaults to off,
i.e. in the normal case merge-base should behave as it does now. And if we
have that configurable, we might as well take the safe but dumb approach
to just traverse _everything_.
Ciao,
Dscho
^ permalink raw reply
* Re: git reset --hard include/linux/config.h
From: Alex Riesen @ 2006-07-05 17:05 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20060705165801.GA11822@mars.ravnborg.org>
On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> Also what is the right command to bring back a file to the original
> state after doing some modifications that was not needed anyway?
git checkout HEAD include/linux/config.h
^ permalink raw reply
* Re: git reset --hard include/linux/config.h
From: Sam Ravnborg @ 2006-07-05 17:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0607051005s59315296tfb68345959a14c1b@mail.gmail.com>
On Wed, Jul 05, 2006 at 07:05:27PM +0200, Alex Riesen wrote:
> On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> >Also what is the right command to bring back a file to the original
> >state after doing some modifications that was not needed anyway?
>
> git checkout HEAD include/linux/config.h
Thanks!
By the way - the modifications to include/linux/config.h was not lost.
But git apperantly managed to be fooled to think the file was
up-to-date.
Sam
^ permalink raw reply
* Re: git reset --hard include/linux/config.h
From: Alex Riesen @ 2006-07-05 17:29 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20060705171406.GA17834@mars.ravnborg.org>
On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> On Wed, Jul 05, 2006 at 07:05:27PM +0200, Alex Riesen wrote:
> > On 7/5/06, Sam Ravnborg <sam@ravnborg.org> wrote:
> > >Also what is the right command to bring back a file to the original
> > >state after doing some modifications that was not needed anyway?
> >
> > git checkout HEAD include/linux/config.h
>
> Thanks!
>
> By the way - the modifications to include/linux/config.h was not lost.
> But git apperantly managed to be fooled to think the file was
> up-to-date.
After that checkout or after reset --hard? Both is quiet unusual, though
^ permalink raw reply
* Re: Why's Git called Git ?
From: Aaron Gray @ 2006-07-05 19:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607032022050.12404@g5.osdl.org>
Anyway good going, I am glad Linux has an open source VCS again now.
I do not know how BitKeeper are going to fell knowing they have been
replaced by a Git :)
I am toying with using a VCS for a set of related projects, either CVS
because its well known, SubVersion for ease of use, or Git as it is new.
Lots to descide upon, any pointers would be appreciated.
All the best to the Git team.
Regards,
Aaron
----- Original Message -----
From: "Linus Torvalds" <torvalds@osdl.org>
To: "Aaron Gray" <angray@beeb.net>
Cc: "Git Mailing List" <git@vger.kernel.org>
Sent: Tuesday, July 04, 2006 4:28 AM
Subject: Re: Why's Git called Git ?
>
>
> On Tue, 4 Jul 2006, Aaron Gray wrote:
>>
>> Why the name I could not find any answer in the documentation ?
>
> It's really quite random. It needs to be a two- or three-letter thing just
> because I end up typing a lot.
>
> My favourite explanation is "I name all my projects after myself: first
> 'Linux', now 'git'".
>
> Which only makes sense if you know british slang.
>
> The runner up was "Because 'twerp' was too hard to type".
>
> But really, there's not a lot of real thinking behind it. The made-up
> acronym was "global information tracker", but that's a pretty bad excuse
> too.
>
> It just happened. Don't ask me why. All the explanations are really made
> up after the fact.
>
> Linus
^ permalink raw reply
* Re: Why's Git called Git ?
From: Jakub Narebski @ 2006-07-05 19:33 UTC (permalink / raw)
To: git
In-Reply-To: <001001c6a06d$6e7b94b0$0200a8c0@AMD2500>
Aaron Gray wrote:
> Anyway good going, I am glad Linux has an open source VCS again now.
>
> I do not know how BitKeeper are going to fell knowing they have been
> replaced by a Git :)
>
> I am toying with using a VCS for a set of related projects, either CVS
> because its well known, SubVersion for ease of use, or Git as it is new.
> Lots to descide upon, any pointers would be appreciated.
CVS is showing it's age; mainly the fact that IIRC it began as a series of
scripts over RCS, file level version control system, extending version
control to sets of files, somewhat. Branching in CVS is serious PITA.
Renaming _with_ retaining full and correct history: forget about it.
Subversion is "better CVS": still centralized, CVS infernal branching
replaced by "cheap copy" branching. Well known, replaces CVS thorough OSS
projects.
Git, Mercurial, Monotone, Bazaar-NG, Darcs are new brand of distributed VCS.
I really like notion of branching in Git; but be warned about tracking and
not recording renames, and the need of explicit packing (the latter very
minor). Powerfull, perhaps too powerfull for newbie user: but that is what
Cogito is for (although now Git contains fairly large set of high-level
commands).
http://git.or.cz/
http://git.or.cz/gitwiki
http://git.or.cz/gitwiki/Git
and "Other version control software" at
http://git.or.cz/gitwiki/GitLinks
P.S. If you decide to use Git as VCS for your project, consider adding entry
about it on http://git.or.cz/gitwiki/GitProjects wiki page.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git (at FreeNode)
^ permalink raw reply
* Re: Strange date format in git-send-email
From: Junio C Hamano @ 2006-07-05 21:22 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e8fv2o$khv$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> There were two patches on the list: one hacky adding setlocale
> call (not applied), second implementing rfc-822 date in Perl.
> Should be in current.
What do you mean by "should be in current"?
I specifically asked you about this issue a few days ago, even
with a patch to test out for people who are having problems, but
haven't heard back anything yet. The issue is still on hold and
not in "current" as far as I am concerned.
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org, Eric Wong <normalperson@yhbt.net>
From: Junio C Hamano <junkio@cox.net>
Subject: Re: [PATCH] send-email: Use setlocale in addition to
$ENV{LC_ALL} to set locale
Date: Sun, 02 Jul 2006 19:49:50 -0700
Message-ID: <7vd5cnv1v5.fsf@assigned-by-dhcp.cox.net>
I was reviewing old log and noticed this topic has never been
resolved. Your proposal was to use POSIX::setlocale(), and
Eric's counter-proposal was to mimic what 822-date script does,
doing it by hand without mucking with locales, and the
discussion seemed to have died there. Does this still need to
be addressed?
My gut feeling is that it would probably be less problematic if
we do not muck with locales at all (so drop POSIX::strftime as
well).
So maybe something like this (totally untested)?
...
^ permalink raw reply
* Logo your Business Identity (ID4949330)
From: Lynne Ellis @ 2006-07-05 21:44 UTC (permalink / raw)
To: geogirb
z6b
Our art team creates a custom logo for you, based on your needs. Years of experience have taught us how to create a logo that makes a statement that is unique to you.
In a professional manner we learn about your image and how you would like the world to perceive you and your company. With this information we then create a logo that is not only unique but reflects the purpose of you and your company.
For value and a logo that reflects your image, take a few minutes and visit Logo Maker!
http://bilge.biz.try-logosxb.biz
Sincerely,
Logo Design Team
appropriate ambient betatron
^ permalink raw reply
* Re: merge-base: update the clean-up postprocessing
From: Junio C Hamano @ 2006-07-05 23:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: A Large Angry SCM, git
In-Reply-To: <Pine.LNX.4.63.0607050946390.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 4 Jul 2006, Junio C Hamano wrote:
>
>> This is "for concepts" only -- it still seems to have bugs
>> somewhere to break other tests, although it passes your new
>> tests.
>
> Doesn't this introduce a nasty O(n*m) performance (where m is the
> number of merge bases, and n the number of traversed commits)? I think
> possibly many commits are traversed multiple times.
In practice m is small and the recomputation of bases between
bases does not require the minimalization so O(m^2). I've given
the numbers from a small real world example on the fixed code.
^ 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