* Re: [PATCH] Support username and password inside URL
From: Kalle Valo @ 2005-11-23 20:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtj3xe72.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Kalle Valo <Kalle.Valo@iki.fi> writes:
>
>> Currently usage of curl was so that netrc was mandatory and passwords in URL
>> weren't allowed. Change netrc to optional to make HTTP basic authentication
>> with username and password in URL also work.
>
> HTTP "basic"? Let's at least say "digest" for starters ;-).
Sorry, I didn't understand this. But anyway, I have always used the
basic authentication because it has been sufficient for my needs.
> I am modestly against letting users use auth-embedding URLs, and
> fairly strongly against encouraging users to do so.
I didn't even think about security implications when I sent the patch,
sorry about that. Now that I think of it, I even remember that some
browser removed this feature altogether. Yeah, it was IE:
http://support.microsoft.com/kb/834489
And Firefox seems to show a dialog confirmation dialog if I open an
URL with username and password. So I have to agree with you, it isn't
a good idea to embed the credentials to the URL.
> If you are using the password protected URL yourself, I'd
> imagine having them in your netrc would not be such a big deal,
Yes, I can manage with netrc for now. The only problem is that you
can't specify multiple usernames and passwords per host. (Or at least
that's how I understood the netrc man page.) If there's a way to do
that in git, I would really like to know about that.
> so I suspect your expected usage is not for yourself, but more
> like giving a temporary, even one-shot, access to others like
> the above example, and making it more convenient for them (even
> in that case, if it is not one-shot but for repeated use, I'd
> imagine it would not be such a big deal to ask them to do
> appropriate netrc).
Actually I'm going to be only user of the private git repository and
it's going to be permanent. I have multiple computers in different
locations (servers, workstations, laptops) and I would like to
distribute my private files (configuration files, scripts etc.) to all
of them using git. The files are not really that secret, but I just
don't want to share them with the whole world. That's why I'm using
just HTTP authentication and nothing secure.
> If that is what is going on here, then IMNSHO it would be better to
> make it clear that you are doing security-by-obscurity by not using
> username password pair, which makes you pretend that you are doing
> _some_ security.
I agree with you. I don't consider HTTP authentication secure at all.
It can just block search engines and casual readers from accessing the
page, nothing more. The problem with randomized URL (like you
suggested) is that if some person or a search engine finds the URL
somehow, then there's nothing stopping the information leak. HTTP
authentication at least stops search engines accessing the page.
--
Kalle Valo
^ permalink raw reply
* Re: Perl version support
From: Randal L. Schwartz @ 2005-11-23 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtiz4053.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> I think the target market is people who use whatever POSIXy
Junio> systems for their own work. To them, git and its dependencies
Junio> are merely tools to get their job done, and while they might be
Junio> capable and even willing to match the version requirements if it
Junio> is absolutely necessary, they'd rather spend their time on what
Junio> they do best (i.e. write software or documentation or whatever,
Junio> whose changes are to be managed by git), than installing or
Junio> upgrading base software just to satisfy git. And I'd like to
Junio> see their time spent on what they do best, instead of caring and
Junio> feeding of git, too.
Yes, this is why I keep pointing out GNU tools being used instead of
POSIXy versions. :) Mostly because they break on either my Darwin
laptop or my OpenBSD host server.
Junio> So in that sense, excluding 75% of people with "5.8 only" is not
Junio> acceptable at all, and covering 75% with "5.6 or better" might
Junio> be good enough, at least as a starter.
I think we're in agreement.
>> If you'd like, I can review all the Perl code with a tool that
>> determines the minimum Perl version, and provide patches to bring the
>> code to 5.5 level.
Junio> If it is not too much trouble, I'd appreciate it, at least the
Junio> first half that can be done without taking too much of your time.
Junio> Is it a mechanical "lint" like thing, that says "line 47 you
Junio> have list form of pipe open -- that's 5.8 and better"?
The "perlver" tool installed with the "Perl::MinimumVersion" module
from the CPAN will do about 80% of it. The other 20% are things
that I can use my brain for.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Ryan Anderson @ 2005-11-23 19:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7vpsor5h7o.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Junio C Hamano wrote:
> Ryan Anderson <ryan@michonline.com> writes:
>
>
>>On Wed, Nov 23, 2005 at 12:37:59AM -0800, Junio C Hamano wrote:
>>
>>>merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>
>>>
>>>>>>>>>"Junio" == Junio C Hamano <junkio@cox.net> writes:
>>>>
>>>>Junio> open my $oh, qw(|- git-update-index -z --stdin)
>>>>
>>
>>...
>>No, you're not using the list form for pipes. I use that in
>>git-graft-ripple:
>>
>> open(P,"-|","git-rev-list","--parents","--merge-order",$range)
>
>
> Oh, I didn't?
Sorry, I read after waking up and totally didn't see the "qw" in there.
You did, my bad.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Cogito documentation updates
From: Junio C Hamano @ 2005-11-23 19:52 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <438483A4.6040802@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I'm not Junio, but I think the priorities right now are ordererd like
> this; good performance, fast development, portability.
I am, but I am not Pasky, so I cannot talk about priority of
Cogito.
> However, most of the plumbing works on just about anything with a CPU,
> so unless you really need cg-clone you should be able to do it with
> git-clone, which AFAIU uses 'tar' and 'cpio' instead of cp to transfer
> files (for portability reasons, I imagine).
Exactly, because people with portability problems tend to feed
good patches directly to me and to the list.
^ permalink raw reply
* Re: Problem merging
From: Junio C Hamano @ 2005-11-23 19:48 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20051123085953.GA4933@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> Have you tried this merge with the recursive merge strategy?
>
> Btw is there a reason why 'recursive' isn't the default merge strategy
> for git-merge? It might be a bit confusing that git-pull and git-merge
> have different default strategies...
Agreed; will patch.
^ permalink raw reply
* Re: Perl version support
From: Junio C Hamano @ 2005-11-23 19:47 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86mzjvphhj.fsf_-_@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> I'd say that 50% of the Perl-using population is at 5.6, with 25% each
> at 5.5 and 5.8. Those on 5.5 are generally unable to upgrade Perl
> for corporate reasons.
I think the target market is people who use whatever POSIXy
systems for their own work. To them, git and its dependencies
are merely tools to get their job done, and while they might be
capable and even willing to match the version requirements if it
is absolutely necessary, they'd rather spend their time on what
they do best (i.e. write software or documentation or whatever,
whose changes are to be managed by git), than installing or
upgrading base software just to satisfy git. And I'd like to
see their time spent on what they do best, instead of caring and
feeding of git, too.
So in that sense, excluding 75% of people with "5.8 only" is not
acceptable at all, and covering 75% with "5.6 or better" might
be good enough, at least as a starter.
> If you'd like, I can review all the Perl code with a tool that
> determines the minimum Perl version, and provide patches to bring the
> code to 5.5 level.
If it is not too much trouble, I'd appreciate it, at least the
first half that can be done without taking too much of your time.
Is it a mechanical "lint" like thing, that says "line 47 you
have list form of pipe open -- that's 5.8 and better"?
^ permalink raw reply
* Re: Allow editing of a revert-message
From: Linus Torvalds @ 2005-11-23 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jaz5fj7.fsf@assigned-by-dhcp.cox.net>
On Wed, 23 Nov 2005, Junio C Hamano wrote:
>
> I think we can do
>
> -e)
> edit="-e" ;;
> ..
>
> git-commit -n -F .msg $edit
>
> to lose the ${EDITOR-${VISUAL-vi}} part..
You are of course right. That would also fix the total idiocy of my patch
that had you editing the message even if it wasn't used due to a "-n" that
disables commits ;)
Linus
^ permalink raw reply
* Re: Allow editing of a revert-message
From: Junio C Hamano @ 2005-11-23 19:29 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0511230954440.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ..., although I
> actually suspect it should be on by default (and we should have a
> "--no-edit" flag to disable it, probably together with an automatic
> disable if stdin isn't a terminal).
Thanks, and I agree. It is very very unlikely that somebody has
git-revert in her script and relies on git-revert to be
non-interactive, so we might not even need --no-edit.
> +[ "$edit" ] && ${EDITOR:-${VISUAL:-vi}} .msg
> case "$no_commit" in
> '')
> git-commit -n -F .msg
I think we can do
-e)
edit="-e" ;;
..
git-commit -n -F .msg $edit
to lose the ${EDITOR-${VISUAL-vi}} part..
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Junio C Hamano @ 2005-11-23 18:53 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Randal L. Schwartz, git
In-Reply-To: <20051123135604.GB16995@mythryan2.michonline.com>
Ryan Anderson <ryan@michonline.com> writes:
> On Wed, Nov 23, 2005 at 12:37:59AM -0800, Junio C Hamano wrote:
>> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>
>> >>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> >
>> > Junio> open my $oh, qw(|- git-update-index -z --stdin)
>> >
> ...
> No, you're not using the list form for pipes. I use that in
> git-graft-ripple:
>
> open(P,"-|","git-rev-list","--parents","--merge-order",$range)
Oh, I didn't?
^ permalink raw reply
* Allow editing of a revert-message
From: Linus Torvalds @ 2005-11-23 17:57 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I think all commit operations should allow editing of the message (ie we
should do this for merges too), but that's _particularly_ true of doing a
"git revert".
We should always explain why we needed to revert something.
This patch adds a "-e" or "--edit" flag to "git revert", although I
actually suspect it should be on by default (and we should have a
"--no-edit" flag to disable it, probably together with an automatic
disable if stdin isn't a terminal).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git-revert.sh b/git-revert.sh
index 4154fe0..05bd854 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -25,7 +25,7 @@ usage () {
esac
}
-no_commit= replay=
+no_commit= replay= edit=
while case "$#" in 0) break ;; esac
do
case "$1" in
@@ -36,6 +36,9 @@ do
-r|--r|--re|--rep|--repl|--repla|--replay)
replay=t
;;
+ -e|--edit)
+ edit=t
+ ;;
-*)
usage
;;
@@ -161,6 +164,7 @@ echo >&2 "Finished one $me."
# If we are revert, or if our cherry-pick results in a hand merge,
# we had better say that the current user is responsible for that.
+[ "$edit" ] && ${EDITOR:-${VISUAL:-vi}} .msg
case "$no_commit" in
'')
git-commit -n -F .msg
^ permalink raw reply related
* Re: [PATCH] Cogito documentation updates
From: Linus Torvalds @ 2005-11-23 17:29 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Jonas Fonseca, Petr Baudis, git
In-Reply-To: <8664qjph7d.fsf@blue.stonehenge.com>
On Wed, 23 Nov 2005, Randal L. Schwartz wrote:
>
> Delete the -d switch, or explain to me why it is there, and let's work
> out a POSIX workaround.
It's
-d: same as --no-dereference --preserve=link
--no-dereference
never follow symbolic links
--preserve[=ATTR_LIST]
preserve the specified attributes (default: mode,owner-
ship,timestamps) and security contexts, if possible additional
attributes: links, all
so it's basically making sure that the copy copies the _link_, not the
file it points to.
I think you may have to use "cpio -p" instead of "cp" to be portable.
Something like
cpio -plmu $src $dst
might do it.
Linus
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Johannes Schindelin @ 2005-11-23 17:22 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511231639.59866.Josef.Weidendorfer@gmx.de>
Hi,
On Wed, 23 Nov 2005, Josef Weidendorfer wrote:
> [myporcelain]
> headproperties.merge.candidates = blabla
With such a config file, git complains loudly. Key names are only allowed
to be alphanumerical, and the first letter cannot even be a digit. No
dots.
> This suggestion is about easier reading of config files; IMHO far easier
> with some use cases; but yes, it is arguable if it's worth an added
> complexity of config.c/config-set.c.
Well, I'll be glad to help the implementation of whatever we agree on.
Ciao,
Dscho
^ permalink raw reply
* Re: files are disappearing in git
From: Linus Torvalds @ 2005-11-23 17:20 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: Git ML
In-Reply-To: <20051123142303.GJ22568@schottelius.org>
On Wed, 23 Nov 2005, Nico -telmich- Schottelius wrote:
>
> I've the problem that some files (a directory with 3 files) is simply 'away':
>
> - We added it once
> - In current tree it's away
> - pasky aided me in irc to find the commit where it is gone with git bisect
> --> very nice tool
> - the commit, after which the directory was gone did NOT modify this directory
> - though the directory is gone
>
> What should I do know to find out what's the reason git 'forgot' that directory?
I bet somebody just messed up the index before that commit. So the commit
probably _did_ modify the directory, though some incorrect patching or
some scripting bug.
If you can guess at all what went on at around that commit (what else
happened there?) that might help. Was it a merge? If those three files
existed in the base commit of the merge but not in one of the branches,
then the merge would have assumed that the branch just deleted it.
Is the tree public so that we can look at it and perhaps make a guess from
what happened around it?
Linus
^ permalink raw reply
* Re: [RFC] Applying a graft to a tree and "rippling" the changes through
From: Linus Torvalds @ 2005-11-23 17:14 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Paul Mackerras, Johannes Schindelin, git
In-Reply-To: <20051123072738.GI20960@kiste.smurf.noris.de>
On Wed, 23 Nov 2005, Matthias Urlichs wrote:
> Hi,
>
> Paul Mackerras:
> > However, I was unable to get current gitk to exhibit the problem, even
> > with Thomas Gleixner's enormous history.git repository. Do you have a
> > specific example (repository and commit ID) where you see the problem
> > occur?
> >
> I've seen it in the past ... hmmm ... testing ... and it seems to
> majickally have fixed itself.
I saw it all the time before adding the "arrows" logic.
With the arrows, the graph never gets so complex that you'd see it.
Linus
^ permalink raw reply
* Re: [PATCH] Add git-graft-ripple, a tool for permanently grafting history into a tree.
From: Linus Torvalds @ 2005-11-23 17:07 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Junio C Hamano, git
In-Reply-To: <20051123135150.GA16995@mythryan2.michonline.com>
On Wed, 23 Nov 2005, Ryan Anderson wrote:
>
> I'm not entirely convinced this is a good idea, but there it is.
Well, quite frankly, I think the whole graft-rippling is just wrong (why
do it? The grafts are fine, and after you've rippled, you'll never be able
to merge with somebody who didn't) but if you do it, I think you should
fix it up properly and have a resulting tree that is at least as good as
the original.
Linus
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Josef Weidendorfer @ 2005-11-23 15:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511231549320.8191@wbgn013.biozentrum.uni-wuerzburg.de>
On Wednesday 23 November 2005 15:53, Johannes Schindelin wrote:
> Okay. What about this config file?
>
> -- snip --
> [myporcelain.headproperties: my/head.name]
> merge.candidates = my/other.head
> [myporcelain.headproperties]
> merge.candidates = blabla for my/head.name
> -- snap --
I am not sure you want to show here. Your example gives
myporcelain.headproperties.merge.candidates = my/other.head for my/head.name
myporcelain.headproperties.merge.candidates = blabla for my/head.name
I.e. 2 values for the same variable with the same "for" specification.
This is perfectly valid.
Are you talking about the multiple representations for the same thing?
Then hierarchical config keys already introduce this:
[myporcelain]
headproperties.merge.candidates = blabla
is the same as
[myprocelain.headproperties.merge]
candidates = blabla
> I am not totally opposed to what you are trying, but I think it
> contradicts the KISS principle.
This suggestion is about easier reading of config files; IMHO far easier
with some use cases; but yes, it is arguable if it's worth an added
complexity of config.c/config-set.c.
And of course this is no issue if config files are only to be written
by git-config-set. But I do not think this was the goal of the config
format.
Josef
> (Note: the restriction that key names must
> not start with a digit is also a contradiction to that.)
>
> Ciao,
> Dscho
>
> -
> 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
>
>
^ permalink raw reply
* Re: [PATCH] Add git-graft-ripple, a tool for permanently grafting history into a tree.
From: Johannes Schindelin @ 2005-11-23 15:40 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20051123135150.GA16995@mythryan2.michonline.com>
Hi,
On Wed, 23 Nov 2005, Ryan Anderson wrote:
> For some reason, my gut says that this goes too far. I'm having a hard
> time pinning down a way to explain that.
I can pin down what my gut says:
- the old commits still exist, so the links are not invalid
- the commit message is signed off as is
- the process to find the correct new SHA1 is not straight-forward, i.e.
one would need to introduce a recursion where now suffices a simple
linear loop.
Ciao,
Dscho
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Johannes Schindelin @ 2005-11-23 15:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Josef Weidendorfer, git
In-Reply-To: <438371E8.2030701@op5.se>
Hi,
On Tue, 22 Nov 2005, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
> >
> > git-config-set --get remote.origin.url
> >
>
> So... "git-config-set" is used for both getting and setting? Why not just
> "git-config --set" and "git-config --get" to make things a bit less confusing?
I tried to do this more like a proof of a concept (Yeah, famous last
words...) and tried to be not so intrusive. There is already a config.c,
and to keep with the naming, this would have to move to config-lib.c to
make space for config.c which really is the source for git-config$(X).
Should we rename config.c to config-lib.c, and config-set.c to config.c?
Personally, I think it too intrusive, but what the heck.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Cogito documentation updates
From: Andreas Ericsson @ 2005-11-23 14:58 UTC (permalink / raw)
To: git
In-Reply-To: <8664qjph7d.fsf@blue.stonehenge.com>
Randal L. Schwartz wrote:
>>>>>>"Jonas" == Jonas Fonseca <fonseca@diku.dk> writes:
>
>
> Jonas> Ah, yes. I just recently tried local cloning on a FreeBSD box and it
> Jonas> worked fine (apart from it spitting out a few errors, see the log below)
> Jonas> and since the caveat section only mentioned the -u option I thought
> Jonas> everything was fine. However, cloning a specific branch hits the error.
> Jonas> So maybe the caveat section should just be updated to say that the -d
> Jonas> option is required.
>
> But instead of targeting GNU tools, why not target POSIX tools where
> possible?
>
> Delete the -d switch, or explain to me why it is there, and let's work
> out a POSIX workaround.
>
-d same as --no-dereference --preserve=link
--no-dereference
never follow symbolic links
--preserve[=ATTR_LIST]
preserve the specified attributes (default:
mode,ownership,timestamps) and security contexts,
if possible
additional attributes: links, all
I don't know how to get those options with POSIX only cp.
> I'm not asking for everyone to be cautious when contributing code.
> I'll be happy to be "mr portability" and figure out how to make it
> still work on OpenBSD and Darwin (my two platforms of choice).
>
> However, as I said in another posting, maybe I just need to understand
> the target market first. (I realize that goal #1 is Linux Kernel
> development.)
>
I'm not Junio, but I think the priorities right now are ordererd like
this; good performance, fast development, portability.
Good performance because it's designed to handle one of the largest open
projects there is.
Fast development because it's still a young project but has more
momentum than most projects, open or closed, ever get. If it slows down
now it will stay slow until the kernel team needs new features and
there's no way of recycling inertia.
Portability because that's nice but not vital for the project as a whole
(it's a linuxish tool, so most users run it on linux so far). I think
portability usually ends up a bit behind in the race because it often
hinders #1 and #2.
Again, I'm not Junio. I might be dead wrong.
However, most of the plumbing works on just about anything with a CPU,
so unless you really need cg-clone you should be able to do it with
git-clone, which AFAIU uses 'tar' and 'cpio' instead of cp to transfer
files (for portability reasons, I imagine).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Get rid of .git/branches/ and .git/remotes/?
From: Johannes Schindelin @ 2005-11-23 14:53 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511230005.12957.Josef.Weidendorfer@gmx.de>
Hi,
On Wed, 23 Nov 2005, Josef Weidendorfer wrote:
> My suggestion complements hierarchical keys:
>
> [myporcelain.headproperties: my/head.name]
> merge.candidates = my/other.head
> merge.default = your/master
>
> would be the same as
>
> [myporcelain.headproperties]
> merge.candidates = my/other.head for my/head.name
> merge.default = your/master for my/head.name
Okay. What about this config file?
-- snip --
[myporcelain.headproperties: my/head.name]
merge.candidates = my/other.head
[myporcelain.headproperties]
merge.candidates = blabla for my/head.name
-- snap --
I am not totally opposed to what you are trying, but I think it
contradicts the KISS principle. (Note: the restriction that key names must
not start with a digit is also a contradiction to that.)
Ciao,
Dscho
^ permalink raw reply
* Re: Problem merging
From: Johannes Schindelin @ 2005-11-23 14:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q6483ms.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 22 Nov 2005, Junio C Hamano wrote:
> Sorry, but I am not a good enough cryptoanalyst to reverse SHA1
> hashes,
I think nobody is. Since there are infinitely many files having the same
SHA1 (pigeon-hole principle), there probably are infinitely many of them
which compile just fine (and therefore could be the original).
Now, I tried to find all of them, but I, too, failed ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: git-mv is not able to handle directory with one file in it
From: Josef Weidendorfer @ 2005-11-23 14:47 UTC (permalink / raw)
To: git
In-Reply-To: <200511231326.27972.lan@ac-sw.com>
On Wednesday 23 November 2005 08:26, Alexander Litvinov wrote:
> I have found one error during directory movig: If I move directory with one
> file somewhere in it this script will try to add target directory instead of
> file. Commenting lines starting from 190 solve this error. But I don't
> understand what is the logic behind this case ? Why do target directory
> checked instead of target file ?
$src/$dst pairs match the arguments given on the command line of git-mv,
And git-mv (as was git-rename) is able to move directory trees around.
It is simplier to keep the granularity at directories, as multiple moves
of directories can not overlap each other. If you do it at file level, you
have to remote and create directories yourself.
Of course, for git it is done at file level (that are the @srcfiles/@dstfiles
arrays), but this is quite trivial as git does not work with directories, but
only with files.
> Should we replace $dst my $destfiles[0] ?
Yes, that was part of my patch.
Josef
^ permalink raw reply
* Re: [PATCH] Add git-graft-ripple, a tool for permanently grafting history into a tree.
From: Randal L. Schwartz @ 2005-11-23 14:37 UTC (permalink / raw)
To: Ryan Anderson; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <20051123135150.GA16995@mythryan2.michonline.com>
>>>>> "Ryan" == Ryan Anderson <ryan@michonline.com> writes:
Ryan> git_commit_tree():
Ryan> my $found;
Ryan> do {
Ryan> $found = 0;
Ryan> if ($csets{$old}{comments} =~ /\s([a-f0-9]{40})\s/ &&
Ryan> exists $newcsets{$1}) {
Ryan> my $tcommit = $1;
Ryan> $found = 1;
Ryan> $csets{$old}{comments} =~ s/$tcommit/$newcsets{$tcommit}/g;
Ryan> }
Ryan> } while ($found);
I hate artificial booleans. This is better written as:
{
last unless my ($tcommit) = $csets{$old}{comments} =~ /\s([a-f0-9]{40})\s/;
last unless exists $newcsets{$tcommit};
$csets{$old}{comments} =~ s/$tcommit/$newcsets{$tcommit}/g;
redo;
}
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] Cogito documentation updates
From: Randal L. Schwartz @ 2005-11-23 14:33 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Petr Baudis, git
In-Reply-To: <20051123121651.GB19302@diku.dk>
>>>>> "Jonas" == Jonas Fonseca <fonseca@diku.dk> writes:
Jonas> Ah, yes. I just recently tried local cloning on a FreeBSD box and it
Jonas> worked fine (apart from it spitting out a few errors, see the log below)
Jonas> and since the caveat section only mentioned the -u option I thought
Jonas> everything was fine. However, cloning a specific branch hits the error.
Jonas> So maybe the caveat section should just be updated to say that the -d
Jonas> option is required.
But instead of targeting GNU tools, why not target POSIX tools where
possible?
I realize I'm being a rebel here. I want to use git on non-Linux platforms.
I believe git is useful for far more than Linux Kernel development, and
you're this --> <-- close to making it work.
Delete the -d switch, or explain to me why it is there, and let's work
out a POSIX workaround.
I'm not asking for everyone to be cautious when contributing code.
I'll be happy to be "mr portability" and figure out how to make it
still work on OpenBSD and Darwin (my two platforms of choice).
However, as I said in another posting, maybe I just need to understand
the target market first. (I realize that goal #1 is Linux Kernel
development.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] git-mv is not able to handle big directories
From: Randal L. Schwartz @ 2005-11-23 14:29 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Junio C Hamano, git
In-Reply-To: <200511231619.41497.lan@ac-sw.com>
>>>>> "Alexander" == Alexander Litvinov <lan@ac-sw.com> writes:
Alexander> I have made this change. I also belive it will work on earlier perl but I
Alexander> can't test this.
This patch looks good back to 5.5. I didn't execute it either, but
the Perl version installed in my head gave it a thumbs-up. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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