* Re: git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-25 23:39 UTC (permalink / raw)
To: Miklos Vajna
Cc: Michael J Gruber, Git Mailing List, Fabian Seoane,
Shawn O. Pearce, Johannes Schindelin
In-Reply-To: <20081125204108.GF4746@genesis.frugalware.org>
On Tue, Nov 25, 2008 at 9:41 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Nov 25, 2008 at 06:31:41PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
>> I don't know, I just noticed that turning on rename and copy detection
>> makes git-fast-import crash, which shouldn't happen either. Something's
>> not right here. CC'ing the authors of im- and export.
>
> Could you please write a testcase that reproduces your problem?
>
>> Why export|import directly to git?
>
> I guess he did not know about filter-branch. :)
I know about filter-branch (but I am not sure it can do what I want).
I made a mistake of not explaining what I want, instead I suggested (a
possibly wrong) solution. I want to export the whole git repository as
a set of human readable patches, that can be assembled back into a git
repository (with the same hashes as the original one) if needed. The
reason I want that is that if we later decide to switch to another
VCS, we have all the information to reproduce the repository. Another
reason is to be sure that we know all the sources that are needed to
construct the repository, e.g. that there are no binary blobs
(possibly containing malicious code). Another reason I want that is to
be able to rewrite the history, in particular, we have one Mercurial
repository with some old history and another Mercurial history with a
newer history and I just want to concatenate them together into one
git repository.
In each case I know several workarounds, but if there is a way to just
convert the whole git repository into a set of patches and (and be
able to convert everything back including the same hashes), then it'd
be awesome.
See also this thread why people want this (and I assumed git can do
this from this thread):
http://groups.google.com/group/sage-devel/browse_thread/thread/7b116d902ee20d9c/
Thanks,
Ondrej
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Jeff King @ 2008-11-25 23:25 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20081126064906.6117@nanako3.lavabit.com>
On Wed, Nov 26, 2008 at 06:49:06AM +0900, Nanako Shiraishi wrote:
> While I think the way recent "git commit" displays the commit you just
> created is very helpful, I often find the double quotes around the
> message unnecessary and sometimes even confusing. I just made a
> commit and saw this message:
>
> [master]: created d9a5491: "Show "standard deviation" column in table 3"
While I do think that typographically the embedded quotes look awful, I
find that the quotes do help separate the commit subject from the other
text when there are colons in the subject. IOW, I think that
[master]: created d9a5491: foo: bar
is harder to read than
[master]: created d9a5491: "foo: bar"
And 47% of commits in git.git have a colon (only 7% have a double
quote).
So I sympathize with the desire to remove the quotes, as they look bad
and are obviously not too rare. But I'd like to find a solution which
maintains a better visual separation between the subject and the other
text than simply removing them.
-Peff
^ permalink raw reply
* Re: git-svn and svn branches
From: Eric Wong @ 2008-11-25 23:08 UTC (permalink / raw)
To: Ryan Phillips; +Cc: git
In-Reply-To: <20081121195835.GA12141@athena.lan>
Ryan Phillips <ryan@trolocsis.com> wrote:
> I followed the following instructions on adding a remote svn branch to my
> local git-svn repository. http://www.dmo.ca/blog/20070608113513
>
> Are these still accurate?
>
> I started the repository with
> # git svn init [url/trunk]`
> # cd project.git
> # git svn fetch -r[HEAD revision]
> which works fine. I added something like Snippet 1 to the .git/config and
> issued a `git svn fetch -r[HEAD revision of the branch]` and nothing
> happens. It takes git-svn a few seconds to run, but the git-remote svn
> branch doesn't get initialized.
>
> Does this procedure only work with a full mirror of a git-svn repository?
> or perhaps I'm doing something wrong. Any help would be appreciated.
>
> Thanks,
> Ryan
>
> Snippet 1
> =========
>
> [svn-remote "svn34"]
> url = svn+ssh://your-server/home/svn/project-name/branches/3.4.x
> fetch = :refs/remotes/git-svn-3.4
Try this:
git svn fetch -i svn34
It's been a while since I've used this, but I believe a test
case covers it so it probably still works :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/4] builtin-clone: fix a memory leak in cmd_clone()
From: Miklos Vajna @ 2008-11-25 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabbpok6v.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Sun, Nov 23, 2008 at 07:51:36PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> Can't this be done much earlier? This variable can potentially be
> assigned to work_tree, but after we set up the atexit handler neither dir
> nor work_tree are not used (it is a bit hard to see as this function
> itself is a bit too big to be maintainable).
Hm, reading the code again I think you should just drop 1/4.
work_tree is a pointer to dir, and junk_work_tree is a pointer to
work_tree. junk_work_tree is used in the signal handler, so it has to be
allocated during the whole clone.
I guess it was just an accident that my patch passed the tests.
Sorry for the mistake.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git svn rebase creates some commits with empty author, commiter and date fields
From: Eric Wong @ 2008-11-25 22:06 UTC (permalink / raw)
To: Peter Kirk; +Cc: git
In-Reply-To: <200811181121.18264.peter.kirk@gmx.de>
Peter Kirk <peter.kirk@gmx.de> wrote:
> Hi there,
>
> I am using git version 1.6.0.3, which I compiled myself from sources on my
> linux/amd64 box which runns kubuntu 8.10.
>
> Now, when I do "git svn clone" to retrieve the entire history from the svn
> server then everything works fine. Then I start working with this, commit some
> myself, and run "git svn rebase" frequently. What happens (and I don't see the
> pattern) is that *some* commits that are retrieved via "git svn rebase" are
> broken...they don't contain a valid author field, the date is at 1970 and, most
> importantly (for me) the commit message is empty except for the "git-svn-id:"
> line that "git svn" adds automatically. The diff is fine, and I can still use
> the checkout fine...but I cannot view the log-message/author/date of some
> commits, which becomes tiresome quickly.
> The only way to "fix" these broken commits is to do a clean "git svn clone",
> but as new commits are pulled via "git svn rebase", my repository will again
> become polluted with broken commits.
Weird.
Does this happen on other repositories you may use as well? Do you know
of any strange hooks or otherwise non-standard setup with the SVN
server?
Which version of the SVN perl bindings are you using?
--
Eric Wong
^ permalink raw reply
* Re: Extra pair of double quotes in "git commit" output?
From: Junio C Hamano @ 2008-11-25 22:02 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20081126064906.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> While I think the way recent "git commit" displays the commit you just created is very helpful, I often find the double quotes around the message unnecessary and sometimes even confusing. I just made a commit and saw this message:
>
> [master]: created d9a5491: "Show "standard deviation" column in table 3"
>
> The colon after the shortened commit SHA1 is enough to signal that it will talk about a different piece of information on the rest of the line. I think the extra double quotes can be dropped safely:
>
> [master]: created d9a5491: Show "standard deviation" column in table 3
>
> and it will make the output shorter by two columns, more pretty, and does not lose the clarity.
[offtopic. Please wrap your text at a reasonable width around 70 columns]
Like this?
It might break some existing tests (I didn't check), but I think that is a
sensible thing to do.
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git c/builtin-commit.c w/builtin-commit.c
index 591d16b..654bfbe 100644
--- c/builtin-commit.c
+++ w/builtin-commit.c
@@ -881,7 +881,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
{
struct rev_info rev;
struct commit *commit;
- static const char *format = "format:%h: \"%s\"";
+ static const char *format = "format:%h: %s";
unsigned char junk_sha1[20];
const char *head = resolve_ref("HEAD", junk_sha1, 0, NULL);
^ permalink raw reply related
* Extra pair of double quotes in "git commit" output?
From: Nanako Shiraishi @ 2008-11-25 21:49 UTC (permalink / raw)
To: git
While I think the way recent "git commit" displays the commit you just created is very helpful, I often find the double quotes around the message unnecessary and sometimes even confusing. I just made a commit and saw this message:
[master]: created d9a5491: "Show "standard deviation" column in table 3"
The colon after the shortened commit SHA1 is enough to signal that it will talk about a different piece of information on the rest of the line. I think the extra double quotes can be dropped safely:
[master]: created d9a5491: Show "standard deviation" column in table 3
and it will make the output shorter by two columns, more pretty, and does not lose the clarity.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: How to hide a git repository?
From: Junio C Hamano @ 2008-11-25 21:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Thomas Koch, Daniel Barkalow, Gary Yang, git
In-Reply-To: <200811252219.38530.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Tue, 25 Nov 2008, Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > If you have something more fancy, check out newest gitweb and take a
>> > look at gitweb/INSTALL: you can now, thanks to commit dd7f5f1 by
>> > Alexander Gavrilov, see
>> > http://permalink.gmane.org/gmane.comp.version-control.git/99962
>>
>> Somehow I had an impression that you weren't enthused about that
>> patch.
>
> I didn't like original version, but quite like the one that got in
> git.git: very flexible and nonintrusive. I have acked it, haven't I?
Yeah, indeed you did. Thanks.
^ permalink raw reply
* Re: Unable to clone empty repositories remotely
From: Christian MICHON @ 2008-11-25 21:33 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <837i6rplcd.fsf@kalahari.s2.org>
On Tue, Nov 25, 2008 at 10:05 PM, Hannu Koivisto <azure@iki.fi> wrote:
> Greetings,
>
> mkdir test
> cd test
> git init --bare --shared=group
> cd ..
> git clone test test2
>
> works, though clone says it cannot checkout, which is expected.
> This is nevertheless very useful when you create a shared
> repository for a new project; you can then create a personal clone
> and start adding stuff to it. If, however, you normally work on
> another machine and want to have your personal clone there
> (i.e. git clone ssh://therepomachine/somewhere/test), cloning
> doesn't work at all (tested with git 1.6.0.3.525.ge32c2 in Cygwin):
>
> Initialized empty Git repository in /cygdrive/c/temp/test/.git/
> fatal: no matching remote head
>
> This behaviour isn't documented by either git-init(1) or
> git-clone(1). I think it would be very convenient if this worked
> for the reasons mentioned above. I'm sure you could create your
> personal repository with git init and then git remote add the
> shared repository to it but that's much more difficult.
>
> --
> Hannu
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
how about creating at least 1 empty commit before any cloning ?
wouldn't this solve the problem ?
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: How to hide a git repository?
From: Jakub Narebski @ 2008-11-25 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Koch, Daniel Barkalow, Gary Yang, git
In-Reply-To: <7vprkjjz79.fsf@gitster.siamese.dyndns.org>
On Tue, 25 Nov 2008, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > If you have something more fancy, check out newest gitweb and take a
> > look at gitweb/INSTALL: you can now, thanks to commit dd7f5f1 by
> > Alexander Gavrilov, see
> > http://permalink.gmane.org/gmane.comp.version-control.git/99962
>
> Somehow I had an impression that you weren't enthused about that
> patch.
I didn't like original version, but quite like the one that got in
git.git: very flexible and nonintrusive. I have acked it, haven't I?
--
Jakub Narebski
Poland
^ permalink raw reply
* Unable to clone empty repositories remotely
From: Hannu Koivisto @ 2008-11-25 21:05 UTC (permalink / raw)
To: git
Greetings,
mkdir test
cd test
git init --bare --shared=group
cd ..
git clone test test2
works, though clone says it cannot checkout, which is expected.
This is nevertheless very useful when you create a shared
repository for a new project; you can then create a personal clone
and start adding stuff to it. If, however, you normally work on
another machine and want to have your personal clone there
(i.e. git clone ssh://therepomachine/somewhere/test), cloning
doesn't work at all (tested with git 1.6.0.3.525.ge32c2 in Cygwin):
Initialized empty Git repository in /cygdrive/c/temp/test/.git/
fatal: no matching remote head
This behaviour isn't documented by either git-init(1) or
git-clone(1). I think it would be very convenient if this worked
for the reasons mentioned above. I'm sure you could create your
personal repository with git init and then git remote add the
shared repository to it but that's much more difficult.
--
Hannu
^ permalink raw reply
* Re: How to hide a git repository?
From: Junio C Hamano @ 2008-11-25 21:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Thomas Koch, Daniel Barkalow, Gary Yang, git
In-Reply-To: <m3skpfk1mp.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> If you have something more fancy, check out newest gitweb and take a
> look at gitweb/INSTALL: you can now, thanks to commit dd7f5f1 by
> Alexander Gavrilov, see
> http://permalink.gmane.org/gmane.comp.version-control.git/99962
Somehow I had an impression that you weren't enthused about that patch.
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Miklos Vajna @ 2008-11-25 20:41 UTC (permalink / raw)
To: Michael J Gruber
Cc: Ondrej Certik, Git Mailing List, Fabian Seoane, Shawn O. Pearce,
Johannes Schindelin
In-Reply-To: <492C367D.3030209@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 448 bytes --]
On Tue, Nov 25, 2008 at 06:31:41PM +0100, Michael J Gruber <git@drmicha.warpmail.net> wrote:
> I don't know, I just noticed that turning on rename and copy detection
> makes git-fast-import crash, which shouldn't happen either. Something's
> not right here. CC'ing the authors of im- and export.
Could you please write a testcase that reproduces your problem?
> Why export|import directly to git?
I guess he did not know about filter-branch. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] tg export: implement skipping empty patches for quilt mode
From: Uwe Kleine-König @ 2008-11-25 20:54 UTC (permalink / raw)
To: martin f krafft; +Cc: git, Petr Baudis
In-Reply-To: <20081125084531.GA13122@lapse.rw.madduck.net>
On Tue, Nov 25, 2008 at 09:45:31AM +0100, martin f krafft wrote:
> also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.11.24.2256 +0100]:
> > +skipempty=false
>
> Any reason not to make it default? Why do we even need this option?
> Do empty quilt files ever have a purpose?
My first implementation did it unconditionally because I think this
should be the default, too. Then I found in the tg-export section of
README:
TODO: -n option to prevent exporting of empty patches
I'm not sure if this was meant for collapse or quilt or both. I assumed
the last and implemented -n as suggested.
Best regards
Uwe
^ permalink raw reply
* Re: [PATCH] tg export: implement skipping empty patches for quilt mode
From: martin f krafft @ 2008-11-25 8:45 UTC (permalink / raw)
To: Uwe Kleine-König, git, Petr Baudis
In-Reply-To: <1227563810-5426-1-git-send-email-u.kleine-koenig@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 633 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.11.24.2256 +0100]:
> +skipempty=false
Any reason not to make it default? Why do we even need this option?
Do empty quilt files ever have a purpose?
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"the husbands of very beautiful women
belong to the criminal classes."
-- oscar wilde
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: How to hide a git repository?
From: Jakub Narebski @ 2008-11-25 20:10 UTC (permalink / raw)
To: Thomas Koch; +Cc: Daniel Barkalow, Gary Yang, git
In-Reply-To: <200811252001.37259.thomas@koch.ro>
Thomas Koch <thomas@koch.ro> writes:
> Am Tuesday 25 November 2008 19:38:02 schrieb Daniel Barkalow:
> > On Mon, 24 Nov 2008, Gary Yang wrote:
> > > Do I have to create two git servers? One is for public to download the
> > > released code. For example: gitpub.mycompany.com:/pub/linux/kernel.
> >
> > The public can't generally use this URL, because it's an ssh URL, and they
> > won't be able to connect with ssh. They can only really use
> > git://gitpub.mycompany.com/pub/linux/kernel or something similar.
> >
> > The normal pattern is to have R/W access with ssh and anonymous read
> > access via git://...; you can then have multiple repositories on the same
> > host, with the git server only serving the public one. All of them will be
> > accessible to the ssh methods (restricted by the user's UNIX permissions
> > on the files in those directories).
To control access via SSH protocol (which can be used both for
fetching and for pushing), you can either configure accounts and
user/groups permissions on repository directories, or you can use
external tool like ssh_acl or Gitosis.
To control access via HTTP you can employ authorization and
authentication from your web server; for push this would be matter of
setting up WebDAV.
To control access via anonymous git:// protocol, you can use whitelist
and blacklist mechanism built in git-daemon; by default only
repositories with git-daemon-export-ok in them (in .git) are exported,
if I understand correctly.
Additionally, if protocol is authenticated you can use hooks mechanism
like example contrib/hooks/update-paranoid to restrict access (and
with finer granularity too).
> Do you now of a way to show public repos with gitweb to the public and
> private repos to the staff with the same gitweb installation?
You can quite simply restrict access to some directories/repositories,
or the fact that they are listed in list of all projects for _all_
clients quite easily (see description of GITWEB_EXPORT_OK in
gitweb/README and gitweb/INSTALL).
If you have something more fancy, check out newest gitweb and take a
look at gitweb/INSTALL: you can now, thanks to commit dd7f5f1 by
Alexander Gavrilov, see
http://permalink.gmane.org/gmane.comp.version-control.git/99962
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: jgit, MutableInteger vs AtomicInteger
From: Shawn O. Pearce @ 2008-11-25 19:19 UTC (permalink / raw)
To: Vasyl Vavrychuk; +Cc: git
In-Reply-To: <loom.20081125T134459-650@post.gmane.org>
Vasyl Vavrychuk <vvavrychuk@gmail.com> wrote:
> I've just started browsing jgit sources and an obvious question arise.
> I didn't found such question in mail list and decided to ask the community.
>
> I don't see reason behind creating own mutable integer container because we
> have java.util.concurrent.atomic.AtomicInteger with methods
> public final int get()
> public final void set(int i)
>
> And that is what we want.
Eh, its sort-of what we want.
The MutableInteger used in jgit is used instead of this C construct:
int x;
call_something(&x);
call_something_else(&x);
... now use x ...
In other words it is stack allocated, passed into methods for them
to read and/or update, and then later used in the caller.
AtomicInteger does in fact have get and set methods, providing what
would seem to be the same operation. But if you read the source
code you'll see that the get and set methods operate against a
volatile int. IIRC the volatile tag requires that the JRE must
not cache the value in a register.
If you look again at how MutableInteger is used, we never touch the
value outside of a single thread. The volatile tag on the field
isn't necessary. It may actually make it harder for the JIT to
produce tight machine code. Where we use MutableInteger is the
depths of revision traversal and commit parsing, it *must* be fast.
Also, there's the simple fact that I forgot about AtomicInteger,
and it took me less time to code MutableInteger than it did to look
to see if the JRE had something already. ;-)
--
Shawn.
^ permalink raw reply
* Re: How to hide a git repository?
From: Daniel Barkalow @ 2008-11-25 19:08 UTC (permalink / raw)
To: Thomas Koch; +Cc: Gary Yang, git
In-Reply-To: <200811252001.37259.thomas@koch.ro>
On Tue, 25 Nov 2008, Thomas Koch wrote:
> Do you now of a way to show public repos with gitweb to the public and
> private repos to the staff with the same gitweb installation?
I don't really know much about gitweb, but I'd expect that you can have
the same physical machine, the same gitweb executable, the same
apache, different virtual hosts, and different configurations for each
virtual host. Without having different URLs in some way, there's no way
for the system to cause web browsers of staff members to authenticate
themselves in order to reveal the private repos.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: How to hide a git repository?
From: Thomas Koch @ 2008-11-25 19:01 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Gary Yang, git
In-Reply-To: <alpine.LNX.1.00.0811251327480.19665@iabervon.org>
Am Tuesday 25 November 2008 19:38:02 schrieb Daniel Barkalow:
> On Mon, 24 Nov 2008, Gary Yang wrote:
> > Do I have to create two git servers? One is for public to download the
> > released code. For example: gitpub.mycompany.com:/pub/linux/kernel.
>
> The public can't generally use this URL, because it's an ssh URL, and they
> won't be able to connect with ssh. They can only really use
> git://gitpub.mycompany.com/pub/linux/kernel or something similar.
>
> The normal pattern is to have R/W access with ssh and anonymous read
> access via git://...; you can then have multiple repositories on the same
> host, with the git server only serving the public one. All of them will be
> accessible to the ssh methods (restricted by the user's UNIX permissions
> on the files in those directories).
>
> -Daniel
> *This .sig left intentionally blank*
> --
Do you now of a way to show public repos with gitweb to the public and
private repos to the staff with the same gitweb installation?
Best regards,
--
Thomas Koch, Software Developer
http://www.koch.ro
Young Media Concepts GmbH
Sonnenstr. 4
CH-8280 Kreuzlingen
Switzerland
Tel +41 (0)71 / 508 24 86
Fax +41 (0)71 / 560 53 89
Mobile +49 (0)170 / 753 89 16
Web www.ymc.ch
^ permalink raw reply
* Re: How to hide a git repository?
From: Daniel Barkalow @ 2008-11-25 18:38 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <900638.56188.qm@web37904.mail.mud.yahoo.com>
On Mon, 24 Nov 2008, Gary Yang wrote:
> Do I have to create two git servers? One is for public to download the
> released code. For example: gitpub.mycompany.com:/pub/linux/kernel.
The public can't generally use this URL, because it's an ssh URL, and they
won't be able to connect with ssh. They can only really use
git://gitpub.mycompany.com/pub/linux/kernel or something similar.
The normal pattern is to have R/W access with ssh and anonymous read
access via git://...; you can then have multiple repositories on the same
host, with the git server only serving the public one. All of them will be
accessible to the ssh methods (restricted by the user's UNIX permissions
on the files in those directories).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
From: Junio C Hamano @ 2008-11-25 18:17 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: Johannes Sixt, git
In-Reply-To: <492C24D4.1010306@oak.homeunix.org>
"Marcel M. Cary" <marcel@oak.homeunix.org> writes:
> Nor have I seen a response to the idea of correcting the shell's
> behavior in cd_to_toplevel, for example by adding a "cd `pwd`",...
I think you probably could fool the shell by unsetting PWD or something
silly like that (or "cd -P" which may not be supported by non POSIX shells
but I suspect the ones we care about do support it).
Doing a 'cd "$(pwd)"' inside cd_to_toplevel would be a less objectionable
and arguably more portable workaround for the case where you have a
symlink pointing into somewhere in your work tree.
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Peter Baumann @ 2008-11-25 17:34 UTC (permalink / raw)
To: Ondrej Certik; +Cc: Git Mailing List, Fabian Seoane
In-Reply-To: <85b5c3130811250844u498fbb97m9d1aef6e1397b8c7@mail.gmail.com>
On Tue, Nov 25, 2008 at 05:44:28PM +0100, Ondrej Certik wrote:
> Hi,
>
> 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":
>
Perhabs you are looking for git filter-branch, because it seems you want
to change the history in some way (e.g. remove a wrongly committed file)?
Nevertheless, I expect your shown commands below to procude the same
repo again, so you might be on something ...
-Peter
> $ git clone git://git.sympy.org/sympy-full-history-20081023.git
> $ cd sympy-full-history-20081023
> $ git fast-export --all --export-marks=marks > patches
> $ cd ..
> $ mkdir sympy-new
> $ cd sympy-new
> $ git init
> $ git fast-import --export-marks=marks < ../sympy-full-history-20081023/patches
> git-fast-import statistics:
> ---------------------------------------------------------------------
> Alloc'd objects: 25000
> Total objects: 21355 ( 144 duplicates )
> blobs : 8009 ( 0 duplicates 4529 deltas)
> trees : 10627 ( 144 duplicates 9189 deltas)
> commits: 2719 ( 0 duplicates 0 deltas)
> tags : 0 ( 0 duplicates 0 deltas)
> Total branches: 21 ( 26 loads )
> marks: 1048576 ( 10728 unique )
> atoms: 726
> Memory total: 2880 KiB
> pools: 2098 KiB
> objects: 781 KiB
> ---------------------------------------------------------------------
> pack_report: getpagesize() = 4096
> pack_report: core.packedGitWindowSize = 33554432
> pack_report: core.packedGitLimit = 268435456
> pack_report: pack_used_ctr = 40706
> pack_report: pack_mmap_calls = 2791
> pack_report: pack_open_windows = 1 / 2
> pack_report: pack_mapped = 26177739 / 35513414
> ---------------------------------------------------------------------
>
>
>
> However, the repository is very different to the original one. It
> contains only 191 patches:
>
> $ git log --pretty=oneline | wc -l
> 191
>
> and it only contains couple files. Compare this with the original repository:
>
> $ git log --pretty=oneline | wc -l
> 2719
>
> What am I doing wrong? Is there some other way to do it? I also tried
> "git format-patch" and "git am" and that almost works, only it changes
> hashes. Is there some way to tell "git am" to preserve the hash?
>
> Thanks,
> Ondrej
^ permalink raw reply
* Re: git fast-export | git fast-import doesn't work
From: Michael J Gruber @ 2008-11-25 17:31 UTC (permalink / raw)
To: Ondrej Certik
Cc: Git Mailing List, Fabian Seoane, Shawn O. Pearce,
Johannes Schindelin
In-Reply-To: <85b5c3130811250844u498fbb97m9d1aef6e1397b8c7@mail.gmail.com>
Ondrej Certik venit, vidit, dixit 25.11.2008 17:44:
> Hi,
>
> 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":
>
> $ git clone git://git.sympy.org/sympy-full-history-20081023.git
> $ cd sympy-full-history-20081023
> $ git fast-export --all --export-marks=marks > patches
> $ cd ..
> $ mkdir sympy-new
> $ cd sympy-new
> $ git init
> $ git fast-import --export-marks=marks < ../sympy-full-history-20081023/patches
> git-fast-import statistics:
> ---------------------------------------------------------------------
> Alloc'd objects: 25000
> Total objects: 21355 ( 144 duplicates )
> blobs : 8009 ( 0 duplicates 4529 deltas)
> trees : 10627 ( 144 duplicates 9189 deltas)
> commits: 2719 ( 0 duplicates 0 deltas)
> tags : 0 ( 0 duplicates 0 deltas)
> Total branches: 21 ( 26 loads )
> marks: 1048576 ( 10728 unique )
> atoms: 726
> Memory total: 2880 KiB
> pools: 2098 KiB
> objects: 781 KiB
> ---------------------------------------------------------------------
> pack_report: getpagesize() = 4096
> pack_report: core.packedGitWindowSize = 33554432
> pack_report: core.packedGitLimit = 268435456
> pack_report: pack_used_ctr = 40706
> pack_report: pack_mmap_calls = 2791
> pack_report: pack_open_windows = 1 / 2
> pack_report: pack_mapped = 26177739 / 35513414
> ---------------------------------------------------------------------
>
>
>
> However, the repository is very different to the original one. It
> contains only 191 patches:
>
> $ git log --pretty=oneline | wc -l
> 191
>
> and it only contains couple files. Compare this with the original repository:
>
> $ git log --pretty=oneline | wc -l
> 2719
I get the same stats (with the dups) but a perfect rev count, when I use
git log --all. The reason is that the history in the imported repo is
disconnected at various places (at tagging commits)! Your command counts
only the revs backwards to the first "disconnection".
So, the real issue is: Why has the result these cuts in the history?
I don't know, I just noticed that turning on rename and copy detection
makes git-fast-import crash, which shouldn't happen either. Something's
not right here. CC'ing the authors of im- and export.
BTW: Maybe you can accomplish what you want with different means? Why
export|import directly to git?
Michael
--
git 1.6.0.4.608.ga9645
^ permalink raw reply
* Re: French git user
From: Nicolas Morey-Chaisemartin @ 2008-11-25 17:00 UTC (permalink / raw)
Cc: Jean-Francois Veillette, git
In-Reply-To: <46d6db660811250741w54d34062w7766efd135c457b8@mail.gmail.com>
Christian MICHON a écrit :
> On Tue, Nov 25, 2008 at 2:38 PM, Jean-Francois Veillette
> <jean_francois_veillette@yahoo.ca> wrote:
>
>> I'll probably need to do the same here (Montréal, Qc), so if you can share
>> your slides (or else), that would be nice.
>>
>> Merci ! (thanks),
>>
>> - jfv
>>
>>
>
> you'll need to ask Nicolas. what I did was to provide feedback to his
> slides only (done).
> it's up to him to share his work or not.
>
>
I'd gladly share it, I just have to check my company policy.
I asked my boss tonight so I'll get an answer by tomorrow and post it on
a ftp somewhere, if I can share it
Nicolas
^ permalink raw reply
* git fast-export | git fast-import doesn't work
From: Ondrej Certik @ 2008-11-25 16:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Fabian Seoane
Hi,
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":
$ git clone git://git.sympy.org/sympy-full-history-20081023.git
$ cd sympy-full-history-20081023
$ git fast-export --all --export-marks=marks > patches
$ cd ..
$ mkdir sympy-new
$ cd sympy-new
$ git init
$ git fast-import --export-marks=marks < ../sympy-full-history-20081023/patches
git-fast-import statistics:
---------------------------------------------------------------------
Alloc'd objects: 25000
Total objects: 21355 ( 144 duplicates )
blobs : 8009 ( 0 duplicates 4529 deltas)
trees : 10627 ( 144 duplicates 9189 deltas)
commits: 2719 ( 0 duplicates 0 deltas)
tags : 0 ( 0 duplicates 0 deltas)
Total branches: 21 ( 26 loads )
marks: 1048576 ( 10728 unique )
atoms: 726
Memory total: 2880 KiB
pools: 2098 KiB
objects: 781 KiB
---------------------------------------------------------------------
pack_report: getpagesize() = 4096
pack_report: core.packedGitWindowSize = 33554432
pack_report: core.packedGitLimit = 268435456
pack_report: pack_used_ctr = 40706
pack_report: pack_mmap_calls = 2791
pack_report: pack_open_windows = 1 / 2
pack_report: pack_mapped = 26177739 / 35513414
---------------------------------------------------------------------
However, the repository is very different to the original one. It
contains only 191 patches:
$ git log --pretty=oneline | wc -l
191
and it only contains couple files. Compare this with the original repository:
$ git log --pretty=oneline | wc -l
2719
What am I doing wrong? Is there some other way to do it? I also tried
"git format-patch" and "git am" and that almost works, only it changes
hashes. Is there some way to tell "git am" to preserve the hash?
Thanks,
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