* Re: [PATCH] tg export: implement skipping empty patches for quilt mode
From: martin f krafft @ 2008-11-26 20:39 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <1227701580-9762-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.11.26.1313 +0100]:
> addionally fix the README item for skipping the export of empty patches
> not to need an option (-n) as this should be the default.
[...]
> - TODO: -n option to prevent exporting of empty patches
> + TODO: prevent exporting of empty patches
Is it still a TODO? Looks like your patch fixes it, no?
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"the difference between genius and stupidity
is that genius has it's limits."
-- albert einstein
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-p4: fix keyword-expansion regex
From: Junio C Hamano @ 2008-11-26 20:33 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20081126185215.GA11037@osc.edu>
I will queue this to 'pu' and wait for an Ack from git-p4 folks. Thanks.
^ permalink raw reply
* git configure script
From: Neale T. Pickett @ 2008-11-26 19:30 UTC (permalink / raw)
To: git
I downloaded 1.6.0.4 from
http://kernel.org/pub/software/scm/git/git-1.6.0.4.tar.gz
and ran
./configure --prefix=$HOME/opt
But it installed everything in $HOME/bin and $HOME/libexec. Looking
into it, it seems the shipped Makefile doesn't look to see what --prefix
is, despite the configure script claiming that "make install" would
honor this.
I'm guessing it should have shipped with a Makefile.in or something, but
honestly Autoconf confuses the dickens out of me.
Neale
^ permalink raw reply
* Re: [PATCH] git checkout: don't warn about unborn branch if -f is already passed
From: Junio C Hamano @ 2008-11-26 19:46 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1227509722.32583.0.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
> I think it's unnecessary to warn that the checkout has been forced due to an
> unborn current branch if -f has been explicitly passed. For one project, I am
> using git-new-workdir to create workdirs from a bare repository whose HEAD is
> set to an unborn branch, and this warning started to irritate me.
I doubt anybody minds this particular change per-se, but I wonder what the
justification of keeping a dangling HEAD in a bare repository is.
After all, the primary intended purpose of a bare repository is to serve
as a distribution point (i.e. something you can clone from), and I think a
dangling HEAD interferes with the usual operation of clone (although I've
never tested this).
Care to explain why?
^ permalink raw reply
* Re: [PATCH] send-email: Fix Pine address book parsing
From: Junio C Hamano @ 2008-11-26 19:46 UTC (permalink / raw)
To: Trent Piepho; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0811260243440.5161@t2.domain.actdsltmp>
Trent Piepho <tpiepho@freescale.com> writes:
> ... There isn't any code that just does line wrapping.
> The code that prints out a address book entry will at various points check
> if it should output a newline. And it whatever it prints after those
> points isn't allowed to start with space. The code that reads the entries
> eats all the spaces before and after each field. If long comments are
> wrapped, it will change "a b" into "a\n : b\n" and effectively does
> s/^ +: / /; when reading it back. But email address don't get wrapped
> that way so we don't need to care about the ':'.
I never was worried about eating and losing the leading space that was
used only to signal the continuation line, but was wondering if we need to
insert an artificial space in place of the newline we are eating, but it
appears that we can say with confidence that worry is unfounded.
Will queue. Thanks.
^ permalink raw reply
* Re: git cat-file blob does not convert crlf
From: Junio C Hamano @ 2008-11-26 19:42 UTC (permalink / raw)
To: Quim K. Holland; +Cc: git
In-Reply-To: <20081127013456.6117@qkholland.gmail.com>
"Quim K. Holland" <qkholland@gmail.com> writes:
> I think git is buggy.
Thanks for pointing it out X-<.
> I wanted to discard the changes I made to my file by checking out a copy from the last commit, so I said
> % git cat-file blob HEAD:my-file >my-file
> But this does not respect core.autocrlf and the file becomes one long line.
That is pretty much intentional. cat-file is a low-level command that is
meant to inspect the raw object contents. The output from the command has
to be reproducible regardless of what customization you have in your
particular repository and omission of attributes support (including the
crlf conversion) is quite deliberate.
You said that you wanted to discard the changes by checking out a copy out
of the HEAD commit. This can literally be done by:
$ git checkout HEAD my-file
If you want to check out a copy out of the index (i.e, "the last staged
version"), you can say:
$ git checkout my-file
In other words, if you want to checkout, you can say checkout ;-)
^ permalink raw reply
* git cat-file blob does not convert crlf
From: Quim K. Holland @ 2008-11-26 19:34 UTC (permalink / raw)
To: git
I think git is buggy.
I wanted to discard the changes I made to my file by checking out a copy from the last commit, so I said
% git cat-file blob HEAD:my-file >my-file
But this does not respect core.autocrlf and the file becomes one long line.
Also it feels stupid that I have to say my-file twice at the command prompt.
^ permalink raw reply
* [PATCH] git-p4: fix keyword-expansion regex
From: Pete Wyckoff @ 2008-11-26 18:52 UTC (permalink / raw)
To: git
This text:
my $dir = $File::Find::dir;
return if ($dir !~ m,$options->{dirpat}$,);
was improperly converted to:
my $dir = $File$dir !~ m,$options->{dirpat}$,);
by the keyword identifier expansion code. Add a \n
to make sure the regex doesn't go across end-of-line
boundaries.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 9b04ca5..09317af 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1005,7 +1005,7 @@ class P4Sync(Command):
if stat['type'] in ('text+ko', 'unicode+ko', 'binary+ko'):
text = re.sub(r'(?i)\$(Id|Header):[^$]*\$',r'$\1$', text)
elif stat['type'] in ('text+k', 'ktext', 'kxtext', 'unicode+k', 'binary+k'):
- text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$]*\$',r'$\1$', text)
+ text = re.sub(r'\$(Id|Header|Author|Date|DateTime|Change|File|Revision):[^$\n]*\$',r'$\1$', text)
contents[stat['depotFile']] = text
--
1.5.6.5
^ permalink raw reply related
* Re: format-patch problem when using relative
From: Nikola Knežević @ 2008-11-26 18:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081126180154.GA7584@coredump.intra.peff.net>
On 26 Nov 2008, at 19:01 , Jeff King wrote:
> So I think what you really want is:
>
> git format-patch --relative=click click/master myclick -- click
>
> to limit the path pruning to the 'click' directory.
Yes, that did the trick. Also, when I think about it, it makes sense -
do checks relative to a path, but prune using path.
Thanks,
Nikola
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Alex Riesen @ 2008-11-26 18:43 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811260931030.14328@xanadu.home>
Nicolas Pitre, Wed, Nov 26, 2008 15:33:51 +0100:
> On Wed, 26 Nov 2008, Alex Riesen wrote:
> > 2008/11/19 Nicolas Pitre <nico@cam.org>:
> > > I'm looking at it now. I'm therefore revoking my earlier ACK as well
> > > (better keep that test case alive).
> > >
> >
> > Any news here?
>
> Yes: my hard disk crashed a couple hours after I mentioned this, so most
> of my time has been spent on recovery since then. I'll come back to it
> eventually.
Heh... Good luck!
^ permalink raw reply
* Re: [PATCH] sha1_file: avoid bogus "file exists" error message
From: Joey Hess @ 2008-11-26 18:19 UTC (permalink / raw)
To: Git List
In-Reply-To: <20081120185628.GA25604@kodama.kitenet.net>
[-- Attachment #1: Type: text/plain, Size: 294 bytes --]
Joey Hess wrote:
> Note that in both occasions that I've seen this failure, it has not been
> due to a missing directory, or bad permissions
Actually, it was due to bad permissions. :-) Once git was fixed to
actually say that, I figured out where to look to fix them.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: French git user
From: Pascal Obry @ 2008-11-26 18:06 UTC (permalink / raw)
To: devel; +Cc: Jean-Francois Veillette, git
In-Reply-To: <492D0295.6060808@morey-chaisemartin.com>
Nicolas,
There is also at least two commands that I used often that are missing
to me:
$ git checkout -b branch_name branch_point
Which is equivalent to:
$ git branch branch_name branch_point
$ git checkout branch_name
The other missing command is:
$ git add [-p|-i]
Very important to create a set tightly related commits out of a dirty tree.
Maybe also adding a note about aliases:
$ git config --global alias.co checkout
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: format-patch problem when using relative
From: Jeff King @ 2008-11-26 18:01 UTC (permalink / raw)
To: Nikola Knežević; +Cc: git
In-Reply-To: <17081052-4480-4971-9F38-BD5C48087379@gmail.com>
On Wed, Nov 26, 2008 at 05:12:02PM +0100, Nikola Knežević wrote:
> git format-patch -o patches -n --relative=click click/master myclick
>
> This produced a bunch of files in patches directory, most of which are
> empty. When I tried this --stdout, I had something like this:
Hmm. It seems that there is no history pruning done with --relative, so
you will still end up with commits that make no changes. However, this
is intentional. See cd676a51:
diff --relative: output paths as relative to the current subdirectory
[...]
- This works not just with diff but also works with the log
family of commands, but the history pruning is not affected.
In other words, if you go to a subdirectory, you can say:
$ git log --relative -p
but it will show the log message even for commits that do not
touch the current directory. You can limit it by giving
pathspec yourself:
$ git log --relative -p .
This originally was not a conscious design choice, but we
have a way to affect diff pathspec and pruning pathspec
independently. IOW "git log --full-diff -p ." tells it to
prune history to commits that affect the current subdirectory
but show the changes with full context. I think it makes
more sense to leave pruning independent from --relative than
the obvious alternative of always pruning with the current
subdirectory, which would break the symmetry.
So I think what you really want is:
git format-patch --relative=click click/master myclick -- click
to limit the path pruning to the 'click' directory.
-Peff
^ permalink raw reply
* Re: French git user
From: Pascal Obry @ 2008-11-26 17:59 UTC (permalink / raw)
To: devel; +Cc: Jean-Francois Veillette, git
In-Reply-To: <492D0295.6060808@morey-chaisemartin.com>
Nicolas,
You said that the form git-<cmd> version is deprecated. That's true. But
in the suit of the document you use only git-<cmd>. This is not working
anymore with recent Git version. I would recommend using only the "git
<cmd>" form.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: French git user
From: Pascal Obry @ 2008-11-26 17:55 UTC (permalink / raw)
To: Johan Herland; +Cc: git, devel, Jean-Francois Veillette
In-Reply-To: <200811260955.57421.johan@herland.net>
Johan,
You said that the form git-<cmd> version is deprecated. That's true. But
in the suit of the document you use only git-<cmd>. This is not working
anymore with recent Git version. I would recommend using only the "git
<cmd>" form.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-26 17:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael J Gruber, Git Mailing List, Fabian Seoane
In-Reply-To: <alpine.DEB.1.00.0811261739110.30769@pacific.mpi-cbg.de>
On Wed, Nov 26, 2008 at 5:40 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 26 Nov 2008, Ondrej Certik wrote:
>
>> I am also trying to make the example simpler. I tried to squash the
>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
>> fails after squashing about 600 commits. Still investigating.
>
> 1500... wow.
>
> The best idea would probably be to just "edit" the first, delete the rest
> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
> the command line (when git rebase stops after the "edit" command).
That worked, thanks! My original repo:
A -- B -- ... --- D --- E --- ...
where E and the rest of the commits (there are branches and merges in
there) are the ones that I need to preserve, but all the commits
between B and D can be squashed (~1500 of them). So I created a
branch:
A -- B -- ... --- D
then squashed the commits using the technique you described above, so
now I have:
A -- BD --
and now I would like to append "E -- ..." to it -- is there any way to
do that? I tried rebase, but that destroys all the branches and merges
and those are necessary to reproduce the fast-export bug.
>
> rebase -i was _never_ meant for such _massive_ interactions; that's just
> too much for a shell script.
In fact, I think it would work, but there is probably another bug,
that I am hitting, maybe due to whitespace problems --- in the
original repository, the patches are linear, but when I create a
branch before the failing patch and then cherry-pick it (that should
work), it fails and creates conflicts. The same behavior is with git
rebase. So I'll investigate more and report it in a separate thread,
as it is not related to fast-export.
Ondrej
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: David Brown @ 2008-11-26 17:15 UTC (permalink / raw)
To: Jeff King; +Cc: Santi Béjar, Nanako Shiraishi, git
In-Reply-To: <20081126133422.GA1761@coredump.intra.peff.net>
On Wed, Nov 26, 2008 at 08:34:23AM -0500, Jeff King wrote:
>> or to make the separation more evident:
>>
>> [master d9a5491] foo: bar
>
>Out of those suggestions, I find only the final one aesthetically
>acceptable. Nobody else has weighed in, so maybe they don't care. Or
>maybe they are just on vacation due to the (American) holiday.
Color certainly works well in the cases where that is available.
Otherwise, I prefer the above solution.
David
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Schindelin @ 2008-11-26 17:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Ondrej Certik, Git Mailing List, Fabian Seoane
In-Reply-To: <492D7CF5.1020202@drmicha.warpmail.net>
Hi,
On Wed, 26 Nov 2008, Michael J Gruber wrote:
> Looking at the source I suspect that fast-export fails to denote
> parenthood in the case of yet unmarked parents (last for-loop of
> handle_commit() in builtin_fast_export.c). But I don't really know that
> code at all.
I strongly doubt so. Noticed the use of has_unshown_parent(commit) in
both cases before calling handle_commit()?
In any case, here is a script that I wrote _long_ time ago, to be able to
reconstruct history from the output of "git rev-list --all --parents".
Maybe this helps you in reconstructing something that is handled
incorrectly by fast-export | fast-import, but is lighter than a full-blown
repository.
-- snip --
#!/bin/sh
# Given the output of git-rev-list, this reconstructs the DAG of the
history
i=0
tac | while read rev parents; do
let i=$i+1
echo $i > a1
git add a1
tree=$(git write-tree)
parents="$(for parent in $parents
do
echo -n "-p $(git rev-parse sp-$parent) "
done)"
commit=$(echo "$rev $i" | git commit-tree $tree $parents)
git tag sp-$rev $commit
done
-- snap --
Ciao,
Dscho
--
|
Ceci n'est pas une pipe
^ permalink raw reply
* [PATCH] t9129-git-svn-i18n-commitencoding: Make compare_svn_head_with() compatible with OSX sed
From: Marcel Koeppen @ 2008-11-26 16:51 UTC (permalink / raw)
To: gitster; +Cc: git
The sed call used in compare_svn_head_with() uses the + quantifier, which
is not supported in the OSX version of sed. It is replaced by the
equivalent \{1,\}.
Signed-off-by: Marcel Koeppen <git-dev@marzelpan.de>
---
t/t9129-git-svn-i18n-commitencoding.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t9129-git-svn-i18n-commitencoding.sh b/t/t9129-git-svn-i18n-commitencoding.sh
index 2848e46..938b7fe 100755
--- a/t/t9129-git-svn-i18n-commitencoding.sh
+++ b/t/t9129-git-svn-i18n-commitencoding.sh
@@ -16,7 +16,7 @@ compare_git_head_with () {
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
- sed -e 1,3d -e "/^-\+\$/d" >current &&
+ sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
--
1.6.0.4.771.gef3b3.dirty
^ permalink raw reply related
* Re: git fast-export | git fast-import doesn't work
From: Michael J Gruber @ 2008-11-26 16:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ondrej Certik, Michael J Gruber, Git Mailing List, Fabian Seoane
In-Reply-To: <alpine.DEB.1.00.0811261739110.30769@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 26.11.2008 17:40:
> Hi,
>
> On Wed, 26 Nov 2008, Ondrej Certik wrote:
>
>> I am also trying to make the example simpler. I tried to squash the
>> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
>> fails after squashing about 600 commits. Still investigating.
>
> 1500... wow.
>
> The best idea would probably be to just "edit" the first, delete the rest
> of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
> the command line (when git rebase stops after the "edit" command).
>
> rebase -i was _never_ meant for such _massive_ interactions; that's just
> too much for a shell script.
Or chop the DAG with grafts.
Removing the tags one by one I noticed that for several of them, removal
of the tag increases the number of commits on the connected DAG
component containing master (in the ex/imported repo), and that one
reaches the correct number with still a few tags left in there. Yet, the
topology is wrong in several places; I think all of them can be
attributed to missing parent info (which even creates new roots in some
places).
Looking at the source I suspect that fast-export fails to denote
parenthood in the case of yet unmarked parents (last for-loop of
handle_commit() in builtin_fast_export.c). But I don't really know that
code at all.
Michael
P.S.: That git repo itself is a product of
hg-fast-export|git-fast-import, right?
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Sixt @ 2008-11-26 16:35 UTC (permalink / raw)
To: Ondrej Certik
Cc: Michael J Gruber, Johannes Schindelin, Git Mailing List,
Fabian Seoane
In-Reply-To: <85b5c3130811260750y2e24436ye2426ccfc2f66071@mail.gmail.com>
Ondrej Certik schrieb:
> I am also trying to make the example simpler. I tried to squash the
> first uninteresting ~1500 commits into one, but "git rebase -i"
> uterrly fails after squashing about 600 commits. Still investigating.
Don't use rebase. Set a graft and rewrite the history:
$ echo $(git rev-parse HEAD) $(git rev-parse HEAD~1500) >> \
.git/info/grafts
Assuming "first 1500" means the "most recent 1500" commits. But you get
the idea. You can truncate history as well by omitting the second SHA1.
It's very convenient to keep gitk open and File->Reload after each graft
that you set.
When you're done with setting grafts:
$ git filter-branch -f --tag-name-filter cat -- --all
(You are doing this on a copy of your repository, don't you?)
-- Hannes
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Johannes Schindelin @ 2008-11-26 16:40 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Michael J Gruber, Git Mailing List, Fabian Seoane
In-Reply-To: <85b5c3130811260750y2e24436ye2426ccfc2f66071@mail.gmail.com>
Hi,
On Wed, 26 Nov 2008, Ondrej Certik wrote:
> I am also trying to make the example simpler. I tried to squash the
> first uninteresting ~1500 commits into one, but "git rebase -i" uterrly
> fails after squashing about 600 commits. Still investigating.
1500... wow.
The best idea would probably be to just "edit" the first, delete the rest
of the 1500, and then 'git read-tree -u -m <last-of-the-1500-commits>"' on
the command line (when git rebase stops after the "edit" command).
rebase -i was _never_ meant for such _massive_ interactions; that's just
too much for a shell script.
Ciao,
Dscho
^ permalink raw reply
* Re: French git user
From: Hannu Koivisto @ 2008-11-26 16:22 UTC (permalink / raw)
To: Johan Herland; +Cc: devel, git
In-Reply-To: <200811261123.56317.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Wednesday 26 November 2008, Nicolas Morey-Chaisemartin wrote:
>> Yes I say in french that git-foo is deprecated.
>> However I'm still using it in the following slides because people
>> have directly the good command to look at the man.
>> I know it's not really consistent but asI'd rahter keep it that way
>> and insist while presenting it, it should only be used for man pages.
>
> The man pages are also accessible _without_ using the "git-foo" form,
> either by doing "git foo --help" or "git help foo". I'd suggest using
> the "git foo" form, and using "git help foo" instead of "man git-foo".
Depending on the audience, one might want to mention that if you
are using a modern version of zsh as your shell and have activated
its run-help function (see
http://zsh.dotsrc.org/Doc/Release/zsh_24.html#SEC218), you can just
say
git foo -bar <M-h>
and you'll get git-foo manual page. When you exit man, you'll get
your command line back just like it was when you hit M-h. I think
it handles even "echo dum ; git foo <M-h>" kind of cases. You
can't live without it once you have tried it. Or the completion
with descriptions for options etc.
--
Hannu
^ permalink raw reply
* format-patch problem when using relative
From: Nikola Knežević @ 2008-11-26 16:12 UTC (permalink / raw)
To: git
Hi,
I have a subdirectory in my top-level directory, which I merged using
subtree strategy. I want to send my patches upstream, so I did
something like:
git format-patch -o patches -n --relative=click click/master myclick
This produced a bunch of files in patches directory, most of which are
empty. When I tried this --stdout, I had something like this:
[PATCH 8725/8846]
[PATCH 8726/8846]
[PATCH 8750/8846]
..
[PATCH 8845/8846]
So, it seems that format-patch was counting all patches, but only
printing the interesting ones.
I'm running git 1.6.0.1 on FreeBSD7/amd64.
PS. Please CC me, since I'm not on the list.
Cheers,
Nikola
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-26 15:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, Git Mailing List, Fabian Seoane
In-Reply-To: <492D6CC3.2050408@drmicha.warpmail.net>
On Wed, Nov 26, 2008 at 4:35 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Ondrej Certik venit, vidit, dixit 26.11.2008 11:18:
>> On Wed, Nov 26, 2008 at 10:35 AM, Ondrej Certik <ondrej@certik.cz> wrote:
>>> On Wed, Nov 26, 2008 at 1:14 AM, Johannes Schindelin
>>> <Johannes.Schindelin@gmx.de> wrote:
>>>> Hi,
>>>>
>>>> On Tue, 25 Nov 2008, Ondrej Certik wrote:
>>>>
>>>>> I would like to export our whole git repository to patches, and then
>>>>> reconstruct it again from scratch. Following the man page of "git
>>>>> fast-export":
>>>>>
>>>>> [...]
>>>>>
>>>>> However, the repository is very different to the original one. It
>>>>> contains only 191 patches:
>>>> Can you try again with a Git version that contains the commit
>>>> 2075ffb5(fast-export: use an unsorted string list for extra_refs)?
>>> I tried the next branch:
>>>
>>> $ git --version
>>> git version 1.6.0.4.1060.g9433b
>>>
>>> that contains the 2075ffb5 patch. I haven't observed any change ---
>>> the "git log" still only shows 191 commits (git log --all shows
>>> everything).
>>
>> I deleted all tags and then fast-exported and imported, now all the
>> commits show in "git log", however, the patches are wrongly connected.
>> Basically, both repositories are identical (including hashes) up to
>> this commit:
>>
>> d717177d4 (fixed downloads instructions in the README and a typo)
>>
>> However, the original repo (sympy-full-history-20081023) contains 3
>> children at this commit:
>
> There's some nice 3 way branching and double 2 way merging going on. I
> cut out the interesting part of the graph, making d717177d4 and
> 6e869485f parentless. The resulting mini DAG is reproduced correctly by
> export|import, even with -M -C.
I am also trying to make the example simpler. I tried to squash the
first uninteresting ~1500 commits into one, but "git rebase -i"
uterrly fails after squashing about 600 commits. Still investigating.
Ondrej
^ 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