* Trouble with git-svn when upstream svn URL changed
From: Seth Falcon @ 2006-12-08 17:43 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Hi,
One of the repositories I have been tracking with git-svn was
reorganized and the path that I have been tracking is now in a new
location.
I was hoping that the following would work:
git clone orig new
cd new
git svn rebuild $NEW_URL
I also tried
git svn rebuild --remote $NEW_URL
This have some output that looked reasonable (svn rev nums and git
sha1's). But git svn fetch does nothing and I don't seem to have any
of the new content. Am I using this incorrectly?
I guess I can create a fresh git repos using git-svn init and then
fetch all of my dev branches from the original repository.
git version 1.4.4.1.g03c8-dirty (no changes to git-svn)
Thanks,
^ permalink raw reply
* Re: Trouble with git-svn when upstream svn URL changed
From: Eric Wong @ 2006-12-08 18:11 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m21wnai8qe.fsf@ziti.local>
Seth Falcon <sethfalcon@gmail.com> wrote:
> Hi,
>
> One of the repositories I have been tracking with git-svn was
> reorganized and the path that I have been tracking is now in a new
> location.
>
> I was hoping that the following would work:
>
> git clone orig new
> cd new
> git svn rebuild $NEW_URL
>
> I also tried
>
> git svn rebuild --remote $NEW_URL
>
> This have some output that looked reasonable (svn rev nums and git
> sha1's). But git svn fetch does nothing and I don't seem to have any
> of the new content. Am I using this incorrectly?
This is incorrect, rebuild is not designed to handle new urls. However,
git/git-svn are very flexible beasts :)
> I guess I can create a fresh git repos using git-svn init and then
> fetch all of my dev branches from the original repository.
You can look at "Advanced Example: Tracking a Reorganized Repository"
in the manpage. Ignore the text about --follow-parent since you
already have the old stuff fetched, and start following the instructions
beginning with "# And now, we continue tracking the new revisions:"
If that fails (I don't think it would); you can always link branches
together using grafts (git-svn graft-branches tries to automate this;
but it's imperfect).
--
^ permalink raw reply
* Re: [PATCH] Allow building GIT in a different directory from the source directory
From: Han-Wen Nienhuys @ 2006-12-08 18:14 UTC (permalink / raw)
To: git
In-Reply-To: <elc84p$4cs$1@sea.gmane.org>
Jakub Narebski escreveu:
> Perhaps we should add this to INSTALL file, or to comments in either
> Makefile, or configure.ac?
yes, will do.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Jon Loeliger @ 2006-12-08 18:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sf, Git List, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612011134080.3695@woody.osdl.org>
On Fri, 2006-12-01 at 14:13, Linus Torvalds wrote:
> So this is why it's really important that the submodule really is a git
> repository in its own right, and why committing stuff in the supermodule
> NEVER affect the submodule itself directly (it might _cause_ you to also
> do a commit in the submodule indirectly, but the submodule commit MUST be
> totally independent, and stand on its own).
An implication of this is that the entire administrative
responsibility for having some super-sub module interaction
lies entirely with the supermodule.
Why not have a "glue" object at the "stub"-interface of
the supermodule tree that provides policy mappings to
the sub-modules. Perhaps indicating git URL location,
mappings of branch names between super- and sub- modules,
special commit SHA1s, user policy or config choices at
the boundary, and things like that.
Is that the sort of direction we are headed?
jdl
^ permalink raw reply
* Re: Trouble with git-svn when upstream svn URL changed
From: Seth Falcon @ 2006-12-08 18:34 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061208181109.GA10475@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> This is incorrect, rebuild is not designed to handle new urls.
ok, I was lead astray by this part of the doc for rebuild:
A Subversion URL may be optionally specified at the
command-line if the directory/repository you're tracking has
moved or changed protocols.
> However, git/git-svn are very flexible beasts :)
>
>> I guess I can create a fresh git repos using git-svn init and then
>> fetch all of my dev branches from the original repository.
>
> You can look at "Advanced Example: Tracking a Reorganized Repository"
> in the manpage. Ignore the text about --follow-parent since you
> already have the old stuff fetched, and start following the instructions
> beginning with "# And now, we continue tracking the new revisions:"
Oh, sorry I didn't find that example. This worked perfectly, thanks!
One question: My fingers are in the habit of typing remotes/git-svn.
Can I do:
cd .git/svn
rm -r git-svn
mv git-newsvn git-svn
Or is there a safer way to rename? Or are there other config-file
ways to make this work -- to provide an alias?
Thank you so much for the prompt reply. Nice to get going again and
with the full history.
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Marco Costalba @ 2006-12-08 18:34 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Shawn Pearce, Git Mailing List
In-Reply-To: <45781639.1050208@op5.se>
On 12/7/06, Andreas Ericsson <ae@op5.se> wrote:
> Shawn Pearce wrote:
> >
> > Perhaps there is some fast IPC API supported by Qt that you could
> > use to run the revision listing outside of the main UI process,
> > to eliminate the bottlenecks you are seeing and remove the problems
> > noted above? One that doesn't involve reading from a pipe I mean...
> >
>
> Why not just fork() + exec() and read from the filedescriptor? You can
> up the output buffer of the forked program to something suitable, which
> means the OS will cache it for you until you copy it to a buffer in qgit
> (i.e., read from the descriptor).
>
Please, what do you mean with "something suitable"? How can I redirect
the output to a memory buffer or to a file that the OS will cache
*until* I've copied it?
If I redirect to a 'normal' file, this will be flushed by OS after
some time, normally few seconds.
Could you please post links with examples/docs about this kind of
implementation?
Thanks
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-12-08 18:45 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Linus Torvalds, sf, Git List, Martin Waitz
In-Reply-To: <1165602554.19135.309.camel@cashmere.sps.mot.com>
On Fri, Dec 08, 2006 at 12:29:14PM -0600, Jon Loeliger wrote:
> Why not have a "glue" object at the "stub"-interface of
> the supermodule tree that provides policy mappings to
> the sub-modules. Perhaps indicating git URL location,
> mappings of branch names between super- and sub- modules,
> special commit SHA1s, user policy or config choices at
> the boundary, and things like that.
>
> Is that the sort of direction we are headed?
Not unless you have something useful in mind that could be put in
these glue objects. URLs and branch names, in particular, should
not be stored in the repository itself, but in configuration files,
since they will be different for different copies of the repo.
^ permalink raw reply
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Nguyen Thai Ngoc Duy @ 2006-12-08 19:11 UTC (permalink / raw)
To: git
In-Reply-To: <elc6g3$v1m$1@sea.gmane.org>
On 12/9/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>
> git-sh-setup isn't a 'normal' binary, in that it should be called by
> bash only and not run in a subshell. Therefore, it should not be installed
> in a executable directory, but rather in $prefix/share/git-core/
Executables should not go to $prefix/share I think. Maybe $prefix/libexec?
BTW, I think you touched a larger issue: plumbling/porcelain separation.
--
^ permalink raw reply
* [PATCH] Add branch.*.localmerge and documentation update
From: Josef Weidendorfer @ 2006-12-08 19:12 UTC (permalink / raw)
To: Santi Béjar
Cc: Junio C Hamano, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612081823.45565.Josef.Weidendorfer@gmx.de>
Clarify the meaning of branch.*.merge option and add a similar
branch.*.localmerge option, which can be used to specify a local
tracking branch to be merged by default.
Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This now gives a warning.
The value of branch.*.merge can be a list to get an octopus
merge. I chose the same way for branch.*.localmerge, and if
you specify both options, the octopus merge will have even
more parents ;-)
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
This implements to branch.*.localmerge option as counterpart
to branch.*.merge as discussed.
To get the "No default merge when any branch.*.(local)merge is given,
but not in current branch" feature, what is the way to check this,
as git-repo-config can not match with regexps against config keys?
Josef
Documentation/config.txt | 23 +++++++++++++++++++++--
git-parse-remote.sh | 40 +++++++++++++++++++++++++++++++---------
2 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9090762..6e19130 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -125,10 +125,29 @@ apply.whitespace::
branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
+ If this option is not given, `git fetch` defaults to "origin".
branch.<name>.merge::
- When in branch <name>, it tells `git fetch` the default remote branch
- to be merged.
+ When in branch <name>, it tells `git fetch` the default refspec to
+ be marked for merging in FETCH_HEAD. The value has to exactly
+ match a remote part of the refspecs which are fetched from the remote
+ repository given by "branch.<name>.remote".
+ The merge information is used by `git pull` (which first calls
+ `git fetch`) for the default merge action.
+ Without this or a "branch.<name>.localmerge" option, `git pull` defaults to
+ the first refspec fetched.
+ Specify multiple values to get an octopus merge.
+
+branch.<name>.localmerge::
+ When in branch <name>, it tells `git fetch` the default refspec to
+ be marked for merging in FETCH_HEAD. The value has to exactly
+ match a local part (i.e. the local tracking branch) of the refspecs
+ which are fetched from the remote repository given by "branch.<name>.remote".
+ The merge information is used by `git pull` (which first calls
+ `git fetch`) for the default merge action.
+ Without this or a "branch.<name>.merge" option, `git pull` defaults to the
+ first refspec fetched.
+ Specify multiple values to get an octopus merge.
pager.color::
A boolean to enable/disable colored output when the pager is in
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index da064a5..08ab272 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -133,7 +133,9 @@ canon_refs_list_for_fetch () {
# leave the branches in branch.${curr_branch}.merge alone,
# or the first one otherwise; add prefix . to the rest
# to prevent the secondary branches to be merged by default.
- merge_branches=
+ merge_remotebranches=
+ merge_localbranches=
+ found_mergerefs=
if test "$1" = "-d"
then
shift ; remote="$1" ; shift
@@ -141,8 +143,10 @@ canon_refs_list_for_fetch () {
then
curr_branch=$(git-symbolic-ref HEAD | \
sed -e 's|^refs/heads/||')
- merge_branches=$(git-repo-config \
+ merge_remotebranches=$(git-repo-config \
--get-all "branch.${curr_branch}.merge")
+ merge_localbranches=$(git-repo-config \
+ --get-all "branch.${curr_branch}.localmerge")
fi
set x $(expand_refs_wildcard "$@")
shift
@@ -160,17 +164,31 @@ canon_refs_list_for_fetch () {
remote=$(expr "z$ref" : 'z\([^:]*\):')
local=$(expr "z$ref" : 'z[^:]*:\(.*\)')
dot_prefix=.
- if test -z "$merge_branches"
+ if test ! -z "$merge_remotebranches"
then
- merge_branches=$remote
- dot_prefix=
- else
- for merge_branch in $merge_branches
+ for merge_branch in $merge_remotebranches
do
- [ "$remote" = "$merge_branch" ] &&
- dot_prefix= && break
+ [ "$remote" = "$merge_branch" ] &&
+ dot_prefix= && break
done
fi
+ if test ! -z "$merge_localbranches"
+ then
+ for merge_branch in $merge_localbranches
+ do
+ [ "$local" = "$merge_branch" ] &&
+ dot_prefix= && break
+ done
+ fi
+ if test -z "$merge_remotebranches" -a -z "$merge_localbranches"
+ then
+ merge_remotebranches=$remote
+ dot_prefix=
+ fi
+ if test -z $dot_prefix
+ then
+ found_mergeref=true
+ fi
case "$remote" in
'') remote=HEAD ;;
refs/heads/* | refs/tags/* | refs/remotes/*) ;;
@@ -191,6 +209,10 @@ canon_refs_list_for_fetch () {
fi
echo "${dot_prefix}${force}${remote}:${local}"
done
+ if test -z $found_mergeref
+ then
+ echo >&2 "Warning: No merge candidate because of no match with branch.*.merge or branch.*.localmerge"
+ fi
}
# Returns list of src: (no store), or src:dst (store)
--
^ permalink raw reply related
* Re: Trouble with git-svn when upstream svn URL changed
From: Eric Wong @ 2006-12-08 19:13 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2wt52fd8p.fsf@ziti.local>
Seth Falcon <sethfalcon@gmail.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > This is incorrect, rebuild is not designed to handle new urls.
>
> ok, I was lead astray by this part of the doc for rebuild:
>
> A Subversion URL may be optionally specified at the
> command-line if the directory/repository you're tracking has
> moved or changed protocols.
Hmm.. it seems that rebuild will work as intended iff you didn't clone
(and therefore still have .git/svn/git-svn/.rev_db intact). Otherwise,
it will rebuild the .rev_db file and ignore your specified URL. Perhaps
running rebuild twice (specifying the URL on a second clone) after a
clone would work. I honestly haven't used or looked at rebuild in a
while.
> > However, git/git-svn are very flexible beasts :)
> >
> >> I guess I can create a fresh git repos using git-svn init and then
> >> fetch all of my dev branches from the original repository.
> >
> > You can look at "Advanced Example: Tracking a Reorganized Repository"
> > in the manpage. Ignore the text about --follow-parent since you
> > already have the old stuff fetched, and start following the instructions
> > beginning with "# And now, we continue tracking the new revisions:"
>
> Oh, sorry I didn't find that example. This worked perfectly, thanks!
>
> One question: My fingers are in the habit of typing remotes/git-svn.
> Can I do:
> cd .git/svn
> rm -r git-svn
> mv git-newsvn git-svn
>
> Or is there a safer way to rename? Or are there other config-file
> ways to make this work -- to provide an alias?
You need to mv refs/remotes/git-newsvn refs/remotes/git-svn, too. Then
it should be safe.
--
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Junio C Hamano @ 2006-12-08 19:18 UTC (permalink / raw)
To: Pazu; +Cc: git
In-Reply-To: <loom.20061208T131919-178@post.gmane.org>
Pazu <pazu@pazu.com.br> writes:
> # Please enter the commit message for your changes.
> # (Comment lines starting with '#' will not be included)
> # On branch refs/heads/next
> # Updated but not checked in:
> # (will commit)
> #
> # modified: perl/Makefile
> # modified: var.c
>
> Here's where the magic would happen. Removing the line "modified: var.c" would
> remove var.c from this commit. Of course, the template message should be
> modified to tell the user he can do that.
>
> So, what do you think about this?
Personally, I would refuse to use such a modified git, because
often the first thing I would do in the commit log buffer is
check the listed files and remove the '# ...' lines while
typing. I do not want that to affect the set of changes I
staged in any way.
But maybe that is just me.
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Jakub Narebski @ 2006-12-08 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsaui4cn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Pazu <pazu@pazu.com.br> writes:
>
>> # Please enter the commit message for your changes.
>> # (Comment lines starting with '#' will not be included)
>> # On branch refs/heads/next
>> # Updated but not checked in:
>> # (will commit)
>> #
>> # modified: perl/Makefile
>> # modified: var.c
>>
>> Here's where the magic would happen. Removing the line "modified: var.c" would
>> remove var.c from this commit. Of course, the template message should be
>> modified to tell the user he can do that.
>>
>> So, what do you think about this?
>
> Personally, I would refuse to use such a modified git, because
> often the first thing I would do in the commit log buffer is
> check the listed files and remove the '# ...' lines while
> typing. I do not want that to affect the set of changes I
> staged in any way.
>
> But maybe that is just me.
I was to raise the same objection.
But this can be solved by using magic _only_ if the template with exception
of "modified:" lines matches, and if there is at least one file
in "modified:" section.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Junio C Hamano @ 2006-12-08 19:31 UTC (permalink / raw)
To: Salikh Zakirov; +Cc: git
In-Reply-To: <4579529F.9030401@Intel.com>
Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:
> Junio Hamano wrote:
>> +Instead of staging files after each individual change, you can
>> +tell `git commit` to notice the changes to the tracked files in
>> +your working tree and do corresponding `git add` and `git rm`
>> +for you.
>
> This part is confusing as hell to anyone having any experience
> with either CVS, SVN, Hg or Monotone, as doing "corresponding `git add`
> and `git rm`" commands automatically will be interpreted as adding
> untracked files automatically, which is not the case here.
Well, that's why the description says 'the changes to the
tracked files' above to make it clear. An obvious alternative
is not to talk about staging in terms of `git add` and `git rm`
but instead mention `git update-index` in that part of the
documentation, but I think that is going backwards. I think the
conclusion of recent discussions is not to paper over the
differences from new people (nor making git closer to other
systems by castrating git), but make things easier to learn for
them. My attempt to update git-commit documentation is a part
of this effort.
Better rewording is very much appreciated.
But you are right. Prior experiences with other systems would
make it harder to learn git here, because 'git add', especially
with Nico's enhancement in 'next', is different from 'cvs add'.
The problem is that these systems do not have the concept of
tracking 'contents' (they instead track paths), and 'add' to
them mean 'add the named paths to the set of tracked paths'.
On the other hand, git fundamentally tracks contents. We do
have the concept of 'the set of tracked paths', but that is a
side effect of tracking contents. In other words, you do not
'add' a path without 'add'ing its contents.
By the way, I have been wondering if the --only variant of the
command should also add untracked files to the index. That is:
$ git commit foo.c '*.h'
currently barfs if foo.c is not tracked, and/or there is no
tracked header files. We could instead run git-update-index
--add on them.
Incidentally, this would make this sequence possible:
$ tar xf /var/tmp/foo.tar ;# extract tarball here.
$ git init-db
$ git commit -m 'initial import' .
^ permalink raw reply
* Re: [PATCH 1/5] rerere: avoid misrecording on a skipped or aborted rebase/am
From: Junio C Hamano @ 2006-12-08 19:33 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <11655749724034-git-send-email-normalperson@yhbt.net>
This is good, but Documentation/git-rerere.txt should talk about
this new option you added.
^ permalink raw reply
* Re: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Eric Wong @ 2006-12-08 19:37 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <elc6g3$v1m$1@sea.gmane.org>
Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>
> git-sh-setup isn't a 'normal' binary, in that it should be called by
> bash only and not run in a subshell. Therefore, it should not be installed
> in a executable directory, but rather in $prefix/share/git-core/
This seems to break existing hooks, or at least old repositories can
be stuck using an old version of git-sh-setup in those hooks.
You could to add GIT_datadir to PATH before invoking hooks for existing
ones to work, or write some sort of conversion script...
> ---
> Makefile | 10 ++++++++--
> git-am.sh | 2 +-
> git-applymbox.sh | 2 +-
> git-applypatch.sh | 2 +-
> git-bisect.sh | 2 +-
> git-checkout.sh | 2 +-
> git-clean.sh | 2 +-
> git-commit.sh | 2 +-
> git-fetch.sh | 2 +-
> git-instaweb.sh | 2 +-
> git-lost-found.sh | 2 +-
> git-merge.sh | 2 +-
> git-pull.sh | 2 +-
> git-quiltimport.sh | 2 +-
> git-rebase.sh | 2 +-
> git-repack.sh | 2 +-
> git-request-pull.sh | 2 +-
> git-reset.sh | 2 +-
> git-resolve.sh | 2 +-
> git-revert.sh | 2 +-
> git-tag.sh | 2 +-
> git-verify-tag.sh | 2 +-
> 22 files changed, 29 insertions(+), 23 deletions(-)
You shoudl probably change these, too:
templates/hooks--pre-applypatch:. git-sh-setup
templates/hooks--applypatch-msg:. git-sh-setup
--
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Nicolas Pitre @ 2006-12-08 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Salikh Zakirov, git
In-Reply-To: <7vfybqi3r1.fsf@assigned-by-dhcp.cox.net>
On Fri, 8 Dec 2006, Junio C Hamano wrote:
> By the way, I have been wondering if the --only variant of the
> command should also add untracked files to the index. That is:
>
> $ git commit foo.c '*.h'
>
> currently barfs if foo.c is not tracked, and/or there is no
> tracked header files. We could instead run git-update-index
> --add on them.
That would be a good thing indeed.
> Incidentally, this would make this sequence possible:
>
> $ tar xf /var/tmp/foo.tar ;# extract tarball here.
> $ git init-db
> $ git commit -m 'initial import' .
... making the UI even more consistent.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Lars Hjemli @ 2006-12-08 19:49 UTC (permalink / raw)
To: H. Peter Anvin, Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <457995F8.1080405@zytor.com>
On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Linus Torvalds wrote:
> > I could write a simple C caching thing that just hashes the CGI arguments
> > and uses a hash to create a cache (and proper lock-files etc to serialize
> > access to a particular cache object while it's being created) fairly
> > easily, but I'm pretty sure people would much prefer a mod_perl thing just
> > to avoid the fork/exec overhead with Apache (I think mod_perl allows
> > Apache to run perl scripts without it), and that means I'm not the right
> > person any more.
>
> True about mod_perl. Haven't messed with that myself, either.
> fork/exec really is very cheap on Linux, so it's not a huge deal.
I've been playing around with a "native git" cgi thingy the last week
(I call it cgit), and I've been thinking about adding exactly this
kind of caching to it. And since it's basically a standard git command
written in C, it should have less overhead than any perl
implementation.
It's far from ready yet, but I'll try to publish some code this
weekend just in case someone finds it interesting.
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-08 19:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <8c5c35580612081149y2042c62j55b1b7b3f23da6ad@mail.gmail.com>
Lars Hjemli wrote:
> On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
>> Linus Torvalds wrote:
>> > I could write a simple C caching thing that just hashes the CGI
>> arguments
>> > and uses a hash to create a cache (and proper lock-files etc to
>> serialize
>> > access to a particular cache object while it's being created) fairly
>> > easily, but I'm pretty sure people would much prefer a mod_perl
>> thing just
>> > to avoid the fork/exec overhead with Apache (I think mod_perl allows
>> > Apache to run perl scripts without it), and that means I'm not the
>> right
>> > person any more.
>>
>> True about mod_perl. Haven't messed with that myself, either.
>> fork/exec really is very cheap on Linux, so it's not a huge deal.
>
> I've been playing around with a "native git" cgi thingy the last week
> (I call it cgit), and I've been thinking about adding exactly this
> kind of caching to it. And since it's basically a standard git command
> written in C, it should have less overhead than any perl
> implementation.
>
Trust me, perl, or CGI, is not the problem. It's all about I/O traffic
generated by git.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Lars Hjemli @ 2006-12-08 19:59 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <4579C234.5080709@zytor.com>
On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Trust me, perl, or CGI, is not the problem. It's all about I/O traffic
> generated by git.
Yes, I understand. That's why I've been thinking about internal
caching of pages.
It's just a kick doing it in C, playing around with the git internals :-)
--
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-08 20:02 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <8c5c35580612081159r325bfe1dsa764da050d63606b@mail.gmail.com>
Lars Hjemli wrote:
> On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
>> Trust me, perl, or CGI, is not the problem. It's all about I/O traffic
>> generated by git.
>
> Yes, I understand. That's why I've been thinking about internal
> caching of pages.
Caching, preferrably with smarts, is the key.
> It's just a kick doing it in C, playing around with the git internals :-)
That's fine, but it does make it harder to maintain.
-hpa
^ permalink raw reply
* [PATCH 6/5] git-rerere: document the 'clear' and 'diff' commands
From: Eric Wong @ 2006-12-08 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vbqmei3nx.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-rerere.txt | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index 8b6b651..de65cce 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -7,8 +7,7 @@ git-rerere - Reuse recorded resolve
SYNOPSIS
--------
-'git-rerere'
-
+'git-rerere' [clear|diff]
DESCRIPTION
-----------
@@ -167,6 +166,25 @@ would conflict the same way the test merge you resolved earlier.
`git-rerere` is run by `git rebase` to help you resolve this
conflict.
+COMMANDS
+--------
+
+Normally, git-rerere is run without arguments or user-intervention.
+However, it has several commands that allow it to interact with
+its working state.
+
+'clear'::
+
+This resets the metadata used by rerere if a merge resolution is to be
+is aborted. Calling gitlink:git-am[1] --skip or gitlink:git-rebase[1]
+[--skip|--abort] will automatcally invoke this command.
+
+'diff'::
+
+This displays diffs for the current state of the resolution. It is
+useful for tracking what has changed while the user is resolving
+conflicts. Additional arguments are passed directly to the system
+diff(1) command installed in PATH.
Author
------
--
1.4.4.2.g860f4
^ permalink raw reply related
* Re: git pull and merging.
From: Santi Béjar @ 2006-12-08 20:09 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Junio C Hamano, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612081823.45565.Josef.Weidendorfer@gmx.de>
On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Friday 08 December 2006 02:56, Santi Béjar wrote:
> > > [remote "repo"]
> > > url = ...
> > > fetch = branch1
> > > fetch = branch2
> > >
> > > [branch "mybranch1"]
> > > remote = repo
> > > merge = branch1
> > >
> > > actually looks fine, and is the only possible way.
> > > But still, this does not work.
> >
> > It works for me.
> >
> > > You have to specify
> > >
> > > merge = refs/heads/branch1
> >
> > It does not.
> >
> > The merge line must match exactly the remote part of the refspec.
>
> Yes, you are right; I just looked it up in git-parse-remote.
> Sorry about any confusion.
>
> >
> > >
> > > That's confusing (perhaps I can come up with a patch
> > > to allow "branch1" alone).
> > >
> > > So probably the best way is to write some more detailed
> > > explanation into the docu ...
> >
> > Perhaps that the branch.<name>.remote and branch.<name>.merge have the
> > equivalent meaning as the parameters of git-pull?
>
> We want to fetch multiple refs from one remote in a row. So what
> are you proposing? That branch.<name>.merge has to exactly
> specify one remote? I do not think this is needed.
I'm not proposing anything. What I wanted to say is that we could
document the ...remote and ...merge configs as the default parameters
of git-pull (this is how it is implemented already).
>
> Actually, I am really for a new branch.<name>.localmerge option,
> and keeping branch.<name>.merge (but not advertising it).
I do not see anything wrong with the current ...remote and ...merge
(see above), but I'm not against the ...localmerge config.
^ permalink raw reply
* Re: Fast access git-rev-list output: some OS knowledge required
From: Michael K. Edwards @ 2006-12-08 20:10 UTC (permalink / raw)
To: Marco Costalba; +Cc: Andreas Ericsson, Shawn Pearce, Git Mailing List
In-Reply-To: <e5bfff550612081034q5e4c0c93s3512fce2f11b1fab@mail.gmail.com>
There is a very handy solution to this problem called "tmpfs". It
should already be mounted at /tmp. Put tmp.txt there and your problem
will go away.
Cheers,
^ permalink raw reply
* Re: git-svnimport breakage as of git-1.4.4
From: Sasha Khapyorsky @ 2006-12-08 20:32 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
In-Reply-To: <1165505193.26874.13.camel@systems03.lan.brontes3d.com>
Hi,
On 10:26 Thu 07 Dec , Daniel Drake wrote:
>
> git-svnimport broken between git-1.4.3.5 and git-1.4.4
>
> I have found that commit 83936a29e275bc0c04f60d3333e4951a9e16b1fc is the
> cause of this.
>
> I am using git-svnimport to work with a repo with this layout:
>
> https://server/repo/trunk
> https://server/repo/tags/x.y.z
> https://server/repo/branches/somebranch
>
> Starting a fresh import:
>
> # git-svnimport -v -i -C repo -r https://server repo
Is this 'server' public? Can I rerun this git-svnimport?
If not, please try the patch:
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cbaa8ab..b9de446 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -210,6 +210,12 @@ $svn .= "/$svn_dir" if defined $svn_dir;
my $svn2 = SVNconn->new($svn);
$svn = SVNconn->new($svn);
+if($svn_dir) {
+ $svn_dir =~ s#/*$#/#;
+} else {
+ $svn_dir = "";
+}
+
my $lwp_ua;
if($opt_d or $opt_D) {
$svn_url = URI->new($svn_url)->canonical;
@@ -906,7 +912,7 @@ sub commit_all {
my ($changed_paths, $revision, $author, $date, $message, $pool) = @_;
my %p;
while(my($path,$action) = each %$changed_paths) {
- $p{$path} = [ $action->action,$action->copyfrom_path, $action->copyfrom_rev, $path ];
+ $p{$path} = [ $action->action,$svn_dir$action->copyfrom_path, $action->copyfrom_rev, $svn_dir$path ];
}
$changed_paths = \%p;
Thanks,
^ permalink raw reply related
* Problem compiling: that perl thing again
From: Luben Tuikov @ 2006-12-08 20:36 UTC (permalink / raw)
To: git
Over the last 2 months each time I pull, check out next and compile,
I'm seeing _some_ kind of problem with compiling the perl section
of git. Sometimes git-reset --hard, or a fresh checkout, or git-clean
resolve the situation. But not this time.
Here is what I see now:
$ make
...
make -C perl PERL_PATH='/usr/bin/perl' prefix='/home/luben' all
make[1]: Entering directory `/home/luben/projects/git-next/perl'
Makefile out-of-date with respect to Makefile.PL
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/Config.pm
/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE/config.h
Cleaning current config before rebuilding Makefile...
mv: cannot stat `perl.mak': No such file or directory
make[1]: *** [perl.mak] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/home/luben/projects/git-next/perl'
make: *** [all] Error 2
$ git-rev-list --max-count=1 HEAD
e1e8377415c8754c3773c09b78baaffa89d6fa9e
So, where is "perl.mak"?
Luben
^ 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