* Re: Status of GIT for Fedora 10 + gitweb's look
From: Todd Zullinger @ 2009-03-20 17:31 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <B041B86F1FF246ACBD68051753788FBE@HPLAPTOP>
[-- Attachment #1: Type: text/plain, Size: 1188 bytes --]
Aaron Gray wrote:
> What I am really after knowing is gitweb on the latest version
> 1.6.2.1 anything like the nice HTML layout on http://git.kernel.org/
> or do I have to do the html formatting myself in the perl code ?
The gitweb included in the 1.6.0.6 packages for F-10 should look
mostly the same as the gitweb used on kernel.org. As JH mentioned,
you can install that with 'yum install gitweb'. If you need to modify
them, the options and css should let you do what you need without
editing the perl script.
If you do want to use 1.6.2.1, the rawhide packages should rebuild for
F-10 just fine (do note that the rawhide packages finally caught up
and moved the git-* binaries out of $PATH, something that isn't done
in the stock F-10 packages).
The fedora rawhide git packages are at:
http://mirrors.kernel.org/fedora/development/source/SRPMS/git-1.6.2-1.fc11.src.rpm
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When life gives you lemons, make lemonade, pee in it, and serve it to
the people that piss you off.
-- Jack Handy, Deep Thoughts
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 17:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink,
git
In-Reply-To: <7v7i2ki0sw.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 20 Mar 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Often, it is quite interesting to inspect the branch tracked by a given
> > branch. This patch introduces a nice notation to get at the tracked
> > branch: '%<branch>' can be used to access that tracked branch.
> >
> > A special shortcut '%' refers to the branch tracked by the current branch.
> >
> > Suggested by Pasky.
> >
> > Even if a branch name can legally start with a '%' sign, we can use the
> > special character '%' here, as you can always specify the full ref:
> > refs/heads/%my-branch (pointed out by doener on IRC).
>
> That is not a good argument, as %<name> is (just like name@{-n} is) a
> substitute way to spell the "name" of a branch, not just a random SHA-1,
> and to some commands it makes a difference between <branchname> and
> refs/heads/<branchname>. The latter is not giving the name of the branch,
> but merely a commit object name.
>
> An most obvious one is that "git checkout branchname" and "git checkout
> refs/heads/branchname" behave differently. You cannot checkout a branch
> called %master after this patch goes in.
>
> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts. Too bad. Don't
> do it next time you create a new branch". I _can_ buy that argument.
Be that as it may, at this point I kick the ball back to the interested
parties. I did my duty.
Ciao,
Dscho
^ permalink raw reply
* Minimum libCurl version for git
From: Mike Ralphson @ 2009-03-20 17:59 UTC (permalink / raw)
To: git list, Junio C Hamano, Daniel Stenberg, Nick Hengeveld,
Mike Hommey, Mike
See $gmane/112765 for background.
Git uses 31 CURL_, CURLINFO and CURLOPT symbols, two of these
(CURLINFO_HTTP_CODE and CURLOPT_INFILE) are officially deprecated, but
only because they have been renamed in 'recent' versions.
We protect the usage of symbols introduced in version 7.9.2 and later
with #ifdefs. These date back to some time in 2005 when those versions
of libCurl were 3 or so years old.
We use CURLOPT_FTP_USE_EPSV unprotected, which was introduced in
version 7.9.2. This is something of a pity as it is an optional
configuration item which is probably not widely used (I don't think I
knew there was any support for git over ftp). Still, 7.9.2 was a long
time ago (Dec 2001), and no-one is complaining. Disregarding this, we
would be able to use libCurl versions as far back as 7.8.1 (Aug 2001),
bugs, security fixes and performance notwithstanding.
According to Daniel's list [1], CURLOPT_SSLKEY was introduced in
7.9.3, but we enable it in http.c if we see version >= 7.9.2. This
could be a typo in the haxx.se list, or the option could have been
available in (some) 7.9.2 releases, or it could be a git bug. Again,
not one which appears to be biting anyone.
Going forward there are various options:
1. Do nothing - go with the status quo.
2. Correct the #ifdefs for CURLOPT_SSLKEY
3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our
minimum supported version. I feel slightly embarrassed about that, as
that's exactly the version I have here on AIX (unless I wrest it back
from being sysadmin-installed to being user-supported). Add a check to
the Makefile and error if libCurl is too old.
4. Drop all current #ifdefs and one of the deprecated symbol names.
Our minimum supported libCurl version would be 7.9.8 from Jun 2002.
5. Drop all current #ifdefs and both of the deprecated symbol names.
Our minimum supported libCurl version would be 7.10.8 from Nov 2003.
6. Warn (not error) if libCurl is older than say the 3 years suggested
by Daniel. This would seem to require periodic updates to the Makefile
check.
I'm happy to whip up a patch if required, but I thought a series of
mutually-exclusive alternative patches would be confusing without
prior agreement on the approach.
Mike
[1] http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Junio C Hamano @ 2009-03-20 18:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher, B.Steinbrink,
git
In-Reply-To: <7v7i2ki0sw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Just be honest and say "You may have a branch whose name begins with a '%'
> and you cannot refer to it anymore in certain contexts. Too bad. Don't
> do it next time you create a new branch". I _can_ buy that argument.
>
> It however asks for a sane escape hatch. You cannot "fix" such branch
> names in most obvious ways (if you could, that would be a bug in this %
> feature).
>
> (1) git branch -m %master percent-master
>
> We would end up renaming what master tracks to new name.
>
> (2) git branch percent-master refs/heads/%master; git branch -d %master
>
> The first part is a good try, but the latter deletes what master
> tracks.
>
> "git update-ref -d refs/heads/%master" needs to replace the second step of
> the latter.
A naïve question.
Has nobody suggested to use a really illegal characters such as ':'
instead? After all, we are not talking something that you can use in
refspecs but another way to spell branch names.
Alternatively, '~master' may have a nice connotation that means "where
master calls its home".
I haven't looked at the patch deeply yet, but what does the failure case
do? I think we should die() if %master is asked for and master is not
merging from anywhere by default (similarly, if @{-4} is asked and we
haven't switched that many times, we should die(), although I do not
remember how I coded that codepath---I presume it's the same codepath you
are touching with this round).
^ permalink raw reply
* Re: Status of GIT for Fedora 10 + gitweb's look
From: Aaron Gray @ 2009-03-20 18:02 UTC (permalink / raw)
To: Git Mailing List, J.H.
In-Reply-To: <49C3D252.4070009@eaglescrag.net>
Got it :-
http://www.somegitserver.com/git/gitweb.cgi
This should work straight out of the bag with Fedora.
Aaron
> - John 'Warthog9' Hawley
>
> Aaron Gray wrote:
>> On Fri, Mar 20, 2009 at 4:32 PM, J.H. <warthog19@eaglescrag.net
>> <mailto:warthog19@eaglescrag.net>> wrote:
>>
>> Considering that the version running on kernel.org
>> <http://kernel.org/> is
>>
>> 1) a Forked copy and
>> 2) Based on code thats over 3 years old
>>
>> My guess is that your missing a style sheet or a link in your apache
>> config for gitweb. The latest version should look more or less the
>> same as what's up on git.kernel.org <http://git.kernel.org/>. Take
>> a look in your browser and see if it can give you any hints as to
>> what the error is, what it can't download, etc.
>>
>> Your right its not picking up the CSS !
>> I have :-
>> /var/www/cgi-bin/
>> gitweb.cgi
>> gitweb.css
>> I am wondering whether its a configuration problem, permissions and
>> SELinux is in premissive mode. It looks like it may be Apache
>> configuration. I tried a test hello.cgi, and hello.css and Apache does
>> not seem to be reading '.css' file from cgi-bin.
>> I'll go over to the Apache group if noone can help me here.
>> Cheers,
>> Aaron
>>
>> - John 'Warthog9' Hawley
>>
>> Aaron Gray wrote:
>>
>> On Fri, Mar 20, 2009 at 4:21 PM, J.H. <warthog19@eaglescrag.net
>> <mailto:warthog19@eaglescrag.net>
>> <mailto:warthog19@eaglescrag.net
>> <mailto:warthog19@eaglescrag.net>>> wrote:
>>
>> If your on Fedora 10 to get gitweb installed all you should
>> have to
>> do is:
>>
>> yum install gitweb
>>
>> and you will be off and running.
>>
>> Its all running. It installed 1.6.0.6-1 I wanted to get
>> 1.6.2.1-1 only for the reason of gitweb.
>> gitweb appears as text rather than nice html tables. Does the
>> latest version look like http://git.kernel.org/ or do I have to
>> do my own HTML formatting ?
>> Cheers,
>> Aaron
>> - John 'Warthog9' Hawley
>>
>> Aaron Gray wrote:
>>
>> I tried installing Git on F10 and got the following :-
>>
>> [root@localhost ~]# rpm -Uvh git-1.6.2.1-1.fc9.i386.rpm
>> error: Failed dependencies:
>> perl-Git = 1.6.2.1-1.fc9 is needed by
>> git-1.6.2.1-1.fc9.i386
>> git = 1.6.0.6-3.fc10 is needed by (installed)
>> perl-Git-1.6.0.6-3.fc10.i386
>> git = 1.6.0.6-3.fc10 is needed by (installed)
>> git-svn-1.6.0.6-3.fc10.i386
>> git = 1.6.0.6-3.fc10 is needed by (installed)
>> git-daemon-1.6.0.6-3.fc10.i386
>> git = 1.6.0.6-3.fc10 is needed by (installed)
>> gitweb-1.6.0.6-3.fc10.i386
>>
>>
>> Can I install from source I could only find F9 SRPMS.
>>
>> What I am really after knowing is gitweb on the latest
>> version
>> 1.6.2.1 anything like the nice HTML layout on
>> http://git.kernel.org/ or do I have to do the html
>> formatting
>> myself in the perl code ?
>>
>> Many thanks in advance,
>>
>> Aaron
>>
>> -- To unsubscribe from this list: send the line
>> "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> <mailto:majordomo@vger.kernel.org>
>> <mailto:majordomo@vger.kernel.org
>> <mailto:majordomo@vger.kernel.org>>
>>
>> More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>>
>>
^ permalink raw reply
* Re: Tracking of local branches
From: Daniel Barkalow @ 2009-03-20 18:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git Mailing List, Johannes Schindelin
In-Reply-To: <7viqm4i1md.fsf@gitster.siamese.dyndns.org>
On Fri, 20 Mar 2009, Junio C Hamano wrote:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
> > I semi-successfully messed around in remote.c (format_tracking_info(),
> > stat_tracking_info()) to make it use branch->merge_name rather than
> > branch->merge. This makes "git status" work as expected ("Your branch
> > is... severely screwed.") for tracked local branches. (It's messed up
> > for remote ones but hey it was a first shot; merge[0]->dst is really
> > needed here I guess.)
> >
> > Now I could go after sha1_name.c and do the same,
> >
> > OR
> >
> > make it so that all branches have their merge member set up, uhm. Any
> > possible side effects?
>
> My gut feeling is that the latter if works should be preferable for
> consistency if nothing else.
>
> The "struct branch" hasn't changed ever since it was introduced by cf81834
> (Report information on branches from remote.h, 2007-09-10) and Daniel
> might know about some corner cases that rely on branch.merge not being set
> up for local ones, but honestly, I would think it would be a bug in the
> existing code if there were such cases.
As long as the semantics for tracking local branches are the same as for
tracking remote ones, I'm pretty sure there's nothing that relies on
branch.merge not being something local.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Nicolas Pitre @ 2009-03-20 18:42 UTC (permalink / raw)
To: Alexandre Bourget
Cc: Mike Hommey, Nicolas Sebrecht, Git List, Sam Hocevar,
Christian Couder
In-Reply-To: <1237559694.25283.46.camel@alexandre-desktop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 753 bytes --]
On Fri, 20 Mar 2009, Alexandre Bourget wrote:
> Le vendredi 20 mars 2009 à 08:13 +0100, Mike Hommey a écrit :
> > On Fri, Mar 20, 2009 at 01:54:02AM +0100, Nicolas Sebrecht wrote:
> > IMHO, we should find a better way to say that than to use the "index"
> > word at all. This obviously applies to all uses of "index" in french
> > where we avoided it in english.
> >
> > OTOH, the best I can find for "staging area" is "zone de préparation",
> > and that doesn't help finding a word for stage and unstage.
>
> "zone de préparation" sounds good to me.
What about:
"staging area" -> "zone de regroupement"
"to stage" -> "regrouper"
"to unstage" -> "dégrouper"
But admitedly this doesn't convay the actual meaning perfectly either.
Nicolas
^ permalink raw reply
* git quiltimport and git apply fail importing the PREEMPT_RT patches
From: Uwe Kleine-König @ 2009-03-20 19:06 UTC (permalink / raw)
To: git
Cc: Dan Nicholson, Eric W. Biederman, Gerrit Pape,
Johannes Schindelin, Junio C Hamano, Pierre Habouzit
Hello,
~/gsrc/linux-2.6$ git version
git version 1.5.6.5
(but with newer git I get the same)
~/gsrc/linux-2.6$ git checkout v2.6.29-rc8
Note: moving to "v2.6.29-rc8" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
~/gsrc/linux-2.6$ wget -O - http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.29-rc8-rt2-broken-out.tar.bz2 | tar xjf -
~/gsrc/linux-2.6$ git quiltimport --author="do <nt@kn.ow>"
origin.patch.bz2
Patch is empty. Was it split wrong?
hhmmm, quilt seems to support packed patches.
After bunzip2 origin.patch.bz2 and editing series accordingly I get:
~/gsrc/linux-2.6$ git quiltimport --author="do <nt@kn.ow>"
origin.patch
.dotest/patch:12188: space before tab in indent.
.platform_data = &markeins_flash_data,
.dotest/patch:19521: trailing whitespace.
.dotest/patch:20778: trailing whitespace.
[PERF_COUNT_BRANCH_INSTRUCTIONS] = 0x230e4, /* BR_ISSUED */
.dotest/patch:21259: trailing whitespace.
[PERF_COUNT_BRANCH_INSTRUCTIONS] = 0x230e4, /* BR_ISSUED */
.dotest/patch:21548: trailing whitespace.
[PERF_COUNT_BRANCH_INSTRUCTIONS] = 0x410a0, /* BR_PRED */
error: cannot apply binary patch to 'Documentation/logo.gif' without full index line
error: Documentation/logo.gif: patch does not apply
The hunk for Documentation/logo.gif looks as follows:
diff --git a/Documentation/logo.gif b/Documentation/logo.gif
deleted file mode 100644
index 2eae75f..0000000
Binary files a/Documentation/logo.gif and /dev/null differ
For me this looks complete enough to be applicable:
~/gsrc/linux-2.6$ git ls-tree HEAD:Documentation | grep logo.gif
100644 blob 2eae75fecfb965f49065c680063a40c594736ee5 logo.gif
(For these who want to look into the 2nd issue, here is an easier
reproduction recipe:
~/gsrc/linux-2.6$ git apply --index -C1 - << EOF
> diff --git a/Documentation/logo.gif b/Documentation/logo.gif
> deleted file mode 100644
> index 2eae75f..0000000
> Binary files a/Documentation/logo.gif and /dev/null differ
> EOF
error: cannot apply binary patch to 'Documentation/logo.gif' without full index line
error: Documentation/logo.gif: patch does not apply
)
For the first issue I have a patch that I'll send as a reply to this
mail. Luckily this works around the second problem, too :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Allan Caffee @ 2009-03-20 19:13 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johannes Schindelin, git
In-Reply-To: <20090320064813.6117@nanako3.lavabit.com>
On Thu, Mar 19, 2009 at 5:48 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
>> I'd start like this:
>>
>> enum color_name {
>> COLOR_RESET,
>> COLOR_RED,
>> COLOR_GREEN,
>> COLOR_YELLOW,
>> COLOR_BLUE,
>> COLOR_MAGENTA,
>> COLOR_CYAN,
>> COLOR_WHITE
>> };
>
> Looking for "COLOR_RED" in the archive gives:
>
> http://article.gmane.org/gmane.comp.version-control.git/109676
>
Duly noted. Perhaps those #defines should be relocated to color.h? If
we still wanted to provide a color_name type we could use
GIT_COLOR_NAME_RESET et al. That would give us something like:
#define GIT_COLOR_NORMAL ""
#define GIT_COLOR_RESET "\033[m"
#define GIT_COLOR_BOLD "\033[1m"
#define GIT_COLOR_RED "\033[31m"
#define GIT_COLOR_GREEN "\033[32m"
#define GIT_COLOR_YELLOW "\033[33m"
#define GIT_COLOR_BLUE "\033[34m"
#define GIT_COLOR_CYAN "\033[36m"
#define GIT_COLOR_BG_RED "\033[41m"
enum color_name {
GIT_COLOR_NAME_NORMAL
GIT_COLOR_NAME_RESET,
GIT_COLOR_NAME_RED,
GIT_COLOR_NAME_GREEN,
GIT_COLOR_NAME_YELLOW,
GIT_COLOR_NAME_BLUE,
GIT_COLOR_NAME_MAGENTA,
GIT_COLOR_NAME_CYAN,
GIT_COLOR_NAME_WHITE
GIT_COLOR_NAME_BG_RED
};
/*
* Map names to ANSI escape sequences. Consider putting this in color.c
* and providing color_name_get_ansi_code(enum color_name).
*/
const char* git_color_codes[] {
GIT_COLOR_RESET,
GIT_COLOR_BOLD,
GIT_COLOR_RED,
GIT_COLOR_GREEN,
GIT_COLOR_YELLOW,
GIT_COLOR_BLUE,
GIT_COLOR_CYAN,
GIT_COLOR_BG_RED,
};
That conveniently offers clients access to both the raw escape codes and
a clear type for storing/handling colors.
~Allan
^ permalink raw reply
* [PATCH] quiltimport: use quilt to do patch/series parsing and application
From: Uwe Kleine-König @ 2009-03-20 19:18 UTC (permalink / raw)
To: git
Cc: Dan Nicholson, Eric W. Biederman, Gerrit Pape,
Johannes Schindelin, Junio C Hamano, Pierre Habouzit
In-Reply-To: <20090320190617.GA28784@pengutronix.de>
quilt supports packed patches that are not recognized by quiltimport.
Instead of adding this feature explicitly, use quilt to do the dirty
work.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Dan Nicholson <dbn.lists@gmail.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Gerrit Pape <pape@smarden.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>
Cc: Pierre Habouzit <madcoder@debian.org>
---
Hello,
note I didn't test it deeply, but I succeeded to import the preempt-rt patch.
Things that might be worth testing are:
missing patches referenced in series
patch conflicts
Best regards
Uwe
git-quiltimport.sh | 51 ++++++++++++++++++++++++---------------------------
1 files changed, 24 insertions(+), 27 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 9a6ba2b..8b76682 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -51,6 +51,7 @@ if ! [ -d "$QUILT_PATCHES" ] ; then
echo "The \"$QUILT_PATCHES\" directory does not exist."
exit 1
fi
+export QUILT_PATCHES
# Temporary directories
tmp_dir="$GIT_DIR"/rebase-apply
@@ -62,31 +63,23 @@ tmp_info="$tmp_dir/info"
# Find the intial commit
commit=$(git rev-parse HEAD)
+# TODO: assert wc == index == HEAD
+# TODO: assert .pc doesn't exist
+
+# detach HEAD
+git checkout -q "$commit"
+
mkdir $tmp_dir || exit 2
-while read patch_name level garbage <&3
+while quilt unapplied > /dev/null
do
- case "$patch_name" in ''|'#'*) continue;; esac
- case "$level" in
- -p*) ;;
- ''|'#'*)
- level=;;
- *)
- echo "unable to parse patch level, ignoring it."
- level=;;
- esac
- case "$garbage" in
- ''|'#'*);;
- *)
- echo "trailing garbage found in series file: $garbage"
- exit 1;;
- esac
- if ! [ -f "$QUILT_PATCHES/$patch_name" ] ; then
- echo "$patch_name doesn't exist. Skipping."
- continue
- fi
+ # apply patch
+ quilt push || exit 3
+
+ patch_name="$(quilt top)";
+
echo $patch_name
- git mailinfo "$tmp_msg" "$tmp_patch" \
- <"$QUILT_PATCHES/$patch_name" >"$tmp_info" || exit 3
+ (quilt header; echo "---") | git mailinfo "$tmp_msg" "$tmp_patch" \
+ >"$tmp_info" || exit 3
test -s "$tmp_patch" || {
echo "Patch is empty. Was it split wrong?"
exit 1
@@ -129,10 +122,14 @@ do
fi
if [ -z "$dry_run" ] ; then
- git apply --index -C1 ${level:+"$level"} "$tmp_patch" &&
- tree=$(git write-tree) &&
- commit=$( (echo "$SUBJECT"; echo; cat "$tmp_msg") | git commit-tree $tree -p $commit) &&
- git update-ref -m "quiltimport: $patch_name" HEAD $commit || exit 4
+ quilt files | git update-index --add --remove --stdin &&
+ (echo "$SUBJECT"; echo; cat "$tmp_msg") | git commit -F - ||
+ exit 4
fi
-done 3<"$QUILT_PATCHES/series"
+done
+
+if [ -n "$dry_run" ] ; then
+ quilt pop -a;
+fi
+
rm -rf $tmp_dir || exit 5
--
1.6.2
^ permalink raw reply related
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Daniel Barkalow @ 2009-03-20 19:34 UTC (permalink / raw)
To: Junio C Hamano
Cc: Petr Baudis, Johannes Schindelin, Jeff King, Shawn O. Pearce,
Andreas Gruenbacher, git
In-Reply-To: <7vbprwi1ju.fsf@gitster.siamese.dyndns.org>
On Fri, 20 Mar 2009, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> >> "git branch" I agree with, but not "git update-ref". As plumbing, the
> >> latter should be much more allowing, feeding rope aplenty (but also
> >> allowing cool tricks we do not think about yet).
> >
> > We shouldn't allow creating insane ref names even with update-ref. That
> > way porcelains cannot rely on update-ref to sanity check the user's
> > crap. At most, maybe you might want to bypass this check with some force
> > switch, though I really can't quite imagine why.
>
> That's all nice and clean in theory, but it was more or less the same
> reasoning as what was behind the tightening not to allow anything but
> refs/heads pointed by HEAD, but you know what fell out of it. "Insane"
> and "crap" are in the eye of the beholder.
I think there's no possible use to being able to use update-ref to create
a ref that rev-parse can't be made to read. I think people will want to do
all sorts of things that are insane (I'd personally like some refs with
the basename "..."), but they're only likely to do insane things that
happen to work, rather than insane things that aren't prevented but still
don't work.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Jeff King @ 2009-03-20 19:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, B.Steinbrink, git
In-Reply-To: <7vwsakgjie.fsf@gitster.siamese.dyndns.org>
On Fri, Mar 20, 2009 at 11:02:33AM -0700, Junio C Hamano wrote:
> A naïve question.
>
> Has nobody suggested to use a really illegal characters such as ':'
> instead? After all, we are not talking something that you can use in
> refspecs but another way to spell branch names.
But if this goes into dwim_ref, then won't it be usable for refspecs? Or
even if it isn't, then imagine the user who doesn't know this and types
git push :foo
unwittingly deleting the remote "foo".
Yes, that is unlikely (since why would they push the tracking branch of
foo?), but I don't think it makes sense to argue that it doesn't have
confusing (and potentially dangerous) consequenses.
> Alternatively, '~master' may have a nice connotation that means "where
> master calls its home".
I think that is quite clever and doesn't have any meaning for a revision
specifier already. I like it.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: some French translation enhancements
From: Mike Hommey @ 2009-03-20 19:43 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Alexandre Bourget, Nicolas Sebrecht, Git List, Sam Hocevar,
Christian Couder
In-Reply-To: <alpine.LFD.2.00.0903201438570.30483@xanadu.home>
On Fri, Mar 20, 2009 at 02:42:50PM -0400, Nicolas Pitre wrote:
> On Fri, 20 Mar 2009, Alexandre Bourget wrote:
>
> > Le vendredi 20 mars 2009 à 08:13 +0100, Mike Hommey a écrit :
> > > On Fri, Mar 20, 2009 at 01:54:02AM +0100, Nicolas Sebrecht wrote:
> > > IMHO, we should find a better way to say that than to use the "index"
> > > word at all. This obviously applies to all uses of "index" in french
> > > where we avoided it in english.
> > >
> > > OTOH, the best I can find for "staging area" is "zone de préparation",
> > > and that doesn't help finding a word for stage and unstage.
> >
> > "zone de préparation" sounds good to me.
>
> What about:
>
> "staging area" -> "zone de regroupement"
> "to stage" -> "regrouper"
> "to unstage" -> "dégrouper"
>
> But admitedly this doesn't convay the actual meaning perfectly either.
It sounds kinda weird. Staging is not really close to gathering.
Mike
^ permalink raw reply
* Re: [PATCH v2 1/2] Introduce config variable "diff.defaultOptions"
From: Jeff King @ 2009-03-20 19:49 UTC (permalink / raw)
To: Keith Cascio; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.GSO.2.00.0903200911530.16242@kiwi.cs.ucla.edu>
On Fri, Mar 20, 2009 at 10:11:27AM -0700, Keith Cascio wrote:
> (a) numeric data (integers, chars, and floats): define magic value(s)
> that represent pristineness. Initialize all fields to PRISTINE.
> Later, if a field has any value other than PRISTINE, we know there was
> intent-to-change.
Good point. Though we will need to make sure that existing code is never
looking at PRISTINE values, which aren't likely to make much sense (I
suspect most will be INT_MAX or -1, as 0 is a reasonable value for many
of the options). This should be easy for most code, since the flattening
will get rid of PRISTINE. But remember that there are pieces of code
that do something like:
if (some_diff_option_is_set)
set_some_other_related_diff_option;
which will need to be PRISTINE-aware.
> > 3. Introduce some mechanism to help future callers get it right
> > (since otherwise assigning directly is a subtle bug).
>
> Yes, in the future, someone could write naughty code that sets a bit
> flag directly rather than using one of the macros. In C, we probably
> can't make that impossible. But generally speaking we can't protect
> against all forms of gross negligence.
I think you can safely ignore this complaint. I was worried we would
need something like:
DIFF_SET(&opt, stat_name_width, 10);
It is much easier to mistakenly write this as
opt.state_name_width = 10;
than it is to accidentally do a bit-set when there is a DIFF_OPT_SET
macro. That is, I think most people _want_ to use DIFF_OPT_SET because
it is easier to read and less typing.
So I saw this as a problem more for non-bit options, but you have
already addressed that above.
> All in all, turns out v3 requires surprisingly little modification of
> existing code outside of diff.h/diff.c. Actually, it only adds 3
> lines, that's it!!
>
> builtin-diff.c | 2 +
> builtin-log.c | 1 +
> diff.c | 112 ++++++++++++++++++++++++-
> diff.h | 17 +++-
>
> Shall I post v3?
Yes, please. It is much better to be talking about actual code than
hypotheticals.
-Peff
^ permalink raw reply
* Multiple Projects in one SVN Repository
From: Alexander Lippling @ 2009-03-20 19:51 UTC (permalink / raw)
To: git
Hi folks,
I'm evaluating git and I'm wondering how to manage the following
problem:
We have a svn repository which contains all of our projects. They
reference each other relatively (e.g. ../../../ProjectA.dll).
The projects are each of the following structure:
• <project>
• trunk
• current (this is needed, because relative links wouldn't work
without additionally changes when the trunk is branched)
• branches
• <branch name>
• tags
• <tag name>
How can I use git svn to manage this situation?
It is important, that the projects are checked out in a way so that
the relative links to other projects still work.
- Alexander
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Jeff King @ 2009-03-20 19:58 UTC (permalink / raw)
To: Allan Caffee; +Cc: Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <b2e43f8f0903201213o396de6c0sb52149ed1d889d1@mail.gmail.com>
On Fri, Mar 20, 2009 at 03:13:53PM -0400, Allan Caffee wrote:
> /*
> * Map names to ANSI escape sequences. Consider putting this in color.c
> * and providing color_name_get_ansi_code(enum color_name).
> */
> const char* git_color_codes[] {
> GIT_COLOR_RESET,
> GIT_COLOR_BOLD,
> GIT_COLOR_RED,
> GIT_COLOR_GREEN,
> GIT_COLOR_YELLOW,
> GIT_COLOR_BLUE,
> GIT_COLOR_CYAN,
> GIT_COLOR_BG_RED,
> };
>
> That conveniently offers clients access to both the raw escape codes and
> a clear type for storing/handling colors.
I want to point out one thing: an enum or a list like this is actually a
subset of the useful color codes that git can represent. Actual
configured colors can have attributes, foreground, and background
colors. So they need to be stored in a character array.
Adding an enum for GIT_COLOR_RED and using it throughout the code can be
helpful for simple cases, but it doesn't give you an easy way of saying
"red background, blue foreground". Maybe that is enough for git internal
usage, since we tend not to use backgrounds or attributes for defaults.
But maybe it makes more sense to do this as:
const char *ansi_color(enum color fg, enum color bg, enum attribute attr);
and return a pointer to a static array representing the color (and even
cycle through a list the way sha1_to_hex or git_path does). And you
could even use it to simplify and share code with the config color
parsing in color.c.
-Peff
^ permalink raw reply
* Re: Gnome chose Git
From: Jeff King @ 2009-03-20 20:03 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Pat Notz, Shawn O. Pearce, Git
In-Reply-To: <49C354CC.2020108@drmicha.warpmail.net>
On Fri, Mar 20, 2009 at 09:33:16AM +0100, Michael J Gruber wrote:
> > But do note that reflogs expire eventually, so you will want to also
> > look at gc.reflogexpire and gc.reflogexpireunreachable if you want to
> > keep this as an activity log forever.
>
> In any case, reflogs are local. I would assume that accountability
> tracking should be public and transparent. Depends on the use case, of
> course.
I think the use case was auditing "when did this code get into the repo,
and by whom". Which is inherently a local thing, since you are talking
about when it got into a central repo.
As for public and transparent, reflogs are only the database mechanism;
git already has the hooks in place for writing every ref change to this
mechanism, and it stores everything you need. They would just need some
way of publishing the information. I think it was you who suggested
notes, which would be one way of doing so; you could also publish tags
indexed by pusher (since we may or may not actually care about fast
lookup from commit to pusher here), or even just a web page.
-Peff
^ permalink raw reply
* Re: [PATCH RESEND] git-gui: Fix merge conflict display error when filename contains spaces
From: Markus Heidelberg @ 2009-03-20 20:11 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <49C34B5A.2040807@web.de>
Jens Lehmann, 20.03.2009:
> When a merge conflict occurs in a file with spaces in the filename,
> git-gui showed wrongly "LOCAL: deleted".
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> Resending this patch, as i have not received any reply so far.
You should send git-gui patches to Shawn O. Pearce <spearce@spearce.org>,
since he is the maintainer, and CCing the git list.
This will raise the chance of a reply. Or maybe it will simply be
commited to http://repo.or.cz/w/git-gui.git without a reply.
Markus
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Junio C Hamano @ 2009-03-20 20:13 UTC (permalink / raw)
To: Allan Caffee; +Cc: Nanako Shiraishi, Johannes Schindelin, git
In-Reply-To: <b2e43f8f0903201213o396de6c0sb52149ed1d889d1@mail.gmail.com>
Allan Caffee <allan.caffee@gmail.com> writes:
> On Thu, Mar 19, 2009 at 5:48 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>>> I'd start like this:
>>>
>>> enum color_name {
>>> COLOR_RESET,
>>> COLOR_RED,
>>> COLOR_GREEN,
>>> COLOR_YELLOW,
>>> COLOR_BLUE,
>>> COLOR_MAGENTA,
>>> COLOR_CYAN,
>>> COLOR_WHITE
>>> };
>>
>> Looking for "COLOR_RED" in the archive gives:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/109676
>>
>
> Duly noted. Perhaps those #defines should be relocated to color.h?
Heh, I did not even realize the above 109676 was referring to what I wrote
sometime ago.
> If we still wanted to provide a color_name type we could use
> GIT_COLOR_NAME_RESET et al. That would give us something like:
>
> #define GIT_COLOR_NORMAL ""
> #define GIT_COLOR_RESET "\033[m"
> #define GIT_COLOR_BOLD "\033[1m"
> #define GIT_COLOR_RED "\033[31m"
> #define GIT_COLOR_GREEN "\033[32m"
> #define GIT_COLOR_YELLOW "\033[33m"
> #define GIT_COLOR_BLUE "\033[34m"
> #define GIT_COLOR_CYAN "\033[36m"
> #define GIT_COLOR_BG_RED "\033[41m"
>
> enum color_name {
> GIT_COLOR_NAME_NORMAL
> GIT_COLOR_NAME_RESET,
> GIT_COLOR_NAME_RED,
> GIT_COLOR_NAME_GREEN,
> GIT_COLOR_NAME_YELLOW,
> GIT_COLOR_NAME_BLUE,
> GIT_COLOR_NAME_MAGENTA,
> GIT_COLOR_NAME_CYAN,
> GIT_COLOR_NAME_WHITE
> GIT_COLOR_NAME_BG_RED
> };
>
> /*
> * Map names to ANSI escape sequences. Consider putting this in color.c
> * and providing color_name_get_ansi_code(enum color_name).
> */
> const char* git_color_codes[] {
> GIT_COLOR_RESET,
> GIT_COLOR_BOLD,
> GIT_COLOR_RED,
> GIT_COLOR_GREEN,
> GIT_COLOR_YELLOW,
> GIT_COLOR_BLUE,
> GIT_COLOR_CYAN,
> GIT_COLOR_BG_RED,
> };
>
> That conveniently offers clients access to both the raw escape codes and
> a clear type for storing/handling colors.
Is git_color_codes[GIT_COLOR_NAME_FOO] supposed to give you GIT_COLOR_FOO?
Are you consolidating various pieces of physical color definition to one
place? That sounds sensible.
The corrent code does:
diff.c::
user says "meta" is "purple"
-> parse_diff_color_slot() says "meta" is slot 2
-> git_diff_basic_config() asks color_parse() to place the ANSI
representation of the "purple" in slot 2
-> code uses diff_get_color() to grab "meta" color from the slot
and sends it to the terminal
builtin-branch.c duplicates the exact same logic with a separate tables
and a set of slots. builtin-grep.c cheats and does not give the end user
any customizability, which needs to be fixed.
The "slots" are defined in terms of what the color is used for, the
meaning, e.g. "a line from the file before the change (DIFF_FILE_OLD)"; we
cannot avoid having application specific set of slots, but the parsing
should be able to share the code.
Once the slot number is known, we ask color_parse() to put the final
physical string (suitable for the terminal's consumption) to fill the
slot. But for that, I do not think git_color_codes[] nor GIT_COLOR_FOO
need to be exposed to the applications (i.e. "diff", "branch", "grep").
It is an implementation detail that color_parse() always uses ANSI escape
sequences right now, but we could encapsulate that in color.c and later
perhaps start looking up from the terminfo database, for example.
But that leaves the question of initialization. I think it would give a
better abstraction if we changed the type of values stored in a
color-table like diff.c::diff_colors[] from physical string sent to the
terminal to a color name (your enum color_name). Then the application
code can initialize their own color-table for each application-specific
slots with GIT_COLOR_NAME_RED, let the configuration mechanism to
customize it for the user. The codepath that currently assume the color
table contains strings that can be sent to the terminal need to be
modified to ask color_code_to_terminal_string(GIT_COLOR_NAME_YELLOW) or
something. Which means:
(1) Physical color representation should be known only to color.c. I.e.
#define GIT_COLOR_BOLD "\033[1m"
does not belong to color.h (public header for application consumption)
nor diff.c (application);
(2) Logical color name and the ways to convert it for terminal consumption
belongs to color.h. I.e.
enum color_name {
GIT_COLOR_NAME_YELLOW,
...
}
should go to color.h;
color_fprintf() should be changed to take "enum color_name color"
instead of "const char *color";
We would need strbuf variant for callers that prepare the string in
core before giving it to fprintf().
(3) "static const char *git_color_codes[]" would be an implementation
detail of the current "ANSI-only" one, hidden inside color.c, for
color_fprintf() and its strbuf cousin to look at.
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Julian Phillips @ 2009-03-20 20:28 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, B.Steinbrink, git
In-Reply-To: <20090320193650.GA26934@coredump.intra.peff.net>
On Fri, 20 Mar 2009, Jeff King wrote:
> On Fri, Mar 20, 2009 at 11:02:33AM -0700, Junio C Hamano wrote:
>
>> A na?ve question.
>>
>> Has nobody suggested to use a really illegal characters such as ':'
>> instead? After all, we are not talking something that you can use in
>> refspecs but another way to spell branch names.
>
> But if this goes into dwim_ref, then won't it be usable for refspecs? Or
> even if it isn't, then imagine the user who doesn't know this and types
>
> git push :foo
>
> unwittingly deleting the remote "foo".
>
> Yes, that is unlikely (since why would they push the tracking branch of
> foo?), but I don't think it makes sense to argue that it doesn't have
> confusing (and potentially dangerous) consequenses.
>
>> Alternatively, '~master' may have a nice connotation that means "where
>> master calls its home".
>
> I think that is quite clever and doesn't have any meaning for a revision
> specifier already. I like it.
I considered suggesting this earlier, but didn't as the behaviour is not
consistent. If you have a user named master then you have to type
'~master' (including quotes), if you don't you can type ~master, and you
always have to type '~' instead of ~. I didn't particularly fancy typing
all those quotes, and certainly not explaining the behaviour to people not
overly familiar with unix shell behaviour.
--
Julian
---
It's very inconvenient to be mortal -- you never know when everything may
suddenly stop happening.
^ permalink raw reply
* [PATCH] rebase -p: Preserve --no-ff merges
From: Anders Kaseorg @ 2009-03-20 20:38 UTC (permalink / raw)
To: gitster; +Cc: git
Previously, git rebase -p would turn some merges that had been constructed
with git merge --no-ff into fast-forwards. Now it reconstructs those
merges using --no-ff as well.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3dc659d..39545cc 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -275,7 +275,7 @@ pick_one_preserving_merges () {
if ! GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" \
GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
- output git merge $STRATEGY -m "$msg" \
+ output git merge --no-ff $STRATEGY -m "$msg" \
$new_parents
then
printf "%s\n" "$msg" > "$GIT_DIR"/MERGE_MSG
--
1.6.2
^ permalink raw reply related
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-20 20:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903201033310.10279@pacific.mpi-cbg.de>
On Fri, 20 Mar 2009, Johannes Schindelin wrote:
> On Thu, 19 Mar 2009, david@lang.hm wrote:
>
>> On Fri, 20 Mar 2009, Johannes Schindelin wrote:
>>
>>> I'd rather have more file types supported that are useful for the
>>> average user, than a generic XML merge driver that is useful to only a
>>> handful of people.
>>
>> we are both after the same thing,
>
> Apparently not...
>
>> the most use to the average user.
>>
>> you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely
>> seperate things that should have support developed seperatly.
>
> No. I look at SVG, ODF text, ODF spreadsheet, etc as things with
> completely different user interfaces.
>
> And likewise, the merge _helper_, the very thing the user will get to see,
> must have different user interfaces.
I absolutly agree with this. the UI and merge _helper_ tools for these
different file formats are completely different.
> And I see much more potential for this project to fail in those different
> user interfaces than something as _trivial_ (in relation) as XML merging.
and the key thing that I am saying is that a properly done XML merge may
eliminate the need to do _any_ development of a merge helper tool.
so rather than focusing on what the merge helper tool is going to be and
what the UI for that is, I am focusing on the potential to eliminate any
need to hae a specific helper tool by making it so that the marked up
files can be manipulated with the existing tools for that file type.
David Lang
^ permalink raw reply
* Re: [PATCH v4] Introduce %<branch> as shortcut to the tracked branch
From: Jeff King @ 2009-03-20 20:50 UTC (permalink / raw)
To: Julian Phillips
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Petr Baudis,
Andreas Gruenbacher, B.Steinbrink, git
In-Reply-To: <alpine.LNX.2.00.0903202022560.12211@reaper.quantumfyre.co.uk>
On Fri, Mar 20, 2009 at 08:28:28PM +0000, Julian Phillips wrote:
>> I think that is quite clever and doesn't have any meaning for a revision
>> specifier already. I like it.
>
> I considered suggesting this earlier, but didn't as the behaviour is not
> consistent. If you have a user named master then you have to type
> '~master' (including quotes), if you don't you can type ~master, and you
> always have to type '~' instead of ~. I didn't particularly fancy typing
> all those quotes, and certainly not explaining the behaviour to people not
> overly familiar with unix shell behaviour.
Oh, good point. I wasn't thinking it through. My initial thought was
that there is no problem conflicting with a file ~master/foo, since you
generally don't want to use absolute paths that are likely outside your
git repository. But of course the shell doesn't know this and will screw
you, which I failed to consider.
-Peff
^ permalink raw reply
* Re: Minimum libCurl version for git
From: Junio C Hamano @ 2009-03-20 21:44 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git list, Daniel Stenberg, Nick Hengeveld, Mike Hommey
In-Reply-To: <e2b179460903201059j20e37c1cr7ccfa4b42e45c9d9@mail.gmail.com>
Mike Ralphson <mike.ralphson@gmail.com> writes:
> Going forward there are various options:
>
> 1. Do nothing - go with the status quo.
>
> 2. Correct the #ifdefs for CURLOPT_SSLKEY
>
> 3. Drop the #ifdefs for CURLOPT_SSLKEY entirely and make 7.9.3 our
> minimum supported version. I feel slightly embarrassed about that, as
> that's exactly the version I have here on AIX (unless I wrest it back
> from being sysadmin-installed to being user-supported). Add a check to
> the Makefile and error if libCurl is too old.
>
> 4. Drop all current #ifdefs and one of the deprecated symbol names.
> Our minimum supported libCurl version would be 7.9.8 from Jun 2002.
>
> 5. Drop all current #ifdefs and both of the deprecated symbol names.
> Our minimum supported libCurl version would be 7.10.8 from Nov 2003.
>
> 6. Warn (not error) if libCurl is older than say the 3 years suggested
> by Daniel. This would seem to require periodic updates to the Makefile
> check.
>
> I'm happy to whip up a patch if required, but I thought a series of
> mutually-exclusive alternative patches would be confusing without
> prior agreement on the approach.
>
> Mike
>
> [1] http://cool.haxx.se/cvs.cgi/curl/docs/libcurl/symbols-in-versions?rev=HEAD&content-type=text/vnd.viewcvs-markup
Thanks for a detailed analysis.
My gut feeling is we should be able to do 3 safely.
I am not sure if you are reading the "deprecated" column correctly,
though:
Name Introduced Deprecated Removed
CURLINFO_HTTP_CODE 7.4.1 7.10.8
CURLOPT_INFILE 7.1 7.9.7
These two symbols are what we do use in our code, so the
deprecated/removed column would give us the upper bound of the versions,
not the lower bound.
We can have these two macro definitions on our side
#if curl older than 7.10.8
#define CURLINFO_RESPONSE_CODE CURLINFO_HTTP_CODE
#endif
#if curl older than 7.9.7
#define CURLOPT_READDATA CURLOPT_INFILE
#endif
for backward compatibility, while writing our code to the recent API by
using CURLINFO_RESPONSE_CODE and CURLOPT_READDATA, and people with older
curl would not have to suffer a bit.
So I think your 4 and 5 are non issues.
But this is without having a handy tally of what releases of various
distros shipped their libcurl with. If we had a table like this...
Distro Last update libcurl version
----------------------------------------------------------------
Debian 3.1 sarge 2005-06-06 ???
Debian 4.0 etch 2009-02-10 (4.0r7) 7.15.5
Debian 5.0 lenny 2009-02-14 7.18.2
... then we could say "This is git, a tool primarily for developers to
keep track of sources; nobody would be running on a box that was updated
the last time four years ago, so we can safely assume libcurl more recent
than version ???".
It would also be valid to argue that "4.0 etch may have been updated last
month, but libcurl 7.15.5 has been available on the release a lot before
that, as of 200X-XX-XX, which is more than N years ago, which makes it
safe to assume that assuming 7.15.5 or later is fine for Debian folks; do
not get fooled by the date of last update," in which case it would be good
to have entry for the original release date.
For non-commercial Linux folks I think it should be Ok to assume not too
ancient libcurl, but I have no clue on how the table like the above would
look like for things like AIX, IRIX, HPUX etc. ... Oh, and SCO.
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 21:48 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Junio C Hamano, Petr Baudis, Jeff King, Shawn O. Pearce,
Andreas Gruenbacher, git
In-Reply-To: <alpine.LNX.1.00.0903201515490.19665@iabervon.org>
Hi,
On Fri, 20 Mar 2009, Daniel Barkalow wrote:
> On Fri, 20 Mar 2009, Junio C Hamano wrote:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > >> "git branch" I agree with, but not "git update-ref". As plumbing,
> > >> the latter should be much more allowing, feeding rope aplenty (but
> > >> also allowing cool tricks we do not think about yet).
> > >
> > > We shouldn't allow creating insane ref names even with update-ref.
> > > That way porcelains cannot rely on update-ref to sanity check the
> > > user's crap. At most, maybe you might want to bypass this check with
> > > some force switch, though I really can't quite imagine why.
> >
> > That's all nice and clean in theory, but it was more or less the same
> > reasoning as what was behind the tightening not to allow anything but
> > refs/heads pointed by HEAD, but you know what fell out of it.
> > "Insane" and "crap" are in the eye of the beholder.
>
> I think there's no possible use to being able to use update-ref to
> create a ref that rev-parse can't be made to read. I think people will
> want to do all sorts of things that are insane (I'd personally like some
> refs with the basename "..."), but they're only likely to do insane
> things that happen to work, rather than insane things that aren't
> prevented but still don't work.
Of course, you are forgetting that rev-parse may well have been able to
grok such a ref at some stage.
And at that stage, it becomes not a user error, but a _huge_ mistake by
us, the Git developers.
Don't blame the user
(http://www.schneier.com/blog/archives/2009/03/it_security_bla.html).
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