* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-09 11:22 UTC (permalink / raw)
To: Uri Okrent
Cc: Matthieu Moy, Nanako Shiraishi, Junio C Hamano, Teemu Likonen,
Git
In-Reply-To: <4AA6A7A9.3080908@gmail.com>
On Tue, Sep 08, 2009 at 11:51:21AM -0700, Uri Okrent wrote:
> I know that by default I'd like to see new messages, and in case I'm
> doing something adventurous I'd like to see a message I may not have
> seen before. If I had turned off all messages because I got sick of
> seeing one or two in particular, then I'd never know.
Yeah, I think the 'advice.all' option, while clever, is not really
helping anyone. In my revised series, I am just omitting entirely (but
the code is still structured that adding it later would be very easy if
we change our minds).
> P.S. I never really introduced myself to the list... Uri Okrent here
> from L.A. Keep up the great work everyone!
Welcome. :)
-Peff
^ permalink raw reply
* [PATCH 0/2] configurable advice messages
From: Jeff King @ 2009-09-09 11:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906072322.GA29949@coredump.intra.peff.net>
On Sun, Sep 06, 2009 at 03:23:22AM -0400, Jeff King wrote:
> I'll re-roll 3 and 4 based on that, but I will wait a bit to see any
> more comments. Probably you should consider patches 1 and 2 as a
> potential series for 'maint', and 3 and 4 should be spun off into their
> own series (they really only rely textually on the first two).
Looks like you applied 1 and 2 already, so here is the re-roll of the
latter two patches incorporating the changes that have been discussed.
[1/2]: push: make non-fast-forward help message configurable
[2/2]: status: make "how to stage" messages optional
-Peff
^ permalink raw reply
* [PATCH 1/2] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-09 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090909112623.GA30765@coredump.intra.peff.net>
This message is designed to help new users understand what
has happened when refs fail to push. However, it does not
help experienced users at all, and significantly clutters
the output, frequently dwarfing the regular status table and
making it harder to see.
This patch introduces a general configuration mechanism for
optional messages, with this push message as the first
example.
Signed-off-by: Jeff King <peff@peff.net>
---
Changes from the original version:
- s/message/advice/ in the config and filenames.
- no more advice.all config option. The point of this is to shut up
messages that annoy you; It's probably best to let users see a
message, dislike it, and then turn it off manually after making a
decision that they don't need or want to see it. But adding a "never
show me any advice" option means they will never see some of the
messages, which might otherwise be helpful.
My thinking here is influenced by the fact that we are usually pretty
conservative about adding messages in the first place. If we suddenly
had a period of adding a bunch of "you are clueless, and here is how
git works" messages, enabled by default, then I might reconsider.
- I re-worked the code to give each preference its own variable. This
means we can avoid maintaining a separate list of "#define
MESSAGE_ONE 1" in addition to the array. It also means that checking
a preference is a little nicer. Instead of:
if (advice[ADVICE_PUSH_NONFASTFORWARD].preference)
you get:
if (advice_push_nonfastforward)
Documentation/config.txt | 11 +++++++++++
Makefile | 2 ++
advice.c | 25 +++++++++++++++++++++++++
advice.h | 8 ++++++++
builtin-push.c | 2 +-
cache.h | 1 +
config.c | 3 +++
7 files changed, 51 insertions(+), 1 deletions(-)
create mode 100644 advice.c
create mode 100644 advice.h
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..a35b918 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -113,6 +113,17 @@ For command-specific variables, you will find a more detailed description
in the appropriate manual page. You will find a description of non-core
porcelain configuration variables in the respective porcelain documentation.
+advice.*::
+ When set to 'true', display the given optional help message.
+ When set to 'false', do not display. The configuration variables
+ are:
++
+--
+ pushNonFastForward::
+ Advice shown when linkgit:git-push[1] refuses
+ non-fast-forward refs. Default: true.
+--
+
core.fileMode::
If false, the executable bit differences between the index and
the working copy are ignored; useful on broken filesystems like FAT.
diff --git a/Makefile b/Makefile
index a614347..9d9ff45 100644
--- a/Makefile
+++ b/Makefile
@@ -397,6 +397,7 @@ export PERL_PATH
LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
+LIB_H += advice.h
LIB_H += archive.h
LIB_H += attr.h
LIB_H += blob.h
@@ -454,6 +455,7 @@ LIB_H += utf8.h
LIB_H += wt-status.h
LIB_OBJS += abspath.o
+LIB_OBJS += advice.o
LIB_OBJS += alias.o
LIB_OBJS += alloc.o
LIB_OBJS += archive.o
diff --git a/advice.c b/advice.c
new file mode 100644
index 0000000..b5216a2
--- /dev/null
+++ b/advice.c
@@ -0,0 +1,25 @@
+#include "cache.h"
+
+int advice_push_nonfastforward = 1;
+
+static struct {
+ const char *name;
+ int *preference;
+} advice_config[] = {
+ { "pushnonfastforward", &advice_push_nonfastforward },
+};
+
+int git_default_advice_config(const char *var, const char *value)
+{
+ const char *k = skip_prefix(var, "advice.");
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(advice_config); i++) {
+ if (strcmp(k, advice_config[i].name))
+ continue;
+ *advice_config[i].preference = git_config_bool(var, value);
+ return 0;
+ }
+
+ return 0;
+}
diff --git a/advice.h b/advice.h
new file mode 100644
index 0000000..862bae3
--- /dev/null
+++ b/advice.h
@@ -0,0 +1,8 @@
+#ifndef ADVICE_H
+#define ADVICE_H
+
+extern int advice_push_nonfastforward;
+
+int git_default_advice_config(const char *var, const char *value);
+
+#endif /* ADVICE_H */
diff --git a/builtin-push.c b/builtin-push.c
index 787011f..6eda372 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -157,7 +157,7 @@ static int do_push(const char *repo, int flags)
continue;
error("failed to push some refs to '%s'", url[i]);
- if (nonfastforward) {
+ if (nonfastforward && advice_push_nonfastforward) {
printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
"Merge the remote changes before pushing again. See the 'non-fast forward'\n"
"section of 'git push --help' for details.\n");
diff --git a/cache.h b/cache.h
index 5fad24c..e1ab092 100644
--- a/cache.h
+++ b/cache.h
@@ -4,6 +4,7 @@
#include "git-compat-util.h"
#include "strbuf.h"
#include "hash.h"
+#include "advice.h"
#include SHA1_HEADER
#ifndef git_SHA_CTX
diff --git a/config.c b/config.c
index e87edea..f21530c 100644
--- a/config.c
+++ b/config.c
@@ -627,6 +627,9 @@ int git_default_config(const char *var, const char *value, void *dummy)
if (!prefixcmp(var, "mailmap."))
return git_default_mailmap_config(var, value);
+ if (!prefixcmp(var, "advice."))
+ return git_default_advice_config(var, value);
+
if (!strcmp(var, "pager.color") || !strcmp(var, "color.pager")) {
pager_use_color = git_config_bool(var,value);
return 0;
--
1.6.5.rc0.173.g0bfef
^ permalink raw reply related
* [PATCH 2/2] status: make "how to stage" messages optional
From: Jeff King @ 2009-09-09 11:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090909112623.GA30765@coredump.intra.peff.net>
These messages are nice for new users, but experienced git
users know how to manipulate the index, and these messages
waste a lot of screen real estate.
Signed-off-by: Jeff King <peff@peff.net>
---
Most changes are just from rebasing on the prior patch.
Since advice.statusAdvice was a bit redundant, I switched it to
advice.statusHints. Just advice.status was a bit too vague for my taste,
especially as we might want something like advice.statusCurrentBranch or
something later. statusHints is a little vague, too, so I'm open to
suggestions.
This version retains the "compact" output of the last version. I.e., no
newline between header and files, as there would be with the hints.
Like:
# Changed but not updated:
modified: foo
I tried looking at it both with and without the newline, and didn't feel
strongly. My reasoning was that people turning off the hints are
probably interested in compactness. Suggestions welcome.
Documentation/config.txt | 4 ++++
advice.c | 2 ++
advice.h | 1 +
wt-status.c | 8 ++++++++
4 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a35b918..8cbabe8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -122,6 +122,10 @@ advice.*::
pushNonFastForward::
Advice shown when linkgit:git-push[1] refuses
non-fast-forward refs. Default: true.
+ statusHints::
+ Directions on how to stage/unstage/add shown in the
+ output of linkgit:git-status[1] and the template shown
+ when writing commit messages. Default: true.
--
core.fileMode::
diff --git a/advice.c b/advice.c
index b5216a2..ae4b1e8 100644
--- a/advice.c
+++ b/advice.c
@@ -1,12 +1,14 @@
#include "cache.h"
int advice_push_nonfastforward = 1;
+int advice_status_hints = 1;
static struct {
const char *name;
int *preference;
} advice_config[] = {
{ "pushnonfastforward", &advice_push_nonfastforward },
+ { "statushints", &advice_status_hints },
};
int git_default_advice_config(const char *var, const char *value)
diff --git a/advice.h b/advice.h
index 862bae3..e9df8e0 100644
--- a/advice.h
+++ b/advice.h
@@ -2,6 +2,7 @@
#define ADVICE_H
extern int advice_push_nonfastforward;
+extern int advice_status_hints;
int git_default_advice_config(const char *var, const char *value);
diff --git a/wt-status.c b/wt-status.c
index 85f3fcb..38eb245 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -48,6 +48,8 @@ static void wt_status_print_unmerged_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Unmerged paths:");
+ if (!advice_status_hints)
+ return;
if (!s->is_initial)
color_fprintf_ln(s->fp, c, "# (use \"git reset %s <file>...\" to unstage)", s->reference);
else
@@ -60,6 +62,8 @@ static void wt_status_print_cached_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Changes to be committed:");
+ if (!advice_status_hints)
+ return;
if (!s->is_initial) {
color_fprintf_ln(s->fp, c, "# (use \"git reset %s <file>...\" to unstage)", s->reference);
} else {
@@ -73,6 +77,8 @@ static void wt_status_print_dirty_header(struct wt_status *s,
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Changed but not updated:");
+ if (!advice_status_hints)
+ return;
if (!has_deleted)
color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to update what will be committed)");
else
@@ -85,6 +91,8 @@ static void wt_status_print_untracked_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Untracked files:");
+ if (!advice_status_hints)
+ return;
color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to include in what will be committed)");
color_fprintf_ln(s->fp, c, "#");
}
--
1.6.5.rc0.173.g0bfef
^ permalink raw reply related
* jk/1.7.0-status, was: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Jeff King @ 2009-09-09 11:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
On Mon, Sep 07, 2009 at 05:56:53PM -0700, Junio C Hamano wrote:
> * jk/1.7.0-status (2009-09-05) 5 commits
> - docs: note that status configuration affects only long format
> (merged to 'next' on 2009-09-07 at 8a7c563)
> + commit: support alternate status formats
> + status: add --porcelain output format
> + status: refactor format option parsing
> + status: refactor short-mode printing to its own function
> (this branch uses jc/1.7.0-status.)
>
> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
> is similar to that of post 1.7.0 "git status".
>
> It might be a good idea to make the --short format part of 1.6.6 without
> waiting for 1.7.0; it would require some branch shuffling to bring the
> short-status patch earlier than the one that makes "status" different from
> "commit --dry-run", though.
It looks like the short-status patch is already right before "commit
--dry-run", but it is of course part of "git stat". So we could get by
with branching from jc/1.7.0-status^, and do one of:
1. develop as if we were a totally separate topic, refactoring, adding
--porcelain mode, etc.
2. just support "--short" from "git status" with as small a change as
possible, and let the rest of the enhancements stay where they are,
for 1.7.0
Option (1) is what I would usually do, but I think in this case it is
just going to end up with me re-doing lots of work as the
almost-duplicated refactoring happening in the two branches is going to
make a gigantic conflict.
And of course option (3) is to just let --short rest until 1.7.0.
-Peff
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: Jeff King @ 2009-09-09 12:26 UTC (permalink / raw)
To: demerphq; +Cc: Sverre Rabbelier, Tim Visher, Git Mailing List
In-Reply-To: <9b18b3110909050758k597f917fn3baefa5fdb4741a0@mail.gmail.com>
On Sat, Sep 05, 2009 at 04:58:36PM +0200, demerphq wrote:
> It would be useful in for instance prompt status line. At $work we
> have a number of people using a prompt that includes the result of
> parsing git-status, but something --left-right-count would be much
> nicer, and if i understand it, more efficient (although maybe im
> wrong). In the prompt they use a number of different unicode arrows to
> show what has happened, with a Y type thing for diverged.
Well, if they are using the other bits of "git status" then it may not
be that inefficient compared to a "--left-right-count".
However, it sounds like they are not actually interested in the count,
but just the two bits of information: is A ahead of B, and is B ahead of
A (and then displaying one of four symbols as a result).
And getting that information is even more efficient than just a count,
because you don't have to traverse all of the commits. Though you do
still have to find the merge base, so I'm not sure how much you would be
saving in practice.
A "--left-right-count" does feel like an odd option to "git log" or "git
rev-list", as you are no longer logging or listing anything. In a way,
it makes more sense to me as a special output format of "git
merge-base".
Anyway, I think your example sounds like a reasonable application.
Personally, I do not use a git-enhanced prompt, so it is not my itch to
scratch (and I think a plumbing patch would only make sense if it was a
stepping stone to an actual application, which means somebody needs to
write the actual application).
-Peff
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Tay Ray Chuan @ 2009-09-09 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Tom Preston-Werner, Jakub Narebski
In-Reply-To: <be6fef0d0909080610j89c0a4bkf1cb0119b9b11db@mail.gmail.com>
Hi,
On Tue, Sep 8, 2009 at 9:10 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Tue, Sep 8, 2009 at 3:06 AM, Junio C Hamano<gitster@pobox.com> wrote:
>> I am torn about this.
>>
>> On one hand, if we are going to treat such a half failure as nothing
>> conclusive, I do not see a point to keep that check to begin with.
>>
>> On the other hand, if a HEAD request to a URL results in an unauthorized,
>> what plausible excuse the server operator could give for allowing a GET
>> request to the same URL? If we are going to keep the check if *.pack that
>> corresponds to the *.idx will be available, shouldn't we trust whatever
>> check we perform?
>
> I am in favour or removing this check, not just due to its
> unreliability, but for the sake of consistency (we very rarely send a
> HEAD request to poll data before doing a GET).
my patch below is in response to earlier deliberation.
I still think github.com should look into this issue (of differing
responses for HEAD and GET requests).
-- >8 --
Subject: [PATCH] http.c: remove verification of remote packs
Make http.c::fetch_pack_index() no longer check for the remote pack
with a HEAD request before fetching the corresponding pack index file.
Not only does sending a HEAD request before we do a GET incur a
performance penalty, it does not offer any significant error-
prevention advantages (pack fetching in the *_http_pack_request()
methods is capable of handling any errors on its own).
This addresses an issue raised elsewhere:
http://code.google.com/p/msysgit/issues/detail?id=323
http://support.github.com/discussions/repos/957-cant-clone-over-http-or-git
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Junio, I'm not sure if the credits and references ("This addresses...")
should be included, since the patch doesn't look like it's fixing any
thing, even though it is a response to an acknowledged issue.
Please remove those lines if you so wish.
http.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/http.c b/http.c
index 5926c5b..84def9f 100644
--- a/http.c
+++ b/http.c
@@ -869,17 +869,6 @@ static int fetch_pack_index(unsigned char *sha1, const char *base_url)
char *url;
struct strbuf buf = STRBUF_INIT;
- /* Don't use the index if the pack isn't there */
- end_url_with_slash(&buf, base_url);
- strbuf_addf(&buf, "objects/pack/pack-%s.pack", hex);
- url = strbuf_detach(&buf, 0);
-
- if (http_get_strbuf(url, NULL, 0)) {
- ret = error("Unable to verify pack %s is available",
- hex);
- goto cleanup;
- }
-
if (has_pack_index(sha1)) {
ret = 0;
goto cleanup;
--
1.6.4.2
^ permalink raw reply related
* Problem with "dashless options"
From: Henrik Tidefelt @ 2009-09-09 13:21 UTC (permalink / raw)
To: git
Hi,
Yesterday I installed a fresh git (1.6.4.2) on my system using
MacPorts. Some of the git sub-commands work fine (for instance,
checkout, status, remote), while push gives an error as follows:
$ git push isy next
fatal: BUG: dashless options don't support arguments
The same thing happens when I do
$ git push --repo=isy next
Since this seems to be a rather severe problem, I suppose it is that
it is related to the old and perhaps unusual platform I am using. It
is a PowerPC machine running Mac OS 10.4, with GCC powerpc-apple-
darwin8-gcc-4.0.1 and MacPorts 1.8.0.
I'll be happy to provide additional information that might help.
Best regards,
Henrik Tidefelt
^ permalink raw reply
* Re: Problem with "dashless options"
From: Jeff King @ 2009-09-09 14:34 UTC (permalink / raw)
To: Henrik Tidefelt; +Cc: git
In-Reply-To: <D69FA890-4249-4DC9-B8AE-C9F105F1AD3B@isy.liu.se>
On Wed, Sep 09, 2009 at 03:21:30PM +0200, Henrik Tidefelt wrote:
> Yesterday I installed a fresh git (1.6.4.2) on my system using
> MacPorts. Some of the git sub-commands work fine (for instance,
> checkout, status, remote), while push gives an error as follows:
>
> $ git push isy next
> fatal: BUG: dashless options don't support arguments
Hmm. Very strange. The only code path that triggers this is an option
declared with PARSE_OPT_NODASH but not PARSE_OPT_NOARG. But there are
only two options in all of git that use PARSE_OPT_NODASH, and:
1. They are in git grep, not git push.
2. They correctly have PARSE_OPT_NOARG set.
Which leads me to believe that something is writing random cruft on top
of the options struct. Either a stack overflow, or some issue related to
your compiler (either a bug in the compiler, or something non-portable
we are doing).
Can you try applying the patch below which will at least give us a bit
more information about the offending option?
Also, does 1.6.4.1 work OK? Or any other earlier version? If so, can you
try bisecting?
diff --git a/parse-options.c b/parse-options.c
index f7ce523..e93eb67 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -275,7 +275,15 @@ static int parse_nodash_opt(struct parse_opt_ctx_t *p, const char *arg,
continue;
if ((options->flags & PARSE_OPT_OPTARG) ||
!(options->flags & PARSE_OPT_NOARG))
- die("BUG: dashless options don't support arguments");
+ die("BUG: dashless options don't support arguments\n"
+ "buggy option is:\n"
+ " type: %d\n"
+ " short_name: %c\n"
+ " long_name: %s\n"
+ " flags: %d\n",
+ options->type, options->short_name,
+ options->long_name, options->flags
+ );
if (!(options->flags & PARSE_OPT_NONEG))
die("BUG: dashless options don't support negation");
if (options->long_name)
^ permalink raw reply related
* Funktion like "last commit time" in SVN
From: Benjamin.Glasebach @ 2009-09-09 14:40 UTC (permalink / raw)
To: git
Hello,
does GIT have any Funktion "last commit time" like in SVN?
So that the create and change-time don't change.
Thanks
EISENMANN Anlagenbau GmbH & Co. KG
i.A. Benjamin Glasebach
Postfach 1280 - 71002 Böblingen
Tübinger Straße 81 - 71032 Böblingen
Tel.: +49 7031 78-1632
Fax.: +49 7031 78-22 1632
E-Mail: Benjamin.Glasebach@eisenmann.com
Internet: http://www.eisenmann.com
_________________________________________________________________________
Sitz: Böblingen, AG Stuttgart HRA 241890
USt.-IdNr.: DE 145 141 525
Persönlich haftende Gesellschafterin: EISENMANN Anlagenbau Verwaltung GmbH;
Sitz: Böblingen, AG Stuttgart HRB 245853
Geschäftsführer: Dr. Matthias von Krauland, Dr. Thomas Beck, Dr. Kersten
Christoph Link, Werner Schuster, Ralf Völlinger
Diese E-Mail sowie etwaige Anlagen sind ausschließlich für den Adressaten
bestimmt und können vertrauliche oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Empfänger sind,
unterrichten Sie bitte den Absender und vernichten Sie diese Mail.
Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese
E-Mail zu speichern, weiterzuleiten oder ihren Inhalt, auf welche Weise
auch immer, zu verwenden. Wir verwenden aktuelle Virenschutzprogramme.
Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte, mit
Viren befallene E-Mails entstehen, schließen wir jede Haftung aus.
The information contained in this e-mail or attachments is intended only
for its addressee and may contain confidential and/or privileged
information. If you have received this e-mail in error, please notify
the sender and delete the e-mail. If you are not the intended recipient,
you are hereby notified, that saving, distribution or use of the
content of this e-mail in any way is prohibited. We use updated virus
protection software. We do not accept any responsibility for damages
caused anyhow by viruses transmitted via e-mail.
^ permalink raw reply
* Re: Funktion like "last commit time" in SVN
From: Bruce Stephens @ 2009-09-09 14:53 UTC (permalink / raw)
To: Benjamin.Glasebach; +Cc: git
In-Reply-To: <OFDE6223D3.9B58FBF2-ONC125762C.00502B15-C125762C.005096F0@EISENMANN.DE>
Benjamin.Glasebach@eisenmann.com writes:
> does GIT have any Funktion "last commit time" like in SVN?
> So that the create and change-time don't change.
I don't know exactly what SVN does. Does this help,
<http://git.or.cz/gitwiki/ExampleScripts#Settingthetimestampsofthefilestothecommittimestampofthecommitwhichlasttouchedthem>?
[...]
^ permalink raw reply
* [PATCH] rebase: use plumbing to show dirty state
From: Jeff King @ 2009-09-09 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
Commit 4cfbe06 introduced the use of "git diff" to show
dirty state in a format more familiar to users. However, it
should have used the plumbing "git diff-files" instead.
Not only is it good practice in general to use plumbing in
scripts, but in this case we really don't want the automatic
pager to kick in for an error message.
Signed-off-by: Jeff King <peff@peff.net>
---
I got quite a surprise when I ran "git rebase" and was presented with a
pager with nothing but:
M foo.c
in it. I suspect this issue wasn't noticed while testing because most
people use "-FX" with "less", so their short list of dirty files causes
the pager to exit immediately.
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 2315d95..6ec155c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -387,7 +387,7 @@ fi
# The tree must be really really clean.
if ! git update-index --ignore-submodules --refresh > /dev/null; then
echo >&2 "cannot rebase: you have unstaged changes"
- git diff --name-status -r --ignore-submodules -- >&2
+ git diff-files --name-status -r --ignore-submodules -- >&2
exit 1
fi
diff=$(git diff-index --cached --name-status -r --ignore-submodules HEAD --)
--
1.6.5.rc0.166.ge65f.dirty
^ permalink raw reply related
* git-cvsserver man page needs examples...
From: david.hagood @ 2009-09-09 16:00 UTC (permalink / raw)
To: git
I'm trying to work out how I can use git-cvsserver on a local repository
to allow a stupid program that only understands CVS to work.
I've looked over the man page, but it really isn't clear as to what the
command lines and settings would look like. There seems to be a lot of
assumptions in the man page that aren't spelled out, such as the
assumption that you are making a repo available to many other hosts.
There is the tantalizing hint that "you can rename git-cvsserver to cvs"
which would lead me to believe that I might just be able to point the
stupid program at git-cvsserver and be done with it, but that doesn't
really seem clear.
It also isn't clear what effect operations on the repo, such as "git
checkout", would have on the view that the CVS client sees - if any at
all.
Then there is the statement "You also need to ensure that each repository
is "bare" (without a git index file) for cvs commit to work." Does that
mean that I have to have a repository that operates differently for CVS
commit to work than a standard repository for local use?
Might I suggest that the man page either contain or point to some examples
of using git-cvsserver for different use cases, such as:
local repo and server, for stupid programs that speak CVS but not GIT.
local repo and server exporting to other workstations.
I haven't found any good examples on-line of how to achieve these goals -
just reiterations of the man pages.
^ permalink raw reply
* Re: [PATCH] git.el: Use git-add-file for unmerged files, remove git-resolve-file
From: Alexandre Julliard @ 2009-09-09 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Nordholts, git
In-Reply-To: <7vtyzdrq1h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I do not know all the details of how Emacs keybinding works, but I had an
> impression that something-x sequence is triggered if you type something-X
> and you do not have an explicit binding for something-X but you do have a
> binding for something-x.
>
> IOW, if I only have
>
> (define-key global-map "\C-xc" 'compile)
>
> then both "\C-xc" and "\C-xC" runs "compile", but in addition to the
> above if I also have
>
> (define-key global-map "\C-xC" 'grep-find)
>
> then I can invoke these two commands with lower- and upper- case 'c/C'
> after control-x.
>
> If people have been relying on the historical behaviour that typing "R"
> marked the path resolved (which may internally have been implemented with
> whatever way), and if you are removing that binding, wouldn't that now
> expose them to whatever happens to be bound to "r"?
No, I don't claim to understand exactly how that works for the C-x case,
but it doesn't apply here, "r" and "R" are two different bindings.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: Problem with "dashless options"
From: Henrik Tidefelt @ 2009-09-09 16:26 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090909143455.GA10092@sigill.intra.peff.net>
Yes, that was a strange error. I applied the patch, but could not
reproduce the error any more. Also, Gustaf Hendeby built git
directly from the git distribution (not via MacPorts) on my machine,
and could not reproduce the error. Then I simply tried to clean and
build the git from MacPorts again, and voila!, now it works.
Something very strange must have happened during the previous build.
I am sorry for taking your time.
Henrik
On 9Sep , 2009, at 16:34 , Jeff King wrote:
> On Wed, Sep 09, 2009 at 03:21:30PM +0200, Henrik Tidefelt wrote:
>
>> Yesterday I installed a fresh git (1.6.4.2) on my system using
>> MacPorts. Some of the git sub-commands work fine (for instance,
>> checkout, status, remote), while push gives an error as follows:
>>
>> $ git push isy next
>> fatal: BUG: dashless options don't support arguments
>
> Hmm. Very strange. The only code path that triggers this is an option
> declared with PARSE_OPT_NODASH but not PARSE_OPT_NOARG. But there are
> only two options in all of git that use PARSE_OPT_NODASH, and:
>
> 1. They are in git grep, not git push.
>
> 2. They correctly have PARSE_OPT_NOARG set.
>
> Which leads me to believe that something is writing random cruft on
> top
> of the options struct. Either a stack overflow, or some issue
> related to
> your compiler (either a bug in the compiler, or something non-portable
> we are doing).
>
> Can you try applying the patch below which will at least give us a bit
> more information about the offending option?
>
> Also, does 1.6.4.1 work OK? Or any other earlier version? If so,
> can you
> try bisecting?
>
> diff --git a/parse-options.c b/parse-options.c
> index f7ce523..e93eb67 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -275,7 +275,15 @@ static int parse_nodash_opt(struct
> parse_opt_ctx_t *p, const char *arg,
> continue;
> if ((options->flags & PARSE_OPT_OPTARG) ||
> !(options->flags & PARSE_OPT_NOARG))
> - die("BUG: dashless options don't support arguments");
> + die("BUG: dashless options don't support arguments\n"
> + "buggy option is:\n"
> + " type: %d\n"
> + " short_name: %c\n"
> + " long_name: %s\n"
> + " flags: %d\n",
> + options->type, options->short_name,
> + options->long_name, options->flags
> + );
> if (!(options->flags & PARSE_OPT_NONEG))
> die("BUG: dashless options don't support negation");
> if (options->long_name)
^ permalink raw reply
* Re: Problem with "dashless options"
From: Pierre Habouzit @ 2009-09-09 16:30 UTC (permalink / raw)
To: Henrik Tidefelt; +Cc: Jeff King, git
In-Reply-To: <AB9C50E3-E2BB-4449-B8F9-75777ADE1602@isy.liu.se>
On Wed, Sep 09, 2009 at 06:26:37PM +0200, Henrik Tidefelt wrote:
> Yes, that was a strange error. I applied the patch, but could not
> reproduce the error any more. Also, Gustaf Hendeby built git
> directly from the git distribution (not via MacPorts) on my machine,
> and could not reproduce the error. Then I simply tried to clean and
> build the git from MacPorts again, and voila!, now it works.
> Something very strange must have happened during the previous build.
Are you using a keyboard mapping where AltGr+space produces an ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
^ permalink raw reply
* [ JGIT ] incompatiblity found in DirCache
From: Adam W. Hawks @ 2009-09-09 18:55 UTC (permalink / raw)
To: git
When using the DirCache interface to the index you can create a invalid/corrupt tree for git 1.6.5.
The problem seems to be you can add a path to the index that starts with a "/" and DirCache creates a entry with a mode but no path.
This causes git 1.6.5 to fail with a corrupt tree.
The following code will create the problem
import java.io.File;
import java.io.IOException;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
import org.spearce.jgit.dircache.DirCache;
import org.spearce.jgit.dircache.DirCacheBuilder;
import org.spearce.jgit.dircache.DirCacheEntry;
import org.spearce.jgit.lib.Commit;
import org.spearce.jgit.lib.FileMode;
import org.spearce.jgit.lib.ObjectId;
import org.spearce.jgit.lib.ObjectWriter;
import org.spearce.jgit.lib.PersonIdent;
import org.spearce.jgit.lib.RefUpdate;
import org.spearce.jgit.lib.Repository;
import org.spearce.jgit.lib.RefUpdate.Result;
public class BuildTest
{
private Repository db;
public static void main(String[] args)
{
BuildTest bt = new BuildTest();
bt.doit();
}
public void doit()
{
Date when = Calendar.getInstance().getTime();
File gitDir = new File("gitProblem/.git");
gitDir.mkdirs();
try
{
db = new Repository(gitDir);
db.create(true);
DirCache dirc = DirCache.newInCore();
DirCacheBuilder dcb = dirc.builder();
byte[] data = "Some File data".getBytes();
ObjectWriter ow = new ObjectWriter(db);
ObjectId dataId = ow.writeBlob(data);
DirCacheEntry newEntry = new DirCacheEntry("/someDir/someFile");
newEntry.setAssumeValid(false);
newEntry.setFileMode(FileMode.REGULAR_FILE);
newEntry.setLastModified(when.getTime());
newEntry.setLength(data.length);
newEntry.setObjectId(dataId);
dcb.add(newEntry );
dcb.finish();
dirc = dcb.getDirCache();
PersonIdent pi = new PersonIdent("someonw","someone@somewhere",when,TimeZone.getDefault());
ObjectId tree = dirc.writeTree(new ObjectWriter(db));
Commit commit = new Commit(db);
commit.setAuthor(pi);
commit.setCommitter(pi);
commit.setMessage("This causes a corrupt tree");
commit.setTreeId(tree);
commit.commit();
ObjectId cid = commit.getCommitId();
RefUpdate ru = db.updateRef("refs/heads/master");
ru.setExpectedOldObjectId(ObjectId.zeroId());
ru.setNewObjectId(cid);
ru.setRefLogIdent(pi);
ru.setRefLogMessage("some reflog message", true);
Result result = ru.update();
System.out.println("Result = "+result.toString());
}
catch (IOException e)
{
System.out.println(e);
e.printStackTrace();
System.exit(1);
}
}
}
^ permalink raw reply
* Re: [PATCH 1/2] push: make non-fast-forward help message configurable
From: Junio C Hamano @ 2009-09-09 19:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090909113858.GA31051@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/advice.c b/advice.c
> new file mode 100644
> index 0000000..b5216a2
> --- /dev/null
> +++ b/advice.c
> @@ -0,0 +1,25 @@
> +#include "cache.h"
> +
> +int advice_push_nonfastforward = 1;
> +
> +static struct {
> + const char *name;
> + int *preference;
> +} advice_config[] = {
> + { "pushnonfastforward", &advice_push_nonfastforward },
> +};
Can we have the value inside this struct, instead of having a pointer
to another variable, and get rid of that variable altogether?
> diff --git a/builtin-push.c b/builtin-push.c
> index 787011f..6eda372 100644
> --- a/builtin-push.c
> +++ b/builtin-push.c
> @@ -157,7 +157,7 @@ static int do_push(const char *repo, int flags)
> continue;
>
> error("failed to push some refs to '%s'", url[i]);
> - if (nonfastforward) {
> + if (nonfastforward && advice_push_nonfastforward) {
If we did so, this part needs to become
if (nonfastforward && check_advice("pushnonfastforward")) {
which would be less efficient, but by definition advices are on the slow
path, right?
And check_advice() implementation can find programming errors by barfing
when the given string token does not exist in the table.
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Junio C Hamano @ 2009-09-09 19:08 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Junio C Hamano, git, msysgit, Tom Preston-Werner, Jakub Narebski
In-Reply-To: <20090909203350.e3d7e5dc.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> I still think github.com should look into this issue (of differing
> responses for HEAD and GET requests).
>
> -- >8 --
>
> Subject: [PATCH] http.c: remove verification of remote packs
>
> Make http.c::fetch_pack_index() no longer check for the remote pack
> with a HEAD request before fetching the corresponding pack index file.
>
> Not only does sending a HEAD request before we do a GET incur a
> performance penalty, it does not offer any significant error-
> prevention advantages (pack fetching in the *_http_pack_request()
> methods is capable of handling any errors on its own).
>
> This addresses an issue raised elsewhere:
>
> http://code.google.com/p/msysgit/issues/detail?id=323
> http://support.github.com/discussions/repos/957-cant-clone-over-http-or-git
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
>
> Junio, I'm not sure if the credits and references ("This addresses...")
> should be included, since the patch doesn't look like it's fixing any
> thing, even though it is a response to an acknowledged issue.
>
> Please remove those lines if you so wish.
I think the backstory deserves to be recorded in this case, which is what
you did.
Thanks.
^ permalink raw reply
* Re: [PATCH] git.el: Use git-add-file for unmerged files, remove git-resolve-file
From: Junio C Hamano @ 2009-09-09 19:10 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: Martin Nordholts, git
In-Reply-To: <87ocpk6qwe.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I do not know all the details of how Emacs keybinding works, but I had an
>> impression that something-x sequence is triggered if you type something-X
>> and you do not have an explicit binding for something-X but you do have a
>> binding for something-x.
>>
>> IOW, if I only have
>>
>> (define-key global-map "\C-xc" 'compile)
>>
>> then both "\C-xc" and "\C-xC" runs "compile", but in addition to the
>> above if I also have
>>
>> (define-key global-map "\C-xC" 'grep-find)
>>
>> then I can invoke these two commands with lower- and upper- case 'c/C'
>> after control-x.
>>
>> If people have been relying on the historical behaviour that typing "R"
>> marked the path resolved (which may internally have been implemented with
>> whatever way), and if you are removing that binding, wouldn't that now
>> expose them to whatever happens to be bound to "r"?
>
> No, I don't claim to understand exactly how that works for the C-x case,
> but it doesn't apply here, "r" and "R" are two different bindings.
Thanks. I just wanted to make sure that a user who is used to typing "R"
won't get the file removed with the new code.
^ permalink raw reply
* [PATCH] preserve mtime of local clone
From: Clemens Buchacher @ 2009-09-09 19:51 UTC (permalink / raw)
To: git; +Cc: msysgit, Junio C Hamano, Shawn O. Pearce
A local clone without hardlinks copies all objects, including dangling
ones, to the new repository. Since the mtimes are renewed, those
dangling objects cannot be pruned by "git gc --prune", even if they
would have been old enough for pruning in the original repository.
Instead, preserve mtime during copy. "git gc --prune" will then work
in the clone just like it would have in the original.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
I noticed this problem when I cloned a repo with lots of old dangling
objects onto a windows machine. git-gui immediately recommended running
git-gc, and I did. But each time I restarted git-gui, it recommended git-gc
again, because there were still plenty of dangling objects lying around
which could not be removed due to their recent mtimes.
So there is actually a problem with git-gui's recommendation. Especially on
Windows, where it only checks for 1 or more files in .git/objects/42 (as
opposed to 8 files on other platforms). The probability of that happening if
the repo contains about 100 loose objects is 1-(254/255)^100 = 32%. The
probability for the same to happen with at least 2 files is only 6% [*].
Maybe that would be a good compromise?
Alternatively, git-gc could remember the number of dangling objects, and
git-gui can adjust its recommendation accordingly, taking that number and
the date of the lastest repack into account.
Clemens
[*] The following octave script shows the probability for m or more objects
to be in .git/objects/42 for a total of n objects.
m = [1 2 8];
n = 100:100:3000;
P = zeros(length(n), length(m));
for k = 1:length(n)
P(n(k), :) = 1-binocdf(m-1, n(k), 1/255);
end
plot(n, P);
n \ m 1 2 8
100 32% 6% 0%
500 86% 58% 0%
1000 98% 90% 5%
2000 100% 100% 55%
---
builtin-clone.c | 2 +-
builtin-init-db.c | 2 +-
cache.h | 6 ++++--
copy.c | 25 ++++++++++++++++++++++---
lockfile.c | 2 +-
rerere.c | 2 +-
6 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index ad04808..cb3c895 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -269,7 +269,7 @@ static void copy_or_link_directory(struct strbuf *src, struct strbuf *dest)
die_errno("failed to create link '%s'", dest->buf);
option_no_hardlinks = 1;
}
- if (copy_file(dest->buf, src->buf, 0666))
+ if (copy_file(dest->buf, src->buf, 0666, 1))
die_errno("failed to copy file to '%s'", dest->buf);
}
closedir(dir);
diff --git a/builtin-init-db.c b/builtin-init-db.c
index dd84cae..5deb81d 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -100,7 +100,7 @@ static void copy_templates_1(char *path, int baselen,
die_errno("cannot symlink '%s' '%s'", lnk, path);
}
else if (S_ISREG(st_template.st_mode)) {
- if (copy_file(path, template, st_template.st_mode))
+ if (copy_file(path, template, st_template.st_mode, 0))
die_errno("cannot copy '%s' to '%s'", template,
path);
}
diff --git a/cache.h b/cache.h
index 5fad24c..1875c97 100644
--- a/cache.h
+++ b/cache.h
@@ -921,8 +921,10 @@ extern const char *git_mailmap_file;
/* IO helper functions */
extern void maybe_flush_or_die(FILE *, const char *);
-extern int copy_fd(int ifd, int ofd);
-extern int copy_file(const char *dst, const char *src, int mode);
+extern int copy_fd(int ifd, int ofd, int preserve_times);
+extern int copy_file(const char *dst, const char *src, int mode, int
+ preserve_times);
+extern int copy_times(int ofd, int ifd);
extern ssize_t read_in_full(int fd, void *buf, size_t count);
extern ssize_t write_in_full(int fd, const void *buf, size_t count);
extern void write_or_die(int fd, const void *buf, size_t count);
diff --git a/copy.c b/copy.c
index e54d15a..fe0380e 100644
--- a/copy.c
+++ b/copy.c
@@ -1,6 +1,6 @@
#include "cache.h"
-int copy_fd(int ifd, int ofd)
+int copy_fd(int ifd, int ofd, int preserve_times)
{
while (1) {
char buffer[8192];
@@ -31,11 +31,18 @@ int copy_fd(int ifd, int ofd)
}
}
}
+ if (preserve_times && copy_times(ofd, ifd)) {
+ int time_error = errno;
+ close(ifd);
+ return error("copy-fd: failed to preserve times: %s",
+ strerror(time_error));
+ }
close(ifd);
return 0;
}
-int copy_file(const char *dst, const char *src, int mode)
+int copy_file(const char *dst, const char *src, int mode,
+ int preserve_times)
{
int fdi, fdo, status;
@@ -46,7 +53,7 @@ int copy_file(const char *dst, const char *src, int mode)
close(fdi);
return fdo;
}
- status = copy_fd(fdi, fdo);
+ status = copy_fd(fdi, fdo, preserve_times);
if (close(fdo) != 0)
return error("%s: close error: %s", dst, strerror(errno));
@@ -55,3 +62,15 @@ int copy_file(const char *dst, const char *src, int mode)
return status;
}
+
+int copy_times(int ofd, int ifd)
+{
+ struct stat st;
+ struct timespec times[2];
+ if (fstat(ifd, &st))
+ return -1;
+ times[0].tv_nsec = UTIME_OMIT;
+ times[1].tv_sec = st.st_mtime;
+ times[1].tv_nsec = ST_MTIME_NSEC(st);
+ return futimens(ofd, times);
+}
diff --git a/lockfile.c b/lockfile.c
index eb931ed..c7bbd4d 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -196,7 +196,7 @@ int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
close(fd);
return error("cannot open '%s' for copying", path);
}
- } else if (copy_fd(orig_fd, fd)) {
+ } else if (copy_fd(orig_fd, fd, 0)) {
if (flags & LOCK_DIE_ON_ERROR)
exit(128);
close(fd);
diff --git a/rerere.c b/rerere.c
index 87360dc..d25f5f1 100644
--- a/rerere.c
+++ b/rerere.c
@@ -326,7 +326,7 @@ static int do_plain_rerere(struct string_list *rr, int fd)
continue;
fprintf(stderr, "Recorded resolution for '%s'.\n", path);
- copy_file(rerere_path(name, "postimage"), path, 0666);
+ copy_file(rerere_path(name, "postimage"), path, 0666, 0);
mark_resolved:
rr->items[i].util = NULL;
}
--
1.6.4.2.266.gbaa17
^ permalink raw reply related
* Re: [PATCH 1/2] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-09 20:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <7vr5ugszte.fsf@alter.siamese.dyndns.org>
On Wed, Sep 09, 2009 at 12:06:21PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > diff --git a/advice.c b/advice.c
> > new file mode 100644
> > index 0000000..b5216a2
> > --- /dev/null
> > +++ b/advice.c
> > @@ -0,0 +1,25 @@
> > +#include "cache.h"
> > +
> > +int advice_push_nonfastforward = 1;
> > +
> > +static struct {
> > + const char *name;
> > + int *preference;
> > +} advice_config[] = {
> > + { "pushnonfastforward", &advice_push_nonfastforward },
> > +};
>
> Can we have the value inside this struct, instead of having a pointer
> to another variable, and get rid of that variable altogether?
We could, but then callers need some way of indexing into the array.
Which means either:
- a constant offset (like "#define ADVICE_PUSH_NONFASTFORWARD 0"). The
problem with that is you get no compile-time support for making sure
that your index matches the variable you want. I.e., you have:
{ "pushnonfastforward", 1 } /* ADVICE_PUSH_NONFASTFORWARD */
with the position in the array implicitly matching the manually
assigned numbers. We do have precedent in things like diff_colors.
I don't remember if we have ever screwed it up.
- a dynamic offset, like (as you noted):
> If we did so, this part needs to become
>
> if (nonfastforward && check_advice("pushnonfastforward")) {
>
> which would be less efficient, but by definition advices are on the slow
> path, right?
which, as you note, is less efficient. It also turns typo-checking into
a run-time error rather than a compile-time error, which is IMHO a bad
idea. And if you care about such things, it is worse for using something
like ctags to find variable uses.
I went the way I did because it provides compile-time checking, and
because the variable is referred to by name in the table, the matching
is explicit and thus harder to screw up.
One final option would be to get rid of the table altogether. Its
function is to allow you to iterate over all of the variables. Now that
the "advice.all" option has been dropped, the only use is during config
parsing. We could simply unroll that loop to:
if (!strcmp(k, "pushnonfastforward")) {
advice_push_nonfastforward = git_config_bool(var, value);
return 0;
}
if (!strcmp(k, "statushints")) {
advice_status_hints = git_config_bool(var, value);
return 0;
}
as we do in other config parsing.
-Peff
^ permalink raw reply
* Re: [ JGIT ] incompatiblity found in DirCache
From: Robin Rosenberg @ 2009-09-09 21:11 UTC (permalink / raw)
To: Adam W. Hawks, spearce; +Cc: git
In-Reply-To: <4AA7FA2B.4090707@writeme.com>
onsdag 09 september 2009 20:55:39 skrev "Adam W. Hawks" <awhawks@writeme.com>:
> When using the DirCache interface to the index you can create a invalid/corrupt tree for git 1.6.5.
>
> The problem seems to be you can add a path to the index that starts with a "/" and DirCache creates a entry with a mode but no path.
> This causes git 1.6.5 to fail with a corrupt tree.
I think there are more ways of entering bad stuff. Preventing a deliberate programmatic creation of invalid trees is probably not the most important
thing, but then again, validating the data to prevent e.g. the EGit plugin from doing it by mistake due to bugs could probably
be worthwhile.
-- robin
^ permalink raw reply
* Re: Problem with "dashless options"
From: Henrik Tidefelt @ 2009-09-09 21:12 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Jeff King, git
In-Reply-To: <20090909163001.GE4859@laphroaig.corp>
No, but it is mapped to WHITE FROWNING FACE; I guess I defined it so
to avoid the trouble I was previously experiencing from accidentally
typing the instead of space without being able to see the
difference on screen. Why would it matter?
Henrik
On 09-09-09, at 18:30 , Pierre Habouzit wrote:
> On Wed, Sep 09, 2009 at 06:26:37PM +0200, Henrik Tidefelt wrote:
>> Yes, that was a strange error. I applied the patch, but could not
>> reproduce the error any more. Also, Gustaf Hendeby built git
>> directly from the git distribution (not via MacPorts) on my machine,
>> and could not reproduce the error. Then I simply tried to clean and
>> build the git from MacPorts again, and voila!, now it works.
>> Something very strange must have happened during the previous build.
>
> Are you using a keyboard mapping where AltGr+space produces an
> ?
>
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
^ permalink raw reply
* obnoxious CLI complaints
From: Brendan Miller @ 2009-09-09 21:27 UTC (permalink / raw)
To: git
Here are a bunch of really basic usability issues I have with git:
1. cloning from a new empty repo fails, and so do a lot of other
operations. This adds unnecessary steps to setting up a new shared
repo.
2. git --bare init. The flag goes before the operation unlike every other flag?
3. It's not obvious whether operations work on the working
directory/the "index"/the repository
e.g. get reset --soft, --mixed, --hard. git diff --cached
4. The index is inconsistently referred to as too many different
things (cache, index, staging area) and only the last one makes any
intuitive sense to a new user. This is partially a CLI issue, and
partially a documentation issue, but both add up to cause confusion.
5. Most commands require lots of flags, and don't have reasonable
defaults. e.g. archive.
git archive --format=tar --prefix=myproject/ HEAD | gzip >myproject.tar.gz
Should just be:
git archive
run from the root of the repo.
This is what I want to do 90% of the time, so it should just have the
proper defaults, and not make me look at the man page every time I
want to use it.
6. Where is the bug tracker? If people users can't find the bug
tracker, they can't report issues, and obnoxious bugs go unfixed, or
people have to whine on the mailing list. There should be a nice big
link on the front page of git-scm.com. A bug tracker is really the
only way for the vast majority of a community that use a tool can give
feedback on the problems the tool has.
7. Man pages: It's nice we have them, but we shouldn't need them to do
basic stuff. I rarely had to look at the man pages using svn, but
every single time I use git I have to dig into these things. Frankly,
I have better things to do than RTFM.
8. There's no obvious way to make a remote your default push pull
location without editing the git config file. Why not just something
like
git remote setdefault origin
or even
git remote add --default origin http://somegiturl.org/
This come up in the use case where I:
1. set up a remote bare repo
2. push from my local repo, and thence forth want to keep local and
remote in sink.
Right now I have to modify .git/config to do this.
It's ok to have kind of a weak UI on a new tool, when people are busy
adding basic functionality. However, at this point git already has way
more features than most of the competition, and the needless
complexity of the CLI is the biggest issue in day to day use.
Brendan
^ 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