* Re: Git-1.6.0.2-preview20080921 on Windows
From: Steffen Prohaska @ 2008-09-22 5:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: msysGit, Git Mailing List
In-Reply-To: <m3od2hl3lv.fsf@localhost.localdomain>
On Sep 21, 2008, at 9:07 PM, Jakub Narebski wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Git-1.6.0.2-preview20080921 for Windows is available at
>>
>> http://code.google.com/p/msysgit/downloads
>
> Wouldn't it be better if this email had [ANNOUNCE] in the subject, to
> be catched by mail2rss thingy that feeds Ohloh page for Git?
Your are right.
Steffen
^ permalink raw reply
* Re: Git-1.6.0.2-preview20080921 on Windows
From: Steffen Prohaska @ 2008-09-22 5:46 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: msysGit, Git Mailing List
In-Reply-To: <bb6f213e0809211119t3c2bc6e8x3342bd33bef38916@mail.gmail.com>
On Sep 21, 2008, at 8:19 PM, Alexander Gavrilov wrote:
> On Sun, Sep 21, 2008 at 9:30 PM, Steffen Prohaska <prohaska@zib.de>
> wrote:
>> Git-1.6.0.2-preview20080921 for Windows is available at
>>
>> http://code.google.com/p/msysgit/downloads
>>
>> The version installed is based on Junio's current
>> 'maint' (cc185a6a8a)
>> plus the patch series I sent today, see
>>
>> http://article.gmane.org/gmane.comp.version-control.git/92605
>>
>> The new installer is not yet featured on the msysgit homepage,
>> because
>> the installer contains the new "libexec/git-core" layout, which has
>> not
>> been tested much. I'll wait a few days to see if the new layout
>> works.
>> If hear nothing bad, I'll move the "Featured" flag to 1.6.0.2.
>
> You forgot to merge my build of the Cygwin kill utility for MSys.
> Available here:
>
> http://repo.or.cz/w/msysgit.git?a=log;h=refs/heads/mob
Apologies. I'll include it in the next release.
> Also, when I start git-gui from an empty repository, or try to amend
> the root commit, I get:
>
[...]
>
> I get the same error if I simply run 'git mktree' as well.
This is fixed by:
diff --git a/mktree.c b/mktree.c
index e0da110..9545c96 100644
--- a/mktree.c
+++ b/mktree.c
@@ -70,6 +70,9 @@ int main(int ac, char **av)
unsigned char sha1[20];
int line_termination = '\n';
+ if (argv[0] && *argv[0])
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory();
while ((1 < ac) && av[1][0] == '-') {
I'll create an updated installer soon.
Steffen
^ permalink raw reply related
* Re: [PATCH v2 0/1] git-svn: testcase for partial rebuild
From: Eric Wong @ 2008-09-22 4:12 UTC (permalink / raw)
To: Junio C Hamano, Deskin Miller; +Cc: git
In-Reply-To: <20080921024538.GB2505@riemann.deskinm.fdns.net>
Deskin Miller <deskinm@umich.edu> wrote:
> ---
> On Wed, Sep 17, 2008 at 11:38:04PM -0700, Eric Wong wrote:
> > This seems to break the following test case for me:
> >
> > *** t9107-git-svn-migrate.sh ***
> > * ok 1: setup old-looking metadata
> > * ok 2: git-svn-HEAD is a real HEAD
> > * ok 3: initialize old-style (v0) git svn layout
> > * ok 4: initialize a multi-repository repo
> > * ok 5: multi-fetch works on partial urls + paths
> > * ok 6: migrate --minimize on old inited layout
> > * FAIL 7: .rev_db auto-converted to .rev_map.UUID
> >
> > I haven't had time to diagnose it. Also, can you add a test that
> > demonstrates this functionality (and ensures things keeps working when
> > future work is done on git-svn?)
>
> Thanks for the response; I had a bug in my Perl that my testing hadn't caught.
> Gave me an opportunity to learn how the git testsuites work!
>
> This testcase fails for me when applied to master, and passes with patch 1/1 in
> the series.
Thanks Deskin, this series is
Acked-by: Eric Wong <normalperson@yhbt.net>
Junio: I would apply the patch series in reverse order to not break
tests on potential bisections, however.
--
Eric Wong
^ permalink raw reply
* Re: ignoring files/directories in git
From: mwolfe38 @ 2008-09-22 0:06 UTC (permalink / raw)
To: git
In-Reply-To: <19596152.post@talk.nabble.com>
I just thought that I would add that the reason is a bug in the 1.5.4.3
version that I am using which is the ubuntu 8.04 repository version.
According to some developers, the current version should fix this issue.
mwolfe38 wrote:
>
> I'm working on a project by myself and using git mostly just to learn
> about it.
> In my project I have several directories I want to have git ignore. One of
> them being
> cache/ and the other log/
> I've added them to the .gitignore file which I have in the initial
> directory of the repository
> The contents of my gitignore are:
>
> .settings
> .cache
> cache/
> log/
> .project
>
> However, if I do
> git add .
> It will add the files from cache and log anyways.
> I know git add . will add anything that hasn't been added but shouldn't it
> ignore files in .gitignore?
> If not, what is the point, I would just ignore them manually anyways.
> The main reason i like doing git add .
> is because i'm using symfony php framework which makes good use of scripts
> which generates lots if initial files for you and thus adding one at a
> time would be a pain.
>
> Any idea what might be going on here? I thought maybe I had added those
> directories before putting them in .gitignore so i used git rm -r to
> remove them but they still show back up with doing git add .
>
> Thanks in advance
>
--
View this message in context: http://www.nabble.com/ignoring-files-directories-in-git-tp19596152p19599905.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* out of memory problem
From: Guo Tang @ 2008-09-21 22:59 UTC (permalink / raw)
To: Git mailing list
Gentlemen,
I try to run "git gc" on linux kernel tree. The virtual memory keeps
going up until over 3GB, then crash.
Tried twice with the v1.6.0.2, same result.
Then I used the git coming with FC9 (v1.5.5.1), the peak virutal memory
usage is about 1.5GB. "git gc" finished without any trouble.
Could there be a memory leak in v1.6.0.2?
Thanks,
Guo
^ permalink raw reply
* Re: [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI
From: Paul Mackerras @ 2008-09-21 22:55 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Shawn O. Pearce
In-Reply-To: <1221685659-476-1-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> File encoding can be specified in the following ways:
>
> 1) It defaults to the current locale encoding.
> 2) It can be overridden by setting the gui.encoding option.
I'm happy with providing a way to say what the default encoding of
files in the repository is, but I wonder why it is seen as a property
of the GUI. Is it just that there is an existing "gui" section that
is convenient to use, or does git-gui already use gui.encoding (before
this patch series), or is there some other reason?
> 3) It can be further set on per-file basis by specifying
> the 'encoding' attribute in gitattributes.
I haven't used .gitattributes before, but I would expect that the
.gitattributes files would be stored in the repository along with
everything else. If that's the case, then for gitk at least there is
the question of which version of a given .gitattributes file one
should use when viewing the tree for a commit which isn't the
currently checked-out commit - do you use the version from that tree,
or the version in the working directory? We seem to be using the
latter at present, and caching the results. Is there a philosophical
reason to do that, other than speed? (Also it seems that we won't
notice if the user changes .gitattributes after we've looked at it, or
if they create one after we've looked for one and not found it.)
> Since git apparently cannot work with filenames in non-locale
> encodings anyway, I did not try to do anything about it apart
> from fixing some obvious bugs.
For Linux, filenames are sequences of non-null bytes, so using
binary encoding to read them in Tcl sounds about right.
> There are also some bugs in handling of commit encodings in gitk,
> but they are out of the scope of this series.
I'm interested to hear what they are.
Paul.
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Jakub Narebski @ 2008-09-21 22:21 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0809202134p2457e0cdn50ae8183ba07bcde@mail.gmail.com>
On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
> > > +
> > > +#define CE_EXTENDED_FLAGS (0)
> > > +
> > > +/*
> > > + * Safeguard to avoid saving wrong flags:
> > > + * - CE_EXTENDED2 won't get saved until its semantic is known
> > > + * - Bits in 0x0000FFFF have been saved in ce_flags already
> > > + * - Bits in 0x003F0000 are currently in-memory flags
> > > + */
> > > +#if CE_EXTENDED_FLAGS & 0x80CFFFFF
> > > +#error "CE_EXTENDED_FLAGS out of range"
> > > +#endif
> >
> >
> > I don't quite understand the above fragment (especially with the fact
> > that CE_EXTENDED_FLAGS is defined as (0))...
>
> Because this patch does not introduce any new on-disk flag yet so
> CE_EXTENDED_FLAGS remains 0. In the next patch, CE_EXTENDED_FLAGS will
> be updated to have CE_NO_CHECKOUT.
Well, now I understand CE_EXTENDED_FLAGS being (0).
What I still don't understand the pattern it is protected against.
As I understand it if CE_EXTENDED_FLAGS & 0x0000FFFF it is bad,
because ce_flags saved flags are not extended flags, and
CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags. But why
CE_EXTENDED_FLAGS & 0x80C00000 is bad, and why (if I understand it)
CE_EXTENDED_FLAGS & 0x00300000 is not bad.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: clone fails: Could not get the current working directory
From: John Freeman @ 2008-09-21 22:18 UTC (permalink / raw)
To: Paul Johnston, git
In-Reply-To: <d3a045300809211012l35b1ec2dq39f4174170d8c926@mail.gmail.com>
Paul Johnston wrote:
> On the server, where is git installed? I had a similar problem with
> clone when my git installation was not in a PATH known to ssh.
It is installed in a non-standard directory, /opt/csg/bin. This is part
of the system-wide PATH defined in /etc/bashrc. I also added it to my
~/.bashrc before I discovered that fact.
> Try
> creating symlinks from usr/bin (for example) to your git executables
> to see if this solves the problem.
I did create symlinks in $HOME/local/bin which is in the PATH defined in
my ~/.bashrc. I do not have administrator privileges, so I cannot put
symlinks in /usr/bin. I think it is finding the executable just fine,
but that there is some issue with accessing the repo directory. I have
tested with
> ssh user@remote.system.edu -- "git-upload-pack"
and it works as expected.
> Also, search the archives for
> git-upload-pack.
>
I've skimmed it, and I see nothing related to my problem. Specifying
--upload-pack explicitly gives the same error.
Thank you for the response, though. Are there any other ideas?
- John
^ permalink raw reply
* Re: [PATCH v2 00/14] Sparse checkout
From: Jakub Narebski @ 2008-09-21 22:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <fcaeb9bf0809210432x500cf586k877d07b335bf33de@mail.gmail.com>
On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>>> On 9/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> [...] Checking the source again, I
> misunderstood gitattributes/gitingore's leading '/' notion (in a good
> way). Leading '/' means './' and that would be fine for
> .git{attributes,ignore}.
By the way it would be nice if gitignore accepted './' as equivalent
to current '/', as this is something I think (from questions here
and on #git) that people expect to work (not reading documentation
carefully enough). This is something that for example `ls' would use,
or something that `find' returns.
> In sparse patterns, leading '/' means toplevel directory because you
> may want to checkout some more from a subdirectory without moving up
> to toplevel directory. Now .git{ignore,attributes} and sparse patterns
> are incompatible, gaah...
Well, this doesn't make sense in a _file_, but makes perfect sense when
invoked from _command line_, as option argument.
But I was thinking more about centralizing pattern matching wrt either
full pathname (with prefix stripped, or not), or basename of a file.
If match check is centralized, then if you enhance pattern language (for
selecting which files to mark no-checkout in sparse checkout for example
by allowing '**' which matches also '/' (if you don't go route of 'tar'
with '--wildcards-match-slash' option)), then it would enhance gitignore
patterns and gitattributes patterns too (well, excluding the fact that
they are delimited differently).
>> Second, while unifying the "check the match" part of gitignore,
>> gitattribute and sparse checkout would be IMVHO a good idea, [...]
>
> It is surely good. Optimization like 68492fc (Speedup scanning for
> excluded files.) could be applied to .gitattributes too. Now I know
> why I was confused when reading the matching part of
> .git{attributes,ignore}.
And all speedups (well, perhaps not all) would apply to all classes
of matching against patterns as well.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 7/7] Windows: Revert to default paths and convert them by RUNTIME_PREFIX
From: Johannes Sixt @ 2008-09-21 21:58 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1222014278-11071-8-git-send-email-prohaska@zib.de>
On Sonntag, 21. September 2008, Steffen Prohaska wrote:
> The RUNTIME_PREFIX mechanism allows us to use the default (absolute) paths
> on Windows too. Defining RUNTIME_PREFIX explicitly requests for
> translation of paths during runtime, depending on the path to the
> executable.
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
> Makefile | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 8181f74..98278f0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -767,6 +767,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> SNPRINTF_RETURNS_BOGUS = YesPlease
> NO_SVN_TESTS = YesPlease
> NO_PERL_MAKEMAKER = YesPlease
> + RUNTIME_PREFIX = YesPlease
> NO_POSIX_ONLY_PROGRAMS = YesPlease
> NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
> COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/regex
> -Icompat/fnmatch @@ -775,9 +776,6 @@ ifneq (,$(findstring
> MINGW,$(uname_S)))
> COMPAT_OBJS += compat/mingw.o compat/fnmatch/fnmatch.o
> compat/regex/regex.o compat/winansi.o EXTLIBS += -lws2_32
> X = .exe
> - gitexecdir = ../libexec/git-core
> - template_dir = ../share/git-core/templates/
> - ETC_GITCONFIG = ../etc/gitconfig
> endif
> ifneq (,$(findstring arm,$(uname_M)))
> ARM_SHA1 = YesPlease
This cannot be the complete patch. The part that sets $(prefix) to the empty
string is missing, otherwise the runtime prefix discovery would never
trigger, right? (But see also my comment on [PATCH 1/7].)
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/7] Windows: Add workaround for MSYS' path conversion
From: Johannes Sixt @ 2008-09-21 21:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <1222014278-11071-2-git-send-email-prohaska@zib.de>
On Sonntag, 21. September 2008, Steffen Prohaska wrote:
> MSYS' automatic path conversion causes problems when passing paths as
> defines ('-D' arguments to the compiler). MSYS tries to be smart and
> converts absolute paths to native Windows paths, e.g. if MSYS sees
> "/bin" it converts it to "c:/msysgit/bin". But we want completely
> unmodified paths; e.g. if we set bindir in the Makefile to "/bin", the
> define BINDIR shall expand to "/bin". Conversion to absolute Windows
> path will takes place later, during runtime.
>
> This commit adds a workaround by replacing "/" with its octal
> representation "\057", effectively hiding the path from MSYS' path
> conversion mechanism. MSYS does no longer see the absolute path and
> therefore leaves it alone.
This is disgusting, don't you think so, too?
The reason that you need this patch is because you insist that paths in the
Makefile remain defined as:
bindir = $(prefix)/bin
mandir = $(prefix)/share/man
infodir = $(prefix)/share/info
gitexecdir = $(prefix)/libexec/git-core
etc...
even if RUNTIME_PREFIX is enabled (and you seem to imply that $(prefix) is
empty, but this is not enforced by any patch).
Wouldn't it be quite natural that enabling RUNTIME_PREFIX implies that the
above paths are relative, and, therefore, the Makefile must define them as
bindir = bin
mandir = share/man
infodir = share/info
gitexecdir = libexec/git-core
etc...
because the prefix is ... determined at runtime? Now the paths should not be
mangled anymore.
-- Hannes
^ permalink raw reply
* [PATCH 6/6] gitweb: prevent double slashes in PATH_INFO hrefs
From: Giuseppe Bilotta @ 2008-09-21 20:57 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Lea Wiemann, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1222030663-22540-6-git-send-email-giuseppe.bilotta@gmail.com>
When using PATH_INFO in combination with a rewrite rule that hides the
cgi script name, links to projects and/or actions without projects might
be generated with a double slash.
Fix by removing the trailing slash (if present) from $href before
appending PATH_INFO data.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4a91d07..ebab86b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -675,6 +675,8 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
+ $href =~ s,/$,,;
+
# use PATH_INFO for project name
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
--
1.5.6.5
^ permalink raw reply related
* [PATCH 4/6] gitweb: use_pathinfo creates parent..current paths
From: Giuseppe Bilotta @ 2008-09-21 20:57 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Lea Wiemann, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1222030663-22540-4-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc, unless oldname contains two consecutive dots, since
this would cause ambiguity when parsing the resulting path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 26 +++++++++++++++++++++++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9868bf4..0dd2526 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -682,9 +682,29 @@ sub href (%) {
delete $params{'action'};
}
- # next, we put either hash_base:file_name or hash
+ # next, we put hash_parent_base:/file_parent..hash_base:/file_name, stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'} || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'}) unless $params{'file_parent'} eq $params{'file_name'};
+ delete $params{'hash_parent'} if $params{'hash_parent'} eq git_get_hash_by_path($params{'hash_parent_base'},$params{'file_parent'});
+ delete $params{'file_parent'};
+ } else {
+ delete $params{'hash_parent'} if $params{'hash_parent'} eq $params{'hash_parent_base'};
+ if ($params{'file_name'}) {
+ delete $params{'hash_parent'} if $params{'hash_parent'} eq git_get_hash_by_path($params{'hash_parent_base'},$params{'file_name'});
+ }
+ }
+ $href .= "..";
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
@@ -694,7 +714,7 @@ sub href (%) {
}
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
* [PATCH 5/6] gitweb: remove PATH_INFO from $my_url and $my_uri
From: Giuseppe Bilotta @ 2008-09-21 20:57 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Lea Wiemann, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1222030663-22540-5-git-send-email-giuseppe.bilotta@gmail.com>
This patch (combined with appropriate server configuration) allows usage
of the gitweb CGI script as DirectoryIndex for the server root even when
the pathinfo feature is enabled.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0dd2526..4a91d07 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -26,6 +26,10 @@ our $cgi = new CGI;
our $version = "++GIT_VERSION++";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
+if (my $path_info = $ENV{"PATH_INFO"}) {
+ $my_url =~ s,$path_info$,,;
+ $my_uri =~ s,$path_info$,,;
+}
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
--
1.5.6.5
^ permalink raw reply related
* [PATCH 3/6] gitweb: parse parent..current syntax from pathinfo
From: Giuseppe Bilotta @ 2008-09-21 20:57 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Lea Wiemann, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1222030663-22540-3-git-send-email-giuseppe.bilotta@gmail.com>
This makes it possible to use an URL such as
$project/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
$project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 26 ++++++++++++++++++++++++--
1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 18da484..9868bf4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -553,7 +553,9 @@ sub evaluate_path_info {
$action = undef;
}
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ $path_info =~ /^((.+?)(:(.+))?\.\.)?(.+?)(:(.+))?$/;
+ my ($parentrefname, $parentpathname, $refname, $pathname) = (
+ $2, $4, $5, $7);
if (defined $pathname) {
# we got "project.git/branch:filename" or "project.git/branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
@@ -562,7 +564,11 @@ sub evaluate_path_info {
$action ||= "tree";
$pathname =~ s,/$,,;
} else {
- $action ||= "blob_plain";
+ if ($parentrefname) {
+ $action ||= "blobdiff_plain";
+ } else {
+ $action ||= "blob_plain";
+ }
}
$hash_base ||= validate_refname($refname);
$file_name ||= validate_pathname($pathname);
@@ -573,6 +579,22 @@ sub evaluate_path_info {
$hash ||= validate_refname($refname);
$hash_base ||= validate_refname($refname);
}
+ # the parent part might be missing the pathname, in which case we use the $file_name, if present
+ if (defined $parentrefname) {
+ $hash_parent_base ||= validate_refname($parentrefname);
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $file_parent ||= validate_pathname($parentpathname);
+ } else {
+ $file_parent ||= $file_name
+ }
+ if (defined $file_parent) {
+ $hash_parent ||= git_get_hash_by_path($hash_parent_base, $file_parent);
+ } else {
+ $hash_parent ||= validate_refname($parentrefname);
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCH 2/6] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-09-21 20:57 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Lea Wiemann, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1222030663-22540-2-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, make filenames start with a / (right after the :
that separates them from the hash base). This minimal change allows
relative navigation to work properly when viewing HTML files.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e783d12..18da484 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -664,7 +664,7 @@ sub href (%) {
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($params{'file_name'});
+ $href .= ":/".esc_url($params{'file_name'});
delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
delete $params{'file_name'};
} else {
--
1.5.6.5
^ permalink raw reply related
* [PATCH 1/6] gitweb: action in path with use_pathinfo
From: Giuseppe Bilotta @ 2008-09-21 20:57 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Lea Wiemann, Junio C Hamano,
Giuseppe Bilotta
In-Reply-To: <1222030663-22540-1-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, reduce the number of CGI parameters by embedding
the action in the path. The typicial cgiweb path is thus
$project/$action/$hash_base:$file_name or $project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
except when $project/$branch was used to access a branch whose name
matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 109 ++++++++++++++++++++++++++++++++++------------------
1 files changed, 72 insertions(+), 37 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index da474d0..e783d12 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -488,6 +488,37 @@ if (defined $searchtext) {
$search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
+# dispatch
+my %actions = (
+ "blame" => \&git_blame,
+ "blobdiff" => \&git_blobdiff,
+ "blobdiff_plain" => \&git_blobdiff_plain,
+ "blob" => \&git_blob,
+ "blob_plain" => \&git_blob_plain,
+ "commitdiff" => \&git_commitdiff,
+ "commitdiff_plain" => \&git_commitdiff_plain,
+ "commit" => \&git_commit,
+ "forks" => \&git_forks,
+ "heads" => \&git_heads,
+ "history" => \&git_history,
+ "log" => \&git_log,
+ "rss" => \&git_rss,
+ "atom" => \&git_atom,
+ "search" => \&git_search,
+ "search_help" => \&git_search_help,
+ "shortlog" => \&git_shortlog,
+ "summary" => \&git_summary,
+ "tag" => \&git_tag,
+ "tags" => \&git_tags,
+ "tree" => \&git_tree,
+ "snapshot" => \&git_snapshot,
+ "object" => \&git_object,
+ # those below don't need $project
+ "opml" => \&git_opml,
+ "project_list" => \&git_project_list,
+ "project_index" => \&git_project_index,
+);
+
# now read PATH_INFO and use it as alternative to parameters
sub evaluate_path_info {
return if defined $project;
@@ -512,6 +543,16 @@ sub evaluate_path_info {
# do not change any parameters if an action is given using the query string
return if $action;
$path_info =~ s,^\Q$project\E/*,,;
+
+ # next comes the action
+ $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^\Q$action\E/*,,;
+ } else {
+ $action = undef;
+ }
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
# we got "project.git/branch:filename" or "project.git/branch:dir/"
@@ -525,10 +566,12 @@ sub evaluate_path_info {
}
$hash_base ||= validate_refname($refname);
$file_name ||= validate_pathname($pathname);
+ $hash ||= git_get_hash_by_path($hash_base, $file_name);
} elsif (defined $refname) {
# we got "project.git/branch"
- $action ||= "shortlog";
- $hash ||= validate_refname($refname);
+ $action ||= "shortlog";
+ $hash ||= validate_refname($refname);
+ $hash_base ||= validate_refname($refname);
}
}
evaluate_path_info();
@@ -537,37 +580,6 @@ evaluate_path_info();
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
-# dispatch
-my %actions = (
- "blame" => \&git_blame,
- "blobdiff" => \&git_blobdiff,
- "blobdiff_plain" => \&git_blobdiff_plain,
- "blob" => \&git_blob,
- "blob_plain" => \&git_blob_plain,
- "commitdiff" => \&git_commitdiff,
- "commitdiff_plain" => \&git_commitdiff_plain,
- "commit" => \&git_commit,
- "forks" => \&git_forks,
- "heads" => \&git_heads,
- "history" => \&git_history,
- "log" => \&git_log,
- "rss" => \&git_rss,
- "atom" => \&git_atom,
- "search" => \&git_search,
- "search_help" => \&git_search_help,
- "shortlog" => \&git_shortlog,
- "summary" => \&git_summary,
- "tag" => \&git_tag,
- "tags" => \&git_tags,
- "tree" => \&git_tree,
- "snapshot" => \&git_snapshot,
- "object" => \&git_object,
- # those below don't need $project
- "opml" => \&git_opml,
- "project_list" => \&git_project_list,
- "project_index" => \&git_project_index,
-);
-
if (!defined $action) {
if (defined $hash) {
$action = git_get_type($hash);
@@ -624,8 +636,13 @@ sub href (%) {
if ($params{-replay}) {
while (my ($name, $symbol) = each %mapping) {
if (!exists $params{$name}) {
- # to allow for multivalued params we use arrayref form
- $params{$name} = [ $cgi->param($symbol) ];
+ if ($cgi->param($symbol)) {
+ # to allow for multivalued params we use arrayref form
+ $params{$name} = [ $cgi->param($symbol) ];
+ } else {
+ no strict 'refs';
+ $params{$name} = $$name if $$name;
+ }
}
}
}
@@ -636,10 +653,28 @@ sub href (%) {
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action come next
+ # in the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # next, we put either hash_base:file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":".esc_url($params{'file_name'});
+ delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
+ delete $params{'file_name'};
+ } else {
+ delete $params{'hash'} if $params{'hash'} eq $params{'hash_base'};
+ }
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 0/6] gitweb pathinfo improvements
From: Giuseppe Bilotta @ 2008-09-21 20:57 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Petr Baudis, Lea Wiemann, Junio C Hamano,
Giuseppe Bilotta
This is a resend, with some improvements and a proper cover
letter, of my patchset to extend PATH_INFO support in gitweb.
Hopefully I'm doing it the right way this time :)
The basic idea is to have gitweb support paths in the form of
project/action/parent:/filename..hash:/filename
(modulo missing parameters) and to generate them when use_pathinfo
is enabled.
For backwards compatibility, old-style urls $project/$hash are
still supported (unless $hash is a named ref that happens to
coincide with a gitweb action). Also, CGI parameters are still
used when the path_info form would be ambiguous (e.g. filenames
with two consecutive dots in their name).
Giuseppe Bilotta (6):
gitweb: action in path with use_pathinfo
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from pathinfo
gitweb: use_pathinfo creates parent..current paths
gitweb: remove PATH_INFO from $my_url and $my_uri
gitweb: prevent double slashes in PATH_INFO hrefs
gitweb/gitweb.perl | 161 +++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 122 insertions(+), 39 deletions(-)
^ permalink raw reply
* Re: Problems with git over http
From: Sean Davis @ 2008-09-21 20:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqskrto48n.fsf@bauges.imag.fr>
On Sun, Sep 21, 2008 at 12:25 PM, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> "Sean Davis" <sdavis2@mail.nih.gov> writes:
>
>> I am new to git and trying to set up a remote repository over http. I
>> have configured apache2 and the bare, empty repository. Using curl, I
>> can get the file HEAD without a password (seems .netrc is correct?).
>> However, when I try to push to the repository, I get the following:
>>
>> sdavis@lestrade:/tmp/testing> git push
>> http://sdavis@watson.nci.nih.gov/git/sean_git.git/ master
>> fatal: exec http-push failed.
>
> Do you have git-http-push somewhere? What does "git http-push" say?
>
> Probably you have a version of Git compiled with a too old libcurl
> (IIRC, it could have "worked", but a bug in the old libcurl could
> cause repository corruption, and therefore, git refuses to build
> http-push with such version of libcurl).
That was dumb on my part. That is, indeed, an issue. Both the mac
binary that I found and the rpm for opensuse do not include
git-http-push.
Sean
^ permalink raw reply
* Re: [RFC PATCH] Documentation: add manpage about workflows
From: Dmitry Potapov @ 2008-09-21 20:26 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1221147585-5695-1-git-send-email-trast@student.ethz.ch>
On Thu, Sep 11, 2008 at 05:39:45PM +0200, Thomas Rast wrote:
> This attempts to make a manpage about workflows that is both handy to
> point people at it and as a beginner's introduction.
Thank you for your attempt. It is clearly a missing part of the Git
documentation. I have a few comments to it below.
> +SEPARATE CHANGES
> +----------------
> +
> +As a general rule, you should try to split your changes into small
> +logical steps, and commit each of them. They should be consistent,
> +working independently of any later commits, pass the test suite, etc.
I would rather add some explanation why it is a good idea. Something
like this:
"This makes the review process much easier, as well as, makes git bisect
much more useful in finding the cause of regressions."
> +
> +To achieve this, try to commit your new work at least every couple
> +hours. You can always go back and edit the commits with `git rebase
> +--interactive` to further improve the history before you publish it.
I like the idea of this paragraph but not its wording. Maybe this will
be better (just a variant):
"To achieve this, try to split your work in small steps from the very
beginning. It is always easier to squash a few commits together than
splitting one big commit into a few. Don't be afraid making steps too
small or that they are not perfect yet. You can always go back later and
edit the commits with `git rebase --interactive` before you publish it."
> +
> +MANAGING BRANCHES
> +-----------------
> +
> +In the following, we will assume there are 'developers', 'testers' and
> +'users'. Even if the "Testers" are actually an automated test suite
> +and all "Users" are developers themselves, try to think in these terms
> +as you follow a software change through its life cycle.
> +
> +Usually a change evolves in a few steps:
> +
> +* The developers implement a few iterations until it "seems to work".
> +
> +* The testers play with it, report bugs, test the fixes, eventually
> + clearing the change for stable releases.
Perhaps, the above two points are the most controversial in my opinion.
First, I would expect developers to implement a few iterations until
it (their work) passes the automated test suite and peer review. Only
then their work is merged into 'next' (or into a similar branch, which
constitute that this series is published now).
Second, I am not sure what you meant by testers clears changes for
stable releases, especially after you stated "Testers" may be an
automated test suite. Whether some change is included is always a
conscious decision of the project maintainer. The fact that some change
has passed all tests successfully only clears it for including into
'next'.
> +
> +* As the users work with the new feature, they report bugs which will
> + have to be fixed.
> +
> +In the following sections we discuss some problems that arise from
> +such a "change flow", and how to solve them with Git.
> +
> +We consider a fictional project with (supported) stable branch
> +'maint', main testing/development branch 'master' and "bleeding edge"
> +branch 'next'. We collectively call these three branches 'main
> +branches'.
The idea of 'next' is not obvious from your above explanation. When I
started to learn how Git workflow works, I read something like above
and was very puzzled what is the purpose of having two development
branches: 'master' and 'next'. Only later I realized that it is
necessary to give flexibility in making decisions of what should be
included in the next stable release and what may need more "cooking"
to prove their reliability and usefulness.
> +
> +
> +Merging upwards
> +~~~~~~~~~~~~~~~
> +
> +Since Git is quite good at merges, one should try to use them to
> +propagate changes. For example, if a bug is fixed, you would want to
> +apply the corresponding fix to all main branches.
The first and second sentences are a bit disconnected here. I would
rather write the second one like this: "An example of such a change
can be a bug fix, which should be applied to all main branches."
Another thing is that I am not sure that the provided reason for doing
so ("Git is quite good at merges") is good enough. It can be said that
Git is quite good at cherry-picking too. Yet, we use merge, because it
allows to deal with large number of patches easier. Merge can be easily
visualized and understood as every merge point means that all changes
before it are included. However, to being able use merge, the developer
has to start from the oldest branch that will include this change. This
is a clear restriction over the anarchic nature of cherry-picking (where
you can introduce a change to an arbitrary branch and then cherry-pick
to others), but it pays off in the long run by better maintainability of
the project. Thus the recommended practice is a strong preference to use
merge over cherry-picking. It does not mean that cherry-picking should
be completely excluded. Occasionally, it may be useful.
> +
> +A quick moment of thought reveals that you cannot do this by merging
> +"downwards" to older releases, since that would merge 'all' changes.
IMHO, expressions such as "a quick moment of thought reveals..." is
more suitable for blogs than for serious documentation.
> +Hence the following:
> +
> +.Merge upwards
> +[caption="Rule: "]
> +=====================================
> +Always commit your fixes to the oldest supported branch that require
> +them. Then (periodically) merge the main branches upwards into each
> +other.
> +=====================================
Perhaps, it is worth to note here that a non-trivial fixes can be
implemented as topic branches, which starts from the oldest branch
that needs them.
> +
> +This gives a very controlled flow of fixes. If you notice that you
> +have applied a fix to e.g. 'master' that is also required in 'maint',
> +you will need to cherry-pick it (using linkgit:git-cherry-pick[1])
> +downwards. This will happen a few times and is nothing to worry about
> +unless you do it all the time.
> +
> +
> +Topic branches
> +~~~~~~~~~~~~~~
> +
> +Any nontrivial feature will require several patches to implement, and
> +may get extra bugfixes or improvements during its lifetime. If all
> +such commits were in one long linear history chain (e.g. if they were
> +all committed directly to, 'master'), it becomes very hard to see how
> +they belong together.
There is a far more important reason to use topic branches than ecstatic
pleasure from being able to see related changes grouped together in the
history. The main reason to use topic branches is to facilitate parallel
development. Though the idea that anyone commit to the main development
branch ('master') is very appealing due to its simplicity, it leads to
problems down the road. Namely, not all good sounding ideas turns out
good in reality.
In the workflow where everyone commits to 'master' there are only two
ways to deal with that. The first approach is not let developers to
commit their changes until they have completely finished their work
and passed all tests and code-review, and their work deemed important
enough to be included in the next feature release. The second approach
is to commit their work in progress in the hope that it will succeed,
and if not then to rollback changes.
Neither of these two approaches is satisfactory, especially for large
projects. The first approach means that developers are under a great
stress due to inability to save their work in progress, they accumulate
a huge patch, which is very difficult to review, often include some
other changes unrelated to the stated goal, and makes the history of
the project nearly useless for bisecting (linkgit:git-bisect[1]) when
it comes to finding a regression. The second approach means that the
project history gets contaminating with a great number of changes that
eventually didn't work out. Moreover, reverting changes that are belong
to some failed work may extremely difficult as other changes intervene
with them. So, this reverting is hardly ever done completely in practice
if it is done at all, which leads to a lot of garbage in the source
code. Obviously, the history of this project is completely useless for
bisecting as many commits do not really work if they are compiled at
all. Also, this approach leads to an extremely long stabilization period
as it is determined by the time when slowest going work will be in good
shape for release.
Using topic branches immune to that problem as feature are included
into 'master' when they are ready. Moreover, feature branches unless
they are "publish" can go through cycles of testing, review, and
interactive rebasing to edit and improve individual commits. Thus
the finally published history is clean and easy to bisect.
> +
> +Roughly speaking, there are two important workflows.
I think it would make sense to name them here.
> Their
> +distinguishing mark is whether they can be used to propagate merges.
Perhaps, it would be better to say:
"They are distinguished by the ability to propagate merges."
However, this is not the only distinguish between them. Besides, I am
not sure how this one is connected with the rest of the paragraph:
> +Medium to large projects will typically employ some mixture of the
> +two:
> +
> +* "Upstream" in the most general sense 'pushes' changes to the
> + repositor(ies) holding the main history.
IMHO, it would be better:
s/the main history/the official history of the project/
> Everyone can 'pull' from there to stay up to date.
Would that entrench the wrong idea that one needs to do 'pull'
habitually? And the habitual 'pull' results in habitual 'merge'.
> +
> +* Frequent contributors, subsystem maintainers, etc. may use push/pull
> + to send their changes upstream.
This is nitpicking, but you cannot use 'pull' to send changes. However,
I suppose you meant to make your repository available for other people
to pull from it.
> +
> +* The rest -- typically anyone more than one or two levels away from the
> + main maintainer -- send patches by mail.
After reading "mixture of the two:" above, I expected these two being named,
but instead I can see three points. So, it is confusing.
> +If the maintainer tells you that your patch no longer applies to the
> +current upstream, you will have to rebase your topic (you cannot use a
> +merge because you cannot format-patch merges):
> +
> +.format-patch/am: Keeping topics up to date
> +[caption="Recipe: "]
> +=====================================
> +`git rebase upstream`
> +=====================================
Maybe, git pull --rebase is better advice here as it will also fetch
the latest changes from the upstream.
> +
> +You can then fix the conflicts during the rebase. Presumably you have
> +not published your topic other than by mail, so rebasing it is not a
> +problem.
> +
> +If you receive such a patch (as maintainer, or perhaps reader of the
> +mailing list it was sent to), save the mail to a file and use
> +'git-am':
> +
> +.format-patch/am: Publishing branches/topics
> +[caption="Recipe: "]
> +=====================================
> +`git am < patch`
> +=====================================
> +
> +One feature worth pointing out is the three-way merge, which can help
> +if you get conflicts because of renames:
Could it not be any other reason besides renames? Maybe it is better to
drop "because of renames" here.
> `git am -3` will use index
> +information contained in patches
Because the word "index" is often used in Git in the different meaning
(a.k.a cache), I would re-write this sentence to avoid confusion as:
"`git am -3` will use information contained in index lines of patches"
> to reconstruct a merge base. See
If I did not know how git am -3 works, reading this would make me think
that git am somehow manage to figure out a common ancestor (commit),
while it uses index lines of the patch to learn the identity of the blob
that was used as the starting point to create the patch, and if this
blob is available locally, git am -3 performs 3-way merge.
So, "reconstruct a merge base" is hardly appropriate here.
Dmitry
^ permalink raw reply
* [PATCH 1/2] Add new test to show git archive autocrlf bug
From: Charles Bailey @ 2008-09-21 20:25 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
As the few responses to this patch were only positive last time around
(despite my attempt to confuse things by messing up the threading), I'm
resending for inclusion. I believe that the current behaviour is buggy,
so I hope that this patch is 'maint' worthy.
t/t0024-crlf-archive.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100644 t/t0024-crlf-archive.sh
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
new file mode 100644
index 0000000..3511439
--- /dev/null
+++ b/t/t0024-crlf-archive.sh
@@ -0,0 +1,46 @@
+#!/bin/sh
+
+test_description='respect crlf in git archive'
+
+. ./test-lib.sh
+UNZIP=${UNZIP:-unzip}
+
+test_expect_success setup '
+
+ git config core.autocrlf true
+
+ printf "CRLF line ending\r\nAnd another\r\n" > sample &&
+ git add sample &&
+
+ test_tick &&
+ git commit -m Initial
+
+'
+
+test_expect_success 'tar archive' '
+
+ git archive --format=tar HEAD |
+ ( mkdir untarred && cd untarred && "$TAR" -xf - )
+
+ test_cmp sample untarred/sample
+
+'
+
+"$UNZIP" -v >/dev/null 2>&1
+if [ $? -eq 127 ]; then
+ echo "Skipping ZIP test, because unzip was not found"
+ test_done
+ exit
+fi
+
+test_expect_failure 'zip archive' '
+
+ git archive --format=zip HEAD >test.zip &&
+
+ ( mkdir unzipped && cd unzipped && unzip ../test.zip ) &&
+
+ test_cmp sample unzipped/sample
+
+'
+
+test_done
--
1.6.0.1.309.g4f56
^ permalink raw reply related
* [PATCH 2/2] Make git respect core.autocrlf for zip archives
From: Charles Bailey @ 2008-09-21 20:25 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <1222028727-30097-1-git-send-email-charles@hashpling.org>
There is currently no call to git_config at the start of cmd_archive.
When creating tar archives the core config is read as a side-effect of
reading the tar specific config, but this doesn't happen for zip
archives.
The consequence is that in a configuration with core.autocrlf set,
although files in a tar archive are created with crlf line endings,
files in a zip archive retain unix line endings.
Signed-off-by: Charles Bailey <charles@hashpling.org>
---
builtin-archive.c | 2 ++
t/t0024-crlf-archive.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-archive.c b/builtin-archive.c
index 5ceec43..432ce2a 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -111,6 +111,8 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
{
const char *remote = NULL;
+ git_config(git_default_config, NULL);
+
remote = extract_remote_arg(&argc, argv);
if (remote)
return run_remote_archiver(remote, argc, argv);
diff --git a/t/t0024-crlf-archive.sh b/t/t0024-crlf-archive.sh
index 3511439..e533039 100644
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -33,7 +33,7 @@ if [ $? -eq 127 ]; then
exit
fi
-test_expect_failure 'zip archive' '
+test_expect_success 'zip archive' '
git archive --format=zip HEAD >test.zip &&
--
1.6.0.1.309.g4f56
^ permalink raw reply related
* Re: What's cooking in gitweb (20 Sep 2008)
From: Giuseppe Bilotta @ 2008-09-21 20:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Lea Wiemann
In-Reply-To: <200809210138.01874.jnareb@gmail.com>
Hi Jakub, hi all,
sorry for the late reply, I was out of town and connectionless for two
weeks and I'm getting back on track now.
> 1. "gitweb pathinfo improvements" by Giuseppe Bilotta
> Message-ID: <1220435839-29360-1-git-send-email-giuseppe.bilotta@gmail.com>
> http://$gmane/94779
>
> Table of contents:
> ==================
> * [PATCH 1/5] gitweb: action in path with use_pathinfo
> * [PATCH 2/5] gitweb: use_pathinfo filenames start with /
> * [PATCH 3/5] gitweb: parse parent..current syntax from pathinfo
> * [PATCH 4/5] gitweb: use_pathinfo creates parent..current paths
> * [PATCH 5/5] gitweb: remove PATH_INFO from $my_url and $my_uri
>
> Need some refinement, especially with respect to _generating_
> path_info URLs inside gitweb. Some patches (2 and 5) does not
> need correction, and probably should be sent as separate series.
> Author promised to resend series, if I remember correctly.
I'll resend the whole series (plus an additional patch to fix an
aesthetical issue I found recently) as soon as I fix the url
generation for the dotted filename corner case (which by re-reading
the past emails seemed to be the only significant issue, correct?).
Should be shortly
> 2. "[PATCH] gitweb: shortlog now also obeys $hash_parent" by Giuseppe Bilotta
> Message-ID: <1218204731-9931-1-git-send-email-giuseppe.bilotta@gmail.com>
> http://$gmane/91666
>
> Very good idea, but for the following two caveats. The name
> '$commit_hash' is a bit strange to mean also revision range; passing
> "a..b" to parse_commits()... well, it is a good solution, but for me it
> feels a bit hacky. But this is not something serious.
>
> More importnat fact is that I'd very much like for _all_ log-like views
> (perhaps with exception of feeds: Atom and RSS) to implement this
> feature. This could be done by either doing it all in the same commit,
> doing commit series changing 'shortlog', 'log' and 'history' separately,
> or what I would prefer actually, to refactor generation of log-like views
> to use single worker/engine subroutine.
I agree that refactoring is probably the best idea. It will also take
me some more time ;)
BTW, I haven't heard from Lea, so can I just assume that my patches
don't touch any of her caching improvements?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [StGit PATCH 2/2] Test the new stg delete --spill flag
From: Karl Hasselström @ 2008-09-21 19:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080921190708.4503.20574.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
t/t1602-delete-spill.sh | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100755 t/t1602-delete-spill.sh
diff --git a/t/t1602-delete-spill.sh b/t/t1602-delete-spill.sh
new file mode 100755
index 0000000..1ddec53
--- /dev/null
+++ b/t/t1602-delete-spill.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+test_description='Test "stg delete --spill"'
+. ./test-lib.sh
+
+test_expect_success 'Initialize the StGIT repository' '
+ stg init
+'
+
+test_expect_success 'Create five applied and three unapplied patches' '
+ for i in 0 1 2 3 4 5 6 7; do
+ echo $i >> foo &&
+ git add foo &&
+ git commit -m p$i
+ done
+ stg uncommit -n 8 &&
+ stg pop -n 3
+'
+
+test_expect_success 'Try to delete --spill an unapplied patch' '
+ command_error stg delete --spill p7 &&
+ test "$(echo $(stg series))" = "+ p0 + p1 + p2 + p3 > p4 - p5 - p6 - p7" &&
+ test "$(echo $(cat foo))" = "0 1 2 3 4" &&
+ test "$(echo $(git diff-files))" = ""
+'
+
+test_expect_success 'Try to delete --spill a non-top patch' '
+ command_error stg delete --spill p2 &&
+ test "$(echo $(stg series))" = "+ p0 + p1 + p2 + p3 > p4 - p5 - p6 - p7" &&
+ test "$(echo $(cat foo))" = "0 1 2 3 4" &&
+ test "$(echo $(git diff-files))" = ""
+'
+
+test_expect_success 'Delete --spill one patch' '
+ stg delete --spill p4 &&
+ test "$(echo $(stg series))" = "+ p0 + p1 + p2 > p3 - p5 - p6 - p7" &&
+ test "$(echo $(cat foo))" = "0 1 2 3 4" &&
+ test "$(echo $(git diff-files))" = ""
+'
+
+test_expect_success 'Delete --spill several patches' '
+ stg delete --spill p2 p3 p1 &&
+ test "$(echo $(stg series))" = "> p0 - p5 - p6 - p7" &&
+ test "$(echo $(cat foo))" = "0 1 2 3 4" &&
+ test "$(echo $(git diff-files))" = ""
+'
+
+test_done
^ permalink raw reply related
* [StGit PATCH 1/2] Add a new flag, --spill, to stg delete
From: Karl Hasselström @ 2008-09-21 19:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20080921190708.4503.20574.stgit@yoghurt>
It deletes the patches as usual, but doesn't touch index+worktree.
Useful for splitting up a patch, or undoing an "stg refresh".
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/delete.py | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/stgit/commands/delete.py b/stgit/commands/delete.py
index 1b59cdd..015fb49 100644
--- a/stgit/commands/delete.py
+++ b/stgit/commands/delete.py
@@ -30,6 +30,13 @@ Delete the patches passed as arguments."""
args = [argparse.patch_range(argparse.applied_patches,
argparse.unapplied_patches)]
options = [
+ opt('--spill', action = 'store_true',
+ short = 'Spill patch contents to worktree and index', long = """
+ Delete the patches, but do not touch the index and worktree.
+ This only works with applied patches at the top of the stack.
+ The effect is to "spill" the patch contents into the index and
+ worktree. This can be useful e.g. if you want to split a patch
+ into several smaller pieces."""),
opt('-b', '--branch', args = [argparse.stg_branches],
short = 'Use BRANCH instead of the default branch')]
@@ -46,6 +53,12 @@ def func(parser, options, args):
patches = set(common.parse_patches(args, list(stack.patchorder.all)))
else:
parser.error('No patches specified')
+
+ if options.spill:
+ if set(stack.patchorder.applied[-len(patches):]) != patches:
+ parser.error('Can only spill topmost applied patches')
+ iw = None # don't touch index+worktree
+
def allow_conflicts(trans):
# Allow conflicts if the topmost patch stays the same.
if stack.patchorder.applied:
^ 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