* Re: [PATCH 1/8] Docs: send-email's usage text and man page mention same options
From: Miklos Vajna @ 2008-09-28 5:08 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git
In-Reply-To: <1222564196-84202-1-git-send-email-mfwitten@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
On Sat, Sep 27, 2008 at 08:09:49PM -0500, Michael Witten <mfwitten@MIT.EDU> wrote:
> Specifically, boolean options are now listed in the form
>
> --[no-]option
>
> and both forms of documentation now consistently use
>
> --[no-]signed-off-by-cc
I don't think documenting --no-foo in the perl script itself is a good
idea. See c3170a8 (git-merge: exclude unnecessary options from
OPTIONS_SPEC, 2008-05-12) which removes --no-foo from git-merge as well.
Of course the man page part makes sense.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 3/8] Docs: send-email: Man page option ordering
From: Jakub Narebski @ 2008-09-28 8:08 UTC (permalink / raw)
To: git
In-Reply-To: <1222564196-84202-3-git-send-email-mfwitten@mit.edu>
Michael Witten wrote:
> Now the man page lists the options in alphabetical
> order (in terms of the 'main' part of an option's
> name).
I know it is a matter of taste, but I prefer having options
on man page in functional order, grouped by function, perhaps
with subsections to group them (c.f. git-rev-list man page).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/4] mingw: move common functionality to win32.h
From: Johannes Sixt @ 2008-09-28 9:10 UTC (permalink / raw)
To: Dmitry Potapov
Cc: git, Junio C Hamano, Shawn O. Pearce, Alex Riesen, Marcus Griep
In-Reply-To: <20080927215102.GF21650@dpotapov.dyndns.org>
On Samstag, 27. September 2008, Dmitry Potapov wrote:
> win32_to_errno was the first thing that implemented but then released
> that translation of Win32 errors to errno cannot be in general case.
> For instance, ERROR_BUFFER_OVERFLOW means ENAMETOOLONG here, but it
> can be translated to ETOOSMALL in other cases. How do you propose to
> deal with that?
We deal with that when the need arises, in an evolutionary manner. The first
step is to *have* an error code translation routine.
-- Hannes
^ permalink raw reply
* git and perforce
From: Rustom Mody @ 2008-09-28 9:19 UTC (permalink / raw)
To: git
Our team does development under windows using perforce.
I am exploring having a 'private/personal' vcs on my machine behind perforce.
So...
Is the git-perforce integration under windows usable?
Thanks
^ permalink raw reply
* Re: [PATCH 4/4] cygwin: Use native Win32 API for stat
From: Johannes Sixt @ 2008-09-28 9:24 UTC (permalink / raw)
To: Dmitry Potapov
Cc: git, Junio C Hamano, Shawn O. Pearce, Alex Riesen, Marcus Griep
In-Reply-To: <20080927215406.GG21650@dpotapov.dyndns.org>
On Samstag, 27. September 2008, Dmitry Potapov wrote:
> On Sat, Sep 27, 2008 at 08:35:03PM +0200, Johannes Sixt wrote:
> > > +core.cygwinNativeStat::
> >
> > This name is *really* odd, for two reasons:
...
> It was Shawn's suggestion. I don't care much about the name as long as
> it is explained in the documentation... Therefore, I accepted what Shawn
> said without giving it any thought.
Shawn is an importen git-o-maniac, but it's certainly not blasphemy to
question his words of wisdom ;)
> Now, when you bring this name to my
> attention, I believe core.useCygwinStat (in the opposite to the current
> core.cygwinNativeStat) would be a better name. Your name is okay too,
> but a bit too long for my taste and not specific enough (I suppose
> Cygwin does many FS related tricks). Anyway, I don't have a strong
> opinion here, so just whatever most people like is fine with me :)
My point is that emphasis on "stat" in the name is wrong: That's about
implementation, but not about the effect. Why wouldn't 'ignoreCygwinFSTricks'
be specific enough? By using a native stat implementation, *all* of them are
ignored. Yes, you fall back to Cygwin's stat sometimes, but these are cases
where the *effect* is not that relevant. (And the length of the name doesn't
worry me, considering how many people would want to change the default.)
-- Hannes
^ permalink raw reply
* Re: [PATCH 4/4] cygwin: Use native Win32 API for stat
From: Alex Riesen @ 2008-09-28 9:50 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Johannes Sixt,
Marcus Griep
In-Reply-To: <20080927084349.GC21650@dpotapov.dyndns.org>
Dmitry Potapov, Sat, Sep 27, 2008 10:43:49 +0200:
> Despite all efforts to make the fast implementation as robust as possible,
> it may not work well for some very rare situations. I am aware only one
> situation: use Cygwin mount to bind unrelated paths inside repository
> together. Therefore, the core.cygwinnativestat configuration option is
> provided, which controls whether native or Cygwin version of stat is used.
cygwin.tryWindowsState? (I think cygwin has to get its own section)
> +static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
> +{
> + WIN32_FILE_ATTRIBUTE_DATA fdata;
> +
> + if (file_name[0] == '/')
> + return cygstat (file_name, buf);
> +
> + if (!(errno = get_file_attr(file_name, &fdata))) {
> + /*
> + * If the system attribute is set and it is not a directory then
> + * it could be a symbol link created in the nowinsymlinks mode.
> + * Normally, Cygwin works in the winsymlinks mode, so this situation
> + * is very unlikely. For the sake of simplicity of our code, let's
> + * Cygwin to handle it.
> + */
> + if ((fdata.dwFileAttributes & FILE_ATTRIBUTE_SYSTEM) &&
> + !(fdata.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY))
> + return cygstat (file_name, buf);
formatting: space after function name.
> +
> + /* fill out the stat structure */
> + buf->st_dev = buf->st_rdev = 0; /* not used by Git */
> + buf->st_ino = 0;
> + buf->st_mode = file_attr_to_st_mode (fdata.dwFileAttributes);
> + buf->st_nlink = 1;
> + buf->st_uid = buf->st_gid = 0;
> +#ifdef __CYGWIN_USE_BIG_TYPES__
> + buf->st_size = ((_off64_t)fdata.nFileSizeHigh << 32) +
> + fdata.nFileSizeLow;
> +#else
> + buf->st_size = (off_t)fdata.nFileSizeLow;
> +#endif
> + buf->st_blocks = size_to_blocks(buf->st_size);
> + filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
> + filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
> + filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
> + return 0;
> + } else if (errno == ENOENT) {
> + /*
> + * In the winsymlinks mode (which is the default), Cygwin
> + * emulates symbol links using Windows shortcut files. These
> + * files are formed by adding .lnk extension. So, if we have
> + * not found the specified file name, it could be that it is
> + * a symbol link. Let's Cygwin to deal with that.
> + */
> + return cygstat (file_name, buf);
> + }
> + return -1;
> +}
I like it and will be keeping in my tree. Thanks!
^ permalink raw reply
* small warm-up: easy parse-opt migrations.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster
There's not a lot to tell, those are just three migration to
parse-options.
^ permalink raw reply
* [PATCH] parse-opt: migrate builtin-merge-file.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster, Pierre Habouzit
In-Reply-To: <1222595139-32087-3-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-merge-file.c | 68 +++++++++++++++++++++++++++----------------------
1 files changed, 37 insertions(+), 31 deletions(-)
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
index 45c9853..7736fe8 100644
--- a/builtin-merge-file.c
+++ b/builtin-merge-file.c
@@ -2,21 +2,44 @@
#include "cache.h"
#include "xdiff/xdiff.h"
#include "xdiff-interface.h"
+#include "parse-options.h"
-static const char merge_file_usage[] =
-"git merge-file [-p | --stdout] [--diff3] [-q | --quiet] [-L name1 [-L orig [-L name2]]] file1 orig_file file2";
+static const char *const merge_file_usage[] = {
+ "git merge-file [options] [-L name1 [-L orig [-L name2]]] file1 orig_file file2",
+ NULL
+};
+
+static int label_cb(const struct option *opt, const char *arg, int unset)
+{
+ static int label_count = 0;
+ const char **names = (const char **)opt->value;
+
+ if (label_count >= 3)
+ return error("too many labels on the command like");
+ names[label_count++] = arg;
+ return 0;
+}
int cmd_merge_file(int argc, const char **argv, const char *prefix)
{
- const char *names[3];
+ const char *names[3] = { NULL, NULL, NULL };
mmfile_t mmfs[3];
mmbuffer_t result = {NULL, 0};
xpparam_t xpp = {XDF_NEED_MINIMAL};
int ret = 0, i = 0, to_stdout = 0;
int merge_level = XDL_MERGE_ZEALOUS_ALNUM;
- int merge_style = 0;
+ int merge_style = 0, quiet = 0;
int nongit;
+ struct option options[] = {
+ OPT_BOOLEAN('p', "stdout", &to_stdout, "send results to standard output"),
+ OPT_SET_INT(0, "diff3", &merge_style, "use a diff3 based merge", XDL_MERGE_DIFF3),
+ OPT__QUIET(&quiet),
+ OPT_CALLBACK('L', NULL, names, "name",
+ "set labels for file1/orig_file/file2", &label_cb),
+ OPT_END(),
+ };
+
prefix = setup_git_directory_gently(&nongit);
if (!nongit) {
/* Read the configuration file */
@@ -25,37 +48,20 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
merge_style = git_xmerge_style;
}
- while (argc > 4) {
- if (!strcmp(argv[1], "-L") && i < 3) {
- names[i++] = argv[2];
- argc--;
- argv++;
- } else if (!strcmp(argv[1], "-p") ||
- !strcmp(argv[1], "--stdout"))
- to_stdout = 1;
- else if (!strcmp(argv[1], "-q") ||
- !strcmp(argv[1], "--quiet"))
- freopen("/dev/null", "w", stderr);
- else if (!strcmp(argv[1], "--diff3"))
- merge_style = XDL_MERGE_DIFF3;
- else
- usage(merge_file_usage);
- argc--;
- argv++;
- }
-
- if (argc != 4)
- usage(merge_file_usage);
-
- for (; i < 3; i++)
- names[i] = argv[i + 1];
+ argc = parse_options(argc, argv, options, merge_file_usage, 0);
+ if (argc != 3)
+ usage_with_options(merge_file_usage, options);
+ if (quiet)
+ freopen("/dev/null", "w", stderr);
for (i = 0; i < 3; i++) {
- if (read_mmfile(mmfs + i, argv[i + 1]))
+ if (!names[i])
+ names[i] = argv[i];
+ if (read_mmfile(mmfs + i, argv[i]))
return -1;
if (buffer_is_binary(mmfs[i].ptr, mmfs[i].size))
return error("Cannot merge binary files: %s\n",
- argv[i + 1]);
+ argv[i]);
}
ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
@@ -65,7 +71,7 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
free(mmfs[i].ptr);
if (ret >= 0) {
- const char *filename = argv[1];
+ const char *filename = argv[0];
FILE *f = to_stdout ? stdout : fopen(filename, "wb");
if (!f)
--
1.6.0.2.516.g12936
^ permalink raw reply related
* [PATCH] parse-opt: migrate fmt-merge-msg.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster, Pierre Habouzit
In-Reply-To: <1222595139-32087-1-git-send-email-madcoder@debian.org>
Also fix an inefficient printf("%s", ...) where we can use write_in_full.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-fmt-merge-msg.c | 50 +++++++++++++++++++++-------------------------
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index a1879f1..654d996 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -5,8 +5,10 @@
#include "revision.h"
#include "tag.h"
-static const char *fmt_merge_msg_usage =
- "git fmt-merge-msg [--log] [--no-log] [--file <file>]";
+static const char * const fmt_merge_msg_usage[] = {
+ "git fmt-merge-msg [--log|--no-log] [--file <file>]",
+ NULL
+};
static int merge_log;
@@ -342,37 +344,31 @@ int fmt_merge_msg(int merge_log, struct strbuf *in, struct strbuf *out) {
int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
{
+ const char *inpath = NULL;
+ struct option options[] = {
+ OPT_BOOLEAN(0, "log", &merge_log, "populate log with the shortlog"),
+ OPT_STRING('F', "file", &inpath, "file", "file to read from"),
+ OPT_END()
+ };
+
FILE *in = stdin;
struct strbuf input, output;
int ret;
git_config(fmt_merge_msg_config, NULL);
-
- while (argc > 1) {
- if (!strcmp(argv[1], "--log"))
- merge_log = 1;
- else if (!strcmp(argv[1], "--no-log"))
- merge_log = 0;
- else if (!strcmp(argv[1], "-F") || !strcmp(argv[1], "--file")) {
- if (argc < 3)
- die ("Which file?");
- if (!strcmp(argv[2], "-"))
- in = stdin;
- else {
- fclose(in);
- in = fopen(argv[2], "r");
- if (!in)
- die("cannot open %s", argv[2]);
- }
- argc--; argv++;
- } else
- break;
- argc--; argv++;
+ argc = parse_options(argc, argv, options, fmt_merge_msg_usage, 0);
+ if (argc > 0)
+ usage_with_options(fmt_merge_msg_usage, options);
+
+ if (!inpath || strcmp(inpath, "-"))
+ in = stdin;
+ else {
+ fclose(in);
+ in = fopen(argv[2], "r");
+ if (!in)
+ die("cannot open %s", argv[2]);
}
- if (argc > 1)
- usage(fmt_merge_msg_usage);
-
strbuf_init(&input, 0);
if (strbuf_read(&input, fileno(in), 0) < 0)
die("could not read input file %s", strerror(errno));
@@ -381,6 +377,6 @@ int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
ret = fmt_merge_msg(merge_log, &input, &output);
if (ret)
return ret;
- printf("%s", output.buf);
+ write_in_full(STDOUT_FILENO, output.buf, output.len);
return 0;
}
--
1.6.0.2.516.g12936
^ permalink raw reply related
* [PATCH] parse-opt: migrate git-merge-base.
From: Pierre Habouzit @ 2008-09-28 9:45 UTC (permalink / raw)
To: git; +Cc: spearce, gitster, Pierre Habouzit
In-Reply-To: <1222595139-32087-2-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-merge-base.c | 37 ++++++++++++++++---------------------
1 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index b08da51..03fc1c2 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -1,6 +1,7 @@
#include "builtin.h"
#include "cache.h"
#include "commit.h"
+#include "parse-options.h"
static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
{
@@ -21,8 +22,10 @@ static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
return 0;
}
-static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>...";
+static const char * const merge_base_usage[] = {
+ "git merge-base [--all] <commit-id> <commit-id>...",
+ NULL
+};
static struct commit *get_commit_reference(const char *arg)
{
@@ -44,25 +47,17 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
int rev_nr = 0;
int show_all = 0;
- git_config(git_default_config, NULL);
-
- while (1 < argc && argv[1][0] == '-') {
- const char *arg = argv[1];
- if (!strcmp(arg, "-a") || !strcmp(arg, "--all"))
- show_all = 1;
- else
- usage(merge_base_usage);
- argc--; argv++;
- }
- if (argc < 3)
- usage(merge_base_usage);
-
- rev = xmalloc((argc - 1) * sizeof(*rev));
-
- do {
- rev[rev_nr++] = get_commit_reference(argv[1]);
- argc--; argv++;
- } while (argc > 1);
+ struct option options[] = {
+ OPT_BOOLEAN('a', "all", &show_all, "outputs all common ancestors"),
+ OPT_END()
+ };
+ git_config(git_default_config, NULL);
+ argc = parse_options(argc, argv, options, merge_base_usage, 0);
+ if (argc < 2)
+ usage_with_options(merge_base_usage, options);
+ rev = xmalloc(argc * sizeof(*rev));
+ while (argc-- > 0)
+ rev[rev_nr++] = get_commit_reference(*argv++);
return show_merge_base(rev, rev_nr, show_all);
}
--
1.6.0.2.516.g12936
^ permalink raw reply related
* Re: Implementation of a "textconv" filter for easy custom diff.
From: Matthieu Moy @ 2008-09-28 9:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080928041040.GA24214@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Neat. I started on something like this quite a while ago,
Did you publish/send it anywhere?
> We have one major difference in our approaches. In yours, there is a
> new "textconv" attribute that can be used. In mine, I subtly changed the
> meaning of the "diff=foo" attribute to be "use the diff driver named by
> diff.foo.*", and you would set diff.foo.textconv to your command. This
> is a bit simpler to implement, and it provides a better path forward for
> defining sets of diff tweaks.
Yes, that's an interesting approach too.
One point in favor of mine is that the "textconv" thing is no
necessarily limited to diff-ing. That would be really cool to have
"blame" use it too for example (with quite bad performance, but that
would be the first time I see a tool able to do this).
Well, OTOH, one could argue that "blame" is based on diff-ing, and
therefore it's natural to define a diff filter to tell how "blame"
should work.
> For example, one of the limitations of the current syntax is that you
> can't say "Choose automatically whether this is binary or text, but if
> it is text, use this hunk header." But with my scheme it is easy to do:
>
> in attributes:
> file diff=foo
>
> in config:
> [diff "foo"]
> xfuncname = "some regex"
> binary = auto
No sure that would actually be useful in real life, but it doesn't
harm to have it. And the argument "better path forward for defining
sets of diff tweaks" is a good one IMO.
--
Matthieu
^ permalink raw reply
* Re: [RFC] gitweb wishlist and TODO list
From: Jakub Narebski @ 2008-09-28 10:01 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <200809251230.11342.jnareb@gmail.com>
On Thu, 25 Sep 2008, Jakub Narebski wrote:
> This is yet another series of planned gitweb features. It expands more
> on new user-visible features than on improving gitweb code (therefore
> for example using Git.pm/Git::Repo, gitweb caching, and list form of
> open for pipelines are not mentioned here).
Below there are a few more features which were missing from the list:
* Support for invoking gitweb.cgi (the compiled version) from command
line to easy generate projects list in format used by gitweb,
perhaps also to generate web feeds (RSS, Atom, OPML). It would
probably require adding support for CLI parameters.
* gitweb-admin or gitwebmin; I guess best as separate script.
Allow to set gitweb configuration, gitweb-related per-repository
configuration (visibility, access, description, README, URLs,...).
Perhaps also allow to set access permissions, delete/create
branches, change denyFastForward, rename project, set alternates,
etc.
* Make gitweb use less dependent on understanding git terminology, like
'tree' -> 'browse' etc. (proposed by Pieter de Bie (Pieter) on #git,
as "simplified interface", 2008-09-27T14:56+0200).
'tree' -> 'browse', 'blob' -> 'file' or 'show',
'snapshot' -> 'archive' or 'download', 'heads' -> 'branches'
'commit | commitdiff | tree | snapshot' -> 'show | browse' for heads
Unfortunately there is no consensus on how such simpler terminology
should look like...
* Support for generating bundles, and not only snapshots, either
depth=1 bundles, or diff bundles (snapshot for diff is bundle).
* Support for i18n (translating gitweb), best using 'gettext' which
the rest of git (gitk and git-gui) uses (use Locale::TextDomain,
or Locale::Maketext?).
* Possibly: fallback to "user.name <user.email>" for repository owner
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Implement a textconv filter for "git diff"
From: Matthieu Moy @ 2008-09-28 10:00 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20080928041526.GB24214@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Sep 28, 2008 at 04:06:56AM +0200, Matthieu Moy wrote:
>
>> +static int textconv_two_files(const char *textconv,
>> + const char *name_a,
>> + const char *name_b,
>> + mmfile_t *mf1,
>> + mmfile_t *mf2,
>> + struct diff_filespec *one,
>> + struct diff_filespec *two)
>> +{
>
> Must we always be textconv'ing two files? What if I am comparing
> "v1.5:foo.odf" to "foo.txt" in the working tree?
Hmm, why not, and the textconv could be different (like comparing
old:foo.doc with ./foo.odt).
> In my implementation, I textconv one at a time. I just did so from
> fill_mmfile, so all of diff automagically just sees the converted text.
One has to be carefull not to call textconv for plumbing commands,
since the generated patches are not applicable, and only for the eyes
of the reader.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Document the textconv filter.
From: Johannes Sixt @ 2008-09-28 11:07 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1222567618-22156-5-git-send-email-Matthieu.Moy@imag.fr>
On Sonntag, 28. September 2008, Matthieu Moy wrote:
> +Converting files to text before a diff
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +The attribute `textconv` affects 'git diff' in a way similar to the
> +`diff` attribute, but with `textconv`, the user provides only a way to
> +convert the file into text, and git takes care of doing the diff as
> +usual (i.e. other options of 'git diff' such as '--color' remain
> +available).
> +
> +The value of `textconv` must be a string, which is the textconv
> +driver.
Wouldn't it be much more useful to have git parse stdout of the custom diff
tool in order to colorize it? Of course, this would mean that external diff
tools are more complicated and their stdout has to conform mostly to the git
diff syntax. But:
> +To tell git to use the `exif` filter for jpeg images, use:
> +
> +----------------------------------------------------------------
> +*.jpg textconv=exif
> +----------------------------------------------------------------
In this very example it would be possible that the external diff driver shows
the differences in the image in a window and also produces EXIF information
on stdout.
-- Hannes
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Jakub Narebski @ 2008-09-28 11:59 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <48d723bf90941_5de93fcd2ee870984625e@app02.zenbe.com.tmail>
On Mon, 22 Sep 2008, Duy Nguyen wrote:
> On 09/22/2008 "Jakub Narebski" <jnareb@gmail.com> wrote:
>>On Sun, 21 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>>> On 9/21/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>> +
>>>>> +#define CE_EXTENDED_FLAGS (0)
>>>>> +
>>>>> +/*
>>>>> + * Safeguard to avoid saving wrong flags:
>>>>> + * - CE_EXTENDED2 won't get saved until its semantic is known
>>>>> + * - Bits in 0x0000FFFF have been saved in ce_flags already
>>>>> + * - Bits in 0x003F0000 are currently in-memory flags
>>>>> + */
>>>>> +#if CE_EXTENDED_FLAGS & 0x80CFFFFF
>>>>> +#error "CE_EXTENDED_FLAGS out of range"
>>>>> +#endif
>>>>
>>>>
>>>> I don't quite understand the above fragment (especially with the fact
>>>> that CE_EXTENDED_FLAGS is defined as (0))...
>>>
>>> Because this patch does not introduce any new on-disk flag yet so
>>> CE_EXTENDED_FLAGS remains 0. In the next patch, CE_EXTENDED_FLAGS will
>>> be updated to have CE_NO_CHECKOUT.
>>
>> Well, now I understand CE_EXTENDED_FLAGS being (0).
>>
>> What I still don't understand the pattern it is protected against.
>> As I understand it if CE_EXTENDED_FLAGS & 0x0000FFFF it is bad,
>> because ce_flags saved flags are not extended flags, and
>> CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags. But why
>> CE_EXTENDED_FLAGS & 0x80C00000 is bad, and why (if I understand it)
>> CE_EXTENDED_FLAGS & 0x00300000 is not bad.
>
> Wrong bit computation, should be "#if CE_EXTENDED_FLAGS & 0x803FFFFF".
> Thanks for pointing out.
So now there is:
Now CE_EXTENDED_FLAGS & 0x803FFFFF is bad because:
* CE_EXTENDED_FLAGS & 0x0000FFFF are saved flags (not extended)
* CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags
* CE_EXTENDED_FLAGS & 0x80000000 is 'extra flags' bit
(this is not mentioned in quoted comment; I'm not sure if
it needs to be or not)
Is that correct?
--
Jakub Narebski
Poland
^ permalink raw reply
* strange "git clone" behavior wrt an active branch
From: Leo Razoumov @ 2008-09-28 12:05 UTC (permalink / raw)
To: Git Mailing List
Hi All,
I am using the latest stable version git-1.6.0.2.
The man page for git-clone states explicitly that "git clone"
" Clones a repository into a newly created directory, ...[snip]...
and creates and checks out an initial branch equal to the
cloned repository's currently active branch. "
I noticed that while my active branch "My" happens to point to the
same commit as the "master" the git clone will check out master
instead of My (currently active branch). Is it a bug?
Here is the example that demontrates the problem
~> mkdir tmp
~/tmp> git init
~/tmp> cat > txt
some text
~/tmp> git add .
~/tmp> git ci -m 'init ci'
~/tmp> git branch -a
* master
~/tmp> git co -b My
~/tmp> git branch -a
* My
master
Now "My" is my active branch in 'tmp' repo. It points to the same
commit as the master. Now let us clone it
~/tmp> cd ..
~> git clone tmp tmp1
~> cd tmp1
~/tmp1> git branch -a
* master
origin/HEAD
origin/My
origin/master
In the cloned repository 'tmp1', master branch is active. No local
tracking branch for "My" was created. I think this behavior
contradicts the man page. Is it a bug or feature??
Thanks,
--Leo--
^ permalink raw reply
* Re: [PATCH 01/14] Extend index to save more flags
From: Nguyen Thai Ngoc Duy @ 2008-09-28 12:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200809281359.46858.jnareb@gmail.com>
On 9/28/08, Jakub Narebski <jnareb@gmail.com> wrote:
> So now there is:
>
> Now CE_EXTENDED_FLAGS & 0x803FFFFF is bad because:
> * CE_EXTENDED_FLAGS & 0x0000FFFF are saved flags (not extended)
>
> * CE_EXTENDED_FLAGS & 0x003F0000 are in-memory flags
>
> * CE_EXTENDED_FLAGS & 0x80000000 is 'extra flags' bit
> (this is not mentioned in quoted comment; I'm not sure if
> it needs to be or not)
>
> Is that correct?
Correct.
--
Duy
^ permalink raw reply
* Re: [PATCH] Document the textconv filter.
From: Matthieu Moy @ 2008-09-28 12:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <200809281307.21409.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Sonntag, 28. September 2008, Matthieu Moy wrote:
>> +Converting files to text before a diff
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +The attribute `textconv` affects 'git diff' in a way similar to the
>> +`diff` attribute, but with `textconv`, the user provides only a way to
>> +convert the file into text, and git takes care of doing the diff as
>> +usual (i.e. other options of 'git diff' such as '--color' remain
>> +available).
>> +
>> +The value of `textconv` must be a string, which is the textconv
>> +driver.
>
> Wouldn't it be much more useful to have git parse stdout of the custom diff
> tool in order to colorize it?
That would do it for --color, but not --color-words for example. The
problem with the GIT_EXTERNAL_DIFF is that the diff tool has to
re-implement everything that "git diff" already do.
Take my opendocument diff script :
http://www-verimag.imag.fr/~moy/opendocument/git-oodiff
That's 77 lines of code as a wrapper to odt2txt and diff. With the
"textconv" attribute, it's one line in .gitattributes, and two in
~/.gitconfig.
> Of course, this would mean that external diff tools are more
> complicated and their stdout has to conform mostly to the git diff
> syntax. But:
>
>> +To tell git to use the `exif` filter for jpeg images, use:
>> +
>> +----------------------------------------------------------------
>> +*.jpg textconv=exif
>> +----------------------------------------------------------------
>
> In this very example it would be possible that the external diff driver shows
> the differences in the image in a window and also produces EXIF information
> on stdout.
Yes, but that's really a specific example. Having git colorize the
diff would be a little extra, but that wouldn't reduce the effort to
write the external diff tool itself, and doesn't give you _all_ of
git-diff, just --color.
--
Matthieu
^ permalink raw reply
* Re: strange "git clone" behavior wrt an active branch
From: Santi Béjar @ 2008-09-28 12:37 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Git Mailing List
In-Reply-To: <ee2a733e0809280505n69f62e0fy89667c175bcc16c@mail.gmail.com>
On Sun, Sep 28, 2008 at 2:05 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
> Hi All,
> I am using the latest stable version git-1.6.0.2.
>
> The man page for git-clone states explicitly that "git clone"
>
> " Clones a repository into a newly created directory, ...[snip]...
> and creates and checks out an initial branch equal to the
> cloned repository's currently active branch. "
>
> I noticed that while my active branch "My" happens to point to the
> same commit as the "master" the git clone will check out master
> instead of My (currently active branch). Is it a bug?
>
Currently it is only guessed which is the active branch (with a
preference for the master branch as it is the default), as the current
protocol does not allow tranfering the ref links:
$ git ls-remote $url
$sha1 HEAD
$sha1 $branchname
...
instead of:
ref: refs/heads/master HEAD
$sha1 $branchname
...
So, I think it is a current limitation that maybe should be documented.
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] bash completion: Add --[no-]-validate to "git send-email"
From: Teemu Likonen @ 2008-09-28 12:55 UTC (permalink / raw)
To: Michael Witten; +Cc: gitster, git, spearce
In-Reply-To: <20080928045121.GA3208@mithlond.arda.local>
Teemu Likonen wrote (2008-09-28 07:51 +0300):
> Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
> ---
>
> If your patch is to be applied let's also add the options to bash
> completion.
One extra hyphen in the subject of my commit message. This is better:
bash completion: Add --[no-]validate to "git send-email"
^ permalink raw reply
* Re: small warm-up: easy parse-opt migrations.
From: Sverre Rabbelier @ 2008-09-28 13:20 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, spearce, gitster
In-Reply-To: <1222595139-32087-1-git-send-email-madcoder@debian.org>
On Sun, Sep 28, 2008 at 11:45, Pierre Habouzit <madcoder@debian.org> wrote:
> There's not a lot to tell, those are just three migration to
> parse-options.
I think you forgot the -n switch to git format-patch, yes?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: strange "git clone" behavior wrt an active branch
From: Leo Razoumov @ 2008-09-28 13:23 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0809280537k7adffe3dte9579fe70c7f990e@mail.gmail.com>
On 9/28/08, Santi Béjar <santi@agolina.net> wrote:
> On Sun, Sep 28, 2008 at 2:05 PM, Leo Razoumov <slonik.az@gmail.com> wrote:
> > Hi All,
> > I am using the latest stable version git-1.6.0.2.
> >
> > The man page for git-clone states explicitly that "git clone"
> >
> > " Clones a repository into a newly created directory, ...[snip]...
> > and creates and checks out an initial branch equal to the
> > cloned repository's currently active branch. "
> >
> > I noticed that while my active branch "My" happens to point to the
> > same commit as the "master" the git clone will check out master
> > instead of My (currently active branch). Is it a bug?
> >
>
>
> Currently it is only guessed which is the active branch (with a
> preference for the master branch as it is the default), as the current
> protocol does not allow tranfering the ref links:
This is quite unfortunate design decision. There can be any number of
local branches referring to the same commit. Without being able to
pick into .git/HEAD it is impossible to decide which of them is
"active".
--Leo--
^ permalink raw reply
* git-describe doesn't show the most recent tag
From: Erez Zilber @ 2008-09-28 13:48 UTC (permalink / raw)
To: git-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw
Hi,
I'm trying to run git-describe on the open-iscsi git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/mnc/open-iscsi.git):
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-branch -a
* master
origin/2.0-869-bugfix
origin/HEAD
origin/bnx2i
origin/cxgb3i
origin/master
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe
2.0-868-rc1-81-g31c9d42
However, there are newer tags than 2.0-868-rc1:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-tag
2.0-868-rc1
2.0-869
2.0-869-rc2
2.0-869-rc3
2.0-869-rc4
2.0-869.1
2.0-869.2
2.0-870-rc1
>From what I see in the man page "git-describe - Show the most recent
tag that is reachable from a commit". In this repository, it doesn't
look like that...
Now, I switch to the "2.0-869-bugfix" branch:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-checkout -b
2.0-869-bugfix origin/2.0-869-bugfix
Branch 2.0-869-bugfix set up to track remote branch
refs/remotes/origin/2.0-869-bugfix.
Switched to a new branch "2.0-869-bugfix"
and running again git-describe:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe
2.0-868-rc1-33-g81133dd
Only if I use the --tags flag, I get what I expected:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe --tags
2.0-869.2
Why is this happening?
Thanks,
Erez
^ permalink raw reply
* Re: git-describe doesn't show the most recent tag
From: Pierre Habouzit @ 2008-09-28 13:55 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org, open-iscsi
In-Reply-To: <ce513bcc0809280648s352cda3fj5eb35b6e9cd40af9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
On Sun, Sep 28, 2008 at 01:48:42PM +0000, Erez Zilber wrote:
> Why is this happening?
--tags
Instead of using only the annotated tags, use any tag found in
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.git/refs/tags.
--
·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: git-describe doesn't show the most recent tag
From: Erez Zilber @ 2008-09-28 14:29 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git@vger.kernel.org, open-iscsi
In-Reply-To: <20080928135526.GG5302@artemis.corp>
On Sun, Sep 28, 2008 at 4:55 PM, Pierre Habouzit <madcoder@debian.org> wrote:
> On Sun, Sep 28, 2008 at 01:48:42PM +0000, Erez Zilber wrote:
>> Why is this happening?
>
> --tags
> Instead of using only the annotated tags, use any tag found in
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> .git/refs/tags.
>
I'm not sure that I understand the difference between tags and annotated tags.
Anyway, if I move to the master branch, I see the following tags:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ ls .git/refs/tags/
2.0-868-rc1 2.0-869 2.0-869.1 2.0-869.2 2.0-869-rc2 2.0-869-rc3
2.0-869-rc4 2.0-870-rc1
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-tag
2.0-868-rc1
2.0-869
2.0-869-rc2
2.0-869-rc3
2.0-869-rc4
2.0-869.1
2.0-869.2
2.0-870-rc1
However:
[erez.zilber@erez-lx:/tmp/open-iscsi.git]$ git-describe --tags
2.0-868-rc1-81-g31c9d42
I was expecting to see 2.0-870-rc1 here.
Erez
^ 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