* Re: [PATCH 1/4] t5400: expect success for denying deletion
From: Jan Krüger @ 2008-11-09 10:38 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Sam Vilain
In-Reply-To: <20081107220955.GA16058@coredump.intra.peff.net>
Hi,
On Fri, 7 Nov 2008 17:09:55 -0500, Jeff King <peff@peff.net> wrote:
> Reading over the mailing list postings which led to a240de11, I think
> it is simply a case that Jan didn't fully understand what
> expect_failure meant
Yes, that's exactly what happened, and it won't likely happen again.
Thanks for fixing and for the Cc.
-Jan
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-09 10:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Steve Frécinaux, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081108172759.GA31655@artemis.corp>
Pierre Habouzit wrote:
> On Sat, Nov 08, 2008 at 02:35:55PM +0000, Andreas Ericsson wrote:
>> Steve Frécinaux wrote:
>>> Just a random question: is there a reason why you have put all the
>>> .h in a separate includes/ directory instead of relying on the
>>> install target to put the include files at the right place ?
>>> To me it makes it much harder to hack on the files as one is always
>>> required to switch between both directories...
>> I agree with this, but as I guess Shawn will do roughly 45 times more
>> work on it than me (according to current commit-count in git.git), I'll
>> live with it.
>
> I don't, modifying the public includes may break the ABI and the API.
>
> I believe it to be a good practice to put them in a separate directory
> so that people modifying them will know this particular header is
> public. Yes you can name your private headers differently, but it's not
> really the same, it doesn't make editing public headers hard, and it has
> to. People modifying them _have_ to thing "err why am I modifying this
> specific header in the first place" before doing anything in it.
>
Well, I suggested putting "src/public/public_header.h" quite early on,
with private headers next to the source. AFAIU, the private and public
headers both are now located in the same directory, and that directory is
separate from the .c files.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-09 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <ddb82bf60811061909m6f8a7b72o4b03ebcde8b9d188@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
Same thing done the right way.
regards,
P.
On Fri, Nov 7, 2008 at 04:09, Piotr Findeisen <piotr.findeisen@gmail.com> wrote:
>
> Hello!
>
> I've been reading
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html till
> late night and found that "--" prefixing options names (like in "git
> diff --cached") are replaced by asciidoc with a single unicode
> character "—" which makes them unsuitable for pasting them to a
> terminal.
>
> I've cloned the git repository from
> git://git.kernel.org/pub/scm/git/git.git, made some changes to
> Documentation/user-manual.txt, tested the results and commited my work
> locally.
> The attached file is a result of running `git diff HEAD~1`.
>
> My local log message:
> ------------------
> asciidoc escaping of "--"
>
> Asciidoc replaces "--" with "—" when not in verbatim mode. This is
> sometimes unwanted -- especially when citing command line options like
> "git diff --cached". This commit includes proper quotes in user-manual.txt.
> ------------------
>
> Hope that's of any use.
>
> Best regards,
> Piotr
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: user-manual.txt.patch --]
[-- Type: text/x-diff; name=user-manual.txt.patch, Size: 6445 bytes --]
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..d200759 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -527,7 +527,7 @@ $ git reset --hard fb47ddb2db...
then test, run "bisect good" or "bisect bad" as appropriate, and
continue.
-Instead of "git bisect visualize" and then "git reset --hard
+Instead of "git bisect visualize" and then "git reset \--hard
fb47ddb2db...", you might just want to tell git that you want to skip
the current commit:
@@ -900,7 +900,7 @@ $ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
(See linkgit:git-rev-parse[1] for explanations of commit-selecting
-syntax such as `--not`.)
+syntax such as `\--not`.)
[[making-a-release]]
Creating a changelog and tarball for a software release
@@ -1024,7 +1024,7 @@ at step 3, git maintains a snapshot of the tree's contents in a
special staging area called "the index."
At the beginning, the content of the index will be identical to
-that of the HEAD. The command "git diff --cached", which shows
+that of the HEAD. The command "git diff \--cached", which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
@@ -1572,7 +1572,7 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with `linkgit:git-reset[1] --hard`, and then
+Say you modify a branch with `linkgit:git-reset[1] \--hard`, and then
realize that the branch was the only reference you had to that point in
history.
@@ -1701,7 +1701,7 @@ $ git pull
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-linkgit:git-config[1], and the discussion of the `--track` option in
+linkgit:git-config[1], and the discussion of the `\--track` option in
linkgit:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
@@ -1978,8 +1978,8 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'
This can happen, for example, if you:
- - use `git-reset --hard` to remove already-published commits, or
- - use `git-commit --amend` to replace already-published commits
+ - use `git-reset \--hard` to remove already-published commits, or
+ - use `git-commit \--amend` to replace already-published commits
(as in <<fixing-a-mistake-by-rewriting-history>>), or
- use `git-rebase` to rebase any already-published commits (as
in <<using-git-rebase>>).
@@ -2088,7 +2088,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the \--track option to linkgit:git-branch[1]) to merge changes in from
Linus by default.
-------------------------------------------------
@@ -2468,7 +2468,7 @@ $ git rebase --continue
and git will continue applying the rest of the patches.
-At any point you may use the `--abort` option to abort this process and
+At any point you may use the `\--abort` option to abort this process and
return mywork to the state it had before you started the rebase:
-------------------------------------------------
@@ -2539,7 +2539,7 @@ $ gitk origin..mywork &
and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using `commit --amend`.
+cherry-pick, and possibly modifying them as you go using `commit \--amend`.
The linkgit:git-gui[1] command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
@@ -2897,7 +2897,7 @@ Commit Object
~~~~~~~~~~~~~
The "commit" object links a physical state of a tree with a description
-of how we got there and why. Use the --pretty=raw option to
+of how we got there and why. Use the \--pretty=raw option to
linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
commit:
@@ -3700,16 +3700,16 @@ i.e. it will normally just update existing cache entries.
To tell git that yes, you really do realize that certain files no
longer exist, or that new files should be added, you
-should use the `--remove` and `--add` flags respectively.
+should use the `\--remove` and `\--add` flags respectively.
-NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
+NOTE! A `\--remove` flag does 'not' mean that subsequent filenames will
necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
-removed. The only thing `--remove` means is that update-index will be
+removed. The only thing `\--remove` means is that update-index will be
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
-As a special case, you can also do `git update-index --refresh`, which
+As a special case, you can also do `git update-index \--refresh`, which
will refresh the "stat" information of each index to match the current
stat information. It will 'not' update the object status itself, and
it will only update the fields that are used to quickly test whether
@@ -3956,7 +3956,7 @@ entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
other tools before you can write out the result.
-You can examine such index state with `git ls-files --unmerged`
+You can examine such index state with `git ls-files \--unmerged`
command. An example:
------------------------------------------------
@@ -3967,7 +3967,7 @@ $ git ls-files --unmerged
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
------------------------------------------------
-Each line of the `git ls-files --unmerged` output begins with
+Each line of the `git ls-files \--unmerged` output begins with
the blob mode bits, blob SHA1, 'stage number', and the
filename. The 'stage number' is git's way to say which tree it
came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
^ permalink raw reply related
* Re: Git and Media repositories....
From: Nguyen Thai Ngoc Duy @ 2008-11-09 4:58 UTC (permalink / raw)
To: Santi Béjar; +Cc: Tim Ansell, git
In-Reply-To: <adf1fd3d0811070519qc54369vf0da3bc28182460a@mail.gmail.com>
On 11/7/08, Santi Béjar <santi@agolina.net> wrote:
> On Sun, Nov 2, 2008 at 8:50 PM, Tim Ansell <mithro@mithis.com> wrote:
> > Hey guys,
> >
>
> [...]
>
>
> >
> > The general idea is that we always clone the complete meta-data (tags,
> > commits and trees) and then only clone blobs when they are needed (using
> > something like alternates). This allows us to support shallow, narrow
> > and sparse checkouts while still being able to perform operations such
> > as committing and merging.
> >
>
>
> A related use case could be to remove a blob from a repo but being
> able to work normally with it, similar to:
>
> http://wiki.freebsd.org/VCSFeatureObliterate
Maybe another use case: encrypted blobs (those are generally
unavailable until corrected password is given, so they are "holes" in
checkout/clone). It could be used to store sensitive content (in $HOME
for example)
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] diffcore-rename: support rename cache
From: Jeff King @ 2008-11-09 2:04 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Yann Dirson, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0811080400h7ea5377cvaa8d658335811c23@mail.gmail.com>
On Sat, Nov 08, 2008 at 07:00:10PM +0700, Nguyen Thai Ngoc Duy wrote:
> > The downsides are:
> >
> > - your cache is potentially bigger, since you are caching the score of
> > every pair you look at, instead of just "good" pairs (OTOH, you are
> > not doing a per-commit cache, which helps reduce the size)
>
> It is huge if you accidentially add --find-copies-harder to your
> command, considering that every new file will be compared against
> every files in tree (about 25k).
Hmm, yeah. I was thinking you might be able to do some kind of cut-off
on the caching (i.e., don't bother storing anything that didn't come
close). But you can't safely assume that because an entry isn't there,
it isn't worth seeing (since it might also just not have been computed
yet). You could still organize by commit, and then each commit is either
fully computed or not. But then you still have a pathspec problem.
One thing you could do is just compute the rename score between all
pairs, even if a pathspec is given, limit it to values over "0.5" (or
something low, but that eliminates the totally uninteresting cases), and
then store that as the complete cache for that commit (or tree pair, if
you want to support that).
Then you would have the full information and could do an arbitrary
pathspec limit on it. If you wanted to set the rename threshold below
0.5, then we would have to recompute without the cache (but in practice,
that should be rare).
The real downside is that you pay for the whole-tree detection when you
have asked for a pathspec (but only the first time, after which you can
always generate from cache).
Just thinking out loud...
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-11-09 1:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
In-Reply-To: <7vwsfeaqpa.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 08, 2008 at 12:49:21PM -0800, Junio C Hamano wrote:
> I meant to suggest that change contained in 3/4 can instead be "set the
> configuration to allow such a dangerous push upfront, and make sure the
> pushes the current tests perform actually are still allowed", _if_ you are
> changing the default to forbid.
Ah, I see. I did think about using the config variable for those tests,
but it felt too much like testing two things at once. That is, it is
nicer to debug if each test breaks only when the thing it is testing for
is broken, not some other random unrelated feature. Obviously that isn't
always possible, but it seemed kind of clumsy to me.
Anyway, with a default of "warn" the tests don't need any update at all
(and do serve as a test that we still haven't broken people), and I can
pass the decision off to whoever changes it to "refuse" after the
deprecation period. :)
> I think the default should be to warn for two release cycles during which
> we will give deprecation notice, and then switch the default to forbid
OK, the patch is below, replacing 4/4. 3/4 can simply be dropped at this
point (and I think 1/4 is a no-brainer to apply, and 2/4 is probably
worth it as cleanup).
I worded the warning to explain what happened so that the Frequently
Asking users might have a clue that something bad has happened. But
maybe it should also:
- suggest "git reset --hard"; of course, then we need to explain that
you would be losing your work, so we have to warn about that, too.
- more explicitly warn that the behavior is deprecated.
Also, we could potentially note the deprecation in the documentation for
the config option.
> (and we do not touch "git init/git clone" at all --- changing the default
> to forbid in newly created repositories earlier than existing repositories
> would be changing the behaviour of the command between old and new
> repositories, which is madness). If we are going this route, I think we
I agree. I suggested that for another config option recently, and I now
think I was wrong. It really doesn't dodge the "things are changing"
bullet. It just makes them change at a slightly different time, which
can be even more confusing (i.e., "this breaks in my repo, but when I
make a test repo it works" or vice versa).
I do feel like we made a config change like that at some point long ago,
but I can't recall for what, or the reasoning. Maybe
core.logallrefupdates, which does have clone-specific behavior.
> can modify the tests 3/4 touches to set the configuration to allow such a
> push and make sure that such a push is still allowed.
Again, I am not sure that is best, as above. But I tried to cover all
cases explicitly with my tests, so I think we should get good coverage
either way (and my tests don't depend on any particular default config
setting).
-- >8 --
receive-pack: detect push to current branch of non-bare repo
Pushing into the currently checked out branch of a non-bare
repository can be dangerous; the HEAD then loses sync with
the index and working tree, and it looks in the receiving
repo as if the pushed changes have been reverted in the
index (since they were never there in the first place).
This patch adds a safety valve that checks for this
condition and either generates a warning or denies the
update. We trigger the check only on a non-bare repository,
since a bare repo does not have a working tree (and in fact,
pushing to the HEAD branch is a common workflow for
publishing repositories).
The behavior is configurable via receive.denyCurrentBranch,
defaulting to "warn" so as not to break existing setups
(though it may, after a deprecation period, switch to
"refuse" by default). For users who know what they are doing
and want to silence the warning (e.g., because they have a
post-receive hook that reconciles the HEAD and working
tree), they can turn off the warning by setting it to false
or "ignore".
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/config.txt | 9 +++++++
builtin-receive-pack.c | 59 ++++++++++++++++++++++++++++++++++++++++++++++
t/t5516-fetch-push.sh | 37 ++++++++++++++++++++++++++++
3 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 965ed74..32dcd64 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1198,6 +1198,15 @@ receive.denyNonFastForwards::
even if that push is forced. This configuration variable is
set when initializing a shared repository.
+receive.denyCurrentBranch::
+ If set to true or "refuse", receive-pack will deny a ref update
+ to the currently checked out branch of a non-bare repository.
+ Such a push is potentially dangerous because it brings the HEAD
+ out of sync with the index and working tree. If set to "warn",
+ print a warning of such a push to stderr, but allow the push to
+ proceed. If set to false or "ignore", allow such pushes with no
+ message. Defaults to "warn".
+
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index 7f9f134..db67c31 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -11,8 +11,15 @@
static const char receive_pack_usage[] = "git-receive-pack <git-dir>";
+enum deny_action {
+ DENY_IGNORE,
+ DENY_WARN,
+ DENY_REFUSE,
+};
+
static int deny_deletes = 0;
static int deny_non_fast_forwards = 0;
+static enum deny_action deny_current_branch = DENY_WARN;
static int receive_fsck_objects;
static int receive_unpack_limit = -1;
static int transfer_unpack_limit = -1;
@@ -22,6 +29,21 @@ static int report_status;
static char capabilities[] = " report-status delete-refs ";
static int capabilities_sent;
+static enum deny_action parse_deny_action(const char *var, const char *value)
+{
+ if (value) {
+ if (!strcasecmp(value, "ignore"))
+ return DENY_IGNORE;
+ if (!strcasecmp(value, "warn"))
+ return DENY_WARN;
+ if (!strcasecmp(value, "refuse"))
+ return DENY_REFUSE;
+ }
+ if (git_config_bool(var, value))
+ return DENY_REFUSE;
+ return DENY_IGNORE;
+}
+
static int receive_pack_config(const char *var, const char *value, void *cb)
{
if (strcmp(var, "receive.denydeletes") == 0) {
@@ -49,6 +71,11 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "receive.denycurrentbranch")) {
+ deny_current_branch = parse_deny_action(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
@@ -173,6 +200,20 @@ static int run_update_hook(struct command *cmd)
return hook_status(run_command(&proc), update_hook);
}
+static int is_ref_checked_out(const char *ref)
+{
+ unsigned char sha1[20];
+ const char *head;
+
+ if (is_bare_repository())
+ return 0;
+
+ head = resolve_ref("HEAD", sha1, 0, NULL);
+ if (!head)
+ return 0;
+ return !strcmp(head, ref);
+}
+
static const char *update(struct command *cmd)
{
const char *name = cmd->ref_name;
@@ -186,6 +227,24 @@ static const char *update(struct command *cmd)
return "funny refname";
}
+ switch (deny_current_branch) {
+ case DENY_IGNORE:
+ break;
+ case DENY_WARN:
+ if (!is_ref_checked_out(name))
+ break;
+ warning("updating the currently checked out branch; this may"
+ " cause confusion,\n"
+ "as the index and working tree do not reflect changes"
+ " that are now in HEAD.");
+ break;
+ case DENY_REFUSE:
+ if (!is_ref_checked_out(name))
+ break;
+ error("refusing to update checked out branch: %s", name);
+ return "branch is currently checked out";
+ }
+
if (!is_null_sha1(new_sha1) && !has_sha1_file(new_sha1)) {
error("unpack should have generated %s, "
"but I can't find it!", sha1_to_hex(new_sha1));
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 3411107..a6532cb 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -486,4 +486,41 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'warn on push to HEAD of non-bare repository' '
+ mk_test heads/master
+ (cd testrepo &&
+ git checkout master &&
+ git config receive.denyCurrentBranch warn) &&
+ git push testrepo master 2>stderr &&
+ grep "warning.*this may cause confusion" stderr
+'
+
+test_expect_success 'deny push to HEAD of non-bare repository' '
+ mk_test heads/master
+ (cd testrepo &&
+ git checkout master &&
+ git config receive.denyCurrentBranch true) &&
+ test_must_fail git push testrepo master
+'
+
+test_expect_success 'allow push to HEAD of bare repository (bare)' '
+ mk_test heads/master
+ (cd testrepo &&
+ git checkout master &&
+ git config receive.denyCurrentBranch true &&
+ git config core.bare true) &&
+ git push testrepo master 2>stderr &&
+ ! grep "warning.*this may cause confusion" stderr
+'
+
+test_expect_success 'allow push to HEAD of non-bare repository (config)' '
+ mk_test heads/master
+ (cd testrepo &&
+ git checkout master &&
+ git config receive.denyCurrentBranch false
+ ) &&
+ git push testrepo master 2>stderr &&
+ ! grep "warning.*this may cause confusion" stderr
+'
+
test_done
^ permalink raw reply related
* Re: Init on push
From: Francis Galiegue @ 2008-11-09 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, Jakub Narebski, git
In-Reply-To: <7vmyg9bvu0.fsf@gitster.siamese.dyndns.org>
Le Sunday 09 November 2008 01:13:11 Junio C Hamano, vous avez écrit :
> Francis Galiegue <fg@one2team.net> writes:
> > Le Saturday 08 November 2008 21:44:25 Francis Galiegue, vous avez écrit :
> > [...]
> >
> >> I personnaly think that the directory creation SHOULD be created
> >
> > I meant "handled", sorry.
>
> Why have we ended up losing the most important Cc: to the original patch
> submitter who asked if the idea of his patch is sound?
Sorry for that. I blindly "replied to all", not seeing that the reply chain
has been "broken" along the way.
--
fge
^ permalink raw reply
* Re: [RFC] Configuring (future) committags support in gitweb
From: Jakub Narebski @ 2008-11-09 0:25 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811090027.14343.fg@one2team.net>
Dnia niedziela 9. listopada 2008 00:27, Francis Galiegue napisał:
> Le Saturday 08 November 2008 23:35:48 Jakub Narebski, vous avez écrit :
>>> I don't understand what the "signoff" builtin is : is that a link to see
>>> only commits "Signed-off-by:" a particular person?
>>
>> Committags doesn't need to be replaced by links. In this case I meant
>> here using 'signoff' class for Signed-off-by: (and the like) lines, by
>> wrapping it in '<span class="signoff">' ... '</a>'.
>
> Well, this would also mean to update gitweb.css, wouldn't it?
Not necessary. Please remember that you can configure gitweb to either
use _alternate_ stylesheet (instead of provided gitweb.css), or use
_additional_ stylesheet (for example gitweb-commit.css in addition to
gitweb.css)
>>> And also, what about the sha1 builtin? AFAIK, a SHA1 can point to a
>>> commit, a tree, and others... In fact, it points to any of these right
>>> now, but how would you tell apart these different SHA1s in a commit
>>> message? The only obvious use I see for it is the builtin "Revert ..."
>>> commit message, that the commiter _can_ override...
>>
>> SHA1 (or shortened SHA1 from 8 charasters to 40 characters, or to be
>> even more exact something that looks like SHA1) is replaced by link
>> to 'object' view, which in turn finds type of object and _redirect_
>> to proper view, be it 'commit' (most frequent), 'tag', 'blob' or 'tree'.
>>
>> We could have used instead gitweb link with 'h' (hash) parameter, but
>> without 'a' (action) parameter, which currently finds type of object
>> and _uses_ correct view...
>
> OK, you lost me somewhat.
I'm sorry about that. Perhaps I should use only one mechanism.
> What I understand is that right now, the SHA1 links are "pre-processed" by
> gitweb so that the 'a' parameter is correct, right?
No, they are 'post-processed': finding correct action is left to
_after_ you click on the link (it is more natural, and helps
performance).
If you don't know action for given SHA-1 you can use either
http://example.com/gitweb.cgi?a=object;h=deadbeef
which finds correct type (for example 'commit') and redirects using
HTTP 302 Found redirection to
http://example.com/gitweb.cgi?a=commit;h=deadbeef
This way is used bu SHA-1 committag in commit messages.
Alternate solution (meant for bugtrackers), done by another author,
is to simply skip action ('a') parameter:
http://example.com/gitweb.cgi?h=deadbeef
and then gitweb finds type of object and act accordingly (without
redirect to correct view).
[...]
>>> Finally, is there any reason to think that a sha1 or signoff committag
>>> will ever need to be overriden in some way?
>>
>> One might not want to link SHA1, for example if there are lots of false
>> positives because of commit message conventions or something, or refine
>> 'signoff' committag to use different styles for different types of
>> signoff: Signed-off-by, Acked-by, Tested-by, other. Having explicit
>> 'signoff' committag allows us also to put some committags _after_ it,
>> for example SPAM-protection of emails, or add some committag before
>> 'sha1' to filter out some SHA1 match false positives.
>
> Hmmm, so this means you'd want to make styles customizable somewhat (signoff).
> In fact, what you really want is span for CSS! Then why not, just, making a
> document to say "This is what you can do with CSS for gitweb", and say "these
> are the available CSS tags", and then be done with it?
>
> I mean, when comes the day that someone will WANT other spans to be defined,
> badly, it's not like it will be unheard of, won't it?
Errr... I don't understand.
The examples perhaps are not the best. One would be for example to use
different class (different style) for Signed-off-by signoff (which
denotes signing Certificate of Origin), and the rest of (informative)
signoff:
[gitweb]
committags = sha1 signoff_signed signoff
Another example would be to add SPAM-protection of emails, for example
replacing 'user@example.com' by 'user AT example DOT com', or something
more advanced. This have to be used _after_ signoff, because otherwise
regexp could have difficulties matching mangled email
[gitweb]
committags = sha1 signoff mailto
>>
>>> And I don't see what you '_a_' and '_b_' are about...
>>
>> For example in link match, the text of the link can be further refined
>> by committags later in sequence.
>
> I still don't get it. Can you give an example?
For example signoff line
Signed-off-by: A U Thor <author@example.com>
would be replaced by
{<span class="signoff">}Signed-off-by: A U Thor <author@example.com>{</a>}
where parts inside {...} is HTML code, and should be not expanded
further, and parts outside it could be expanded further by following
lower priority committags (like anti-SPAM for emails), and have to be
finally HTML escaped (like '<' and '>' in email in signoff).
.....................................................................
> [personal thoughts: it would be really, really nice if, somewhat, gitweb.perl
> were splitted somewhat into different modules, and ideally use more
> of "what's out there on CPAN". I'm convinced that some CPAN modules would be
> of GREAT help to gitweb, as well as I'm convinced that not many people out
> there use Windows to run gitweb anyway :p]
First, having gitweb in (almost) one piece makes for easier installation.
But there are plans to have gitweb use Git.pm or future Got::Repo and
friends. I'm not sure about further splitting...
Second, we cannot in good faith use CPAN modules which cannot be found
in standard Perl distributions, or at least in some trusted extras
package (application) repositories, as gitweb is sometimes run on
machines with tight security (think kernel.org for example) where you
cannot simply ask admin to install some third-party alpha-version CPAN
module.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Init on push
From: Junio C Hamano @ 2008-11-09 0:13 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Robin Rosenberg, Jakub Narebski, git
In-Reply-To: <200811082150.24583.fg@one2team.net>
Francis Galiegue <fg@one2team.net> writes:
> Le Saturday 08 November 2008 21:44:25 Francis Galiegue, vous avez écrit :
> [...]
>>
>> I personnaly think that the directory creation SHOULD be created
>
> I meant "handled", sorry.
Why have we ended up losing the most important Cc: to the original patch
submitter who asked if the idea of his patch is sound?
^ permalink raw reply
* Re: [RFC] Configuring (future) committags support in gitweb
From: Francis Galiegue @ 2008-11-08 23:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811082335.49505.jnareb@gmail.com>
Le Saturday 08 November 2008 23:35:48 Jakub Narebski, vous avez écrit :
> >
> > What do you mean with "not having to write whole replacement rule"?
>
> Like in example with 'link' rule, not having to write whole
> <a href="http://example.com/bugzilla.php?id=$1">$&</a>
> (or something like that).
>
OK, good one.
> >> I think it would be good idea to use repository config file for
> >> setting-up repository-specific committags, and use whatever Perl
> >> structure for global configuration. The config language can be
> >> borrowed from "drivers" in gitattributes (`diff' and `merge' drivers).
> >>
> >> So the example configuration could look like this:
> >>
> >> [gitweb]
> >> committags = sha1 signoff bugzilla
> >>
> >> [committag "bugzilla"]
> >> match = "\\b(?:#?)(\\d+)\\b"
> >> link = "http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1"
> >>
> >> where 'sha1' and 'signoff' are built-in committags, committags are
> >> applied in the order they are put in gitweb.committags;
> >
> > I don't understand what the "signoff" builtin is : is that a link to see
> > only commits "Signed-off-by:" a particular person?
>
> Committags doesn't need to be replaced by links. In this case I meant
> here using 'signoff' class for Signed-off-by: (and the like) lines, by
> wrapping it in '<span class="signoff">' ... '</a>'.
>
Well, this would also mean to update gitweb.css, wouldn't it?
> > And also, what about the sha1 builtin? AFAIK, a SHA1 can point to a
> > commit, a tree, and others... In fact, it points to any of these right
> > now, but how would you tell apart these different SHA1s in a commit
> > message? The only obvious use I see for it is the builtin "Revert ..."
> > commit message, that the commiter _can_ override...
>
> SHA1 (or shortened SHA1 from 8 charasters to 40 characters, or to be
> even more exact something that looks like SHA1) is replaced by link
> to 'object' view, which in turn finds type of object and _redirect_
> to proper view, be it 'commit' (most frequent), 'tag', 'blob' or 'tree'.
>
> We could have used instead gitweb link with 'h' (hash) parameter, but
> without 'a' (action) parameter, which currently finds type of object
> and _uses_ correct view...
>
OK, you lost me somewhat.
What I understand is that right now, the SHA1 links are "pre-processed" by
gitweb so that the 'a' parameter is correct, right?
Out of curiosity, I just went to the kernel git repository (I don't know the
git version that git.kernel.org uses offhand) and altered the 'a' parameter
to something which is not even an 'a' command at all: 500...
However, if I try a VALID 'a' command with an "irrelevant" 'h' parameter, it
acts quite funny: it just looks like it wants to try the closest match, but
takes some time figuring it out... Sometimes to something relevant, sometimes
to nothing really relevant. See for instance [1], in which 'a' was
originally "commit".
Ow.
[1]
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.27.y.git;a=tag;h=788a5f3f70e2a9c46020bdd3a195f2a866441c5d
> > Finally, is there any reason to think that a sha1 or signoff committag
> > will ever need to be overriden in some way?
>
> One might not want to link SHA1, for example if there are lots of false
> positives because of commit message conventions or something, or refine
> 'signoff' committag to use different styles for different types of
> signoff: Signed-off-by, Acked-by, Tested-by, other. Having explicit
> 'signoff' committag allows us also to put some committags _after_ it,
> for example SPAM-protection of emails, or add some committag before
> 'sha1' to filter out some SHA1 match false positives.
>
Hmmm, so this means you'd want to make styles customizable somewhat (signoff).
In fact, what you really want is span for CSS! Then why not, just, making a
document to say "This is what you can do with CSS for gitweb", and say "these
are the available CSS tags", and then be done with it?
I mean, when comes the day that someone will WANT other spans to be defined,
badly, it's not like it will be unheard of, won't it?
>
> > And I don't see what you '_a_' and '_b_' are about...
>
> For example in link match, the text of the link can be further refined
> by committags later in sequence.
I still don't get it. Can you give an example?
[personal thoughts: it would be really, really nice if, somewhat, gitweb.perl
were splitted somewhat into different modules, and ideally use more
of "what's out there on CPAN". I'm convinced that some CPAN modules would be
of GREAT help to gitweb, as well as I'm convinced that not many people out
there use Windows to run gitweb anyway :p]
--
fge
^ permalink raw reply
* Re: [RFC] Configuring (future) committags support in gitweb
From: Jakub Narebski @ 2008-11-08 22:35 UTC (permalink / raw)
To: Francis Galiegue; +Cc: git
In-Reply-To: <200811082102.44919.fg@one2team.net>
Dnia sobota 8. listopada 2008 21:02, Francis Galiegue napisał:
> Le Saturday 08 November 2008 20:07:53 Jakub Narebski, vous avez écrit :
>> Francis Galiegue <fg@one2team.net> writes
>> in "Need help for migration from CVS to git in one go..."
>>
>>> * third: also Bonsai-related; Bonsai can link to Bugzilla by
>>> matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
>>> http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
>>> this built-in? (haven't looked yet) Is this planned, or has it been
>>> discussed and been considered not worth the hassle?
[...]
>> Committags are "tags" in commit messages, expanded when rendering commit
>> message, like gitweb now does for (shortened) SHA-1, converting them to
>> 'object' view link. It should be done in a way to make it easy
>> configurable, preferably having to configure only variable part, and not
>> having to write whole replacement rule.
>>
>> Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
>> Message-Id, plain text URL e.g. _http://repo.or.cz_, spam protecting
>> of email addresses, "rich text formatting" like *bold* and _underline_,
>> syntax highlighting of signoff lines.
>>
>
> What do you mean with "not having to write whole replacement rule"?
Like in example with 'link' rule, not having to write whole
<a href="http://example.com/bugzilla.php?id=$1">$&</a>
(or something like that).
>> I think it would be good idea to use repository config file for
>> setting-up repository-specific committags, and use whatever Perl
>> structure for global configuration. The config language can be
>> borrowed from "drivers" in gitattributes (`diff' and `merge' drivers).
>>
>> So the example configuration could look like this:
>>
>> [gitweb]
>> committags = sha1 signoff bugzilla
>>
>> [committag "bugzilla"]
>> match = "\\b(?:#?)(\\d+)\\b"
>> link = "http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1"
>>
>> where 'sha1' and 'signoff' are built-in committags, committags are
>> applied in the order they are put in gitweb.committags;
>
> I don't understand what the "signoff" builtin is : is that a link to see only
> commits "Signed-off-by:" a particular person?
Committags doesn't need to be replaced by links. In this case I meant
here using 'signoff' class for Signed-off-by: (and the like) lines, by
wrapping it in '<span class="signoff">' ... '</a>'.
> And also, what about the sha1 builtin? AFAIK, a SHA1 can point to a commit, a
> tree, and others... In fact, it points to any of these right now, but how
> would you tell apart these different SHA1s in a commit message? The only
> obvious use I see for it is the builtin "Revert ..." commit message, that the
> commiter _can_ override...
SHA1 (or shortened SHA1 from 8 charasters to 40 characters, or to be
even more exact something that looks like SHA1) is replaced by link
to 'object' view, which in turn finds type of object and _redirect_
to proper view, be it 'commit' (most frequent), 'tag', 'blob' or 'tree'.
We could have used instead gitweb link with 'h' (hash) parameter, but
without 'a' (action) parameter, which currently finds type of object
and _uses_ correct view...
> Finally, is there any reason to think that a sha1 or signoff committag will
> ever need to be overriden in some way?
One might not want to link SHA1, for example if there are lots of false
positives because of commit message conventions or something, or refine
'signoff' committag to use different styles for different types of
signoff: Signed-off-by, Acked-by, Tested-by, other. Having explicit
'signoff' committag allows us also to put some committags _after_ it,
for example SPAM-protection of emails, or add some committag before
'sha1' to filter out some SHA1 match false positives.
>> possible actions
>> for committag driver include:
>> * link: replace $match by '_<a href="$link">_$match_</a>_'
>> * html: replace $match by '_$html_'
>> * text: replace $match by '$text'
>> where '_a_' means that 'a' is treated as HTML, and is not expanded
>> further, and 'b' means that it can be further expanded by later
>> committags, and finally is HTML-escaped (esc_html).
>>
>
> What use do you see for the html match? Just asking...
For example 'signoff' committag... well, it is not exactly pure "html"
but rather something like template.
[committag "signoff"]
match = "(?i)^ *(signed[ \\-]off[ \\-]by[ :]|acked[ \\-]by[ :]|cc[ :])"
templ = "{<span class=\"signoff\">}$1{</span>}"
Or simpler
[committag "signoff"]
match = "(?i)^ *(signed[ \\-]off[ \\-]by[ :]|acked[ \\-]by[ :]|cc[ :])"
class = signoff
> And I don't see what you '_a_' and '_b_' are about...
For example in link match, the text of the link can be further refined
by committags later in sequence.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: absurdly slow git-diff
From: Junio C Hamano @ 2008-11-08 21:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Davide Libenzi, Abhijit Menon-Sen, Pierre Habouzit,
Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811071554590.3468@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Junio, the time difference is quite big for Abhijit's admittedly odd
> test-case:
> ...
> with no difference in output.
In git.git history, "git-whatchanged -m -p -1" gives different output for
the following commits, with and without the patch:
c0e9892637e8144f10f2c408e276a470520f3601
d6b3e3a33f71910526ccf80af6c13a230363cd89
cecb98a9c3ed9271b0974bb6d7edbcf16e8a68f3
ce18135d862b5dbc731d203b27c279529e58b54b
36b5b3c65948694d9a92de5a17f2b97c3cd84879
767e130915015f897fb87b939843b4882212574b
927a503cd07718ea0f700052043f383253904a56
I've sampled a few (but not all) of them and they are different only
because just how common lines are matched up, which is expected.
^ permalink raw reply
* Re: Init on push
From: Francis Galiegue @ 2008-11-08 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <200811082144.25261.fg@one2team.com>
Le Saturday 08 November 2008 21:44:25 Francis Galiegue, vous avez écrit :
[...]
>
> I personnaly think that the directory creation SHOULD be created
I meant "handled", sorry.
--
fge
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Junio C Hamano @ 2008-11-08 20:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, Sam Vilain
In-Reply-To: <20081108142756.GC17100@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yes, they do break with 4/4 applied without 3/4 (that was how I found
> them, but "git rebase -i" let me pretend I had the proper foresight. ;)
> ). We can keep 3/4 back until the switch from "warn" to "yes", if that's
> what you are suggesting.
I meant to suggest that change contained in 3/4 can instead be "set the
configuration to allow such a dangerous push upfront, and make sure the
pushes the current tests perform actually are still allowed", _if_ you are
changing the default to forbid.
I think the default should be to warn for two release cycles during which
we will give deprecation notice, and then switch the default to forbid
(and we do not touch "git init/git clone" at all --- changing the default
to forbid in newly created repositories earlier than existing repositories
would be changing the behaviour of the command between old and new
repositories, which is madness). If we are going this route, I think we
can modify the tests 3/4 touches to set the configuration to allow such a
push and make sure that such a push is still allowed.
^ permalink raw reply
* Re: Init on push
From: Francis Galiegue @ 2008-11-08 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v3ai2c5sd.fsf@gitster.siamese.dyndns.org>
Le Saturday 08 November 2008 21:38:10 Junio C Hamano, vous avez écrit :
> Francis Galiegue <fg@one2team.com> writes:
> > Le Saturday 08 November 2008 21:06:01 Jakub Narebski, vous avez écrit :
> >> Junio C Hamano wrote:
> >> > - Teach "-D $there" option to "git init", which does an "mkdir -p $it
> >> > && chdird $it" before it does its work.
> >>
> >> Shouldn't it be "-C $there" (like make and tar)?
> >
> > I agree with that. It's pretty much a standard for quite a few "command
> > line people", insofar as I always look for such an option in case I want
> > to know whether a command has the ability to chdir() to a different
> > directory than the current one :p
>
> In this particular case, it is not "chdir() before starting" but "mkdir
> and then chdir() into it". Using -C would be counterproductive.
> --
> 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
I have missed the mkdir part, but then here this is mkdir _-p_...
I mean, what is the cost of mkdir -p the/dir and then git init -C the/dir? I
don't think it's that good an idea to have git create the directory in this
case...
Think of what would happen if you git -D a/b, and a is a symlink to, where,
somewhere (doesn't exist, exists but if you touch it you're {in trouble,good
for jail time, whatever}).
I personnaly think that the directory creation SHOULD be created to the
commands that are meant for it, just as git handles dir creation in its own
space (a git repository).
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: Init on push
From: Junio C Hamano @ 2008-11-08 20:38 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Jakub Narebski, git
In-Reply-To: <200811082108.34535.fg@one2team.com>
Francis Galiegue <fg@one2team.com> writes:
> Le Saturday 08 November 2008 21:06:01 Jakub Narebski, vous avez écrit :
>> Junio C Hamano wrote:
>> > - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
>> > chdird $it" before it does its work.
>>
>> Shouldn't it be "-C $there" (like make and tar)?
>
> I agree with that. It's pretty much a standard for quite a few "command line
> people", insofar as I always look for such an option in case I want to know
> whether a command has the ability to chdir() to a different directory than
> the current one :p
In this particular case, it is not "chdir() before starting" but "mkdir
and then chdir() into it". Using -C would be counterproductive.
^ permalink raw reply
* Re: [question] git svn fail to fetch GCC source due to index mismatch
From: Björn Steinbrink @ 2008-11-08 20:34 UTC (permalink / raw)
To: dennis; +Cc: git
In-Reply-To: <4914A413.80301@gmail.com>
On 2008.11.08 04:24:51 +0800, dennis wrote:
> HI:
> I have problem when use git svn fetch command to
> retrieve the GCC source code.
> It says index mismatch, then abort, any suggestion?
>
>
> $git svn fetch
> Index mismatch: 98ba56dbceddf50ebfab9e4649e9b1b1a319b377 !=
> 4f40f4619690f89454614be0eba63d584d25523e
> rereading 19e22aa4cbc9f7e3667243481f33c859e3bba358
> Found possible branch point: svn://gcc.gnu.org/svn/gcc/trunk =>
> svn://gcc.gnu.org/svn/gcc/trunk, 130802
> Initializing parent: git-svn@130802
> Found branch parent: (git-svn) 9a08076e1ad241080838d547f64a2a9aceb083ca
> Index mismatch: 4f40f4619690f89454614be0eba63d584d25523e !=
> 98ba56dbceddf50ebfab9e4649e9b1b1a319b377
> rereading 9a08076e1ad241080838d547f64a2a9aceb083ca
> Following parent with do_switch
> Malformed network data: Malformed network data at
> /usr/libexec/git-core/git-svn line 2340
>
> $git branch -a
> git-svn
> git-svn@130802
ad0a82bae: git-svn: Always create a new RA when calling do_switch for svn://
According to the commit message, that fixed a problem that caused the
"Malformed netword data" error. It's in git v1.6.0.3, so if you have an
older git version, try upgrading.
HTH
Björn
^ permalink raw reply
* Re: Init on push
From: Junio C Hamano @ 2008-11-08 20:12 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Robin Rosenberg, git
In-Reply-To: <bb6f213e0811081201w22a36800j1713b91d0cf66fb2@mail.gmail.com>
"Alexander Gavrilov" <angavrilov@gmail.com> writes:
> Gitosis works by replacing the shell with a program called
> gitosis-serve, which parses and validates the incoming commands
> against the user access configuration. If it sees an unknown command,
> it will simply refuse to execute it.
If you implement a new feature by enhancing receive-pack (or anything
else), you obviously cannot use the new feature against an installation
with an older implementation, so what you said is a known. My point was
how to enhance the receiving end and what constraints we would have in
enhancing it.
> On the other hand it will automatically perform initialization before
> calling receive-pack if the user is authorized to write to a certain
> path, but the repository does not exist yet.
That's good to know. I also realize that gitosis does not need any hook
for "git init -D $there" to decide whether a new repository can be created
at requested location, as it reads the command line and makes decision
before driving the underlying command in response to the request.
On the other hand, people who enable 'push' access to their git-daemon
would need it, as the daemon would not even know who is asking for --init.
^ permalink raw reply
* Re: Init on push
From: Francis Galiegue @ 2008-11-08 20:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gf4rf6$v52$1@ger.gmane.org>
Le Saturday 08 November 2008 21:06:01 Jakub Narebski, vous avez écrit :
> Junio C Hamano wrote:
> > - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
> > chdird $it" before it does its work.
>
> Shouldn't it be "-C $there" (like make and tar)?
I agree with that. It's pretty much a standard for quite a few "command line
people", insofar as I always look for such an option in case I want to know
whether a command has the ability to chdir() to a different directory than
the current one :p
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* Re: Init on push
From: Jakub Narebski @ 2008-11-08 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <7viqqyc93w.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> - Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
> chdird $it" before it does its work.
Shouldn't it be "-C $there" (like make and tar)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Configuring (future) committags support in gitweb
From: Francis Galiegue @ 2008-11-08 20:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811082007.55045.jnareb@gmail.com>
Le Saturday 08 November 2008 20:07:53 Jakub Narebski, vous avez écrit :
> Francis Galiegue <fg@one2team.net> writes
> in "Need help for migration from CVS to git in one go..."
>
> > * third: also Bonsai-related; Bonsai can link to Bugzilla by
> > matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> > this built-in? (haven't looked yet) Is this planned, or has it been
> > discussed and been considered not worth the hassle?
>
> Here below there is proposal how the committags support could look like
> for gitweb _user_, which means how to configure gitweb to use (or do not
> use) committags, how to configure committags, and how to define new
> committags.
>
Your proposal goes much further than my initial question, but I thought I'd
jump in anyway :p
> Committags are "tags" in commit messages, expanded when rendering commit
> message, like gitweb now does for (shortened) SHA-1, converting them to
> 'object' view link. It should be done in a way to make it easy
> configurable, preferably having to configure only variable part, and not
> having to write whole replacement rule.
>
> Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
> Message-Id, plain text URL e.g. _http://repo.or.cz_, spam protecting
> of email addresses, "rich text formatting" like *bold* and _underline_,
> syntax highlighting of signoff lines.
>
What do you mean with "not having to write whole replacement rule"?
> I think it would be good idea to use repository config file for
> setting-up repository-specific committags, and use whatever Perl
> structure for global configuration. The config language can be
> borrowed from "drivers" in gitattributes (`diff' and `merge' drivers).
>
> So the example configuration could look like this:
>
> [gitweb]
> committags = sha1 signoff bugzilla
>
> [committag "bugzilla"]
> match = "\\b(?:#?)(\\d+)\\b"
> link = "http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1"
>
> where 'sha1' and 'signoff' are built-in committags, committags are
> applied in the order they are put in gitweb.committags;
I don't understand what the "signoff" builtin is : is that a link to see only
commits "Signed-off-by:" a particular person?
If so, might I suggest that an "alt" tells "Only show commits signed off by
this person"?
And also, what about the sha1 builtin? AFAIK, a SHA1 can point to a commit, a
tree, and others... In fact, it points to any of these right now, but how
would you tell apart these different SHA1s in a commit message? The only
obvious use I see for it is the builtin "Revert ..." commit message, that the
commiter _can_ override...
Or would that be:
my $sha1_re = qr/[a-z[0-9]{40}/;
/(?:(?i:commit\s+))?\b($sha1_re)\b/ => [link to commit $1]
/(?:(?i:tree\s+))\b($sha1_re)\b)/ => [link to tree $1]
/(?:(?:tag\s+))\b($sha1_re)\b)/ => [link to tag $1]
Finally, is there any reason to think that a sha1 or signoff committag will
ever need to be overriden in some way?
> possible actions
> for committag driver include:
> * link: replace $match by '_<a href="$link">_$match_</a>_'
> * html: replace $match by '_$html_'
> * text: replace $match by '$text'
> where '_a_' means that 'a' is treated as HTML, and is not expanded
> further, and 'b' means that it can be further expanded by later
> committags, and finally is HTML-escaped (esc_html).
>
What use do you see for the html match? Just asking...
And I don't see what you '_a_' and '_b_' are about...
--
fge
^ permalink raw reply
* Re: Init on push
From: Alexander Gavrilov @ 2008-11-08 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, git
In-Reply-To: <7viqqyc93w.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 8, 2008 at 10:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> An easy alternative would be to issue the usual "mkdir && git init" shell
> script before spawning receive-pack. This will limit the feature to
> pushing over the ssh transport, and pushing over the git protocol against
> a loose git-daemon will not be able to support it. Also I suspect this
> will break sites managed by gitosis, where all repositories are held under
> the same UNIX user identity, differenciated only via an environment it
> sets based on the ssh key used to make the connection.
Gitosis works by replacing the shell with a program called
gitosis-serve, which parses and validates the incoming commands
against the user access configuration. If it sees an unknown command,
it will simply refuse to execute it.
On the other hand it will automatically perform initialization before
calling receive-pack if the user is authorized to write to a certain
path, but the repository does not exist yet.
Alexander
^ permalink raw reply
* Re: Init on push
From: Junio C Hamano @ 2008-11-08 19:26 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200811081708.45672.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> git remote add someremote someurl
> git push --init someremote/someurl
>
> The implementation would invoke receive pack on the receiving side with
> an --init option. On the server side the repository would be created and
> initialized just as one had executed and mkdir and git init --bare.
We saw this quite a number of times. I think it's about time we did
something about it.
But I do not think it is a reasonable design to give receive-pack such an
option.
An easy alternative would be to issue the usual "mkdir && git init" shell
script before spawning receive-pack. This will limit the feature to
pushing over the ssh transport, and pushing over the git protocol against
a loose git-daemon will not be able to support it. Also I suspect this
will break sites managed by gitosis, where all repositories are held under
the same UNIX user identity, differenciated only via an environment it
sets based on the ssh key used to make the connection.
I wonder if you can take a middle ground alternative:
- Make "git push --init [--shared] $site:$there" and "git push --init
[--shared] git://$site/$there" run "git init -D [--shared] $there"
followed by "git receive-pack $there";
- Teach "-D $there" option to "git init", which does an "mkdir -p $it &&
chdird $it" before it does its work.
- Teach "git daemon" about the "init" service, which is disabled by
default, and can be enabled just like you can enable receive-pack
there.
If sites like repo.or.cz, github, or managed with gitosis want to use
this, I think you might further need to give "git init -D $there" a hook
to control who can create new repositories at which location (gitosis is
the most interesting case, as described above).
^ permalink raw reply
* [RFC] Configuring (future) committags support in gitweb
From: Jakub Narebski @ 2008-11-08 19:07 UTC (permalink / raw)
To: git; +Cc: Francis Galiegue
Francis Galiegue <fg@one2team.net> writes
in "Need help for migration from CVS to git in one go..."
> * third: also Bonsai-related; Bonsai can link to Bugzilla by
> matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> this built-in? (haven't looked yet) Is this planned, or has it been
> discussed and been considered not worth the hassle?
Here below there is proposal how the committags support could look like
for gitweb _user_, which means how to configure gitweb to use (or do not
use) committags, how to configure committags, and how to define new
committags.
Committags are "tags" in commit messages, expanded when rendering commit
message, like gitweb now does for (shortened) SHA-1, converting them to
'object' view link. It should be done in a way to make it easy
configurable, preferably having to configure only variable part, and not
having to write whole replacement rule.
Possible committags include: _BUG(n)_, bug _#n_, _FEATURE(n),
Message-Id, plain text URL e.g. _http://repo.or.cz_, spam protecting
of email addresses, "rich text formatting" like *bold* and _underline_,
syntax highlighting of signoff lines.
I think it would be good idea to use repository config file for
setting-up repository-specific committags, and use whatever Perl
structure for global configuration. The config language can be
borrowed from "drivers" in gitattributes (`diff' and `merge' drivers).
So the example configuration could look like this:
[gitweb]
committags = sha1 signoff bugzilla
[committag "bugzilla"]
match = "\\b(?:#?)(\\d+)\\b"
link = "http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1"
where 'sha1' and 'signoff' are built-in committags, committags are
applied in the order they are put in gitweb.committags; possible actions
for committag driver include:
* link: replace $match by '_<a href="$link">_$match_</a>_'
* html: replace $match by '_$html_'
* text: replace $match by '$text'
where '_a_' means that 'a' is treated as HTML, and is not expanded
further, and 'b' means that it can be further expanded by later
committags, and finally is HTML-escaped (esc_html).
What do you think about this?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: pull --preserve-merges
From: Stephen Haberman @ 2008-11-08 17:57 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Johannes Schindelin, git
In-Reply-To: <200811081807.53199.fg@one2team.net>
Replying to both Johannes and Francis...
> > > Awhile ago I brought up wanting to have a "rebase with preserve merges"
> > > option for `git pull`
> >
> > That might be something you want, but you cannot call it
> >
> > git pull --preserve-merges
> >
> > since everybody used to "pull = fetch && merge" would go "Huh? A merge
> > _does_ preserve merges".
Ah, right, sorry, Johannes, I know it only makes sense in the context if
--rebase is also being in use, I was just being too brief.
> > If at all, you could call it "--rebase=preserve-merges".
I'd be fine with that, I had not thought of it.
> Why not --rebase --keep-merges? Personnally, I think it makes things clearer
> since in general options are either standalone or have a value.
I originally had --rebase --preserve-merges in mind because it matches
the existing -p/--preserve-merges flag that git rebase has that I'd
like git pull to just pass along.
If they were separate flags, passing just --preserve-merges without
--rebase should likely report an error. Probably the same thing if
someone sets `branch.name.preservemerges` but `branch.name.rebase` is
not set.
Unless instead of separate config parameters, `branch.name.rebase` uses
Johannes's suggestion and has separate values...true or false or
preserve-merges. That would probably better parallelize with the
--rebase=preserve-merges style command line argument.
Between one flag/config parameter or two flags/config parameters, I
could go either way and would be willing to patch together either one
to get it in.
Thanks,
Stephen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox