* Re: [Patch] Using 'perl' in *.sh
From: Michal Rokos @ 2006-07-09 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan-Benedict Glaw, Alex Riesen, git
In-Reply-To: <7vd5cfnkz4.fsf@assigned-by-dhcp.cox.net>
Hello,
On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> Michal, is there a reason you do not want to have the version of
> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
I have no problem with that. I can set $PATH.
But then I'd suggest to change magic #!
from #!/usr/bin/perl
to #!/usr/bin/env perl
for *.perl
It that what you meant?
M.
PS: Please note that
#!/usr/bin/env perl -w
will not work on some platforms (at least on HP-UX)...
--
Michal Rokos
NextSoft s.r.o.
Vyskočilova 1/1410
140 21 Praha 4
phone: +420 267 224 311
fax: +420 267 224 307
mobile: +420 736 646 591
e-mail: michal.rokos@nextsoft.cz
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Alex Riesen @ 2006-07-09 12:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607082011060.5623@g5.osdl.org>
Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:
> The basic idea is that "branch1" should be your current branch, and it
> obviously is also expected to match (more or less) the current index. So
> you can do a merge by
>
> - reading in "branch1" into the index:
>
> GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
what is "-m" here for?
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Randal L. Schwartz @ 2006-07-09 14:02 UTC (permalink / raw)
To: Michal Rokos; +Cc: Junio C Hamano, Jan-Benedict Glaw, Alex Riesen, git
In-Reply-To: <200607091441.16161.michal.rokos@nextsoft.cz>
>>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
Michal> I have no problem with that. I can set $PATH.
Michal> But then I'd suggest to change magic #!
Michal> from #!/usr/bin/perl
Michal> to #!/usr/bin/env perl
Michal> for *.perl
Michal> It that what you meant?
No, don't do that. Use the path to Perl that they chose during
configuration because
(a) it might not be the first one in PATH
(b) even if it's the first one in *my* path, it might not be the
first one in *everyone's* path
(c) env requires an *extra* fork/exec
(d) some systems don't have env
The env hack is a nice hack, but it's just a hack. Don't
rely on it when the right thing is nearby.
--
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] change ent to tree in git-diff documentation
From: Johannes Schindelin @ 2006-07-09 14:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git
In-Reply-To: <7v1wsvnkj8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 9 Jul 2006, Junio C Hamano wrote:
> Whoever coined <ent> (I do not remember anymore) do you mind
> this in addition to Matthias's patch?
AFAIR it was me. It was meant as a geek's joke from the beginning, and I
even had the pleasure of Linus calling me a total geek.
I do not have any objections against removing it. (AKA Ack.)
Ciao,
Dscho
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Johannes Schindelin @ 2006-07-09 14:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, git
In-Reply-To: <20060709124324.GE5919@steel.home>
Hi,
On Sun, 9 Jul 2006, Alex Riesen wrote:
> Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:
> > The basic idea is that "branch1" should be your current branch, and it
> > obviously is also expected to match (more or less) the current index. So
> > you can do a merge by
> >
> > - reading in "branch1" into the index:
> >
> > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
>
> what is "-m" here for?
It means that git-read-tree tries to merge the current index with branch1.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Johannes Schindelin @ 2006-07-09 14:31 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11524258261798-git-send-email-ryan@michonline.com>
Hi,
On Sun, 9 Jul 2006, Ryan Anderson wrote:
> If we can deprecate "run from the source tree", this can go away.
You would make yours truly very sad. Besides, for the tests we need the
functionality anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 14:33 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550607082354g62e99216gc72b07055762de3a@mail.gmail.com>
Hi,
On Sun, 9 Jul 2006, Marco Costalba wrote:
> It is possible to add a message (and more) to a tag creating a tag
> object. FWIK this is not allowed for the other refs.
>
> Why there is this (artifical?) difference between tags and the other
> kind of refs?
The tag message is nothing else than a commit message. The
(artificial-but-on-purpose) difference is that you are not supposed to
change a tag ref, whereas a regular ref pointing to a commit is _expected_
to point to some other commit in the future.
Ciao,
Dscho
^ permalink raw reply
* Re: [WIP] Status update on merge-recursive in C
From: Johannes Schindelin @ 2006-07-09 14:41 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1152421230.2103.31.camel@dv>
Hi,
On Sun, 9 Jul 2006, Pavel Roskin wrote:
> Hello, Dscho!
>
> On Sat, 2006-07-08 at 18:42 +0200, Johannes Schindelin wrote:
> > This is just an update for people being interested. Alex and me were
> > busy with that project for a few days now. While it has progressed nicely,
> > there are quite a couple TODOs in merge-recursive.c, just search for "TODO".
>
> That's great. Just a few notes regarding the patch.
>
> Why do you list "recur" twice in all_strategies in the git-merge.sh?
> The second "recur" should probably be "recursive".
This is just make really, really sure that recursive is not tested, but
recur. I would be laughed at if I sent a patch for recur and tested in on
recursive, claiming the patch was fine, right?
Besides, when recur is fixed (for the TODOs as well as for obscure test
cases), there will be no change to git-merge.sh and git-rebase.sh, because
recur will be the new recursive.
> Test for Python in the git-rebase.sh is probably wrong. "recur" doesn't
> need Python - that's the whole point. In fact, if I build git with
> NO_PYTHON, TEST fails in t3401-rebase-partial.sh
Again, I am not concerned about simple bugs as this right now. I want to
fix the big things first. Biggest thing right now: reimplement the
whee^H^H^H^Hread-tree with -i, -m, and no option.
> - variable declarations in the middle of the code (allowed by c99 but
> not by ANSI C) and incomplete function declarations (no "void"). It's
> not C++, let's stick to the C standards.
>From my experience with Java, I know that this declaration in the middle
of the code can make debugging much easier. That is why they are still
there. Like Junio said, once the thing is close to finished, we can fix
these.
> I'm attaching a patch that fixes everything except variable
> declarations.
May I ask you a favour? Can you redo the patch in, say, two weeks? Thank
you!
> It would be great to have a patch that actually removes the old
> "recursive" and makes the new strategy "recursive". I understand it's
> the plan, right?
Yes, sir.
Ciao,
Dscho
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Johannes Schindelin @ 2006-07-09 14:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0607082011060.5623@g5.osdl.org>
Hi,
On Sat, 8 Jul 2006, Linus Torvalds wrote:
> On Sun, 9 Jul 2006, Johannes Schindelin wrote:
> >
> > I also played a little with git-merge-tree, because it seems so much
> > simpler and easier to refactor. But there is a problem: Either I call it
> > the wrong way, or it does not yet work correctly: I tried
> >
> > git-merge-tree $(git-merge-base branch1 branch2) branch1 branch2
> >
> > with what is in 'next'. But it only showed the _new_ files, not the
> > modified ones.
>
> What git-merge-tree does is to show the _difference_ to "branch1".
I see my problem: branch1 is not the "upstream" branch, but my own. Tsk.
Too easy.
Now, if only merge-tree knew about renames. *sigh*.
> And yes, I agree 100% that "git-read-tree" has become an unholy mess. I
> looked at it, and I think it's unfixable. I considered re-writing it from
> scratch, at least for some specific cases, but I couldn't bring myself to
> do it.
Well, I think that at least the unpack_tree() thing should be relatively
easy to extract. And the rest _should_ be relatively easy to clean up,
provided we introduce a read_tree_options struct, which gets passed around
a la "this" in Java/C++.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] gitweb: Send XHTML as 'application/xhtml+xml' where possible
From: Alp Toker @ 2006-07-09 14:55 UTC (permalink / raw)
To: git
"The 'text/html' media type [RFC2854] is primarily for HTML, not for
XHTML. In general, this media type is NOT suitable for XHTML."
This patch makes gitweb use content negotiation to conservatively send
pages as Content-Type 'application/xhtml+xml' when the user agent
explicitly claims to support it.
It falls back to 'text/html' even if the user agent appears to
implicitly support 'application/xhtml+xml' due to a '*/*' glob, working
around an insidious bug in Internet Explorer where sending the correct
media type prevents the page from being displayed.
Signed-off-by: Alp Toker <alp@atoker.com>
---
gitweb/gitweb.cgi | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 3e2790c..beb8061 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -290,7 +290,17 @@ sub git_header_html {
}
}
}
- print $cgi->header(-type=>'text/html', -charset => 'utf-8', -status=> $status, -expires => $expires);
+ my $content_type;
+ # require explicit support from the UA if we are to send the page as
+ # 'application/xhtml+xml', otherwise send it as plain old 'text/html'.
+ # we have to do this because MSIE sometimes globs '*/*', pretending to
+ # support xhtml+xml but choking when it gets what it asked for.
+ if ($cgi->http('HTTP_ACCEPT') =~ m/(,|;|\s|^)application\/xhtml\+xml(,|;|\s|$)/ && $cgi->Accept('application/xhtml+xml') != 0) {
+ $content_type = 'application/xhtml+xml';
+ } else {
+ $content_type = 'text/html';
+ }
+ print $cgi->header(-type=>$content_type, -charset => 'utf-8', -status=> $status, -expires => $expires);
print <<EOF;
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
@@ -298,7 +308,7 @@ sub git_header_html {
<!-- git web interface v$version, (C) 2005-2006, Kay Sievers <kay.sievers\@vrfy.org>, Christian Gierke -->
<!-- git core binaries version $git_version -->
<head>
-<meta http-equiv="content-type" content="text/html; charset=utf-8"/>
+<meta http-equiv="content-type" content="$content_type; charset=utf-8"/>
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
<link rel="stylesheet" type="text/css" href="$stylesheet"/>
--
1.4.1.gbe4c7
^ permalink raw reply related
* Re: RFH: refactor read-tree
From: Linus Torvalds @ 2006-07-09 15:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git
In-Reply-To: <Pine.LNX.4.63.0607091630110.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 9 Jul 2006, Johannes Schindelin wrote:
>
> On Sun, 9 Jul 2006, Alex Riesen wrote:
>
> > Linus Torvalds, Sun, Jul 09, 2006 05:15:41 +0200:
> > > The basic idea is that "branch1" should be your current branch, and it
> > > obviously is also expected to match (more or less) the current index. So
> > > you can do a merge by
> > >
> > > - reading in "branch1" into the index:
> > >
> > > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
> >
> > what is "-m" here for?
>
> It means that git-read-tree tries to merge the current index with branch1.
Well, the current index always "merges" by just taking the timestamps from
it. The actual _content_ doesn't matter for the single-tree case.
For the two- and three-tree case, "git-read-tree -m" will verify that the
parts that got changed still _match_ in the index, but for a single-tree
"git-read-tree", there's nothing to match against, just the target, so
the only thing it does is that for matching index/target-tree entries it
will re-use the index timestamps (and other stat info).
Linus
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 16:24 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Michal Rokos, Junio C Hamano, Alex Riesen, git
In-Reply-To: <86ejwuuba2.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]
On Sun, 2006-07-09 07:02:13 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Michal" == Michal Rokos <michal.rokos@nextsoft.cz> writes:
>
> Michal> I have no problem with that. I can set $PATH.
> Michal> But then I'd suggest to change magic #!
> Michal> from #!/usr/bin/perl
> Michal> to #!/usr/bin/env perl
> Michal> for *.perl
>
> Michal> It that what you meant?
>
> No, don't do that. Use the path to Perl that they chose during
> configuration because
>
> (a) it might not be the first one in PATH
If you want to execute some binary that's not first in path, you'd
better *always* call that explicit.
> (b) even if it's the first one in *my* path, it might not be the
> first one in *everyone's* path
Communication problem. Machine's administrator should offer a working
git installation. If a user chooses to build his own git, he'd better
make sure that all the environment is properly set-up, too.
> (c) env requires an *extra* fork/exec
Only an extra exec.
> (d) some systems don't have env
Huh? Show me a system that has no /usr/bin/env, but a working POSIX
shell in /bin/sh .
> The env hack is a nice hack, but it's just a hack. Don't
> rely on it when the right thing is nearby.
What's the right thing? The right thing is to explicitely call the
interpreter, not using the shellbang at all.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Jakub Narebski @ 2006-07-09 16:47 UTC (permalink / raw)
To: git
In-Reply-To: <7virm7nq7h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Copy description of build configuration variables from the commentary
>> in the top Makefile (from 'next' branch) to configure.ac, splitting
>> them into "autoconf" sections.
>
> I do not see much point in this -- they will become out of sync.
> [...] I think you are better off making a list of
> supported and yet to be supported ones in the comment in
> configure.ac, and when you want to see if the list got stale
> over time, grep for '^# Define' from the Makefile and match them
> up.
This is kind of such a list. Also let me point out that this was in _first_
patch of the series, as a kind of TODO list.
Perhaps those which are done, and those which are not implemented should be
marked differently...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Jakub Narebski @ 2006-07-09 17:04 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0607090011000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sat, 8 Jul 2006, Jakub Narebski wrote:
>
>> moreau francis wrote:
>>
>>> Would it be possible to let the user stick a short explanation
>>> on what a branch is supposed to implement during its creation.
>>
>> It would be possible when/if branch and remotes config would migrate
>> to .git/config. Currently too many I think relies on refs/heads being
>> simple sha1 of "top" commit.
>
> But it does not need a change of existing practice at all! Just add the
> information provided by --topic as branch."pathname".description to the
> config. And make format-patch aware of that.
And make tools remove stale descriptions. I sometimes rename branches "by
hand", as currently there is I think no tool for this...
By the way, did this series of patches (adding support for branch and
remotes configuretion to config file) made into 'next', 'master' or even
'pu', or after some discussion it stalled?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 19:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e8rcu5$je5$2@sea.gmane.org>
Hi,
On Sun, 9 Jul 2006, Jakub Narebski wrote:
> By the way, did this series of patches (adding support for branch and
> remotes configuretion to config file) made into 'next', 'master' or even
> 'pu', or after some discussion it stalled?
The latter. Some parts are there (the remote configuration made it in
AFAIK) but things like the default remote(s) to fetch / push are not.
Ciao,
Dscho
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Junio C Hamano @ 2006-07-09 20:33 UTC (permalink / raw)
To: Michal Rokos; +Cc: git
In-Reply-To: <200607091441.16161.michal.rokos@nextsoft.cz>
Michal Rokos <michal.rokos@nextsoft.cz> writes:
> Hello,
>
> On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
>> Michal, is there a reason you do not want to have the version of
>> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
>
> I have no problem with that. I can set $PATH.
> But then I'd suggest to change magic #!
> from #!/usr/bin/perl
> to #!/usr/bin/env perl
> for *.perl
>
> It that what you meant?
No, that is not what I meant.
Invocation of perl _in_ scripts can be controlled by user's
PATH, but #! cannot be. As Merlyn says 'env' is a nice hack,
but we configure the scripts we install to have #! pointing at
the right interpreter as a more cleaner (than using 'env', that
is) workaround anyway, so #! pointing at PERL_PATH and scripts
relying on user's $PATH would be the right thing to do.
^ permalink raw reply
* Re: [RFC/PATCH 3] Copy description of build configuration variables to configure.ac
From: Junio C Hamano @ 2006-07-09 20:43 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <e8rbuk$je5$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> [...] I think you are better off making a list of
>> supported and yet to be supported ones in the comment in
>> configure.ac, and when you want to see if the list got stale
>> over time, grep for '^# Define' from the Makefile and match them
>> up.
>
> This is kind of such a list. Also let me point out that this was in _first_
> patch of the series, as a kind of TODO list.
Yes, you are right -- I spoke too early without realizing what
was going on. The others build on this TODO list to fill the
gap rather nicely.
^ permalink raw reply
* Re: [Patch] Using 'perl' in *.sh
From: Jan-Benedict Glaw @ 2006-07-09 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michal Rokos, git
In-Reply-To: <7v4pxqfri7.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]
On Sun, 2006-07-09 13:33:04 -0700, Junio C Hamano <junkio@cox.net> wrote:
> Michal Rokos <michal.rokos@nextsoft.cz> writes:
> > On Sunday 09 July 2006 12:14, Junio C Hamano wrote:
> >> Michal, is there a reason you do not want to have the version of
> >> perl you teach git tools via #! lines with PERL_PATH on your $PATH?
> >
> > I have no problem with that. I can set $PATH.
> > But then I'd suggest to change magic #!
> > from #!/usr/bin/perl
> > to #!/usr/bin/env perl
> > for *.perl
> >
> > It that what you meant?
>
> No, that is not what I meant.
Though I think you actually should :-)
> Invocation of perl _in_ scripts can be controlled by user's
> PATH, but #! cannot be. As Merlyn says 'env' is a nice hack,
> but we configure the scripts we install to have #! pointing at
> the right interpreter as a more cleaner (than using 'env', that
> is) workaround anyway, so #! pointing at PERL_PATH and scripts
> relying on user's $PATH would be the right thing to do.
It's just a question of the target system, so: What is our target? If
we target a fairly recent Unix box, we'd put whatever a user asked for
into the shellbang, and hope that he properly sets $PATH.
If we try to aim at POSIX systems, then first of all, `env' isn't a
hack. It's specified i the POSIX documents, even argument passing is
given. (So if `#!/usr/bin/env perl -w' doesn't work on a HP-UX system,
that's simply broken wrt. POSIX.)
At the maximum, we'd allow the user to supply the location of `env' if
it's not /usr/bin/env, but I guess you'll find a hard time finding a
system where there's no /usr/bin/env... The final killer would be to
explicitely mention the interpreter and install all scripts a-x to
force that :-)
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What *have* I done?
From: Petr Baudis @ 2006-07-09 21:21 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <87u05ru30p.fsf@hades.wkstn.nix>
Hi,
Dear diary, on Sun, Jul 09, 2006 at 12:48:22AM CEST, I got a letter
where Nix <nix@esperi.org.uk> said that...
> loki 593 /usr/packages/linux/linux% cg-diff | diffstat
Note that cg-diff -s might be useful.
> loki 594 /usr/packages/linux/linux% cg-reset
> loki 595 /usr/packages/linux/linux% cg-diff
> loki 596 /usr/packages/linux/linux%
...but when you switch away and switch back, the uncommitted changes
appear again?
Just in case, don't the tree happen to simply stay the same as in the
branch you switched from? (Try cg-diff -r yourpreviousbranch.)
And most importantly, does this also happen with just stock 0.17.3
cg-switch? With stock master cg-switch? (If both is no, you probably
forgot to cherrypick some associated cg-switch bugfix or something.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Martin Langhoff @ 2006-07-09 21:26 UTC (permalink / raw)
To: Ryan Anderson; +Cc: git
In-Reply-To: <11524258261798-git-send-email-ryan@michonline.com>
On 7/9/06, Ryan Anderson <ryan@michonline.com> wrote:
> This is the first in a series to categorize the source tree a little bit more
> than it is currently.
Given that you title it RFC, I guess it hasn't been discussed before.
I personally don't see much benefit from the move/rename. The tree is
not so large, the SCM import/export utilities are a single file each
and their names are quite clear. Having /contrib is more an issue of
marking utilities there as 'new, experimental, unsupported', and the
assumption is that when something matures it moves out of /contrib.
So I have to ask... what are the expected benefits of the move?
In any case, use /interop instead. /scm in the tree of an SCM could be
anything ;-)
martin
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Petr Baudis @ 2006-07-09 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, git
In-Reply-To: <Pine.LNX.4.63.0607091632070.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Sun, Jul 09, 2006 at 04:33:53PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sun, 9 Jul 2006, Marco Costalba wrote:
>
> > It is possible to add a message (and more) to a tag creating a tag
> > object. FWIK this is not allowed for the other refs.
> >
> > Why there is this (artifical?) difference between tags and the other
> > kind of refs?
>
> The tag message is nothing else than a commit message.
huh?
The tag message is a message in the "freeform" part of the tag object,
but disregarding the format similiraties, it has really nothing to do
with a commit message. (Also, commit messages don't tend to be commonly
PGP signed. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [RFC] just an (stupid) idea when creating a new branch
From: Johannes Schindelin @ 2006-07-09 22:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Marco Costalba, git
In-Reply-To: <20060709220116.GT29115@pasky.or.cz>
Hi,
On Mon, 10 Jul 2006, Petr Baudis wrote:
> Hi,
>
> Dear diary, on Sun, Jul 09, 2006 at 04:33:53PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> > On Sun, 9 Jul 2006, Marco Costalba wrote:
> >
> > > It is possible to add a message (and more) to a tag creating a tag
> > > object. FWIK this is not allowed for the other refs.
> > >
> > > Why there is this (artifical?) difference between tags and the other
> > > kind of refs?
> >
> > The tag message is nothing else than a commit message.
>
> huh?
>
> The tag message is a message in the "freeform" part of the tag object,
> but disregarding the format similiraties, it has really nothing to do
> with a commit message. (Also, commit messages don't tend to be commonly
> PGP signed. ;-)
Marco was talking about an "artificial difference", which means technical
issues. From a technical viewpoint, the tag message is _exactly_ the same
as a commit message.
Hth,
Dscho
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Petr Baudis @ 2006-07-09 22:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Ryan Anderson, git
In-Reply-To: <46a038f90607091426u5a6ea328h2090a876e51725ce@mail.gmail.com>
Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> So I have to ask... what are the expected benefits of the move?
I've been meaning to do something like this for some time already; my
itch have been the builtins. The tree size _is_ getting out of hand and
a little more categorization of the sources would certainly help.
Although I'd take a different approach:
libgit/
builtin/
standalone/
scripts/
> In any case, use /interop instead. /scm in the tree of an SCM could be
> anything ;-)
I agree on this point.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: RFH: refactor read-tree
From: Alex Riesen @ 2006-07-09 22:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0607090827430.5623@g5.osdl.org>
Linus Torvalds, Sun, Jul 09, 2006 17:30:26 +0200:
> > > > The basic idea is that "branch1" should be your current branch, and it
> > > > obviously is also expected to match (more or less) the current index. So
> > > > you can do a merge by
> > > >
> > > > - reading in "branch1" into the index:
> > > >
> > > > GIT_INDEX_FILE=.git/tmp-index git-read-tree -m branch1
> > >
> > > what is "-m" here for?
> >
> > It means that git-read-tree tries to merge the current index with branch1.
>
> Well, the current index always "merges" by just taking the timestamps from
> it. The actual _content_ doesn't matter for the single-tree case.
But the name suggests it's a temporary index, which would not have
anything in it and even the .git/tmp-index is not supposed to exist.
So I'd actually understand this as creating an index from the tree-ish
branch1, without merging anything. And continue wondering what that -m
is for...
^ permalink raw reply
* Re: [RFC+PATCH 1/1] Move SCM interoperability tools into scm/
From: Johannes Schindelin @ 2006-07-09 22:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Martin Langhoff, Ryan Anderson, git
In-Reply-To: <20060709221326.GU29115@pasky.or.cz>
Hi,
On Mon, 10 Jul 2006, Petr Baudis wrote:
> Dear diary, on Sun, Jul 09, 2006 at 11:26:59PM CEST, I got a letter
> where Martin Langhoff <martin.langhoff@gmail.com> said that...
> > So I have to ask... what are the expected benefits of the move?
>
> I've been meaning to do something like this for some time already; my
> itch have been the builtins. The tree size _is_ getting out of hand and
> a little more categorization of the sources would certainly help.
Funny. I thought the builtin-* prefix, and the *.sh and *.perl extensions
were there for the sake of categorization.
And I disagree on the "out of hand" thing.
Ciao,
Dscho
^ 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