* 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
* [PATHv3 1/3] gitweb: make the supported snapshot formats array global
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-1-git-send-email-giuseppe.bilotta@gmail.com>
The array of supported snapshot format is used and defined (with two
different names) in two routines, one of which (format_snapshot_links)
is often called multiple times per page.
Simplify code and speed up page generation by making the array global.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 15 +++++++--------
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9d1af7e..8441912 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -721,6 +721,10 @@ if (defined $searchtext) {
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
+# list of supported snapshot formats
+our @snapshot_fmts = gitweb_check_feature('snapshot');
+@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
+
# dispatch
if (!defined $action) {
if (defined $hash) {
@@ -1647,8 +1651,6 @@ sub format_diff_line {
# linked. Pass the hash of the tree/commit to snapshot.
sub format_snapshot_links {
my ($hash) = @_;
- my @snapshot_fmts = gitweb_check_feature('snapshot');
- @snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
my $num_fmts = @snapshot_fmts;
if ($num_fmts > 1) {
# A parenthesized list of links bearing format names.
@@ -4850,20 +4852,17 @@ sub git_tree {
}
sub git_snapshot {
- my @supported_fmts = gitweb_check_feature('snapshot');
- @supported_fmts = filter_snapshot_fmts(@supported_fmts);
-
my $format = $input_params{'snapshot_format'};
- if (!@supported_fmts) {
+ if (!@snapshot_fmts) {
die_error(403, "Snapshots not allowed");
}
# default to first supported snapshot format
- $format ||= $supported_fmts[0];
+ $format ||= $snapshot_fmts[0];
if ($format !~ m/^[a-z0-9]+$/) {
die_error(400, "Invalid snapshot format parameter");
} elsif (!exists($known_snapshot_formats{$format})) {
die_error(400, "Unknown snapshot format");
- } elsif (!grep($_ eq $format, @supported_fmts)) {
+ } elsif (!grep($_ eq $format, @snapshot_fmts)) {
die_error(403, "Unsupported snapshot format");
}
--
1.5.6.5
^ permalink raw reply related
* [PATHv3 0/3] PATH_INFO snapshot formats
From: Giuseppe Bilotta @ 2008-11-02 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
The following three patches allow gitweb to read (and emit) PATH_INFO
URLs with embedded snapshot_format information. This eliminates one
for CGI parameter when PATH_INFO is enabled, and also offers a more
user-friendly URL for snapshots.
The first patch is actually rather independent from the other two: it
collects the definition (and calculation) of the array of allowed
snapshot into a global variable.
Giuseppe Bilotta (3):
gitweb: make the supported snapshot formats array global
gitweb: retrieve snapshot format from PATH_INFO
gitweb: embed snapshot format parameter in PATH_INFO
gitweb/gitweb.perl | 70 ++++++++++++++++++++++++++++++++++++++++++++++------
1 files changed, 62 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: libgit2 - a true git library
From: Pierre Habouzit @ 2008-11-02 9:19 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andreas Ericsson, git, Scott Chacon
In-Reply-To: <20081101204259.GC15463@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]
On Sat, Nov 01, 2008 at 08:42:59PM +0000, Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
> > Shawn O. Pearce wrote:
> >> During the GitTogether we were kicking around the idea of a ground-up
> >> implementation of a Git library.
> >
> > Having looked briefly at the code, I've got a couple of comments:
> > * GIT_EXTERN() does nothing. Ever. It's noise and should be removed.
>
> I feel the same way.
>
> But I was also under the impression that the brilliant engineers
> who work for Microsoft decided that on their platform special
> annotations have to be inserted on functions that a DLL wants to
> export to applications.
>
> Hence any cross-platform library that I have seen annotates their
> exported functions this way, with the macro being empty on POSIX
> and expanding to some magic keyword on Microsoft's OS. I think it
> goes between the return type and the function name too...
>
> > Instead it would be better to have GIT_PRIVATE(),
>
> I can see why you said this; needing GIT_PRIVATE() is a lot more
> rare than needing GIT_EXTERN(). Only a handful of cross-module,
> but private, functions are likely to exist, so it makes sense to
> mark the smaller subset. But see above. *sigh*
Not only there is the windows thing, but the *best* way to design a
library is to make _everything_ by default and only show what you mean
to.
GIT_EXTERN allow us to do just that with
__attribute__((visibility("default"))) on GNU-ld/GCC.
Of course we can achieve the same using nothing on public symbols and
__attribute__((visibility("hidden"))) on the private ones, but it's way
more cumbersome and there's always a chance to forget one. It's bad
design IMHO.
FWIW GIT_EXTERN(...) prototype(arguments); isn't unredable to me,
everyone does that, it doesn't break tags, it's _good_. And you can ask
doxygen to substitute this GIT_EXTERN(x) with x so that it doesn't shows
up in the documentation at all (it can include these kind of partially
preprocessed headers in the documentation) for the people who are really
annoyed with them.
But it's definitely a necessary evil.
--
·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] add instructions on how to send patches to the mailing list with Gmail
From: Pierre Habouzit @ 2008-11-02 9:10 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: Santi Béjar, git, Junio C Hamano
In-Reply-To: <b97024a40811011340s92a1c24jb81b75dfb25e43c5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2030 bytes --]
On Sat, Nov 01, 2008 at 08:40:27PM +0000, Tom Preston-Werner wrote:
> On Sat, Nov 1, 2008 at 3:00 AM, Santi Béjar <santi@agolina.net> wrote:
> > On Sat, Nov 1, 2008 at 8:28 AM, Tom Preston-Werner <tom@github.com> wrote:
> >> Gmail is one of the most popular email providers in the world. Now that Gmail
> >> supports IMAP, sending properly formatted patches via `git imap-send` is
> >> trivial. This section in SubmittingPatches explains how to do so.
> >>
> >> Signed-off-by: Tom Preston-Werner <tom@github.com>
> >> ---
> >> Documentation/SubmittingPatches | 27 +++++++++++++++++++++++++++
> >> 1 files changed, 27 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> >> index a1e9100..f0295c6 100644
> >> --- a/Documentation/SubmittingPatches
> >> +++ b/Documentation/SubmittingPatches
> >> @@ -456,3 +456,30 @@ This should help you to submit patches inline using KMail.
> >>
> >> 5) Back in the compose window: add whatever other text you wish to the
> >> message, complete the addressing and subject fields, and press send.
> >> +
> >> +
> >> +Gmail
> >> +-----
> >> +
> >> +Submitting properly formatted patches via Gmail is simple now that
> >> +IMAP support is available. First, edit your ~/.gitconfig to specify your
> >> +account settings:
> >> +
> >> +[imap]
> >> + folder = "[Gmail]/Drafts"
> >> + host = imaps://imap.gmail.com
> >> + user = user@gmail.com
> >> + pass = p4ssw0rd
> >> + port = 993
> >> + sslverify = false
> >
> > 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)
--
·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: [PATHv2 8/8] gitweb: make the supported snapshot formats array global
From: Junio C Hamano @ 2008-11-02 8:50 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jakub Narebski, git, Petr Baudis
In-Reply-To: <200811020255.01895.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Very good idea, although I'd prefer for this patch to come first;
> it is not controversial contrary to other patches in this (sub)series
> which IMHO needs some thought first.
>
> Acked-by: Jakub Narebski <jnareb@gmail.com>
I've dismissed the three patches 6-8 (without prejudice, as I lost track
of them); please resubmit and re-ack.
^ permalink raw reply
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-02 8:30 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, David Symonds, git, gitster, Stephan Beyer
In-Reply-To: <20081029171122.GA12167@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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)
A flag "--staged" that means "staged changes and changes in the work tree"
is no worse than the current "--index". If we were to shoot for clarity,
how about --staged-only (aka --cached) vs --staged-and-unstaged (aka --index)?
I am actually actively unhappy about the latter, but I like more
descriptive --staged-only for the former a lot better.
^ permalink raw reply
* Re: [PATCH] autoconf: Add link tests to each AC_CHECK_FUNC() test
From: Junio C Hamano @ 2008-11-02 8:04 UTC (permalink / raw)
To: David M. Syzdek; +Cc: git, jnareb
In-Reply-To: <1225021939-11858-1-git-send-email-david.syzdek@acsalaska.net>
"David M. Syzdek" <david.syzdek@acsalaska.net> writes:
> Update configure.ac to test libraries for getaddrinfo, strcasestr, memmem,
> strlcpy, strtoumax, setenv, unsetenv, and mkdtemp. The default compilers
> on FreeBSD 4.9-SECURITY and FreeBSD 6.2-RELEASE-p4 do not generate warnings
> for missing prototypes unless `-Wall' is used. This behavior renders the
> results of AC_CHECK_FUNC() void on these platforms. The test AC_SEARCH_LIBS()
> verifies a function is valid by linking to symbol within the system libraries.
> diff --git a/configure.ac b/configure.ac
> index 7c2856e..d3b8bc3 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -293,9 +293,11 @@ AC_SUBST(NO_SOCKADDR_STORAGE)
> #
> # Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
> AC_CHECK_TYPE([struct addrinfo],[
> - AC_CHECK_FUNC([getaddrinfo],
> - [NO_IPV6=],
> - [NO_IPV6=YesPlease])
> + AC_CHECK_FUNC([getaddrinfo],[
> + AC_SEARCH_LIBS([getaddrinfo],,
> + [NO_IPV6=],
> + [NO_IPV6=YesPlease])
> + ],[NO_IPV6=YesPlease])
It's been a looong time since I did any sizeable autoconf/m4 hacking, but
the repetitititiveness of this patch loudly calls for a convenience macro
of a higher order, perhaps something like:
AC_DEFUN([GIT_CHECK_FUNC],[
AC_CHECK_FUNC([$1],[
AC_SEARCH_LIBS([$1},,
[$2],[$3])],
[$3])])
Then we can use it like:
GIT_CHECK_FUNC([getaddrinfo],[NO_IPV6=],[NO_IPV6=YesPlease])
Hmm?
-- >8 --
[PATCH] autoconf: use AC_CHECK_FUNC() with AC_SEARCH_LIBS() test
Update configure.ac to test libraries for getaddrinfo, strcasestr, memmem,
strlcpy, strtoumax, setenv, unsetenv, and mkdtemp. The default compilers
on FreeBSD 4.9-SECURITY and FreeBSD 6.2-RELEASE-p4 do not generate warnings
for missing prototypes unless `-Wall' is used. This behavior renders the
results of AC_CHECK_FUNC() void on these platforms. The test AC_SEARCH_LIBS()
verifies a function is valid by linking to symbol within the system libraries.
---
configure.ac | 28 +++++++++++++++++++---------
1 files changed, 19 insertions(+), 9 deletions(-)
diff --git c/configure.ac w/configure.ac
index 27bab00..ef544e8 100644
--- c/configure.ac
+++ w/configure.ac
@@ -65,7 +65,17 @@ else \
fi \
])# GIT_PARSE_WITH
-
+dnl
+dnl GIT_CHECK_FUNC(FUNCTION, IFTRUE, IFFALSE)
+dnl -----------------------------------------
+dnl Similar to AC_CHECK_FUNC, but on systems that do not generate
+dnl warnings for missing prototypes (e.g. FreeBSD when compiling without
+dnl -Wall), it does not work. By looking for function definition in
+dnl libraries, this problem can be worked around.
+AC_DEFUN([GIT_CHECK_FUNC],[AC_CHECK_FUNC([$1],[
+ AC_SEARCH_LIBS([$1],,
+ [$2],[$3])
+],[$3])])
## Site configuration related to programs (before tests)
## --with-PACKAGE[=ARG] and --without-PACKAGE
#
@@ -325,7 +335,7 @@ AC_SUBST(NO_SOCKADDR_STORAGE)
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
AC_CHECK_TYPE([struct addrinfo],[
- AC_CHECK_FUNC([getaddrinfo],
+ GIT_CHECK_FUNC([getaddrinfo],
[NO_IPV6=],
[NO_IPV6=YesPlease])
],[NO_IPV6=YesPlease],[
@@ -419,43 +429,43 @@ AC_SUBST(SNPRINTF_RETURNS_BOGUS)
AC_MSG_NOTICE([CHECKS for library functions])
#
# Define NO_STRCASESTR if you don't have strcasestr.
-AC_CHECK_FUNC(strcasestr,
+GIT_CHECK_FUNC(strcasestr,
[NO_STRCASESTR=],
[NO_STRCASESTR=YesPlease])
AC_SUBST(NO_STRCASESTR)
#
# Define NO_MEMMEM if you don't have memmem.
-AC_CHECK_FUNC(memmem,
+GIT_CHECK_FUNC(memmem,
[NO_MEMMEM=],
[NO_MEMMEM=YesPlease])
AC_SUBST(NO_MEMMEM)
#
# Define NO_STRLCPY if you don't have strlcpy.
-AC_CHECK_FUNC(strlcpy,
+GIT_CHECK_FUNC(strlcpy,
[NO_STRLCPY=],
[NO_STRLCPY=YesPlease])
AC_SUBST(NO_STRLCPY)
#
# Define NO_STRTOUMAX if you don't have strtoumax in the C library.
-AC_CHECK_FUNC(strtoumax,
+GIT_CHECK_FUNC(strtoumax,
[NO_STRTOUMAX=],
[NO_STRTOUMAX=YesPlease])
AC_SUBST(NO_STRTOUMAX)
#
# Define NO_SETENV if you don't have setenv in the C library.
-AC_CHECK_FUNC(setenv,
+GIT_CHECK_FUNC(setenv,
[NO_SETENV=],
[NO_SETENV=YesPlease])
AC_SUBST(NO_SETENV)
#
# Define NO_UNSETENV if you don't have unsetenv in the C library.
-AC_CHECK_FUNC(unsetenv,
+GIT_CHECK_FUNC(unsetenv,
[NO_UNSETENV=],
[NO_UNSETENV=YesPlease])
AC_SUBST(NO_UNSETENV)
#
# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
-AC_CHECK_FUNC(mkdtemp,
+GIT_CHECK_FUNC(mkdtemp,
[NO_MKDTEMP=],
[NO_MKDTEMP=YesPlease])
AC_SUBST(NO_MKDTEMP)
^ permalink raw reply related
* Re: [PATCH 1/3] Fix error in diff_filepair::status documentation.
From: Junio C Hamano @ 2008-11-02 6:31 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20081101220314.1116.79924.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> Signed-off-by: Yann Dirson <ydirson@altern.org>
> ---
>
> diffcore.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/diffcore.h b/diffcore.h
> index 713cca7..05d0898 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 DIFF_STATUS_* in diff.h) */
I think you spotted the right bug and fixed it in a wrong way. The status
letters are user visible, and "git grep status Documentation/*diff*"
mention it in handful places without listing its repertoire, which _is_
the bug.
^ permalink raw reply
* Re: [PATCH 3/3] git send-email: add --annotate option
From: Junio C Hamano @ 2008-11-02 6:23 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225450632-7230-4-git-send-email-madcoder@debian.org>
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?
^ permalink raw reply
* Re: [PATCH 1/3] git send-email: make the message file name more specific.
From: Junio C Hamano @ 2008-11-02 6:18 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225456609-694-2-git-send-email-madcoder@debian.org>
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.
Having said that, if we were to do this, let's do it the right way and put
these "temporary" files under $GIT_DIR.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> git-send-email.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 65c254d..4ca571f 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -127,7 +127,7 @@ sub unique_email_list(@);
> sub cleanup_compose_files();
>
> # Constants (essentially)
> -my $compose_filename = ".msg.$$";
> +my $compose_filename = ".gitsendemail.msg.$$";
>
> # Variables we fill in automatically, or via prompting:
> my (@to,@cc,@initial_cc,@bcclist,@xh,
> --
> 1.6.0.3.763.g0275.dirty
>
> --
> 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: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Junio C Hamano @ 2008-11-02 6:08 UTC (permalink / raw)
To: Theodore Tso; +Cc: Pierre Habouzit, Sam Vilain, git, Sam Vilain
In-Reply-To: <20081030163056.GA8899@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> On Thu, Oct 30, 2008 at 03:43:21PM +0100, Pierre Habouzit wrote:
>>
>> git format-patch origin/next.. works already. I'm used to the asymetric
>> git format-patch origin/next syntax, and I would be sorry if it
>> disappeared though, and I see no really good reason to get rid of it.
>
> The reason why it annoys me is because I often what to cherry-pick a
> single patch to send to someone, and so while "git show 332d2e78"
> shows me the patch, but if I want to use git-send-email for that
> particular patch, "git format-patch 332d2e78" doesn't DTRT. I have to
> type "git format-patch 332d2e78^..332d2e78" instead.
> ...
> (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.
^ permalink raw reply
* Re: git reset --hard w/o touching every file
From: Jeff King @ 2008-11-02 5:52 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <gejanr$os$1@ger.gmane.org>
On Sun, Nov 02, 2008 at 12:36:09AM -0400, Edward Z. Yang wrote:
> I'm using a script to automatically update a website with the contents
> of a Git repository at a specified interval. While I could use git pull,
> I've been told that it's safer to do a git fetch, and then a git reset
> --hard remotes/master, because the former could trigger a merge and on a
> live website that is NOT desirable.
Well, there will never be a merge if you aren't making local changes
(and your upstream is not doing silly things like rewinding the history of
what it gives you). But if you aren't making local changes, then doing a
reset is "safe" in the sense that you will have nothing to throw away.
> Unfortunately, since Git touches all files on a reset --hard, it's
> causing problems with the smart cache system, which checks whether or
> not the cache file is older than the source file, and regenerating if
> it is.
Ah, OK. I see what you want.
Git usually tries very hard not to touch files that don't need to be
touched. So that sounds like a bug. However, I can't reproduce it with
this test case:
mkdir repo && cd repo && git init &&
touch a b && git add a b && git commit -m added &&
echo changes >a && git commit -a -m 'changed a' &&
touch -d 1979-10-12 a b && echo before reset && ls -l a b &&
git update-index --refresh &&
git reset --hard HEAD^ && echo after reset && ls -l a b
I end up with:
before reset
-rw-r--r-- 1 peff peff 8 1979-10-12 00:00 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
HEAD is now at d7fd84e added
after reset
-rw-r--r-- 1 peff peff 0 2008-11-02 01:46 a
-rw-r--r-- 1 peff peff 0 1979-10-12 00:00 b
which makes sense. The only tricky thing is the "update-index --refresh"
call, which basically tells git "update your cache with the new mtime
value", which is necessary because of the contrived use of "touch". But
if you are manipulating these files only through "git reset", it should
Just Work.
-Peff
^ permalink raw reply
* Re: libgit2 - a true git library
From: David Brown @ 2008-11-02 5:09 UTC (permalink / raw)
To: Scott Chacon; +Cc: Shawn O. Pearce, Nicolas Pitre, Pierre Habouzit, david, git
In-Reply-To: <d411cc4a0811011807g229f8becs9f411d6e19fb6c12@mail.gmail.com>
On Sat, Nov 01, 2008 at 06:07:04PM -0700, Scott Chacon wrote:
>Think about trying to incorporate this into something proprietary,
>Shawn - how much of a pain is it going to be to get that license
>reviewed in Google? However, LGPL I'm sure there is already a
>reviewed policy. Now, since that may be a pain, time that Shawn could
>have been spending being paid to work on the library is lost because
>they can't use it, or it takes weeks/months to review it. That's my
>concern.
The gcc exception license should have been reviewed by anyone who has
ever build anything proprietary out of gcc.
GPL+link exception is a very common license. It's most common use is
for runtime libraries for various programming languages.
Lawyers I know are significantly less fearful of the GPL+exception
than the LGPL. The exception basically says that if you use it in a
certain way, then none of the GPL applies.
David
^ permalink raw reply
* Re: [PATCH] prepare deprecation of git-revert
From: Jeff King @ 2008-11-02 4:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1225468527-29694-1-git-send-email-madcoder@debian.org>
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.
-Peff
^ 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