* [PATCH 2/3] packed_git: add new PACK_KEEP flag and haspackkeep() access macro
From: drafnel @ 2008-11-02 16:31 UTC (permalink / raw)
To: git; +Cc: gitster, nico, spearce, Brandon Casey
In-Reply-To: <1225643477-32319-1-git-send-email-foo@foo.com>
From: Brandon Casey <drafnel@gmail.com>
If you want to tell whether a pack has an associated ".keep" file you
would do:
if (haspackkeep(p))
do_something
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
cache.h | 2 ++
sha1_file.c | 5 +++++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 0cb9350..48cd366 100644
--- a/cache.h
+++ b/cache.h
@@ -686,7 +686,9 @@ extern struct packed_git {
} *packed_git;
#define PACK_LOCAL 1
+#define PACK_KEEP 2
#define ispacklocal(p) ((p)->flags & PACK_LOCAL)
+#define haspackkeep(p) ((p)->flags & PACK_KEEP)
struct pack_entry {
off_t offset;
diff --git a/sha1_file.c b/sha1_file.c
index e4141c9..8a027e9 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -841,6 +841,11 @@ struct packed_git *add_packed_git(const char *path, int path_len, int local)
return NULL;
}
memcpy(p->pack_name, path, path_len);
+
+ strcpy(p->pack_name + path_len, ".keep");
+ if (!access(p->pack_name, F_OK))
+ p->flags |= PACK_KEEP;
+
strcpy(p->pack_name + path_len, ".pack");
if (stat(p->pack_name, &st) || !S_ISREG(st.st_mode)) {
free(p);
--
1.6.0.2.588.g3102
^ permalink raw reply related
* [PATCH 1/3] packed_git: convert pack_local flag into generic bit mask
From: drafnel @ 2008-11-02 16:31 UTC (permalink / raw)
To: git; +Cc: gitster, nico, spearce, Brandon Casey
In-Reply-To: <14536526.1225596838300.JavaMail.teamon@b301.teamon.com>
From: Brandon Casey <drafnel@gmail.com>
This converts the pack_local flag of the packed_git structure into a generic
bit mask and introduces a PACK_LOCAL mask and an ispacklocal() access macro.
So instead of this:
if (p->pack_local)
do_something
you would do this:
if (ispacklocal(p))
do_something
This is in preparation for adding a flag indicating whether a .keep file is
present.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
builtin-count-objects.c | 2 +-
builtin-gc.c | 2 +-
builtin-pack-objects.c | 2 +-
cache.h | 5 ++++-
pack-redundant.c | 4 ++--
server-info.c | 4 ++--
sha1_file.c | 5 +++--
7 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index ab35b65..3f981d6 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -108,7 +108,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
if (!packed_git)
prepare_packed_git();
for (p = packed_git; p; p = p->next) {
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
if (open_pack_index(p))
continue;
diff --git a/builtin-gc.c b/builtin-gc.c
index 7af65bb..0473158 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -135,7 +135,7 @@ static int too_many_packs(void)
size_t len;
int keep;
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
len = strlen(p->pack_name);
if (PATH_MAX <= len + 1)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 59c30d1..6a8b9bf 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -701,7 +701,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
break;
if (incremental)
return 0;
- if (local && !p->pack_local)
+ if (local && !ispacklocal(p))
return 0;
}
}
diff --git a/cache.h b/cache.h
index b0edbf9..0cb9350 100644
--- a/cache.h
+++ b/cache.h
@@ -679,12 +679,15 @@ extern struct packed_git {
int index_version;
time_t mtime;
int pack_fd;
- int pack_local;
+ unsigned int flags;
unsigned char sha1[20];
/* something like ".git/objects/pack/xxxxx.pack" */
char pack_name[FLEX_ARRAY]; /* more */
} *packed_git;
+#define PACK_LOCAL 1
+#define ispacklocal(p) ((p)->flags & PACK_LOCAL)
+
struct pack_entry {
off_t offset;
unsigned char sha1[20];
diff --git a/pack-redundant.c b/pack-redundant.c
index 25b81a4..964f18f 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -544,7 +544,7 @@ static struct pack_list * add_pack(struct packed_git *p)
unsigned long off = 0, step;
const unsigned char *base;
- if (!p->pack_local && !(alt_odb || verbose))
+ if (!ispacklocal(p) && !(alt_odb || verbose))
return NULL;
l.pack = p;
@@ -562,7 +562,7 @@ static struct pack_list * add_pack(struct packed_git *p)
}
/* this list will be pruned in cmp_two_packs later */
l.unique_objects = llist_copy(l.all_objects);
- if (p->pack_local)
+ if (ispacklocal(p))
return pack_list_insert(&local_packs, &l);
else
return pack_list_insert(&altodb_packs, &l);
diff --git a/server-info.c b/server-info.c
index c1c073b..2eb20f5 100644
--- a/server-info.c
+++ b/server-info.c
@@ -168,14 +168,14 @@ static void init_pack_info(const char *infofile, int force)
/* we ignore things on alternate path since they are
* not available to the pullers in general.
*/
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
i++;
}
num_pack = i;
info = xcalloc(num_pack, sizeof(struct pack_info *));
for (i = 0, p = packed_git; p; p = p->next) {
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
info[i] = xcalloc(1, sizeof(struct pack_info));
info[i]->p = p;
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..e4141c9 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -851,7 +851,8 @@ struct packed_git *add_packed_git(const char *path, int path_len, int local)
* actually mapping the pack file.
*/
p->pack_size = st.st_size;
- p->pack_local = local;
+ if (local)
+ p->flags |= PACK_LOCAL;
p->mtime = st.st_mtime;
if (path_len < 40 || get_sha1_hex(path + path_len - 40, p->sha1))
hashclr(p->sha1);
@@ -941,7 +942,7 @@ static int sort_pack(const void *a_, const void *b_)
* remote ones could be on a network mounted filesystem.
* Favor local ones for these reasons.
*/
- st = a->pack_local - b->pack_local;
+ st = ispacklocal(a) - ispacklocal(b);
if (st)
return -st;
--
1.6.0.2.588.g3102
^ permalink raw reply related
* Re: [PATCH] prepare deprecation of git-revert
From: Johannes Schindelin @ 2008-11-02 16:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Alex Riesen, Pierre Habouzit, git
In-Reply-To: <20081102093225.GA32296@laptop>
Hi,
On Sun, 2 Nov 2008, Nguyen Thai Ngoc Duy wrote:
> Add git command expansion
>
> This allows git commands to be typed shorter (in shells that do not
> support autocompletion). There are three types of expansion:
>
> - "foo" matches "foo*" commands (bi -> bisect)
> - "foo" also matches "f*-oo*" (fim -> fast-import)
> - "foo-bar" (with dash) matches "foo*-bar*" (fo-p -> format-patch)
I'd rather have the soft-alias code back to perform this expansion, but
only for a limited and explicit set of abbreviations.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Johannes Schindelin @ 2008-11-02 16:05 UTC (permalink / raw)
To: Alex Riesen
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <20081102143751.GA18140@blimp.localdomain>
Hi,
On Sun, 2 Nov 2008, Alex Riesen wrote:
> Johannes Schindelin, Sat, Nov 01, 2008 21:37:14 +0100:
> > On Sat, 1 Nov 2008, Alex Riesen wrote:
> > > Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> > > >
> > > > P.S.: some guys at the GSoC mentor summit convinced me in at least
> > > > trying to fix _their_ problems on msysGit, so chances are good
> > > > I'll fix issues you would encounter in the same run.
> > >
> > > Do you still plan to distribute MinGW with it? It's very nice to be
> > > able to track Junio's repo, have own branches and rebuild Git from
> > > time to time. For me, at least.
> >
> > You mean to distribute a minimal MSys environment where you have bash?
> > Yes, we have to do that, as there are still too many important parts
> > of Git written in Shell.
>
> No, the mingw compiler and libraries. I vaguely remember some talking
> about including the build environment into Git distribution.
We do that already for a long time. Basically, we have two distributions:
Git for Windows (for the end user) and msysGit (for the developer wanting
to work _on_ Git). Actually, msysGit was there first.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] add instructions on how to send patches to the mailing list with Gmail
From: Fredrik Skolmli @ 2008-11-02 15:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Tom Preston-Werner, Santi Béjar, git, Junio C Hamano
In-Reply-To: <20081102091006.GA4066@artemis>
On Sun, Nov 02, 2008 at 10:10:06AM +0100, Pierre Habouzit wrote:
> > > Warning: It is not secure.
> >
> > It is true that the certificate is not verified, but since the patches
> > are destined for a public mailing list, this does not represent a
> > large problem.
>
> What he means is that the password is cleartext ;)
> (I think)
The way I read and understand it, the issues arises if a MITM-attack takes
place. If the client doesn't verify the certificate, an attacker can easily
get the username and password.
So unless someone creates a separate gmail-account for submitting patches,
one should really trust the connection (ie not a public wlan), or verify the
certificate before transmitting the password.
--
Kind regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-11-02 14:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <alpine.DEB.1.00.0811012134290.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin, Sat, Nov 01, 2008 21:37:14 +0100:
> On Sat, 1 Nov 2008, Alex Riesen wrote:
> > Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> > >
> > > Well, if you install Git for Windows (as opposed to cygwin), it is
> > > minimum hassle, and Perl is delivered right with it.
> >
> > I'd like to try it again, but weren't ther some fatal problems with
> > cygwin1.dll being in PATH? I always work either in Cygwin's bash or just
> > have to have it in PATH, because of the build environment even being
> > strictly Windows based (case-insensitive and alike) just have to use
> > sane tooling in its scripts.
>
> I was talking about Git for Windows, i.e. the result of msysGit (as
> opposed to Git in Cygwin).
>
> So no, there have not been any conflicts with cygwin1.dll in the PATH, as
> far as I can recall. There have been problems with shell utilities being
> found in the Cygwin PATH before being found in the MSys PATH, but I
> thought we just prepended the MSys PATH to avoid that. Haven't checked,
> though.
Ok, I'll give it a try.
> > > P.S.: some guys at the GSoC mentor summit convinced me in at least
> > > trying to fix _their_ problems on msysGit, so chances are good I'll
> > > fix issues you would encounter in the same run.
> >
> > Do you still plan to distribute MinGW with it? It's very nice to be able
> > to track Junio's repo, have own branches and rebuild Git from time to
> > time. For me, at least.
>
> You mean to distribute a minimal MSys environment where you have bash?
> Yes, we have to do that, as there are still too many important parts of
> Git written in Shell.
No, the mingw compiler and libraries. I vaguely remember some talking
about including the build environment into Git distribution.
^ permalink raw reply
* RE: why not TortoiseGit
From: Li Frank @ 2008-11-02 14:14 UTC (permalink / raw)
To: Scott Chacon, Andreas Ericsson; +Cc: Ian Hilt, git
In-Reply-To: <d411cc4a0810310857y5b4f8c46ue33e1f6a9e2c13d1@mail.gmail.com>
I read some code of TortoiseSVN and TortoiseHg Code.
At beginning, TortoiseGit can git command to get information like Qgit.
After linkable library ready, replace "git command".
I think TortoiseGit can start base on below way.
1. Base on TortoiseHg, It is python Script. Replace below hg operator
with Git.
2. Base on TortoiseSVN, It is developed with C++. Need VS2008.
ToritoiseSVN provide some built in diff and merge tools.
3. Base on Qgit, which provide some basic UI, such comment dialogbox,
history view and file annotate.
Best regards
Frank Li
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Scott Chacon
Sent: Friday, October 31, 2008 11:58 PM
To: Andreas Ericsson
Cc: Ian Hilt; Li Frank-B20596; git@vger.kernel.org
Subject: Re: why not TortoiseGit
I'm trying to get this restarted - dscho and I talked about this at the
GitTogether, and I met some people (from the OpenAFS project that also
happened to be there, oddly) who were interested in working on this with
me. I think the lack of a linkable library has greatly hindered the
development of projects like this, so that will likely be part of the
development process as well.
Scott
On Fri, Oct 31, 2008 at 5:35 AM, Andreas Ericsson <ae@op5.se> wrote:
> Ian Hilt wrote:
>>
>> On Fri, Oct 31, 2008 at 09:44:45AM +0800, Li Frank-B20596 wrote:
>>>
>>> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg Why not
>>> ToroiseGit
>>
>> This is what Johannes Schindelin had to say,
>>
>> <http://code.google.com/p/msysgit/wiki/GitCheetah>
>
> Noone's written TortoiseGit yet. I have no idea why, and I have no
> reason to write it myself. If GitCheetah isn't working well, I'm sure
> patches are welcome.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
> --
> To unsubscribe from this list: send the line "unsubscribe git" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe git" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: commit takes 8 secs; but instant when offline - can I fix this?
From: Thomas Rast @ 2008-11-02 14:13 UTC (permalink / raw)
To: 13ren; +Cc: git
In-Reply-To: <1225634894605-1445352.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
13ren wrote:
> With the network plugged in, git-commit takes 8 seconds.
>
> When I unplug the network, commit is instant...
Configure your user.email (and user.name), see man git-config. If the
email is not set, Git tries to figure out your hostname, which
depending on DNS misconfigurations can apparently cause such delays.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* commit takes 8 secs; but instant when offline - can I fix this?
From: 13ren @ 2008-11-02 14:08 UTC (permalink / raw)
To: git
Hi all,
With the network plugged in, git-commit takes 8 seconds.
When I unplug the network, commit is instant...
I confirmed this with a fresh test directory, just adding an extra line to
the file "test" for each commit:
> git init
Initialized empty Git repository in /home/user/gitexpt/.git/
> vi test
> git add *
> date; git commit -a -m "add minor change"; date
Mon Nov 3 00:31:02 EST 2008
Created commit 9b845a2: add minor change
1 files changed, 2 insertions(+), 0 deletions(-)
Mon Nov 3 00:31:10 EST 2008
> date; git commit -a -m "add test, without network"; date
Mon Nov 3 00:46:00 EST 2008
Created commit dd02a69: add test, without network
1 files changed, 3 insertions(+), 0 deletions(-)
Mon Nov 3 00:46:00 EST 2008
> git --version
git version 1.5.6.3
Anyone know why is git-commit so slow? Or if there I can anything to change
this?
I'd assumed the slowness was normal, since I'm new to version control. I've
googled and searched mailing lists, but haven't found this. Could be just my
installation (or others make the same assumption?)
Many thanks for any help... I'm going a little crazy here.
--
View this message in context: http://n2.nabble.com/commit-takes-8-secs--but-instant-when-offline---can-I-fix-this--tp1445352p1445352.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Encoding problems using git-svn
From: Robin Rosenberg @ 2008-11-02 13:45 UTC (permalink / raw)
To: Eric Wong; +Cc: James North, Junio C Hamano, git
In-Reply-To: <20081102094845.GB16003@untitled>
On söndag 02 november 2008 10:48 Eric Wong wrote:
> James North <tocapicha@gmail.com> wrote:
> > Hi Eric,
> >
> > Don't worry about not seeing the patch and thanks for the answer :)
> >
> > Your patch works great.
> >
> > Messages appear without problems on "svn log" and "git log", I haven't
> > found any gotcha that I know of.
>
> Thanks for the confirmation.
>
> > The weird thing is that this problem was not found by anyone before, I
> > guessed there should be some people with a setup similar to mine.
>
> Squeaky wheel gets the grease :)
>
> Honestly, I think most folks have just moved onto UTF-8 entirely and
> left legacy encodings behind. Especially people using modern tools like
> git (along with SVN enforcing UTF-8 at the repository/protocol level).
"Most" people don't have a legacy encoding problem, but some of us do and
tools that help with migration by enforcing UTF-8 internally help. SVN is such
an example, though not very helpful as an SCM. That way we can still use
legacy encodings for old stupid tools until we can move to an all UTF-8 world.
We're not there yet, but in a few years hopefully. That's when it's sad that
the git command line for example still enforce the legacy encoding. Some
GUI's, like git gui, jgit and probably a few others help by recoding when
necessary.
-- robiin
^ permalink raw reply
* [PATCH v2] Add reference for status letters in documentation.
From: Yann Dirson @ 2008-11-02 13:37 UTC (permalink / raw)
To: git
Also fix error in diff_filepair::status documentation, and point to
the in-code reference as well as the doc.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
Since diffcore.h is for devs anyway, it is IMHO a good idea to let it
also point to the in-code doc.
Documentation/diff-format.txt | 16 ++++++++++++++++
diffcore.h | 2 +-
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 400cbb3..aafd3a3 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -46,6 +46,22 @@ That is, from the left to the right:
. path for "dst"; only exists for C or R.
. an LF or a NUL when '-z' option is used, to terminate the record.
+Possible status letters are:
+
+- A: addition of a file
+- C: copy of a file into a new one
+- D: deletion of a file
+- M: modification of the contents or mode of a file
+- R: renaming of a file
+- T: change in the type of the file
+- U: file is unmerged (you must complete the merge before it can
+be committed)
+- X: "unknown" change type (most probably a bug, please report it)
+
+Status letters C and M are always followed by a score (denoting the
+percentage of similarity between the source and target of the move or
+copy), and are the only ones to be so.
+
<sha1> is shown as all 0's if a file is new on the filesystem
and it is out of sync with the index.
diff --git a/diffcore.h b/diffcore.h
index 713cca7..5b63458 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -62,7 +62,7 @@ struct diff_filepair {
struct diff_filespec *one;
struct diff_filespec *two;
unsigned short int score;
- char status; /* M C R N D U (see Documentation/diff-format.txt) */
+ char status; /* M C R A D U etc. (see Documentation/diff-format.txt or DIFF_STATUS_* in diff.h) */
unsigned broken_pair : 1;
unsigned renamed_pair : 1;
unsigned is_unmerged : 1;
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Björn Steinbrink @ 2008-11-02 12:35 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, David Symonds, git, gitster, Stephan Beyer
In-Reply-To: <20081029171122.GA12167@sigill.intra.peff.net>
On 2008.10.29 13:11:22 -0400, Jeff King wrote:
> On Wed, Oct 29, 2008 at 06:06:09PM +0100, Johannes Schindelin wrote:
>
> > However, note that we have to hash out what to do about the convention
> > that --cached traditionally means that only the staging area (formerly
> > known as "the index") is affected, while --index means that the command
> > touches the working directory, too.
>
> If we assume that we have only the word "stage" and variations
> available, then there aren't too many options.
>
> only the staging area:
> --stage-only, --staged-only
>
> both:
> --staged (as opposed to --staged-only) --stage-and-worktree (too
> long), --both (not descriptive enough), --stage-too (yuck)
Hm, I don't think that would work out nicely with stash. --keep-index
would become --keep-staged-only, which is IMHO pretty confusing, as the
default is to keep nothing. And even if you add another option to keep
all changes, so that the current state is just put onto the stash, but
the working tree and index are unchanged, you would have --keep-staged
and --keep-staged-only. Not really any better.
Admittedly, --keep-index is quite different from --index, but if you're
going to change the CLI to hide the word "index", that option needs to
be changed as well and the usage of the new terms should be unified.
Looking at --cached/--index we have basically three things:
--cached to refer to the state of the index (diff, grep, [stash], ...)
--cached to _work on_ the index only (rm, apply, ...)
--index to _work on_ both the index and the working tree (apply, ...)
Maybe that could be translated to:
--staged: refer to the state of the index
--stage: in addition to changing the working tree, also stage the changes
--stage-only: only stage the changes, don't change the working tree
That would give us, for example:
git diff --staged
git grep --staged
git apply --stage
git apply --stage-only
git rm --stage-only
git stash --keep-staged
A quick look through Documentation/ revealed only one problematic case,
which is ls-files that already has a --stage option. And that looks like
a dealbreaker :-(
Björn
^ permalink raw reply
* Re: [RFC/PATCH 1/2] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-02 11:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0811020515370.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Hi,
Le dimanche 2 novembre 2008, Johannes Schindelin a écrit :
> Hi,
>
> On Sun, 2 Nov 2008, Christian Couder wrote:
> > This new subcommand should be used when you have a branch or a part of
> > a branch that isn't easily bisectable because at some point, say A, a
> > bug as been introduced. The bug has been fixed latter at another point,
> > say B, but between these points the code is not easily testable because
> > of the bug, so it's not easy to bisect between these points.
>
> Would it not be more intuitive to have support for
>
> git bisect skip A..B
>
> ?
We can have both. "bisect skip" is about not being able or wanting to test
some commits and "bisect replace" is about testing using fixed up branches
(that you can share with others) instead of branches that you can't test.
When working on big projects where many people are often bisecting (like the
Linux kernel), then having shared "bisect-replace" branches (and tags)
might save a lot of time to all people bisecting, as they will not have to
often skip the same commits or maintain sets of patches to apply when
bisecting.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Theodore Tso @ 2008-11-02 10:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Sam Vilain, git, Sam Vilain
In-Reply-To: <7v1vxu4q49.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 01, 2008 at 11:08:06PM -0700, Junio C Hamano wrote:
> > (And I get annoyed when I want to run git format-patch on a single
> > patch not at the tip of the tree; but if it's just me, I can write a
> > "git format-single-patch" wrapper script to get around it.)
>
> Huh? I am so used to "git format-patch -1 HEAD" (or "332d2e78") that I am
> very surprised.
Well, the explanation is that "-<n>" isn't in the SYNPOSIS section of
'git format-patch', and so I never knew you could do it that way. A
new user of git has to paw through approximately 50 options in the
OPTIONS section of the man page before finding "-<n>"; and somehow
I've always missed it. I'd suggest adding an explicit mention of -<n>
to the DESCRIPTION section, perhaps in the paragraph:
A single commit, when interpreted as a <revision range> expression,
means "everything that leads to that commit", but if you write git
format-patch <commit>, the previous rule applies to that command
line and you do not get "everything since the beginning of the
time". If you want to format everything since project inception to
one commit, say "git format-patch --root <commit>" to make it clear
that it is the latter case.
Adding the sentence:
If you want to format a single commit, you can do this via
"git format-patch -1 <commit>" or the more esoteric and perl-ish,
"git format-patch <commit>^!"
might be helpful.
- Ted
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Theodore Tso @ 2008-11-02 9:56 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081102041832.GB5261@coredump.intra.peff.net>
On Sun, Nov 02, 2008 at 12:18:33AM -0400, Jeff King wrote:
>
> Yeah, revert-files is pretty painful to type. And I'm not looking
> forward to fielding UI questions about "why isn't it just revert?" :)
>
At least for me, I don't use it *that* often, so it's not that painful
for me (I have it as an "git revert-file" as an alias already).
And the answer, "because 'git revert' used to do something else" is I
think a perfectly reasonable answer. I probably do "git revert-files"
about 3-5 times more often than I do "git revert", so it's a bit
strange from a character count perspective, but history is history.
> Somebody suggested "clobber", which I think is a bit _too_ intense.
>
> I guess something like "retrieve" is too ambiguous. You really need
> something that implies movement of content, and something that implies
> the working directory. "Checkout" is actually not a bad name; if only we
> had "git switch" instead of "git checkout" for switching branches, it
> would be perfect.
If people really want a shorter name, how about bk's "unedit"? I'd
still worry about people being able to find it, since the reality is
that most of the world knows this command as revert, though.
- Ted
^ permalink raw reply
* Re: [PATCH 3/3] git send-email: add --annotate option
From: Pierre Habouzit @ 2008-11-02 9:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskqa3atg.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]
On Sun, Nov 02, 2008 at 06:23:55AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > This allows to review every patch (and fix various aspects of them, or
> > comment them) in an editor just before being sent. Combined to the fact
> > that git send-email can now process revision lists, this makes git
> > send-email and efficient way to review and send patches interactively.
>
> Without your patches, you run format-patch (with or without cover), you
> use the editor of your choice to massage them and feed the resulting files
> to send-email.
>
> Only because you wanted to allow format-patch parameters to be given to
> send-email, you now need to also allow the messages to be massaged before
> they are sent out.
>
> Is it only me who finds that this series creates its own problem and then
> has to solve it? What are we getting in return?
Actually my problem is that the current workflow is:
$ git format-patch [rev-list]
$ vim *.patch
# massage patches
$ git send-email [argument list too long to copy] --compose *.patch
# struggle in vim to reopen the patches I'm about to comment to copy
# the Subject lines and other similar stuff
# answer to a lot of silly questions that git-s-e should guess from
# the cover.
*also* I often have other patches in my repository, and this send-email
sometimes globs _too many_ patches and this is a big problem for me.
Basically that and all the '#' bits, and the number of commands to type
are what make me dislike git-send-email (but still use it since there
are no good alternatives yet that automate the task).
With my patch series, the workflow is as follows:
$ git send-email --to <where> --annotate [rev-list]
# as vim can open many files at once, I have the cover opened _and_
# all the patches at once, or only the patch if there's one single
# patch I can massage everything I want.
# answer 'y' to the _single_ question git-s-e asks.
# or 'n' if something doesn't fly.
Not only the command line is considerably shorter (even the --to can be
omited actually, but unlike --in-reply-to, it rarely changes and it's in
the history so...), but more importantly I can see what I will send, no
more '*.patch' that will bite me hard. I don't have to struggle opening
all the patches I'm interested in reading while I comment them in the
cover, and so on.
I mean you're mistaken when you say:
] Only because you wanted to allow format-patch parameters to be
] given to send-email, you now need to also allow the messages to be
] massaged before they are sent out.
Your causality is backwards. I _DO_ want git-send-email to allow me to
do the cover _and_ the massaging at once. It's actually the first patch
I wrote locally even if I reordered the series before sending for some
reason I don't remember. *Then* if you do that, there's little point in
having to perform git-format-patch in the first place, hence I wanted
the feature to let git-format-patch be run by git-send-email directly.
I don't know for others, but with those series, git-send-email is
_REALLY_ what I would have wanted it to be from day 1. The sole little
issues I can see are:
* the To:/Cc:/Bcc:/other headers parsing directly from the cover, for
that someone better skilled than me shall add a last patch to do that
properly.
* when you only edit one single patch, it doesn't do the From/To/Cc/...
parsing and you'll get all the silly interactive questions again.
That should probably addressed, but to be frank I care about this one
less, because I send single patches directly from mutt. So it's not
really my itch to scratch[0] ;)
[0] WHO SAID I'M LAZY ? Yeah you in the back, I HEAR YA!
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Encoding problems using git-svn
From: Eric Wong @ 2008-11-02 9:48 UTC (permalink / raw)
To: James North, Junio C Hamano; +Cc: git
In-Reply-To: <8b168cfb0810300814i53a264c2x997543e145d5e15a@mail.gmail.com>
James North <tocapicha@gmail.com> wrote:
> Hi Eric,
>
> Don't worry about not seeing the patch and thanks for the answer :)
>
> Your patch works great.
>
> Messages appear without problems on "svn log" and "git log", I haven't
> found any gotcha that I know of.
Thanks for the confirmation.
> The weird thing is that this problem was not found by anyone before, I
> guessed there should be some people with a setup similar to mine.
Squeaky wheel gets the grease :)
Honestly, I think most folks have just moved onto UTF-8 entirely and
left legacy encodings behind. Especially people using modern tools like
git (along with SVN enforcing UTF-8 at the repository/protocol level).
Junio:
I've pushed the following out to git://git.bogomips.org/git-svn.git:
Eric Wong (2):
git-svn: don't escape tilde ('~') for http(s) URLs
git-svn: respect i18n.commitencoding config
I'll try to get around to the more robust escaping checks
and splitting out the monolithic git-svn.perl source next
week.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Pierre Habouzit @ 2008-11-02 9:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081102043523.GE5261@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]
On Sun, Nov 02, 2008 at 04:35:23AM +0000, Jeff King wrote:
> On Fri, Oct 31, 2008 at 05:52:05PM +0100, Pierre Habouzit wrote:
>
> > Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> > ---
> >
> > One can consider to squash that on top of
> > <1225450632-7230-3-git-send-email-madcoder@debian.org> to be able to pass
> > all non path arguments before a possible '--' to git format-patch.
>
> Personally, I think the other patch is not useful without this. I often
> pull out funny subsets of patches if I know it is safe to do so (e.g., I
> collect small, unrelated bugfixes directly onto a single branch, but I
> send them separately).
>
> With this patch, I might even find send-email usable. :)
Well it still messes the file/reference name conflict with no way to
prevent it because of the backward compatibility, and even if unlikely
it's still possible.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn: change dashed git-commit-tree to git commit-tree
From: Eric Wong @ 2008-11-02 9:38 UTC (permalink / raw)
To: Deskin Miller; +Cc: git, gitster
In-Reply-To: <20081031041025.GB20322@euler>
Deskin Miller <deskinm@umich.edu> wrote:
> Signed-off-by: Deskin Miller <deskinm@umich.edu>
> ---
> Once again I'm using a copy of git-svn.perl directly, and this fails to exec.
> I looked at it more closely and it fails because git binary calls setup_path,
> which puts the libexec path into $PATH; of course, this doesn't happen when
> git-svn is called directly.
Thanks Deskin, looks like Junio already picked it up; but if we had
git-notes I'd add my Signed-off-by there :)
Also, on the subject of using git-svn.perl directly from the source
tree, it may become less usable that way in the near future:
Most of us (myself included) at GitTogether seemed like the idea of
splitting git-svn.perl into multiple files for maintainability reasons.
I just haven't gotten around to doing it yet.
OTOH, Git.pm is already required (but likely also installed in your
normal load paths); so you may just have to remember to use perl -I
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Pierre Habouzit @ 2008-11-02 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsfm3b33.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
On Sun, Nov 02, 2008 at 06:18:08AM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > This helps editors choosing their syntax hilighting properly.
>
> Even though I agree this is the right direction to go, unfortunately this
> can break people's existing setup.
Well for now vim (I don't know if emacs has syntax highlight for it)
does:
autocmd BufNewFile,BufRead .msg.[0-9]*
\ if getline(1) =~ '^From.*# This line is ignored.$' |
\ setf gitsendemail |
\ endif
Even if you're illiterate in vim script language, you should grok what
it does, because of the fact that .msg.nnnn is hardly something one can
recognize. I believe it's highly unlikely to break anything.
What do other people think ?
> Having said that, if we were to do this, let's do it the right way and put
> these "temporary" files under $GIT_DIR.
Agreed, I should have done that.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Nguyen Thai Ngoc Duy @ 2008-11-02 9:32 UTC (permalink / raw)
To: Alex Riesen; +Cc: Pierre Habouzit, git
In-Reply-To: <20081031165003.GA5355@steel.home>
On Fri, Oct 31, 2008 at 05:50:03PM +0100, Alex Riesen wrote:
> Pierre Habouzit, Fri, Oct 31, 2008 16:55:27 +0100:
> > @@ -439,16 +436,17 @@ static int revert_or_cherry_pick(int argc, const char **argv)
> >
> > int cmd_revert(int argc, const char **argv, const char *prefix)
> > {
> > +#if 0
> > + warning("git revert is deprecated, please use git cherry-pick --revert/-R instead");
> > +#endif
>
> "git revert" is much shorter to type than "git cherry-pick -R".
> How about renaming "cherry-pick" into something short, like "pick"?
Maybe a patch like this can help? With it you can type "git cp" for
cherry-pick. If someday "git cp" is added, you can type "git c-p",
much shorter.
--<--
commit dce5cad329390905bb91115a9de0153772be57d8
Author: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Date: Sat Nov 1 17:12:04 2008 +0700
Add git command expansion
This allows git commands to be typed shorter (in shells that do not
support autocompletion). There are three types of expansion:
- "foo" matches "foo*" commands (bi -> bisect)
- "foo" also matches "f*-oo*" (fim -> fast-import)
- "foo-bar" (with dash) matches "foo*-bar*" (fo-p -> format-patch)
This feature is only enabled if core.commandexpansion is true. It
may work better if we can limit the command set (to porcelain
only for example) but I have yet to find a way to pull
commands-list.txt to help.c.
diff --git a/builtin.h b/builtin.h
index 1495cf6..9fb0fef 100644
--- a/builtin.h
+++ b/builtin.h
@@ -12,6 +12,7 @@ extern const char git_more_info_string[];
extern void list_common_cmds_help(void);
extern const char *help_unknown_cmd(const char *cmd);
+extern const char *expand_command(const char *cmd);
extern void prune_packed_objects(int);
extern int read_line_with_nul(char *buf, int size, FILE *file);
extern int fmt_merge_msg(int merge_summary, struct strbuf *in,
diff --git a/git.c b/git.c
index 89feb0b..1bbe340 100644
--- a/git.c
+++ b/git.c
@@ -14,6 +14,7 @@ struct pager_config {
const char *cmd;
int val;
};
+static int command_expansion;
static int pager_command_config(const char *var, const char *value, void *data)
{
@@ -415,6 +416,13 @@ static void execv_dashed_external(const char **argv)
strbuf_release(&cmd);
}
+static int git_command_expansion_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "core.commandexpansion"))
+ command_expansion = git_config_bool(var, value);
+
+ return git_default_config(var, value, cb);
+}
int main(int argc, const char **argv)
{
@@ -501,6 +509,15 @@ int main(int argc, const char **argv)
cmd, argv[0]);
exit(1);
}
+ git_config(git_command_expansion_config, NULL);
+ if (command_expansion) {
+ const char *expand_cmd = expand_command(cmd);
+ if (expand_cmd) {
+ argv[0] = expand_cmd;
+ handle_internal_command(argc, argv);
+ execv_dashed_external(argv);
+ }
+ }
argv[0] = help_unknown_cmd(cmd);
handle_internal_command(argc, argv);
execv_dashed_external(argv);
diff --git a/help.c b/help.c
index fd87bb5..4f0e5a0 100644
--- a/help.c
+++ b/help.c
@@ -359,6 +359,67 @@ const char *help_unknown_cmd(const char *cmd)
exit(1);
}
+const char *expand_command(const char *cmd)
+{
+ int i, n, len;
+ struct cmdnames main_cmds, other_cmds;
+ char *src, *dst;
+
+ memset(&main_cmds, 0, sizeof(main_cmds));
+ memset(&other_cmds, 0, sizeof(main_cmds));
+
+ load_command_list("git-", &main_cmds, &other_cmds);
+
+ add_cmd_list(&main_cmds, &aliases);
+ add_cmd_list(&main_cmds, &other_cmds);
+ qsort(main_cmds.names, main_cmds.cnt,
+ sizeof(main_cmds.names), cmdname_compare);
+ uniq(&main_cmds);
+
+ len = strlen(cmd);
+ n = -1;
+ src = strchr(cmd, '-');
+ for (i = 0;i < main_cmds.cnt; i++) {
+ const char *gitcmd = main_cmds.names[i]->name;
+
+ /* match prefix */
+ if (!strncmp(cmd, gitcmd, len))
+ goto ok_expand;
+
+ if (*cmd != *gitcmd)
+ continue;
+ dst = strchr(gitcmd, '-');
+ if (!dst)
+ continue;
+
+ /* cmd is foo-bar, match foo*-bar* */
+ if (src &&
+ !strncmp(cmd, gitcmd, src-cmd) &&
+ !strncmp(src+1, dst+1, cmd+len-src-1))
+ goto ok_expand;
+
+ /* cmd is foobar,match f*-oobar* */
+ if (!src && !strncmp(cmd+1, dst+1, len-1))
+ goto ok_expand;
+
+ continue;
+ok_expand:
+ trace_printf("expand: %s\n", main_cmds.names[i]->name);
+ if (n != -1)
+ return NULL;
+ n = i;
+ }
+
+ if (n != -1) {
+ const char *assumed = main_cmds.names[n]->name;
+ main_cmds.names[n] = NULL;
+ clean_cmdnames(&main_cmds);
+ return assumed;
+ }
+ else
+ return NULL;
+}
+
int cmd_version(int argc, const char **argv, const char *prefix)
{
printf("git version %s\n", git_version_string);
--<--
--
Duy
^ permalink raw reply related
* Re: [PATCH] prepare deprecation of git-revert
From: Pierre Habouzit @ 2008-11-02 9:30 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081102044159.GF5261@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]
On Sun, Nov 02, 2008 at 04:41:59AM +0000, Jeff King wrote:
> On Fri, Oct 31, 2008 at 04:55:27PM +0100, Pierre Habouzit wrote:
>
> > I've not kept the auto-edit feature of git-revert for the git-cherry-pick -R
> > case as I don't believe it makes a lot of sense. But if people are unhappy
> > with that, I can easily "fix" it.
>
> I disagree. I write a new commit message for every revert I do.
>
> When you cherry-pick, you are pulling a good commit from somewhere else.
> So its commit message should suffice to explain why you are making the
> change (and infrequently, you might want to give more context or say
> "and here is where this comes from").
>
> But when you revert, you are saying "this other commit was bad, so let's
> reverse it." So you can look at the other commit to see what it did, but
> you still don't know _why_ it was bad. A revert should always give
> information about what you know _now_ that you didn't know when you
> made the commit originally.
Indeed that makes sense, I'll update the patch then, and be lighter on
the deprecation side since it seems I misunderstood what people agreed
on.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-11-02 9:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Scott Chacon
In-Reply-To: <20081102015611.GH15463@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
On Sun, Nov 02, 2008 at 01:56:11AM +0000, Shawn O. Pearce wrote:
> Pierre Habouzit <madcoder@debian.org> wrote:
> > For types that _will_ be in the tight loops, we must make the types
> > explicit or it'll bite us hard performance-wise. I'm thinking what is
> > "struct object" or "struct commit" in git.git. It's likely that we will
> > loose a *lot* of those types are opaque.
>
> Yes, but I'm arguing they should be opaque to the application, and
> visible to the library. Today the application is suffering from
> massive fork+exec overhead. I really don't give a damn if the
> application's compiler has to deal with a function call to read
> from a private member of an opaque type. Its still thousands of
> CPU instructions less per operation.
The problem is not the function call, it's really cheap on modern CPUs.
The problem is that across a function call the compiler cannot make
some kind of optimizations and _that_ isn't cheap.
For example, pointers whose value have been loaded from the store into a
register have to be loaded again. A function call trashes all the
registers, etc...
> Come back to me a year after libgit2 has been widely deployed on
> Linux distros and we have multiple applications linking to it.
> Lets talk then about the harmful performance problems caused by
> making these types opaque to the application. About that time
> we'll also be talking about how great pack v4 is and why its a good
> thing those types were opaque, as we didn't have to break the ABI
> to introduce it.
Well I fear it'll be more than a few percent harm, and I can already see
Linus argue against the switch to libgit2 for git-core because it lost
2% performances ;P
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATHv3 2/3] gitweb: retrieve snapshot format from PATH_INFO
From: Giuseppe Bilotta @ 2008-11-02 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1225617699-30004-2-git-send-email-giuseppe.bilotta@gmail.com>
We parse requests for $project/snapshot/$head.$sfx as equivalent to
$project/snapshot/$head?sf=$sfx, where $sfx is any of the known
(although not necessarily supported) snapshot formats (or its default
suffix).
The filename for the resulting package preserves the requested
extensions (so asking for a .tgz gives a .tgz, and asking for a .tar.gz
gives a .tar.gz), although for obvious reasons it doesn't preserve the
basename (git/snapshot/next.tgz returns a file names git-next.tgz).
This introduces a potential case for ambiguity if a project has a head
that ends with a snapshot-like suffix (.zip, .tgz, .tar.gz, etc) and the
sf CGI parameter is not present; however, gitweb only produces URLs with
the sf parameter currently, so this is only a potential issue for
hand-coded URLs for extremely unusual project.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8441912..0a41be5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -616,6 +616,44 @@ sub evaluate_path_info {
$input_params{'hash_parent'} ||= $parentrefname;
}
}
+
+ # for the snapshot action, we allow URLs in the form
+ # $project/snapshot/$hash.ext
+ # where .ext determines the snapshot and gets removed from the
+ # passed $refname to provide the $hash.
+ #
+ # To be able to tell that $refname includes the format extension, we
+ # require the following two conditions to be satisfied:
+ # - the hash input parameter MUST have been set from the $refname part
+ # of the URL (i.e. they must be equal)
+ # - the snapshot format MUST NOT have been defined already (e.g. from
+ # CGI parameter sf)
+ # It's also useless to try any matching unless $refname has a dot,
+ # so we check for that too
+ if ($input_params{'action'} eq 'snapshot' &&
+ defined $refname && index($refname, '.') != -1 &&
+ $refname eq $input_params{'hash'} &&
+ !defined $input_params{'snapshot_format'}) {
+ # We loop over the known snapshot formats, checking for
+ # extensions. Allowed extensions are both the defined suffix
+ # (which includes the initial dot already) and the snapshot
+ # format key itself, with a prepended dot
+ while (my ($fmt, %opt) = each %known_snapshot_formats) {
+ my $hash = $refname;
+ my $sfx;
+ $hash =~ s/(\Q$opt{'suffix'}\E|\Q.$fmt\E)$//;
+ next unless $sfx = $1;
+ # a valid suffix was found, so set the snapshot format
+ # and reset the hash parameter
+ $input_params{'snapshot_format'} = $fmt;
+ $input_params{'hash'} = $hash;
+ # we also set the format suffix to the one requested
+ # in the URL: this way a request for e.g. .tgz returns
+ # a .tgz instead of a .tar.gz
+ $known_snapshot_formats{$fmt}{'suffix'} = $sfx;
+ last;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATHv3 3/3] gitweb: embed snapshot format parameter in PATH_INFO
From: Giuseppe Bilotta @ 2008-11-02 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1225617699-30004-3-git-send-email-giuseppe.bilotta@gmail.com>
When PATH_INFO is active, get rid of the sf CGI parameter by embedding
the snapshot format information in the PATH_INFO URL, in the form of an
appropriate extension.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0a41be5..d2484ab 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -810,6 +810,7 @@ sub href (%) {
# - action
# - hash_parent or hash_parent_base:/file_parent
# - hash or hash_base:/filename
+ # - the snapshot_format as an appropriate suffix
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -821,6 +822,10 @@ sub href (%) {
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
+ # since we destructively absorb parameters, we keep this
+ # boolean that remembers if we're handling a snapshot
+ my $is_snapshot = $params{'action'} eq 'snapshot';
+
# Summary just uses the project path URL, any other action is
# added to the URL
if (defined $params{'action'}) {
@@ -860,6 +865,18 @@ sub href (%) {
$href .= esc_url($params{'hash'});
delete $params{'hash'};
}
+
+ # If the action was a snapshot, we can absorb the
+ # snapshot_format parameter too
+ if ($is_snapshot) {
+ my $fmt = $params{'snapshot_format'};
+ # snapshot_format should always be defined when href()
+ # is called, but just in case some code forgets, we
+ # fall back to the default
+ $fmt ||= $snapshot_fmts[0];
+ $href .= $known_snapshot_formats{$fmt}{'suffix'};
+ delete $params{'snapshot_format'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ 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