* Re: [ANNOUNCE] Git homepage change
From: Baz @ 2009-01-06 2:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: David Bryson, Mike Hommey, git
In-Reply-To: <2faad3050901051817g1381478ex9f5cb6f0404e5f86@mail.gmail.com>
2009/1/6 Baz <brian.ewins@gmail.com>:
> 2009/1/6 Scott Chacon <schacon@gmail.com>:
>> Hi,
>>
>> On Mon, Jan 5, 2009 at 1:27 PM, David Bryson <david@statichacks.org> wrote:
>>> On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>>>>
>>>> FWIW, I think the "mascot" or whatever it is supposed to be, on the
>>>> top right end, is "safe", trademark/copyright-wise. It looks too much
>>>> like ???????????????(D??mo-kun), the NHK mascot.
>>>> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
>>>
>>> I think Scott mentioned at GitTogether that they paid the same artist
>>> design some artwork for them including that tree munching monster and an
>>> octopus.
>>>
>>> Scott do you care to elaborate ?
>>
>> I bought rights to the image from iStockPhoto, we can use it online
>> for whatever we want to. The only restriction is that we can't sell
>> stuff with the image on it. I have no idea what NHK is, nor do I know
>> how TM/copyright issues would work in this regard - (the site is
>> hosted in the US, has NHK registered TM for that here?) - but I doubt
>> it really matters. If I get a cease and desist, I'll replace the
>> image, but to me it doesn't seem close enough to infringe and I doubt
>> they would care.
>
> NHK are the public broadcaster in Japan, and Domo-kun is their mascot.
> Apparently the NHK spots with Domo-kun are also used in the US on
> Nickelodeon. It's like the NBC peacock, or the BBC test card girl:
> instantly recognizable to anyone who watched that channel.
>
> And yes, there is a US trademark:
> http://tess2.uspto.gov/bin/showfield?f=doc&state=3pcqf.6.1
Sorry, that link uses cookie state. Here's one directly to the TM:
http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=77266968
>
> No connection to NHK at all, but I thought you'd used Domo
> deliberately when I first saw that logo, so got curious. The site is
> great, btw.
>
> Cheers,
> Baz
>
>>
>> Btw, I would also like to say in general that the response to this
>> from emails sent to me personally (my address is at the bottom of the
>> page) has been very positive and I've even received a few patches that
>> are now live.
>>
>> Also, Miklos : your patch changes the format of the output and doesn't
>> speed things up or anything, so I'm just sticking with the current
>> script for now (unless I'm missing something).
>>
>> Boyd Gerber: I'm confused - the mailing list archive link on the home
>> page points to the Gmane page, which is completely up to date. Is
>> there a link I'm missing?
>>
>> Thanks,
>> Scott
>>
>>>
>>> Dave
>>>
>>>
>> --
>> 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
* [PATCH] Documentation/gitcore-tutorial.txt: HEAD not symlink these days
From: jidanni @ 2009-01-06 2:18 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/gitcore-tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index e4dd551..05328cf 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -751,7 +751,7 @@ Creating a new branch
Branches in git are really nothing more than pointers into the git
object database from within the `.git/refs/` subdirectory, and as we
-already discussed, the `HEAD` branch is nothing but a symlink to one of
+already discussed, the `HEAD` branch is nothing but a pointer to one of
these object pointers.
You can at any time create a new branch by just picking an arbitrary
--
1.6.0.6
^ permalink raw reply related
* Re: [ANNOUNCE] Git homepage change
From: Baz @ 2009-01-06 2:17 UTC (permalink / raw)
To: Scott Chacon; +Cc: David Bryson, Mike Hommey, git
In-Reply-To: <d411cc4a0901051749p2ef880bub45bba1c0d41bfc7@mail.gmail.com>
2009/1/6 Scott Chacon <schacon@gmail.com>:
> Hi,
>
> On Mon, Jan 5, 2009 at 1:27 PM, David Bryson <david@statichacks.org> wrote:
>> On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>>>
>>> FWIW, I think the "mascot" or whatever it is supposed to be, on the
>>> top right end, is "safe", trademark/copyright-wise. It looks too much
>>> like ???????????????(D??mo-kun), the NHK mascot.
>>> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
>>
>> I think Scott mentioned at GitTogether that they paid the same artist
>> design some artwork for them including that tree munching monster and an
>> octopus.
>>
>> Scott do you care to elaborate ?
>
> I bought rights to the image from iStockPhoto, we can use it online
> for whatever we want to. The only restriction is that we can't sell
> stuff with the image on it. I have no idea what NHK is, nor do I know
> how TM/copyright issues would work in this regard - (the site is
> hosted in the US, has NHK registered TM for that here?) - but I doubt
> it really matters. If I get a cease and desist, I'll replace the
> image, but to me it doesn't seem close enough to infringe and I doubt
> they would care.
NHK are the public broadcaster in Japan, and Domo-kun is their mascot.
Apparently the NHK spots with Domo-kun are also used in the US on
Nickelodeon. It's like the NBC peacock, or the BBC test card girl:
instantly recognizable to anyone who watched that channel.
And yes, there is a US trademark:
http://tess2.uspto.gov/bin/showfield?f=doc&state=3pcqf.6.1
No connection to NHK at all, but I thought you'd used Domo
deliberately when I first saw that logo, so got curious. The site is
great, btw.
Cheers,
Baz
>
> Btw, I would also like to say in general that the response to this
> from emails sent to me personally (my address is at the bottom of the
> page) has been very positive and I've even received a few patches that
> are now live.
>
> Also, Miklos : your patch changes the format of the output and doesn't
> speed things up or anything, so I'm just sticking with the current
> script for now (unless I'm missing something).
>
> Boyd Gerber: I'm confused - the mailing list archive link on the home
> page points to the Gmane page, which is completely up to date. Is
> there a link I'm missing?
>
> Thanks,
> Scott
>
>>
>> Dave
>>
>>
> --
> 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: [ANNOUNCE] Git homepage change
From: Scott Chacon @ 2009-01-06 1:49 UTC (permalink / raw)
To: David Bryson; +Cc: Mike Hommey, git
In-Reply-To: <20090105212716.GJ6595@eratosthenes.cryptobackpack.org>
Hi,
On Mon, Jan 5, 2009 at 1:27 PM, David Bryson <david@statichacks.org> wrote:
> On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>>
>> FWIW, I think the "mascot" or whatever it is supposed to be, on the
>> top right end, is "safe", trademark/copyright-wise. It looks too much
>> like ???????????????(D??mo-kun), the NHK mascot.
>> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
>
> I think Scott mentioned at GitTogether that they paid the same artist
> design some artwork for them including that tree munching monster and an
> octopus.
>
> Scott do you care to elaborate ?
I bought rights to the image from iStockPhoto, we can use it online
for whatever we want to. The only restriction is that we can't sell
stuff with the image on it. I have no idea what NHK is, nor do I know
how TM/copyright issues would work in this regard - (the site is
hosted in the US, has NHK registered TM for that here?) - but I doubt
it really matters. If I get a cease and desist, I'll replace the
image, but to me it doesn't seem close enough to infringe and I doubt
they would care.
Btw, I would also like to say in general that the response to this
from emails sent to me personally (my address is at the bottom of the
page) has been very positive and I've even received a few patches that
are now live.
Also, Miklos : your patch changes the format of the output and doesn't
speed things up or anything, so I'm just sticking with the current
script for now (unless I'm missing something).
Boyd Gerber: I'm confused - the mailing list archive link on the home
page points to the Gmane page, which is completely up to date. Is
there a link I'm missing?
Thanks,
Scott
>
> Dave
>
>
^ permalink raw reply
* Re: git documentation
From: Miklos Vajna @ 2009-01-06 1:46 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901051745280.28514@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Mon, Jan 05, 2009 at 05:46:56PM -0800, david@lang.hm wrote:
> why. Yet probably there is no line of documentation on the Git site or
> elsewhere that I can quote to justify adding a "Yes" to the comparison.
I think it's documented in Documentation/merge-strategies.txt, under the
'recursive' merge strategy:
"Additionally this can detect and handle merges involving renames."
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Documentation/git-rebase.txt: effect of Control-C interrupt
From: jidanni @ 2009-01-06 1:17 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-rebase.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index c8ad86a..91ca138 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -210,6 +210,9 @@ OPTIONS
--abort::
Restore the original branch and abort the rebase operation.
+ (If you interrupt a rebase with control-C, you will still have
+ to issue a subsequent git rebase --abort to restore the
+ initial state.)
--skip::
Restart the rebasing process by skipping the current patch.
--
1.6.0.6
^ permalink raw reply related
* Re: git documentation
From: Jakub Narebski @ 2009-01-06 1:07 UTC (permalink / raw)
To: David Lang; +Cc: git, Alexey Mahotkin
In-Reply-To: <alpine.DEB.1.10.0901051745280.28514@asgard.lang.hm>
David Lang <david@lang.hm> writes:
> On lwn there is a comment (under the GNOME survey topic)
> http://lwn.net/Articles/313435/
>
> The Shlomi Fish "Better SCM" site for example is very clear that Git
> won't do a merge across a rename. It even has a citation for this
> claim. But as a Git user who has actually done a merge across a rename
> I know it works just fine, and anyone familiar with Git's internals
> will guess immediately why. Yet probably there is no line of
> documentation on the Git site or elsewhere that I can quote to justify
> adding a "Yes" to the comparison.
I have tried to add info about Git to Better SCM quite a long time
ago; it was finally added by (IIRC) Alexey Mahotkin for
http://versioncontrolblog.com and sent for inclusion in Better SCM to
Shlomi Fish.
Unfortunately it contains some factual errors. I have sent corrections
to Alexey, but didn't finish it:
"Git at Better SCM Initiative comparison of VCS (long)"
http://article.gmane.org/gmane.comp.version-control.git/97253
(see also other posts in this thread, and other posts with the same,
or similar, subject on git mailing list).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Documentation/urls-remotes.txt: Multiple fetch lines are allowed
From: jidanni @ 2009-01-06 1:06 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/urls-remotes.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 41ec777..d38f189 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -22,7 +22,7 @@ or even by a manual edit to the `$GIT_DIR/config` file. The URL of
this remote will be used to access the repository. The refspec
of this remote will be used by default when you do
not provide a refspec on the command line. The entry in the
-config file would appear like this:
+config file would appear as below. Multiple fetch lines are allowed.
------------
[remote "<name>"]
--
1.6.0.6
^ permalink raw reply related
* Re: [EGIT PATCH] Fixed trivial warnings. Mainly parametrized raw types, added serialVersionUID, removed unnecessery throws.
From: Robin Rosenberg @ 2009-01-06 0:54 UTC (permalink / raw)
To: Vasyl' Vavrychuk; +Cc: git
In-Reply-To: <gjrgip$al9$1@ger.gmane.org>
måndag 05 januari 2009 00:26:02 skrev Vasyl' Vavrychuk:
> Not sure what is right:
> public abstract class AnyObjectId implements Comparable<ObjectId> {
> or
> public abstract class AnyObjectId implements Comparable<AnyObjectId> {
>
> IMHO second, but class AnyObjectId contains some compareTo(ObjectId).
>
> Also not sure if this bunch of changes is complete enough. Maybe it's better to make more fixes in this direction and then commit.
I broke up the patch and applied it just to be nice, with the exception of this change.
-- robin
^ permalink raw reply
* git merge failure: what next?
From: Daniel Quinlan @ 2009-01-06 0:41 UTC (permalink / raw)
To: git
I cannot figure out how to resolve a problem with git merge.
I usually use "git pull" to merge changes from a central repository
before pushing local changes to the central repository.
I've learned from bitter experience not to have changes in the
intermediate cache/stage/index, since that always leads to
confusion -- but it's possible I failed to follow that rule in this
case.
The working tree is currently dirty with lots of changes I'm not ready
to commit.
Anyway, now I get this:
> % git pull
> *** : needs update
> .
> .
> fatal: Entry 'correct/orblag/orblag' would be overwritten by merge.
> Cannot merge.
> Merge with strategy recursive failed.
> %
>
At this point, I usually do something like remove the 'correct/orblag/
orblag', knowing that I just want
whatever is in the repository (or ultimately, not caring, provided I
can get past this message).
However, that doesn't work:
> % rm correct/orblag/orblag
> rm: cannot remove `correct/orblag/orblag': No such file or directory
>
Also,
> % git mergetool
> No files need merging
>
I'm stuck.
A related problem is that although I'm usually able to get past this
problem by deleting
a file, this can be tedious as there may be multiple files with
conflicts, but git-merge only
lets me know about the first one it finds. Knowing all the conflicts
right off the bat would
give me an idea about the breadth of the problem.
Another possibility I might like to see is the CVS approach -- just
create combined files
with all the differences in them instead of hanging up on the first
conflict.
Suggestions?
Thanks,
-- danq
^ permalink raw reply
* Re: [EGIT PATCH] Sorting commit items by click on the table header in commit dialog.
From: Robin Rosenberg @ 2009-01-06 0:49 UTC (permalink / raw)
To: Vasyl' Vavrychuk; +Cc: Shawn O. Pearce, git
In-Reply-To: <200901050835.20038.robin.rosenberg.lists@dewire.com>
Seems this was trivial to apply after patchin the patch, so I did.
-- robin
^ permalink raw reply
* git documentation
From: david @ 2009-01-06 1:46 UTC (permalink / raw)
To: git
on lwn there is a comment (under the GNOME survey topic)
http://lwn.net/Articles/313435/
The Shlomi Fish "Better SCM" site for example is very clear that Git won't
do a merge across a rename. It even has a citation for this claim. But as
a Git user who has actually done a merge across a rename I know it works
just fine, and anyone familiar with Git's internals will guess immediately
why. Yet probably there is no line of documentation on the Git site or
elsewhere that I can quote to justify adding a "Yes" to the comparison.
sounds like a missing piece of documentation that someone should be able
to fill in fairly easily.
David Lang
^ permalink raw reply
* Re: gitweb: removal of old style blobdiff support breaks ikiwiki
From: Jeff King @ 2009-01-06 0:25 UTC (permalink / raw)
To: Joey Hess; +Cc: Gerrit Pape, git
In-Reply-To: <20090105235418.GA9373@gnu.kitenet.net>
On Mon, Jan 05, 2009 at 06:54:18PM -0500, Joey Hess wrote:
> I wonder if it wouldn't be better to make gitweb continue to support the
> old urls, using diff-tree instead of the porcelain?
It can't; there is currently no interface for diffing two arbitrary
blobs except "git diff". The simplest fix to retain functionality but
plug the hole is to pass --no-ext-diff to all versions, and
--no-textconv to versions which have textconv (i.e., 1.6.1 and later).
IIRC, there is a problem with --no-ext-diff in some versions, so that
fix might have to be backported, too.
-Peff
^ permalink raw reply
* [PATCH] parse-opt: migrate builtin-ls-files.
From: Miklos Vajna @ 2009-01-06 0:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
option_parse_ignored(), option_parse_directory() and
option_parse_no_empty() callbacks are necessary because
dir->show_ignored, dir->show_other_directories and
dir->hide_empty_directories are bitfields in struct dir_struct. Maybe it
would worth just removing them, but I did not want to touch dir.h just
because of parseopt.
builtin-ls-files.c | 294 ++++++++++++++++++++++++++++------------------------
1 files changed, 159 insertions(+), 135 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index f72eb85..a2f3de4 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -10,6 +10,7 @@
#include "dir.h"
#include "builtin.h"
#include "tree.h"
+#include "parse-options.h"
static int abbrev;
static int show_deleted;
@@ -28,6 +29,7 @@ static const char **pathspec;
static int error_unmatch;
static char *ps_matched;
static const char *with_tree;
+static int exc_given;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -395,156 +397,178 @@ int report_path_error(const char *ps_matched, const char **pathspec, int prefix_
return errors;
}
-static const char ls_files_usage[] =
- "git ls-files [-z] [-t] [-v] (--[cached|deleted|others|stage|unmerged|killed|modified])* "
- "[ --ignored ] [--exclude=<pattern>] [--exclude-from=<file>] "
- "[ --exclude-per-directory=<filename> ] [--exclude-standard] "
- "[--full-name] [--abbrev] [--] [<file>]*";
+static const char * const ls_files_usage[] = {
+ "git ls-files [options] [<file>]*",
+ NULL
+};
+
+static int option_parse_z(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (unset)
+ line_terminator = '\n';
+ else
+ line_terminator = 0;
+ return 0;
+}
+
+static int option_parse_exclude(const struct option *opt,
+ const char *arg, int unset)
+{
+ struct dir_struct *dir = opt->value;
+
+ exc_given = 1;
+ add_exclude(arg, "", 0, &dir->exclude_list[EXC_CMDL]);
+
+ return 0;
+}
+
+static int option_parse_exclude_from(const struct option *opt,
+ const char *arg, int unset)
+{
+ struct dir_struct *dir = opt->value;
+
+ exc_given = 1;
+ add_excludes_from_file(dir, arg);
+
+ return 0;
+}
+
+static int option_parse_exclude_standard(const struct option *opt,
+ const char *arg, int unset)
+{
+ struct dir_struct *dir = opt->value;
+
+ exc_given = 1;
+ setup_standard_excludes(dir);
+
+ return 0;
+}
+
+static int option_parse_ignored(const struct option *opt,
+ const char *arg, int unset)
+{
+ struct dir_struct *dir = opt->value;
+
+ dir->show_ignored = 1;
+
+ return 0;
+}
+
+static int option_parse_directory(const struct option *opt,
+ const char *arg, int unset)
+{
+ struct dir_struct *dir = opt->value;
+
+ dir->show_other_directories = 1;
+
+ return 0;
+}
+
+static int option_parse_no_empty(const struct option *opt,
+ const char *arg, int unset)
+{
+ struct dir_struct *dir = opt->value;
+
+ dir->hide_empty_directories = 1;
+
+ return 0;
+}
+
+static int option_parse_full_name(const struct option *opt,
+ const char *arg, int unset)
+{
+ prefix_offset = 0;
+
+ return 0;
+}
int cmd_ls_files(int argc, const char **argv, const char *prefix)
{
- int i;
- int exc_given = 0, require_work_tree = 0;
+ int require_work_tree = 0, show_tag = 0;
struct dir_struct dir;
+ struct option builtin_ls_files_options[] = {
+ { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
+ "paths are separated with NUL character",
+ PARSE_OPT_NOARG, option_parse_z },
+ OPT_BOOLEAN('t', NULL, &show_tag,
+ "identify the file status with tags"),
+ OPT_BOOLEAN('v', NULL, &show_valid_bit,
+ "use lowercase letters for 'assume unchanged' files"),
+ OPT_BOOLEAN('c', "cached", &show_cached,
+ "show cached files in the output (default)"),
+ OPT_BOOLEAN('d', "deleted", &show_deleted,
+ "show deleted files in the output"),
+ OPT_BOOLEAN('m', "modified", &show_modified,
+ "show modified files in the output"),
+ OPT_BOOLEAN('o', "others", &show_others,
+ "show other files in the output"),
+ { OPTION_CALLBACK, 'i', "ignored", &dir, NULL,
+ "show ignored files in the output",
+ PARSE_OPT_NOARG, option_parse_ignored },
+ OPT_BOOLEAN('s', "stage", &show_stage,
+ "show staged contents' object name in the output"),
+ OPT_BOOLEAN('k', "killed", &show_killed,
+ "show files on the filesystem that need to be removed"),
+ { OPTION_CALLBACK, 0, "directory", &dir, NULL,
+ "show 'other' directories' name only",
+ PARSE_OPT_NOARG, option_parse_directory },
+ { OPTION_CALLBACK, 0, "no-empty-directory", &dir, NULL,
+ "do not list empty directories",
+ PARSE_OPT_NOARG, option_parse_no_empty },
+ OPT_BOOLEAN('u', "unmerged", &show_unmerged,
+ "show unmerged files in the output"),
+ { OPTION_CALLBACK, 'x', "exclude", &dir, "pattern",
+ "skip files matching pattern",
+ 0, option_parse_exclude },
+ { OPTION_CALLBACK, 'X', "exclude-from", &dir, "file",
+ "exclude patterns are read from <file>",
+ 0, option_parse_exclude_from },
+ OPT_STRING(0, "exclude-per-directory", &dir.exclude_per_dir, "file",
+ "read additional per-directory exclude patterns in <file>"),
+ { OPTION_CALLBACK, 0, "exclude-standard", &dir, NULL,
+ "add the standard git exclusions",
+ PARSE_OPT_NOARG, option_parse_exclude_standard },
+ { OPTION_CALLBACK, 0, "full-name", NULL, NULL,
+ "make the output relative to the project top directory",
+ PARSE_OPT_NOARG, option_parse_full_name },
+ OPT_BOOLEAN(0, "error-unmatch", &error_unmatch,
+ "if any <file> is not in the index, treat this as an error"),
+ OPT_STRING(0, "with-tree", &with_tree, "tree-ish",
+ "pretend that paths removed since <tree-ish> are still present"),
+ OPT__ABBREV(&abbrev),
+ OPT_END()
+ };
memset(&dir, 0, sizeof(dir));
if (prefix)
prefix_offset = strlen(prefix);
git_config(git_default_config, NULL);
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
-
- if (!strcmp(arg, "--")) {
- i++;
- break;
- }
- if (!strcmp(arg, "-z")) {
- line_terminator = 0;
- continue;
- }
- if (!strcmp(arg, "-t") || !strcmp(arg, "-v")) {
- tag_cached = "H ";
- tag_unmerged = "M ";
- tag_removed = "R ";
- tag_modified = "C ";
- tag_other = "? ";
- tag_killed = "K ";
- if (arg[1] == 'v')
- show_valid_bit = 1;
- continue;
- }
- if (!strcmp(arg, "-c") || !strcmp(arg, "--cached")) {
- show_cached = 1;
- continue;
- }
- if (!strcmp(arg, "-d") || !strcmp(arg, "--deleted")) {
- show_deleted = 1;
- continue;
- }
- if (!strcmp(arg, "-m") || !strcmp(arg, "--modified")) {
- show_modified = 1;
- require_work_tree = 1;
- continue;
- }
- if (!strcmp(arg, "-o") || !strcmp(arg, "--others")) {
- show_others = 1;
- require_work_tree = 1;
- continue;
- }
- if (!strcmp(arg, "-i") || !strcmp(arg, "--ignored")) {
- dir.show_ignored = 1;
- require_work_tree = 1;
- continue;
- }
- if (!strcmp(arg, "-s") || !strcmp(arg, "--stage")) {
- show_stage = 1;
- continue;
- }
- if (!strcmp(arg, "-k") || !strcmp(arg, "--killed")) {
- show_killed = 1;
- require_work_tree = 1;
- continue;
- }
- if (!strcmp(arg, "--directory")) {
- dir.show_other_directories = 1;
- continue;
- }
- if (!strcmp(arg, "--no-empty-directory")) {
- dir.hide_empty_directories = 1;
- continue;
- }
- if (!strcmp(arg, "-u") || !strcmp(arg, "--unmerged")) {
- /* There's no point in showing unmerged unless
- * you also show the stage information.
- */
- show_stage = 1;
- show_unmerged = 1;
- continue;
- }
- if (!strcmp(arg, "-x") && i+1 < argc) {
- exc_given = 1;
- add_exclude(argv[++i], "", 0, &dir.exclude_list[EXC_CMDL]);
- continue;
- }
- if (!prefixcmp(arg, "--exclude=")) {
- exc_given = 1;
- add_exclude(arg+10, "", 0, &dir.exclude_list[EXC_CMDL]);
- continue;
- }
- if (!strcmp(arg, "-X") && i+1 < argc) {
- exc_given = 1;
- add_excludes_from_file(&dir, argv[++i]);
- continue;
- }
- if (!prefixcmp(arg, "--exclude-from=")) {
- exc_given = 1;
- add_excludes_from_file(&dir, arg+15);
- continue;
- }
- if (!prefixcmp(arg, "--exclude-per-directory=")) {
- exc_given = 1;
- dir.exclude_per_dir = arg + 24;
- continue;
- }
- if (!strcmp(arg, "--exclude-standard")) {
- exc_given = 1;
- setup_standard_excludes(&dir);
- continue;
- }
- if (!strcmp(arg, "--full-name")) {
- prefix_offset = 0;
- continue;
- }
- if (!strcmp(arg, "--error-unmatch")) {
- error_unmatch = 1;
- continue;
- }
- if (!prefixcmp(arg, "--with-tree=")) {
- with_tree = arg + 12;
- continue;
- }
- if (!prefixcmp(arg, "--abbrev=")) {
- abbrev = strtoul(arg+9, NULL, 10);
- if (abbrev && abbrev < MINIMUM_ABBREV)
- abbrev = MINIMUM_ABBREV;
- else if (abbrev > 40)
- abbrev = 40;
- continue;
- }
- if (!strcmp(arg, "--abbrev")) {
- abbrev = DEFAULT_ABBREV;
- continue;
- }
- if (*arg == '-')
- usage(ls_files_usage);
- break;
+ argc = parse_options(argc, argv, builtin_ls_files_options,
+ ls_files_usage, 0);
+ if (show_tag || show_valid_bit) {
+ tag_cached = "H ";
+ tag_unmerged = "M ";
+ tag_removed = "R ";
+ tag_modified = "C ";
+ tag_other = "? ";
+ tag_killed = "K ";
}
+ if (show_modified || show_others || dir.show_ignored || show_killed)
+ require_work_tree = 1;
+ if (show_unmerged)
+ /* There's no point in showing unmerged unless
+ * you also show the stage information.
+ */
+ show_stage = 1;
+ if (dir.exclude_per_dir)
+ exc_given = 1;
if (require_work_tree && !is_inside_work_tree())
setup_work_tree();
- pathspec = get_pathspec(prefix, argv + i);
+ pathspec = get_pathspec(prefix, argv);
/* Verify that the pathspec matches the prefix */
if (pathspec)
--
1.6.1
^ permalink raw reply related
* gitweb: removal of old style blobdiff support breaks ikiwiki
From: Joey Hess @ 2009-01-05 23:54 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
> * debian/diff/0005-gitweb-do-not-run-git-diff-that-is-Porcelain.diff:
> new; fix possible gitweb vulnerability: calling "git diff": Jakub
> says that legacy-style URI to view two blob differences are never
> generated since 1.4.3. This codepath runs "git diff" Porcelain from
> the gitweb, which is a no-no. It can trigger diff.external command
> that is specified in the configuration file of the repository being
> viewed.
Jakub didn't know the whole picture. This change breaks ikiwiki
configurations that use the old url form with gitweb. That url form
is used in configuration examples that have probably been copied into a
lot of ikiwiki setup files.
(Who knows what else might rely on the old url form.. One other thing I've
found that does is various cut-n-pasted gitweb urls embedded on various
websites..)
I wonder if it wouldn't be better to make gitweb continue to support the
old urls, using diff-tree instead of the porcelain?
Gerrit:
I'll be releasing a new version of ikiwiki to that documents how to use
the new gitweb url form. The version in Debian testing would need to
have a new-ish feature backported into it to support the new url form at
all. So please let me know if there are any plans to make this change to
the git in testing (or stable).
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] get_authors.sh, author.rb: use -s option of git shortlog.
From: Miklos Vajna @ 2009-01-05 23:54 UTC (permalink / raw)
To: Adeodato Simó; +Cc: Scott Chacon, git
In-Reply-To: <1231195946-20967-1-git-send-email-dato@net.com.org.es>
[-- Attachment #1: Type: text/plain, Size: 278 bytes --]
On Mon, Jan 05, 2009 at 11:52:26PM +0100, Adeodato Simó <dato@net.com.org.es> wrote:
> > I suppose fixing up the ruby part after this is not that hard, sadly I
> > don't speak Ruby myself, so I have no idea where and what to touch. ;-)
>
> Done.
Heh, great, thanks. :)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Permit a wider range of repository names in jgit daemon requests
From: Robin Rosenberg @ 2009-01-05 23:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20090105024622.GC20973@spearce.org>
måndag 05 januari 2009 03:46:22 skrev Shawn O. Pearce:
> The earlier restriction was too narrow for some applications, for
> example repositories named "jgit.dev" and "jgit.test" are perfectly
> valid Git repositories and should still be able to be served by
> the daemon.
>
> By blocking out only uses of ".." as a path component and Windows
> UNC paths (by blocking "\") we can reasonably prevent the client
> from escaping the base dirctories configured in the daemon.
>
> + if (name.startsWith("../") || name.contains("/../")
> + || name.contains("\\"))
//host/share also works as UNC path (even the DOS commands support it, provided
you quote the paths) and if you block // shuldn't '/', and '[A-Z]:' also be blocked?
\\ is a UNC-prefix only at the beginning of a path so if / need not be filtered, nor
does //. Inside a path \\ is the same as \ AFAIK (except directly after the drive letter.
This should probablybe factored out into a utilty so we can have a simple unit test for it.
-- robin
^ permalink raw reply
* [PATCH] get_authors.sh, author.rb: use -s option of git shortlog.
From: Adeodato Simó @ 2009-01-05 22:52 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, Miklos Vajna, Adeodato Simó
In-Reply-To: <20090105185737.GV21154@genesis.frugalware.org>
Suggested by Miklos Vajna <vmiklos@frugalware.org>.
---
app/models/author.rb | 26 ++++++++++++--------------
script/get_authors.sh | 2 +-
2 files changed, 13 insertions(+), 15 deletions(-)
> I suppose fixing up the ruby part after this is not that hard, sadly I
> don't speak Ruby myself, so I have no idea where and what to touch. ;-)
Done.
Btw, I don't think authors.txt should be in the repo at all, since it's
automatically generated, but it's your choice. :-)
diff --git a/app/models/author.rb b/app/models/author.rb
index 8fafc15..6bf069a 100644
--- a/app/models/author.rb
+++ b/app/models/author.rb
@@ -1,22 +1,20 @@
class Author
-
- def self.all
- authors = File.join(RAILS_ROOT, 'config/authors.txt')
+ def self.all
+ authors = File.join(RAILS_ROOT, 'config/authors.txt')
if File.exists?(authors)
authors = File.readlines(authors)
@authors = {:main => [], :contrib => []}
authors.each do |author|
- data = author.split(' ')
- number = data.pop.gsub('(', '').gsub(')', '').chomp
- name = data.join(' ')
- if(number.to_i > 50)
- @authors[:main] << [name, number.to_i]
- else
- @authors[:contrib] << [name, number.to_i]
+ if author =~ /(\d+)\s+(.+)/
+ name, number = $2, $1.to_i
+ if number > 50
+ @authors[:main] << [name, number]
+ else
+ @authors[:contrib] << [name, number]
+ end
end
end
+ @authors
end
- @authors
- end
-
-end
\ No newline at end of file
+ end
+end
diff --git a/script/get_authors.sh b/script/get_authors.sh
index 9aa8c6b..028a354 100755
--- a/script/get_authors.sh
+++ b/script/get_authors.sh
@@ -1,3 +1,3 @@
export GIT_DIR=/Users/schacon/projects/git/.git
cd /Users/schacon/projects/git
-git log --pretty=short --no-merges | git shortlog -n | grep -v -e '^ ' | grep ':' > ../gitscm/config/authors.txt
+git shortlog --no-merges -sn > ../gitscm/config/authors.txt
--
1.6.1.62.g677ca
^ permalink raw reply related
* Re: [ANNOUNCE] Git homepage change
From: David Bryson @ 2009-01-05 21:27 UTC (permalink / raw)
To: Mike Hommey; +Cc: Scott Chacon, git
In-Reply-To: <20090105194011.GB25104@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>
> FWIW, I think the "mascot" or whatever it is supposed to be, on the
> top right end, is "safe", trademark/copyright-wise. It looks too much
> like ???????????????(D??mo-kun), the NHK mascot.
> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
I think Scott mentioned at GitTogether that they paid the same artist
design some artwork for them including that tree munching monster and an
octopus.
Scott do you care to elaborate ?
Dave
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Boyd Lynn Gerber @ 2009-01-05 20:51 UTC (permalink / raw)
To: Scott Chacon; +Cc: Felipe Oliveira Carvalho, Petr Baudis, git
In-Reply-To: <d411cc4a0901051233v416a3b13n22811715a534872d@mail.gmail.com>
On Mon, 5 Jan 2009, Scott Chacon wrote:
> On Mon, Jan 5, 2009 at 12:16 PM, Felipe Oliveira Carvalho
> <felipekde@gmail.com> wrote:
>> On the footer we have:
>> "Source for this website was forked from Petr Baudis's git.or.cz"
>>
>> The link git.or.cz should be changed to git.or.cz/index.html to avoid
>> confusion for newcomers.
>
> Thanks, that is a good catch - I just updated this.
Also the mail list archive should really point to a valid archive. 2005
is really old.
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Scott Chacon @ 2009-01-05 20:33 UTC (permalink / raw)
To: Felipe Oliveira Carvalho; +Cc: Petr Baudis, git
In-Reply-To: <a2075f4c0901051216q193057fdrc07e17b580d67150@mail.gmail.com>
Hi,
On Mon, Jan 5, 2009 at 12:16 PM, Felipe Oliveira Carvalho
<felipekde@gmail.com> wrote:
> On the footer we have:
> "Source for this website was forked from Petr Baudis's git.or.cz"
>
> The link git.or.cz should be changed to git.or.cz/index.html to avoid
> confusion for newcomers.
Thanks, that is a good catch - I just updated this.
Scott
>
> git-scm.com is a very good page for "git quick start".
>
> --
> Felipe
>
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Ted Pavlic @ 2009-01-05 20:27 UTC (permalink / raw)
To: git; +Cc: Petr Baudis, Scott Chacon
In-Reply-To: <20090105164001.GA12275@machine.or.cz>
> The wiki is still hosted at the original place for the time being, as
> well as the man/ gitbot redirect. To reach the original manpage, use
> http://git.or.cz/index.html.
There were a couple of other pages under git.or.cz that may still be
linked elsewhere (e.g., the "external patches" page and the SVN crash
course). It would be nice if permanent redirects were added from those
pages to their new homes (so that existing links on the web wind up in
the right place).
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Felipe Oliveira Carvalho @ 2009-01-05 20:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, git
In-Reply-To: <20090105164001.GA12275@machine.or.cz>
On the footer we have:
"Source for this website was forked from Petr Baudis's git.or.cz"
The link git.or.cz should be changed to git.or.cz/index.html to avoid
confusion for newcomers.
git-scm.com is a very good page for "git quick start".
--
Felipe
^ permalink raw reply
* Re: [PATCH v2] parse-opt: migrate builtin-apply.
From: Miklos Vajna @ 2009-01-05 20:06 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20090105191222.GA14793@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 331 bytes --]
On Mon, Jan 05, 2009 at 08:12:22PM +0100, Pierre Habouzit <madcoder@debian.org> wrote:
> > I still haven't applied and ran the testsuite myself, but these makes me
> > wonder if there isn't a built-in "bit" type support in parse_options().
>
> There is.
FYI, in the meantime f26c494 is already in next, using OPT_BIT. :-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Mike Hommey @ 2009-01-05 19:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, git
In-Reply-To: <20090105164001.GA12275@machine.or.cz>
On Mon, Jan 05, 2009 at 05:40:01PM +0100, Petr Baudis wrote:
> Hi,
>
> thanks for the changes, Scott!
>
> Based on the previous feedback of other developers and my last review
> of git-scm.com, I have changed git.or.cz to redirect to git-scm.com.
>
> The wiki is still hosted at the original place for the time being, as
> well as the man/ gitbot redirect. To reach the original manpage, use
> http://git.or.cz/index.html.
FWIW, I think the "mascot" or whatever it is supposed to be, on the
top right end, is "safe", trademark/copyright-wise. It looks too much
like どーもくん(Dômo-kun), the NHK mascot.
http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
Mike
^ 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