* git svn woes
From: Yang Zhang @ 2008-11-05 18:52 UTC (permalink / raw)
To: git
For some reason, I'm getting this error when trying to git svn rebase
things from an svn repository to a git repository:
error: patch failed: myfile:1
error: myfile: patch does not apply
I have a simple bash script (and transcript of its output) demonstrating
exactly what I mean:
http://assorted.svn.sourceforge.net/viewvc/assorted/sandbox/trunk/src/git/gitsvn.bash?revision=1056&view=markup
Any hints? Thanks in advance!
--
Yang Zhang
http://www.mit.edu/~y_z/
^ permalink raw reply
* Re: GIT and SCC
From: Shawn O. Pearce @ 2008-11-05 18:25 UTC (permalink / raw)
To: Martin Terreni; +Cc: git
In-Reply-To: <1225909527.8578.10.camel@terrenisrv1.terrenis.net>
Martin Terreni <martin@terrenis.net> wrote:
> Does Git support SCC in any way?
What is SCC?
Google defines it as the Seminole Community College Campus Web Site
(www.scc-fl.edu). As far as I know, we do not send them money.
--
Shawn.
^ permalink raw reply
* GIT and SCC
From: Martin Terreni @ 2008-11-05 18:25 UTC (permalink / raw)
To: git
Does Git support SCC in any way?
Regards,
Martin Terreni
^ permalink raw reply
* Re: [RFC] Referring to a submodule state recorded in a supermodule from within the submodule
From: Johan Herland @ 2008-11-05 18:09 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vhc6mkqxb.fsf@gitster.siamese.dyndns.org>
On Wednesday 05 November 2008, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > I have a stand-alone project, "foo", that I work on myself. The
> > "foo" project is included as a submodule in two other projects,
> > "bar" and "baz", that I don't have any direct affiliation with.
> >
> > Semi-regularly, I like to keep tabs on bar and baz, to see what
> > versions of foo they are using, what changes they have made to foo,
> > and if there are things I could pick up from them, or maybe even
> > things they could learn from eachother.
> >
> > Doing this currently is quite tedious:
> > 1. Clone/Fetch bar and initialize/update its foo submodule
> > 2. Clone/Fetch baz and initialize/update its foo submodule
>
> If I am reading you right and you are only interested in the part
> "foo" in these projects, there is something wrong with the setup of
> "bar" and "baz".
>
> The submodule mechanism is designed to bind an independent project on
> its own as a subdirectory of another project. It seems to me that
> the problem is that "bar" and "baz" projects do not give direct
> access to clone "foo" part of them for you or other people.
No, they do. I can clone foo directly from bar/baz's server. The problem
is that I cannot quickly get at which revision of foo is used by
bar/baz without tedious cloning and interacting with the superrepos.
I basically want to quickly answer questions like "What are the
differences between bar's foo and baz's foo (and my own foo)?"
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Suraj N. Kurapati @ 2008-11-05 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <200811042215.31147.sunaku@gmail.com>
Allows the user to answer 'Stage this hunk' questions with a
single keypress, just like in Darcs. Previously, the user was
forced to press the Return key after every choice they made.
This quickly becomes tiring, burdensome work for the fingers.
Signed-off-by: Suraj N. Kurapati <sunaku@gmail.com>
---
git-add--interactive.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index b0223c3..b71905e 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -877,6 +877,8 @@ sub patch_update_file {
$num = scalar @hunk;
$ix = 0;
+ require Term::ReadKey;
+ Term::ReadKey::ReadMode('cbreak');
while (1) {
my ($prev, $next, $other, $undecided, $i);
$other = '';
@@ -920,7 +922,7 @@ sub patch_update_file {
print;
}
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
- my $line = <STDIN>;
+ my $line = Term::ReadKey::ReadKey(0);
if ($line) {
if ($line =~ /^y/i) {
$hunk[$ix]{USE} = 1;
@@ -998,6 +1000,7 @@ sub patch_update_file {
}
}
}
+ Term::ReadKey::ReadMode('restore');
my $n_lofs = 0;
my @result = ();
--
1.6.0.3
\0
^ permalink raw reply related
* Re: [PATCH 1/3 v2] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-05 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20081104183506.bb9af13a.chriscool@tuxfamily.org>
Le mardi 4 novembre 2008, Christian Couder a écrit :
> This subcommand should be used when you have a branch or a part of a
> branch that isn't easily bisectable because of a bug that has been
> fixed latter.
>
> We suppose that a bug as been introduced at some point, say A, and
> that it has been fixed latter at another point, say B, but that
> between these points the code is not easily testable because of the
> bug, so it's not easy to bisect between these points.
>
> In this case you can create a branch starting at the parent of A, say
> O, that has a fixed history. In this fixed history for example, there
> could be first a commit C that is the result of squashing A and B
> together and then all the commits between A and B that have been
> cherry picked.
>
> For example, let's say the commits between A and B are X1, X2, ... Xn
> and they have been cherry picked after C as Y1, Y2, ... Yn:
>
> C--Y1--Y2--...--Yn
> /
> ...--O--A--X1--X2--...--Xn--B--...
>
> By design, the last cherry picked commit (Yn) should point to the same
> tree as commit B.
>
> So in this case you can say:
>
> $ git bisect replace B Yn
>
> and commit B will be tagged with a special name like:
> "bisect-replace-with-Yn"
>
> (A branch that points to commit Yn will also be created with a name
> like: "bisect-replace-B")
It occured to me that perhaps only the branch is needed and we can get rid
of the tag. This should remove the need to check that the branch still
exists when we are creating grafts.
I will see what I an come up with.
Regards,
Christian.
^ permalink raw reply
* Re: git-svn: Having a "rare" structure
From: Marc Fargas @ 2008-11-05 17:46 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4911DADA.4010902@drmicha.warpmail.net>
Hi,
On Wed, Nov 5, 2008 at 6:41 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> You can delete the bogus branches (using git branch -rd or git
> update-ref -d), but I'm not sure if you can reset git svn's state info:
> You may try messing with .git/svn/.metadata.
I'll try it, if not I'll recreate the repo from scratch ;)) Thanks for the tips!
> I tried the approach I suggested in the last post for real, and things
> seem to work. Only gotcha is I don't know whether django folks will
> stick with putting branches under {releases,features}, that would create
> problems
They say they won't put more folders in branches/ ;))
Thanks again for the tips, that will solve lots of trouble. Thanks!
Cheers.
Marc
--
http://www.marcfargas.com - will be finished someday.
^ permalink raw reply
* Re: [RFC] Referring to a submodule state recorded in a supermodule from within the submodule
From: Junio C Hamano @ 2008-11-05 17:45 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200811051824.28374.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> I have a stand-alone project, "foo", that I work on myself. The "foo"
> project is included as a submodule in two other projects, "bar"
> and "baz", that I don't have any direct affiliation with.
>
> Semi-regularly, I like to keep tabs on bar and baz, to see what versions
> of foo they are using, what changes they have made to foo, and if there
> are things I could pick up from them, or maybe even things they could
> learn from eachother.
>
> Doing this currently is quite tedious:
> 1. Clone/Fetch bar and initialize/update its foo submodule
> 2. Clone/Fetch baz and initialize/update its foo submodule
If I am reading you right and you are only interested in the part "foo" in
these projects, there is something wrong with the setup of "bar" and "baz".
The submodule mechanism is designed to bind an independent project on its
own as a subdirectory of another project. It seems to me that the problem
is that "bar" and "baz" projects do not give direct access to clone "foo"
part of them for you or other people.
^ permalink raw reply
* Re: git-svn: Having a "rare" structure
From: Michael J Gruber @ 2008-11-05 17:41 UTC (permalink / raw)
To: Marc Fargas; +Cc: git
In-Reply-To: <2686a05b0811050736q520f1771t6ffa2840bfb3c308@mail.gmail.com>
Marc Fargas venit, vidit, dixit 05.11.2008 16:36:
> Hi,
>
> On Wed, Nov 5, 2008 at 2:07 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> git config svn-remote.svn.branches
>> 'django/branches/features/*:refs/remotes/svn/features/*'
>>
>> git config --add svn-remote.svn.branches
>> 'django/branches/releases/*:refs/remotes/svn/releases/*'
>>
>> In fact, you should be able to use your previous branches config when
>> fetching up to r9093, then switch to the config I suggested, and the
>> fetch from r9094.
>
> I'll try it right now, I have one q... I've been fetching from svn so
> I now have "like a mess" in the branches dir (and their history) is
> there a way to make git-svn forget about everything after r9093 so I
> can do the config change and re-fetch since then? That'd be awesome.
You can delete the bogus branches (using git branch -rd or git
update-ref -d), but I'm not sure if you can reset git svn's state info:
You may try messing with .git/svn/.metadata.
I tried the approach I suggested in the last post for real, and things
seem to work. Only gotcha is I don't know whether django folks will
stick with putting branches under {releases,features}, that would create
problems.
Cheers,
Michael
^ permalink raw reply
* Re: Slow "git rev-list origin/master --not --all" or "git fetch" slow when downloading nothing
From: Linus Torvalds @ 2008-11-05 17:37 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811050138j7b8bbed1nd94a999f55e38d61@mail.gmail.com>
On Wed, 5 Nov 2008, Santi Béjar wrote:
>
> In cold cache "git rev-list origin/master --not --all" is slow
> reading many files:
Hmm. It sounds like you possibly don't have packed refs.
Have you done "git gc" on that thing lately? What does "strace" say?
Linus
^ permalink raw reply
* [RFC] Referring to a submodule state recorded in a supermodule from within the submodule
From: Johan Herland @ 2008-11-05 17:24 UTC (permalink / raw)
To: git
Hi,
I have a stand-alone project, "foo", that I work on myself. The "foo"
project is included as a submodule in two other projects, "bar"
and "baz", that I don't have any direct affiliation with.
Semi-regularly, I like to keep tabs on bar and baz, to see what versions
of foo they are using, what changes they have made to foo, and if there
are things I could pick up from them, or maybe even things they could
learn from eachother.
Doing this currently is quite tedious:
1. Clone/Fetch bar and initialize/update its foo submodule
2. Clone/Fetch baz and initialize/update its foo submodule
3. Set up remotes bar_foo and baz_foo in my main foo repo,
pointing to bar/foo and baz/foo, respectively. Fetch.
4. Create tags bar_foo_current and baz_foo_current pointing
to the foo SHA1 sum recorded in baz and baz, respectively.
5. Start comparing bar_foo_current and baz_foo_current to
eachother, and to my own master branch.
Now, bring this into a larger company setting. There are many (~100)
different foo-type projects owned by (~50) different developers. These
projects are included as submodules by several (~20) different
bar/baz-type projects. In addition, each bar/baz-type project has
multiple (~3) branches using various versions of the foo-type
submodules.
Finally, throw in questions like "What are the differences in submodule
FOO between branch X of BAR, and branch Y of BAZ?", for random values
of FOO, X, BAR, Y, and BAZ. It is apparent that the above approach just
doesn't cut it.
Ironically, these questions are fairly easily answered by our current
CVS setup (which applies the supermodule tags/branches to the entire
source tree (including submodules)):
1. cd FOO
2. cvs diff -r BAR_X -r BAZ_Y
What I'd like, is some way to refer to the state of a repo as specified
by the appropriate submodule blob in a superproject commit. Ideally
this should be done remotely as well, so that I don't have to clone the
entire superproject just to get at the appropriate submodule blob.
Crude Proposal:
Define a new "git submodule" subcommand that takes three arguments:
<superURL> <tree-ish> <submoduleName>
The command does the following steps:
1. Locate git repo at <superURL>
2. Resolve <tree-ish> to the tree object within the git repo in #1
3. Locate .gitmodules within the tree object in #2
4. Lookup <submoduleName> in .gitmodules to find its path and URL
5. Locate the submodule blob from the path in #4 within the tree from #2
6. Record the object name (SHA1) stored in the submodule blob from #4
7. Fetch the object name (#7) from the submodule repo (its URL was
found in #4) into the local git repo
8. Store a reference to the fetched object
Given the above command, the tedious steps described at the top can be
reduced to the following (which is reasonably close to the equivalent
CVS commands):
1. git submodule magic-command url/to/bar master foo
2. git submodule magic-command url/to/baz master foo
3. Start comparing the fetched refs to eachother, and
to my own master branch.
If this sounds reasonable, I'd be happy to start coding the above
proposal.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re* Slow "git rev-list origin/master --not --all" or "git fetch" slow when downloading nothing
From: Junio C Hamano @ 2008-11-05 17:32 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811050138j7b8bbed1nd94a999f55e38d61@mail.gmail.com>
"Santi Béjar" <santi@agolina.net> writes:
> In cold cache "git rev-list origin/master --not --all" is slow
> reading many files:
>
> cold cache:
> $ /usr/bin/time git rev-list origin/master --not --all
> 0.03user 0.02system 0:04.57elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
> 77848inputs+0outputs (410major+1798minor)pagefaults 0swaps
>
> hot cache:
> $ /usr/bin/time git rev-list origin/master --not --all
> 0.01user 0.00system 0:00.06elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+2207minor)pagefaults 0swaps
>
> I think that, in this particular case (when the arguments are the tips
> of some of the branches), this should not read that many files.
What kind of "many files" are you making git read? Do you have too many
unpacked refs? Too many loose objects?
> ... When nothing has changed in the remote repository (so
> refs/<remote>/* has all the remote refs) the "git fetch" could be almost
> instantaneous (even in coldcache),...
You at least need to read:
- what "--all" refs point at; to find this out, you need to read all
unpacked refs files, and one packed-refs file;
- commit objects that these refs point at; to cull refs that do not point
at committish and dereference tag objects that point at commit, you
need to read these objects (either loose objects or in packs);
- commit objects on the ancestry graph starting from the commit pointed
at by origin/master and the commits from "--all" refs, until your
traversal from origin/master hit one of the ancestors of "--all" refs.
I noticed that when you "git pack-refs" (or "git gc"), we do not remove
the leading directories of loose refs that become empty because of
pruning. This can cause many opendir() when you used to have too many
hierachy of refs even after packing them.
dir.c | 13 +++++++++----
pack-refs.c | 5 +++++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git c/dir.c w/dir.c
index 0131983..7241631 100644
--- c/dir.c
+++ w/dir.c
@@ -779,7 +779,12 @@ int is_inside_dir(const char *dir)
return get_relative_cwd(buffer, sizeof(buffer), dir) != NULL;
}
-int remove_dir_recursively(struct strbuf *path, int only_empty)
+/*
+ * option:
+ * 1: remove empty directory;
+ * 2: remove empty subdirectories, but not the directory itself
+ */
+int remove_dir_recursively(struct strbuf *path, int option)
{
DIR *dir = opendir(path->buf);
struct dirent *e;
@@ -803,9 +808,9 @@ int remove_dir_recursively(struct strbuf *path, int only_empty)
if (lstat(path->buf, &st))
; /* fall thru */
else if (S_ISDIR(st.st_mode)) {
- if (!remove_dir_recursively(path, only_empty))
+ if (!remove_dir_recursively(path, !!option))
continue; /* happy */
- } else if (!only_empty && !unlink(path->buf))
+ } else if (!option && !unlink(path->buf))
continue; /* happy, too */
/* path too long, stat fails, or non-directory still exists */
@@ -815,7 +820,7 @@ int remove_dir_recursively(struct strbuf *path, int only_empty)
closedir(dir);
strbuf_setlen(path, original_len);
- if (!ret)
+ if (!ret && option != 2)
ret = rmdir(path->buf);
return ret;
}
diff --git c/pack-refs.c w/pack-refs.c
index 2c76fb1..30fbae8 100644
--- c/pack-refs.c
+++ w/pack-refs.c
@@ -2,6 +2,7 @@
#include "refs.h"
#include "tag.h"
#include "pack-refs.h"
+#include "dir.h"
struct ref_to_prune {
struct ref_to_prune *next;
@@ -73,10 +74,14 @@ static void prune_ref(struct ref_to_prune *r)
static void prune_refs(struct ref_to_prune *r)
{
+ struct strbuf refs = STRBUF_INIT;
+
+ strbuf_addstr(&refs, git_path("refs"));
while (r) {
prune_ref(r);
r = r->next;
}
+ remove_dir_recursively(&refs, 2);
}
static struct lock_file packed;
^ permalink raw reply related
* Re: git-svn: Having a "rare" structure
From: Marc Fargas @ 2008-11-05 15:36 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49119AAD.2010803@drmicha.warpmail.net>
Hi,
On Wed, Nov 5, 2008 at 2:07 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> git config svn-remote.svn.branches
> 'django/branches/features/*:refs/remotes/svn/features/*'
>
> git config --add svn-remote.svn.branches
> 'django/branches/releases/*:refs/remotes/svn/releases/*'
>
> In fact, you should be able to use your previous branches config when
> fetching up to r9093, then switch to the config I suggested, and the
> fetch from r9094.
I'll try it right now, I have one q... I've been fetching from svn so
I now have "like a mess" in the branches dir (and their history) is
there a way to make git-svn forget about everything after r9093 so I
can do the config change and re-fetch since then? That'd be awesome.
Thanks a lot for the tip! ;)
Sincerelly,
Marc
--
http://www.marcfargas.com - will be finished someday.
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Junio C Hamano @ 2008-11-05 15:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Jeff King
In-Reply-To: <20081105104001.GA22272@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
> On Tue, Nov 04, 2008 at 11:54:26PM +0000, Junio C Hamano wrote:
>
>> Somebody already suggested this but I really think GIT: lines should be at
>> the end and use '# ' prefix instead.
>
> This will break previous editor syntax hilighting stuff even more, and
> has the drawback that you can't put shell sniplets in here. I think it's
> why GIT: was chosen. But maybe we just don't care.
Ah, please scratch that "I really think" --- my mistake.
I did not check nor realize "GIT:" is what send-email already does.
^ permalink raw reply
* Re: let git-diff allow patch to delete empty files?
From: Sam Liddicott @ 2008-11-05 14:49 UTC (permalink / raw)
To: git
In-Reply-To: <49118FEE.30408@liddicott.com>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
* Sam Liddicott wrote, On 05/11/08 12:22:
> In some cases "patch" cannot apply diff's generated using git-diff, I've
> had a "git diff" output look like this when an empty file was removed as
> the only change:
>
> ..
> However this equivalent pair works by making the file non-empty and then
> deleting it.
>
> diff -Nru 1/here 2/here
> --- 1/here 2008-11-05 09:43:55.000000000 +0000
> +++ 2/here 2008-11-05 09:43:58.000000000 +0000
> @@ -0,0 +1 @@
> +
> diff -Nru 1/here 2/here
> --- 1/here 2008-11-05 09:37:23.000000000 +0000
> +++ 2/here 1970-01-01 01:00:00.000000000 +0100
> @@ -1 +0,0 @@
> -
>
The same problem occurs with new empty files.
Attached is an awk filter which will expand out these git notes into the
2-part unified diff's.
It would be nicer if git did it natively.
Sam
[-- Attachment #2: git-new-delete-filter.awk --]
[-- Type: text/plain, Size: 1430 bytes --]
#! /usr/bin/awk -f
function do_empty() {
if (diff!="" && deleted!="" && indx!="") {
printf("Make patch give the file 1 line\n");
printf("--- %s\n",diff);
printf("+++ %s\n",diff);
printf("@@ -0,0 +1 @@\n+\n");
printf("Make patch delete the 1 line file\n");
printf("--- %s\t\n",diff);
printf("+++ /dev/null\t1970-01-01 01:00:00.000000000\n");
printf("@@ -1 +0,0 @@\n-\n");
}
if (diff!="" && created!="" && indx!="") {
printf("Make patch create the file with 1 line\n");
printf("--- %s\n",diff);
printf("+++ %s\n",diff);
printf("@@ -0,0 +1 @@\n+\n");
printf("Make patch create delete the line but keep the file\n");
printf("--- %s\n",diff);
printf("+++ %s\n",diff);
printf("@@ -1 +0,0 @@\n-\n");
}
no_empty();
}
function no_empty() {
diff="";
deleted="";
created="";
indx="";
}
{
if (in_hunk > 0) in_hunk--;
}
/^diff --git / {
do_empty();
if (! in_hunk) diff=$3;
}
/^deleted file mode / {
if (! in_hunk && diff!="") deleted=$0;
}
/^new file mode / {
if (! in_hunk && diff!="") created=$0;
}
/^index / {
if (! in_hunk && diff!="") indx=$0;
}
/^--- / {
no_empty();
}
/^@@ / {
# read the hunk size
p=index($2,",");
if (p==0) c1=1;
else c1=strtonum(substr($2, p+1));
p=index($3,",");
if (p==0) in_hunk=1;
else in_hunk=strtonum(substr($2, p+1));
if (c1 > in_hunk) in_hunk=c1;
}
{
print;
}
END {
do_empty();
}
^ permalink raw reply
* Re: git-svn: Having a "rare" structure
From: Michael J Gruber @ 2008-11-05 13:07 UTC (permalink / raw)
To: Marc Fargas; +Cc: git
In-Reply-To: <2686a05b0811050204v59edc4a3h7f9ce6c6ecd13058@mail.gmail.com>
Marc Fargas venit, vidit, dixit 05.11.2008 11:04:
> Hi all,
>
> First of all, please CC responses to me as I'm not subscribed to this list ;)
>
> On the subject, I use git-svn to for most of my stuff and also to
> "interact" with some SVN projects out there, there's one that is
> driving me mad.
>
> The Django project has a (somehow) rare SVN structure that I almost
> managet to make git-svn understand, but a recent "rarity" to the
> structure broke it again and I haven't succeeded in making git-svn
> understand it, so I'm trying to get some guidance on how to make
> git-svn understand the structure.
>
> Right know the Django SVN repo is like that:
> browse: http://code.djangoproject.com/browser/django
> svn url: http://code.djangoproject.com/svn/django
>
> trunk/
> tags/notable_moments/
> tags/releases/
> branches/*
> branches/features/
> branches/releases/
>
> Until now, the last two didn't exist and git-svn was working nicely,
> but now "features" and "releases" were created, and git-svn is taking
> them as if they were branches, while they arent (branches are in
> subdirectories of those two).
>
> My git repo was done like that until now:
>
> git svn init --prefix svn/
> http://code.djangoproject.com/svn/django -T trunk -b branches -t
> 'tags/*/*'
> git svn fetch
>
> With that, git-svn understood that tags were in the subdirectories of
> tags/{notable_moments,releases}/ but I can't do that with the branches
> as there are branches also in the top branches/ directory.
>
> I do not really care about those branches on the top directory as
> those are old, so I really only need git-svn to understand the
> {features,releases}/* thing. So:
>
> How can I do something like "-b branches/{features,releases}/*" making
> git-svn ignore the other top-level branches? Or, can I make it
> understand both, the top-level ones and the ones inside those two
> subdirectories?
You can use "-T trunk -t 'tags/*/*'" and then set up the branches config
by hand:
git config svn-remote.svn.branches
'django/branches/features/*:refs/remotes/svn/features/*'
git config --add svn-remote.svn.branches
'django/branches/releases/*:refs/remotes/svn/releases/*'
In fact, you should be able to use your previous branches config when
fetching up to r9093, then switch to the config I suggested, and the
fetch from r9094.
Cheers,
Michael
^ permalink raw reply
* Re: Repo corrupted somehow?
From: Eyvind Bernhardsen @ 2008-11-05 12:26 UTC (permalink / raw)
To: Andrew Arnott; +Cc: Daniel Barkalow, git
In-Reply-To: <alpine.LNX.1.00.0811050043030.19665@iabervon.org>
On 5. nov.. 2008, at 06.56, Daniel Barkalow wrote:
> On Tue, 4 Nov 2008, Andrew Arnott wrote:
>
>> It was the CRLF conversion. When I played around with
>> git config --global core.autocrlf true/false
>> I got the problem to eventually go away.
>>
>> Thanks for all your responses.
>
> It's still worth debugging further, because git should know that it
> wrote
> the files differently and not see that as changes. It's not too
> helpful to
> have autocrlf if it causes this problem.
I think I know what this is. If a repository contains files with
CRLFs, those files will show as modified when core.autcorlf is true
(if you commit them, the CRLFs will be converted to CRs in the
repository, so in a sense they _are_ modified). Try turning autocrlf
back on, cloning the repository, then touching all the files (to make
git check them for changes) and see if you get the same problem.
I proposed an alternative autocrlf implementation on the list a while
back: making it an attribute instead of a configuration setting and
adding a configuration setting to tell git which line ending is
preferred when the autocrlf attribute is set.
That would allow you to turn on autocrlf and let git convert all CRLFs
to CRs in a single commit, thus converting a repository with CRLFs to
one that can be used with autocrlf in a versioned way. In theory that
lets you check out new commits with EOL conversion while old commits
will be left alone (avoiding the problem you saw), but
since .gitattributes is read from the working directory and not the
tree to be checked out, it doesn't work perfectly.
I implemented the easy bit (reading autocrlf from .gitattributes), but
for various reasons the patch has just been gathering dust in my
private git.git repo. Maybe I should dust it off :)
--
Eyvind
^ permalink raw reply
* bidirectional hg <-> git syncing
From: Ondrej Certik @ 2008-11-05 12:48 UTC (permalink / raw)
To: Git Mailing List
Hi,
I wanted to share how we sync hg and git repo and I am interested if
anyone has any comments to it.
In our project [0], we used Mercurial, but recently several of the
core developers including me switched to git, but because we already
wrote docs and taught our users to use mercurial (see for example
[1]), we want to support both. So currently our main repo is still
mercurial and we automatically convert to git using
Our /home/hg/repos/sympy/.hg/hgrc contains:
[hooks]
#update the git repo
changegroup = /home/git/update-sympy.sh
where /home/git/update-sympy.sh is:
-----------
#!/bin/bash
cd /home/git/repos/sympy
sudo /bin/su git -c "../fast-export/hg-fast-export.sh -r /home/hg/repos/sympy"
cd /home/git/repos/
sudo /bin/su git -c "rm -rf sympy.git"
sudo /bin/su git -c "git clone --bare sympy/.git/ sympy.git"
sudo /bin/su git -c "echo 'main SymPy repository' > sympy.git/description"
sudo /bin/su git -c "touch sympy.git/git-daemon-export-ok"
---------
Which uses hg-fast-export to update the git repo.
Before pushing any patches in, we need to convert them to mercurial.
So if the user uses mercurial, nothing changes. If the user (like me)
uses git, I need to convert the patches to mercurial first, so that I
can push it in. So I do the following sequence, starting off my master
branch:
git checkout -b fix
# do some commits
./hgconvert
where the ./hgconvert script is:
-----
#! /bin/bash
work=`mktemp -t -d sym.XXX`
git format-patch -k -p -o $work master..HEAD
# add a new line after the subject line so that Mercurial imports it fine.
sed -i '4a\\' $work/*
cd ~/repos/sympy.hg/
hg import $work/*
rm -r $work
---------
This takes all patches commited after the master and commits them to
my hg repo at ~/repos/sympy.hg/. I'll then push them in, both our hg
and git repo updates and then I do in my local git repository:
git checkout master
git pull # this pulls the changes, essentially the same as in the
"fix" branch, only from our official git repo
git branch -D fix
This works nicely as long as I do not do any merges in my local git
repo. Is there some way to also convert the branches and merges? As I
understood it, there are tools that only convert the whole repo, but
since we already convert the whole repo from hg to git, I need to only
convert the latest commits from git back to hg.
One solution is to fully switch to git and convert to hg automatically
on our server -- and that's what we'll do soon probably. Then we'll be
able to push nonlinear history in git, but only linear in mercurial.
Thanks,
Ondrej
[0] http://code.google.com/p/sympy/
[1] http://docs.sympy.org/sympy-patches-tutorial.html
Ondrej
^ permalink raw reply
* let git-diff allow patch to delete empty files?
From: Sam Liddicott @ 2008-11-05 12:22 UTC (permalink / raw)
To: git
In some cases "patch" cannot apply diff's generated using git-diff, I've
had a "git diff" output look like this when an empty file was removed as
the only change:
diff --git a/source3/include/dcerpc.h b/source3/include/dcerpc.h
deleted file mode 100644
index e69de29..0000000
which patch rejected, saying:
patch: **** Only garbage was found in the patch input.
There is a ghastly diff notation recognized by patch, using the magic
date 1970-01-01 01:00:00.000000000 to signify deletion which git-diff
properly uses for non-empty files.
Empty files are a different matter because there is no unified diff that
can represent deletion of an empty file because patch doesn't like
unified diff's with no context.
However this equivalent pair works by making the file non-empty and then
deleting it.
diff -Nru 1/here 2/here
--- 1/here 2008-11-05 09:43:55.000000000 +0000
+++ 2/here 2008-11-05 09:43:58.000000000 +0000
@@ -0,0 +1 @@
+
diff -Nru 1/here 2/here
--- 1/here 2008-11-05 09:37:23.000000000 +0000
+++ 2/here 1970-01-01 01:00:00.000000000 +0100
@@ -1 +0,0 @@
-
In considering this filthy hack we should recognize that currently :
* patch will choke on certain "git diff" output. If patch's exit code is
checked as part of a loop of patches, then the patch procedure will
fail. This happened to me
* if delete-empty-file is one action in a larger patch file it will do
nothing - which can be worse if the "existence" of a file affects the
build system.
This filthy hack fixes both problems.
Sam
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Pierre Habouzit @ 2008-11-05 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7v1vxroxn1.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3730 bytes --]
On Tue, Nov 04, 2008 at 11:54:26PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
> > @@ -363,10 +366,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
> >
> > ($sender) = expand_aliases($sender) if defined $sender;
> >
> > +sub check_file_rev_conflict($) {
> > + my $f = shift;
> > + if ($repo->command('rev-parse', '--verify', '--quiet', $f)) {
> > + die("revision/filename conflict on `$f'");
>
> Perhaps wording this a bit more to the point? This is triggered when
> '$f' can be both a filename or a revision, so...
>
> File '$f' exists but it could also be the range of commits
> to produce patches for. Please disambiguate by...
>
> * Saying "./$f" if you mean a file; or
> * Giving -F option if you mean a range.
>
> Earlier I suggested that "origin^0" is a way for the user to disambiguate
> favouring a rev, but such a filename can exist, so we cannot blindly
> suggest to say "$f^0" here. I think adding -F (or --format-patch) option
> to send-email to explicitly disable file/directory interpretation would be
> a cleaner solution for this (and it would allow you to drive this from a
> script without worrying about what garbage files you happen to have in the
> working tree).
Okay, still having --[no-]format-patch is probably a good idea indeed
for scripts. Will do.
On Tue, Nov 04, 2008 at 11:54:39PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > + print C <<EOT;
> > +From $tpl_sender # This line is ignored.
> > +GIT: Lines beginning in "GIT: " will be removed.
> > +GIT: Consider including an overall diffstat or table of contents
> > +GIT: for the patch you are writing.
> > +GIT:
> > +GIT: Clear the body content if you don't wish to send a summary.
> > +From: $tpl_sender
> > +Subject: $tpl_subject
> > +In-Reply-To: $tpl_reply_to
> > +
>
> Somebody already suggested this but I really think GIT: lines should be at
> the end and use '# ' prefix instead.
This will break previous editor syntax hilighting stuff even more, and
has the drawback that you can't put shell sniplets in here. I think it's
why GIT: was chosen. But maybe we just don't care.
> With the ability to give --cover-letter option to underlying format-patch
> do you still need this?
>
> > + my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor") || $ENV{VISUAL} || $ENV{EDITOR} || "vi";
> > +
> > + if ($annotate) {
> > + do_edit($compose_filename, @files);
> > + } else {
> > + do_edit($compose_filename);
> > + }
>
> Don't we want to abort the whole process when the user kills the editor
> instead of normal exit (iow, do_edit() which is system() reports that the
> editor was killed)?
Probably, I kept what was done as is, but we probably want do_edit() to
die() if the user killed it.
On mer, nov 05, 2008 at 07:03:42 +0000, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> > On Tue, Nov 04, 2008 at 03:54:54PM -0800, Junio C Hamano wrote:
> Yeah, if send-email did not have --compose to begin with, we could just
> say "don't use --compose; use --cover-letter when you use send-email to
> front-end format-patch instead", but some people perhaps are used to run
> format-patch separately without --cover-letter and then create the cover
> letter from scratch with --compose (which seems a bit more work to me,
> though).
>
> So I am not opposed to a sendemail.foo configuration option.
Will do
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-svn: Having a "rare" structure
From: Marc Fargas @ 2008-11-05 10:04 UTC (permalink / raw)
To: git
Hi all,
First of all, please CC responses to me as I'm not subscribed to this list ;)
On the subject, I use git-svn to for most of my stuff and also to
"interact" with some SVN projects out there, there's one that is
driving me mad.
The Django project has a (somehow) rare SVN structure that I almost
managet to make git-svn understand, but a recent "rarity" to the
structure broke it again and I haven't succeeded in making git-svn
understand it, so I'm trying to get some guidance on how to make
git-svn understand the structure.
Right know the Django SVN repo is like that:
browse: http://code.djangoproject.com/browser/django
svn url: http://code.djangoproject.com/svn/django
trunk/
tags/notable_moments/
tags/releases/
branches/*
branches/features/
branches/releases/
Until now, the last two didn't exist and git-svn was working nicely,
but now "features" and "releases" were created, and git-svn is taking
them as if they were branches, while they arent (branches are in
subdirectories of those two).
My git repo was done like that until now:
git svn init --prefix svn/
http://code.djangoproject.com/svn/django -T trunk -b branches -t
'tags/*/*'
git svn fetch
With that, git-svn understood that tags were in the subdirectories of
tags/{notable_moments,releases}/ but I can't do that with the branches
as there are branches also in the top branches/ directory.
I do not really care about those branches on the top directory as
those are old, so I really only need git-svn to understand the
{features,releases}/* thing. So:
How can I do something like "-b branches/{features,releases}/*" making
git-svn ignore the other top-level branches? Or, can I make it
understand both, the top-level ones and the ones inside those two
subdirectories?
Note that I just gueesed the "-b branches/{features,releases}/*"
thing; I didn't try it, tryiing takes lots of time and bandwidth ;\\
Thanks for all,
Marc
--
http://www.marcfargas.com - will be finished someday.
^ permalink raw reply
* Re: git pull regression?
From: Carlos R. Mafra @ 2008-11-05 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20081105083810.GA22318@localhost.aei.mpg.de>
On Wed 5.Nov'08 at 9:38:10 +0100, Carlos R. Mafra wrote:
> On Tue 4.Nov'08 at 15:37:03 -0800, Junio C Hamano wrote:
> > "Carlos R. Mafra" <crmafra2@gmail.com> writes:
> >
> > > It looks like a regression to me. I can finish
> > > the bisection if people in the list say that
> > > I am not making a mistake somewhere :-)
> >
> > Interesting, and _sounds_ like a regression, but I do not think anybody
> > can tell if it is without looking at what .git/config and exact command
> > sequence you are using for this "git pull" and where you are starting
> > from.
Hm...that what I feared most has just happened.
I tried to bisect my problem when I realized that it wasn't
goint to take 2 hours and a lot of reboots like with the kernel :-)
And I soon realized that something was wrong when I was
running 'make install'. I had two terminals open, one with
the regular user with which I was compiling git, and the
other with the root user where I run 'make install'.
After compiling with the regular user and running
'make install' with the root user from the other terminal
the whole compilation was happening again and strangely
it was installing things in the prefix /root instead of
/usr/local
I simply don't know why this happened nor how. But
somehow my git installation was screwed.
I have just compiled the latest git and it is ok now.
I am really sorry for all the noise, but I was
sincerely fooled by the symptoms (as you can see
in the previous email).
^ permalink raw reply
* Slow "git rev-list origin/master --not --all" or "git fetch" slow when downloading nothing
From: Santi Béjar @ 2008-11-05 9:38 UTC (permalink / raw)
To: Git Mailing List
Hi *,
In cold cache "git rev-list origin/master --not --all" is slow
reading many files:
cold cache:
$ /usr/bin/time git rev-list origin/master --not --all
0.03user 0.02system 0:04.57elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
77848inputs+0outputs (410major+1798minor)pagefaults 0swaps
hot cache:
$ /usr/bin/time git rev-list origin/master --not --all
0.01user 0.00system 0:00.06elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2207minor)pagefaults 0swaps
I think that, in this particular case (when the arguments are the tips
of some of the branches), this should not read that many files.
Moreover, this is used in "git fetch" (git rev-list --quiet --objects
<list_of_remote_sha1> --not --all) to detect if all the objects are
reachable from the local repository. When nothing has changed in the
remote repository (so refs/<remote>/* has all the remote refs) the
"git fetch" could be almost instantaneous (even in coldcache), but
currently it is not because of the above.
Thanks,
Santi
^ permalink raw reply
* Re: git pull regression?
From: Carlos R. Mafra @ 2008-11-05 8:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzanoyg0.fsf@gitster.siamese.dyndns.org>
On Tue 4.Nov'08 at 15:37:03 -0800, Junio C Hamano wrote:
> "Carlos R. Mafra" <crmafra2@gmail.com> writes:
>
> > It looks like a regression to me. I can finish
> > the bisection if people in the list say that
> > I am not making a mistake somewhere :-)
>
> Interesting, and _sounds_ like a regression, but I do not think anybody
> can tell if it is without looking at what .git/config and exact command
> sequence you are using for this "git pull" and where you are starting
> from.
Ok, I am sorry for the lack of details, which I provide now.
It happened again with the git repo itself (Linus hasn't
updated his yet).
[mafra@localhost:git]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
And the commands were these (ok, I made a mistake that
I pulled without being first in the master branch,
but the problem I am describing here also happened
before, when I was already in the master branch)
[mafra@localhost:git]$ git --version
git version 1.6.0.3
[mafra@localhost:git]$ git log
[mafra@localhost:git]$ git pull
remote: Counting objects: 245, done.
remote: Compressing objects: 100% (49/49), done.
remote: Total 131 (delta 100), reused 109 (delta 82)
Receiving objects: 100% (131/131), 33.91 KiB, done.
Resolving deltas: 100% (100/100), completed with 43 local objects.
From git://git.kernel.org/pub/scm/git/git
aa17c7c..826ea6f html -> origin/html
a5a323f..16088d8 maint -> origin/maint
1655dcb..1e98488 man -> origin/man
9f8f132..5508064 master -> origin/master
58edc95..494ccbd next -> origin/next
+ fe6aa64...a5f8d19 pu -> origin/pu (forced update)
You asked me to pull without telling me which branch you
want to merge with, and 'branch..merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch..remote = <nickname>
branch..merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
[mafra@localhost:git]$ git branch
* (no branch)
master
[mafra@localhost:git]$ git checkout master
Previous HEAD position was 031e6c8... GIT 1.6.0.3
Switched to branch "master"
Your branch is behind 'origin/master' by 5 commits, and can be fast-forwarded.
[mafra@localhost:git]$ git pull
[mafra@localhost:git]$ git status
# On branch master
# Your branch is behind 'origin/master' by 5 commits, and can be fast-forwarded.
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# git-help--browse
# git-merge-stupid
# test-absolute-path
nothing added to commit but untracked files present (use "git add" to track)
[mafra@localhost:git]$ git pull
[mafra@localhost:git]$
Notice how "git pull" doesn't say "Already up-to-date" anymore.
And now 'git log' shows me the last commit being
9f8f132621faedd instead of the really last one 550806439402
These are the same issues that I described in the first email
when I updated Linus' tree, so they are not due to the mistake
of not being in master branch.
And now if I go back to v1.6.0 I get this
[mafra@localhost:git]$ git checkout master
Switched to branch "master"
Your branch is behind 'origin/master' by 5 commits, and can be fast-forwarded.
[mafra@localhost:git]$ git pull
Updating 9f8f132..5508064
Fast forward
Documentation/Makefile | 8 ++++-
Documentation/git-format-patch.txt | 3 +-
INSTALL | 5 ++-
Makefile | 6 ++++
contrib/hooks/post-receive-email | 57 ++++++++++++++++++++++++++++++------
5 files changed, 65 insertions(+), 14 deletions(-)
[mafra@localhost:git]$
and everything is ok again.
Anything else I can do to help or is bisection the last resort? :-)
Thanks,
Carlos
^ permalink raw reply
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Junio C Hamano @ 2008-11-05 7:03 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, git
In-Reply-To: <20081105033151.GB24886@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Nov 04, 2008 at 03:54:54PM -0800, Junio C Hamano wrote:
>
>> Pierre Habouzit <madcoder@debian.org> writes:
>>
>> > Automatically turn --compose on when there is more than one patch, and
>> > that the output is a tty.
>>
>> I do not think this is a good idea. I suspect I am not the only person
>> who uses "format-patch --cover-letter", edit the files to review and
>> prepare, and runs send-email to fire them off.
>
> Maybe a config option to turn this behavior on? It seems specific to
> different workflows (i.e., whether or not you are using "git send-email
> $REVS" or using format-patch first).
Yeah, if send-email did not have --compose to begin with, we could just
say "don't use --compose; use --cover-letter when you use send-email to
front-end format-patch instead", but some people perhaps are used to run
format-patch separately without --cover-letter and then create the cover
letter from scratch with --compose (which seems a bit more work to me,
though).
So I am not opposed to a sendemail.foo configuration option.
^ 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