* [PATCH] git-add--interactive: never skip files included in index
From: Pauli Virtanen @ 2009-10-10 15:51 UTC (permalink / raw)
To: git; +Cc: Pauli Virtanen
Make "git add -p" to not skip files that are in index even if they are
excluded (by .gitignore etc.). This fixes the contradictory behavior
that "git status" and "git commit -a" listed such files as modified, but
"git add -p FILENAME" ignored them.
Signed-off-by: Pauli Virtanen <pav@iki.fi>
---
git-add--interactive.perl | 2 +-
t/t3701-add-interactive.sh | 18 ++++++++++++++++++
2 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 392efb9..69aeaf0 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -259,7 +259,7 @@ sub list_modified {
@tracked = map {
chomp $_;
unquote_path($_);
- } run_cmd_pipe(qw(git ls-files --exclude-standard --), @ARGV);
+ } run_cmd_pipe(qw(git ls-files --), @ARGV);
return if (!@tracked);
}
diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
index 62fd65e..89bfdcb 100755
--- a/t/t3701-add-interactive.sh
+++ b/t/t3701-add-interactive.sh
@@ -138,6 +138,24 @@ test_expect_success 'real edit works' '
test_cmp expected output
'
+cat >.gitignore <<EOF
+file
+EOF
+cat >file <<EOF
+changed
+EOF
+test_expect_success 'skip files similarly as commit -a' '
+ git reset
+ echo y | git add -p file &&
+ git diff >output &&
+ git reset &&
+ git commit -am commit &&
+ git diff >expected &&
+ test_cmp expected output &&
+ git reset --hard HEAD^
+'
+rm -f .gitignore
+
if test "$(git config --bool core.filemode)" = false
then
say 'skipping filemode tests (filesystem does not properly support modes)'
--
1.6.3.3
^ permalink raw reply related
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Tay Ray Chuan @ 2009-10-10 16:07 UTC (permalink / raw)
To: eduard stefan; +Cc: Git Mailing List
In-Reply-To: <4AD0AE84.1070500@gmail.com>
Hi,
On Sat, Oct 10, 2009 at 11:55 PM, eduard stefan <eduard.stefan@gmail.com> wrote:
> I was just trying to point that the URL used is not relevant,
> as long as the protocol used is URL, then it crashes.
ok.
I suspect, as you do, it's got to do with remote-curl.
Could you try this command?
echo list | git remote-curl http://github.com/loudej/spark.git
On my machine, I get
@refs/heads/master HEAD
f192d3de483f2e7f38eebf84c8f1bbc8c4b5f185 refs/heads/gh-pages
2a0cd31d8706ec2d8cc5d7b49873cc24621b20af refs/heads/installers
10526926014eb2d89c2b449f1e29f4df7ab620bd refs/heads/master
7f36b2caf2f01566bd58f9304d6ad5c36ae280ce refs/heads/mono
80fc2424ebf082265c66bd6e0637c74744742b49 refs/heads/spark-1.1
62d62d5c183dd22cdf9491999291047add05c722 refs/heads/spike-1.1
d85abb61563e7f4f372c7e0418da0f20c49baf48 refs/tags/v1.0.39890-RC1
db9d3380c39284695added69edab46c2ddab2f48 refs/tags/v1.0.39917-RC2
70c418dd806a4eb7f32fa6fe710c9a5967ddef32 refs/tags/v1.0.39935
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: eduard stefan @ 2009-10-10 16:52 UTC (permalink / raw)
To: Tay Ray Chuan, Git Mailing List
In-Reply-To: <be6fef0d0910100907t61ea922bqf117e6c025e94ce7@mail.gmail.com>
Tay Ray Chuan wrote:
> I suspect, as you do, it's got to do with remote-curl.
>
> Could you try this command?
>
> echo list | git remote-curl http://github.com/loudej/spark.git
Inside an empty repository it crashes the same way,
without any additional information.
"git remote-curl" crashes in the same way,
but "git remote-curl --help" tries to launch the browser.
Is there any way to obtain more information from this crash?
Some debug mode?
Have a nice day,
A.
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Luke-Jr @ 2009-10-10 17:23 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Thomas Rast, Luke Dashjr, git
In-Reply-To: <200908141754.51393.luke@dashjr.org>
Just for reference, since these fixes+functions have not yet been merged to
mainline Git, I have pushed a fork with them rebased on up-to-date tags:
http://repo.or.cz/w/git/ljr.git
^ permalink raw reply
* [PATCH] disallow refs containing successive slashes
From: Jens Lehmann @ 2009-10-10 17:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When creating branches using names starting with '/' or containing a '//',
a leading slash would just vanish and successive slashes were 'compressed'
into just one slash.
This behaviour comes from the refs being stored as files in subdirectories
where the filesystem compresses each '//' in a pathname to a '/' . So
disallowing refs to contain '//' fixes these problems and prohibits
branch names to start with a '/' or to contain '//'.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
I became aware of this issue while looking into problems occuring
when a user created a branch starting with a '/' in git gui (e.g.
"/foo"). Strange things happen, while git gui shows the current
branch as "/foo" under the hood a branch "foo" (without the slash)
had been created. But then you can't delete "/foo" from git gui,
because a branch of that name doesn't exist.
IMHO branch names should not be allowed to start with a '/' or
contain a '//' (branches with trailing slashes are not allowed since
commit 03feddd6). So this implies that refs should never contain a
'//' in the first place.
This behaviour has been changed the last time by commit 03feddd.
The version before that commit didn't allow '//' to be part of a
ref (but still allowed a trailing '/'). The newer version explicitly
states "/* tolerate duplicated slashes */" in the added code. But i
couldn't find any hints on the list or on the interweb *why* these
were allowed. So this patch might break something i can't see right
now, even though the test suite runs fine ...
Thoughts? Objections?
Documentation/git-check-ref-format.txt | 2 ++
refs.c | 7 +++++--
t/t1600-check-ref-format.sh | 19 +++++++++++++++++++
3 files changed, 26 insertions(+), 2 deletions(-)
create mode 100755 t/t1600-check-ref-format.sh
diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt
index 0b7982e..180ffbb 100644
--- a/Documentation/git-check-ref-format.txt
+++ b/Documentation/git-check-ref-format.txt
@@ -38,6 +38,8 @@ imposes the following rules on how references are named:
. They cannot end with a slash `/` nor a dot `.`.
+. They cannot contain two successive slashes `//`.
+
. They cannot end with the sequence `.lock`.
. They cannot contain a sequence `@{`.
diff --git a/refs.c b/refs.c
index 808f56b..cedd768 100644
--- a/refs.c
+++ b/refs.c
@@ -687,6 +687,7 @@ int for_each_rawref(each_ref_fn fn, void *cb_data)
* - it has double dots "..", or
* - it has ASCII control character, "~", "^", ":" or SP, anywhere, or
* - it ends with a "/".
+ * - it contains '//'
* - it ends with ".lock"
* - it contains a "\" (backslash)
*/
@@ -712,8 +713,10 @@ int check_ref_format(const char *ref)
level = 0;
while (1) {
- while ((ch = *cp++) == '/')
- ; /* tolerate duplicated slashes */
+ if ((ch = *cp++) == '/')
+ /* Don't tolerate successive slashes */
+ return CHECK_REF_FORMAT_ERROR;
+
if (!ch)
/* should not end with slashes */
return CHECK_REF_FORMAT_ERROR;
diff --git a/t/t1600-check-ref-format.sh b/t/t1600-check-ref-format.sh
new file mode 100755
index 0000000..05fb9f9
--- /dev/null
+++ b/t/t1600-check-ref-format.sh
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+test_description='git check-ref-format'
+
+. ./test-lib.sh
+
+test_expect_success 'refs/heads/master is ok' '
+ git check-ref-format refs/heads/master
+'
+
+test_expect_success 'no successive slashes allowed' '
+ test_must_fail git check-ref-format a//b
+'
+
+test_expect_success 'no trailing slashes allowed' '
+ test_must_fail git check-ref-format a/b/
+'
+
+test_done
--
1.6.5.rc2.205.g1185a
^ permalink raw reply related
* Re: [PATCH] Fix MSVC build on cygwin
From: Ramsay Jones @ 2009-10-09 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: mstormo, GIT Mailing-list
In-Reply-To: <7v3a5t6p1f.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Thanks; that's quite a detailed description to explain why -DFOO-DBAR is
> bad when -DFOO -DBAR was wanted ;-)
Heh, yeah I usually have the opposite problem; often I can't spare any
words past the one-line summary...
I suspect the unusual verbosity won't last... ;-)
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH] Fix the exit code of MSVC build scripts on cygwin
From: Ramsay Jones @ 2009-10-09 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, mstormo, GIT Mailing-list
In-Reply-To: <7vy6nl5ag0.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>>> -exit system(@args);
>>> +system(@args) == 0
>>> + or exit 1;
>>> +exit 0;
>> exit(system(@args) != 0);
>>
>> Yours looks a little verbose...
>
> Thanks, will queue with a fixup.
>
Thanks! (Alex and Junio)
I had this as my penultimate version, so I'm happy.
[I changed it to be more explicit about the actual exit values
returned by the script. (and thus more verbose :) ]
ATB,
Ramsay Jones
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Jakub Narebski @ 2009-10-10 18:45 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git, Johannes Schindelin
In-Reply-To: <76c5b8580910091532yd6c6fc4ib942a29c827f3a6c@mail.gmail.com>
On Sat, 10 Oct 2009, Eugene Sajine wrote:
> >
> > RTFM (in this case gitweb/README). gitweb.owner and gitweb.description
> > configuration variables in per-repository config.
>
> Ok, my bad, didn't get there;) It is good to know there are places
> where to keep the info. But it is not the point. The point is to
> integrate gitweb with bare repo creation more than it is right now by
> providing keys which will help filling out this info at the bare repo
> creation stage.
>
> shortly i'm talking about command like this (the key names are for sample only):
>
> $ git clone --bare repo repo.git -desc "description" -gwowner
> "gitwebowner@server.com" -cloneurl "git://host/repo.git"
>
> seems to me quite comfy, and no headache...
The project description, project owner and (clone) url are used by
gitweb only, so I don't see why git-clone has to feature-creep to
set them.
[cut off part about using XML for all of gitweb config: description,
owner, cloneurl]
> > %
> > "To be fair, there are uses for XML. On Halloween, for example."
> >
> > - Johannes Schindelin, on git@vger.kernel.org
> > %
>
> yeah, to show kids xml print outs as an answer to "trick or treat!".
> Can save on candies;)
Err, I think Dscho meant here that XML is so *scary*... Isn't it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] disallow refs containing successive slashes
From: Junio C Hamano @ 2009-10-10 21:50 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4AD0C93C.6050306@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> When creating branches using names starting with '/' or containing a '//',
> a leading slash would just vanish and successive slashes were 'compressed'
> into just one slash.
Hmm. We already do that without your patch.
$ git branch /foo//bar
$ git for-each-ref --format='%(refname)'
refs/heads/foo/bar
refs/heads/master
$ git branch -d /foo//bar
Deleted branch /foo//bar (was deadbeef)
$ git for-each-ref --format='%(refname)'
refs/heads/master
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> I became aware of this issue while looking into problems occuring
> when a user created a branch starting with a '/' in git gui (e.g.
> "/foo"). Strange things happen, while git gui shows the current
> branch as "/foo" under the hood a branch "foo" (without the slash)
> had been created. But then you can't delete "/foo" from git gui,
> because a branch of that name doesn't exist.
Perhaps an interface to give a cleaned-up version, e.g.
$ git check-ref-format --print refs/heads//foo/bar
refs/heads/foo/bar
is what you want in order to fix git-gui? I dunno.
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Tay Ray Chuan @ 2009-10-10 22:54 UTC (permalink / raw)
To: eduard stefan; +Cc: Git Mailing List, msysgit
In-Reply-To: <4AD0BBCB.8000306@gmail.com>
Hi,
On Sun, Oct 11, 2009 at 12:52 AM, eduard stefan <eduard.stefan@gmail.com> wrote:
> Tay Ray Chuan wrote:
>> I suspect, as you do, it's got to do with remote-curl.
>>
>> Could you try this command?
>>
>> echo list | git remote-curl http://github.com/loudej/spark.git
>
> Inside an empty repository it crashes the same way,
> without any additional information.
> "git remote-curl" crashes in the same way,
> but "git remote-curl --help" tries to launch the browser.
just to check, running
echo list | git remote-curl http://github.com/loudej/spark.git
and
git clone http://github.com/loudej/spark.git
both gives the same error message:
An unhandled win32 exception occurred in git-remote-curl.exe [5820].
Just-In-Time debugging this exception failed with the following
error: No installed debugger has Just-In-Time debugging enabled. In
Visual Studio, Just-In-Time debugging can be enabled from
Tools/Options/Debugging/Just-In-Time.
Check the documentation index for 'Just-in-time debugging, errors'
for more information.
in a dialog?
> Is there any way to obtain more information from this crash?
> Some debug mode?
I'm assuming you're using the Microsoft Visual Studio development
tools to compile git from the source. I'm cc'ing this to the msysgit
mailing list, perhaps someone familiar with them can advise you
further.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-11 1:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Johannes Schindelin
In-Reply-To: <200910102045.13374.jnareb@gmail.com>
>
> The project description, project owner and (clone) url are used by
> gitweb only, so I don't see why git-clone has to feature-creep to
> set them.
>
Well my logic is simple. Gitweb is a part of git bundle. If you don't
want to use gitweb you're free to use git clone as you want. I don't
see why not to provide some usability features to it. For me it is
quite obvious that it will be more comfortable to setup gitweb if this
would be in place. Instead of putting info in few different places
manually, why not to give people a possibilty to do that using one
command?
This is usability feature, but i feel that for me as a person who will
support big ceantral bare repo hosting server, this would save huge
time and efforts...
Thanks,
Eugene
^ permalink raw reply
* Re: combine git repo historically
From: Christian Couder @ 2009-10-11 2:36 UTC (permalink / raw)
To: bill lam; +Cc: Johannes Sixt, git, Christian Couder
In-Reply-To: <20091010140358.GA3924@debian.b2j>
On Saturday 10 October 2009, bill lam wrote:
> On Fri, 09 Oct 2009, Johannes Sixt wrote:
> > bill lam schrieb:
> > > I have two git repos, no branches.
> > >
> > > repo 1.
> > > emptyrootcommit -- A ... M
> > >
> > > repo 2.
> > > emptyrootcommit -- N ... Z
> > >
> > > N was evolved from M but the time gap is large, how can I combine
> > > them into one repo
> > >
> > > emptyrootcommit -- A ... M -- N ... Z
> > >
> > > so that snapshots N .. Z will not be changed.
> >
> > $ echo $(git rev-parse N) $(git rev-parse M) >> .git/info/grafts
> > $ git filter-branch --tag-name-filter cat -- --all --not M
> >
> > i.e. you graft the older history right before the younger history, then
> > you use git filter-branch to rewrite the parentship of the younger
> > commits.
>
> Thanks, graft is new to me. I tested it works but it needs first issue
> git fetch /path/to/repo1
> within repo2 to fetch tip M from repo1 into repo2, is it correct?
>
> If I also want to fetch also all objects from repo1, what will the
> command to do it.
Maybe you should do something like:
$ git remote add repo1 /path/to/repo1
$ git fetch repo1
The fetch command should output something like:
remote: Counting objects: 423, done.
remote: Compressing objects: 100% (149/149), done.
remote: Total 363 (delta 276), reused 298 (delta 213)
Receiving objects: 100% (363/363), 136.65 KiB, done.
Resolving deltas: 100% (276/276), completed with 29 local objects.
From /path/to/repo1
* [new branch] branch1 -> repo1/branch1
* [new branch] branch2 -> repo1/branch2
So the branches in repo1 will be available in repo2 as remote/repo1/branch1,
remote/repo1/branch2, ...
> Christian Couder also mentioned the git-replace command, how to stitch
> with it?
First you need to create a commit that will replace commit N, let's call it
N' and after that you can use "git replace N N'". So the complex part is to
create N'.
You want N' to have the same content as N but to have M as parent. So you
could do something like the following:
(We suppose that commits A to M are in branch1 and that you are in the root
directory of your repo2 working directory.)
$ git checkout -b repo1-branch1 remote/repo1/branch1
$ git checkout N -- .
$ export GIT_AUTHOR_NAME=<author name of commit N>
$ export GIT_AUTHOR_EMAIL=<author email of commit N>
$ export GIT_AUTHOR_DATE=<date of commit N>
$ git commit -a
And then use the commit message from commit N, and maybe also say in the
commit message that it is replacement commit made to link repo1 with repo2
or something like that.
At this step you have created N' and you should make sure that it is exactly
what you want. It should point to the same tree as N, it should have M as
parent, ...
If everything is ok then you can use:
$ git replace N HEAD
And you should be done.
Regards,
Christian.
^ permalink raw reply
* meaning of HEAD in context of filter-branch
From: bill lam @ 2009-10-11 2:43 UTC (permalink / raw)
To: git
I tried to process some files that changed between each commit using
the command
git filter-branch --tree-filter 'git diff --name-only HEAD^.. | foo
however it seems that HEAD is fixed to mean the HEAD of the current
tip before starting git-filter-branch, by trying like this
$ git rev-list -1 HEAD^
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
git filter-branch --tree-filter 'git rev-list -1 HEAD^ >>/tmp/sha' -- --all
$ cat /tmp/sha
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
2bf95faed2d51c338ea6fa93e7bb6cc9c1bc759b
how to get the HEAD during filter-branch or other workaround?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: combine git repo historically
From: bill lam @ 2009-10-11 4:06 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Sixt, git
In-Reply-To: <200910110436.52653.chriscool@tuxfamily.org>
On Sun, 11 Oct 2009, Christian Couder wrote:
> $ git checkout -b repo1-branch1 remote/repo1/branch1
> $ git checkout N -- .
> ...
> If everything is ok then you can use:
>
> $ git replace N HEAD
Thanks for detail instruction, I tested it ok except that when trying
to checkout it reported an error
$ git checkout -b repo1-branch1 remote/oldjproject/master
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'remote/oldjproject/master' which can not
be resolved as commit?
but it ran ok by omitting that 'remote/'
$ git checkout -b repo1-branch1 oldjproject/master
Does it need to purge the file system tree before
git checkout N -- .
so that there will be no artifact leaved by M?
I found that it is necessary to do a
git reset --hard (original HEAD)
to complete the story. Is it correct?
git version 1.6.5.rc3.35.g3340
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: git-svn very slow on fetch (shared git-svn repo)
From: Eric Wong @ 2009-10-11 7:01 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <4AD04F95.7050603@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Here is the problem.
>
> Doing a:
>
> $ git svn fetch
>
> Takes age to update the repository. The long story is that I'm trying to
> have shared git-svn repositories.
>
> I'm cloning the repository on a server using a standard "git svn clone".
> I then let users cloning this repository using the procedure described
> in git-svn help. Copy/paste here:
>
> <<
> # Do the initial import on a server
> ssh server "cd /pub && git svn clone
> http://svn.example.com/project
> # Clone locally - make sure the refs/remotes/ space matches the
> server
> mkdir project
> cd project
> git init
> git remote add origin server:/pub/project
> git config --add remote.origin.fetch
> '+refs/remotes/*:refs/remotes/*'
> git fetch
> # Create a local branch from one of the branches just fetched
> git checkout -b master FETCH_HEAD
> # Initialize 'git svn' locally (be sure to use the same URL and
> -T/-b/-t options as were used on server)
> git svn init http://svn.example.com/project
> # Pull the latest changes from Subversion
> git svn rebase
> >>
>
> If you do a "git svn fetch" (to get new branches) it takes age if you
> have imported branches that are not used since a long time.
>
> I've traced this down to the Perl fetch_all procedure. It seems that the
> fetch is looking at the older version in all branches and then read the
> remote repository starting from this revision. As some branches are
> unused since a very long it it re-read most of the history. In my
> example it start at rev 8200 whereas the last revision on trunk is
> 150000 (I put trace in git-svn Perl script).
>
> I have observed that this happen only the first time.
>
> This can be confirmed by the fact that if you break git-svn fetch
> process and restart it it will start to a later revision. So it seems
> that git-svn is keeping some kind of data about what has already been
> fetched but those data are not properly copied by the procedure above.
>
> Is there a workaround that? Where are those data stored?
Hi Pascal,
For globs (branches and tags) the $GIT_DIR/svn/.metadata
config file, under the svn-remote.svn.{branches,tags}-maxRev keys.
For explicitly specified refs (e.g. "trunk"), then it's in the last
record of the corresponding rev_map (e.g.
$GIT_DIR/svn/trunk/.rev_map.$UUID) as a 4-byte revision number + 20
bytes of zeroes.
--
Eric Wong
^ permalink raw reply
* Re: git svn with non-standard svn layout
From: Eric Wong @ 2009-10-11 7:09 UTC (permalink / raw)
To: Fabian Molder; +Cc: git
In-Reply-To: <loom.20091010T001433-536@post.gmane.org>
Fabian Molder <fm122@arcor.de> wrote:
> Hello,
>
> - want to use git inside an huge SVN project
> --> so git-svn could do the job ..
>
>
> - I struggle with two things:
> A) - the SVN project has an non-standard layout
> B) - want to have (several) git's for just the (few) peaces I work on
>
> for A)
> ======
> - svn layout looks like this (simplified):
> - trunk (not really used, all interesting work in branches)
> - branches
> - r1.2
> - development
> - integration
> - r1.3
> - development
> - integration
> ...
>
> - inside development and integration is:
> - xapplication1
> - xapplication2
> - xapplication3
> ...
> - aa
> -bb
> -cc
> - zapplication1
> - zapplication2
> - zapplication3
> ...
>
> - I created an simplified svn test (from scratch; import/repo/workdir)
> via this bash-script: http://pastebin.ca/1608231
>
> for B)
> ======
> - the svn repo is very huge, but I'm only interested in these dirs:
> xapplication2/
> aa/bb/cc/zapplication1
> - my objectives:
> - have several local git's, just the ones I need:
> --> xapplication2/.git
> --> aa/bb/cc/zapplication1/.git
Hi Fabian,
Since you don't want to track the entire repo and these seem like
unrelated (history-wise) trees, you probably want the simplest cases:
git svn clone svn://example.com/path/to/xapplication2
git svn clone svn://example.com/path/to/aa/bb/cc/xapplication1
These commands are like doing the following with plain old svn:
svn co svn://example.com/path/to/xapplication2
svn co svn://example.com/path/to/aa/bb/cc/xapplication1
> I tried to use "git config svn-remote.svn.branches" to do this,
> please see in function "do_git_svn" in bash-script - but no success
svn-remote.svn.branches and tags are really only for repos with
standard layouts.
--
Eric Wong
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.5
From: Junio C Hamano @ 2009-10-11 8:40 UTC (permalink / raw)
To: git
The latest feature release GIT 1.6.5 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5-1.fc9.$arch.rpm (RPM)
This cycle took a bit longer than I hoped, but here it is. We already
have some new features cooking in 'next', and I expect we may be able to
have 1.6.6 by the end of the year.
Enjoy.
----------------------------------------------------------------
GIT v1.6.5 Release Notes
========================
In git 1.7.0, which was planned to be the release after 1.6.5, "git
push" into a branch that is currently checked out will be refused by
default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyCurrentBranch in the receiving
repository.
Also, "git push $there :$killed" to delete the branch $killed in a remote
repository $there, when $killed branch is the current branch pointed at by
its HEAD, will be refused by default.
You can choose what should happen upon such a push by setting the
configuration variable receive.denyDeleteCurrent in the receiving
repository.
To ease the transition plan, the receiving repository of such a
push running this release will issue a big warning when the
configuration variable is missing. Please refer to:
http://git.or.cz/gitwiki/GitFaq#non-bare
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
for more details on the reason why this change is needed and the
transition plan.
Updates since v1.6.4
--------------------
(subsystems)
* various updates to gitk, git-svn and gitweb.
(portability)
* more improvements on mingw port.
* mingw will also give FRSX as the default value for the LESS
environment variable when the user does not have one.
* initial support to compile git on Windows with MSVC.
(performance)
* On major platforms, the system can be compiled to use with Linus's
block-sha1 implementation of the SHA-1 hash algorithm, which
outperforms the default fallback implementation we borrowed from
Mozilla.
* Unnecessary inefficiency in deepening of a shallow repository has
been removed.
* "git clone" does not grab objects that it does not need (i.e.
referenced only from refs outside refs/heads and refs/tags
hierarchy) anymore.
* The "git" main binary used to link with libcurl, which then dragged
in a large number of external libraries. When using basic plumbing
commands in scripts, this unnecessarily slowed things down. We now
implement http/https/ftp transfer as a separate executable as we
used to.
* "git clone" run locally hardlinks or copies the files in .git/ to
newly created repository. It used to give new mtime to copied files,
but this delayed garbage collection to trigger unnecessarily in the
cloned repository. We now preserve mtime for these files to avoid
this issue.
(usability, bells and whistles)
* Human writable date format to various options, e.g. --since=yesterday,
master@{2000.09.17}, are taught to infer some omitted input properly.
* A few programs gave verbose "advice" messages to help uninitiated
people when issuing error messages. An infrastructure to allow
users to squelch them has been introduced, and a few such messages
can be silenced now.
* refs/replace/ hierarchy is designed to be usable as a replacement
of the "grafts" mechanism, with the added advantage that it can be
transferred across repositories.
* "git am" learned to optionally ignore whitespace differences.
* "git am" handles input e-mail files that has CRLF line endings sensibly.
* "git am" learned "--scissors" option to allow you to discard early part
of an incoming e-mail.
* "git archive -o output.zip" works without being told what format to
use with an explicit "--format=zip".option.
* "git checkout", "git reset" and "git stash" learned to pick and
choose to use selected changes you made, similar to "git add -p".
* "git clone" learned a "-b" option to pick a HEAD to check out
different from the remote's default branch.
* "git clone" learned --recursive option.
* "git clone" from a local repository on a different filesystem used to
copy individual object files without preserving the old timestamp, giving
them extra lifetime in the new repository until they gc'ed.
* "git commit --dry-run $args" is a new recommended way to ask "what would
happen if I try to commit with these arguments."
* "git commit --dry-run" and "git status" shows conflicted paths in a
separate section to make them easier to spot during a merge.
* "git cvsimport" now supports password-protected pserver access even
when the password is not taken from ~/.cvspass file.
* "git fast-export" learned --no-data option that can be useful when
reordering commits and trees without touching the contents of
blobs.
* "git fast-import" has a pair of new front-end in contrib/ area.
* "git init" learned to mkdir/chdir into a directory when given an
extra argument (i.e. "git init this").
* "git instaweb" optionally can use mongoose as the web server.
* "git log --decorate" can optionally be told with --decorate=full to
give the reference name in full.
* "git merge" issued an unnecessarily scary message when it detected
that the merge may have to touch the path that the user has local
uncommitted changes to. The message has been reworded to make it
clear that the command aborted, without doing any harm.
* "git push" can be told to be --quiet.
* "git push" pays attention to url.$base.pushInsteadOf and uses a URL
that is derived from the URL used for fetching.
* informational output from "git reset" that lists the locally modified
paths is made consistent with that of "git checkout $another_branch".
* "git submodule" learned to give submodule name to scripts run with
"foreach" subcommand.
* various subcommands to "git submodule" learned --recursive option.
* "git submodule summary" learned --files option to compare the work
tree vs the commit bound at submodule path, instead of comparing
the index.
* "git upload-pack", which is the server side support for "git clone" and
"git fetch", can call a new post-upload-pack hook for statistics purposes.
(developers)
* With GIT_TEST_OPTS="--root=/p/a/t/h", tests can be run outside the
source directory; using tmpfs may give faster turnaround.
* With NO_PERL_MAKEMAKER set, DESTDIR= is now honoured, so you can
build for one location, and install into another location to tar it
up.
Fixes since v1.6.4
------------------
All of the fixes in v1.6.4.X maintenance series are included in this
release, unless otherwise noted.
^ permalink raw reply
* Re: combine git repo historically
From: Jakub Narebski @ 2009-10-11 8:48 UTC (permalink / raw)
To: Christian Couder; +Cc: bill lam, Johannes Sixt, git, Christian Couder
In-Reply-To: <200910110436.52653.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> On Saturday 10 October 2009, bill lam wrote:
> > Christian Couder also mentioned the git-replace command, how to stitch
> > with it?
>
> First you need to create a commit that will replace commit N, let's call it
> N' and after that you can use "git replace N N'". So the complex part is to
> create N'.
>
> You want N' to have the same content as N but to have M as parent. So you
> could do something like the following:
>
> (We suppose that commits A to M are in branch1 and that you are in the root
> directory of your repo2 working directory.)
>
> $ git checkout -b repo1-branch1 remote/repo1/branch1
> $ git checkout N -- .
> $ export GIT_AUTHOR_NAME=<author name of commit N>
> $ export GIT_AUTHOR_EMAIL=<author email of commit N>
> $ export GIT_AUTHOR_DATE=<date of commit N>
> $ git commit -a
>
> And then use the commit message from commit N, and maybe also say in the
> commit message that it is replacement commit made to link repo1 with repo2
> or something like that.
I think simpler solution would be to use plumbing for that. First
save commit to be replaced in a (text) file:
$ git cat-file commit N > COMMIT_N
If you want to edit only commit message and perhaps parentage (like I
think in this case), you need to simply edit COMMIT_N file, and modify
(or add) 'parent' header(s), which is between 'tree' and 'author'
header.
Then put modified commit in repository object database
$ git hash-object -t commit -w COMMIT_N
> At this step you have created N' and you should make sure that it is exactly
> what you want. It should point to the same tree as N, it should have M as
> parent, ...
>
> If everything is ok then you can use:
>
> $ git replace N HEAD
And then do
$ git replace N NEW_N
where N is _SHA-1_ of original comit ("git rev-parse --verify N^0"),
and NEW_N is SHA-1 of replacement commit, as written by git-hash-object.
> And you should be done.
But I haven't tested this. YMMV.
See also my answer here:
http://stackoverflow.com/questions/1220557/how-do-i-prepend-history-to-a-git-repo/1547490#1547490
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-svn very slow on fetch (shared git-svn repo)
From: Pascal Obry @ 2009-10-11 9:00 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20091011070136.GB16264@dcvr.yhbt.net>
Hi Eric,
> For globs (branches and tags) the $GIT_DIR/svn/.metadata
> config file, under the svn-remote.svn.{branches,tags}-maxRev keys.
Right. I found out that copying the .metadata solve this problem.
> For explicitly specified refs (e.g. "trunk"), then it's in the last
> record of the corresponding rev_map (e.g.
> $GIT_DIR/svn/trunk/.rev_map.$UUID) as a 4-byte revision number + 20
> bytes of zeroes.
Seems like we do not need to copy this one as it is reconstructed by a
simple rebase on the trunk branch. This is quite fast as reconstructed
from the embedded git-svn-id if I'm not mistaken.
So you confirm that copying the .metadata is the solution?
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: git-svn very slow on fetch (shared git-svn repo)
From: Eric Wong @ 2009-10-11 9:03 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <4AD19E9F.8010302@obry.net>
Pascal Obry <pascal@obry.net> wrote:
> Hi Eric,
>
>> For globs (branches and tags) the $GIT_DIR/svn/.metadata
>> config file, under the svn-remote.svn.{branches,tags}-maxRev keys.
>
> Right. I found out that copying the .metadata solve this problem.
>
>> For explicitly specified refs (e.g. "trunk"), then it's in the last
>> record of the corresponding rev_map (e.g.
>> $GIT_DIR/svn/trunk/.rev_map.$UUID) as a 4-byte revision number + 20
>> bytes of zeroes.
>
> Seems like we do not need to copy this one as it is reconstructed by a
> simple rebase on the trunk branch. This is quite fast as reconstructed
> from the embedded git-svn-id if I'm not mistaken.
>
> So you confirm that copying the .metadata is the solution?
Yes, copying .metadata should be enough. The .rev_map rebuild should
be fast.
--
Eric Wong
^ permalink raw reply
* Re: combine git repo historically
From: Andreas Schwab @ 2009-10-11 9:34 UTC (permalink / raw)
To: Christian Couder; +Cc: bill lam, Johannes Sixt, git, Christian Couder
In-Reply-To: <200910110436.52653.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> You want N' to have the same content as N but to have M as parent. So you
> could do something like the following:
>
> (We suppose that commits A to M are in branch1 and that you are in the root
> directory of your repo2 working directory.)
>
> $ git checkout -b repo1-branch1 remote/repo1/branch1
> $ git checkout N -- .
> $ export GIT_AUTHOR_NAME=<author name of commit N>
> $ export GIT_AUTHOR_EMAIL=<author email of commit N>
> $ export GIT_AUTHOR_DATE=<date of commit N>
> $ git commit -a
Isn't that what git cherry-pick does?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git-svn very slow on fetch (shared git-svn repo)
From: Pascal Obry @ 2009-10-11 9:37 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20091011090338.GA27480@dcvr.yhbt.net>
Eric,
> Yes, copying .metadata should be enough.
I've put this in place. Works fine.
> The .rev_map rebuild should be fast.
Yep. Thanks for your quick reply.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: meaning of HEAD in context of filter-branch
From: Andreas Schwab @ 2009-10-11 9:38 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091011024357.GA9021@debian.b2j>
bill lam <cbill.lam@gmail.com> writes:
> how to get the HEAD during filter-branch or other workaround?
>From git-filter-index(1):
Filters
The filters are applied in the order as listed below. The <command>
argument is always evaluated in the shell context using the eval
command (with the notable exception of the commit filter, for technical
reasons). Prior to that, the $GIT_COMMIT environment variable will be
^^^^^^^^^^^
set to contain the id of the commit being rewritten.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: combine git repo historically
From: Christian Couder @ 2009-10-11 10:11 UTC (permalink / raw)
To: bill lam; +Cc: Johannes Sixt, git
In-Reply-To: <20091011040659.GB9021@debian.b2j>
On Sunday 11 October 2009, bill lam wrote:
> On Sun, 11 Oct 2009, Christian Couder wrote:
> > $ git checkout -b repo1-branch1 remote/repo1/branch1
> > $ git checkout N -- .
> > ...
> > If everything is ok then you can use:
> >
> > $ git replace N HEAD
>
> Thanks for detail instruction, I tested it ok except that when trying
> to checkout it reported an error
>
> $ git checkout -b repo1-branch1 remote/oldjproject/master
> fatal: git checkout: updating paths is incompatible with switching
> branches. Did you intend to checkout 'remote/oldjproject/master' which
> can not be resolved as commit?
>
> but it ran ok by omitting that 'remote/'
> $ git checkout -b repo1-branch1 oldjproject/master
>
> Does it need to purge the file system tree before
> git checkout N -- .
>
> so that there will be no artifact leaved by M?
Yeah, perhaps, I forgot that there could be some files added and other files
removed between M and N.
If you remove everything (except the .git directory of course), then doing:
$ git checkout N -- .
$ git add .
$ export GIT_AUTHOR_NAME=<author name of commit N>
$ export GIT_AUTHOR_EMAIL=<author email of commit N>
$ export GIT_AUTHOR_DATE=<date of commit N>
$ git commit
should do the trick if I am not missing something which may very well be the
case.
So perhaps it is easier to use Jakub's suggestion instead.
> I found that it is necessary to do a
> git reset --hard (original HEAD)
>
> to complete the story. Is it correct?
Yes, you should go back to your orginal branch at the end.
Regards,
Christian.
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Jakub Narebski @ 2009-10-11 10:39 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910101845h43a607f0sd4184da302a19963@mail.gmail.com>
On Sun, 11 Oct 2009, Eugene Sajine wrote:
> >
> > The project description, project owner and (clone) url are used by
> > gitweb only, so I don't see why git-clone has to feature-creep to
> > set them.
>
> Well my logic is simple. Gitweb is a part of git bundle. If you don't
> want to use gitweb you're free to use git clone as you want. I don't
> see why not to provide some usability features to it. For me it is
> quite obvious that it will be more comfortable to setup gitweb if this
> would be in place. Instead of putting info in few different places
> manually, why not to give people a possibilty to do that using one
> command?
>
> This is usability feature, but i feel that for me as a person who will
> support big ceantral bare repo hosting server, this would save huge
> time and efforts...
And this would be best left for a custom script creating repositories
and their git hosting related configuration. Such script of necessity
would have to be site-specific, or at least contain site-specific
configuration, like:
* whether to use gitweb.owner or filesystem uid + GECOS is enough
* whether to use gitweb.description or description file
* whether to use gitweb.url, cloneurl file, or let gitweb autogenerate
clone / fetch URL from base URL
* gitosis / gitlite configuration, if needed, or setup of public keys
for SSH authentication
* project README.html file, if used
etc.
git-clone is not a dumping ground (also, code speak louder than words).
I even think it might be mistake to have default 'description' file in
templates...
--
Jakub Narebski
Poland
^ 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