* jgit, MutableInteger vs AtomicInteger
From: Vasyl Vavrychuk @ 2008-11-25 13:54 UTC (permalink / raw)
To: git
Hi,
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.
Regards,
V. V.
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: Kristian Høgsberg @ 2008-11-25 15:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491DE6CC.6060201@op5.se>
On Fri, 2008-11-14 at 21:59 +0100, Andreas Ericsson wrote:
> I've been working quite a lot on git -> libgit2 code moving,
> but the licensing stuff is a bit depressing, as I can't know
> if the work I'm doing is for nothing or not.
>
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?
>
> I'm planning on writing a tool for this that will have "ok",
> "not ok" and "ask-each-patch" as options.
>
> The list of people whose position I know is rather short.
> Please correct me if you're on it and would like not to be.
> Junio C. Hamano ask
> Johannes Schindelin ok
> Shawn O. Pearce ok
> Andreas Ericsson ok
> Pierre Habouzit ok
> Brian Gernhardt ok
>
>
> I've put everyone who "owns" more than 500 lines of code
> on the bcc list, figuring your permission is important
> but that you don't want the hundreds (well, one can hope)
> of emails from people saying "ok". The list of major owners
> was generated with "git showners *.c" in a worktree from
> the next branch of git.git.
You're welcome to use any of the code I've written under the GPL +
exception license, though most of it is probably not that useful, as
it's mostly porting shell commands to builtins. I'm very happy to see
this effort start up, as I've been tempted to do something similar
myself :)
cheers,
Kristian
^ permalink raw reply
* Re: French git user
From: Christian MICHON @ 2008-11-25 15:41 UTC (permalink / raw)
To: Jean-Francois Veillette; +Cc: devel, git
In-Reply-To: <C10BF28F-3466-4908-A5ED-6FB68FBEC3A2@yahoo.ca>
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.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* [PATCH] Invoke "gc --auto" from git commit
From: Jean-Luc Herren @ 2008-11-25 16:15 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
This feature was lost during the port of git commit to C.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
---
builtin-commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 591d16b..209805b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -947,6 +947,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
struct commit_list *parents = NULL, **pptr = &parents;
struct stat statbuf;
int allow_fast_forward = 1;
+ const char *argv_gc_auto[] = { "gc", "--auto", NULL };
git_config(git_commit_config, NULL);
@@ -1068,6 +1069,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
"not exceeded, and then \"git reset HEAD\" to recover.");
rerere();
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
run_hook(get_index_file(), "post-commit", NULL);
if (!quiet)
print_summary(prefix, commit_sha1);
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-11-25 16:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <492BA998.5050106@viscovery.net>
Johannes Sixt wrote:
> Marcel M. Cary schrieb:
>> * Change "git rev-parse --show-cdup" to print a full path instead of
>> a series of "../" when it prints anything
>
> http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88562
>
> I don't see that you bring in any new arguments.
To be clear, as mentioned here:
http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88573
I'm not talking about a situation where the symlink is in the working
tree pointing outwards. I'm talking about a symlink outside pointing
in. And as mentioned later in that thread, the --work-tree workaround
doesn't actually work.
One new thing I have to add is that the reason --show-cdup prints a
correct path but pull fails is because it's the *shell* who
misinterprets the path. So telling git rev-parse where the work-tree is
helps nothing. It already knows.
http://thread.gmane.org/gmane.comp.version-control.git/88557/focus=88581
So far I've seen no response to the idea, which Yves mentions, about
trying to restrict the absolute path behavior to times when bash would
interpret the "../" incorrectly.
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`", and I
don't really understand the scenario where this would be a performance
concern; I think I haven't found a particular discussion that several
people have referenced. Perhaps I should prepare a patch for that so I
can verify that it works as I expect and so we have something more
concrete to discuss?
Any tips on how to follow the reference
7vk5sly3h9.fsf@assigned-by-dhcp.cox.net in the first url above? It
looks to be about performance. Message-Id seems to not be indexed for
searching.
Marcel
^ permalink raw reply
* Re: [PATCH] rev-parse: Fix shell scripts whose cwd is a symlink into a git work-dir
From: Johannes Sixt @ 2008-11-25 16:30 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: gitster, git
In-Reply-To: <492C24D4.1010306@oak.homeunix.org>
Marcel M. Cary schrieb:
> Any tips on how to follow the reference
> 7vk5sly3h9.fsf@assigned-by-dhcp.cox.net in the first url above? It
> looks to be about performance. Message-Id seems to not be indexed for
> searching.
http://mid.gmane.org/7vk5sly3h9.fsf@assigned-by-dhcp.cox.net
-- Hannes
^ 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
* 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
* 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: 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: [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: 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: 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 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: 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: 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: [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: [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: 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: 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
* 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: 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
* 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: 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
* 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
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