* Re: [PATCH] Show submodules as modified when they contain a dirty work tree
From: Jens Lehmann @ 2010-01-14 21:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Johannes Schindelin, Shawn O. Pearce,
Heiko Voigt, Lars Hjemli
In-Reply-To: <7v6375lkpj.fsf@alter.siamese.dyndns.org>
Am 13.01.2010 23:10, schrieb Junio C Hamano:
> And a patch to add:
>
>>> * It doesn't give detailed output when doing a "git diff* -p" with or
>>> without the --submodule option. It should show something like
>>>
>>> diff --git a/sub b/sub
>>> index 5431f52..3f35670 160000
>>> --- a/sub
>>> +++ b/sub
>>> @@ -1 +1 @@
>>> -Subproject commit 5431f529197f3831cdfbba1354a819a79f948f6f
>>> +Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
>>>
>
> would look like the attached.
Your patch did not show submodules as dirty when the refs were identical.
The following patch fixes that and extends the test to catch that too.
-- >8 --
Subject: Show a modified submodule directory as dirty even if the refs match
When the submodules HEAD and the ref committed in the HEAD of the
superproject were the same, "git diff[-index] HEAD" did not show the
submodule as dirty when it should.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
diff-lib.c | 3 ++-
t/t4027-diff-submodule.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index 5ce226b..9cdf6da 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -233,7 +233,8 @@ static int get_stat_data(struct cache_entry *ce,
return -1;
}
changed = ce_match_stat(ce, &st, 0);
- if (changed) {
+ if (changed
+ || (S_ISGITLINK(ce->ce_mode) && is_submodule_modified(ce->name))) {
mode = ce_mode_from_stat(ce, st.st_mode);
sha1 = null_sha1;
}
diff --git a/t/t4027-diff-submodule.sh b/t/t4027-diff-submodule.sh
index bf8c980..83c1914 100755
--- a/t/t4027-diff-submodule.sh
+++ b/t/t4027-diff-submodule.sh
@@ -97,6 +97,41 @@ test_expect_success 'git diff HEAD with dirty submodule (untracked)' '
test_cmp expect.body actual.body
'
+test_expect_success 'git diff HEAD with dirty submodule (work tree, refs match)' '
+ git commit -m "x" sub &&
+ echo >>sub/world &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subprev $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (index, refs match)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ echo >>world &&
+ git add world
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subprev $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
+test_expect_success 'git diff HEAD with dirty submodule (untracked, refs match)' '
+ (
+ cd sub &&
+ git reset --hard &&
+ git clean -qfdx &&
+ >cruft
+ ) &&
+ git diff HEAD >actual &&
+ sed -e "1,/^@@/d" actual >actual.body &&
+ expect_from_to >expect.body $subprev $subprev-dirty &&
+ test_cmp expect.body actual.body
+'
+
test_expect_success 'git diff (empty submodule dir)' '
: >empty &&
rm -rf sub/* sub/.git &&
--
1.6.6.294.g1f7f2.dirty
^ permalink raw reply related
* Re: [PATCH 3/4] start_command: detect execvp failures early
From: Junio C Hamano @ 2010-01-14 21:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Ilari Liusvaara, git
In-Reply-To: <201001101411.22418.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Previously, failures during execvp could be detected only by
> finish_command. However, in some situations it is beneficial for the
> parent process to know earlier that the child process will not run.
>
> The idea to use a pipe to signal failures to the parent process and
> the test case were lifted from patches by Ilari Liusvaara.
I wonder if we can do this without pipe, perhaps using "vfork, exec, then
update a variable"....
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Robin H. Johnson @ 2010-01-14 21:06 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20100114204305.GC26883@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]
On Thu, Jan 14, 2010 at 03:43:05PM -0500, Jeff King wrote:
> On Thu, Jan 14, 2010 at 11:41:07AM -0800, Shawn O. Pearce wrote:
>
> > > Because receive-pack runs as the user who is pushing, not as the
> > > repository owner. So by convincing you to push to my repository in a
> > > multi-user environment, I convince you to run some arbitrary code of
> > > mine.
> >
> > Uhhh, this was in fetch/upload-pack Peff, not push/receive-pack.
> >
> > Same issue though.
> Errr...yeah. Sorry for the confusion. But yes, it's the same mechanism,
> except that it is even easier to get people to pull from you (to get
> them to push, you first have to get them to write a worthwhile code
> contribution. ;) ).
post-update, post-receive, update, pre-receive would all be subject to
this problem as well if:
- the repo was group/world-writable
- the hook is untrusted
post-upload-pack just required group/world-readable and untrusted hook
code.
I'd like to lodge a complaint about the removal of the functionality. I
would have commented on the patch prior to this, but even searching I
didn't see it cross the list.
As a reasonable middle ground between the functionality and complete
removal, can we find a way just to only execute the potentially
dangerous hooks under known safe conditions or when explicitly requested
by the user.
Places where the hooks are safe:
- the hooks are known trusted AND not writable by the user/group.
(e.g. "chown -R root:root hooks/").
- Systems where the users/groups do not have full shell access, just
access to run Git itself. Eg gitosis, regular git+ssh:// w/ a
restricted shell.
Upcoming use case:
For Gentoo's work on migrating to Git, we've been working on a
pre-upload-pack hook and script that can explicitly block the generation
of some packs.
Basically, unless you send a sufficiently recent 'have' line, you are
told to fetch a bundle via HTTP or rsync instead.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Marko Poutiainen @ 2010-01-14 21:07 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20100114195234.GA26684@coredump.intra.peff.net>
Jeff King wrote:
> On Thu, Jan 14, 2010 at 08:18:40PM +0200, Marko Poutiainen wrote:
>
>> It seems that that there is a bug related to how Git handles the add
>> command with wildcards if the wildcard also matches a file that is ignored.
>>
>> E.g (I activate the *.[ao] rule when editing .git/info/exclude):
>>
>> mep@Blackbird:~$ cd /tmp
>> mep@Blackbird:/tmp$ mkdir git
>> mep@Blackbird:/tmp$ cd git
>> mep@Blackbird:/tmp/git$ git init
>> Initialized empty Git repository in /tmp/git/.git/
>> mep@Blackbird:/tmp/git$ nano -w .git/info/exclude
>> mep@Blackbird:/tmp/git$ touch a.o a.c a.h
>> mep@Blackbird:/tmp/git$ git add a.*
>> The following paths are ignored by one of your .gitignore files:
>> a.o
>> Use -f if you really want to add them.
>> fatal: no files added
>
> It's not a bug. That is working as designed. If "git add" encounters a
> problem with any of the files you gave it on the command line (and
> remember, the shell expands the wildcard, so git literally sees the
> three files on the command line) then it aborts the entire operation.
>
> Now whether that is useful behavior in this case, I don't know. If you
> were truly manually specifying the files, then it would probably not be
> a big deal to simply remove the offending file. But there is no way to
> use the shell wildcard and get the behavior you want (not even a "git
> add --really-ignore-my-ignores a.*").
>
> I don't think it would be right to silently ignore them, because it may
> be the sign of an error. It could be downgraded to a warning, like:
>
> $ git add *.a
> warning: a.o is ignored, not adding
>
> The downside would be that somebody who really _did_ want to add such a
> file but forgot to use "-f" is going to be less likely to notice it, as
> the command does not barf. So maybe such behavior should be triggered
> with a command-line option. I dunno.
Well, it then the interface just isn't consistent, because if that's the
reason, then why does
$git add .
then work in this case? . is still just a type of wildcard, so it fail
in a similar way, shouldn't it?
Your idea of giving a warning is good as is the command-line option. In
any case, in my opinion this feature can make some operations more
complex than they should be. For instance, in my example I would have to
separately do git add to both files. What if there are more than two
files to add and I get this error every time I try to add the files?
^ permalink raw reply
* Re: What is the best way to convert a multi module CVS repository to git?
From: Heiko Voigt @ 2010-01-14 20:52 UTC (permalink / raw)
To: git
In-Reply-To: <20100104155322.GC12195@atpcttvc.global-intra.net>
On Mon, Jan 04, 2010 at 04:53:22PM +0100, Wolfgang.Liebich@siemens-enterprise.com wrote:
> Hi,
> I have inherited a rather big, old, multi-module CVS repository which I
> want to convert to GIT.
> Most of the CVS modules do belong to one project now, i.e. the
> separation into multiple modules is something of a historical accident
> now. This means it does not make sense to put each CVS module into an
> own GIT project and use submodules.
> Furthermore the conversion will be one-way, i.e. afterwards the CVS repo
> will be shutdown forever and moved to offline storage. Incremental
> conversion is therefore not an issue.
> If I need one day to convert everything (the repo is about 3GB), so be
> it - the most important feature to me is correctness (I do NOT want to
> have to run manual verifications for N days/weeks/months, just to verify
> that everything was converted), and ideally even the possibility of
> re-creating the history of files which were moved across directories
> (this HAS happened sometimes - I did not fiddle around with the RCS
> files, but used straight rm+add, and accepted the loss of history forced
> on me by CVS).
>
> What is the best (i.e. most trustworthy) method of conversion? For now
> it seems to me that cvs2git (the ...2git companion to cvs2svn) is the
> best choice (because it can handle multi-module projects in a sane way)
> - but I'm open to suggestions!
As far as I know cvs2git provides the technically most correct
conversion out there. Nevertheless I would suggest to try parsecvs. It
is kind of hard to set up but has a more intuitive heuristic for tags
although not strictly correct.
cheers Heiko
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Avery Pennarun @ 2010-01-14 20:46 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100114085124.GA10298@Knoppix>
On Thu, Jan 14, 2010 at 3:51 AM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> The client tries only one auth method instead of potentially trying
> multiple. Witness the 'use verbose mode and check if it uses the key'
> type stuff.
I believe this is a limitation of the client, not of the protocol. So
a patch to the ssh client could fix this.
> OpenSSH? With the level of paranoia in it, I'd say good luck. And
> it's not just client, its the server also (and especially the
> server).
But you could fork it if you wanted. It's about as easy to convince
me to install a different version of ssh than to install
yet-another-security-server. (In fact, it might be easier to get me
to put in a patched openssh; at least then I can trust that it's
mostly openssh, and examine just what's different in your version.)
> And if you host the repo system too, you would get second key anyway
> (and SSH is not too good at handling multiple keys).
I'm not really sure about this. ssh-add seems pretty easy.
Have fun,
Avery
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Jeff King @ 2010-01-14 20:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Arun Raghavan, git
In-Reply-To: <20100114194107.GA20033@spearce.org>
On Thu, Jan 14, 2010 at 11:41:07AM -0800, Shawn O. Pearce wrote:
> > Because receive-pack runs as the user who is pushing, not as the
> > repository owner. So by convincing you to push to my repository in a
> > multi-user environment, I convince you to run some arbitrary code of
> > mine.
>
> Uhhh, this was in fetch/upload-pack Peff, not push/receive-pack.
>
> Same issue though.
Errr...yeah. Sorry for the confusion. But yes, it's the same mechanism,
except that it is even easier to get people to pull from you (to get
them to push, you first have to get them to write a worthwhile code
contribution. ;) ).
-Peff
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Jeff King @ 2010-01-14 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marko Poutiainen, git
In-Reply-To: <7vljg0bfox.fsf@alter.siamese.dyndns.org>
On Thu, Jan 14, 2010 at 12:21:34PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > ... But there is no way to
> > use the shell wildcard and get the behavior you want (not even a "git
> > add --really-ignore-my-ignores a.*").
>
> Perhaps you want to run
>
> $ git add 'a.*'
>
> Notice that the wildcard is protected from the shell.
Ugh. You're right that it does work, but I don't expect users to make
the intuitive jump from the OP's problem to this solution (I certainly
didn't). In particular:
1. Most programs don't take their own globs. Without knowing that git
can do so, there is no reason to discover it in this instance. I
can see searching the manpage for options, but not for a discussion
of globbing behavior.
2. They would have to know that using a git-glob will magically change
the error-checking behavior.
-Peff
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Junio C Hamano @ 2010-01-14 20:21 UTC (permalink / raw)
To: Jeff King; +Cc: Marko Poutiainen, git
In-Reply-To: <20100114195234.GA26684@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... But there is no way to
> use the shell wildcard and get the behavior you want (not even a "git
> add --really-ignore-my-ignores a.*").
Perhaps you want to run
$ git add 'a.*'
Notice that the wildcard is protected from the shell.
^ permalink raw reply
* Re: [PATCH 1/5] MSVC: Windows-native implementation for subset of Pthreads API
From: Johannes Sixt @ 2010-01-14 19:55 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: kusmabite, msysgit, git, Andrzej K. Haczewski
In-Reply-To: <20100114051241.GF10586@dpotapov.dyndns.org>
On Donnerstag, 14. Januar 2010, Dmitry Potapov wrote:
> I hope I have explained well enough why I can vouch that the above
> assignment works atomically WRT any Interlock function.
Your arguments are very convincing, thank you very much!
-- Hannes
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Arun Raghavan @ 2010-01-14 19:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git
In-Reply-To: <20100114194107.GA20033@spearce.org>
2010/1/15 Shawn O. Pearce <spearce@spearce.org>:
> Jeff King <peff@peff.net> wrote:
>> On Thu, Jan 14, 2010 at 11:31:57PM +0530, Arun Raghavan wrote:
>> > [I'm not on the list, so please CC me on replies]
>> >
>> > Hello,
>> > I noticed that the post-upload hook had been removed in commit
>> > 1456b043fc0f0a395c35d6b5e55b0dad1b6e7acc. The commit message states:
>> >
>> > This hook runs after "git fetch" in the repository the objects are
>> > fetched from as the user who fetched, and has security implications.
>> >
>> > I was wondering if someone could shed some light (or links) on what
>> > security implications this hook has?
>>
>> Because receive-pack runs as the user who is pushing, not as the
>> repository owner. So by convincing you to push to my repository in a
>> multi-user environment, I convince you to run some arbitrary code of
>> mine.
>
> Uhhh, this was in fetch/upload-pack Peff, not push/receive-pack.
>
> Same issue though.
Ah, got it - thank you!
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Jeff King @ 2010-01-14 19:52 UTC (permalink / raw)
To: Marko Poutiainen; +Cc: git
In-Reply-To: <4B4F6000.4070005@sofistes.net>
On Thu, Jan 14, 2010 at 08:18:40PM +0200, Marko Poutiainen wrote:
> It seems that that there is a bug related to how Git handles the add
> command with wildcards if the wildcard also matches a file that is ignored.
>
> E.g (I activate the *.[ao] rule when editing .git/info/exclude):
>
> mep@Blackbird:~$ cd /tmp
> mep@Blackbird:/tmp$ mkdir git
> mep@Blackbird:/tmp$ cd git
> mep@Blackbird:/tmp/git$ git init
> Initialized empty Git repository in /tmp/git/.git/
> mep@Blackbird:/tmp/git$ nano -w .git/info/exclude
> mep@Blackbird:/tmp/git$ touch a.o a.c a.h
> mep@Blackbird:/tmp/git$ git add a.*
> The following paths are ignored by one of your .gitignore files:
> a.o
> Use -f if you really want to add them.
> fatal: no files added
It's not a bug. That is working as designed. If "git add" encounters a
problem with any of the files you gave it on the command line (and
remember, the shell expands the wildcard, so git literally sees the
three files on the command line) then it aborts the entire operation.
Now whether that is useful behavior in this case, I don't know. If you
were truly manually specifying the files, then it would probably not be
a big deal to simply remove the offending file. But there is no way to
use the shell wildcard and get the behavior you want (not even a "git
add --really-ignore-my-ignores a.*").
I don't think it would be right to silently ignore them, because it may
be the sign of an error. It could be downgraded to a warning, like:
$ git add *.a
warning: a.o is ignored, not adding
The downside would be that somebody who really _did_ want to add such a
file but forgot to use "-f" is going to be less likely to notice it, as
the command does not barf. So maybe such behavior should be triggered
with a command-line option. I dunno.
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Junio C Hamano @ 2010-01-14 19:44 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Thomas Rast, Jeff King, Adam Megacz, git
In-Reply-To: <94a0d4531001141136m3eb51d11rafdf7f0672e68dff@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Thu, Jan 14, 2010 at 9:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I think the point of the message you are responding to is that it has
>> already been proven that there are users that never reads any of the
>> zillions of "your first 10 minutes with Git". How that _could_ ever
>> possibly be the reason/justification why you would want to push that
>> change to our documentation?
>
> Users are lazy.
And the ones that suffer from the issue discussed in this thread will not
read the manual your patch touches. When you make changes to the manual,
you should not be targetting them, as they won't read it anyway. Instead,
the description of the manual should aim to help people who _read_ it.
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Shawn O. Pearce @ 2010-01-14 19:41 UTC (permalink / raw)
To: Jeff King; +Cc: Arun Raghavan, git
In-Reply-To: <20100114193607.GB25863@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Thu, Jan 14, 2010 at 11:31:57PM +0530, Arun Raghavan wrote:
> > [I'm not on the list, so please CC me on replies]
> >
> > Hello,
> > I noticed that the post-upload hook had been removed in commit
> > 1456b043fc0f0a395c35d6b5e55b0dad1b6e7acc. The commit message states:
> >
> > This hook runs after "git fetch" in the repository the objects are
> > fetched from as the user who fetched, and has security implications.
> >
> > I was wondering if someone could shed some light (or links) on what
> > security implications this hook has?
>
> Because receive-pack runs as the user who is pushing, not as the
> repository owner. So by convincing you to push to my repository in a
> multi-user environment, I convince you to run some arbitrary code of
> mine.
Uhhh, this was in fetch/upload-pack Peff, not push/receive-pack.
Same issue though.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Felipe Contreras @ 2010-01-14 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Jeff King, Adam Megacz, git
In-Reply-To: <7vy6k0cxbz.fsf@alter.siamese.dyndns.org>
On Thu, Jan 14, 2010 at 9:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I think the point of the message you are responding to is that it has
> already been proven that there are users that never reads any of the
> zillions of "your first 10 minutes with Git". How that _could_ ever
> possibly be the reason/justification why you would want to push that
> change to our documentation?
Users are lazy.
--
Felipe Contreras
^ permalink raw reply
* Re: Removal of post-upload-hook
From: Jeff King @ 2010-01-14 19:36 UTC (permalink / raw)
To: Arun Raghavan; +Cc: git
In-Reply-To: <6f8b45101001141001q40d8b746v8385bc6ae37a6af4@mail.gmail.com>
On Thu, Jan 14, 2010 at 11:31:57PM +0530, Arun Raghavan wrote:
> [I'm not on the list, so please CC me on replies]
>
> Hello,
> I noticed that the post-upload hook had been removed in commit
> 1456b043fc0f0a395c35d6b5e55b0dad1b6e7acc. The commit message states:
>
> This hook runs after "git fetch" in the repository the objects are
> fetched from as the user who fetched, and has security implications.
>
> I was wondering if someone could shed some light (or links) on what
> security implications this hook has?
Because receive-pack runs as the user who is pushing, not as the
repository owner. So by convincing you to push to my repository in a
multi-user environment, I convince you to run some arbitrary code of
mine.
-Peff
^ permalink raw reply
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Junio C Hamano @ 2010-01-14 19:15 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Thomas Rast, Jeff King, Junio C Hamano, Adam Megacz, git
In-Reply-To: <94a0d4531001141104w74dbaf35jb5fded9e266bc04b@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Thu, Jan 14, 2010 at 5:02 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> Wincent Colaiuta wrote:
>>>
>>> Fair enough, but I'm sighing here at the thought of people jumping in
>>> and using git commands without even having looked at _any_ of the
>>> zillions of "your first 10 minutes with Git" tutorials out there,
>>> which pretty much _all_ start with how to set up your user.name and
>>> user.email...
>>
>> If you really are shocked by that thought, try hanging out on #git for
>> six hours on any given day...
>
> Which is precisely why I was pushing for this:
> http://thread.gmane.org/gmane.comp.version-control.git/131150
I think the point of the message you are responding to is that it has
already been proven that there are users that never reads any of the
zillions of "your first 10 minutes with Git". How that _could_ ever
possibly be the reason/justification why you would want to push that
change to our documentation?
^ permalink raw reply
* Re: [PATCH v2 3/3] commit: show interesting ident information in summary
From: Felipe Contreras @ 2010-01-14 19:04 UTC (permalink / raw)
To: Thomas Rast; +Cc: Wincent Colaiuta, Jeff King, Junio C Hamano, Adam Megacz, git
In-Reply-To: <201001141602.22244.trast@student.ethz.ch>
On Thu, Jan 14, 2010 at 5:02 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Wincent Colaiuta wrote:
>>
>> Fair enough, but I'm sighing here at the thought of people jumping in
>> and using git commands without even having looked at _any_ of the
>> zillions of "your first 10 minutes with Git" tutorials out there,
>> which pretty much _all_ start with how to set up your user.name and
>> user.email...
>
> If you really are shocked by that thought, try hanging out on #git for
> six hours on any given day...
Which is precisely why I was pushing for this:
http://thread.gmane.org/gmane.comp.version-control.git/131150
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: J.H. @ 2010-01-14 18:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Petr Baudis, git
In-Reply-To: <vpqbpgxrn32.fsf@bauges.imag.fr>
On 01/14/2010 02:35 AM, Matthieu Moy wrote:
> "J.H." <warthog19@eaglescrag.net> writes:
>
>> Just a heads up I've got an initial import of the current wiki up at
>> http://git.wiki.kernel.org - some of it was quite a clean conversion,
>> some of it not so much. Please note that user accounts were not carried
>> over but edit histories were. I'll work on cleaning up the rest of if
>> tomorrow, assuming that there isn't any objections to Petr's e-mail
>> above.
>
> My only objection would be "Oh, migrating to another wiki engine will
> be much conversion work", but if you're willing to do it ;-).
It unfortunately goes with the territory, though I'll admit the Moinmoin
-> Mediawiki was the first conversion I've seen where even Mediawiki said:
There are a number of hacky scripts for this. They are all
defective in various ways - anyone who does this job does it
precisely once, so there's no-one who really maintains a good
converter script.
> This page seems to be an interesting test-case:
> http://git.wiki.kernel.org/index.php/GitFaq
> full of miss-imported formatting, links, ...
That's not actually the worst,
http://git.wiki.kernel.org/index.php/GitRelatedLogos
even after I've cleaned up a chunk of it is still pretty bad.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: J.H. @ 2010-01-14 18:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.1001141136450.4985@pacific.mpi-cbg.de>
On 01/14/2010 02:43 AM, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 14 Jan 2010, J.H. wrote:
>
>> On 01/13/2010 05:24 PM, Petr Baudis wrote:
>>
>>> On Thu, Jan 14, 2010 at 12:29:08AM +0100, Petr Baudis wrote:
>>>> I would like to notify you that unfortunately, Czech UPC terminated
>>>> the sponsorship of the hardware and connectivity hosting the Git Wiki
>>>> and repo.or.cz (after generously donating it for several years).
>>>
>>> ...please scratch the Git Wiki part, you would be supporting just
>>> repo.or.cz - we are considering to move the Git wiki to
>>> wiki.kernel.org MediaWiki installation and I would like to ask if
>>> anyone disagrees with this. The motivation is that:
>>>
>>> (i) wiki.kernel.org is actually maintained! Thus, there should be
>>> less spam or upgrade issues and better support in case of problems.
>>>
>>> (ii) Also, I personally think MediaWiki is so much nicer than
>>> ikiwiki...
>
> ... not to mention than MoinMoin...
>
>>> (iii) ...and OBTW, no CamelCase!
>>>
>>> Of course, there will be compatibility redirects.
>>
>> Just a heads up I've got an initial import of the current wiki up at
>> http://git.wiki.kernel.org - some of it was quite a clean conversion,
>> some of it not so much.
>
> Did you use a script? And did you leech the sources, or did you get a
> dump?
Used a conversion script form a dump from Petr, needless to say it wa
sthe one generally recommended by mediawiki and even their commentary on
it was "It's the least bad" basically
> I note that "<<<!-- ! TOC here -->(2)>>" could be converted to "__TOC__",
> I believe.
I'll have to go in behind and track those down, should be easy enough to
find / fix.
>> Please note that user accounts were not carried over but edit histories
>> were.
>
> IIUC there are no email addresses stored in the Git Wiki, so I think that
> we'll have to live with that. You might get the occasional complaint of a
> stolen account.
I'm fine with dealing with those on an individual basis, and it would be
good for people to re-create their accounts as soon as possible.
>> I'll work on cleaning up the rest of if tomorrow, assuming that there
>> isn't any objections to Petr's e-mail above.
>
> I like it. Especially since there is a fun project waiting for me to
> get some time to do it, to convert the full history of a MediaWiki
> instance into a Git repository. Maybe via the git-remote* mechanism, once
> Sverre and Ilari manage to flush out the last remnants of clumsy design.
Now you've got a solid wiki to work with that's pertinent ;-)
- John 'Warthog9' Hawley
^ permalink raw reply
* Gitignore matching "git add" wildcard prevents operation
From: Marko Poutiainen @ 2010-01-14 18:18 UTC (permalink / raw)
To: git
It seems that that there is a bug related to how Git handles the add
command with wildcards if the wildcard also matches a file that is ignored.
E.g (I activate the *.[ao] rule when editing .git/info/exclude):
mep@Blackbird:~$ cd /tmp
mep@Blackbird:/tmp$ mkdir git
mep@Blackbird:/tmp$ cd git
mep@Blackbird:/tmp/git$ git init
Initialized empty Git repository in /tmp/git/.git/
mep@Blackbird:/tmp/git$ nano -w .git/info/exclude
mep@Blackbird:/tmp/git$ touch a.o a.c a.h
mep@Blackbird:/tmp/git$ git add a.*
The following paths are ignored by one of your .gitignore files:
a.o
Use -f if you really want to add them.
fatal: no files added
mep@Blackbird:/tmp/git$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# a.c
# a.h
# a.o
nothing added to commit but untracked files present (use "git add" to track)
Furthermore:
mep@Blackbird:/tmp/git$ git add .
mep@Blackbird:/tmp/git$ git commit -m "foo"
[master (root-commit) 43da825] foo
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a.c
create mode 100644 a.h
mep@Blackbird:/tmp/git$ nano a.c
mep@Blackbird:/tmp/git$ nano a.h
mep@Blackbird:/tmp/git$ git add a.*
The following paths are ignored by one of your .gitignore files:
a.o
Use -f if you really want to add them.
fatal: no files added
mep@Blackbird:/tmp/git$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: a.c
# modified: a.h
#
no changes added to commit (use "git add" and/or "git commit -a")
^ permalink raw reply
* Removal of post-upload-hook
From: Arun Raghavan @ 2010-01-14 18:01 UTC (permalink / raw)
To: git
[I'm not on the list, so please CC me on replies]
Hello,
I noticed that the post-upload hook had been removed in commit
1456b043fc0f0a395c35d6b5e55b0dad1b6e7acc. The commit message states:
This hook runs after "git fetch" in the repository the objects are
fetched from as the user who fetched, and has security implications.
I was wondering if someone could shed some light (or links) on what
security implications this hook has?
Thanks,
--
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)
^ permalink raw reply
* Re: [PATCH 01/18] rebase -i: Make the condition for an "if" more transparent
From: Junio C Hamano @ 2010-01-14 17:42 UTC (permalink / raw)
To: Eric Blake; +Cc: git, Michael Haggerty
In-Reply-To: <loom.20100114T164214-897@post.gmane.org>
Eric Blake <ebb9@byu.net> writes:
> Michael Haggerty <mhagger <at> alum.mit.edu> writes:
>
>> current_sha1=$(git rev-parse --verify HEAD)
>> - if test "$no_ff$current_sha1" = "$parent_sha1"; then
>> + if test -z "$no_ff" -a "$current_sha1" = "$parent_sha1"
>
> 'test cond1 -a cond2' is not portable. Use 'test cond1 && test cond2'.
I avoid "test -a/-o" myself without even thinking (I am from old-school),
but at the same time I thought the progress in the world made such caution
obsolescent.
Not so. Even though POSIX.1 lists -a/-o as options to "test", they are
marked "Obsolescent XSI" ("Strictly Conforming POSIX Applications and
Strictly Conforming XSI Applications shall not use obsolescent features").
We may want [PATCH -01/18] to clean up the existing code first. Even
outside git-rebase--interactive.sh there are quite a few of them.
$ git grep -n -e 'test .* -[ao] ' -- '*.sh' | wc -l
38
^ permalink raw reply
* git-svn dcommit to multiple repositories
From: Marc Strapetz @ 2010-01-14 17:26 UTC (permalink / raw)
To: git
AFAIU from git-svn.perl for dcommit, the repository to commit to can't
be specified. Instead dcommit automatically detects UUID and URL by
analyzing the log. This works only as long as the corresponding git
branches do not intersect. Doesn't it make sense to have --svn-remote
working for dcommit, too?
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: [PATCH 2/2] status: only touch path we may need to check
From: Sverre Rabbelier @ 2010-01-14 16:02 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1263481341-28401-3-git-send-email-pclouds@gmail.com>
Heya,
2010/1/14 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
> $ time git st eclass/
> real 0m3.211s
> $ time ~/w/git/git st eclass/
> real 0m1.587s
Wow, nice reduction!
--
Cheers,
Sverre Rabbelier
^ 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