* git-apply fails to apply some patches
From: Gerrit Pape @ 2006-09-15 13:22 UTC (permalink / raw)
To: git, 386495
Hi, please see http://bugs.debian.org/386495 or below. I can reproduce
the problem with 1.4.2.1.
Thanks, Gerrit.
----- Forwarded message from Matthew Wilcox <matthew@wil.cx> -----
Trying to apply a patch that was created with interdiff fails ...
Here's the first patch (which works)
--- pciutils-2.1.11.orig/debian/dirs
+++ pciutils-2.1.11/debian/dirs
@@ -0,0 +1,6 @@
+usr/share/misc
+usr/share/man
+usr/bin
+usr/lib
+usr/share/lintian/overrides
+bin
On top of that, I try to apply this interdiff generated patch:
diff -u pciutils-2.1.11/debian/dirs pciutils-2.1.11/debian/dirs
--- pciutils-2.1.11/debian/dirs
+++ pciutils-2.1.11/debian/dirs
@@ -6,0 +7 @@
+var/lib/pciutils
and git-apply says:
error: debian/dirs: already exists in working directory
I suspect it's confused by the '-x,0' thinking that means "file does not
exist" rather than "we have 0 context for this diff".
----- End forwarded message -----
^ permalink raw reply
* [PATCH] Skip t3403 selftests if stdin is not a terminal
From: Gerrit Pape @ 2006-09-15 12:59 UTC (permalink / raw)
To: git
sh t3403-rebase-skip.sh </dev/null fails because stdin is not connected
to a terminal, as in the Debian autobuild environment. This disbales
the test 3 and 7 in this case.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
t/t3403-rebase-skip.sh | 23 +++++++++++++++++------
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/t/t3403-rebase-skip.sh b/t/t3403-rebase-skip.sh
index 8ab63c5..983d152 100755
--- a/t/t3403-rebase-skip.sh
+++ b/t/t3403-rebase-skip.sh
@@ -39,10 +39,16 @@ test_expect_success setup '
test_expect_failure 'rebase with git am -3 (default)' 'git rebase master'
-test_expect_success 'rebase --skip with am -3' '
- git reset --hard HEAD &&
- git rebase --skip
- '
+if tty -s
+then
+ test_expect_success 'rebase --skip with am -3' '
+ git reset --hard HEAD &&
+ git rebase --skip
+ '
+else
+ echo 'stdin is not a terminal, skip test.'
+fi
+
test_expect_success 'checkout skip-merge' 'git checkout -f skip-merge'
test_expect_failure 'rebase with --merge' 'git rebase --merge master'
@@ -52,8 +58,13 @@ test_expect_success 'rebase --skip with
git rebase --skip
'
-test_expect_success 'merge and reference trees equal' \
- 'test -z "`git-diff-tree skip-merge skip-reference`"'
+if tty -s
+then
+ test_expect_success 'merge and reference trees equal' \
+ 'test -z "`git-diff-tree skip-merge skip-reference`"'
+else
+ echo 'stdin is not a terminal, skip test.'
+fi
test_debug 'gitk --all & sleep 1'
--
1.4.2.1
^ permalink raw reply related
* [PATCH] Build on Debian GNU/Hurd
From: Gerrit Pape @ 2006-09-15 12:58 UTC (permalink / raw)
To: git
Patch from Cyril Brulebois to make the build process detect and support the
Debian GNU/Hurd architecture, see
http://bugs.debian.org/379841
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Makefile | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 7b3114f..6e36eff 100644
--- a/Makefile
+++ b/Makefile
@@ -383,6 +383,11 @@ ifeq ($(uname_S),NetBSD)
ALL_CFLAGS += -I/usr/pkg/include
ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
endif
+ifeq ($(uname_S),GNU)
+ # GNU stands for GNU/Hurd
+ NO_STRLCPY = YesPlease
+ ALL_CFLAGS += -DPATH_MAX=4096
+endif
ifeq ($(uname_S),AIX)
NO_STRCASESTR=YesPlease
NO_STRLCPY = YesPlease
--
1.4.2.1
^ permalink raw reply related
* Re: Tracking a branch using StGIT
From: Rajkumar S @ 2006-09-15 12:18 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <eee551$mtc$1@sea.gmane.org>
On 9/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Besides in remotes file you have only specified which remote branch
> is tracked by which local branch. Additionally all but first are marked
> as not-for-merge. There is no place for default branch to merge with.
>
> There was some discussion about moving remotes information into config
> file, including marking tracking branches as read-only, marking default
> branch to merge (or marking branch as for-merge/not-for-merge), marking
> branch as of not fast-forwarding type (like 'pu' in git.git) on the
> _server_ side etc. But it petered out, unfortunately.
Thanks a lot for your comments, I have just put the RELENG_1 line in
the remotes and have RELENG_1 always checked out.
raj
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Jakub Narebski @ 2006-09-15 12:09 UTC (permalink / raw)
To: git
In-Reply-To: <64de5c8b0609150459i2e678a02r86bb678ea420054f@mail.gmail.com>
Rajkumar S wrote:
> On 9/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> git pull is git fetch + merge of first head in remotes file with _current_
>> branch.
>
> I was under the impression that git pull is git pull + merge of
> corresponding branches in remotes files. ie master -> origin and
> RELENG_1 -> RELENG_1. Is such a pull possible, for all lines in
> remotes file?
GIT-PULL(1)
DESCRIPTION
Runs git-fetch with the given parameters, and calls git-merge to merge the
retrieved head(s) into the current branch.
Besides in remotes file you have only specified which remote branch
is tracked by which local branch. Additionally all but first are marked
as not-for-merge. There is no place for default branch to merge with.
There was some discussion about moving remotes information into config
file, including marking tracking branches as read-only, marking default
branch to merge (or marking branch as for-merge/not-for-merge), marking
branch as of not fast-forwarding type (like 'pu' in git.git) on the
_server_ side etc. But it petered out, unfortunately.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Rajkumar S @ 2006-09-15 11:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eee3i5$ib6$1@sea.gmane.org>
On 9/15/06, Jakub Narebski <jnareb@gmail.com> wrote:
> git pull is git fetch + merge of first head in remotes file with _current_
> branch.
I was under the impression that git pull is git pull + merge of
corresponding branches in remotes files. ie master -> origin and
RELENG_1 -> RELENG_1. Is such a pull possible, for all lines in
remotes file?
In my case I am only interested in RELENG_1 branch, so would it be
fine if I just put the
"Pull: refs/heads/RELENG_1:refs/heads/RELENG_1" line in my remotes
file? Since I use StGIT I do not intend to modify my local RELENG_1
branch except by StGIT patches, so all pulls from remote should be
fast forward merged. Thus if the stg pull can pull in the remote
RELENG_1 to local RELENG_1 with patched popped, and fastforward merge
it, it would be great.
raj
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Jakub Narebski @ 2006-09-15 11:42 UTC (permalink / raw)
To: git
In-Reply-To: <64de5c8b0609150432o5d6835a8pb578082746576864@mail.gmail.com>
Rajkumar S wrote:
> On 9/15/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
>
>> After StGIT pops all the patches, it just calls "git pull origin". My
>> understanding of GIT is that this should update local RELENG_1 with
>> the remote RELENG_1 from the "origin" repository. Anything wrong with
>> my assumptions?
>
> I checked this again, this time with out using stgit, and the results
> are the same. So this is not a StGIT problem but a user error :(
>
> My sequence of test is as follows:
>
> # root@beastie:# git clone /usr/local/pfSense/upstream/pfSense/ releng_1
> <snip>
> 100% (1220/1220) done
> # cd releng_1/
>
> # cat .git/remotes/origin
> URL: /usr/local/pfSense/upstream/pfSense/.git
> Pull: refs/heads/master:refs/heads/origin
> Pull: refs/heads/avendor:refs/heads/avendor
> Pull: refs/heads/Package-Reorg-2005:refs/heads/Package-Reorg-2005
> Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
>
> # git branch
> Package-Reorg-2005
> RELENG_1
> avendor
> * master
> origin
>
> # git pull
> Already up-to-date.
>
> # git checkout RELENG_1
>
> # git pull
[...]
>
> As you can see, when I switched to RELENG_1 branch and did a git pull,
> I am getting errors. I am wondering where I am wrong.
git pull is git fetch + merge of first head in remotes file with _current_
branch.
You'd better git fetch if you are on RELENG_1 branch (if you are not on
master), then git checkout master && git pull . origin
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Rajkumar S @ 2006-09-15 11:34 UTC (permalink / raw)
To: Santi; +Cc: git
In-Reply-To: <8aa486160609150417s288d6540tc8ee6aa83bbf67b4@mail.gmail.com>
On 9/15/06, Santi <sbejar@gmail.com> wrote:
> No. But the it merge the first pull line in .git/remotes/origin into
> the current branch. So he only has to put the RELENG_1 line the first,
> as:
>
> URL: /usr/local/pfSense/upstream/pfSense/.git
> Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
Thanks a lot, that should solve this.
raj
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Rajkumar S @ 2006-09-15 11:32 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0609150342y6105d8d1o61abb1934da9f51b@mail.gmail.com>
On 9/15/06, Catalin Marinas <catalin.marinas@gmail.com> wrote:
> After StGIT pops all the patches, it just calls "git pull origin". My
> understanding of GIT is that this should update local RELENG_1 with
> the remote RELENG_1 from the "origin" repository. Anything wrong with
> my assumptions?
I checked this again, this time with out using stgit, and the results
are the same. So this is not a StGIT problem but a user error :(
My sequence of test is as follows:
# root@beastie:# git clone /usr/local/pfSense/upstream/pfSense/ releng_1
<snip>
100% (1220/1220) done
# cd releng_1/
# cat .git/remotes/origin
URL: /usr/local/pfSense/upstream/pfSense/.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/avendor:refs/heads/avendor
Pull: refs/heads/Package-Reorg-2005:refs/heads/Package-Reorg-2005
Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
# git branch
Package-Reorg-2005
RELENG_1
avendor
* master
origin
# git pull
Already up-to-date.
# git checkout RELENG_1
# git pull
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with c0a06b86b8431293214f5eb18e49fcb8117c6070
Merging:
997e28966d7b7964562232628cc4f64dccbead9e Execute after commands via sh &
c0a06b86b8431293214f5eb18e49fcb8117c6070 Execute after commands via sh &
found 1 common ancestor(s):
1b08ecedad1e6a7199f12d1fad97373587c85454 Minor nitpick. <br> after
firmware branch select box
As you can see, when I switched to RELENG_1 branch and did a git pull,
I am getting errors. I am wondering where I am wrong.
raj
^ permalink raw reply
* duplicate memory allocation in buildin-add.c
From: Liu Yubao @ 2006-09-15 11:26 UTC (permalink / raw)
To: git
http://www.kernel.org/git/?p=git/git.git;a=commitdiff;h=0d78153952e70c21e94dc6b7eefcb2ac5337a902
buildin-add.c:
+static void fill_directory(struct dir_struct *dir, const char **pathspec)
+{
+ const char *path, *base;
+ int baselen;
...
+ if (baselen) {
+ char *common = xmalloc(baselen + 1);
+ common = xmalloc(baselen + 1);
+ memcpy(common, *pathspec, baselen);
+ common[baselen] = 0;
+ path = base = common;
+ }
...
Allocate memory twice for "common" variable, is it indended? I'm very confused @_@
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Santi @ 2006-09-15 11:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Rajkumar S, git
In-Reply-To: <b0943d9e0609150342y6105d8d1o61abb1934da9f51b@mail.gmail.com>
2006/9/15, Catalin Marinas <catalin.marinas@gmail.com>:
> On 15/09/06, Rajkumar S <rajkumars+git@gmail.com> wrote:
> > I am using StGIT to track a branch of a remote git repository
> > (actually a remote cvs repository, which I am tracking cvsimport)
> [...]
> > The .git/remotes/origin is
> > URL: /usr/local/pfSense/upstream/pfSense/.git
> > Pull: refs/heads/master:refs/heads/origin
> > Pull: refs/heads/avendor:refs/heads/avendor
> > Pull: refs/heads/Package-Reorg-2005:refs/heads/Package-Reorg-2005
> > Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
> >
> > My requirement is to track RELENG_1 branch with StGIT while
> > maintaining my own patches. but when I do a stg pull the messages are:
> [...]
> > It seems StGIT is trying to merge the origin branch from remote to
> > RELENG_1 of local. Is there a way to get RELENG_1 of remote to merge
> > with MyBranch (clone of "RELENG_1") of local?
>
> After StGIT pops all the patches, it just calls "git pull origin". My
> understanding of GIT is that this should update local RELENG_1 with
> the remote RELENG_1 from the "origin" repository. Anything wrong with
> my assumptions?
>
No. But the it merge the first pull line in .git/remotes/origin into
the current branch. So he only has to put the RELENG_1 line the first,
as:
URL: /usr/local/pfSense/upstream/pfSense/.git
Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/avendor:refs/heads/avendor
Pull: refs/heads/Package-Reorg-2005:refs/heads/Package-Reorg-2005
Santi
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Andy Whitcroft @ 2006-09-15 10:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Rajkumar S, git
In-Reply-To: <b0943d9e0609150342y6105d8d1o61abb1934da9f51b@mail.gmail.com>
Catalin Marinas wrote:
> On 15/09/06, Rajkumar S <rajkumars+git@gmail.com> wrote:
>> I am using StGIT to track a branch of a remote git repository
>> (actually a remote cvs repository, which I am tracking cvsimport)
> [...]
>> The .git/remotes/origin is
>> URL: /usr/local/pfSense/upstream/pfSense/.git
>> Pull: refs/heads/master:refs/heads/origin
>> Pull: refs/heads/avendor:refs/heads/avendor
>> Pull: refs/heads/Package-Reorg-2005:refs/heads/Package-Reorg-2005
>> Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
>>
>> My requirement is to track RELENG_1 branch with StGIT while
>> maintaining my own patches. but when I do a stg pull the messages are:
> [...]
>> It seems StGIT is trying to merge the origin branch from remote to
>> RELENG_1 of local. Is there a way to get RELENG_1 of remote to merge
>> with MyBranch (clone of "RELENG_1") of local?
>
> After StGIT pops all the patches, it just calls "git pull origin". My
> understanding of GIT is that this should update local RELENG_1 with
> the remote RELENG_1 from the "origin" repository. Anything wrong with
> my assumptions?
>
Well that will update origin, and then merge the result with the current
branch. That second part probabally isn't what you had in mind.
Normally you would git fetch origin to stop that happening, but that
also can't update the branch you are on.
Not sure if this helps.
-apw
^ permalink raw reply
* Re: [PATCH (take 2)] gitweb: Do not parse refs by hand, use git-peek-remote instead
From: Jakub Narebski @ 2006-09-15 10:49 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7v4pv91wqk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Now, once we start doing this, it may make sense to rethink how
> this function and git_get_references functions are used. I
> think
>
> git grep -n -e '^sub ' \
> -e git_get_references \
> -e git_get_refs_list gitweb/gitweb.perl
>
> would be instructive how wasteful the current code is.
>
> get_refs_list is called _TWICE_ in git_summary and worse yet
> very late in the function, after calling git_get_references that
> could already have done what the function does (by the way,
> git_get_references already knows how to use peek-remote output
> but for some reason it uses ls-remote -- I think you can safely
> rewrite it to use peek-remote). So you end up doing peek-remote
> three times to draw the summary page.
>
> git_get_references are called from almost everywhere that shows
> the list of commits, which is understandable because we would
> want to see those markers in the list.
>
> I very much suspect that you can use git_get_refs_list to return
> a hash and a sorted list at the same time from the same input
> and make git_summary to do with just a single call to it, and
> get rid of git_get_references with a little bit of restructuring
> of the caller.
We can easily collapse two calls for git_get_refs_list in gi_summary,
one for tags and one for heads into one call plus some filtering.
Changing git_get_refs_list to do also the job of git_get_references
means that in git_tags and git_heads we do extra the job of
git_get_references. Neither git_tags, nor git_heads use references and
refs marker; using the heads references in git_heads and tags
references in git_tags is repeating the same information twice,
cluttering the output. Unless we want to add yet another subroutine...
But as call to git-peek-remote is what takes most time, we can waste
some time processing references which we would not use for the sake of
clarity. Well, we can get rid of git_get_references too, if we don't
mind slight decrease in performance.
We would then use:
git_summary:
my ($refs, $reflist) = git_get_refs_list();
my @taglist = map { s!^tags/!! } grep { m!^tags/! } @$reflist;
my @headlist = map { s!^heads/!! } grep { m!^heads/! } @$reflist;
git_heads, git_tags:
my (undef, $taglist) = git_get_refs_list("tags");
my (undef, $headlist) = git_get_refs_list("heads");
everywhere else
my ($refs, undef) = git_get_refs_list($type);
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Tracking a branch using StGIT
From: Catalin Marinas @ 2006-09-15 10:42 UTC (permalink / raw)
To: Rajkumar S; +Cc: git
In-Reply-To: <64de5c8b0609150120h3aeee6dcv976da13134396654@mail.gmail.com>
On 15/09/06, Rajkumar S <rajkumars+git@gmail.com> wrote:
> I am using StGIT to track a branch of a remote git repository
> (actually a remote cvs repository, which I am tracking cvsimport)
[...]
> The .git/remotes/origin is
> URL: /usr/local/pfSense/upstream/pfSense/.git
> Pull: refs/heads/master:refs/heads/origin
> Pull: refs/heads/avendor:refs/heads/avendor
> Pull: refs/heads/Package-Reorg-2005:refs/heads/Package-Reorg-2005
> Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
>
> My requirement is to track RELENG_1 branch with StGIT while
> maintaining my own patches. but when I do a stg pull the messages are:
[...]
> It seems StGIT is trying to merge the origin branch from remote to
> RELENG_1 of local. Is there a way to get RELENG_1 of remote to merge
> with MyBranch (clone of "RELENG_1") of local?
After StGIT pops all the patches, it just calls "git pull origin". My
understanding of GIT is that this should update local RELENG_1 with
the remote RELENG_1 from the "origin" repository. Anything wrong with
my assumptions?
--
Catalin
^ permalink raw reply
* [PATCH 3/3 (take 2)] gitweb: Add link to "project_index" view to "project_list" page
From: Jakub Narebski @ 2006-09-15 9:11 UTC (permalink / raw)
To: git
In-Reply-To: <200609150459.27708.jnareb@gmail.com>
Add link to "project_index" view as [TXT] beside link to "opml" view,
(which is marked by [OPML]) to "project_list" page.
While at it add alternate links for "opml" and "project_list" to HTML
header for "project_list" view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Corrected alternate links (dumb error while copy'n'paste).
gitweb/gitweb.perl | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e900713..3079531 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1255,6 +1255,13 @@ EOF
printf('<link rel="alternate" title="%s log" '.
'href="%s" type="application/rss+xml"/>'."\n",
esc_param($project), href(action=>"rss"));
+ } else {
+ printf('<link rel="alternate" title="%s projects list" '.
+ 'href="%s" type="text/plain; charset=utf-8"/>'."\n",
+ $site_name, href(project=>undef, action=>"project_index"));
+ printf('<link rel="alternate" title="%s projects logs" '.
+ 'href="%s" type="text/x-opml"/>'."\n",
+ $site_name, href(project=>undef, action=>"opml"));
}
if (defined $favicon) {
print qq(<link rel="shortcut icon" href="$favicon" type="image/png"/>\n);
@@ -1309,7 +1316,9 @@ sub git_footer_html {
-class => "rss_logo"}, "RSS") . "\n";
} else {
print $cgi->a({-href => href(project=>undef, action=>"opml"),
- -class => "rss_logo"}, "OPML") . "\n";
+ -class => "rss_logo"}, "OPML") . " ";
+ print $cgi->a({-href => href(project=>undef, action=>"project_index"),
+ -class => "rss_logo"}, "TXT") . "\n";
}
print "</div>\n" .
"</body>\n" .
--
1.4.2
^ permalink raw reply related
* Re: [PATCH (take 2)] gitweb: Do not parse refs by hand, use git-peek-remote instead
From: Junio C Hamano @ 2006-09-15 9:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609151043.20681.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > But, if we change git_get_refs_list to do also work of git_get_references,
>> > we should also change git_get_references to not use info/refs file at all
>> > (it can, and usually for unknown reasons is stale) but always use
>> > git-peek-remote, for consistency.
>>
>> Yes that would make sense. A repository served by gitweb does
>> not necessarily has to serve objects over http transport, so it
>> is nicer not to require info/refs to even exist or up to date.
>
> We do not require info/refs, as currently git_get_references falls
> back to git-ls-remotes (should be git-peek-remote as it is faster)
> if info/refs does not exist. But info/refs is usually stale; I guess
> it is updated on pull/fetch/push, but not on commit.
Yes, we are in agreement and are saying the same thing.
^ permalink raw reply
* Re: Historical kernel repository size
From: Olivier Galibert @ 2006-09-15 9:03 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Thomas Gleixner, Linus Torvalds, Petr Baudis, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609142115560.2627@xanadu.home>
On Thu, Sep 14, 2006 at 09:19:04PM -0400, Nicolas Pitre wrote:
> Erm... Both incantations work fine fine here.
>
> > -rw-rw-r-- 1 tglx ftpadmin 13600376 Sep 14 22:16 pack-4d27038611fe7755938efd4a2745d5d5d35de1c1.idx
> > -rw-rw-r-- 1 tglx ftpadmin 158679705 Sep 14 22:16 pack-4d27038611fe7755938efd4a2745d5d5d35de1c1.pack
>
> And I get the same result as well.
For the curious, a 100/100 parameter gives a size of 154261771.
Disminishing returns, here I come.
OG.
^ permalink raw reply
* Re: stgit: cannot push a patch - Python trace dump
From: Catalin Marinas @ 2006-09-15 8:58 UTC (permalink / raw)
To: Auke Kok; +Cc: git
In-Reply-To: <450A3524.5040403@intel.com>
Auke Kok <auke-jan.h.kok@intel.com> wrote:
> I'm preparing patches for upstream and am haunted by an apparent
> patch breaking stg. The problem appears to be one or more of my
> patches breaking a push:
[...]
> I've been abusing stg by leaving the commit messages empty so I
> assume that that's the cause here, or related to the problem.
Thanks, I fixed StGIT to cope with this and I'll update the repository
and snapshot tonight (which, BTW, will contain the initial support for
patch history tracking).
--
Catalin
^ permalink raw reply
* Re: [PATCH (take 2)] gitweb: Do not parse refs by hand, use git-peek-remote instead
From: Jakub Narebski @ 2006-09-15 8:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vvenpzi1h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > But, if we change git_get_refs_list to do also work of git_get_references,
> > we should also change git_get_references to not use info/refs file at all
> > (it can, and usually for unknown reasons is stale) but always use
> > git-peek-remote, for consistency.
>
> Yes that would make sense. A repository served by gitweb does
> not necessarily has to serve objects over http transport, so it
> is nicer not to require info/refs to even exist or up to date.
We do not require info/refs, as currently git_get_references falls
back to git-ls-remotes (should be git-peek-remote as it is faster)
if info/refs does not exist. But info/refs is usually stale; I guess
it is updated on pull/fetch/push, but not on commit.
--
Jakub Narebski
Poland
^ permalink raw reply
* Tracking a branch using StGIT
From: Rajkumar S @ 2006-09-15 8:20 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
Hi,
I am using StGIT to track a branch of a remote git repository
(actually a remote cvs repository, which I am tracking cvsimport)
The remote repository git branch show:
Package-Reorg-2005
RELENG_1
avendor
* master
origin
My local repository has:
root@beastie:# stg branch -l
Available branches:
> s MyBranch | clone of "RELENG_1"
Package-Reorg-2005 |
s RELENG_1 |
avendor |
master |
origin |
The .git/remotes/origin is
URL: /usr/local/pfSense/upstream/pfSense/.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/avendor:refs/heads/avendor
Pull: refs/heads/Package-Reorg-2005:refs/heads/Package-Reorg-2005
Pull: refs/heads/RELENG_1:refs/heads/RELENG_1
My requirement is to track RELENG_1 branch with StGIT while
maintaining my own patches. but when I do a stg pull the messages are:
Popping all applied patches... done
Pulling from "origin"...
Trying really trivial in-index merge... fatal: Merge requires
file-level merging Nope. Merging HEAD with
c0a06b86b8431293214f5eb18e49fcb8117c6070 Merging:
997e28966d7b7964562232628cc4f64dccbead9e Execute after commands via sh
&
c0a06b86b8431293214f5eb18e49fcb8117c6070 Execute after commands via sh &
found 1 common ancestor(s):
1b08ecedad1e6a7199f12d1fad97373587c85454 Minor nitpick. <br> after
firmware branch select box
CONFLICT (add/add): File usr/local/www/status_filter_reload.php added
non-identically in both branches. Adding as
usr/local/www/status_filter_reload.php~HEAD and
usr/local/www/status_filter_reload.php~c0a06b86b8431293214f5eb18e49fcb8117c6070
instead.
<snip>
It seems StGIT is trying to merge the origin branch from remote to
RELENG_1 of local. Is there a way to get RELENG_1 of remote to merge
with MyBranch (clone of "RELENG_1") of local?
raj
^ permalink raw reply
* Re: [PATCH (take 2)] gitweb: Do not parse refs by hand, use git-peek-remote instead
From: Junio C Hamano @ 2006-09-15 7:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eedjrj$tja$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> But, if we change git_get_refs_list to do also work of git_get_references,
> we should also change git_get_references to not use info/refs file at all
> (it can, and usually for unknown reasons is stale) but always use
> git-peek-remote, for consistency.
Yes that would make sense. A repository served by gitweb does
not necessarily has to serve objects over http transport, so it
is nicer not to require info/refs to even exist or up to date.
^ permalink raw reply
* Re: cvs import
From: Markus Schiltknecht @ 2006-09-15 7:37 UTC (permalink / raw)
To: Shawn Pearce
Cc: Michael Haggerty, Jon Smirl, Martin Langhoff, Git Mailing List,
monotone-devel, dev
In-Reply-To: <20060914155003.GB9657@spearce.org>
Hi,
Shawn Pearce wrote:
> I don't know how the Monotone guys feel about it but I think Git
> is happy with the data in any order, just so long as the dependency
> chains aren't fed out of order. Which I think nearly all changeset
> based SCMs would have an issue with. So we should be just fine
> with the current chronological order produced by cvs2svn.
I'd vote for splitting into file data (and delta / patches) import and
metadata import (author, changelog, DAG).
Monotone would be happiest if the file data were sent one file after
another and (inside each file) in the order of each file's single
history. That guarantees good import performance for monotone. I imagine
it's about the same for git. And if you have to somehow cache the files
anyway, subversion will benefit, too. (Well, at least the cache will
thank us with good performance).
After all file data has been delivered, the metadata can be delivered.
As neigther monotone nor git care much if they are chronological across
branches, I'd vote for doing it that way.
Regards
Markus
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: Allow for href() to be used for projectless links
From: Jakub Narebski @ 2006-09-15 7:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmd1zma7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Change adding project to params if $params{"project"} is false
>> to adding project to params if it not exist. It allows for href()
>> to be used for projectless links by using "project=>undef" as
>> argument, while still adding project to params by default
>> in the most common case.
>
> This did not parse very well, at least for me.
O.K. let me rephrase it. Before this patch href() ensured that we had
p=<project> among CGI params, by adding it if it was not provided. Some
actions don't need project parameter, namely "project_list",
"project_index" and "opml". Moreover "project_list" view was sed as a
_home_ link, i.e. default action when project was not provided (just like
summary is default action when project is provided).
The change introduced by this patch allow to use href() to generate links
also for "project_list" and "opml" views. The only links which do not use
href() are anchor links, and $home_link link.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH (take 2)] gitweb: Do not parse refs by hand, use git-peek-remote instead
From: Jakub Narebski @ 2006-09-15 7:14 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pv91wqk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> This is in response to Linus work on packed refs. Additionally it
>> makes gitweb work with symrefs, too.
>>
>> Do not parse refs by hand, using File::Find and reading individual
>> heads to get hash of reference, but use git-peek-remote output
>> instead.
>
> Looks nicer. Will apply.
>
> Now, once we start doing this, it may make sense to rethink how
> this function and git_get_references functions are used.
[...]
> I very much suspect that you can use git_get_refs_list to return
> a hash and a sorted list at the same time from the same input
> and make git_summary to do with just a single call to it, and
> get rid of git_get_references with a little bit of restructuring
> of the caller.
It can be done. Well, we could also collapse git_get_references and
git_get_refs_list into one subroutine, but it would be slightly slower
than git_get_references.
But, if we change git_get_refs_list to do also work of git_get_references,
we should also change git_get_references to not use info/refs file at all
(it can, and usually for unknown reasons is stale) but always use
git-peek-remote, for consistency.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: Allow for href() to be used for projectless links
From: Junio C Hamano @ 2006-09-15 6:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609150457.16924.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Change adding project to params if $params{"project"} is false
> to adding project to params if it not exist. It allows for href()
> to be used for projectless links by using "project=>undef" as
> argument, while still adding project to params by default
> in the most common case.
This did not parse very well, at least for me.
> @@ -1304,9 +1305,11 @@ sub git_footer_html {
> if (defined $descr) {
> print "<div class=\"page_footer_text\">" . esc_html($descr) . "</div>\n";
> }
> - print $cgi->a({-href => href(action=>"rss"), -class => "rss_logo"}, "RSS") . "\n";
> + print $cgi->a({-href => href(action=>"rss"),
> + -class => "rss_logo"}, "RSS") . "\n";
> } else {
> - print $cgi->a({-href => href(action=>"opml"), -class => "rss_logo"}, "OPML") . "\n";
> + print $cgi->a({-href => href(project=>undef, action=>"opml"),
> + -class => "rss_logo"}, "OPML") . "\n";
> }
> print "</div>\n" .
> "</body>\n" .
Argh. While I very much welcome folding of the long lines, I'd
rather see a separate patch to clean up other loooooooong lines
the current gitweb code has.
^ 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