* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Andreas Schwab @ 2009-11-18 0:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mike Hommey, Jeff King, Matthieu Moy, git, Karl Chen
In-Reply-To: <7v8we4er0t.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>
>> Mike Hommey <mh@glandium.org> writes:
>>
>>> On Tue, Nov 17, 2009 at 02:34:26AM -0500, Jeff King wrote:
>>>> Maybe:
>>>>
>>>> A leading path component of "~user" is expanded to the home directory
>>>> of "user"; "~" is expanded to the home directory of the user running
>>>> git.
>>>>
>>>> would be more clear?
>>>
>>> Add "real" before "user running git" and you have my vote. Or maybe
>>> using the effective user would be better, and the patch should use
>>> geteuid() instead of getuid(), I don't know. ident.c uses getuid(), but
>>> I'm wondering if that's what it should use (although it doesn't seem to
>>> have been a problem to anyone)
>>
>> "~" should just expand to the value of $HOME, like in the shell,
>> independent of the real home directory of the real or effective user.
>
> How should this interact with installations that run gitosis/gitlite that
> use shared account, giving user identity via the ssh key?
Sorry, I don't know enough about such an installation to be able to
answer that.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH v3] Speed up bash completion loading
From: Jonathan Nieder @ 2009-11-18 0:49 UTC (permalink / raw)
To: Stephen Boyd
Cc: SZEDER Gábor, Junio C Hamano, Kirill Smelkov,
Sverre Rabbelier, Shawn O. Pearce, git
In-Reply-To: <4B010D42.4090902@gmail.com>
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
On this slow laptop, this decreases the time to load
git-completion.bash from about 500 ms to about 175 ms.
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: SZEDER Gábor <szeder@ira.uka.de>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
I do not know whether it is kosher to carry over an ack like this.
The interdiff is small, for what it’s worth:
$ git branch jn/faster-completion-startup ee41299
$ git diff jn/faster-completion-startup
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index bd22802..f67254d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -330,7 +330,7 @@ __git_list_merge_strategies ()
}'
}
-unset __git_merge_strategies
+__git_merge_strategies=
# 'git merge -s help' (and thus detection of the merge strategy
# list) fails, unfortunately, if run outside of any git working
# tree. __git_merge_strategies is set to the empty string in
@@ -501,10 +501,10 @@ __git_list_all_commands ()
done
}
-unset __git_all_commands
+__git_all_commands=
__git_compute_all_commands ()
{
- : ${__git_all_commands=$(__git_list_all_commands)}
+ : ${__git_all_commands:=$(__git_list_all_commands)}
}
__git_list_porcelain_commands ()
@@ -593,11 +593,11 @@ __git_list_porcelain_commands ()
done
}
-unset __git_porcelain_commands
+__git_porcelain_commands=
__git_compute_porcelain_commands ()
{
__git_compute_all_commands
- : ${__git_porcelain_commands=$(__git_list_porcelain_commands)}
+ : ${__git_porcelain_commands:=$(__git_list_porcelain_commands)}
}
__git_aliases ()
Please let me know if I have commited a faux pas.
Stephen Boyd wrote:
>> Junio C Hamano wrote:
>>> Wouldn't
>>>
>>> : ${__gms:=$(command)}
>>>
>>> run command only until it gives a non-empty string?
>
> Why not do this for all of the lists and not just the merge strategies?
I generally find set-if-unset a little more intuitive. But some users
might install and try out git completion before realizing the need to
install git, and in this case set-if-empty gives better behavior.
Thanks.
contrib/completion/git-completion.bash | 76 +++++++++++++++++---------------
1 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e3ddecc..1223a07 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -21,13 +21,7 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
-#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -324,12 +318,8 @@ __git_remotes ()
done
}
-__git_merge_strategies ()
+__git_list_merge_strategies ()
{
- if [ -n "${__git_merge_strategylist-}" ]; then
- echo "$__git_merge_strategylist"
- return
- fi
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
s/\.$//
@@ -339,8 +329,17 @@ __git_merge_strategies ()
p
}'
}
-__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
+
+__git_merge_strategies=
+# 'git merge -s help' (and thus detection of the merge strategy
+# list) fails, unfortunately, if run outside of any git working
+# tree. __git_merge_strategies is set to the empty string in
+# that case, and the detection will be repeated the next time it
+# is needed.
+__git_compute_merge_strategies ()
+{
+ : ${__git_merge_strategies:=$(__git_list_merge_strategies)}
+}
__git_complete_file ()
{
@@ -474,27 +473,24 @@ __git_complete_remote_or_refspec ()
__git_complete_strategy ()
{
+ __git_compute_merge_strategies
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategies"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategies" "" "${cur##--strategy=}"
return 0
;;
esac
return 1
}
-__git_all_commands ()
+__git_list_all_commands ()
{
- if [ -n "${__git_all_commandlist-}" ]; then
- echo "$__git_all_commandlist"
- return
- fi
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
do
@@ -504,17 +500,18 @@ __git_all_commands ()
esac
done
}
-__git_all_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
-__git_porcelain_commands ()
+__git_all_commands=
+__git_compute_all_commands ()
+{
+ : ${__git_all_commands:=$(__git_list_all_commands)}
+}
+
+__git_list_porcelain_commands ()
{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
- echo "$__git_porcelain_commandlist"
- return
- fi
local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
+ __git_compute_all_commands
+ for i in "help" $__git_all_commands
do
case $i in
*--*) : helper pattern;;
@@ -595,8 +592,13 @@ __git_porcelain_commands ()
esac
done
}
-__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
+
+__git_porcelain_commands=
+__git_compute_porcelain_commands ()
+{
+ __git_compute_all_commands
+ : ${__git_porcelain_commands:=$(__git_list_porcelain_commands)}
+}
__git_aliases ()
{
@@ -1088,7 +1090,8 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __git_compute_all_commands
+ __gitcomp "$__git_all_commands
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1444,7 +1447,8 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __git_compute_merge_strategies
+ __gitcomp "$__git_merge_strategies"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1545,7 +1549,8 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __git_compute_all_commands
+ __gitcomp "$__git_all_commands" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2142,7 +2147,8 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __git_compute_porcelain_commands
+ __gitcomp "$__git_porcelain_commands $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCHv3] Add branch management for releases to gitworkflows
From: Raman Gupta @ 2009-11-18 0:19 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nanako Shiraishi, git, gitster, skillzero
In-Reply-To: <200911151807.15726.trast@student.ethz.ch>
Thomas Rast wrote:
> Nanako Shiraishi wrote:
>> Quoting rocketraman@fastmail.fm
>>> Add a basic introduction to the branch management undertaken during a
>>> git.git release
> [...]
>> Here are some corrections that can be applied on top of your change.
Ok. I am submitting another patch on top of yours and Nanako's with some additional explanation and guidance, as well as some rewording and reorganization. I also corrected an error that skillzero caught earlier.
I think the basics of Junio's message re rotating 'master', 'maint', and 'maint-one-rev-old' are already in the document, so I haven't added anything explicit regarding that.
> At the bottom there are some more corrections on top of your combined
> patches. At this point I would prefer to squash everything into a
> single patch, but if you want to keep them separate I can come up with
> a commit message.
Squashing is fine with me.
> All but the last change are just intended to "sound nicer". Since I'm
> not a native speaker either (I'm not sure any have commented in the
> threads so far), it would probably be nice to get some additional
> comments.
I *am* a native English speaker. Sadly, its the *only* language I speak, read, and write. However, additional comments would definitely be nice.
> As for the last hunk, I felt it was misleading to state 'pu' uses the
> same process as 'next' immediately after mentioning the "next will be
> rewound shortly" messages that Junio sends out. Such a message is
> never required for 'pu' because (as is already explained in the
> manpage) the "contract" is that the maintainer may rewind it anytime
> he likes.
I added it back in with the additional explanation that the public announcement is not necessary. I think its important for a reader to understand how the 'pu' branch might be maintained. Besides, the title of the section includes pu, so some discussion around pu is warranted, or the title should change also.
> Apart from that, I'm not entirely happy with the way the "release" and
> "maint, after a feature release" sections are tangled yet. There are
> several forward and backward references between them. I see that you
> are trying to drive home the point that maint needs to be contained in
> master. Can't we just deal with that in the "feature release"
> section?
Agree. I reworded the sections to untangle the information somewhat. Let me know what you think.
-- 8< --
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 490346c..91c0eea 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -216,10 +216,17 @@ Assuming you are using the merge approach discussed above, when you
are releasing your project you will need to do some additional branch
management work.
-Since 'master' is supposed to be always a superset of 'maint', you
-should first make sure that condition holds.
+A feature release is created from the 'master' branch, since 'master'
+tracks the commits that should go into the next feature release.
-.Make sure 'maint' fast-forwards to 'master'
+The 'master' branch is supposed to be a superset of 'maint'. If this
+condition does not hold, then 'maint' contains some commits that
+are not included on 'master'. The fixes represented by those commits
+will therefore not be included in your feature release.
+
+To verify that 'master' is indeed a superset of 'maint', use git log:
+
+.Verify 'master' is a superset of 'maint'
[caption="Recipe: "]
=====================================
git log master..maint
@@ -228,8 +235,8 @@ git log master..maint
This command should not list any commits. Otherwise, check out
'master' and merge 'maint' into it.
-Then you can tag the tip of
-'master' with a tag indicating the release version.
+Now you can proceed with the creation of the feature release. Apply a
+tag to the tip of 'master' indicating the release version:
.Release tagging
[caption="Recipe: "]
@@ -237,19 +244,15 @@ Then you can tag the tip of
`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
=====================================
-Similarly, for a maintenance release, 'maint' is tracking the commits
-to be released. Therefore, simply replace 'master' above with
-'maint'.
-
-You need to push the new tag to a public git server
-when you push the updated 'master' (or 'maint',
-if you are making a maintenance release). See
-"DISTRIBUTED WORKFLOWS" below. This makes the tag available to
+You need to push the new tag to a public git server (see
+"DISTRIBUTED WORKFLOWS" below). This makes the tag available to
others tracking your project. The push could also trigger a
post-update hook to perform release-related items such as building
-release tarballs and preformatted documentation pages. You may want
-to defer the push until after you have updated your 'maint' branch
-(see the next section).
+release tarballs and preformatted documentation pages.
+
+Similarly, for a maintenance release, 'maint' is tracking the commits
+to be released. Therefore, in the steps above simply tag and push
+'maint' rather than 'master'.
Maintenance branch management after a feature release
@@ -281,13 +284,10 @@ code so that maintenance fixes can be tracked for the current release:
* `git merge --ff-only master`
=====================================
-This should fast-forward 'maint' from 'master'. If it is not a
-fast-forward, then 'maint' contained some commits that were not included on
-'master', which means that the recent feature release could be missing
-some fixes made on 'maint'. If that happens, you need to go back to the
-previous "Branch management for a release" step. Correcting this mistake
-becomes messy if you have already pushed the release tag, and that is why
-you should wait until finishing this step before pushing the release out.
+If the merge fails because it is not a fast-forward, then it is
+possible some fixes on 'maint' were missed in the feature release.
+This will not happen if the content of the branches was verified as
+described in the previous section.
Branch management for next and pu after a feature release
@@ -297,7 +297,7 @@ After a feature release, the integration branch 'next' may optionally be
rewound and rebuilt from the tip of 'master' using the surviving
topics on 'next':
-.Update maint to new release
+.Rewind and rebuild next
[caption="Recipe: "]
=====================================
* `git checkout next`
@@ -319,6 +319,10 @@ so.
If you do this, then you should make a public announcement indicating
that 'next' was rewound and rebuilt.
+The same rewind and rebuild process may be followed for 'pu'. A public
+announcement is not necessary since 'pu' is a throw-away branch, as
+described above.
+
DISTRIBUTED WORKFLOWS
---------------------
--
1.6.2
^ permalink raw reply related
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-18 0:16 UTC (permalink / raw)
To: J.H.; +Cc: Junio C Hamano, git, Jakub Narebski
In-Reply-To: <4B032AC8.4@eaglescrag.net>
> For starters I think overriding the /~<user> (specifically the ~ here) is
> going to be a bad idea no matter what you do and gives the wrong impression
> about what / how the request is being responded to. You might want to try
> and pick a different delimiter or re-work the rule so that you could have
> something like:
>
> http://git.kernel.org/<gitweb urls>
> http://git.kernel.org/user/<gitweb urls>
>
> Your also, likely, going to need to take into account things like index.cgi
> and gitweb.cgi in the url as things like:
>
> http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=summary
> http://git.kernel.org/gitweb.cgi?p=bluetooth/bluez-gnome.git;a=summary
>
<VirtualHost git.abstraction.fr:80>
ServerAdmin webmaster@abstraction.fr
ServerName git.abstraction.fr:80
DocumentRoot /var/www/sylvain/git.abstraction.fr/html
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/www/sylvain/git.abstraction.fr/log/access.log combined
ErrorLog /var/www/sylvain/git.abstraction.fr/log/error.log
ServerSignature On
RewriteEngine on
RewriteLog /var/www/sylvain/git.abstraction.fr/log/rewrite.log
RewriteLogLevel 3
RewriteRule ^/$
/cgi-bin/gitweb.cgi [QSA,L,PT]
RewriteRule ^/gitweb.cgi$
/cgi-bin/gitweb.cgi [QSA,L,PT]
RewriteRule ^/\~([^\/]+)/?$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
RewriteRule ^/\~([^\/]+)/gitweb.cgi$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
RewriteRule ^/users/([^\/]+)/?$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
RewriteRule ^/users/([^\/]+)/gitweb.cgi$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin/">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
Alias /gitweb /usr/share/gitweb/
<Directory "/usr/share/gitweb/">
AllowOverride None
Options +MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
You can test here :
http://git.abstraction.fr/
http://git.abstraction.fr/gitweb.cgi
http://git.abstraction.fr/~sylvain/
http://git.abstraction.fr/~sylvain/gitweb.cgi
http://git.abstraction.fr/users/sylvain/
http://git.abstraction.fr/users/sylvain/gitweb.cgi
The dns record is fresh. If your dns is not up to date the ip is 88.191.254.60.
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-18 0:14 UTC (permalink / raw)
To: J.H.; +Cc: Junio C Hamano, Sylvain Rabot, git, Jakub Narebski
In-Reply-To: <4B0338F9.9000608@eaglescrag.net>
"J.H." <warthog19@eaglescrag.net> writes:
> Junio C Hamano wrote:
>
>> I am not objecting but showing my ignorance, but why is it a bad idea to
>> allow
>>
>> http://git.kernel.org/~junio/git.git
>>
>> to map to /home/junio/pubilic_git/git.git when
>>
>> http://www.kernel.org/~junio/index.html
>>
>> maps to /home/junio/public_html/index.html already?
>
> I'm not objecting to the mapping, I'm objecting to the use of the ~
> specifically, since that's the default for mod_userdir - it's more or
> less a race condition waiting to happen with respect to does
> mod_rewrite get to and process it first or does mod_userdir.
Yeah, thanks for explaining it to me. I realized the overlap between them
immediately after I sent the message out X-<.
http://site.xz/users/gitster/git.git
(or anything that does not override "~name") sounds good to me.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-18 0:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Nanako Shiraishi, Michael J Gruber,
Jonathan Nieder, git, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <7vzl6kd9t3.fsf@alter.siamese.dyndns.org>
On Wed, Nov 18, 2009 at 1:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Exactly. That is where we disagree. The funny "@stage" does not convey
> the fact that it is affecting how "git diff" operates, like any other
> option like "-R" does in "git diff -R" command line does. Now the user
> needs to know git commands take -option like other normal tools do, but in
> addition they need to remember that an oddball "diff" subcommand takes
> "@funny" in addition to the usual "-option".
Right now there are 4 modes of operations, the user would need to
remember all of them... instead, the @stage pointer would reduce the
modes to 1, so the user would have to look on the man-page only once,
quickly.
Also, to me it feels more natural to do "git diff b a" rather than
"git diff -R a b", therefore "git diff @stage HEAD" beats "git diff -R
--cached HEAD".
Moreover, I wonder if these modes are really properly implemented. For
example, what's with these funky commands:
git diff HEAD master next <- shouldn't only 2 be allowed?
git diff HEAD..master HEAD..next
Anyway, you are making the assumption that users actually use, and
understand the different modes of operation, but I'm claiming most of
them don't, and one of the reasons could be that they are not
intuitive.
> How would that be an improvement?
It might make people actually start using the stage, which again, it
seems apparent to me they don't. This can be easily interpreted from
reading the git user survey (only 23% of the people use "git add -i /
-p", and 15% "git add -u / -A" often), but if you don't believe so, we
can wait for the next one and ask the question explicitly.
--
Felipe Contreras
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: J.H. @ 2009-11-18 0:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sylvain Rabot, git, Jakub Narebski
In-Reply-To: <7vskccaf4q.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> "J.H." <warthog19@eaglescrag.net> writes:
>
>> For starters I think overriding the /~<user> (specifically the ~ here)
>> is going to be a bad idea no matter what you do and gives the wrong
>> impression about what / how the request is being responded to. You
>> might want to try and pick a different delimiter or re-work the rule
>> so that you could have something like:
>>
>> http://git.kernel.org/<gitweb urls>
>> http://git.kernel.org/user/<gitweb urls>
>
> I am not objecting but showing my ignorance, but why is it a bad idea to
> allow
>
> http://git.kernel.org/~junio/git.git
>
> to map to /home/junio/pubilic_git/git.git when
>
> http://www.kernel.org/~junio/index.html
>
> maps to /home/junio/public_html/index.html already?
I'm not objecting to the mapping, I'm objecting to the use of the ~
specifically, since that's the default for mod_userdir - it's more or
less a race condition waiting to happen with respect to does mod_rewrite
get to and process it first or does mod_userdir.
Case in point should:
assuming that www.example.com (to get away from the specifics of
kernel.org) is running gitweb but you also wanted to allow users to show
their ~/public_html directories then
http://www.example.org/~junio/
could be ambiguous as to what should / is servicing the url.
Now in reality it should work because of how apache is setup, but I
would argue it's a bad practice to overload the '~' designator like that
for use in gitweb specifically.
If you have mod_userdir disabled / not available this isn't an issue,
but making that assumption might be a bad idea.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: J.H. @ 2009-11-17 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sylvain Rabot, git, Jakub Narebski
In-Reply-To: <7vskccaf4q.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> "J.H." <warthog19@eaglescrag.net> writes:
>
>> For starters I think overriding the /~<user> (specifically the ~ here)
>> is going to be a bad idea no matter what you do and gives the wrong
>> impression about what / how the request is being responded to. You
>> might want to try and pick a different delimiter or re-work the rule
>> so that you could have something like:
>>
>> http://git.kernel.org/<gitweb urls>
>> http://git.kernel.org/user/<gitweb urls>
>
> I am not objecting but showing my ignorance, but why is it a bad idea to
> allow
>
> http://git.kernel.org/~junio/git.git
>
> to map to /home/junio/pubilic_git/git.git when
>
> http://www.kernel.org/~junio/index.html
>
> maps to /home/junio/public_html/index.html already?
I'm not objecting to the mapping, I'm objecting to the use of the ~
specifically, since that's the default for mod_userdir - it's more or
less a race condition waiting to happen with respect to does mod_rewrite
get to and process it first or does mod_userdir.
Case in point should:
assuming that www.example.com (to get away from the specifics of
kernel.org) is running gitweb but you also wanted to allow users to show
their ~/public_html directories then
http://www.example.org/~junio/
could be ambiguous as to what should / is servicing the url.
Now in reality it should work because of how apache is setup, but I
would argue it's a bad practice to overload the '~' designator like that
for use in gitweb specifically.
If you have mod_userdir disabled / not available this isn't an issue,
but making that assumption might be a bad idea.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-17 23:46 UTC (permalink / raw)
To: J.H.; +Cc: Junio C Hamano, Sylvain Rabot, git, Jakub Narebski
In-Reply-To: <4B032AC8.4@eaglescrag.net>
"J.H." <warthog19@eaglescrag.net> writes:
> For starters I think overriding the /~<user> (specifically the ~ here)
> is going to be a bad idea no matter what you do and gives the wrong
> impression about what / how the request is being responded to. You
> might want to try and pick a different delimiter or re-work the rule
> so that you could have something like:
>
> http://git.kernel.org/<gitweb urls>
> http://git.kernel.org/user/<gitweb urls>
I am not objecting but showing my ignorance, but why is it a bad idea to
allow
http://git.kernel.org/~junio/git.git
to map to /home/junio/pubilic_git/git.git when
http://www.kernel.org/~junio/index.html
maps to /home/junio/public_html/index.html already?
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-17 23:40 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: J.H., git, Jakub Narebski
In-Reply-To: <7fce93be0911171454i61e995a1ob0bf80013bcb0727@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> On Tue, Nov 17, 2009 at 23:10, Junio C Hamano <gitster@pobox.com> wrote:
>> Sylvain Rabot <sylvain@abstraction.fr> writes:
>>
>>>> Wouldn't it be a good idea to somehow make this work well together with
>>>> the --user-path feature of git-daemon?
>>>>
>>>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>>>> but more like ~/public_git, as this is like ~/public_html but for git
>>>> repositories. Then the end users will browse
>>>
>>> As I said, it's configuration :)
>>
>> Wrong answer.
>
> Am I passing a test ?
Sorry, but that wasn't what I meant.
>> Exactly because it is configurable, the document that outlines the
>> recommended practice should suggest the best convention. My point was
>> that it is likely to be tied to "git"-ness of the specified directory
>> under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
>> name tied to "gitweb"-ness in this document.
>
> Again, git is a brand new world for me and I don't know any of his
> conventions yet.
I do not see this as git-specific conventions.
But suggesting ~/gitweb is perfectly excusable, especially if you did not
know that git-daemon can respond to "git://host/~user/".
John warthog19 (hmm, I thought he used to be warthog9) explained the above
much better than I did. People tend to cut and paste without thinking, so
we should describe a good default layout in our documentation.
> I am not trying to impose my own conventions, I am just proposing an idea.
Yeah, I know. We are all in this to improve things for people who follow
us.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-11-17 23:13 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, J. Bruce Fields, Nanako Shiraishi,
Michael J Gruber, Jonathan Nieder, git, Hannu Koivisto, Jeff King,
Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <94a0d4530911171506o2b08954bw4acba8ea9193e65d@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> If the goal of the change is to make things more user-friendly, then
> I'd say "git diff HEAD @stage" is better than "git diff
> --tree-vs-staged HEAD".
Exactly. That is where we disagree. The funny "@stage" does not convey
the fact that it is affecting how "git diff" operates, like any other
option like "-R" does in "git diff -R" command line does. Now the user
needs to know git commands take -option like other normal tools do, but in
addition they need to remember that an oddball "diff" subcommand takes
"@funny" in addition to the usual "-option".
How would that be an improvement?
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-17 23:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Nanako Shiraishi, Michael J Gruber,
Jonathan Nieder, git, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <7v4ooseqvb.fsf@alter.siamese.dyndns.org>
On Wed, Nov 18, 2009 at 12:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> That could be easily fixed by making explicit in the syntax that these
>> are not typical refs: i.e. @stage and @work.
>
> The message I get from that suggestion is that the most sensible approach,
> if we are going to add something from this discussion to "git diff", is to
> do what you did _not_ quote from my message, which is:
>
> As to --tree-vs-index counterproposal (was it a counterproposal?),
> except for that I think they are too long to type in practice and need
> to be shortened to be useful, I do not have a fundamental objection
> against it.
>
> IOW, this is about options, and should not be done as syntax sugar that
> does a half-baked job of pretending to be refs.
Sorry, I thought your only objection to STAGE and WORKTREE was that
they were not clearly differentiated, and my proposal gets rid of that
issue. Now I fail to see what's the problem since you didn't explain
what's wrong with adding syntactic sugar.
If the goal of the change is to make things more user-friendly, then
I'd say "git diff HEAD @stage" is better than "git diff
--tree-vs-staged HEAD".
--
Felipe Contreras
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: J.H. @ 2009-11-17 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sylvain Rabot, git, Jakub Narebski
In-Reply-To: <7vd43gerak.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
>>> Wouldn't it be a good idea to somehow make this work well together with
>>> the --user-path feature of git-daemon?
>>>
>>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>>> but more like ~/public_git, as this is like ~/public_html but for git
>>> repositories. Then the end users will browse
>> As I said, it's configuration :)
>
> Wrong answer.
>
> Exactly because it is configurable, the document that outlines the
> recommended practice should suggest the best convention. My point was
> that it is likely to be tied to "git"-ness of the specified directory
> under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
> name tied to "gitweb"-ness in this document.
For starters I think overriding the /~<user> (specifically the ~ here)
is going to be a bad idea no matter what you do and gives the wrong
impression about what / how the request is being responded to. You
might want to try and pick a different delimiter or re-work the rule so
that you could have something like:
http://git.kernel.org/<gitweb urls>
http://git.kernel.org/user/<gitweb urls>
Your also, likely, going to need to take into account things like
index.cgi and gitweb.cgi in the url as things like:
http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=summary
http://git.kernel.org/gitweb.cgi?p=bluetooth/bluez-gnome.git;a=summary
are likely to be correct for almost all installations.
I would agree with Junio on this, if your suggesting a possible practice
you should focus on the best convention. Making it depend on something
like ~/gitweb doesn't make it clear or obvious enough to a user, or an
administrator, that the directory is being exported for the world to
see. There is a reason it's called ~/public_html.
Keep in mind most people are going to read the documentation and
copy/paste what they need and not change anything.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-17 22:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vd43gerak.fsf@alter.siamese.dyndns.org>
On Tue, Nov 17, 2009 at 23:10, Junio C Hamano <gitster@pobox.com> wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
>>> Wouldn't it be a good idea to somehow make this work well together with
>>> the --user-path feature of git-daemon?
>>>
>>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>>> but more like ~/public_git, as this is like ~/public_html but for git
>>> repositories. Then the end users will browse
>>
>> As I said, it's configuration :)
>
> Wrong answer.
>
Am I passing a test ?
> Exactly because it is configurable, the document that outlines the
> recommended practice should suggest the best convention. My point was
> that it is likely to be tied to "git"-ness of the specified directory
> under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
> name tied to "gitweb"-ness in this document.
Again, git is a brand new world for me and I don't know any of his
conventions yet.
I am not trying to impose my own conventions, I am just proposing an idea.
If you like it and want to make it more "git world compliant", please do so.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-11-17 22:19 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, J. Bruce Fields, Nanako Shiraishi,
Michael J Gruber, Jonathan Nieder, git, Hannu Koivisto, Jeff King,
Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <94a0d4530911171400ub3b093ai668fd2404b12272f@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> That could be easily fixed by making explicit in the syntax that these
> are not typical refs: i.e. @stage and @work.
The message I get from that suggestion is that the most sensible approach,
if we are going to add something from this discussion to "git diff", is to
do what you did _not_ quote from my message, which is:
As to --tree-vs-index counterproposal (was it a counterproposal?),
except for that I think they are too long to type in practice and need
to be shortened to be useful, I do not have a fundamental objection
against it.
IOW, this is about options, and should not be done as syntax sugar that
does a half-baked job of pretending to be refs.
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Junio C Hamano @ 2009-11-17 22:16 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Mike Hommey, Jeff King, Matthieu Moy, git, Karl Chen
In-Reply-To: <m2lji43l20.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Mike Hommey <mh@glandium.org> writes:
>
>> On Tue, Nov 17, 2009 at 02:34:26AM -0500, Jeff King wrote:
>>> Maybe:
>>>
>>> A leading path component of "~user" is expanded to the home directory
>>> of "user"; "~" is expanded to the home directory of the user running
>>> git.
>>>
>>> would be more clear?
>>
>> Add "real" before "user running git" and you have my vote. Or maybe
>> using the effective user would be better, and the patch should use
>> geteuid() instead of getuid(), I don't know. ident.c uses getuid(), but
>> I'm wondering if that's what it should use (although it doesn't seem to
>> have been a problem to anyone)
>
> "~" should just expand to the value of $HOME, like in the shell,
> independent of the real home directory of the real or effective user.
How should this interact with installations that run gitosis/gitlite that
use shared account, giving user identity via the ssh key?
Note that the question is not "how would this...", but "how _should_
this...".
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-17 22:10 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <7fce93be0911171224r1cfc438ay7b38b81646154a23@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
>> Wouldn't it be a good idea to somehow make this work well together with
>> the --user-path feature of git-daemon?
>>
>> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
>> but more like ~/public_git, as this is like ~/public_html but for git
>> repositories. Then the end users will browse
>
> As I said, it's configuration :)
Wrong answer.
Exactly because it is configurable, the document that outlines the
recommended practice should suggest the best convention. My point was
that it is likely to be tied to "git"-ness of the specified directory
under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
name tied to "gitweb"-ness in this document.
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Felipe Contreras @ 2009-11-17 22:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Nanako Shiraishi, Michael J Gruber,
Jonathan Nieder, git, Hannu Koivisto, Jeff King, Wincent Colaiuta,
Matthias Lederhofer
In-Reply-To: <7vocn1dn5d.fsf@alter.siamese.dyndns.org>
On Tue, Nov 17, 2009 at 8:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> But we do not have to support commit-ish operations, such as "git log".
Right, and actuallly don't have to support WORKTREE/STAGE on all the
commands that work with the stage. For example I think 'git apply'
behaves completely different than 'git diff', since you cannot apply a
patch on top of a commit, therefore it doesn't make sense to stage
stuff as pseudo-refs; it makes sense to keep the --foo options
(although I would prefer something like --stage and --stage-only).
> It is a different story if these pseudo-refs that denote tree-ish are
> useful outside the context of "diff". I do not think of many commands
> that take arbitrary tree-ish other than the ones I mentioned above. Even
> though they take arbitrary tree-ish, people almost always use commit-ish
> with them.
>
> Which points to another issue with the approach.
>
> The original intention of these magic tokens are to make things easier,
> but they actually may make things _harder_ to teach, because you have to
> explain why "git log WORKTREE" does not work but "git archive WORKTREE"
> does. Admittedly, you already have to explain your example to people
> saying "it does not work because v2.6.11 is a tree and a tree by itself
> does not have a point in history", but the thing is, v2.6.11-tree and
> v2.6.11 are oddballs, and you do not have to give that explanation very
> often, simply because the users are not exposed to a raw tree.
>
> But WORKTREE and STAGE tokens are _meant_ to be exposed to them much more
> prominently. That's the whole point of the "git diff STAGE WORKTREE"
> proposal.
>
> People would become aware that they are very different from ordinary
> commits, and then eventually they will realize that they are not even
> trees [*1*].
>
> At that point, I suspect that these magic tokens become larger UI warts
> themselves; they behave differently from everything else that is spelled
> in all caps (e.g. HEAD, ORIG_HEAD, MERGE_HEAD).
That could be easily fixed by making explicit in the syntax that these
are not typical refs: i.e. @stage and @work.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Andreas Schwab @ 2009-11-17 21:20 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jeff King, Matthieu Moy, git, Karl Chen
In-Reply-To: <20091117074930.GB11636@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> On Tue, Nov 17, 2009 at 02:34:26AM -0500, Jeff King wrote:
>> Maybe:
>>
>> A leading path component of "~user" is expanded to the home directory
>> of "user"; "~" is expanded to the home directory of the user running
>> git.
>>
>> would be more clear?
>
> Add "real" before "user running git" and you have my vote. Or maybe
> using the effective user would be better, and the patch should use
> geteuid() instead of getuid(), I don't know. ident.c uses getuid(), but
> I'm wondering if that's what it should use (although it doesn't seem to
> have been a problem to anyone)
"~" should just expand to the value of $HOME, like in the shell,
independent of the real home directory of the real or effective user.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-17 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vhbssewm7.fsf@alter.siamese.dyndns.org>
On Tue, Nov 17, 2009 at 21:15, Junio C Hamano <gitster@pobox.com> wrote:
> Sylvain Rabot <sylvain@abstraction.fr> writes:
>
>> +If you want gitweb to act a bit like UserDir mod in apache, knowing, http://<host>/~<user>
>> +will list all git repos of <user> located in a special directory in his home (/home/<user>/gitweb/),
>> +do the following steps :
>> +
>> +Add this to the VirtualHost section of your apache configuration file :
>> +
>> + RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
>> +
>> +Modify your gitweb.conf file, located at /etc/gitweb.conf in this example, with :
>> +
>> + $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/path/to/the/defaul/project/root";
>> +
>> +Thus, each user with a gitweb folder in his home will be able to browse it with gitweb.
>> +/!\ The gitweb folder and user's home folder must be readable by the webserver user.
>
> Wouldn't it be a good idea to somehow make this work well together with
> the --user-path feature of git-daemon?
>
> Perhaps the recommended name given in the example shouldn't be ~/gitweb,
> but more like ~/public_git, as this is like ~/public_html but for git
> repositories. Then the end users will browse
As I said, it's configuration :)
>
> http://my.site/~gitster/public_git/git.git
>
would be http://my.site/~gitster/git.git
> and gitweb can be told to show
>
> clone URL: git://my.site/~gitster/public_git/git.git
and git://my.site/~gitster/git.git
if --user-path of git daemon set to public_git
> on the page. If the site administrator runs git-daemon with --user-path
> set to public_git, everything will work seamlessly, no?
>
Yes :)
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-17 20:15 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski
In-Reply-To: <7fce93be0911150204h259b7424md251c54186d05b7d@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> +If you want gitweb to act a bit like UserDir mod in apache, knowing, http://<host>/~<user>
> +will list all git repos of <user> located in a special directory in his home (/home/<user>/gitweb/),
> +do the following steps :
> +
> +Add this to the VirtualHost section of your apache configuration file :
> +
> + RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
> +
> +Modify your gitweb.conf file, located at /etc/gitweb.conf in this example, with :
> +
> + $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/path/to/the/defaul/project/root";
> +
> +Thus, each user with a gitweb folder in his home will be able to browse it with gitweb.
> +/!\ The gitweb folder and user's home folder must be readable by the webserver user.
Wouldn't it be a good idea to somehow make this work well together with
the --user-path feature of git-daemon?
Perhaps the recommended name given in the example shouldn't be ~/gitweb,
but more like ~/public_git, as this is like ~/public_html but for git
repositories. Then the end users will browse
http://my.site/~gitster/public_git/git.git
and gitweb can be told to show
clone URL: git://my.site/~gitster/public_git/git.git
on the page. If the site administrator runs git-daemon with --user-path
set to public_git, everything will work seamlessly, no?
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Sylvain Rabot @ 2009-11-17 19:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Petr Baudis, Luben Tuikov, J.H., git
In-Reply-To: <200911171912.40658.jnareb@gmail.com>
On Tue, Nov 17, 2009 at 19:12, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 17 Nov 2009, Sylvain Rabot wrote:
>> On Tue, Nov 17, 2009 at 14:58, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> > The description is a bit lacking. Where user should put theirs git
>> > repositories, or symbolic links to git repositories?
>>
>> As I said It's only configuration so It depends of your server
>> architecture. If admin of the server decides he allows users to browse
>> via gitweb their private/public repos which are linked in
>> /home/*/.gitweb or anything else he has to modify the environmental
>> variable in the rewrite rule according to his wish.
>
> So in described configuration, to make repository visible user would have
> to put repository, or symbolic link to repository (or .git/ directory of
> the repository) in ~/gitweb/ directory (just like one would need to put
> HTML files in ~/public_html/ or ~/WWW/ to have them visible as web site),
> isn't it?
>
That's right.
>> > How it would look like in gitweb?
>>
>> What do you mean ?
>
> How would example gitweb URL to repository look like?
http://repo.or.cz/ -> list the main GITWEB_PROJECTROOT (e.g.: /pub/scm)
http://repo.or.cz/~user -> list /home/user/gitweb
http://repo.or.cz/~user2 -> list /home/user2/gitweb
...
>
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* Re: [PATCH v2 0/2] user-manual: new "getting started" section
From: Junio C Hamano @ 2009-11-17 18:25 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Nanako Shiraishi, Felipe Contreras, Michael J Gruber,
Jonathan Nieder, Junio C Hamano, git, Hannu Koivisto, Jeff King,
Wincent Colaiuta, Matthias Lederhofer
In-Reply-To: <20091117172815.GH31767@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Nov 17, 2009 at 09:06:25PM +0900, Nanako Shiraishi wrote:
>> David's proposal introduced two magic tokens STAGE and WORKTREE.
>>
>> git diff STAGE WORKTREE (like "git diff" today)
>> git diff HEAD WORKTREE (like "git diff HEAD" today)
>> git diff WORKTREE HEAD (like "git diff -R HEAD" today)
>> git diff HEAD STAGE (like "git diff --cached" today)
>> git diff commit STAGE (like "git diff --cached commit" today)
>>
>> This looks nice on surface, but I think the apparent niceness
>> is shallow. If of course has a small problem of introducing an
>> obvious backward incompatibility. You can't use a branch whose
>> name is STAGE anymore, but a deeper problem is that these two
>> magic tokens pretend to be refs. But they do so only to the diff
>> command. I don't see how you can make them sanely be usable to
>> other commands like "git log v1.0.0..WORKTREE".
>
> Doesn't appear that refs have to point to commits; e.g., on the linux
> project:
>
> git log v2.6.11-tree..v2.6.32-rc7
> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a
> commit
> fatal: Invalid revision range v2.6.11-tree..v2.6.32-rc7
True. A ref can even point to a blob.
I think "diff" always takes two (pseudo-)tree-ish in David's world, and
you should be able to use these magic topens anywhere that expects a
tree-ish. For example:
$ git checkout STAGE Makefile
would be a way to say "please check out the version of Makefile in the
staging area". And
$ git archive WORKTREE
$ git archive STAGE
would be a version of tar that is index-aware.
But we do not have to support commit-ish operations, such as "git log".
It is a different story if these pseudo-refs that denote tree-ish are
useful outside the context of "diff". I do not think of many commands
that take arbitrary tree-ish other than the ones I mentioned above. Even
though they take arbitrary tree-ish, people almost always use commit-ish
with them.
Which points to another issue with the approach.
The original intention of these magic tokens are to make things easier,
but they actually may make things _harder_ to teach, because you have to
explain why "git log WORKTREE" does not work but "git archive WORKTREE"
does. Admittedly, you already have to explain your example to people
saying "it does not work because v2.6.11 is a tree and a tree by itself
does not have a point in history", but the thing is, v2.6.11-tree and
v2.6.11 are oddballs, and you do not have to give that explanation very
often, simply because the users are not exposed to a raw tree.
But WORKTREE and STAGE tokens are _meant_ to be exposed to them much more
prominently. That's the whole point of the "git diff STAGE WORKTREE"
proposal.
People would become aware that they are very different from ordinary
commits, and then eventually they will realize that they are not even
trees [*1*].
At that point, I suspect that these magic tokens become larger UI warts
themselves; they behave differently from everything else that is spelled
in all caps (e.g. HEAD, ORIG_HEAD, MERGE_HEAD).
As to --tree-vs-index counterproposal (was it a counterproposal?), except
for that I think they are too long to type in practice and need to be
shortened to be useful, I do not have a fundamental objection against it.
[Footnote]
*1* For example, I would not expect that we will make "git show WORKTREE"
to build a tree on the fly by running "git add -A && git write-tree" with
a temporary index and then running "git show" on the resulting tree
object, because there would be a better response than that if a user asks
"please show my worktree".
^ permalink raw reply
* Re: [PATCH] Document git-svn's first-parent rule
From: Junio C Hamano @ 2009-11-17 18:25 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20091117074208.GA337@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
>> Thanks; is it a good time to pull from your bogomips repository to get
>> accumulated changes?
>
> Now is, I just pushed to it:
>
> Eric Wong (3):
> git svn: read global+system config for clone+init
> git svn: add authorsfile test case for ~/.gitconfig
> git svn: attempt to create empty dirs on clone+rebase
>
> Thomas Rast (1):
> Document git-svn's first-parent rule
>
> Toby Allsopp (1):
> git svn: handle SVN merges from revisions past the tip of the branch
>
> HEAD=ce45a45f24cc7b3ccc7f6ebcd0025559b4421bda
Thanks, pulled.
^ permalink raw reply
* Re: [PATCH] Make sure $PERL_PATH is defined when the test suite is run.
From: Junio C Hamano @ 2009-11-17 18:25 UTC (permalink / raw)
To: Philippe Bruhat (BooK); +Cc: Johannes Sixt, git
In-Reply-To: <20091117083557.GC3608@plop>
"Philippe Bruhat (BooK)" <book@cpan.org> writes:
>> Make it: ... >>$@
>
> This proves late commits needs many extra pair of eyes. :-)
> ...
>> This one needs the double-quotes as well.
>
> Thanks. Sending again. (sorry for the noise)
Thanks, I also missed them. Will re-queue.
^ 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