* Re: [PATCH v2] correct verify_path for Windows
From: Alex Riesen @ 2008-10-11 22:58 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Sixt, Joshua Juran, Giovanni Funchal, git,
Shawn O. Pearce
In-Reply-To: <20081011163310.GZ21650@dpotapov.dyndns.org>
2008/10/11 Dmitry Potapov <dpotapov@gmail.com>:
>> > + /* On Windows, file names are case-insensitive */
>> > + case 'G':
>> > + if ((rest[1]|0x20) != 'i')
>> > + break;
>> > + if ((rest[2]|0x20) != 't')
>> > + break;
>>
>> We have tolower().
>
> I am aware of that, but I am not sure what we gain by using it. It seems
> it makes only code bigger and slow.
It does? Care to look into git-compat-util.h?
> ... As to readability, I don't see much
> improvement... Isn't obvious what this code does, especially with the
> above comment?
You want to seriously argue that "a | 0x20" is as readable as "tolower(a)"?
For the years to come? With a person who does not even know what ASCII is?
Ok, I'm exaggerating. But the point is: it is not us who will be
reading the code.
And even if they do this just to remove Windows quirks it is well worth to
use a bit more of english language so that they don't need a second look.
As to comment: it is just additional info. It can't be checked by compiler
if you make and accidental typo in your code (like, for example, accidentally
putting an extra pipe in that expression, should happen to that emacs users
from time to time).
BTW, is it such a critical path? Can't the code be unified and do
without #ifdef?
^ permalink raw reply
* [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-11 22:56 UTC (permalink / raw)
To: gitster; +Cc: spearce, dpotapov, git, Mark Levedahl
In-Reply-To: <7v1vymke85.fsf@gitster.siamese.dyndns.org>
Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch forces use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Documentation/config.txt | 4 +++-
compat/cygwin.c | 18 +++++++++++++++---
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7161597..a3a9495 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -124,7 +124,9 @@ core.ignoreCygwinFSTricks::
one hierarchy using Cygwin mount. If true, Git uses native Win32 API
whenever it is possible and falls back to Cygwin functions only to
handle symbol links. The native mode is more than twice faster than
- normal Cygwin l/stat() functions. True by default.
+ normal Cygwin l/stat() functions. True by default, unless core.filemode
+ is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
+ POSIX emulation is required to support core.filemode.
core.trustctime::
If false, the ctime differences between the index and the
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 423ff20..1fed265 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -91,13 +91,20 @@ static int cygwin_stat(const char *path, struct stat *buf)
* functions should be used. The choice is determined by core.ignorecygwinfstricks.
* Reading this option is not always possible immediately as git_dir may be
* not be set yet. So until it is set, use cygwin lstat/stat functions.
+ * However, if core.filemode is true, we *must* use the Cygwin posix stat as
+ * the Windows stat fuctions do not determine posix filemode.
*/
static int native_stat = 1;
+static int core_filemode = 0;
static int git_cygwin_config(const char *var, const char *value, void *cb)
{
- if (!strcmp(var, "core.ignorecygwinfstricks"))
+ if (!strcmp(var, "core.filemode"))
+ core_filemode = git_config_bool(var, value);
+
+ else if (!strcmp(var, "core.ignorecygwinfstricks"))
native_stat = git_config_bool(var, value);
+
return 0;
}
@@ -105,8 +112,13 @@ static int init_stat(void)
{
if (have_git_dir()) {
git_config(git_cygwin_config, NULL);
- cygwin_stat_fn = native_stat ? cygwin_stat : stat;
- cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
+ if (!core_filemode && native_stat) {
+ cygwin_stat_fn = cygwin_stat;
+ cygwin_lstat_fn = cygwin_lstat;
+ } else {
+ cygwin_stat_fn = stat;
+ cygwin_lstat_fn = lstat;
+ }
return 0;
}
return 1;
--
1.6.0.2.536.ga36e
^ permalink raw reply related
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Andreas Ericsson @ 2008-10-11 22:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Pierre Habouzit, Erez Zilber
In-Reply-To: <20081010165952.GI8203@spearce.org>
Shawn O. Pearce wrote:
> If the caller supplies --tags they want the lightweight, unannotated
> tags to be searched for a match. If a lightweight tag is closer
> in the history, it should be matched, even if an annotated tag is
> reachable further back in the commit chain.
>
> The same applies with --all when matching any other type of ref.
>
In 99% of the cases, "--all" will then give back the currently
checked out branch unless a revision is specified, right?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] gitweb: Better processing format string in custom links in navbar
From: Jakub Narebski @ 2008-10-11 22:02 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Shawn O. Pearce, Petr Baudis
Make processing format string in custom links in action bar ('actions'
feature) more robust. Now there would be no problems if one of
expanded values (for example project name, of project filename)
contains '%'; additionally format string supports '%' escaping by
doubling, i.e. '%%' expands to '%'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Neither of parameters we expand to ($projec, $git_dir, $treehash,
$treebase) is ensured to have no '%' in the value. Therefore
sequential expansion, i.e. expanding one parameter after another could
lead to error.
Also there was no way to put '%' on the link; now it is possible
thanks to '%%' -> '%' expansion.
I have tred to be not too generic; you can check unquote() subroutine
to see how such more generic function (something like tsprintf_simple)
should look like
Pasky, could you check if it works correctly?
gitweb/gitweb.perl | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1116800..cc6edbe 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -290,10 +290,10 @@ our %feature = (
# The 'default' value consists of a list of triplets in the form
# (label, link, position) where position is the label after which
- # to inster the link and link is a format string where %n expands
+ # to insert the link and link is a format string where %n expands
# to the project name, %f to the project path within the filesystem,
# %h to the current hash (h gitweb parameter) and %b to the current
- # hash base (hb gitweb parameter).
+ # hash base (hb gitweb parameter); %% expands to %.
# To enable system wide have in $GITWEB_CONFIG e.g.
# $feature{'actions'}{'default'} = [('graphiclog',
@@ -2866,14 +2866,19 @@ sub git_print_page_nav {
$arg{'tree'}{'hash_base'} = $treebase if defined $treebase;
my @actions = gitweb_check_feature('actions');
+ my %repl = (
+ '%' => '%',
+ 'n' => $project, # project name
+ 'f' => $git_dir, # project path within filesystem
+ 'h' => $treehead || '', # current hash ('h' parameter)
+ 'b' => $treebase || '', # hash base ('hb' parameter)
+ );
while (@actions) {
- my ($label, $link, $pos) = (shift(@actions), shift(@actions), shift(@actions));
+ my ($label, $link, $pos) = splice(@actions,0,3);
+ # insert
@navs = map { $_ eq $pos ? ($_, $label) : $_ } @navs;
# munch munch
- $link =~ s#%n#$project#g;
- $link =~ s#%f#$git_dir#g;
- $treehead ? $link =~ s#%h#$treehead#g : $link =~ s#%h##g;
- $treebase ? $link =~ s#%b#$treebase#g : $link =~ s#%b##g;
+ $link =~ s/%([%nfhb])/$repl{$1}/g;
$arg{$label}{'_href'} = $link;
}
--
Stacked GIT 0.14.3
git version 1.6.0.2
^ permalink raw reply related
* Re: [PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
From: Junio C Hamano @ 2008-10-11 21:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, spearce
In-Reply-To: <alpine.DEB.1.00.0810111336350.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Some confusing tutorials suggest that it would be a good idea to call
> something like this:
>
> git pull origin master:master
>
> While it might make sense to store what you want to merge, it typically
> is plain wrong.
I am somewhat confused.
This "confusion" has been there for very long time and (at least the
scripted version of) git-pull/git-fetch pair has supported a workaround in
the form of --update-head-ok option.
Have we broken the workaround ll.127..147 in git-pull.sh recently, or are
you trying to address something else?
^ permalink raw reply
* Re: [PATCH] "git diff <tree>{3,}": do not reverse order of arguments
From: Junio C Hamano @ 2008-10-11 21:36 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: Junio C Hamano, Matt McCutchen, git
In-Reply-To: <237967ef0810110553r662df370ud1ec34de402bfe1c@mail.gmail.com>
"Mikael Magnusson" <mikachu@gmail.com> writes:
> 2008/10/11 Junio C Hamano <gitster@pobox.com>:
>> Perhaps the thinko was caused by discrepancy between the way internal
>> revision parser handles A..B and the way git-rev-parse parses it. While
>> the internal revision parser parses it into "A ^B", rev-parse gives them
>> in reverse order, i.e. "B ^A" (which is not going to change). In any
>> case, thanks for spotting this.
>
> Ehm, do you mean the internal parses it into "A ^B" and rev-parse gives "^B A"?
Sorry; a typo is in my description on the result from the internal parser.
For A..B, rev-parse gives B^ then A, and internal gives ^A in ent[0] and B
in ent[1].
^ permalink raw reply
* Re: [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Junio C Hamano @ 2008-10-11 21:34 UTC (permalink / raw)
To: Mark Levedahl; +Cc: spearce, dpotapov, git
In-Reply-To: <1223751859-3540-1-git-send-email-mlevedahl@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> Cygwin's POSIX emulation allows use of core.filemode true, unlike native
> Window's implementation of stat / lstat, and Cygwin/git users who have
> configured core.filemode true in various repositories will be very
> unpleasantly surprised to find that git is no longer honoring that option.
> So, this patch fores use of Cygwin's stat functions if core.filemode is
s/fores/forces/;
> static int native_stat = 1;
> +static int core_filemode = 0;
Makes me wonder why "trust_executable_bit" is unavailable here.
Perhaps git_cygwin_config() does not fall back to git_default_config()
for a reason?
> static int git_cygwin_config(const char *var, const char *value, void *cb)
> {
> + if (!strcmp(var, "core.filemode")) {
> + core_filemode = git_config_bool(var, value);
> + native_stat &= !core_filemode;
> + }
> if (!strcmp(var, "core.ignorecygwinfstricks"))
> - native_stat = git_config_bool(var, value);
> + native_stat = git_config_bool(var, value) &&
> + !core_filemode;
> return 0;
> }
If you can safely determine if you would want to use cygwin_stat or not
only after you have read both core.filemode and core.ignorecygwinfstricks,
perhaps keeping the config reader as is (this includes not falling back to
git_default_config()) and instead doing:
static int init_stat(void)
{
...
git_config(git_sygwin_config, NULL);
if (!core_filemode && native_stat) {
cygwin_stat_fn = cygwin_stat;
cygwin_lstat_fn = cygwin_lstat;
} else {
cygwin_stat_fn = stat;
cygwin_lstat_fn = lstat;
}
...
is less yucky?
^ permalink raw reply
* Re: [PATCH] Git.pm: release hash and blob handles
From: Petr Baudis @ 2008-10-11 21:23 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0810111229u60c28671w1afd952200c6fa23@mail.gmail.com>
On Sun, Oct 12, 2008 at 03:29:28AM +0800, Ray Chuan wrote:
> the methods
>
> * hash_and_insert_object
> * cat_blob
>
> use bidirectional pipes to pull/push data from the various git
> utilities, but they don't close them after this is complete. this
> denies Git's subsequent attempts to use these resources, leading to
> failure.
>
> a simple, reproducible test case can be seen at
> http://rctay.spaces.live.com/blog/cns!59D3BFCD027B09E5!792.entry.
Hmm, I don't understand why git-svn does not work for you, but this
patch is not correct. The whole point of the infrastructure is to leave
the pipes open so that subsequent calls _reuse_ these pipes. This leads
to substantial speedup as you do not need to re-fork git all the time.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: Adding Reviewed-by/Tested-by tags to other peoples commits
From: Junio C Hamano @ 2008-10-11 21:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Bennee, git
In-Reply-To: <alpine.DEB.1.00.0810111457300.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Color me puzzled. You said in another mail that you think this is the
> task for the MUA.
Not really. I said that I think people usually do this in MUA with the
current system. I did not mean to say that I think such a partition of
jobs between commit and MUA is ideal.
>> This is a bit tangent, but perhaps rebase needs a hook so that users can
>> strip certain tags automatically from the commit log messages (e.g.
>> things like Reviewd-by: and Tested-by: become less trustworthy when you
>> rebase; S-o-b: becomes somewhat less trustworthy when you "edit" in
>> rebase-i; etc).
>
> Maybe. I am not really convinced of the S-o-b. You kept stressing that
> the SOB is not about validity, but a statement that the patch is
> intellectually proper or some such (IOW it means something like "Darl,
> forget it"). And the point of origin does not change, even if you rebase
> the commit.
The "somewhat less trustworthy" kicks in when you "edit" in rebase-i if
you change the tree that gets recorded. You are right that it is
irrelevant if you ran rebase-i to only edit the commit log message.
^ permalink raw reply
* [PATCH] Git.pm: release hash and blob handles
From: Ray Chuan @ 2008-10-11 19:29 UTC (permalink / raw)
To: git
the methods
* hash_and_insert_object
* cat_blob
use bidirectional pipes to pull/push data from the various git
utilities, but they don't close them after this is complete. this
denies Git's subsequent attempts to use these resources, leading to
failure.
a simple, reproducible test case can be seen at
http://rctay.spaces.live.com/blog/cns!59D3BFCD027B09E5!792.entry.
Signed-off-by: Tay Ray Chuan <rctay89 <at> gmail.com>
---
perl/Git.pm | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 6aab712..7e17f38 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -821,6 +821,7 @@ sub hash_and_insert_object {
throw Error::Simple("in pipe went bad");
}
+ $self->_close_hash_and_insert_object();
return $hash;
}
@@ -910,6 +911,7 @@ sub cat_blob {
throw Error::Simple("couldn't write to passed in filehandle");
}
+ $self->_close_cat_blob();
return $size;
}
--
1.6.0.2
^ permalink raw reply related
* [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-11 19:04 UTC (permalink / raw)
To: spearce, dpotapov; +Cc: git, Mark Levedahl
In-Reply-To: <1223751280-2104-1-git-send-email-mlevedahl@gmail.com>
Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch fores use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Resend as I mangled Shawn's email address.
Documentation/config.txt | 4 +++-
compat/cygwin.c | 10 +++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7161597..a3a9495 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -124,7 +124,9 @@ core.ignoreCygwinFSTricks::
one hierarchy using Cygwin mount. If true, Git uses native Win32 API
whenever it is possible and falls back to Cygwin functions only to
handle symbol links. The native mode is more than twice faster than
- normal Cygwin l/stat() functions. True by default.
+ normal Cygwin l/stat() functions. True by default, unless core.filemode
+ is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
+ POSIX emulation is required to support core.filemode.
core.trustctime::
If false, the ctime differences between the index and the
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 423ff20..54028b3 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -91,13 +91,21 @@ static int cygwin_stat(const char *path, struct stat *buf)
* functions should be used. The choice is determined by core.ignorecygwinfstricks.
* Reading this option is not always possible immediately as git_dir may be
* not be set yet. So until it is set, use cygwin lstat/stat functions.
+ * However, if core.filemode is true, we *must* use the Cygwin posix stat as
+ * the Windows stat fuctions do not determine posix filemode.
*/
static int native_stat = 1;
+static int core_filemode = 0;
static int git_cygwin_config(const char *var, const char *value, void *cb)
{
+ if (!strcmp(var, "core.filemode")) {
+ core_filemode = git_config_bool(var, value);
+ native_stat &= !core_filemode;
+ }
if (!strcmp(var, "core.ignorecygwinfstricks"))
- native_stat = git_config_bool(var, value);
+ native_stat = git_config_bool(var, value) &&
+ !core_filemode;
return 0;
}
--
1.6.0.2.535.g47d45.dirty
^ permalink raw reply related
* [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-11 18:54 UTC (permalink / raw)
To: spearc, dpotapov; +Cc: git, Mark Levedahl
Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch fores use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Documentation/config.txt | 4 +++-
compat/cygwin.c | 10 +++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7161597..a3a9495 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -124,7 +124,9 @@ core.ignoreCygwinFSTricks::
one hierarchy using Cygwin mount. If true, Git uses native Win32 API
whenever it is possible and falls back to Cygwin functions only to
handle symbol links. The native mode is more than twice faster than
- normal Cygwin l/stat() functions. True by default.
+ normal Cygwin l/stat() functions. True by default, unless core.filemode
+ is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
+ POSIX emulation is required to support core.filemode.
core.trustctime::
If false, the ctime differences between the index and the
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 423ff20..54028b3 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -91,13 +91,21 @@ static int cygwin_stat(const char *path, struct stat *buf)
* functions should be used. The choice is determined by core.ignorecygwinfstricks.
* Reading this option is not always possible immediately as git_dir may be
* not be set yet. So until it is set, use cygwin lstat/stat functions.
+ * However, if core.filemode is true, we *must* use the Cygwin posix stat as
+ * the Windows stat fuctions do not determine posix filemode.
*/
static int native_stat = 1;
+static int core_filemode = 0;
static int git_cygwin_config(const char *var, const char *value, void *cb)
{
+ if (!strcmp(var, "core.filemode")) {
+ core_filemode = git_config_bool(var, value);
+ native_stat &= !core_filemode;
+ }
if (!strcmp(var, "core.ignorecygwinfstricks"))
- native_stat = git_config_bool(var, value);
+ native_stat = git_config_bool(var, value) &&
+ !core_filemode;
return 0;
}
--
1.6.0.2.535.g47d45.dirty
^ permalink raw reply related
* [ANNOUNCE] CGIT 0.8.1
From: Lars Hjemli @ 2008-10-11 18:46 UTC (permalink / raw)
To: Git Mailing List
cgit-0.8.1, another webinterface for git, is now available.
clone: git://hjemli.net/pub/git/cgit
browse: http://hjemli.net/git/cgit
This is a minor feature-release which adds support for extracting
snapshot revision (i.e. tag name) from the snapshot name instead of
relying on querystring parameters, i.e. the following urls will
download the expected revisons:
http://hjemli.net/git/cgit/snapshot/cgit-0.8.1.tar.gz
http://hjemli.net/git/cgit/snapshot/cgit-0.8.tar.gz
---
Shortlog since v0.8:
Lars Hjemli (5):
ui-shared: specify correct css class for summary tab
Add cgit_query.nohead flag
ui-snapshot: add dwimmery
Makefile: enable compilation on uclibc
CGIT 0.8.1
^ permalink raw reply
* Re: User Authentication ?
From: Jakub Narebski @ 2008-10-11 18:28 UTC (permalink / raw)
To: Neshama Parhoti; +Cc: git
In-Reply-To: <912ec82a0810110941t33343fe1mfe1bce58739f79fa@mail.gmail.com>
"Neshama Parhoti" <pneshama@gmail.com> writes:
> I want to setup a git server on the web but I need user
> authentication.
>
> From what I understand, currently git-daemon does not support
> authentication.
The purpose of git-daemon is to allow fast (and bandwidth-saving)
anonymous read-only (fetch) access to git repositories. The ability
to push via git-daemon was added later, and is turned off by default
because it should be used only in special situation.
> Is there any way to achieve that ?
The reason behind git-daemon not supporting authentication is that
re-implementing authentication poorly is a bad idea.
If you need authentication there is SSH that provides authentication
(for ssh:// protocol), or WebDAV (for HTTP push protocol). Perhaps
also future "smart" HTTP server would support some kind of
authentification...
> I really don't want to give ssh logins for people who I just want to
> be able to access my repository...
First, you can always set git-shell as shell for those git only
accounts. Second, you can set up Gitosis, which IIRC needs only single
account, and handles authentication by itself; I have heard also of
ssh_acl in this context...
I don't know if there is some other equivalent of Gitosis...
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* User Authentication ?
From: Neshama Parhoti @ 2008-10-11 16:41 UTC (permalink / raw)
To: git
Hi All,
I want to setup a git server on the web but I need user authentication.
>From what I understand, currently git-daemon does not support authentication.
Is there any way to achieve that ?
I really don't want to give ssh logins for people who I just want to
be able to access my repository...
Thank you,
Pnesh.
^ permalink raw reply
* [PATCH] print an error message for invalid path
From: Dmitry Potapov @ 2008-10-11 16:39 UTC (permalink / raw)
To: Johannes Sixt, Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <48EAFBC2.7020305@viscovery.net>
If verification of path failed, it is always better to print an error message
saying this than relying on the caller function to print a meaningful error
message (especially when the callee already prints error message for another
situation).
Because the callers of add_index_entry_with_check() did not print any error
message, it resulted that the user would not notice the problem when checkout
if an invalid path failed.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
On Tue, Oct 07, 2008 at 08:03:46AM +0200, Johannes Sixt wrote:
>
> Look at the original patch. You did not change the behavior except to
> write more error messages. Maybe I misunderstand the words "to error out".
> I understand them as "to detect an error and return early", but not "write
> an error message".
For me, to "error out" means to show an error to the user. Usually, it
implies that the program will return after that, though not necessary
immediately. (Like gcc may print an error but it continues to parse the
program and may report more errors).
You are right that I have not changed anything in terms of exiting
earlier, and because I am aware about any commonly accepted definition
of what "error out" means, I have replaced the comment with less
ambiguous and detail description.
builtin-update-index.c | 2 +-
read-cache.c | 6 ++++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 417f972..3a2291b 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -218,7 +218,7 @@ static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
struct cache_entry *ce;
if (!verify_path(path))
- return -1;
+ return error("Invalid path '%s'", path);
len = strlen(path);
size = cache_entry_size(len);
diff --git a/read-cache.c b/read-cache.c
index 901064b..aff6390 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -591,8 +591,10 @@ struct cache_entry *make_cache_entry(unsigned int mode,
int size, len;
struct cache_entry *ce;
- if (!verify_path(path))
+ if (!verify_path(path)) {
+ error("Invalid path '%s'", path);
return NULL;
+ }
len = strlen(path);
size = cache_entry_size(len);
@@ -874,7 +876,7 @@ static int add_index_entry_with_check(struct index_state *istate, struct cache_e
if (!ok_to_add)
return -1;
if (!verify_path(ce->name))
- return -1;
+ return error("Invalid path '%s'", ce->name);
if (!skip_df_check &&
check_file_directory_conflict(istate, ce, pos, ok_to_replace)) {
--
1.6.0.2.447.g64b01
^ permalink raw reply related
* Re: [PATCH v2] correct verify_path for Windows
From: Dmitry Potapov @ 2008-10-11 16:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Joshua Juran, Giovanni Funchal, git, Shawn O. Pearce
In-Reply-To: <48EAFF23.1020607@viscovery.net>
On Tue, Oct 07, 2008 at 08:18:11AM +0200, Johannes Sixt wrote:
> Dmitry Potapov schrieb:
> > +#if defined(_WIN32) || defined(__CYGWIN__)
>
> I think that for consistency you should use __MINGW32__ instead of _WIN32.
I like Alex's suggestion more to use FILESYSTEM_CASEINSENSITIVE.
>
> > + /* On Windows, file names are case-insensitive */
> > + case 'G':
> > + if ((rest[1]|0x20) != 'i')
> > + break;
> > + if ((rest[2]|0x20) != 't')
> > + break;
>
> We have tolower().
I am aware of that, but I am not sure what we gain by using it. It seems
it makes only code bigger and slow. As to readability, I don't see much
improvement... Isn't obvious what this code does, especially with the
above comment?
Dmitry
^ permalink raw reply
* [PATCH] Fix testcase failure when extended attributes are in use
From: Deskin Miller @ 2008-10-11 15:41 UTC (permalink / raw)
To: spearce; +Cc: git, heikki.orsila
06cbe855 (Make core.sharedRepository more generic, 2008-04-16) made
several testcases in t1301-shared-repo.sh which fail if on a system
which creates files with extended attributes (e.g. SELinux), since ls
appends a '+' sign to the permission set in such cases. This fixes the
testcase to strip any such sign prior to verifying the permission set.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Shawn, I read an email that said you'd maintain until Sunday the 12th, so I'm
sending this to you; if you want to punt to Junio, feel free.
Deskin Miller
t/t1301-shared-repo.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t1301-shared-repo.sh b/t/t1301-shared-repo.sh
index dc85e8b..b244f3e 100755
--- a/t/t1301-shared-repo.sh
+++ b/t/t1301-shared-repo.sh
@@ -83,7 +83,7 @@ do
rm -f .git/info/refs &&
git update-server-info &&
actual="$(ls -l .git/info/refs)" &&
- actual=${actual%% *} &&
+ actual=$(echo "$actual" | sed -e "s/[+]\? .*$//") &&
test "x$actual" = "x-$y" || {
ls -lt .git/info
false
@@ -96,7 +96,7 @@ do
rm -f .git/info/refs &&
git update-server-info &&
actual="$(ls -l .git/info/refs)" &&
- actual=${actual%% *} &&
+ actual=$(echo "$actual" | sed -e "s/[+]\? .*$//") &&
test "x$actual" = "x-$x" || {
ls -lt .git/info
false
--
1.6.0.2.307.gc427
^ permalink raw reply related
* Re: Adding Reviewed-by/Tested-by tags to other peoples commits
From: Johannes Schindelin @ 2008-10-11 13:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Bennee, git
In-Reply-To: <7vfxn3jqt9.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 11 Oct 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sat, 11 Oct 2008, Alex Bennee wrote:
> >
> >> I've just tested/reviewed a patch of someone elses and I want to
> >> forward it on the appropriate mailing list. I gather for Linux you
> >> just add the appropriate tags to the commit. Does git offer a
> >> shortcut for doing this or do you have to do a reset HEAD^ and
> >> re-commit with a copy&pasted and modified commit message?
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/75250/focus=76304
> >
> > In the end, nothing happened, but I could see that you might want to
> > push for this patch.
>
> The fact a particular change has been reviewed is an attribute of a
> commit, and by recording the fact once (perhaps when you commit for the
> first time, or if your workflow is "commit blindly, then review, and
> then amend" then when you amend that commit), the commit object will
> remember that fact.
If that was the goal, you would _have_ to add commit notes. Because
otherwise you would have to pretend to have changed the commit, which you
did not at all.
> The patch you quoted adds Reviewed-by: at format-patch time, but I
> suspect that is a wrong approach.
Color me puzzled. You said in another mail that you think this is the
task for the MUA. When I send patches (even forwarded ones), I use
format-patch just before pasting into the MUA (I do not trust send-email).
And that's where Git can kick in: format-patch. Not the MUA.
So technically, I understood that the format-patch approach is exactly the
same as you were proposing, only that you do not ask the MUA to do Git's
job.
Unless, of course, you are talking about the reviewing style where the
patch does not leave the MUA until it is to be forwarded.
> You have to remember and recall which ones you reviewed (and which ones
> you didn't) when you run format-patch.
Don't you have to do that anyway? I do not see how giving format-patch a
new option --reviewed-by would change the equation in any way.
> This is a bit tangent, but perhaps rebase needs a hook so that users can
> strip certain tags automatically from the commit log messages (e.g.
> things like Reviewd-by: and Tested-by: become less trustworthy when you
> rebase; S-o-b: becomes somewhat less trustworthy when you "edit" in
> rebase-i; etc).
Maybe. I am not really convinced of the S-o-b. You kept stressing that
the SOB is not about validity, but a statement that the patch is
intellectually proper or some such (IOW it means something like "Darl,
forget it"). And the point of origin does not change, even if you rebase
the commit.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] "git diff <tree>{3,}": do not reverse order of arguments
From: Mikael Magnusson @ 2008-10-11 12:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matt McCutchen, git
In-Reply-To: <7vwsgfjrp6.fsf@gitster.siamese.dyndns.org>
2008/10/11 Junio C Hamano <gitster@pobox.com>:
> Perhaps the thinko was caused by discrepancy between the way internal
> revision parser handles A..B and the way git-rev-parse parses it. While
> the internal revision parser parses it into "A ^B", rev-parse gives them
> in reverse order, i.e. "B ^A" (which is not going to change). In any
> case, thanks for spotting this.
Ehm, do you mean the internal parses it into "A ^B" and rev-parse gives "^B A"?
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH (GITK) v2 4/4] gitk: Implement batch lookup and caching of encoding attrs.
From: Paul Mackerras @ 2008-10-11 12:03 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <200810111328.50951.angavrilov@gmail.com>
Alexander Gavrilov writes:
> > And if [tcl_encoding] is slow, then it should have a cache. There's
> > only likely to be at most 2 or 3 values it gets called for, and it's
> > a constant function.
>
> In git-gui the slowdown appeared during the construction of the menu
> listing all available encodings, so a simple cache would not have helped.
> I reimplemented it using a lookup table to resolve aliases (constructed
> on the first run). But it can be thought of as a precalculated cache.
Hmmm, one that uses more time and memory than it needs to for gitk's
use... I guess it's not a lot, but it still seems unnecessary, unless
you can see a need for a menu of encodings in gitk.
> > At this point, what I think I might do is apply your set of patches
> > (but with 2/4 and 3/4 folded into a single patch) and then go through
> > and do another commit that addresses the concerns I've raised. OK?
>
> Maybe I should resend the patches, scrapping path_encoding_cache,
> and adding the optimized version of tcl_encoding?
OK.
Paul.
^ permalink raw reply
* Re: Adding Reviewed-by/Tested-by tags to other peoples commits
From: Junio C Hamano @ 2008-10-11 11:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Bennee, git
In-Reply-To: <alpine.DEB.1.00.0810111239590.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 11 Oct 2008, Alex Bennee wrote:
>
>> I've just tested/reviewed a patch of someone elses and I want to forward
>> it on the appropriate mailing list. I gather for Linux you just add the
>> appropriate tags to the commit. Does git offer a shortcut for doing this
>> or do you have to do a reset HEAD^ and re-commit with a copy&pasted and
>> modified commit message?
>
> http://thread.gmane.org/gmane.comp.version-control.git/75250/focus=76304
>
> In the end, nothing happened, but I could see that you might want to push
> for this patch.
The fact a particular change has been reviewed is an attribute of a
commit, and by recording the fact once (perhaps when you commit for the
first time, or if your workflow is "commit blindly, then review, and then
amend" then when you amend that commit), the commit object will remember
that fact.
The patch you quoted adds Reviewed-by: at format-patch time, but I suspect
that is a wrong approach. You have to remember and recall which ones you
reviewed (and which ones you didn't) when you run format-patch. People
who commit and immediately format-patch to send, or people who do not
review until immediately before format-patch to send, would not realize
the downside of the approach, but when your work style is to perform
commit/review and e-mail communication in separate phases, it matters.
This is a bit tangent, but perhaps rebase needs a hook so that users can
strip certain tags automatically from the commit log messages (e.g.
things like Reviewd-by: and Tested-by: become less trustworthy when you
rebase; S-o-b: becomes somewhat less trustworthy when you "edit" in
rebase-i; etc).
^ permalink raw reply
* Re: [Gitk PATCH 1/6] gitk: Add procedure to create accelerated menus
From: Robin Rosenberg @ 2008-10-11 11:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18672.1017.68669.913415@cargo.ozlabs.ibm.com>
lördagen den 11 oktober 2008 03.40.09 skrev Paul Mackerras:
> Robin Rosenberg writes:
>
> > +proc mcw {menubar args} {
> > + set ai [lsearch $args "-label"]
> > + if { $ai > 0 } {
> > + set label [lindex $args [expr {$ai + 1}]]
> > + foreach {l u} [::tk::UnderlineAmpersand $label] {
>
> Where did you find out about ::tk::UnderlineAmpersand? Is it part of
> the exported interface of Tk that we can rely on in future?
I found it here. http://wiki.tcl.tk/1632. It hints that it may not be unoffical. Seems to
original from: http://groups.google.com/group/comp.lang.perl.tk/browse_thread/thread/5b6f4c6a4a9f17b4/c9f8ab47800d27ee?lnk=st&q=#c9f8ab47800d27ee
so if someone thinks there is a problem we could replace it with UnderlineAmpersand
with tcl code to do the same (or rip it as is if the license allows it).
>
> > +# Wrapper for mc to remove ampersands used for accelerators.
> > +proc mca {label} {
> > + set tl8 [mc $label]
> > + foreach {l u} [::tk::UnderlineAmpersand $tl8] break
> > + return $l
>
> return [string map {"&" ""} [mc $label]]
>
> instead, perhaps?
In theory we should translate && to & also, which UnderLineAmpersand does.
-- robin
^ permalink raw reply
* Re: [Gitk Patch 0/6]
From: Robin Rosenberg @ 2008-10-11 11:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18672.4878.128010.174357@cargo.ozlabs.ibm.com>
lördagen den 11 oktober 2008 04.44.30 skrev Paul Mackerras:
> Robin Rosenberg writes:
>
> > (This is a resend to include gitk maintainer Paul Mackerras)
>
> Thanks.
>
> > I finally got tired of pressing Alt and some letter to activate menus in Gitk.
> > For example in "any" program you can press Alt-F to have the File menu drop
> > down and then select the underscored character to select the wanted menu.
> >
> > This series makes it possible. Friends of TCL may think my solution is too
> > hack-ish. It doesn't fix all of the similary problem (mostly button) but
> > that is the subject of later patches as it looks like it requires other
> > means.
>
> It'll do for a first cut, but there would be a nicer way to do it, I
> think.
>
> Also, I think patches 2 and 4 should be combined into one, as should
> patches 5 and 6. I'll do that and apply the series as 4 commits,
> unless you have an objection.
I split the commits to simplify review. My thought about squashing would
be different, but I have no strong opinions here. I was thinking 1+2, 4+5, 3+5, 6
-- robin
^ permalink raw reply
* [PATCH] Introduce core.keepHardLinks
From: Johannes Schindelin @ 2008-10-11 11:45 UTC (permalink / raw)
To: git, gitster, spearce
When a tracked file was hard linked, we used to break the hard link
whenever Git writes to that file. Make that optional.
To keep the implementation simple, mode changes will still break the
hard links.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
With the current revision of the patch, I can set
keep_hard_links = 1 and the test suite still passes.
I briefly tried to fix the "mode changes" issue, but replacing
the "st.st_mode != ce->ce_mode" with "S_ISREG(ce->ce_mode)"
(and consequently also adding
"|| (keep_hard_links && chmod(path, mode)" to create_file()),
made at least t3400 fail, and then I ran out of my Git time budget.
Documentation/config.txt | 4 +++
cache.h | 1 +
config.c | 5 ++++
entry.c | 7 ++++-
environment.c | 1 +
t/t0056-hardlinked.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 74 insertions(+), 2 deletions(-)
create mode 100644 t/t0056-hardlinked.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 173386e..7bfe431 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -207,6 +207,10 @@ core.symlinks::
file. Useful on filesystems like FAT that do not support
symbolic links. True by default.
+core.keepHardLinks::
+ If true, do not break hard links by deleting and recreating the
+ files. Off by default.
+
core.gitProxy::
A "proxy command" to execute (as 'command host port') instead
of establishing direct connection to the remote server when
diff --git a/cache.h b/cache.h
index c89f2c6..c4bdece 100644
--- a/cache.h
+++ b/cache.h
@@ -479,6 +479,7 @@ enum rebase_setup_type {
extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
+extern int keep_hard_links;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index 18d305c..35ffdef 100644
--- a/config.c
+++ b/config.c
@@ -490,6 +490,11 @@ static int git_default_core_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.keephardlinks")) {
+ keep_hard_links = git_config_bool(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/entry.c b/entry.c
index aa2ee46..dfddf83 100644
--- a/entry.c
+++ b/entry.c
@@ -82,7 +82,8 @@ static void remove_subtree(const char *path)
static int create_file(const char *path, unsigned int mode)
{
mode = (mode & 0100) ? 0777 : 0666;
- return open(path, O_WRONLY | O_CREAT | O_EXCL, mode);
+ return open(path, O_WRONLY | O_CREAT |
+ (keep_hard_links ? O_TRUNC : O_EXCL), mode);
}
static void *read_blob_entry(struct cache_entry *ce, const char *path, unsigned long *size)
@@ -225,7 +226,9 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
if (!state->force)
return error("%s is a directory", path);
remove_subtree(path);
- } else if (unlink(path))
+ } else if ((!keep_hard_links || !S_ISREG(st.st_mode) ||
+ st.st_mode != ce->ce_mode) &&
+ unlink(path))
return error("unable to unlink old '%s' (%s)", path, strerror(errno));
} else if (state->not_new)
return 0;
diff --git a/environment.c b/environment.c
index 0693cd9..ef721e0 100644
--- a/environment.c
+++ b/environment.c
@@ -42,6 +42,7 @@ enum safe_crlf safe_crlf = SAFE_CRLF_WARN;
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
enum branch_track git_branch_track = BRANCH_TRACK_REMOTE;
enum rebase_setup_type autorebase = AUTOREBASE_NEVER;
+int keep_hard_links = 0;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
diff --git a/t/t0056-hardlinked.sh b/t/t0056-hardlinked.sh
new file mode 100644
index 0000000..934c2bc
--- /dev/null
+++ b/t/t0056-hardlinked.sh
@@ -0,0 +1,58 @@
+#!/bin/sh
+
+test_description='read-tree and checkout respect hardlinked files'
+
+. ./test-lib.sh
+
+cat > file << EOF
+1. Nf3 Nf6 2. c4 g6 3. Nc3 Bg7 4. d4 O-O 5. Bf4 d5 6. Qb3 dxc4 7. Qxc4 c6
+8. e4 Nbd7 9. Rd1 Nb6 10. Qc5 Bg4 11. Bg5 Na4 12. Qa3 Nxc3 13. bxc3 Nxe4
+14. Bxe7 Qb6 15. Bc4 Nxc3 16. Bc5 Rfe8+ 17. Kf1 Be6 18. Bxb6 Bxc4+ 19. Kg1 Ne2+
+20. Kf1 Nxd4+ 21. Kg1 Ne2+ 22. Kf1 Nc3+ 23. Kg1 axb6 24. Qb4 Ra4 25. Qxb6 Nxd1
+26. h3 Rxa2 27. Kh2 Nxf2 28. Re1 Rxe1 29. Qd8+ Bf8 30. Nxe1 Bd5 31. Nf3 Ne4
+32. Qb8 b5 33. h4 h5 34. Ne5 Kg7 35. Kg1 Bc5+ 36. Kf1 Ng3+ 37. Ke1 Bb4+
+38. Kd1 Bb3+ 39. Kc1 Ne2+ 40. Kb1 Nc3+
+EOF
+
+ln file link || {
+ say "Could not hard link; skipping test"
+ test_done
+ exit
+}
+
+test_expect_success setup '
+
+ git config core.keepHardLinks true &&
+ test_cmp file link &&
+ cp file old &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo "41. Kc1 Rc2#" >> file &&
+ git add file &&
+ test_tick &&
+ git commit -m 2nd &&
+ test_cmp file link &&
+ ! test_cmp file old
+
+'
+
+test_expect_success 'checking a file out does not break the hard link' '
+
+ git checkout HEAD^ -- file &&
+ test_cmp file link &&
+ test_cmp file old
+
+'
+
+test_expect_success 'read-tree -u -m does not break the hard link' '
+
+ git reset --hard &&
+ test_cmp file link &&
+ git read-tree -u -m HEAD^ &&
+ test_cmp file link &&
+ test_cmp file old
+
+'
+
+test_done
--
1.6.0.2.749.g0cc32
^ permalink raw reply related
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