* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-11-21 19:32 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Linus Torvalds, Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20061121180127.GB27221@fieldses.org>
[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]
On Tue, Nov 21, 2006 at 01:01:27PM -0500, J. Bruce Fields wrote:
> On Tue, Nov 21, 2006 at 12:33:34AM +0100, Martin Waitz wrote:
> > On Mon, Nov 20, 2006 at 06:25:07PM -0500, J. Bruce Fields wrote:
> > > Would it also be possible to allow the "Tree:" line in the commit object
> > > to refer to a commit, or does the root of the project need to be a
> > > special case?
> >
> > this would then be something like the branch-archival proposal.
>
> Do you have any pointers to previous discussion? (A couple obvious
> searches don't turn up anything for me.)
Aug 04 Eric W. Biederman [RFC][PATCH] Branch history
I really think that using subprojects can be used for this workflow, too.
But adding a submodule directly to the root is not really possible,
we'd have to use special user interfaces for that, even when the
git-core might be able to handle it.
But what might be possible is to have one toplevel history-tracking
repository in e.g. ~/src and then add all the repositories you work
with as a submodule. Whenever you want to record the history of
some project, you can simply commit it to ~/src.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: remotes/* for "foreign" archives
From: Junio C Hamano @ 2006-11-21 19:33 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86r6vwkfti.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> It occurred to me after posting this, and while still thinking about the
> presentation I'm writing, that it'd be interesting if "get-fetch" could hide
> this from me.
I agree fully, as it was in my earlier "wishlist" ;-)
Anybody?
^ permalink raw reply
* [PATCH] Add support to git-branch to show local and remote branches
From: Andy Parkins @ 2006-11-21 19:31 UTC (permalink / raw)
To: git
Instead of storing a list of refnames in append_ref, a list of structures is
created. Each of these stores the refname and a symbolic constant representing
its type.
The creation of the list is filtered based on a command line switch; no switch
means "local branches only", "-r" means "remote branches only" (as they always
did); but now "-a" means "local branches or remote branches".
As a side effect, the list is now not global, but allocated in print_ref_list()
where it used.
Also a memory leak is plugged, the memory allocated during the list creation
was never freed. This is now done in the new function, tidy_ref_list()
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 97 +++++++++++++++++++++++++++++++++++++++++++----------
1 files changed, 78 insertions(+), 19 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 368b68e..9e0be22 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -11,7 +11,7 @@
#include "builtin.h"
static const char builtin_branch_usage[] =
-"git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | [-r]";
+"git-branch (-d | -D) <branchname> | [-l] [-f] <branchname> [<start-point>] | [-r] | [-a]";
static const char *head;
@@ -79,46 +79,100 @@ static void delete_branches(int argc, co
}
}
-static int ref_index, ref_alloc;
-static char **ref_list;
+#define REF_UNKNOWN_TYPE 0x00
+#define REF_LOCAL_BRANCH 0x01
+#define REF_REMOTE_BRANCH 0x02
+#define REF_TAG 0x04
+
+struct ref_item {
+ char *name;
+ unsigned int kind;
+};
+
+struct ref_list {
+ int index, alloc;
+ struct ref_item *list;
+ int kinds;
+};
static int append_ref(const char *refname, const unsigned char *sha1, int flags,
void *cb_data)
{
- if (ref_index >= ref_alloc) {
- ref_alloc = alloc_nr(ref_alloc);
- ref_list = xrealloc(ref_list, ref_alloc * sizeof(char *));
+ struct ref_list *ref_list = (struct ref_list*)(cb_data);
+ struct ref_item *newitem;
+ int kind = REF_UNKNOWN_TYPE;
+
+ /* Detect kind */
+ if (!strncmp(refname, "refs/heads/", 11)) {
+ kind = REF_LOCAL_BRANCH;
+ refname += 11;
+ } else if (!strncmp(refname, "refs/remotes/", 13)) {
+ kind = REF_REMOTE_BRANCH;
+ refname += 13;
+ } else if (!strncmp(refname, "refs/tags/", 10)) {
+ kind = REF_TAG;
+ refname += 10;
+ }
+
+ /* Don't add types the caller doesn't want */
+ if ((kind & ref_list->kinds) == 0)
+ return 0;
+
+ /* Resize buffer */
+ if (ref_list->index >= ref_list->alloc) {
+ ref_list->alloc = alloc_nr(ref_list->alloc);
+ ref_list->list = xrealloc(ref_list->list,
+ ref_list->alloc * sizeof(struct ref_item));
}
- ref_list[ref_index++] = xstrdup(refname);
+ /* Record the new item */
+ newitem = &(ref_list->list[ref_list->index++]);
+ newitem->name = xstrdup(refname);
+ newitem->kind = kind;
return 0;
}
+static void tidy_ref_list( struct ref_list *ref_list )
+{
+ int i;
+ for (i = 0; i < ref_list->index; i++) {
+ free( ref_list->list[i].name );
+ }
+ free( ref_list->list );
+}
+
static int ref_cmp(const void *r1, const void *r2)
{
+ struct ref_item *c1 = (struct ref_item*)(r1),
+ *c2 = (struct ref_item*)(r2);
+ if( c1->kind != c2->kind )
+ return c1->kind - c2->kind;
return strcmp(*(char **)r1, *(char **)r2);
}
-static void print_ref_list(int remote_only)
+static void print_ref_list( int kinds )
{
int i;
char c;
+ struct ref_list ref_list;
- if (remote_only)
- for_each_remote_ref(append_ref, NULL);
- else
- for_each_branch_ref(append_ref, NULL);
+ memset( &ref_list, 0, sizeof( ref_list ) );
+ ref_list.kinds = kinds;
+ for_each_ref(append_ref, &ref_list);
- qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
+ qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
- for (i = 0; i < ref_index; i++) {
+ for (i = 0; i < ref_list.index; i++) {
c = ' ';
- if (!strcmp(ref_list[i], head))
+ if (ref_list.list[i].kind == REF_LOCAL_BRANCH &&
+ !strcmp(ref_list.list[i].name, head))
c = '*';
- printf("%c %s\n", c, ref_list[i]);
+ printf("%c %s\n", c, ref_list.list[i].name );
}
+
+ tidy_ref_list( &ref_list );
}
static void create_branch(const char *name, const char *start,
@@ -160,8 +214,9 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, remote_only = 0;
+ int delete = 0, force_delete = 0, force_create = 0;
int reflog = 0;
+ int kinds = REF_LOCAL_BRANCH;
int i;
git_config(git_default_config);
@@ -189,7 +244,11 @@ int cmd_branch(int argc, const char **ar
continue;
}
if (!strcmp(arg, "-r")) {
- remote_only = 1;
+ kinds = REF_REMOTE_BRANCH;
+ continue;
+ }
+ if (!strcmp(arg, "-a")) {
+ kinds = REF_REMOTE_BRANCH | REF_LOCAL_BRANCH;
continue;
}
if (!strcmp(arg, "-l")) {
@@ -209,7 +268,7 @@ int cmd_branch(int argc, const char **ar
if (delete)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
- print_ref_list(remote_only);
+ print_ref_list(kinds);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
--
1.4.3.5
^ permalink raw reply related
* Re: Some tips for doing a CVS importer
From: lamikr @ 2006-11-21 19:56 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jon Smirl, Carl Worth, Martin Langhoff, Git Mailing List
In-Reply-To: <20061121063934.GA3332@spearce.org>
Shawn Pearce wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
>
>> brendan said SVN is likely for the main Mozilla repo and monotone for
>> the new Mozilla 2 work. No native win32 caused git to be immediately
>> discarded.
>>
>
> Yea, that lack of native win32 seems to be one of a number of
> blockers for people switching their projects onto Git.
>
> I think there's a number of issues that are keeping people from
> switching to Git and are instead causing them to choose SVN, hg
> or Monotone:
>
> - No GUI.
>
QGIT allows using some commands. I plan to try out the GIT eclipse
plugin in near future myself.
This mail list have some discussion and download link to it's repo in
archives.
(title: Java GIT/Eclipse GIT version 0.1.1, )
> - No native win32 installation.
> - CVS import fails on some projects (e.g. Mozilla).
>
Well, committing the files from Mozilla cvs to svn has also own problems.
SVN accepts only a text files which have either a "Unix" or DOS style
line endings.
If file contains a both some lines using "Unix" way and others using dos
way SVN roll's
back the commit and you need to tools like "dos2unix" or "unix2dos" to
manipulate those.
(And randomly changing all to either of those is propably not a good idea)
^ permalink raw reply
* Re: git-show --stat on first commit
From: Jakub Narebski @ 2006-11-21 20:03 UTC (permalink / raw)
To: git
In-Reply-To: <7v64d8y4tu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
>> On Tue, Nov 21, 2006 at 07:16:44PM CET, Jakub Narebski wrote:
>>..
>>> git repo-config show.difftree --root
>>> git repo-config whatchanged.difftree --root
>>
>> That means extra pointless setup and is besides the point anyway, I was
>> asking about empty commits, not default command settings.
>
> I agree with you. Personally, I think:
>
> - show is where the user is asking for _that_ particular
> commit, so it can safely default to --root, always. No
> option is needed.
We don't show patch for merges by default in git-show, so I don't
see why we would want to show root commit diff in git-show by default:
those two are very similar.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Petr Baudis @ 2006-11-21 20:03 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jon Smirl, Carl Worth, Martin Langhoff, Git Mailing List
In-Reply-To: <20061121063934.GA3332@spearce.org>
On Tue, Nov 21, 2006 at 07:39:35AM CET, Shawn Pearce wrote:
> Jon Smirl <jonsmirl@gmail.com> wrote:
> > brendan said SVN is likely for the main Mozilla repo and monotone for
> > the new Mozilla 2 work. No native win32 caused git to be immediately
> > discarded.
>
> Yea, that lack of native win32 seems to be one of a number of
> blockers for people switching their projects onto Git.
Yep. :-(
> I think there's a number of issues that are keeping people from
> switching to Git and are instead causing them to choose SVN, hg
> or Monotone:
>
> - No GUI.
It has been my impression that Git's situation is far better than in
case of the other systems (except SVN: TortoiseSVN and RapidSVN). Is
that not so?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Shawn Pearce @ 2006-11-21 20:05 UTC (permalink / raw)
To: lamikr; +Cc: Jon Smirl, Carl Worth, Martin Langhoff, Git Mailing List
In-Reply-To: <456359E2.8010403@cc.jyu.fi>
lamikr <lamikr@cc.jyu.fi> wrote:
> Shawn Pearce wrote:
> > - No GUI.
> >
> QGIT allows using some commands. I plan to try out the GIT eclipse
> plugin in near future myself.
> This mail list have some discussion and download link to it's repo in
> archives.
> (title: Java GIT/Eclipse GIT version 0.1.1, )
I'm the author of that plugin. :-)
Its not even capable of making a commit yet. The underling plumbing
(aka jgit) can make commits but the Eclipse GUI has no function to
actually invoke that plumbing and make a commit to the repository.
The Eclipse plugin has apparently been a low priority for me.
I haven't worked on it very recently. Robin Rosenburg has supposedly
gotten the revision compare interface to work, but its slow as a
duck in November due to jgit's pack reading code not running as
fast as it should.
--
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Shawn Pearce @ 2006-11-21 20:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Smirl, Carl Worth, Martin Langhoff, Git Mailing List
In-Reply-To: <20061121200341.GH7201@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Nov 21, 2006 at 07:39:35AM CET, Shawn Pearce wrote:
> > I think there's a number of issues that are keeping people from
> > switching to Git and are instead causing them to choose SVN, hg
> > or Monotone:
> >
> > - No GUI.
>
> It has been my impression that Git's situation is far better than in
> case of the other systems (except SVN: TortoiseSVN and RapidSVN). Is
> that not so?
Hmm.
hg has a browser (hgk). Its a direct port of gitk. I don't see
a GUI otherwise, such as qgit or git-gui. They do however have a
Windows installer.
Monotone has mtsh and guitone. Neither appear to be as far along
as say qgit or even git-gui, which isn't that far along at all.
So I guess you are right. Git's situation is better than that
of hg or Monotone. Now if only I can finish everything I want
to put into git-gui, and get it included as part of the core Git
distribution. :)
--
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Johannes Schindelin @ 2006-11-21 20:22 UTC (permalink / raw)
To: Petr Baudis
Cc: Shawn Pearce, Jon Smirl, Carl Worth, Martin Langhoff,
Git Mailing List
In-Reply-To: <20061121200341.GH7201@pasky.or.cz>
Hi,
On Tue, 21 Nov 2006, Petr Baudis wrote:
> On Tue, Nov 21, 2006 at 07:39:35AM CET, Shawn Pearce wrote:
> >
> > Yea, that lack of native win32 seems to be one of a number of
> > blockers for people switching their projects onto Git.
>
> Yep. :-(
I started playing with MinGW, and got it to compile and run, with some
features lacking. See
Message-ID: <Pine.LNX.4.63.0609021724110.28360@wbgn013.biozentrum.uni-wuerzburg.de>
for details. From TFM
: The two biggest obstacles are fork() and the network stuff (I do not
: plan on supporting Git.pm there). To overcome the absence of fork() I
: wanted to use the subprocess stuff in MinGW's port of GNU make.
> > I think there's a number of issues that are keeping people from
> > switching to Git and are instead causing them to choose SVN, hg
> > or Monotone:
> >
> > - No GUI.
>
> It has been my impression that Git's situation is far better than in
> case of the other systems (except SVN: TortoiseSVN and RapidSVN). Is
> that not so?
I also started playing with writing a shell extension (this is what custom
context menu entries are called in Windows) using only MinGW, and no
payware (except, of course, Windows).
Since both of these little projects were sidetracks from what I am really
supposed to do, I will not be able to continue on these on a regular
basis. Get somebody else interested, though, and I will be glad to help!
Ciao,
Dscho
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Martin Langhoff @ 2006-11-21 20:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Shawn Pearce, Jon Smirl, Carl Worth, Git Mailing List
In-Reply-To: <20061121200341.GH7201@pasky.or.cz>
On 11/22/06, Petr Baudis <pasky@suse.cz> wrote:
> > - No GUI.
>
> It has been my impression that Git's situation is far better than in
> case of the other systems (except SVN: TortoiseSVN and RapidSVN). Is
> that not so?
I think GIT is in pretty good shape in all the items mentioned Shawn
lists except the Win32 port.
Confusing doco? All of them ;-)
Push/pull terminology confusion -- all of them again.
My only thing is that I continue to teach Cogito instead of GIT
because the index is a great thing for a top-level maintainer of a
large project but it really offers almost next to nothing to a user
who wants to make a commit.
but that hasn't stopped adoption over here...
cheers,
^ permalink raw reply
* [PATCH] gitweb: Do not use esc_html in esc_path
From: Jakub Narebski @ 2006-11-21 20:43 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Do not use esc_html in esc_path subroutine to avoid double quoting;
expand esc_html body (except quoting) in esc_path.
Move esc_path before quot_cec and quot_upr. Add some comments.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 28 +++++++++++++++++-----------
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ce185d9..53214b0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -585,7 +585,21 @@ sub esc_html ($;%) {
return $str;
}
-# Make control characterss "printable".
+# quote control characters and escape filename to HTML
+sub esc_path {
+ my $str = shift;
+ my %opts = @_;
+
+ $str = to_utf8($str);
+ $str = escapeHTML($str);
+ if ($opts{'-nbsp'}) {
+ $str =~ s/ / /g;
+ }
+ $str =~ s|([[:cntrl:]])|quot_cec($1)|eg;
+ return $str;
+}
+
+# Make control characters "printable", using character escape codes (CEC)
sub quot_cec {
my $cntrl = shift;
my %es = ( # character escape codes, aka escape sequences
@@ -605,22 +619,14 @@ sub quot_cec {
return "<span class=\"cntrl\">$chr</span>";
}
-# Alternatively use unicode control pictures codepoints.
+# Alternatively use unicode control pictures codepoints,
+# Unicode "printable representation" (PR)
sub quot_upr {
my $cntrl = shift;
my $chr = sprintf('&#%04d;', 0x2400+ord($cntrl));
return "<span class=\"cntrl\">$chr</span>";
}
-# quote control characters and escape filename to HTML
-sub esc_path {
- my $str = shift;
-
- $str = esc_html($str);
- $str =~ s|([[:cntrl:]])|quot_cec($1)|eg;
- return $str;
-}
-
# git may return quoted and escaped filenames
sub unquote {
my $str = shift;
--
1.4.3.4
^ permalink raw reply related
* Re: remotes/* for "foreign" archives
From: Petr Baudis @ 2006-11-21 20:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7v1wnwy4pv.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 21, 2006 at 08:33:48PM CET, Junio C Hamano wrote:
> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>
> > It occurred to me after posting this, and while still thinking about the
> > presentation I'm writing, that it'd be interesting if "get-fetch" could hide
> > this from me.
>
> I agree fully, as it was in my earlier "wishlist" ;-)
>
> Anybody?
It's currently right after first stage of remotes support in Cogito in
my TODO list (and that's not a vaporware anymore but is actually what
I'm already working on these days).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: [PATCH] Add support to git-branch to show local and remote branches
From: Junio C Hamano @ 2006-11-21 21:14 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611211931.24868.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Instead of storing a list of refnames in append_ref, a list of
> structures is created. Each of these stores the refname and a
> symbolic constant representing its type.
Thanks. I'll drop the one in 'pu' and will replace with this
patch but with style fixes and keeping the documentation updates
from there.
^ permalink raw reply
* Stupid Git question
From: Sean Kelley @ 2006-11-21 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <89b129c60611211331r3bb286b6re3c2c8f65ec3896f@mail.gmail.com>
Hi,
I have a stupid git question. We are doing embedded development using
git for our kernel mods.
git clone git+ssh://git.example.com/git/kernel/mh.git kernel
git checkout -b fm-modulator
edit/add/commit
git checkout origin
git pull . fm-modulator
git push origin
Everything up-to-date <<< It pushes nothing
My problem is that I don't understand why when I tell git to push the
changes to our repository it says everything is up-to-date. It
clearly hasn't pushed it yet to our server.
My git layout is like this:
A single repository representing our Monahans kernel "mh.git" hosted
on a remote server accessed by git+ssh.
Four developers work on the kernel and drivers for the target platform.
Any suggestions much appreciated. My prior experience is with
StarTeam and more recently Subversion.
Thanks,
Sean
--
Sean Kelley
--
^ permalink raw reply
* Re: Stupid Git question
From: Jakub Narebski @ 2006-11-21 21:49 UTC (permalink / raw)
To: git
In-Reply-To: <89b129c60611211341j71079633g53b0ec1d2e3193a5@mail.gmail.com>
Sean Kelley wrote:
> git checkout origin
It should be "git checkout master". You shouldn't do work on tracking
branches like origin branch.
> git pull . fm-modulator
>
> git push origin
Here origin means origin remote (repository). Check out what you have in
remotes/origin, or in [remote "origin"] section in git config.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Timur Tabi @ 2006-11-21 21:49 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Thomas Kolejka, git
In-Reply-To: <20061121183941.GB22283@spearce.org>
Shawn Pearce wrote:
> finally you can either run from that directory (see INSTALL file)
> or you can install the binary somewhere else. We don't really
> recommend using `pu` for production level work, so make sure you
> have a backup of any repository you run it on. :)
So how do I make a shallow clone? I've set it all up, but there is no
git-shallow-clone command, and git help clone doesn't have anything either.
--
Timur Tabi
^ permalink raw reply
* [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
From: Kir Kolyshkin @ 2006-11-21 22:02 UTC (permalink / raw)
To: git
It is a common practice to put links to bugzillas, mailing lists, etc.
in git log entries. The fact that gitweb doesn't make HTML links out of
that URLs makes following those URLs inconvenient. This patch fixes that
problem, trying to address cases when URL is enclosed in round or square
brackets.
Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
---
gitweb/gitweb.perl | 2 ++
1 file changed, 2 insertions(+)
--- git-1.4.4/gitweb/gitweb.perl 2006-11-15 08:22:27.000000000 +0100
+++ git-1.4.4-my/gitweb/gitweb.perl 2006-11-21 22:49:14.000000000 +0100
@@ -828,6 +828,8 @@
$line =~ s/$hash_text/$link/;
}
}
+ # make HTML links out of http(s) URLs
+ $line =~ s/(http[s]?:\/\/[^[:space:]\]\)]+)/<a href="\1">\1<\/a>/g;
return $line;
}
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Johannes Schindelin @ 2006-11-21 22:06 UTC (permalink / raw)
To: Timur Tabi; +Cc: Shawn Pearce, Thomas Kolejka, git
In-Reply-To: <45637457.1010505@freescale.com>
Hi,
On Tue, 21 Nov 2006, Timur Tabi wrote:
> Shawn Pearce wrote:
>
> > finally you can either run from that directory (see INSTALL file)
> > or you can install the binary somewhere else. We don't really
> > recommend using `pu` for production level work, so make sure you
> > have a backup of any repository you run it on. :)
>
> So how do I make a shallow clone? I've set it all up, but there is no
> git-shallow-clone command, and git help clone doesn't have anything either.
Try "git clone --depth 1 <url>". This will cut each ancestor chain after
one ancestor (IIRC).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] setlinebuf() vs HP-UX
From: Michal Rokos @ 2006-11-21 22:19 UTC (permalink / raw)
To: git
Hello,
it seems that HP-UX doesn't have setlinebuf() defined.
This tiny patch makes GIT compile again on HP-UX 11i.
Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz>
diff --git a/builtin-archive.c b/builtin-archive.c
index 2df1a84..a8a1f07 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -249,7 +249,7 @@ int cmd_archive(int argc, const char **a
if (remote)
return run_remote_archiver(remote, argc, argv);
- setlinebuf(stderr);
+ setvbuf(stderr, NULL, _IOLBF, BUFSIZ);
memset(&ar, 0, sizeof(ar));
tree_idx = parse_archive_args(argc, argv, &ar);
--
Michal Rokos
NextSoft s.r.o.
Vyskočilova 1/1410
140 21 Praha 4
phone: +420 267 224 311
fax: +420 267 224 307
mobile: +420 736 646 591
^ permalink raw reply related
* (unknown)
From: Johannes Schindelin @ 2006-11-21 22:24 UTC (permalink / raw)
To: Davide Libenzi, git
[PATCH] xdiff: add xdl_merge()
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This code is only lightly tested, but I am tired and hungry.
My hopes are that when I wake up in the morning, all bugs are
fixed, git-merge-one-file is rewritten as a builtin,
git-merge-index defaults to calling xdl_merge() directly when
no program is passed with "-o", and git-merge-recursive also
avoids fork()ing RCS' merge.
A funny side effect is that you can merge with white space
corruption by setting the xpparam flags to ignore whitespace.
The file passed as mf1 wins over mf2 in that case.
Oh, and maybe I did not need to use xdl_change_compact() (and
thus could have left that static to xdiffi.c)? Davide, if you
could enlighten me, I will take the time next weekend to port this
to LibXDiff ;-)
BTW if anybody wonders why these diffstats do not look correct:
"git apply --stat" does not yet have our new scaling...
Makefile | 3
xdiff/xdiff.h | 7 +
xdiff/xdiffi.c | 3
xdiff/xdiffi.h | 1
xdiff/xmerge.c | 433 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 444 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 4c3f87f..b10d65e 100644
--- a/Makefile
+++ b/Makefile
@@ -769,7 +769,8 @@ $(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
-XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o
+XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
+ xdiff/xmerge.o
$(XDIFF_OBJS): xdiff/xinclude.h xdiff/xmacros.h xdiff/xdiff.h xdiff/xtypes.h \
xdiff/xutils.h xdiff/xprepare.h xdiff/xdiffi.h xdiff/xemit.h
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index c9f8178..fa409d5 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -49,6 +49,9 @@ extern "C" {
#define XDL_BDOP_CPY 2
#define XDL_BDOP_INSB 3
+#define XDL_MERGE_MINIMAL 0
+#define XDL_MERGE_EAGER 1
+#define XDL_MERGE_ZEALOUS 2
typedef struct s_mmfile {
char *ptr;
@@ -90,6 +93,10 @@ long xdl_mmfile_size(mmfile_t *mmf);
int xdl_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdemitconf_t const *xecfg, xdemitcb_t *ecb);
+int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
+ mmfile_t *mf2, const char *name2,
+ xpparam_t const *xpp, int level, mmbuffer_t *result);
+
#ifdef __cplusplus
}
#endif /* #ifdef __cplusplus */
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index d76e76a..9aeebc4 100644
--- a/xdiff/xdiffi.c
+++ b/xdiff/xdiffi.c
@@ -45,7 +45,6 @@ static long xdl_split(unsigned long cons
long *kvdf, long *kvdb, int need_min, xdpsplit_t *spl,
xdalgoenv_t *xenv);
static xdchange_t *xdl_add_change(xdchange_t *xscr, long i1, long i2, long chg1, long chg2);
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags);
@@ -397,7 +396,7 @@ static xdchange_t *xdl_add_change(xdchan
}
-static int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {
+int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags) {
long ix, ixo, ixs, ixref, grpsiz, nrec = xdf->nrec;
char *rchg = xdf->rchg, *rchgo = xdfo->rchg;
xrecord_t **recs = xdf->recs;
diff --git a/xdiff/xdiffi.h b/xdiff/xdiffi.h
index d3b7271..472aeae 100644
--- a/xdiff/xdiffi.h
+++ b/xdiff/xdiffi.h
@@ -50,6 +50,7 @@ int xdl_recs_cmp(diffdata_t *dd1, long o
long *kvdf, long *kvdb, int need_min, xdalgoenv_t *xenv);
int xdl_do_diff(mmfile_t *mf1, mmfile_t *mf2, xpparam_t const *xpp,
xdfenv_t *xe);
+int xdl_change_compact(xdfile_t *xdf, xdfile_t *xdfo, long flags);
int xdl_build_script(xdfenv_t *xe, xdchange_t **xscr);
void xdl_free_script(xdchange_t *xscr);
int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
new file mode 100644
index 0000000..7b85aa5
--- /dev/null
+++ b/xdiff/xmerge.c
@@ -0,0 +1,433 @@
+/*
+ * LibXDiff by Davide Libenzi ( File Differential Library )
+ * Copyright (C) 2003-2006 Davide Libenzi, Johannes E. Schindelin
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Davide Libenzi <davidel@xmailserver.org>
+ *
+ */
+
+#include "xinclude.h"
+
+typedef struct s_xdmerge {
+ struct s_xdmerge *next;
+ /*
+ * 0 = conflict,
+ * 1 = no conflict, take first,
+ * 2 = no conflict, take second.
+ */
+ int mode;
+ long i1, i2;
+ long chg1, chg2;
+} xdmerge_t;
+
+static int xdl_append_merge(xdmerge_t **merge, int mode,
+ long i1, long chg1, long i2, long chg2)
+{
+ xdmerge_t *m = *merge;
+ if (m && mode == m->mode &&
+ (i1 == m->i1 + m->chg1 || i2 == m->i2 + m->chg2)) {
+ m->chg1 = i1 + chg1 - m->i1;
+ m->chg2 = i2 + chg2 - m->i2;
+ } else {
+ m = xdl_malloc(sizeof(xdmerge_t));
+ if (!m)
+ return -1;
+ m->next = NULL;
+ m->mode = mode;
+ m->i1 = i1;
+ m->chg1 = chg1;
+ m->i2 = i2;
+ m->chg2 = chg2;
+ if (*merge)
+ (*merge)->next = m;
+ *merge = m;
+ }
+ return 0;
+}
+
+static int xdl_cleanup_merge(xdmerge_t *c)
+{
+ int count = 0;
+ xdmerge_t *next_c;
+
+ /* were there conflicts? */
+ for (; c; c = next_c) {
+ if (c->mode == 0)
+ count++;
+ next_c = c->next;
+ free(c);
+ }
+ return count;
+}
+
+static int xdl_merge_cmp_lines(xdfenv_t *xe1, int i1, xdfenv_t *xe2, int i2,
+ int line_count, long flags)
+{
+ int i;
+ xrecord_t **rec1 = xe1->xdf2.recs + i1;
+ xrecord_t **rec2 = xe2->xdf2.recs + i2;
+
+ for (i = 0; i < line_count; i++) {
+ int result = xdl_recmatch(rec1[i]->ptr, rec1[i]->size,
+ rec2[i]->ptr, rec2[i]->size, flags);
+ if (!result)
+ return -1;
+ }
+ return 0;
+}
+
+static int xdl_recs_copy(xdfenv_t *xe, int i, int count, int add_nl, char *dest)
+{
+ xrecord_t **recs = xe->xdf2.recs + i;
+ int size = 0;
+
+ if (count < 1)
+ return 0;
+
+ for (i = 0; i < count; size += recs[i++]->size)
+ if (dest)
+ memcpy(dest + size, recs[i]->ptr, recs[i]->size);
+ if (add_nl) {
+ i = recs[count - 1]->size;
+ if (i == 0 || recs[count - 1]->ptr[i - 1] != '\n') {
+ if (dest)
+ dest[size] = '\n';
+ size++;
+ }
+ }
+ return size;
+}
+
+static int xdl_fill_merge_buffer(xdfenv_t *xe1, const char *name1,
+ xdfenv_t *xe2, const char *name2, xdmerge_t *m, char *dest)
+{
+ const int marker_size = 7;
+ int marker1_size = (name1 ? strlen(name1) + 1 : 0);
+ int marker2_size = (name2 ? strlen(name2) + 1 : 0);
+ int conflict_marker_size = 3 * (marker_size + 1)
+ + marker1_size + marker2_size;
+ int size, i1, j;
+
+ for (size = i1 = 0; m; m = m->next) {
+ if (m->mode == 0) {
+ size += xdl_recs_copy(xe1, i1, m->i1 - i1, 0,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '<';
+ if (marker1_size) {
+ dest[size] = ' ';
+ memcpy(dest + size + 1, name1,
+ marker1_size - 1);
+ size += marker1_size;
+ }
+ dest[size++] = '\n';
+ } else
+ size += conflict_marker_size;
+ size += xdl_recs_copy(xe1, m->i1, m->chg1, 1,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '=';
+ dest[size++] = '\n';
+ }
+ size += xdl_recs_copy(xe2, m->i2, m->chg2, 1,
+ dest ? dest + size : NULL);
+ if (dest) {
+ for (j = 0; j < marker_size; j++)
+ dest[size++] = '>';
+ if (marker2_size) {
+ dest[size] = ' ';
+ memcpy(dest + size + 1, name2,
+ marker2_size - 1);
+ size += marker2_size;
+ }
+ dest[size++] = '\n';
+ }
+ } else if (m->mode == 1)
+ size += xdl_recs_copy(xe1, i1, m->i1 + m->chg1 - i1, 0,
+ dest ? dest + size : NULL);
+ else if (m->mode == 2)
+ size += xdl_recs_copy(xe2, m->i2 - m->i1 + i1,
+ m->i1 + m->chg2 - i1, 0,
+ dest ? dest + size : NULL);
+ i1 = m->i1 + m->chg1;
+ }
+ size += xdl_recs_copy(xe1, i1, xe1->xdf2.nrec - i1, 0,
+ dest ? dest + size : NULL);
+ return size;
+}
+
+/*
+ * Sometimes, changes are not quite identical, but differ in only a few
+ * lines. Try hard to show only these few lines as conflicting.
+ */
+static int xdl_refine_conflicts(xdfenv_t *xe1, xdfenv_t *xe2, xdmerge_t *m,
+ xpparam_t const *xpp)
+{
+ for (; m; m = m->next) {
+ mmfile_t t1, t2;
+ xdfenv_t xe;
+ xdchange_t *xscr, *x;
+ int i1 = m->i1, i2 = m->i2;
+
+ /* let's handle just the conflicts */
+ if (m->mode)
+ continue;
+
+ /*
+ * This probably does not work outside git, since
+ * we have a very simple mmfile structure.
+ */
+ t1.ptr = (char *)xe1->xdf2.recs[m->i1]->ptr;
+ t1.size = xe1->xdf2.recs[m->i1 + m->chg1]->ptr
+ + xe1->xdf2.recs[m->i1 + m->chg1]->size - t1.ptr;
+ t2.ptr = (char *)xe2->xdf2.recs[m->i1]->ptr;
+ t2.size = xe2->xdf2.recs[m->i1 + m->chg1]->ptr
+ + xe2->xdf2.recs[m->i1 + m->chg1]->size - t2.ptr;
+ if (xdl_do_diff(&t1, &t2, xpp, &xe) < 0)
+ return -1;
+ if (xdl_change_compact(&xe.xdf1, &xe.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe.xdf2, &xe.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe, &xscr) < 0) {
+ xdl_free_env(&xe);
+ return -1;
+ }
+ if (!xscr) {
+ /* If this happens, it's a bug. */
+ xdl_free_env(&xe);
+ return -2;
+ }
+ x = xscr;
+ m->i1 = xscr->i1 + i1;
+ m->chg1 = xscr->chg1;
+ m->i2 = xscr->i2 + i2;
+ m->chg2 = xscr->chg2;
+ while (xscr->next) {
+ xdmerge_t *m2 = xdl_malloc(sizeof(xdmerge_t));
+ if (!m2) {
+ xdl_free_env(&xe);
+ xdl_free_script(x);
+ return -1;
+ }
+ xscr = xscr->next;
+ m2->next = m->next;
+ m->next = m2;
+ m = m2;
+ m->mode = 0;
+ m->i1 = xscr->i1 + i1;
+ m->chg1 = xscr->chg1;
+ m->i2 = xscr->i2 + i2;
+ m->chg2 = xscr->chg2;
+ }
+ xdl_free_env(&xe);
+ xdl_free_script(x);
+ }
+ return 0;
+}
+
+/*
+ * level == 0: mark all overlapping changes as conflict
+ * level == 1: mark overlapping changes as conflict only if not identical
+ * level == 2: analyze non-identical changes for minimal conflict set
+ *
+ * returns < 0 on error, == 0 for no conflicts, else number of conflicts
+ */
+static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1, const char *name1,
+ xdfenv_t *xe2, xdchange_t *xscr2, const char *name2,
+ int level, xpparam_t const *xpp, mmbuffer_t *result) {
+ xdmerge_t *changes, *c;
+ int i1, i2, chg1, chg2;
+
+ c = changes = NULL;
+
+ while (xscr1 && xscr2) {
+ if (!changes)
+ changes = c;
+ if (xscr1->i1 + xscr1->chg1 < xscr2->i1) {
+ i1 = xscr1->i2;
+ i2 = xscr2->i2 - xscr2->i1 + xscr1->i1;
+ chg1 = xscr1->chg2;
+ chg2 = xscr1->chg1;
+ if (xdl_append_merge(&c, 1, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr1 = xscr1->next;
+ continue;
+ }
+ if (xscr2->i1 + xscr2->chg1 < xscr1->i1) {
+ i1 = xscr1->i2 - xscr1->i1 + xscr2->i1;
+ i2 = xscr2->i2;
+ chg1 = xscr2->chg1;
+ chg2 = xscr2->chg2;
+ if (xdl_append_merge(&c, 2, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr2 = xscr2->next;
+ continue;
+ }
+ if (level < 1 || xscr1->i1 != xscr2->i1 ||
+ xscr1->chg1 != xscr2->chg1 ||
+ xscr1->chg2 != xscr2->chg2 ||
+ xdl_merge_cmp_lines(xe1, xscr1->i2,
+ xe2, xscr2->i2,
+ xscr1->chg2, xpp->flags)) {
+ /* conflict */
+ int off = xscr1->i1 - xscr2->i1;
+ int ffo = off + xscr1->chg1 - xscr2->chg1;
+
+ i1 = xscr1->i2;
+ i2 = xscr2->i2;
+ if (off > 0)
+ i1 -= off;
+ else
+ i2 += off;
+ chg1 = xscr1->i2 + xscr1->chg2 - i1;
+ chg2 = xscr2->i2 + xscr2->chg2 - i2;
+ if (ffo > 0)
+ chg2 += ffo;
+ else
+ chg1 -= ffo;
+ if (xdl_append_merge(&c, 0, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ }
+
+ i1 = xscr1->i1 + xscr1->chg1;
+ i2 = xscr2->i1 + xscr2->chg1;
+
+ if (i1 > i2) {
+ xscr1->chg1 -= i1 - i2;
+ xscr1->i1 = i2;
+ xscr1->i2 += xscr1->chg2;
+ xscr1->chg2 = 0;
+ xscr1 = xscr1->next;
+ } else if (i2 > i1) {
+ xscr2->chg1 -= i2 - i1;
+ xscr2->i1 = i1;
+ xscr2->i2 += xscr2->chg2;
+ xscr2->chg2 = 0;
+ xscr2 = xscr2->next;
+ } else {
+ xscr1 = xscr1->next;
+ xscr2 = xscr2->next;
+ }
+ }
+ while (xscr1) {
+ if (!changes)
+ changes = c;
+ i1 = xscr1->i2;
+ i2 = xscr1->i1 + xe2->xdf2.nrec - xe2->xdf1.nrec;
+ chg1 = xscr1->chg2;
+ chg2 = xscr1->chg1;
+ if (xdl_append_merge(&c, 1, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr1 = xscr1->next;
+ }
+ while (xscr2) {
+ if (!changes)
+ changes = c;
+ i1 = xscr2->i1 + xe1->xdf2.nrec - xe1->xdf1.nrec;
+ i2 = xscr2->i2;
+ chg1 = xscr2->chg1;
+ chg2 = xscr2->chg2;
+ if (xdl_append_merge(&c, 2, i1, chg1, i2, chg2)) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ xscr2 = xscr2->next;
+ }
+ if (!changes)
+ changes = c;
+ /* refine conflicts */
+ if (level > 1 && xdl_refine_conflicts(xe1, xe2, changes, xpp) < 0) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ /* output */
+ if (result) {
+ int size = xdl_fill_merge_buffer(xe1, name1, xe2, name2,
+ changes, NULL);
+ result->ptr = xdl_malloc(size);
+ if (!result->ptr) {
+ xdl_cleanup_merge(changes);
+ return -1;
+ }
+ result->size = size;
+ xdl_fill_merge_buffer(xe1, name1, xe2, name2, changes,
+ result->ptr);
+ }
+ return xdl_cleanup_merge(changes);
+}
+
+int xdl_merge(mmfile_t *orig, mmfile_t *mf1, const char *name1,
+ mmfile_t *mf2, const char *name2,
+ xpparam_t const *xpp, int level, mmbuffer_t *result) {
+ xdchange_t *xscr1, *xscr2;
+ xdfenv_t xe1, xe2;
+
+ result->ptr = NULL;
+ result->size = 0;
+
+ if (xdl_do_diff(orig, mf1, xpp, &xe1) < 0 ||
+ xdl_do_diff(orig, mf2, xpp, &xe2) < 0) {
+ return -1;
+ }
+ if (xdl_change_compact(&xe1.xdf1, &xe1.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe1.xdf2, &xe1.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe1, &xscr1) < 0) {
+ xdl_free_env(&xe1);
+ return -1;
+ }
+ if (xdl_change_compact(&xe2.xdf1, &xe2.xdf2, xpp->flags) < 0 ||
+ xdl_change_compact(&xe2.xdf2, &xe2.xdf1, xpp->flags) < 0 ||
+ xdl_build_script(&xe2, &xscr2) < 0) {
+ xdl_free_env(&xe2);
+ return -1;
+ }
+ if (xscr1 || xscr2) {
+ if (!xscr1) {
+ result->ptr = xdl_malloc(mf2->size);
+ memcpy(result->ptr, mf2->ptr, mf2->size);
+ result->size = mf2->size;
+ } else if (!xscr2) {
+ result->ptr = xdl_malloc(mf1->size);
+ memcpy(result->ptr, mf1->ptr, mf1->size);
+ result->size = mf1->size;
+ } else if (xdl_do_merge(&xe1, xscr1, name1,
+ &xe2, xscr2, name2,
+ level, xpp, result) < 0) {
+ xdl_free_script(xscr1);
+ xdl_free_script(xscr2);
+ xdl_free_env(&xe1);
+ xdl_free_env(&xe2);
+ return -1;
+ }
+ xdl_free_script(xscr1);
+ xdl_free_script(xscr2);
+ }
+ xdl_free_env(&xe1);
+ xdl_free_env(&xe2);
+
+ return 0;
+}
^ permalink raw reply related
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
From: Jakub Narebski @ 2006-11-21 22:28 UTC (permalink / raw)
To: git
In-Reply-To: <4563777C.4050108@openvz.org>
Kir Kolyshkin wrote:
> It is a common practice to put links to bugzillas, mailing lists, etc.
> in git log entries. The fact that gitweb doesn't make HTML links out of
> that URLs makes following those URLs inconvenient. This patch fixes that
> problem, trying to address cases when URL is enclosed in round or square
> brackets.
Preliminary committags support was sent as an RFC patch on git mailing list
once. Hyperlinking plain text http, https, ftp, ftps links etc. is a special
case of committag. That wha is implemented now, namely hyperlinking
commitsha to commit view is also special case of comittag.
And I plan to implement it, only later. But you are welcome to do it
instead.
gitweb-xmms2 http://git.xmms.se/?p=gitweb-xmms2.git has xmms2 related
committags support (links to xmms2 Mantis bugtracker from BUG(n) and
FEATURE(n))
> Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
>
> Signed-off-by: Kir Kolyshkin <kir@openvz.org>
> ---
> gitweb/gitweb.perl | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- git-1.4.4/gitweb/gitweb.perl 2006-11-15 08:22:27.000000000 +0100
> +++ git-1.4.4-my/gitweb/gitweb.perl 2006-11-21 22:49:14.000000000 +0100
> @@ -828,6 +828,8 @@
Could you please send patches created by git tools, namely git-format-patch,
or if you really need to send GNU diff patches, use -p option? It really
helps in patch review.
> $line =~ s/$hash_text/$link/;
> }
> }
> + # make HTML links out of http(s) URLs
> + $line =~ s/(http[s]?:\/\/[^[:space:]\]\)]+)/<a href="\1">\1<\/a>/g;
> return $line;
> }
Wont work correctly if commit message has sha1 of commit in it; it would be
changed to
<a href="$my_uri?p=$project;a=commit;h=$hash_text" class="text">$hash_text</a>
then the code you added will add hyperlink in place of href value (!).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Yann Dirson @ 2006-11-21 22:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0611201501230.3338@woody.osdl.org>
On Mon, Nov 20, 2006 at 03:05:47PM -0800, Linus Torvalds wrote:
> On Mon, 20 Nov 2006, Junio C Hamano wrote:
> >
> > That was shot down by Linus and I agree with him. "bind" was a
> > bad idea because binding of a particular subproject commit into
> > a tree is a property of the tree, not one of the commits that
> > happen to have that tree.
>
> Yes. I think it would be a _fine_ idea to have a new tree-entry type that
> points to a sub-commit, but it really does need to be on a "tree level",
> not a commit level.
I'm not sure I get the reason why the submodule should not be recorded
on "commit level".
What I'm thinking of would be that the submodule tree would just be a
standard antry of a tree in the supermodule, and we could record the
submodule commit (pointing to the submodule tree) in the supermodule
commit.
This idea came when thinking about implementing partial merges. That
is, when different people are responsible for different parts of the
tree, and thus when merging a given branch, each dev has to make only
a partial merge of the full tree.
Having submodule commits referenced directly from the supercommit would
make it much easier to finalize the merge (ie. merging the full project
while taking into account that some subtrees have been merged already).
Best regards,
--
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Timur Tabi @ 2006-11-21 22:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn Pearce, Thomas Kolejka, git
In-Reply-To: <Pine.LNX.4.63.0611212306060.26827@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 21 Nov 2006, Timur Tabi wrote:
>
>> Shawn Pearce wrote:
>>
>>> finally you can either run from that directory (see INSTALL file)
>>> or you can install the binary somewhere else. We don't really
>>> recommend using `pu` for production level work, so make sure you
>>> have a backup of any repository you run it on. :)
>> So how do I make a shallow clone? I've set it all up, but there is no
>> git-shallow-clone command, and git help clone doesn't have anything either.
>
> Try "git clone --depth 1 <url>". This will cut each ancestor chain after
> one ancestor (IIRC).
I think you mean git-clone.sh instead of git-clone. If I do the above command,
I get:
$ ./git clone --depth 1 git://127.0.0.1/temp/u-boot-83xx/
Usage: /home/b04825/bin/git-clone [--template=<template_directory>]
[--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q]
[-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]
However, git-clone.sh is not quite working either. I had to run git-daemon on
my machine, because git-clone.sh doesn't like the http protocol, and my firewall
blocks everything but that. So I cloned a repo, started git-daemon, and I tried
this:
$ ./git-clone.sh --depth 1 git://127.0.0.1/temp/u-boot-83xx
usage: git-fetch-pack [--all] [-q] [-v] [-k] [--thin] [--exec=upload-pack]
[host:]directory <refs>...
fetch-pack from 'git://127.0.0.1/temp/u-boot-83xx/' failed.
A regular git-clone of git://127.0.0.1/temp/u-boot-83xx works, so I think
there's something wrong with git-clone.sh or my invocation thereof.
--
Timur Tabi
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-11-21 22:51 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20061121223130.GA24909@nan92-1-81-57-214-146.fbx.proxad.net>
On Tue, 21 Nov 2006, Yann Dirson wrote:
>
> I'm not sure I get the reason why the submodule should not be recorded
> on "commit level".
Because that would be STUPID.
What does the submodules have to do with the commit level? Nothing. Nada.
Zero.
Submodules are _directories_. They can be anywhere in the directory tree.
If you try to encode that in a commit message, you're going to totally
break the whole notion of trying to "diff" two trees.
All of git is designed around the notion that a tree is the directory
structure. If you put directory structure somewhere else, you totally
screw all abstractions.
Now, if that weren't enough, let me enumerate _another_ reason why it's
idiotic and wrong, namely the fact that a "commit" is fundamnetally the
wrong place to add something like that _anyway_. Quite apart from the fact
that we describe directory trees with (wait for it): "tree objects", the
thing is, a commit is about a totally different _dimension_ altogether.
The only and _whole_ point of a "commit" is to describe the "time
dimension". Something that doesn't always change in time should not be in
a commit object, because it is by definition not what a commit is all
about. A commit should describe the relationship of itself to other
commits, ie it's a "how did this change".
And a sub-project simply doesn't even _do_ that. Much of the time, a
subproject stays constant, and is not something that comes and goes on an
individual commit basis.
I don't understand why people are so fixated with putting things in the
wrong object. WHY do people want to put crap in the "commit" object?
People have wanted to put "rename" information there (which is stupid for
all the same reasons: renames _remain_. They aren't a one-time event. If
something was renamed in commit X, it will _remain_ renamed in commit X+1,
so it's clearly not really a "commit X" thing)
Think of it this way:
- if something _only_ makes sense on an _individual commit_ level, it
goes into the "commit object". But if it makes sense for "git diff",
then it MUST NOT be in a commit object, because you do "git diff" over
a big _range_ of commit objects.
Think "git show". The "author" of a commit is only associated with a
_single_ commit. It thus goes into the commit object, and nowhere else.
Same goes for time, and commit message. A commit message is fundamentally
a "this explains this _one_ commit".
But anything that you expect to have in a "range" of commits MUST NOT be
in a "commit object". If I do "git diff v2.6.13..v2.6.14", and I expect
the behaviour you want to encode to show up (and dammit, subprojects very
much fall under that heading - exactly the same way renames must have
meaning _outside_ of a single commit) then clearly it is NOT something
that is associated with any individual commits. It's something that is
associated with the _state_ of the project.
And the _state_ of the project is the "tree". Not the commit. The commit
is about the _history_ of the project.
So please understand this: "commit" is about the time-dimension
("history"). "tree" is about the space-dimension ("state"). The two are
_related_, but they are also very much different concepts, and "related"
does not mean "you can mix them up".
Sub-projects are clearly not about "time". They are about "state".
^ permalink raw reply
* Re: Is there a way to trim old SHAs from a git tree (so it's not so large)?
From: Jakub Narebski @ 2006-11-21 22:53 UTC (permalink / raw)
To: git
In-Reply-To: <45638212.8030501@freescale.com>
Timur Tabi wrote:
> Johannes Schindelin wrote:
>> Try "git clone --depth 1 <url>". This will cut each ancestor chain after
>> one ancestor (IIRC).
>
> I think you mean git-clone.sh instead of git-clone. If I do the above command,
> I get:
>
> $ ./git clone --depth 1 git://127.0.0.1/temp/u-boot-83xx/
> Usage: /home/b04825/bin/git-clone [--template=<template_directory>]
> [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q]
> [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]
>
> However, git-clone.sh is not quite working either. I had to run git-daemon on
> my machine, because git-clone.sh doesn't like the http protocol, and my firewall
> blocks everything but that. So I cloned a repo, started git-daemon, and I tried
> this:
>
> $ ./git-clone.sh --depth 1 git://127.0.0.1/temp/u-boot-83xx
> usage: git-fetch-pack [--all] [-q] [-v] [-k] [--thin] [--exec=upload-pack]
> [host:]directory <refs>...
> fetch-pack from 'git://127.0.0.1/temp/u-boot-83xx/' failed.
>
> A regular git-clone of git://127.0.0.1/temp/u-boot-83xx works, so I think
> there's something wrong with git-clone.sh or my invocation thereof.
Erm, you have to compile git with "make bindir=$(pwd)" to run it from
working directory. Or just install it somewhere not over git, like
/usr/local/ or /home/local/.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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