* Re: git notes: notes
From: Sverre Rabbelier @ 2010-01-24 14:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Michael J Gruber, Joey Hess, git
In-Reply-To: <vpq7hr7zism.fsf@bauges.imag.fr>
Heya,
On Sun, Jan 24, 2010 at 15:20, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> OTOH, format-patch could give the notes, below the ---, where it will
> be ignored by apply. That would make notes handy to prepare a patch
> serie with additional messages: prepare everything within Git, and use
> git send-email to send it.
I like that idea, but as an orthogonal feature, prepare notes in a
special namespace, say refs/notes/format-patch/, and then teach
format-patch a flag to honor that namespace.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git 1.6.6.1 on glibc 2.2
From: Gabor Z. Papp @ 2010-01-24 15:09 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20100124122751.GA3265@progeny.tock>
* Jonathan Nieder <jrnieder@gmail.com>:
| > trying to compile git 1.6.6.1 on Linux 2.4.37.7, glibc 2.2.5:
| >
| > read-cache.c: In function 'fill_stat_cache_info':
| > read-cache.c:72: error: 'struct stat' has no member named 'st_ctim'
| Thanks for the report. Perhaps:
| # Define NO_NSEC if your "struct stat" does not have "st_ctim.tv_nsec"
| # available. This automatically turns USE_NSEC off.
Thanks Jonathan, compiles fine defining NO_NSEC, but my glibc is 2.2.5
and the comment abot USE_NSEC says it requires at least glibc
2.2.4. Maybe the comment is wrong? glibc 2.3.6 compiles fine.
^ permalink raw reply
* Re: cherry picking several patches at once
From: Marc Weber @ 2010-01-24 15:31 UTC (permalink / raw)
To: git
In-Reply-To: <94a0d4531001240510g25ea3398qdd0c7b98f9b81209@mail.gmail.com>
> Ok, in that case we would just need a cherry-pick that can commit to a
> separate branch, however I don't think git internals allow that kind
> of thing.
Which is the best way to implement this git-cherry-push command?
# naive implementation (BASH function):
gitCherryPush(){
# start a subshell so that failures don't quit your shell because of
# set -e
(
set -e
local branch=$(cat .git/HEAD | sed 's@ref: refs/heads/\(.*\)@\1@')
local otherBranch=$1; shift
commits="$(
for range in "$@"; do
local HAS_DOTS=${range%%*..*}
# add -1 if commit is not a range
git rev-list --reverse ${HAS_DOTS:+-1} "$range"
done
)"
echo "checking out other branch"
git checkout "$otherBranch"
echo "$commits" | while read c; do
git cherry-pick "$c" || {
echo "cherry-picking $c failed. fix it, exit 1 to abort. Starting subshell now"
$SHELL || [ "$?" != 1] || return
}
done
echo "checking out original branch $branch"
git checkout $branch
)
}
zsh completion:
compdef _gitCherryPush gitCherryPush
_gitCherryPush(){
typeset -A opt_args
_arguments -S \
':branch to which to move commit range:__git_branch_names' \
':branch to which to move commit range:__git_commit_ranges2'
}
Example usage (push last 5 commits)
gitCherryPush branch-to-push-to HEAD~4 HEAD~4..HEAD
Can I checkout the other branch without touching the working copy? I
don't think so because cherry-pick will fail operating if working
directory is not clean, correct?
Is something like this worth comitting to the main repo?
Marc Weber
^ permalink raw reply
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Johannes Sixt @ 2010-01-24 16:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, Thomas Rast, git, Linus Torvalds
In-Reply-To: <201001232141.49556.j6t@kdbg.org>
On Samstag, 23. Januar 2010, Johannes Sixt wrote:
> On Samstag, 23. Januar 2010, Junio C Hamano wrote:
> > What happens if you did this?
> >
> > git --git-dir=//git/repo/repo.git --work-tree=/git/repo
> >
> > where "//git/repo" is on the "git server" and you are working in local
> > hierarchy "/git/repo"?
>
> Ah, right, this would not do the right thing. (But I can't verify this
> claim right now.)
I tested it, and it does the right thing. The reason is that before
setup_work_tree() calls make_relative_path(), the --work-tree argument has
been processed by make_absolute_path(), which adds the drive prefix.
As long as setup_work_tree() remains the only caller of make_relative_path(),
we are safe.
-- Hannes
^ permalink raw reply
* Re: git 1.6.6.1 on glibc 2.2
From: Jonathan Nieder @ 2010-01-24 17:40 UTC (permalink / raw)
To: Gabor Z. Papp; +Cc: git
In-Reply-To: <x6d40zmte6@gzp>
Gabor Z. Papp wrote:
>| Gabor Z. Papp wrote:
>|> trying to compile git 1.6.6.1 on Linux 2.4.37.7, glibc 2.2.5:
>|>
>|> read-cache.c: In function 'fill_stat_cache_info':
>|> read-cache.c:72: error: 'struct stat' has no member named 'st_ctim'
[...]
> Thanks Jonathan, compiles fine defining NO_NSEC, but my glibc is 2.2.5
> and the comment abot USE_NSEC says it requires at least glibc
> 2.2.4. Maybe the comment is wrong? glibc 2.3.6 compiles fine.
Hmm, in the glibc changelog I find this, from ChangeLog.14:
| 2003-01-04 Andreas Schwab <schwab@suse.de>
|
| * sysdeps/unix/sysv/linux/m68k/bits/stat.h: Add nanosecond fields.
That’s around the time of glibc 2.3.2.
The stat(2) man page tells a little more:
| Since kernel 2.5.48, the stat structure supports nanosecond resolution for
| the three file timestamp fields. Glibc exposes the nanosecond component
| of each field using names either of the form st_atim.tv_nsec, if the
| _BSD_SOURCE or _SVID_SOURCE feature test macro is defined, or of the form
| st_atimensec, if neither of these macros is defined. On file systems that
| do not support sub-second timestamps, these nanosecond fields are returned
| with the value 0.
Searching a little harder yields commit cvs/glibc-2_3_2~418
(2002-12-31) of git://sourceware.org/git/glibc.git, in which the
feature was added. There’s a lovely discussion about it from then on
libc-alpha. [1]
The comment you mention is from commit bdd4da5 (Make nsec checking
optional, 2005-04-13); I am guessing 2.2.4 was just mentioned as a lower
bound.
So how about something like the following? Please feel free to
write something better --- in particular, I am not sure the
documentation for USE_NSEC is the most obvious place to look when
something goes wrong.
Thanks,
Jonathan
[1] http://sourceware.org/ml/libc-alpha/2002-12/threads.html#00011
-- %< --
Subject: Makefile: document minimal glibc version supporting tv_nsec
Compiling git with the default settings and old glibc produces
errors like the following:
| read-cache.c: In function 'fill_stat_cache_info':
| read-cache.c:72: error: 'struct stat' has no member named 'st_ctim'
The Makefile seems to imply that versions after 2.2.4 should be
okay, but that is not true: NO_NSEC must be set to build with
glibc versions before 2.3.2.
Reported-by: Gabor Z. Papp <gzp@papp.hu>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
diff --git a/Makefile b/Makefile
index fd7f51e..8ebc966 100644
--- a/Makefile
+++ b/Makefile
@@ -134,7 +134,7 @@ all::
# "-Wl,-rpath=/path/lib" is used instead.
#
# Define USE_NSEC below if you want git to care about sub-second file mtimes
-# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
+# and ctimes. Note that you need recent glibc (at least 2.3.2) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
# randomly break unless your underlying filesystem supports those sub-second
# times (my ext3 doesn't).
^ permalink raw reply related
* git push failed
From: Björn Gustavsson @ 2010-01-24 17:52 UTC (permalink / raw)
To: git
With git built from master (v1.6.6.1-436-gaba7dea),
the following commands (run in a script):
git commit --amend -m "Update index.html" index.html
git push erlang +gh-pages
failed like this:
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 3.85 KiB, done.
Total 3 (delta 0), reused 0 (delta 0)
error: Ref refs/heads/gh-pages is at
db10c045e068f12aa2f78377fab31e35a8443ca4 but expected
054136d96494979b42524a4dc08ef643bb54cc0e
error: failed to lock refs/heads/gh-pages
To git@erlang_github.com:erlang/otp.git
! [remote rejected] gh-pages -> gh-pages (failed to lock)
error: failed to push some refs to 'git@erlang_github.com:erlang/otp.git'
Unfortunately (from the point of view of finding the bug), the
problem is not reproducible. When I ran my script two more times,
it worked fine.
We all know how difficult it is to investigate non-reproducible bugs,
but perhaps someone familiar with the code might have some idea
about what it could be.
Info about my system:
Mac OS X 10.2.6 (8 cores)
gcc-4.2.1
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* [PATCH] gitweb.js: Workaround for IE8 bug
From: Jakub Narebski @ 2010-01-24 18:05 UTC (permalink / raw)
To: git
In Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses
JavaScript to generate blame info using AJAX, sometimes hang at the
beginning (at 0%) of blaming, e.g. for larger files with long history
like git's own gitweb/gitweb.perl.
The error shown by JavaScript console is "Unspecified error" at char:2
of the following line in gitweb/gitweb.js:
if (xhr.readyState === 3 && xhr.status !== 200) {
Debugging it using IE8 JScript debuger shown that the error occurs
when trying to access xhr.status (xhr is XMLHttpRequest object).
Watch for xhr object shows 'Unspecified error.' as "value" of
xhr.status, and trying to access xhr.status from console throws error.
This bug is some intermittent bug, depending on XMLHttpRequest timing,
as it doesn't occur in all cases. It is probably caused by the fact
that handleResponse is called from timer (pollTimer), to work around
the fact that some browsers call onreadystatechange handler only once
for each state change, and not like required for 'blame_incremental'
as soon as new data is available from server. It looks like xhr
object is not properly initialized; still it is a bug to throw an
error when accessing xhr.status (and not use 'null' or 'undefined' as
value).
Work around this bug in IE8 by using try-catch block when accessing
xhr.status.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
It is, if I remember correctly, resend.
I don't have IE6 nor IE7 to check whether this bug is present also in
older versions of Internet Explorer...
gitweb/gitweb.js | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 2a25b7c..9c66928 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -779,7 +779,12 @@ function handleResponse() {
}
// the server returned error
- if (xhr.readyState === 3 && xhr.status !== 200) {
+ // try ... catch block is to work around bug in IE8
+ try {
+ if (xhr.readyState === 3 && xhr.status !== 200) {
+ return;
+ }
+ } catch (e) {
return;
}
if (xhr.readyState === 4 && xhr.status !== 200) {
^ permalink raw reply related
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Junio C Hamano @ 2010-01-24 18:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Robin Rosenberg, Thomas Rast, git, Linus Torvalds
In-Reply-To: <201001241744.57139.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Samstag, 23. Januar 2010, Johannes Sixt wrote:
>> On Samstag, 23. Januar 2010, Junio C Hamano wrote:
>> > What happens if you did this?
>> >
>> > git --git-dir=//git/repo/repo.git --work-tree=/git/repo
>> >
>> > where "//git/repo" is on the "git server" and you are working in local
>> > hierarchy "/git/repo"?
>>
>> Ah, right, this would not do the right thing. (But I can't verify this
>> claim right now.)
>
> I tested it, and it does the right thing. The reason is that before
> setup_work_tree() calls make_relative_path(), the --work-tree argument has
> been processed by make_absolute_path(), which adds the drive prefix.
>
> As long as setup_work_tree() remains the only caller of make_relative_path(),
> we are safe.
Thanks; I think a more correct description of your findings is:
- msysgit's make_absolute_path() does the right thing (i.e. adds "drive
prefix" to "git/repo" given to --work-tree); and
- as long as the callers feed what the platform considers absolute paths
in abs and base, make_relative_path() does the right thing.
So I think we are Ok. We _might_ want to add Windows-only test at the
beginning of make_relative_path() to make sure that the both inputs have
double-slashes at the beginning to catch future broken callers, but I
think that is a separate topic, and we don't have to do that as long as
setup_work_tree(0 remains the only caller, as you said.
^ permalink raw reply
* [PATCH] Windows: avoid static dependency on advapi32.dll
From: Michael Lukashov @ 2010-01-24 18:53 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Michael Lukashov
This DLL is used to get default user name. By looking
up the only function that we need at runtime, we can
avoid the startup costs of this DLL.
Signed-off-by: Michael Lukashov <michael.lukashov@gmail.com>
---
compat/mingw.c | 31 ++++++++++++++++++++++++++++++-
1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index ab65f77..6ce398c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1176,13 +1176,42 @@ int mingw_getpagesize(void)
return si.dwAllocationGranularity;
}
+static HMODULE advapi32_dll = NULL;
+static BOOL (WINAPI *advapi32_get_user_name)(char *, DWORD *);
+
+static void advapi32_cleanup(void)
+{
+ if (advapi32_dll)
+ FreeLibrary(advapi32_dll);
+ advapi32_dll = NULL;
+ advapi32_get_user_name = NULL;
+}
+
struct passwd *getpwuid(int uid)
{
static char user_name[100];
static struct passwd p;
+ static int advapi32_initialized = 0;
DWORD len = sizeof(user_name);
- if (!GetUserName(user_name, &len))
+
+ if (!advapi32_initialized)
+ {
+ advapi32_dll = LoadLibrary("advapi32.dll");
+ if (!advapi32_dll)
+ die("cannot load advapi32.dll");
+ advapi32_get_user_name = (BOOL (WINAPI *)(char *, DWORD *))
+ GetProcAddress(advapi32_dll, "GetUserNameA");
+ if (!advapi32_get_user_name) {
+ FreeLibrary(advapi32_dll);
+ advapi32_dll = NULL;
+ die("cannot find GetUserNameA");
+ }
+ atexit(advapi32_cleanup);
+ advapi32_initialized = 1;
+ }
+
+ if (!advapi32_get_user_name(user_name, &len))
return NULL;
p.pw_name = user_name;
p.pw_gecos = "unknown";
--
1.6.6.1599.gaed1a
^ permalink raw reply related
* [PATCH] git-gui: use different icon for new and modified files in the index
From: Peter Oberndorfer @ 2010-01-24 18:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
This allows to quickly differentiate between new and modified files
in the index without selecting the file and looking at the diff.
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
---
At work i often use git add '*_en.properties' and after that i like to check
which files are new and which ones where changed.
I hope this is useful for somebody else too.
While creating the patch i found out that file_parttick seems to be unused.
git-gui/git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
index 718277a..880252d 100755
--- a/git-gui/git-gui.sh
+++ b/git-gui/git-gui.sh
@@ -1844,7 +1844,7 @@ set ui_index .vpane.files.index.list
set ui_workdir .vpane.files.workdir.list
set all_icons(_$ui_index) file_plain
-set all_icons(A$ui_index) file_fulltick
+set all_icons(A$ui_index) file_plain
set all_icons(M$ui_index) file_fulltick
set all_icons(D$ui_index) file_removed
set all_icons(U$ui_index) file_merge
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] Windows: Remove dependency on pthreadGC2.dll
From: Johannes Sixt @ 2010-01-24 19:03 UTC (permalink / raw)
To: Michael Lukashov; +Cc: git, Andrzej K. Haczewski
In-Reply-To: <1264327830-4204-1-git-send-email-michael.lukashov@gmail.com>
On Sonntag, 24. Januar 2010, Michael Lukashov wrote:
> Commit 44626dc7 (MSVC: Windows-native implementation for subset
> of threads API, 2010-01-15) introduces builtin replacement of
> pthreadGC2.dll functionality, thus we can completely drop
> dependency on this dll.
Duh! This means that when I tested above-mentioned patch, I actually was using
pthread.h from msysgit instead of compat/win32/pthread.h, and didn't test it
at all (note: MinGW version; MSVC was fine because it had the right includes
all the time). This patch passes the test suite and a 'git gc --aggressive':
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: basic question about push
From: Junio C Hamano @ 2010-01-24 19:08 UTC (permalink / raw)
To: Jeff King; +Cc: Russ Paielli, git
In-Reply-To: <20100124081513.GA10700@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jan 24, 2010 at 07:04:59AM +0000, Russ Paielli wrote:
>
>> warning: updating the current branch
>> [...]
>> What does this mean in English? And what is the correct way to transfer my
>> revisions from my home computer to my work computer? Thanks.
>
> It means your workflow will cause problems as the pusher magically
> changes your repository's concept of "the latest commit" behind the
> pushee's back. The workflow you want is described here:
>
> http://git.wiki.kernel.org/index.php/GitFaq#push-is-reverse-of-fetch
I saw somebody referred to this entry and refused to study the entry
immediately after seeing the word "firewalled", saying "my environment is
not firewalled", without trying to judge if the description applies to his
case. This was understandable; the workflow will apply in non-firewalled
case just as well, even though "firewalled" case may be the easiest to see
why it is recommended.
Perhaps the title of the entry needs to be rewritten to clarify that this
is not _limited_ to a firewalled situation?
^ permalink raw reply
* [PATCH] pull: re-fix command line generation
From: Junio C Hamano @ 2010-01-24 19:12 UTC (permalink / raw)
To: git
14e5d40 (pull: Fix parsing of -X<option>, 2010-01-17) forgot that
merge_name needs to stay as a single non-interpolated string.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Just in case somebody is on 'master' and uses "pull --log"...
git-pull.sh | 2 +-
t/t5524-pull-msg.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 1 deletions(-)
create mode 100755 t/t5524-pull-msg.sh
diff --git a/git-pull.sh b/git-pull.sh
index 2de4c3a..38331a8 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -275,7 +275,7 @@ true)
*)
eval="git-merge $diffstat $no_commit $squash $no_ff $ff_only"
eval="$eval $log_arg $strategy_args $merge_args"
- eval="$eval \"$merge_name\" HEAD $merge_head $verbosity"
+ eval="$eval \"\$merge_name\" HEAD $merge_head $verbosity"
;;
esac
eval "exec $eval"
diff --git a/t/t5524-pull-msg.sh b/t/t5524-pull-msg.sh
new file mode 100755
index 0000000..8cccecc
--- /dev/null
+++ b/t/t5524-pull-msg.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+test_description='git pull message generation'
+
+. ./test-lib.sh
+
+dollar='$Dollar'
+
+test_expect_success setup '
+ test_commit initial afile original &&
+ git clone . cloned &&
+ (
+ cd cloned &&
+ echo added >bfile &&
+ git add bfile &&
+ test_tick &&
+ git commit -m "add bfile"
+ ) &&
+ test_tick && test_tick &&
+ echo "original $dollar" >afile &&
+ git add afile &&
+ git commit -m "do not clobber $dollar signs"
+'
+
+test_expect_success pull '
+(
+ cd cloned &&
+ git pull --log &&
+ git log -2 &&
+ git cat-file commit HEAD >result &&
+ grep Dollar result
+)
+'
+
+test_done
--
1.6.6.1.557.g77031
^ permalink raw reply related
* Re: [PATCH] Windows: avoid static dependency on advapi32.dll
From: Johannes Sixt @ 2010-01-24 19:20 UTC (permalink / raw)
To: Michael Lukashov; +Cc: git
In-Reply-To: <1264359231-4672-1-git-send-email-michael.lukashov@gmail.com>
On Sonntag, 24. Januar 2010, Michael Lukashov wrote:
> This DLL is used to get default user name. By looking
> up the only function that we need at runtime, we can
> avoid the startup costs of this DLL.
Sorry, no. This doesn't work. Even though git.exe does no longer depend on
advapi32.dll directly, it does so indirectly (via ws_32.dll). This patch is
not an improvement, therefore: NAK.
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/2] two git-svn changes to help work with chromium.org
From: Junio C Hamano @ 2010-01-24 19:29 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Jay Soffian, Andrew Myrick
In-Reply-To: <20100123112626.GA21553@dcvr.yhbt.net>
Thanks, pulled.
^ permalink raw reply
* Re: [PATCH v2 0/7] clarify 'git merge' documentation
From: Junio C Hamano @ 2010-01-24 19:29 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jonathan Nieder, git, Petr Baudis, Junio C Hamano
In-Reply-To: <201001241425.07027.trast@student.ethz.ch>
Thanks, pulled.
^ permalink raw reply
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Bernhard R. Link @ 2010-01-24 19:04 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <201001241457.43297.trast@student.ethz.ch>
* Thomas Rast <trast@student.ethz.ch> [100124 14:58]:
> POSIX specifies that multiple slashes must be treated as if they were
> a single slash (except as in the next bullet point). Leading _double_
> slashes may be treated implementation-dependently. [1] Non-leading
> double slashes do not seem to be specified.
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266
| 3.266 Pathname
|
| A character string that is used to identify a file. In the context of
| IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
| including the terminating null byte. It has an optional beginning
| slash, followed by zero or more filenames separated by slashes. A
| pathname may optionally contain one or more trailing slashes.
| Multiple successive slashes are considered to be the same as one
| slash.
^ permalink raw reply
* Re: [PATCH] Handle double slashes in make_relative_path()
From: Junio C Hamano @ 2010-01-24 20:05 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: Thomas Rast, git
In-Reply-To: <20100124190424.GA30585@pcpool00.mathematik.uni-freiburg.de>
"Bernhard R. Link" <brlink@debian.org> writes:
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_266
>
> | 3.266 Pathname
> |
> | A character string that is used to identify a file. In the context of
> | IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes,
> | including the terminating null byte. It has an optional beginning
> | slash, followed by zero or more filenames separated by slashes. A
> | pathname may optionally contain one or more trailing slashes.
> | Multiple successive slashes are considered to be the same as one
> | slash.
Which is a bit stale, and there is an update that is crucial when
discussing the issue that is the topic of this thread.
Try this one instead, especially the last ", except for" which is an
important clarification.
http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html
| 3.266 Pathname
|
| A character string that is used to identify a file. In the context of
| POSIX.1-2008, a pathname may be limited to {PATH_MAX} bytes, including the
| terminating null byte. It has an optional beginning <slash>, followed by
| zero or more filenames separated by <slash> characters. A pathname may
| optionally contain one or more trailing <slash> characters. Multiple
| successive <slash> characters are considered to be the same as one
| <slash>, except for the case of exactly two leading <slash> characters.
And 4.12 in the same issue of POSIX says pathnames with exactly two
leading slashes may be handled in an implemenation defined manner
(i.e. three or more means the same thing as a single slash). Confusing
;-)
^ permalink raw reply
* Re: Modern Git GUI
From: André Harms @ 2010-01-24 20:43 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq636resro.fsf@bauges.imag.fr>
2010/1/24 Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>:
> André Harms <andre.harms@kuhlsolutions.de> writes:
>
>> So I thought about developing a new kind of GUI for Git that looks
>> modern and attractive
>
> Every once in a while, someone comes and says "Git GUIs aren't as good
> as I'd expect, I'll write my own". The result is that we have a myriad
> of GUIs (see
> http://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Graphical_Interfaces ),
> many of them being half-finished and/or abandonned. I don't believe
> adding yet-another-one is going to improve the situation, and
> pick-one-and-improve-it is IMHO a much better approach.
Basically I agree with you. And I think you're right that yet another
one won't improve the situation immediately.
I've to admin, that I didn't think about that very much. So I have to
rethink my plan. But my concept is different than the one of other
GUIs.
>> (you know... some eye-candy stuff) and that is easy to use.
>
> I use mostly the command-line, so I couldn't make a detailed review of
> the existing, but tools like git-cola and a few others sound "modern"
> to me (Qt4 & co).
>
> If you decide to go on with your project, either you want to carry it
> out alone, or you'll have to convince other developers to join. In the
> second case, a good starting point would be to explain why the other
> GUI are not good enough, and why you can't just contribute to them.
If I decide to go on anyhow, I'll work those things out clearly.
Thanks for the tip.
In my opinion other GUIs aren't intuitve for first-time users and
aren't as good for experienced users as the command-line. But a GUI
_can_ be helpful for experienced users as well. So there's a hole that
can be filled. And my concept is based on a hybrid GUI that also
offers a command-line for experienced users. So actions that are made
with the built in command-line (console) are visualized. That also
might be good for beginners who like to use the command-line but are
afraid of using it.
If I go on I'll probably use Clutter as GUI toolkit. With it one is
able to create real good looking GUIs (though it's not a guarantor for
a good GUI).
Thanks for your opinion.
^ permalink raw reply
* git-gui: Using "Stage To Commit" does not always stage all selected files.
From: Peter Oberndorfer @ 2010-01-24 21:05 UTC (permalink / raw)
To: Git Mailing List
Hello,
Using "Stage To Commit" in git-gui does not always stage all selected files.
After startup of git-gui the first modified file is automatically selected.
Selecting another file and then using "Stage to Commit" only the second file is actually staged.
It looks like the reason for this is that selected_paths is not set when a file is automatically selected after startup/refresh/scanning.
How to reproduce:
echo >> userdiff.h
echo >> userdiff.c
git gui&
-> userdiff.c is automatically selected
hold Ctrl and select userdiff.h
Ctrl-T
-> only userdiff.h is staged, userdiff.h remains unstaged
Greetings Peter
^ permalink raw reply
* [PATCH] Make test numbers unique
From: Johannes Sixt @ 2010-01-24 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
:-P
...rse-upstream.sh => t1507-rev-parse-upstream.sh} | 0
1 files changed, 0 insertions(+), 0 deletions(-)
rename t/{t1506-rev-parse-upstream.sh => t1507-rev-parse-upstream.sh} (100%)
diff --git a/t/t1506-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
similarity index 100%
rename from t/t1506-rev-parse-upstream.sh
rename to t/t1507-rev-parse-upstream.sh
--
1.6.6.264.ga6155
^ permalink raw reply
* Re: [PATCH 3/9] gitweb: Add option to force version match
From: Petr Baudis @ 2010-01-24 21:59 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git
In-Reply-To: <1263432185-21334-4-git-send-email-warthog9@eaglescrag.net>
Hi!
On Wed, Jan 13, 2010 at 05:22:59PM -0800, John 'Warthog9' Hawley wrote:
> +# Throw an error if git versions does not match, if $git_versions_must_match is true.
> +if ($git_versions_must_match &&
> + $git_version ne $version) {
> + my $admin_contact =
> + defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
> + my $err_msg = <<EOT;
> +<h1 align="center">*** Warning ***</h1>
> +<p>
> +This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
> +however git version <b>@{[esc_html($git_version)]}</b> was found on server,
> +and administrator requested strict version checking.
> +</p>
> +<p>
> +Please contact the server administrator${admin_contact} to either configure
> +gitweb to allow mismatched versions, or update git or gitweb installation.
> +</p>
> +EOT
> + die_error(500, 'Internal server error', $err_msg);
> +}
> +
I get very unhappy when *I* am the server administrator and read
messages like this. ;-) Could you please mention the
\$git_versions_must_match in the text?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH 8/9] gitweb: Convert output to using indirect file handle
From: Petr Baudis @ 2010-01-24 22:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: John 'Warthog9' Hawley, git
In-Reply-To: <m3ljfydgmt.fsf@localhost.localdomain>
On Fri, Jan 15, 2010 at 04:43:32PM -0800, Jakub Narebski wrote:
> Third, wouldn't it be better to use shorter variable name, e.g. $out
> or $oh, instead of $output_handle? We would be able to align print(f)
> statements without making lines much longer.
I totally agree, I was going to comment on this too. Please use
something very short, I think even the three characters might be pushing
it a bit. Having long idiom will make it real pain to both read and
write gitweb code.
It would still be nice if we could have some way to avoid this hack
entirely. Couldn't we layer PerlIO::via over STDOUT and continue to use
argument-less print as before?
I think we (well, in practice, "you" nowadays :) should be less
perfectionist when accepting gitweb contributions, so if the answer is
"it's too hard for me to do right now", that's fine I guess; I know I
can't contribute the code currently. :(
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when regenerating cache (WIP)
From: Petr Baudis @ 2010-01-24 22:24 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
In-Reply-To: <f4660e9c7ffdb4a62da0c56703de002c9df3b598.1264198194.git.jnareb@gmail.com>
I have stupid question, common to both the original patch and this
RFC.
> [RFC PATCH 10/10] gitweb: Show appropriate "Generating..." page when
> regenerating cache (WIP)
Just why is a "Generating..." page appropriate?
I have to admit I hate it; can you please at least make it
configurable? Why is it needed at all? It generates unnecessary
redirects, clears my previous page in the browser by a useless
placeholder, confuses non-interactive HTTP clients and I just can't
see the real purpose.
What's the gain?
Thanks,
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH 3/9] gitweb: Add option to force version match
From: Jakub Narebski @ 2010-01-24 23:17 UTC (permalink / raw)
To: Petr Baudis
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
git
In-Reply-To: <20100124215924.GA9553@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Wed, Jan 13, 2010 at 05:22:59PM -0800, John 'Warthog9' Hawley wrote:
> > +# Throw an error if git versions does not match, if $git_versions_must_match is true.
> > +if ($git_versions_must_match &&
> > + $git_version ne $version) {
> > + my $admin_contact =
> > + defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
> > + my $err_msg = <<EOT;
> > +<h1 align="center">*** Warning ***</h1>
> > +<p>
> > +This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
> > +however git version <b>@{[esc_html($git_version)]}</b> was found on server,
> > +and administrator requested strict version checking.
+and administrator requested strict version checking by setting
+\$git_versions_must_match to false value (e.g. to 0) in gitweb configuration file,
+'@{[esc_path(-e $GITWEB_CONFIG ? $GITWEB_CONFIG : $GITWEB_CONFIG_SYSTEM)]}'.
> > +</p>
> > +<p>
> > +Please contact the server administrator${admin_contact} to either configure
> > +gitweb to allow mismatched versions, or update git or gitweb installation.
> > +</p>
> > +EOT
> > + die_error(500, 'Internal server error', $err_msg);
> > +}
> > +
>
> I get very unhappy when *I* am the server administrator and read
> messages like this. ;-) Could you please mention the
> \$git_versions_must_match in the text?
Something like the text (extension) proposed above?
Actually, J.H., if you are changing the default, you should also change the
message to mention that checking versions is the default, and administrator
can turn it off[1]. It is incorrect if $git_versions_must_match defaults
to true.
[1] And you have to take into account that gitweb config file can not
exist, and neither $GITWEB_CONFIG nor $GITWEB_CONFIG_SYSTEM needs to be
non-empty. J.H., are you really, really sure that it is a good idea to
have version check turned on by default, in light of this issue?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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