* Re: Git SVN Rebranching Issue
From: Avery Pennarun @ 2008-11-05 0:40 UTC (permalink / raw)
To: Eric Wong; +Cc: Dmitry Potapov, Matt Kern, git
In-Reply-To: <20081105003318.GA5666@hand.yhbt.net>
On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Dmitry Potapov <dpotapov@gmail.com> wrote:
>> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
>> >
>> > Short answer: you can use grafts to remove parents.
>>
>> Using grafts requires some cautious, especially when it is used to make
>> some commits unreachable, because git gc can remove unreachable commits.
>> Also, a repository with grafts cannot be cloned. So using grafts looks
>> like more as workaround rather a real solution.
>
> I don't think extra history is harmful at all, so the grafts could even
> be temporary. AFAIK, the extra history is only an aesthetic issue in
> visualizers (and I actually like to see it myself).
But it's *lying* history in this case; it doesn't reflect what really
happened in svn *or* in real life. I'd say lying history is most
often harmful. "git blame" and "git log" will lie in this case, for
example.
>> Would it not be better to save the old branch using "@SVN-NUMBER" as
>> suffix? Thus, those do not need the old branch can easily delete it.
>
> That would require renaming _existing_ branches to their "@SVN-NUMBER"
> name; which would break mechanisms for tracking branches based on
> refname.
Well, you wouldn't have to rename the existing branch. You would
simply create the new @SVN-NUMBER branch when it became clear that
that commit is no longer reachable from the undecorated branch ref.
Isn't that why the @SVN-NUMBER branches are needed in the first place?
As for tracking branches based on refname, it seems like the current
behaviour of pretending to merge histories together wouldn't work too
well anyway. For someone pulling from the messed-up branch, they
really *will* need to rewind and re-pull, since that's exactly what
happened in svn. I don't think git has any chance of doing this
automatically just because of a new commit with two parents.
Disclaimer: I haven't run into any of this myself since I don't
recycle branch names in svn :)
Have fun,
Avery
^ permalink raw reply
* Re: Git SVN Rebranching Issue
From: Eric Wong @ 2008-11-05 0:33 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Matt Kern, git
In-Reply-To: <20081104094224.GC24100@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
> >
> > Short answer: you can use grafts to remove parents.
>
> Using grafts requires some cautious, especially when it is used to make
> some commits unreachable, because git gc can remove unreachable commits.
> Also, a repository with grafts cannot be cloned. So using grafts looks
> like more as workaround rather a real solution.
I don't think extra history is harmful at all, so the grafts could even
be temporary. AFAIK, the extra history is only an aesthetic issue in
visualizers (and I actually like to see it myself).
Besides, git svn is just a workaround until the SVN repository is
replaced entirely by git :)
> > It was actually an intentional design decision on my part preserve
> > parents based on branch name. We would eventually otherwise lose
> > history of the now-deleted branches, as reflogs can expire.
>
> Would it not be better to save the old branch using "@SVN-NUMBER" as
> suffix? Thus, those do not need the old branch can easily delete it.
That would require renaming _existing_ branches to their "@SVN-NUMBER"
name; which would break mechanisms for tracking branches based on
refname.
--
Eric Wong
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Bernt Hansen @ 2008-11-05 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vod0voy22.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>>
>>> Commits B, C, and D are not included in the git log -S output even
>>> though with gitk you can see that 'org-publish-validate-link' is in the
>>> patch.
>>
>> It is not sufficient for it to be in the patch, it has to be added or
>> deleted in whole. So for example if you had a line
>>
>> org-publish-validate-link Hello
>>
>> and you changed it to
>>
>> org-publish-validate-link World
>>
>> git log -SWorld will find the commit, but git log
>> -Sorg-publish-validate-link will not.
>
> It seems nobody has looked at the actual commits, but Dscho got it 80%
> right.
>
> There seems to be a misconception on what -S<foo> does. It does *NOT*
> grep for string <foo> in the patch text. It counts number of <foo> in
> preimage and postimage and decides that the commit is worth showing iff
> they differ.
>
> If you look at, for example (B):
>
> http://repo.or.cz/w/org-mode.git?a=commitdiff;h=837c81ce51
>
> You can see that in org-publish.el, org-publish-validate-link appears once
> as removed and once as added, so the total number of the appearance of the
> symbol in preimage and postimage are the same.
Now I get it :)
Thanks both of you!
Regards,
Bernt
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Bernt Hansen @ 2008-11-05 0:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811050014310.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>
>> Commits B, C, and D are not included in the git log -S output even
>> though with gitk you can see that 'org-publish-validate-link' is in the
>> patch.
>
> It is not sufficient for it to be in the patch, it has to be added or
> deleted in whole. So for example if you had a line
>
> org-publish-validate-link Hello
>
> and you changed it to
>
> org-publish-validate-link World
>
> git log -SWorld will find the commit, but git log
> -Sorg-publish-validate-link will not.
Ah I wasn't aware of that.
In this case the function 'org-publish-validate-link' was commented out,
and then in a later commit the comments were removed.
I was expecting these commits to be found by git log -S.
Thanks!
Bernt
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Bob Hiestand @ 2008-11-05 0:18 UTC (permalink / raw)
To: geoffrey.russell; +Cc: git, Johannes Schindelin
In-Reply-To: <93c3eada0811041449u20e0fc74gf6a1cb420923e484@mail.gmail.com>
On Tue, Nov 4, 2008 at 4:49 PM, Geoff Russell
<geoffrey.russell@gmail.com> wrote:
> Apologies to Johannes and Bob who have tried to help
> but I'm still having difficulties, here is my current non-working script:
>
> ------------------------------------------------------------------
> #!/bin/sh
> DIR=/tmp/gitdemo
> # for testing just arbitrarily
> # select the 15th most recent commit as our new origin
> NEWORIGIN=$(git rev-list master@{15} | head -1)
> echo $NEWORIGIN
> # checkout earlist point we are interested in
> # we want to drop any history before this point
> git checkout $NEWORIGIN
> # now make a new directory, initialise with new origin
> # and apply all commits after that point
> mkdir $DIR && (cd $DIR ; git init) && \
> rsync -aHv --exclude=.git ./ $DIR && \
> (cd $DIR ; git add . ; git commit -m "starting point" </dev/null ) && \
> git fast-export $NEWORIGIN..master | (cd $DIR ; git fast-import )
>
> ----------------- end of script
>
> The fast-import gives me a message I don't understand and doesn't
> do the import.
If I understood your requirement (I know nothing about fast-export),
it would look like this:
#!/bin/sh
DIR=/tmp/gitdemo
ORIGDIR=$PWD
git checkout -b shorthistory
NEWORIGIN=$(git rev-list --since='5 months ago' --reverse HEAD| head -1)
echo $NEWORIGIN
git filter-branch --parent-filter '
test $GIT_COMMIT = '$NEWORIGIN' &&
echo || cat' \
--tag-name-filter cat $NEWORIGIN^..
mkdir $DIR
cd $DIR
git init
git fetch $ORIGDIR shorthistory:master
Thank you,
bob
^ permalink raw reply
* Re: [PATCH v2 0/2] post-receive-email configurable rev display
From: Junio C Hamano @ 2008-11-04 23:55 UTC (permalink / raw)
To: Pete Harlan; +Cc: Andy Parkins, git
In-Reply-To: <1225783194-24640-1-git-send-email-pgit@pcharlan.com>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH] Makefile: add install-man rules (quick and normal)
From: Junio C Hamano @ 2008-11-04 23:55 UTC (permalink / raw)
To: markus.heidelberg; +Cc: gitster, git
In-Reply-To: <200811021853.03718.markus.heidelberg@web.de>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH v2 1/3] t7700: demonstrate mishandling of objects in packs with a .keep file
From: Junio C Hamano @ 2008-11-04 23:55 UTC (permalink / raw)
To: Brandon Casey; +Cc: Shawn O. Pearce, Git Mailing List, Nicolas Pitre
In-Reply-To: <muOuA1nLBoljLnZoguxeFeKt-8Q-I9Y3ljvxnLWLt9KyA8HwVtMa4Q@cipher.nrlssc.navy.mil>
Thanks; queued.
^ permalink raw reply
* Re: [PATCH 5/5] git send-email: turn --compose on when more than one patch.
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-6-git-send-email-madcoder@debian.org>
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.
^ permalink raw reply
* Re: [PATCH 4/5] git send-email: ask less questions when --compose is used.
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-5-git-send-email-madcoder@debian.org>
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.
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)?
^ permalink raw reply
* Re: [PATCH 2/5] git send-email: interpret unknown files as revision lists
From: Junio C Hamano @ 2008-11-04 23:54 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225815858-30617-3-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index aaace02..c29868a 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -22,8 +22,11 @@ use Term::ReadLine;
> use Getopt::Long;
> use Data::Dumper;
> use Term::ANSIColor;
> +use File::Temp qw/ tempdir /;
We seem to use File::Temp::tempdir already elsewhere, but they are in
archimport, cvsexportcommit and cvsserver, all of which are rather rarely
used ones. I think this is Perl 5.6.1 addition. Is everybody Ok with
this dependency? Just double checking.
> @@ -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).
^ permalink raw reply
* Re: [(v2) PATCH 2/2] tag: Add more tests about mixing incompatible modes and options
From: Junio C Hamano @ 2008-11-04 23:47 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git
In-Reply-To: <20081104232036.19090.6085.stgit@arrakis.enst.fr>
Thanks; will queue.
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Junio C Hamano @ 2008-11-04 23:45 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.1.00.0811050014310.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 4 Nov 2008, Bernt Hansen wrote:
>
>> Commits B, C, and D are not included in the git log -S output even
>> though with gitk you can see that 'org-publish-validate-link' is in the
>> patch.
>
> It is not sufficient for it to be in the patch, it has to be added or
> deleted in whole. So for example if you had a line
>
> org-publish-validate-link Hello
>
> and you changed it to
>
> org-publish-validate-link World
>
> git log -SWorld will find the commit, but git log
> -Sorg-publish-validate-link will not.
It seems nobody has looked at the actual commits, but Dscho got it 80%
right.
There seems to be a misconception on what -S<foo> does. It does *NOT*
grep for string <foo> in the patch text. It counts number of <foo> in
preimage and postimage and decides that the commit is worth showing iff
they differ.
If you look at, for example (B):
http://repo.or.cz/w/org-mode.git?a=commitdiff;h=837c81ce51
You can see that in org-publish.el, org-publish-validate-link appears once
as removed and once as added, so the total number of the appearance of the
symbol in preimage and postimage are the same.
^ permalink raw reply
* Re: git pull regression?
From: Junio C Hamano @ 2008-11-04 23:37 UTC (permalink / raw)
To: Carlos R. Mafra; +Cc: git
In-Reply-To: <20081104222749.GA9296@localhost.aei.mpg.de>
"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.
^ permalink raw reply
* [(v2) PATCH 2/2] tag: Add more tests about mixing incompatible modes and options
From: Samuel Tardieu @ 2008-11-04 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <20081104232031.19090.47633.stgit@arrakis.enst.fr>
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
t/t7004-tag.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index f0edbf1..f377fea 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1090,4 +1090,15 @@ test_expect_success 'filename for the message is relative to cwd' '
git cat-file tag tag-from-subdir-2 | grep "in sub directory"
'
+# mixing modes and options:
+
+test_expect_success 'mixing incompatibles modes and options is forbidden' '
+ test_must_fail git tag -a
+ test_must_fail git tag -l -v
+ test_must_fail git tag -n 100
+ test_must_fail git tag -l -m msg
+ test_must_fail git tag -l -F some file
+ test_must_fail git tag -v -s
+'
+
test_done
^ permalink raw reply related
* [(v2) PATCH 1/2] tag: Check that options are only allowed in the appropriate mode
From: Samuel Tardieu @ 2008-11-04 23:20 UTC (permalink / raw)
To: git
If "git tag -d -l -v ..." is called, only "-l" is honored, which is
arbitrary and wrong. Also, unrecognized options are accepted in the
wrong modes, causing for example "git tag -n 100" to create a tag
named "100" while the user may have wanted to type "git tag -n100".
This patch checks that "git tag" knows in what mode it operates before
performing any operation and accepts only the related options.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
---
builtin-tag.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 84db156..d339971 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -344,7 +344,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
const char *object_ref, *tag;
struct ref_lock *lock;
- int annotate = 0, sign = 0, force = 0, lines = 0,
+ int annotate = 0, sign = 0, force = 0, lines = -1,
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
@@ -380,9 +380,19 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
}
if (sign)
annotate = 1;
+ if (argc == 0 && !(delete || verify))
+ list = 1;
+ if ((annotate || msg.given || msgfile || force) &&
+ (list || delete || verify))
+ usage_with_options(git_tag_usage, options);
+
+ if (list + delete + verify > 1)
+ usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines);
+ if (lines != -1)
+ die("-n option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
@@ -406,11 +416,6 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
}
}
- if (argc == 0) {
- if (annotate)
- usage_with_options(git_tag_usage, options);
- return list_tags(NULL, lines);
- }
tag = argv[0];
object_ref = argc == 2 ? argv[1] : "HEAD";
^ permalink raw reply related
* Re: [PATCH 1/3] tag: Do not allow to call "git tag" in more than one operating mode
From: Samuel Tardieu @ 2008-11-04 23:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej1rqfar.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [2008-11-04 14:47:40 -0800]
| I think this patch breaks "git tag -a" or "git tag -s", but I didn't try.
| Run
|
| $ git tag -s
|
| with and without your patch.
That's right. I didn't notice it because I developped the 2/3 at
the same time and tested with both applied at the same time.
I will resubmit the serie with the first two merged together,
as they are both short, on the same topic and fix the same
problem.
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Johannes Schindelin @ 2008-11-04 23:15 UTC (permalink / raw)
To: Bernt Hansen; +Cc: git
In-Reply-To: <87fxm7rtb7.fsf@gollum.intra.norang.ca>
Hi,
On Tue, 4 Nov 2008, Bernt Hansen wrote:
> Commits B, C, and D are not included in the git log -S output even
> though with gitk you can see that 'org-publish-validate-link' is in the
> patch.
It is not sufficient for it to be in the patch, it has to be added or
deleted in whole. So for example if you had a line
org-publish-validate-link Hello
and you changed it to
org-publish-validate-link World
git log -SWorld will find the commit, but git log
-Sorg-publish-validate-link will not.
Hth,
Dscho
^ permalink raw reply
* Re: git log -S doesn't find some commits
From: Pieter de Bie @ 2008-11-04 23:06 UTC (permalink / raw)
To: Bernt Hansen; +Cc: git
In-Reply-To: <87fxm7rtb7.fsf@gollum.intra.norang.ca>
On Nov 4, 2008, at 11:59 PM, Bernt Hansen wrote:
> o--o--o--o-------------------M--F--o-- .. --o master
> / /
> A--o-- .. --o--o-------------o--o--B--C--X--D
>
>
> where commits A, B, C, D, and F all modify lines with
> 'org-publish-validate-link'. M is a merge commit and X has an empty
> log
> message.
>
> $ git checkout 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 # commit F
> $ git log -Sorg-publish-validate-link
B,C,X and D are not part of 'F', so why should they be included?
You can do something like 'git log -S... F D' to show commits that are
also in D, or git log --all to show all commits.
^ permalink raw reply
* git log -S doesn't find some commits
From: Bernt Hansen @ 2008-11-04 22:59 UTC (permalink / raw)
To: git
Hi!
The org-mode repository at git://repo.or.cz/org-mode.git has history
that looks like this:
o--o--o--o-------------------M--F--o-- .. --o master
/ /
A--o-- .. --o--o-------------o--o--B--C--X--D
where commits A, B, C, D, and F all modify lines with
'org-publish-validate-link'. M is a merge commit and X has an empty log
message.
$ git checkout 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 # commit F
$ git log -Sorg-publish-validate-link
reports 3 commits
F, A, and something earlier than A
Commits B, C, and D are not included in the git log -S output even
though with gitk you can see that 'org-publish-validate-link' is in the
patch.
Am I doing something wrong or is this a bug?
$ git --version
git version 1.6.0.3.523.g304d0
I've marked the commits in column one below.
$ git log --pretty=oneline
F 8ea076e2de2b3721bd813ea5a2df1b53d0c25055 Updated org-publish.el (now version 1.8
e322abfd14267a154a06deb1e7ef5a432b17f68a Merge branch 'add-recursion-to-org-publ
6208fb43cb1bbab852560cf506c7d12674307492 Minor docstring fix.
df54646ab324b11e99279dc0b6dfa161a1c72c7d Fixed the Timeline node.
D 4dcecb97bf4586c26f7e955980caa7e9630ae9a7 More cleaning.
X eda5a993cab01acd6878ab6c982b075d2cba167b *** empty log message ***
C b05bc10e6794c902df679b906d8bd6ec3f5633a9 Cleaned up code.
B 837c81ce51d90427bbcc32b06d84505b1a1e6b2a Use alist instead of a hashtable.
960449c9e93725f791bd450d3c85fd71339efb09 Cleaned up the buffer.
bf09955fec57307616926959b31e19af42520db0 Bugfix for `org-archive-subtree'.
f247d16417f17140a5bd5d03db164cc74191d9c1 Added support for :maxlevel and :skip-e
bd172412fafaa0386762826677f9929c9c4fc41c Added support for recursive publication
96e96fa684585e9916f4d6cdde20d4df7ff3f7d7 Added (require 'erc-log).
Thanks for git!
Bernt
^ permalink raw reply
* Re: exporting the last N days of a repository
From: Geoff Russell @ 2008-11-04 22:49 UTC (permalink / raw)
To: git
In-Reply-To: <cc29171c0811030855s2fb0d7a5ncdfdd6acd7c71537@mail.gmail.com>
Apologies to Johannes and Bob who have tried to help
but I'm still having difficulties, here is my current non-working script:
------------------------------------------------------------------
#!/bin/sh
DIR=/tmp/gitdemo
# for testing just arbitrarily
# select the 15th most recent commit as our new origin
NEWORIGIN=$(git rev-list master@{15} | head -1)
echo $NEWORIGIN
# checkout earlist point we are interested in
# we want to drop any history before this point
git checkout $NEWORIGIN
# now make a new directory, initialise with new origin
# and apply all commits after that point
mkdir $DIR && (cd $DIR ; git init) && \
rsync -aHv --exclude=.git ./ $DIR && \
(cd $DIR ; git add . ; git commit -m "starting point" </dev/null ) && \
git fast-export $NEWORIGIN..master | (cd $DIR ; git fast-import )
----------------- end of script
The fast-import gives me a message I don't understand and doesn't
do the import.
^ permalink raw reply
* Re: [PATCH 1/3] tag: Do not allow to call "git tag" in more than one operating mode
From: Junio C Hamano @ 2008-11-04 22:47 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: git
In-Reply-To: <20081104124207.18273.31679.stgit@arrakis.enst.fr>
Samuel Tardieu <sam@rfc1149.net> writes:
> If "git tag -d -l -v ..." is called, only "-l" is honored, which is
> arbitrary and wrong.
>
> This patch checks that "git tag" knows in what mode it operates before
> performing any operation.
>
> Signed-Off-By: Samuel Tardieu <sam@rfc1149.net>
s/-Off-B/off-b/;
I think this patch breaks "git tag -a" or "git tag -s", but I didn't try.
Run
$ git tag -s
with and without your patch.
^ permalink raw reply
* git pull regression?
From: Carlos R. Mafra @ 2008-11-04 22:27 UTC (permalink / raw)
To: git
Hi,
I tested git v1.6.0.3 today and noticed that git pull is
behaving strangely, compared to what I was used to with
v1.5.6.3
It no longer tells me "Already up-to-date." when it used
to, now it simply says nothing.
And when I pulled Linus tree for the kernel this morning
it downloaded the new commits but git didn't show the
diffstat.
Furthermore, it kept saying to me
"Your branch is behind 'origin/master' by 31 commits,
and can be fast-forwarded"
and git log was not showing the new commits.
At first I thought I had made some mistake with my repo,
but I searched the mailing list and there was a similar
case which was "fixed" after using 'git status' followed
by another 'git pull'. But in my case it did not help.
So I went back to v1.5.6.3 and everything was back
to normal.
After that I made some tests, and v1.6.0 was good
and v1.6.0.1 was bad, but I didn't bisect it
further.
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 :-)
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Christian MICHON @ 2008-11-04 22:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4910C6F4.5010407@op5.se>
On Tue, Nov 4, 2008 at 11:04 PM, Andreas Ericsson <ae@op5.se> wrote:
> Ah, right. Octopus merge always does merge head reduction, but to do
> that it needs to find a common ancestor. When no such ancestor exists,
> it will fail (with a message like "shouldn't be doing octopus merge"?).
>
> If there's no "--no-reduce-heads" option to "git merge", I think you're
> screwed with getting that to happen in a single commit.
:(
>
> Oh wait.
>
> git merge i1 && git merge --no-commit i2 && git commit --amend
>
> might work. I'm still shooting from the hip though, and now it's far too
> late for me to think more. gl though.
>
it's late for me too!
$ git merge i1/master
Merge made by recursive.
a | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
$ git merge --no-commit i2/master
Automatic merge went well; stopped before committing as requested
$ git commit --amend
fatal: You are in the middle of a merge -- cannot amend.
note the merge can work, but it's still done in 2 steps. :(
thanks for suggesting this.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Andreas Ericsson @ 2008-11-04 22:04 UTC (permalink / raw)
To: Christian MICHON; +Cc: Git Mailing List
In-Reply-To: <46d6db660811041308o19f1131dm4d49b6703fa6d22b@mail.gmail.com>
Christian MICHON wrote:
> Andreas Ericsson wrote:
>> Christian MICHON wrote:
>>> Hi,
>>>
>>> I previously posted here a question on how to merge unrelated repos,
>>> and I was quite happy with the answer.
>>> git pull repo_name repo_branch
>>>
>>> Yet, when I merge these repos (they're unrelated), I'd like to merge
>>> all of them at once.
>>>
>>> How do I pull for example 2 repos in 1 command ? I cannot figure out
>>> the exact syntax to use.
>>>
>>> I tried:
>>> git pull ../i1 0.5 ../i2 master
>>> git pull ../i1 0.5 -- ../i2 master
>>>
>>> I also tried to play with --no-commit and -s to no avail.
>>>
>>> Does anyone of you already use this and knows the trick ? Thanks in
>>> advance!
>>>
>> You can only pull from a single repository at a time. The first way of doing
>> what you want that comes to mind is:
>>
>> git remote add lib1 lib1url
>> git remote add lib2 lib2url
>> git fetch lib1 && git fetch lib2 && git merge lib1/master lib2/master
>>
>> --
>> Andreas Ericsson andreas.ericsson@op5.se
>> OP5 AB www.op5.se
>> Tel: +46 8-230225 Fax: +46 8-230231
>>
>
> and apparently this strategy (which I tried before too :( ) fails when merging.
>
> example:
> repo i1 contains file 'a'
> repo i2 contains file 'b'
> new repo z contains file 'readme' and I want to pull repo i1 and i2 at
> the same time inside repo z.
>
> typically, I've to pull 1 repo at a time, if I use pull. If I fetch
> both without merge, and then I try a merge, it fails.
> maybe I'm on a wild goose chase after all.
>
Ah, right. Octopus merge always does merge head reduction, but to do
that it needs to find a common ancestor. When no such ancestor exists,
it will fail (with a message like "shouldn't be doing octopus merge"?).
If there's no "--no-reduce-heads" option to "git merge", I think you're
screwed with getting that to happen in a single commit.
Oh wait.
git merge i1 && git merge --no-commit i2 && git commit --amend
might work. I'm still shooting from the hip though, and now it's far too
late for me to think more. gl though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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