* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Junio C Hamano @ 2007-06-06 20:07 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0706060852y4ab6b794m5fed0484c63159e4@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
> Otherwise ".git" is removed from every remote path which has it,
> including "/some/path/somename.git".
I was very tempted to apply this patch, but after re-reading it
once more, I decided to drop it.
I do not mind keeping the extra .git/ suffix in the -v output in
your example, as the message is just "verbose information":
$ git fetch -v
* refs/heads/origin: same as branch 'master' of /home/user/linux
commit: 5ecd310
But the same output is used by log messages for the merge
commits; indeed, the primary purpose of this output is to
prepare messages for merge commits. From the beginning we
deliberately omitted .git suffix to keep the resulting log
message short and sweet. Keeping .git suffix goes against it.
A repository "git://$site/repo.git" can be accessed with
"git://$site/repo". Repository owners _can_ confuse their users
by having both repo and repo.git, but I honestly do not see a
reason to encourage that.
Earlier you mentioned you know of a case where "$URL/repo.git"
exists and "$URL/repo" does not, and the current clone fails to
set up the target repository after cloning from "$URL/repo"
correctly? I admit I haven't reproduced nor debugged it, but if
that is the case that needs to be fixed.
^ permalink raw reply
* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Junio C Hamano @ 2007-06-06 19:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0706060427l1846bde7racabcfea5d15bdb4@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> writes:
>> > Besides, I just noticed git-clone is broken WRT the .git
>> > as well: I can clone a "a.git" into "b" (and it ignores -l and -s!),
>> > but I can't fetch the "a" (aka "origin") being in "b". And of
>> > course, "origin" in "b" is setup as "/path/a", not "/path/a.git".
>>
>> This probably is worth fixing, independent from what the message
>> says before or after your patch.
>
> And "probably" means: it is broken, but this is ok?
No; it means "patches welcome". Regardless of the patch you are
promoting, that would be a real fix.
^ permalink raw reply
* [PATCH] t5000: skip ZIP tests if unzip was not found
From: Johannes Schindelin @ 2007-06-06 18:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706051819290.4046@racer.site>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Tue, 5 Jun 2007, Johannes Schindelin wrote:
> I seem to remember that I patched it already.
>
> http://thread.gmane.org/gmane.comp.version-control.git/46854/focus=46899
>
> Unfortunately, the patch was incorrect, and I forgot to do it
> properly. Will try this afternoon.
So, took me some more time. Sorry.
t/t5000-tar-tree.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index e223c07..5500505 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -108,6 +108,13 @@ test_expect_success \
'git-archive --format=zip' \
'git-archive --format=zip HEAD >d.zip'
+$UNZIP -v 2>/dev/null
+if [ $? -eq 127 ]; then
+ echo "Skipping ZIP tests, because unzip was not found"
+ test_done
+ exit
+fi
+
test_expect_success \
'extract ZIP archive' \
'(mkdir d && cd d && $UNZIP ../d.zip)'
^ permalink raw reply related
* Re: clarify git clone --local --shared --reference
From: Brandon Casey @ 2007-06-06 18:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <466701E0.4000108@nrlssc.navy.mil>
Brandon Casey wrote:
> If the above is wrong, then I'm missing a clue about git-rebase.
^^^^^^
I mean repack.
-brandon
^ permalink raw reply
* Re: clarify git clone --local --shared --reference
From: Brandon Casey @ 2007-06-06 18:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070606051111.GF9513@spearce.org>
Shawn O. Pearce wrote:
> Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> Shawn O. Pearce wrote:
>>> b) Don't repack the source repository without accounting for the
>>> refs and reflogs of all --shared repositories that came from it.
>>> Otherwise you may delete objects that the source repository no
>>> longer needs, but that one or more of the --shared repositories
>>> still needs.
>> How should this be accomplished? Does this mean never run
>> git-gc/git-repack on the source repository? Or is there a way to
>> cause the sharing repositories to copy over objects no longer
>> required by the source repository?
>
> Well, you can repack, but only if if you account for everything.
> The easiest way to do this is push every branch from the --shared
> repos to the source repository, repack the source repository, then
> you can run `git prune-packed` in the --shared repos to remove
> loose objects that the source repository now has.
>
> You can account for the refs by hand when you run pack-objects
> by hand, but its horribly difficult compared to the push and then
> repack I just described. I think that long-lived --shared isn't that
> common of a workflow; most people use --shared for shortterm things.
> For example contrib/continuous uses --shared when it clones the
> repository to create a temporary build area.
>
ok. I just want to make sure this is not really about prune'ing.
In the following, source and --shared repos are identical except...
1) Source repo contains loose objects which are new commits.
--shared repo does git-pull.
we fast-forward, copying very little.
success.
2) Source repo contains loose objects which are new commits.
Source repo does git-gc, which repacks but doesn't prune.
--shared repo does git-pull.
success?
3) Source repo deletes a branch that --shared repo also has.
This deletion creates dangling unreferenced objects.
** --shared repo still ok here, right?
Source repo does git-gc, which repacks but doesn't prune.
** Is --shared screwed at this point? (This is what I understand
you to say above) Or do the dangling objects still exist,
so --shared is still ok?
git gc --prune
--shared is fubar, at least on the deleted branch.
The docs (git-repack.txt) seem to suggest that git-repack (without -d)
does not delete any objects. And if -d is used, then at most objects
already referenced in other packs will be deleted. This makes me think
that repack is safe on the source repository.
If the above is wrong, then I'm missing a clue about git-rebase. And
don't feel like you have to explain it to me. Do feel free to give a
short *NO!! REPACK IS DANGEROUS ON SHARED REPOS YOU IDIOT!!* or other
such beating. But if you see what I'm misunderstanding please let me know.
If the above is right, then it seems like the source repo developer
should be able to go about his developing, and git-gc'ing without
regard for other developers who may be --share'ing. And only when the
source developer wants to do a prune of dangling objects must something
special be done. git-prune.txt suggests:
git prune $(cd ../another && $(git-rev-parse --all))
> In my day-job repositories I have about 150 MiB of blobs that
> are very common across a number of Git repositories. I've made a
> single repo that has all of those packed, and then setup that as an
> alternate for everything else. It saves a huge chunk of disk for us.
> But that common-blob.git thing that I created never gets changed,
> and never gets repacked. Its sort of a "historical archive" for us.
> Works very nicely. Alternates have their uses...
Ahh, now that's interesting.
Could I create something like that by doing something like this:
(in a cloned repository with only a master branch)
git reset --hard HEAD^ # I know, HEAD is still in the history
git gc --prune # log so it doesn't get pruned, but
# it's just an example
(now back in my devel repo)
<add archive repo to alternates>
git prune-packed
Now most everything is likely referenced in the archive repo except the
last commit. Well, maybe even the HEAD commit due to the history log.
Depending on how you reply above, a periodic pull into the archive repo
(and a repack?), then a 'git prune-packed' from the sharers could allow
good sharing? <waiting for a "NO, YOU IDIOT!"> If not, then I guess the
archive creation steps could be repeated periodically.
-brandon
^ permalink raw reply
* [PATCH v2] filter-branch: also don't fail in map() if a commit cannot be mapped
From: Johannes Sixt @ 2007-06-06 18:38 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0706061850220.4046@racer.site>
The map() function can be used by filters to map a commit id to its
rewritten id. Such a mapping may not exist, in which case the identity
mapping is used (the commit is returned unchanged).
In the rewrite loop, this mapping is also needed, but was done
explicitly in the same way. Use the map() function instead.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
On Wednesday 06 June 2007 19:50, Johannes Schindelin wrote:
> On Wed, 6 Jun 2007, Johannes Sixt wrote:
> > - [ -r "$workdir/../map/$1" ] || return 1
> > + # if it was not rewritten, take the original
> > + [ -r "$workdir/../map/$1" ] || echo "$1"
>
> Maybe "test" instead of "["? Otherwise, ACK from me.
Right!
git-filter-branch.sh | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index fbbb044..15e9b46 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -189,7 +189,8 @@ USAGE="git-filter-branch [-d TEMPDIR] [-r STARTREV]... [-k KEEPREV]... [-s SRCBR
map()
{
- [ -r "$workdir/../map/$1" ] || return 1
+ # if it was not rewritten, take the original
+ test -r "$workdir/../map/$1" || echo "$1"
cat "$workdir/../map/$1"
}
@@ -362,14 +363,9 @@ while read commit; do
parentstr=
for parent in $(get_parents $commit); do
- if [ -r "../map/$parent" ]; then
- for reparent in $(cat "../map/$parent"); do
- parentstr="$parentstr -p $reparent"
- done
- else
- # if it was not rewritten, take the original
- parentstr="$parentstr -p $parent"
- fi
+ for reparent in $(map "$parent"); do
+ parentstr="$parentstr -p $reparent"
+ done
done
if [ "$filter_parent" ]; then
parentstr="$(echo "$parentstr" | eval "$filter_parent")"
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Add git-filter-branch
From: Johannes Schindelin @ 2007-06-06 17:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4666D143.32BC9693@eudaptics.com>
Hi,
On Wed, 6 Jun 2007, Johannes Sixt wrote:
> Johannes Schindelin wrote:
> > Of course, it would be even more so if the target branch name was
> > "filtered", overrideable by "--target <name>".
>
> My plan for this is:
>
> 1. run the rev-list args ("$@") through rev-parse
> 2. pick only the positive ones (/^[a-z0-9]{40}$/)
> 3. filter show-ref against the result of 2.
> 4. foreach ref in the result of 3. install a refs/rewritten/$ref
> with the mapped id if and only if the mapped id is different
> from the original id of $ref.
>
> Then you can, for example, 'git filter-branch --all' to rewrite all
> branches.
That sounds really sensible. For (2), I suggest "git-rev-parse
--symbolic", though. And maybe you want to make sure that there were no
invalid branch names, i.e. "git-filter-branch next~2". (Otherwise, you
would try to create refs/filtered/next~2 after filtering all commits.)
Ciao,
Dscho
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: Jon Loeliger @ 2007-06-06 18:18 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Marc Singer, Git List
In-Reply-To: <vpqhcplx8vb.fsf@bauges.imag.fr>
On Wed, 2007-06-06 at 12:58, Matthieu Moy wrote:
> Cogito is more or less depreceted now. You should probably use git
> itself.
Hmm. We should then likely try to encourage kernel.org and denx.de
folks to advertise cloning their published repos with git rather
than cogito now.
jdl
^ permalink raw reply
* Re: merging two repositories
From: Johannes Schindelin @ 2007-06-06 18:01 UTC (permalink / raw)
To: joel reed; +Cc: git
In-Reply-To: <4666CB31.9070007@gmail.com>
Hi,
On Wed, 6 Jun 2007, joel reed wrote:
> So now I have two trees, one pure git using repo.or.cz, and the other
> made by git-svn against Google' subversion.
I'd merge them by fetching the pure-git one into the git-svn'ed. Or vice
versa. Then, you can say "git merge <other-branch>". If the revisions are
similiar (or identical), it will succeed even if they do not have any
common ancestor.
Ciao,
Dscho
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: Matthieu Moy @ 2007-06-06 17:58 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <1181151454.6086.23.camel@zealous.synapsedev.com>
Marc Singer <elf@synapse.com> writes:
> On Thu, 2007-05-24 at 07:30 -0700, Marc Singer wrote:
>> It looks like it reduces to something very simple.
>>
>> Git patches, as generated by git-format-patch, have a header with an
>> email address.
>>
>> Cogito patches, as generated by cg-mkpatch, have no email address in the
>> header.
Cogito is more or less depreceted now. You should probably use git
itself.
>> git-am doesn't like the cogito patches.
>>
>> Is there a way to import patches that did not come from git? Remember
>> that we'd like to include the functionality of git-am that adds new
>> files to the index.
>>
>> Cheers.
>
> I have patches from another source as well and I'd like to be able to
> import them even though these aren't from git.
You cannot "import" them, because they do not contain the necessary
information (commit message and email adress). But you can "apply"
them, and then commit manually. Use git-patch (even just "patch" could
do) to apply the patch, and commit as usual.
--
Matthieu
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: J. Bruce Fields @ 2007-06-06 17:54 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <1181151454.6086.23.camel@zealous.synapsedev.com>
On Wed, Jun 06, 2007 at 10:37:34AM -0700, Marc Singer wrote:
> On Thu, 2007-05-24 at 07:30 -0700, Marc Singer wrote:
> > It looks like it reduces to something very simple.
> >
> > Git patches, as generated by git-format-patch, have a header with an
> > email address.
> >
> > Cogito patches, as generated by cg-mkpatch, have no email address in the
> > header.
> >
> > git-am doesn't like the cogito patches.
> >
> > Is there a way to import patches that did not come from git? Remember
> > that we'd like to include the functionality of git-am that adds new
> > files to the index.
> >
> > Cheers.
>
> I have patches from another source as well and I'd like to be able to
> import them even though these aren't from git.
Based on my notes from the last time I needed to feed a bunch of
non-mbox, non-git-produced patches into git-am, the hard part was
figuring out how it split a file into separate messages; my notes say:
"Finds lines begining with "From " and ending with "hh:mm:ss
yyyy". See builtin-mailsplit code for more details."
Other than that, I think it just needs and From: and Subject: lines to
get author and first-line of the commit. the git-am man page has some
documentation of this. It could probably use more.
--b.
^ permalink raw reply
* Re: [PATCH] filter-branch: also don't fail in map() if a commit cannot be mapped
From: Johannes Schindelin @ 2007-06-06 17:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1181144191777-git-send-email-johannes.sixt@telecom.at>
Hi,
On Wed, 6 Jun 2007, Johannes Sixt wrote:
> - [ -r "$workdir/../map/$1" ] || return 1
> + # if it was not rewritten, take the original
> + [ -r "$workdir/../map/$1" ] || echo "$1"
Maybe "test" instead of "["? Otherwise, ACK from me.
Ciao,
Dscho
^ permalink raw reply
* Let me ask again: How do we import patches from non-git sources?
From: Marc Singer @ 2007-06-06 17:37 UTC (permalink / raw)
To: git
In-Reply-To: <1180017010.21181.2.camel@zealous.synapsedev.com>
On Thu, 2007-05-24 at 07:30 -0700, Marc Singer wrote:
> It looks like it reduces to something very simple.
>
> Git patches, as generated by git-format-patch, have a header with an
> email address.
>
> Cogito patches, as generated by cg-mkpatch, have no email address in the
> header.
>
> git-am doesn't like the cogito patches.
>
> Is there a way to import patches that did not come from git? Remember
> that we'd like to include the functionality of git-am that adds new
> files to the index.
>
> Cheers.
I have patches from another source as well and I'd like to be able to
import them even though these aren't from git.
^ permalink raw reply
* git-svn "cannot lock ref" error during fetch
From: James Peach @ 2007-06-06 17:17 UTC (permalink / raw)
To: git
Hi all,
I'm new to git, and I'm experimenting with using git-svn to interact
with a large SVN repository with lots of branches.
I initially did an init like this:
git-svn init -t tags -b branches -T trunk svn+ssh://server/svn/project
Then I did a git-svn fetch, which started pulling all the branches.
After a while, however, it hit a branch that it couldn't pull:
Found branch parent: (tags/project-92~9)
767f1f1601a4deae459c99ea6c1d1b9ba8f57a65
Following parent with do_update
...
Successfully followed parent
fatal: refs/remotes/tags/project-92~9: cannot lock the ref
update-ref -m r13726 refs/remotes/tags/project-92~9
950638ff72acc278156a0d55baafbabb43f2b772: command returned error: 128
Some amount of searching failed to turn up any hints on what this
error means or how I can work around it. I'd appreciate any advice ...
James
^ permalink raw reply
* [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Alex Riesen @ 2007-06-06 15:52 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <81b0412b0706060045k4098eb05tc596214f8d9673bf@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 415 bytes --]
Otherwise ".git" is removed from every remote path which has it,
including "/some/path/somename.git".
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Fixed truncation of "/.git/" (with a trailing slash).
The old code broke t5515, because it has left "../.git/"
unchanged, but should have removed ".git/".
builtin-fetch--tool.c | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
[-- Attachment #2: 0001-Fix-the-remote-note-the-fetch-tool-prints-after-stori.txt --]
[-- Type: text/plain, Size: 1830 bytes --]
From c767dcc2000c72909013b9e97b18403686b44498 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa@limbo.localdomain>
Date: Wed, 6 Jun 2007 00:16:14 +0200
Subject: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
Otherwise ".git" is removed from every remote name which has it:
$ git fetch -v
* refs/heads/origin: same as branch 'master' of /home/user/linux
commit: 5ecd310
$ ls /home/user/linux
ls: /home/user/linux: No such file or directory
$ ls /home/user/linux.git
HEAD objects packed-refs ...
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
builtin-fetch--tool.c | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
index ed4d5de..ec4a8c3 100644
--- a/builtin-fetch--tool.c
+++ b/builtin-fetch--tool.c
@@ -140,7 +140,7 @@ static int append_fetch_head(FILE *fp,
int verbose, int force)
{
struct commit *commit;
- int remote_len, i, note_len;
+ int remote_len, note_len;
unsigned char sha1[20];
char note[1024];
const char *what, *kind;
@@ -173,11 +173,20 @@ static int append_fetch_head(FILE *fp,
}
remote_len = strlen(remote);
- for (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)
- ;
- remote_len = i + 1;
- if (4 < i && !strncmp(".git", remote + i - 3, 4))
- remote_len = i - 3;
+ if (remote_len > 5) {
+ static const char ending[] = "/.git";
+ const char *pe = ending + 4;
+ const char *pr = remote + remote_len - 1;
+ /* ignore trailing slashes */
+ while (pr > remote && *pr == '/')
+ --pr;
+ for (; pr > remote && pe > ending; --pr, --pe)
+ if (*pr != *pe)
+ break;
+ if (pe == ending)
+ /* "+ 1" to leave the / before .git */
+ remote_len = pr - remote + 1;
+ }
note_len = 0;
if (*what) {
--
1.5.2.1.868.gb85c1
^ permalink raw reply related
* [PATCH] filter-branch: also don't fail in map() if a commit cannot be mapped
From: Johannes Sixt @ 2007-06-06 15:36 UTC (permalink / raw)
To: git, johannes.schindelin; +Cc: Johannes Sixt
In-Reply-To: <Pine.LNX.4.64.0706051537360.4046@racer.site>
The map() function can be used by filters to map a commit id to its
rewritten id. Such a mapping may not exist, in which case the identity
mapping is used (the commit is returned unchanged).
In the rewrite loop, this mapping is also needed, but was done
explicitly in the same way. Use the map() function instead.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-filter-branch.sh | 14 +++++---------
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index fbbb044..9e12a6c 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -189,7 +189,8 @@ USAGE="git-filter-branch [-d TEMPDIR] [-r STARTREV]... [-k KEEPREV]... [-s SRCBR
map()
{
- [ -r "$workdir/../map/$1" ] || return 1
+ # if it was not rewritten, take the original
+ [ -r "$workdir/../map/$1" ] || echo "$1"
cat "$workdir/../map/$1"
}
@@ -362,14 +363,9 @@ while read commit; do
parentstr=
for parent in $(get_parents $commit); do
- if [ -r "../map/$parent" ]; then
- for reparent in $(cat "../map/$parent"); do
- parentstr="$parentstr -p $reparent"
- done
- else
- # if it was not rewritten, take the original
- parentstr="$parentstr -p $parent"
- fi
+ for reparent in $(map "$parent"); do
+ parentstr="$parentstr -p $reparent"
+ done
done
if [ "$filter_parent" ]; then
parentstr="$(echo "$parentstr" | eval "$filter_parent")"
--
1.5.2.1.120.gd732
^ permalink raw reply related
* [PATCH] filter-branch: use $(($i+1)) instead of $((i+1))
From: Johannes Schindelin @ 2007-06-06 15:24 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Junio C Hamano, Jakub Narebski, git
In-Reply-To: <20070605103421.GB16160@diku.dk>
The expression $((i+1)) is not portable at all: even some bash versions
do not grok it. So do not use it.
Noticed by Jonas Fonseca.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 5 Jun 2007, Jonas Fonseca wrote:
> Junio C Hamano <gitster@pobox.com> wrote Tue, Jun 05, 2007:
> > Jonas Fonseca <fonseca@diku.dk> writes:
> >
> > > $ git filter-branch H2
> > > /home/fonseca/bin/git-filter-branch: 386: arith: syntax error: "i+1"
> > > $
> > >
> > > A possible fix that makes the test pass for me.
> >
> > [...]
> >
> > The portable ones we already have in the code say things like:
> >
> > msgnum=$(($msgnum+1))
>
> Yes, I should have investigated before sending.
>
> > The one in filter-branch that bit you does not dereference 'i'.
> > I am reasonably sure if you fix it to read:
> >
> > i=$(( $i+1 ))
> >
> > dash would grok it.
>
> This works here. Even without the spaces.
Voila.
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 6807782..f89cfe1 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -334,7 +334,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
i=0
while read commit; do
- i=$((i+1))
+ i=$(($i+1))
printf "$commit ($i/$commits) "
git-read-tree -i -m $commit
--
1.5.2.1.2656.g1921f
^ permalink raw reply related
* Re: [PATCH] Add git-filter-branch
From: Johannes Sixt @ 2007-06-06 15:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706061600060.4046@racer.site>
Johannes Schindelin wrote:
> Of course, it would be even more so if the target branch name was
> "filtered", overrideable by "--target <name>".
My plan for this is:
1. run the rev-list args ("$@") through rev-parse
2. pick only the positive ones (/^[a-z0-9]{40}$/)
3. filter show-ref against the result of 2.
4. foreach ref in the result of 3. install a refs/rewritten/$ref
with the mapped id if and only if the mapped id is different
from the original id of $ref.
Then you can, for example, 'git filter-branch --all' to rewrite all
branches.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add git-filter-branch
From: Johannes Schindelin @ 2007-06-06 15:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <466665AD.CF5B85DF@eudaptics.com>
Hi,
On Wed, 6 Jun 2007, Johannes Sixt wrote:
> It is more natural (for git users) to specify revision ranges like
> 'master..next' instead. This makes it so. If no range is specified it
> defaults to 'HEAD'.
>
> As a consequence, the new name of the filtered branch must be the first
> non-option argument. All remaining arguments are passed to 'git rev-list'
> unmodified.
I was really close to do this myself. But I thought there was a
problem to infer the correct source branch.
But you're right, this is more gittish. (Consider that an ACK from me.)
Of course, it would be even more so if the target branch name was
"filtered", overrideable by "--target <name>".
Ciao,
Dscho
^ permalink raw reply
* merging two repositories
From: joel reed @ 2007-06-06 14:56 UTC (permalink / raw)
To: git
I've been maintaining a project in git for a while and making use of
http://repo.or.cz/w/tfs.git as a public repository. Since I also needed
a project site, I set something up at Google Code, which of course,
forces you to use subversion.
I added the files to subversion, checked them in, then a few weeks later
decided I should learn how to use git-svn. So now I have two trees, one
pure git using repo.or.cz, and the other made by git-svn against Google'
subversion.
Is there anyway to merge these two repositories into one? I don't want
to lose the http://repo.or.cz/w/tfs.git history, but I don't care about
the Google subversion history.
I tried moving the .git/svn folder from the git-svn managed repository
into the repo.or.cz .git folder, but as I expected, that didn't work.
Life's never that easy! Anyway, if anyone knows how to merge these two
repos, I would love to hear about it.
jr
PS. Maybe, a more generalized use case here is
a) maintain a git tree for a while
b) decide you have to stick code in subversion for others sometime
later, but you still want to use git and keep your git history
^ permalink raw reply
* git-svn error msg
From: Joakim Tjernlund @ 2007-06-06 14:09 UTC (permalink / raw)
To: git
git-svn init file:///usr/local/src/tst-git-svn/svn-uboot-repo/
and then
git-svn fetch yields lots of:
Use of uninitialized value in substitution (s///) at /usr/bin/git-svn line 2144.
Use of uninitialized value in substitution (s///) at /usr/bin/git-svn line 2144.
....
seems to work though.
git version - 1.5.1.3
^ permalink raw reply
* Re: [PATCH] Add git-index-pack -l to list objects in a pack
From: Nicolas Pitre @ 2007-06-06 13:55 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <11811227811793-git-send-email-sam.vilain@catalyst.net.nz>
On Wed, 6 Jun 2007, Sam Vilain wrote:
> I couldn't figure out how to make git-unpack-objects -n work.
> But it seems to be easy in the loop in index-pack
Why don't you simply use git-show-index?
Nicolas
^ permalink raw reply
* Re: [PATCH] cvsimport: add support for new style remote layout
From: Jeffrey C. Ollie @ 2007-06-06 11:52 UTC (permalink / raw)
To: git
In-Reply-To: <3a477a76f6c5396feee452678fb8110c@pinky>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Wed, 2007-05-30 at 01:56 +0100, Andy Whitcroft wrote:
> cvsimport creates any branches found in the remote CVS repository
> in the refs/heads namespace. This makes sense for a repository
> conversion. When using git as a sane interface to a remote CVS
> repository, that repository may well remain as the 'master'
> respository. In this model it makes sense to import the CVS
> repository into the refs/remotes namespace.
>
> Add a new option '-r <remote>' to set the remote name for
> this import. When this option is specified branches are named
> refs/remotes/<remote>/branch, with HEAD named as master matching
> git-clone separate remotes layout. Without branches are placed
> ion refs/heads, with HEAD named origin as before.
I've run over 5GB of cvs imports through git-cvsimport with this patch
and it's worked very well for me...
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] This patch was inspired by ClearCase command 'ct man', which
From: Jakub Narebski @ 2007-06-06 11:39 UTC (permalink / raw)
To: git
In-Reply-To: <20070605182818.GA8420@localhost>
Nguyen Thai Ngoc Duy wrote:
> opens an html help file on Windows. I at first attempted to
> implement it for MinGW port only but found it so useful that I
> wanted to have it even in Linux.
Could you _please_ follow git commit message convention, which is first line
providing summary of a change, separated by empty line from the rest of
commit description.
For example:
-- >8 --
Subject: [PATCH 1/2] Add '--html' option to git, which gives help in HTML
This patch was inspired by ClearCase command 'ct man', which
opens an html help file on Windows. I at first attempted to
implement it for MinGW port only but found it so useful that I
wanted to have it even in Linux.
[...]
Signed-off-by: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Fix the remote note the fetch-tool prints after storing a fetched reference
From: Alex Riesen @ 2007-06-06 11:27 UTC (permalink / raw)
To: J Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vps495uvs.fsf@assigned-by-dhcp.cox.net>
On 6/6/07, J Junio C Hamano <gitster@pobox.com> wrote:
> > Which one was fetched when? /home/user/a or /home/user/a.git?
>
> I am half tempted to say that this is very close to "doctor, it
> confuses me when I have both of them". Imagine the case where
> the source were a remote repository _and_ there was no way other
> than interacting with it via git protocol. You cannot really
> tell (well, you can tell half, by trying both and if a worked
> but a.git didn't you can tell that a.git does not exist) nor you
> do not really care.
Of course you can! Just print the path to the remote EXACTLY
how the user entered it!
> > Besides, I just noticed git-clone is broken WRT the .git
> > as well: I can clone a "a.git" into "b" (and it ignores -l and -s!),
> > but I can't fetch the "a" (aka "origin") being in "b". And of
> > course, "origin" in "b" is setup as "/path/a", not "/path/a.git".
>
> This probably is worth fixing, independent from what the message
> says before or after your patch.
And "probably" means: it is broken, but this is ok?
^ 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