* Re: [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Junio C Hamano @ 2009-10-19 6:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <81b0412b0910182312h583e74e4v2678eb4375164c34@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> On Mon, Oct 19, 2009 at 08:07, Alex Riesen <raa.lkml@gmail.com> wrote:
>> On Mon, Oct 19, 2009 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>> + OPT_SET_INT(0, "dwim", &dwim_new_local_branch,
>>>> + "Guess local branch from remote reference (default)", 0),
>>>
>>> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0
>>> with --no-dwim?
>>
>> It seems to do, though (I checked before sending).
>>
>
> Right, just looked at the parse-options: it is defined for all types.
>
> parse-options.c +/get_value
>
> const int unset = flags & OPT_UNSET;
> ...
> case OPTION_SET_INT:
> *(int *)opt->value = unset ? 0 : opt->defval;
> return 0;
>
> Very useful.
Ah, did you mean to change the default value to 1 as well?
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Johannes Sixt @ 2009-10-19 6:21 UTC (permalink / raw)
To: Norbert Preining; +Cc: Daniel Barkalow, git
In-Reply-To: <20091019004447.GC11739@gamma.logic.tuwien.ac.at>
Norbert Preining schrieb:
> On So, 18 Okt 2009, Daniel Barkalow wrote:
>> of the *content* is non-linear, the sequence of values stored in
>> refs/heads/master on your central server is linear, local, and easy to
>> enumerate.
>
> That is exactely what I need.
You can always run 'git rev-list master | wc -l' to get a sequence number.
You can throw in --first-parent if you do not want to count commits that
entered master through a merge commit.
You can configure your reflogs such that they do not expire. Then you
count the entries in the reflog.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Jeff King @ 2009-10-19 6:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vbpk4aqop.fsf@alter.siamese.dyndns.org>
On Sun, Oct 18, 2009 at 10:38:46PM -0700, Junio C Hamano wrote:
> > -*NOTE*: Obviously, if you change anything else than the first character
> > -on lines beginning with a space or a minus, the patch will no longer
> > -apply.
> > +The intent of this option is to pick and choose lines of the diff to
>
> I'd slightly prefer "patch" over "diff" in this context.
Sure, I have no problem with that.
> > +apply, or even to modify the contents of lines to be staged. There are
> > +three line types in a diff: addition lines (beginning with a plus),
> > +removal lines (beginning with a minus), and context lines (beginning
> > +with a space). In general, it should be safe to:
> > ++
> > +--
> > +* remove addition lines (don't stage the line)
>
> This is more like "don't add the line", isn't it? Also if this "+" line
> has corresponding "-" line (i.e. it is a "rewrite to this" line), removal
> of such a line would mean "instead of rewriting, remove it".
I was trying not to use "add" because we are already talking about
addition and removal in the patch itself, and I thought it made sense to
map those actions to what the user is conceptually doing (staging or not
staging). Of course, I used "remove" which has a similar problem (you
are removing the addition of the line to the index); probably "delete"
would have been better. So I am not sure I agree that using "add" is any
better than "stage", but I don't feel that strongly about it.
But beyond that, yes, you are right that removing a "+" line may have a
different conceptual meaning to the user depending on the surrounding
text. I wonder if such a "check-list" document really makes much sense,
given that using "-e" at all means you need to understand the patch
format and what makes sense (i.e., anybody who understands 'patch' knows
that you can't just delete context lines and expect it to apply).
> Obviously, the above patch is what "diff --cached" would show after such
> an "add -e", but this does _not_ touch anything in the work tree (which is
> correct; add is about moving changed contents to the index and it should
> fundamentally not affect work tree). As a result, "diff" between the
> index and the work tree now would read like this:
>
> diff --git a/t-f b/t-f
> index 17c3f0b..d68dd40 100644
> --- a/t-f
> +++ b/t-f
> @@ -1,3 +1,4 @@
> a
> -e
> +b
> +c
> d
>
> IOW, your request to "add -e" was "I do not want to put the addition of
> 'c' in the index at this point (that is why you removed '+c')" and "I do
> not want to put the addition of 'b' in the index; I want 'e' instead (that
> is why you changed '+b' to '+e')". After "add -e" granted both requests,
> what is left in the work tree can confuse the user. The "not at this
Yeah, again, this comes down to understanding what you are doing:
applying a patch to the index. So it really requires that the user
understand what that means. Maybe instead of trying to enumerate cases
and their effects, we should just say sometihng like "this is a patch to
the index. While you can make arbitrary changes, keep in mind that (1)
your changes must apply to the content in the index, and (2) any new
changes you introduce in the patch will not be reflected in the working
tree".
-Peff
^ permalink raw reply
* Re: Unapplied patches reminder
From: Jeff King @ 2009-10-19 6:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7v63aci8id.fsf@alter.siamese.dyndns.org>
On Sun, Oct 18, 2009 at 04:31:54PM -0700, Junio C Hamano wrote:
> > From: Jeff King <peff@peff.net>
> > Subject: Re: [BUG?] git-cvsimport: path to cvspsfile
> > Date: Wed, 23 Sep 2009 15:14:29 -0400
> > Message-ID: <20090923191428.GA30104@coredump.intra.peff.net>
> >
> > Bug. The script does a chdir() and then looks at the cvspsfile later. I
> > think "-A" would have the same problem. Here is a totally untested patch
> > to address the issue. Johannes, will this is_absolute_path actually work
> > on Windows? I think The Right Way would be to use
> > File::Spec::file_name_is_absolute, but I haven't checked whether that is
> > part of core perl and if so, which version it appeared in.
>
> My understanding of this is that it is a typical "how about this" that is
> still waiting for a follow-up discussion that will result in an eventual
> solution.
Yep. I got comments from JSixt, but I never got around to re-rolling.
Here it is, though still only lightly tested by me (happily, I have not
had to touch CVS for a few years).
-- >8 --
Subject: [PATCH] cvsimport: fix relative argument filenames
One of the first things that cvsimport does is chdir to the
newly created git repo. This means that any filenames given
to us on the command line will be looked up relative to the
git repo directory. This is probably not what the user
expects, so let's remember and prepend the original
directory for relative filenames.
Signed-off-by: Jeff King <peff@peff.net>
---
git-cvsimport.perl | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 1ad20ac..a7d215c 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -579,10 +579,21 @@ sub get_headref ($) {
return $r;
}
+my $user_filename_prepend = '';
+sub munge_user_filename {
+ my $name = shift;
+ return File::Spec->file_name_is_absolute($name) ?
+ $name :
+ $user_filename_prepend . $name;
+}
+
-d $git_tree
or mkdir($git_tree,0777)
or die "Could not create $git_tree: $!";
-chdir($git_tree);
+if ($git_tree ne '.') {
+ $user_filename_prepend = getwd() . '/';
+ chdir($git_tree);
+}
my $last_branch = "";
my $orig_branch = "";
@@ -644,7 +655,7 @@ unless (-d $git_dir) {
-f "$git_dir/cvs-authors" and
read_author_info("$git_dir/cvs-authors");
if ($opt_A) {
- read_author_info($opt_A);
+ read_author_info(munge_user_filename($opt_A));
write_author_info("$git_dir/cvs-authors");
}
@@ -679,7 +690,7 @@ unless ($opt_P) {
$? == 0 or die "git-cvsimport: fatal: cvsps reported error\n";
close $cvspsfh;
} else {
- $cvspsfile = $opt_P;
+ $cvspsfile = munge_user_filename($opt_P);
}
open(CVS, "<$cvspsfile") or die $!;
--
1.6.5.1.121.g1a4d5
^ permalink raw reply related
* [ANNOUNCE] TortoiseGit 1.2.1.0 Release
From: Frank Li @ 2009-10-19 6:58 UTC (permalink / raw)
To: git, tortoisegit-dev, tortoisegit-users, tortoisegit-announce,
tortoisegit
Download:
http://tortoisegit.googlecode.com/files/TortoiseGit-1.1.1.0-32bit.msi
http://tortoisegit.googlecode.com/files/TortoiseGit-1.1.1.0-64bit.msi
= Release 1.1.1.0 =
== Features ==
* Improve Rebase Dialog
Allow lanuch new rebase dialog again after finish rebase dialog
Disable "force rebase" checkbox during rebase.
* Git SVN
Append svn:ignore settings to the default git exclude file Add
shell extension command to import svn ignore settings.
Need press "Shift" key to show "import svn ignore" command.
* Drag-drop copy\move support
File only
* Add paste command at shell extension
Copy and paste file is okay. But there are problems when including
directory.
Cut and paste working
* Update notepad2 to 4.022
* Sync Dialog
Ability to sync submodules in TGit sync dialog
* Statics
Sort commits by dates before processed by StatGraphDlg
* Log Dialog
Show <No branch> replace ref error message at log dialog
* Add Check software updater support.
== Bug Fix ==
* Fixed issue #185. "Can't find Super-project" when pathname include space.
* Fixed issue #190: Access violation in Blame and wrong path name
when root dir is git repository
* Fixed issue #180: Create patch serial doesn't work when there is
"\" at end of path
* Fixed issue #173: SVN Rebase does not work The correct handle below
case git config svn-remote.svn.fetch
myproject/trunk:refs/remotes/trunk
* Fixed issue #169: Force rebase checkbox is fixed
* Fixed issue #163: Conflict "theirs" and "mine" are reversed during a rebase
* Fixed issue #165: Incorect path to Notepad2
* Fixed issue #158: Rebase can act on the wrong branch
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Junio C Hamano @ 2009-10-19 7:07 UTC (permalink / raw)
To: Jeff King; +Cc: Miklos Vajna, git
In-Reply-To: <20091019063446.GA1457@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> > +* remove addition lines (don't stage the line)
>>
>> This is more like "don't add the line", isn't it? Also if this "+" line
>> has corresponding "-" line (i.e. it is a "rewrite to this" line), removal
>> of such a line would mean "instead of rewriting, remove it".
>
> I was trying not to use "add" because we are already talking about
> addition and removal in the patch itself,
Ah, I wasn't saying "add" is more kosher than "stage" by the above.
By "don't add", I meant that the user is saying "I inserted a new line to
the file, but I actually did not want to add that line to the file for the
next commit." In other words, I was more focusing on the act of inserting
the line to the contents, not on staging the change to the index.
> ... So I am not sure I agree that using "add" is any
> better than "stage", but I don't feel that strongly about it.
That is Ok; the comment was not about stage vs add.
> But beyond that, yes, you are right that removing a "+" line may have a
> different conceptual meaning to the user depending on the surrounding
> text. I wonder if such a "check-list" document really makes much sense,
> given that using "-e" at all means you need to understand the patch
> format and what makes sense (i.e., anybody who understands 'patch' knows
> that you can't just delete context lines and expect it to apply).
Yeah, that is really what I wanted people who are in this discussion to
eventually realize ;-)
> Yeah, again, this comes down to understanding what you are doing:
^ permalink raw reply
* Re: [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Alex Riesen @ 2009-10-19 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Jay Soffian
In-Reply-To: <7vhbtv7vsr.fsf@alter.siamese.dyndns.org>
On Mon, Oct 19, 2009 at 08:16, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> On Mon, Oct 19, 2009 at 08:07, Alex Riesen <raa.lkml@gmail.com> wrote:
>>> On Mon, Oct 19, 2009 at 00:49, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>>> + OPT_SET_INT(0, "dwim", &dwim_new_local_branch,
>>>>> + "Guess local branch from remote reference (default)", 0),
>>>>
>>>> Humph, how does SET_INT know to set it to 1 with --dwim and set it to 0
>>>> with --no-dwim?
>>>
>>> It seems to do, though (I checked before sending).
>>>
>>
>> Right, just looked at the parse-options: it is defined for all types.
>>
>> parse-options.c +/get_value
>>
>> const int unset = flags & OPT_UNSET;
>> ...
>> case OPTION_SET_INT:
>> *(int *)opt->value = unset ? 0 : opt->defval;
>> return 0;
>>
>> Very useful.
>
> Ah, did you mean to change the default value to 1 as well?
>
Err... yes. I (wrongly) assumed that the current value in the
storage is the default. Now, having looked at struct option
I see that It isn't (and the default is in defval).
BTW, why is the option an ...INT? Where a future extension planned?
^ permalink raw reply
* Re: [PATCH] Use "--no-" prefix to switch off some of checkout dwimmery
From: Junio C Hamano @ 2009-10-19 7:25 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <81b0412b0910190017o2e6dfd47v868517404d362843@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> BTW, why is the option an ...INT? Where a future extension planned?
No, in my original I wanted to default to 1 and an option to set it to
zero, only because I did not want a variable with negative name.
^ permalink raw reply
* [PATCH v2 0/3] nested expansion
From: Junio C Hamano @ 2009-10-19 7:30 UTC (permalink / raw)
To: git
This is a re-roll of the earlier "general syntax for applying functions to
pretty-print format output" series, rebased on two patches from Dscho to
implement strbuf_add_wrapped_text(). In other words, this will apply on
top of b4d784c (Add strbuf_add_wrapped_text() to utf8.[ch], 2008-11-10).
The first one is almost the same, except that it drops the unnecessary
cast (pointed out by Dscho) and instead changes the type of return value
from expand callback to ssize_t.
The second one has two changes:
1. w() is renamed to wrap();
2. it actually rewraps the text by using Dscho's strbuf_add_wrapped_text().
The third one is new. It teaches wrap() to just indent without wrapping
when the width parameter is zero or negative.
Junio C Hamano (3):
strbuf_nested_expand(): allow expansion to interrupt in the middle
Add %[wrap(width,in1,in2)<<any-string>>%] implementation
Teach --wrap to only indent without wrapping
pretty.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
strbuf.c | 29 +++++++++++++++++-----
strbuf.h | 5 ++-
utf8.c | 13 ++++++++++
4 files changed, 115 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH v2 1/3] strbuf_nested_expand(): allow expansion to interrupt in the middle
From: Junio C Hamano @ 2009-10-19 7:30 UTC (permalink / raw)
To: git
In-Reply-To: <1255937414-10043-1-git-send-email-gitster@pobox.com>
This itself does not do a "nested" expansion, but it paves a way for
supporting an extended syntax to express a function that works on an
expanded substring, e.g. %[function(param...)expanded-string%], by
allowing the callback function to tell where the argument to the function
ends.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Dropped sloppy casts, as suggested by Dscho.
pretty.c | 4 ++--
strbuf.c | 29 ++++++++++++++++++++++-------
strbuf.h | 5 +++--
3 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/pretty.c b/pretty.c
index 587101f..126be56 100644
--- a/pretty.c
+++ b/pretty.c
@@ -595,8 +595,8 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
-static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
- void *context)
+static ssize_t format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
{
struct format_commit_context *c = context;
const struct commit *commit = c->commit;
diff --git a/strbuf.c b/strbuf.c
index a6153dc..af96155 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -214,29 +214,44 @@ void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
strbuf_setlen(sb, sb->len + len);
}
-void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn,
- void *context)
+void strbuf_nested_expand(struct strbuf *sb, const char **format_p,
+ expand_fn_t fn, void *context)
{
+ const char *format = *format_p;
for (;;) {
const char *percent;
- size_t consumed;
+ ssize_t consumed;
percent = strchrnul(format, '%');
strbuf_add(sb, format, percent - format);
+ format = percent;
if (!*percent)
break;
- format = percent + 1;
+ format++;
consumed = fn(sb, format, context);
- if (consumed)
+ if (consumed < 0)
+ break;
+ else if (consumed)
format += consumed;
else
strbuf_addch(sb, '%');
}
+ *format_p = format;
+}
+
+void strbuf_expand(struct strbuf *sb, const char *o_format, expand_fn_t fn,
+ void *context)
+{
+ const char *format = o_format;
+ strbuf_nested_expand(sb, &format, fn, context);
+ if (*format)
+ die("format error: negative return from expand function: %s",
+ o_format);
}
-size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
- void *context)
+ssize_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder,
+ void *context)
{
struct strbuf_expand_dict_entry *e = context;
size_t len;
diff --git a/strbuf.h b/strbuf.h
index d05e056..256d615 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -109,13 +109,14 @@ static inline void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2) {
}
extern void strbuf_adddup(struct strbuf *sb, size_t pos, size_t len);
-typedef size_t (*expand_fn_t) (struct strbuf *sb, const char *placeholder, void *context);
+typedef ssize_t (*expand_fn_t)(struct strbuf *sb, const char *placeholder, void *context);
extern void strbuf_expand(struct strbuf *sb, const char *format, expand_fn_t fn, void *context);
+extern void strbuf_nested_expand(struct strbuf *sb, const char **format_p, expand_fn_t fn, void *context);
struct strbuf_expand_dict_entry {
const char *placeholder;
const char *value;
};
-extern size_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder, void *context);
+extern ssize_t strbuf_expand_dict_cb(struct strbuf *sb, const char *placeholder, void *context);
__attribute__((format(printf,2,3)))
extern void strbuf_addf(struct strbuf *sb, const char *fmt, ...);
--
1.6.5.1.95.g09fbd
^ permalink raw reply related
* [PATCH v2 2/3] Add %[wrap(width,in1,in2)<<any-string>>%] implementation
From: Junio C Hamano @ 2009-10-19 7:30 UTC (permalink / raw)
To: git
In-Reply-To: <1255937414-10043-1-git-send-email-gitster@pobox.com>
This uses the strbuf_nested_expand() mechanism introduced earlier to
demonstrate how to implement a nested string function, by plugging Dscho's
implementation of strbuf_add_wrapped_text().
The log is much more pleasant to read with
$ git log --format='commit %H%nAuthor: %an%n%n%[wrap(66,4,4)%s%n%n%b%]'
in some repositories (e.g. git-svn conversion of rockbox).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Renamed w() to wrap() and actually plugged Dscho's strbuf_add_wrapped_text().
pretty.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 126be56..bc74c25 100644
--- a/pretty.c
+++ b/pretty.c
@@ -595,6 +595,72 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
+typedef int (*string_fmt_fn)(struct strbuf *sb, const char *placeholder, void *context);
+static ssize_t format_commit_item(struct strbuf *, const char *, void *);
+
+static int wrap_fn(struct strbuf *sb, const char *placeholder, void *context)
+{
+ const char *template = placeholder;
+ char *endptr, *nested;
+ long width = 0, indent1 = 0, indent2 = 0;
+
+ width = strtol(template, &endptr, 10);
+ if (*endptr == ',') {
+ template = endptr + 1;
+ indent1 = strtol(template, &endptr, 10);
+ if (*endptr == ',') {
+ template = endptr + 1;
+ indent2 = strtol(template, &endptr, 10);
+ }
+ }
+ if (*endptr++ != ')')
+ return 0;
+
+ template = endptr;
+ strbuf_nested_expand(sb, &template, format_commit_item, context);
+ if (*template++ != ']')
+ return 0;
+
+ nested = strbuf_detach(sb, NULL);
+ strbuf_add_wrapped_text(sb, nested, indent1, indent2, width);
+ free(nested);
+
+ return template - placeholder;
+}
+
+static struct {
+ const char *name;
+ string_fmt_fn fn;
+} format_fn_list[] = {
+ { "wrap(", wrap_fn }
+};
+
+static size_t format_fn(struct strbuf *sb, const char *placeholder,
+ void *context)
+{
+ const char *template = placeholder;
+ size_t consumed;
+ struct strbuf substr = STRBUF_INIT;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(format_fn_list); i++)
+ if (!prefixcmp(template, format_fn_list[i].name))
+ break;
+ if (ARRAY_SIZE(format_fn_list) <= i)
+ return 0;
+ template += strlen(format_fn_list[i].name);
+ consumed = format_fn_list[i].fn(&substr, template, context);
+ if (!consumed) {
+ strbuf_release(&substr);
+ return 0;
+ }
+
+ strbuf_add(sb, substr.buf, substr.len);
+ template += consumed;
+ strbuf_release(&substr);
+ return template - placeholder;
+}
+
static ssize_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -603,9 +669,19 @@ static ssize_t format_commit_item(struct strbuf *sb, const char *placeholder,
const char *msg = commit->buffer;
struct commit_list *p;
int h1, h2;
+ ssize_t nested;
/* these are independent of the commit */
switch (placeholder[0]) {
+ case ']':
+ return -1;
+ case '[':
+ /*
+ * %[func(arg...) string %]: we consumed the opening '['
+ * and the callee consumed up to the closing '%]'.
+ */
+ nested = format_fn(sb, placeholder + 1, context);
+ return nested ? 1 + nested : 0;
case 'C':
if (placeholder[1] == '(') {
const char *end = strchr(placeholder + 2, ')');
^ permalink raw reply related
* [PATCH v2 3/3] Teach --wrap to only indent without wrapping
From: Junio C Hamano @ 2009-10-19 7:30 UTC (permalink / raw)
To: git
In-Reply-To: <1255937414-10043-1-git-send-email-gitster@pobox.com>
When a zero or negative width is given to "shortlog -w<width>,<in1>,<in2>"
and --format=%[wrap(w,in1,in2)...%], just indent the text by in1 without
wrapping.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
utf8.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/utf8.c b/utf8.c
index da99669..5c18f0c 100644
--- a/utf8.c
+++ b/utf8.c
@@ -310,6 +310,19 @@ int strbuf_add_wrapped_text(struct strbuf *buf,
int w = indent, assume_utf8 = is_utf8(text);
const char *bol = text, *space = NULL;
+ if (width <= 0) {
+ /* just indent */
+ while (*text) {
+ const char *eol = strchrnul(text, '\n');
+ if (*eol == '\n')
+ eol++;
+ print_spaces(buf, indent);
+ strbuf_write(buf, text, eol-text);
+ text = eol;
+ }
+ return 1;
+ }
+
if (indent < 0) {
w = -indent;
space = text;
--
1.6.5.1.95.g09fbd
^ permalink raw reply related
* git fsck not identifying corrupted packs
From: Sergio Callegari @ 2009-10-19 7:56 UTC (permalink / raw)
To: git
Hi,
I have a pack that contains a corrupted object.
It is an old corrupted repo that I have conserved.
As expected, git gc cries out loud about it.
It indicates an inflate error (data stream error with incorrect data check),
and then the impossibility to read an object from a certain offset in the pack.
However, git fsck does not complain at all about the repo.
I guess that for speed reasons, git fsck does not try to inflate the objects.
Is there a means to have fsck to a truly full check on the sanity of a repo?
This both on git 1.6.5.1 and 1.6.4.2.
Thanks
Sergio Callegari
^ permalink raw reply
* What's cooking in git.git (Oct 2009, #03; Mon, 19)
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: git
What's cooking in git.git (Oct 2009, #03; Mon, 19)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
--------------------------------------------------
[Graduated to "master"]
* jp/maint-send-email-fold (2009-10-08) 1 commit.
+ git-send-email.perl: fold multiple entry "Cc:" and multiple single line "RCPT TO:"s
* pv/maint-add-p-no-exclude (2009-10-10) 1 commit.
(merged to 'next' on 2009-10-11 at 0ff2e96)
+ git-add--interactive: never skip files included in index
* dk/blame-el (2009-09-29) 1 commit.
+ git-blame.el: Change how blame information is shown.
* jn/gitweb-patch (2009-10-09) 1 commit.
+ gitweb: Do not show 'patch' link for merge commits
* mr/instaweb-cgid (2009-09-26) 1 commit.
(merged to 'next' on 2009-10-11 at 99bcfaf)
+ instaweb: support mod_cgid for apache2
* tf/doc-pt-br (2009-09-23) 1 commit.
+ Documentation: update pt-BR
The current AsciiDoc may barf on NOME and SINOPSE, as pt_BR language
definition is not widely distributed yet (it just hit the development
tree).
* bg/rebase-reword (2009-10-07) 2 commits.
+ rebase-i: fix reword when using a terminal editor
+ Teach 'rebase -i' the command "reword"
* jp/fetch-tag-match (2009-09-17) 1 commit.
+ fetch: Speed up fetch by rewriting find_non_local_tags
* jn/gitweb-show-size (2009-09-07) 1 commit.
+ gitweb: Add 'show-sizes' feature to show blob sizes in tree view
* jc/maint-1.6.0-blank-at-eof (2009-09-14) 15 commits.
(merged to 'next' on 2009-10-11 at 7f34fb3)
+ diff -B: colour whitespace errors
+ diff.c: emit_add_line() takes only the rest of the line
+ diff.c: split emit_line() from the first char and the rest of the line
+ diff.c: shuffling code around
+ diff --whitespace: fix blank lines at end
+ core.whitespace: split trailing-space into blank-at-{eol,eof}
+ diff --color: color blank-at-eof
+ diff --whitespace=warn/error: fix blank-at-eof check
+ diff --whitespace=warn/error: obey blank-at-eof
+ diff.c: the builtin_diff() deals with only two-file comparison
+ apply --whitespace: warn blank but not necessarily empty lines at EOF
+ apply --whitespace=warn/error: diagnose blank at EOF
+ apply.c: split check_whitespace() into two
+ apply --whitespace=fix: detect new blank lines at eof correctly
+ apply --whitespace=fix: fix handling of blank lines at the eof
(this branch is used by jc/maint-blank-at-eof.)
This is a fix for an ancient bug (or inconsistent set of features); the
topic is based on an ancient codebase and is designed to be merged
upwards. jc/maint-blank-at-eof serves that purpose.
--------------------------------------------------
[New Topics]
* ak/bisect-reset-to-switch (2009-10-13) 1 commit.
- bisect reset: Allow resetting to any commit, not just a branch
* fc/doc-fast-forward (2009-10-11) 1 commit.
- user-manual: use 'fast-forward'
* gb/maint-gitweb-esc-param (2009-10-13) 1 commit.
(merged to 'next' on 2009-10-14 at 105f997)
+ gitweb: fix esc_param
(this branch is used by sb/gitweb-link-author.)
* jc/maint-1.6.3-graft-trailing-space (2009-10-14) 1 commit.
- info/grafts: allow trailing whitespaces at the end of line
* jc/strbuf-nested-expand (2009-10-18) 5 commits
- Teach --wrap to only indent without wrapping
- Add %[wrap(width,in1,in2)<<any-string>>%] implementation
- strbuf_nested_expand(): allow expansion to interrupt in the middle
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
(this branch uses js/log-rewrap.)
* jk/maint-cvsimport-pathname (2009-10-19) 1 commit.
(merged to 'next' on 2009-10-19 at 77824f2)
+ cvsimport: fix relative argument filenames
* jn/show-normalized-refs (2009-10-12) 3 commits.
- check-ref-format: simplify --print implementation
- git check-ref-format --print
- Add tests for git check-ref-format
* sb/gitweb-link-author (2009-10-14) 1 commit.
- gitweb: linkify author/committer names with search
(this branch uses gb/maint-gitweb-esc-param.)
* jc/checkout-auto-track (2009-10-18) 3 commits
- git checkout --nodwim
- DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
- check_filename(): make verify_filename() callable without dying
--------------------------------------------------
[Stalled]
* db/vcs-helper-rest (2009-09-03) 6 commits.
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged in 1.6.5. If people want to replace this with improvements it
would be a good time to do so.
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
(this branch is used by jh/notes.)
Ejected from 'next' as fast-import folks still seem to be discussing with
how to proceed.
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jh/cvs-helper (2009-08-18) 8 commits.
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
- Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
Builds on db/vcs-helper.
--------------------------------------------------
[Cooking]
* tr/stash-format (2009-10-16) 5 commits
. stash list: drop the default limit of 10 stashes
. stash list: use new %g formats instead of sed
. Introduce new pretty formats %g[sdD] for reflog information
. reflog-walk: refactor the branch@{num} formatting
. Refactor pretty_print_commit arguments into a struct
Expecting a re-roll.
* ks/precompute-completion (2009-10-05) 1 commit.
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
* sp/smart-http (2009-10-14) 17 commits
- Smart HTTP fetch: gzip requests
- Smart fetch over HTTP: client side
- Smart push over HTTP: client side
- Discover refs via smart HTTP server when available
- Smart fetch and push over HTTP: server side
- Add stateless RPC options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- Move WebDAV HTTP push under remote-curl
- remote-helpers: Support custom transport options
- remote-helpers: Fetch more than one ref in a batch
- fetch: Allow transport -v -v -v to set verbosity to 3
- remote-curl: Refactor walker initialization
- Add multi_ack_detailed capability to fetch-pack/upload-pack
- Move "get_ack()" back to fetch-pack
- fetch-pack: Use a strbuf to compose the want list
- pkt-line: Make packet_read_line easier to debug
- pkt-line: Add strbuf based functions
* ef/msys-imap (2009-10-13) 8 commits.
- MSVC: Enable OpenSSL, and translate -lcrypto
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
- imap-send: remove useless uid code
Is this good to go yet?
* mr/gitweb-snapshot (2009-09-26) 2 commits.
- gitweb: append short hash ids to snapshot files
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* js/log-rewrap (2008-11-10) 2 commits
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
(this branch is used by jc/strbuf-nested-expand.)
* js/diff-verbose-submodule (2009-10-14) 4 commits.
- add tests for git diff --submodule-summary
- fix output for deleted submodules in git diff --submodule-summary
- fix indentation depth for git diff --submodule-summary
- Add the --submodule-summary option to the diff option family
There was an attempted re-roll and it looked very promising with a minor
fix-up, but I ran out of time to pick it up and unilaterally tweaking it.
Waiting for a response.
* jc/fix-tree-walk (2009-09-14) 10 commits.
- read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
+ unpack_callback(): use unpack_failed() consistently
+ unpack-trees: typofix
+ diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
This includes the fix to aggressive mode of three-way merge used by the
resolve strategy.
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Add selftests verifying concatenation of multiple notes for the same commit
- Refactor notes code to concatenate multiple notes annotating the same object
- Add selftests verifying that we can parse notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- Teach notes code to free its internal data structures on request
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
(this branch uses sr/gfi-options.)
Is this good for 'next' now?
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ 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".
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* ne/rev-cache (2009-09-07) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
This seems to break at least t6001 when merged to 'pu'.
* jg/log-format-body-indent (2009-09-19) 1 commit.
. git-log --format: Add %B tag with %B(x) option
Ejected from 'pu' as this is merely a short-hand for %[wrap(0,x,x)%b%].
^ permalink raw reply
* Potentially dangerous behavior of git gc
From: Sergio Callegari @ 2009-10-19 8:04 UTC (permalink / raw)
To: git
Hi,
I encountered an issue with git gc.
Consider the following scenario. Repo A is using repo B as an alternate object
database through the .git/objects/info/alternates mechanism. B is at
/some_path/B. A has some references, including HEAD that are pointing at
objects that are in fact in the object database of B.
For some reasons, paths are modified on the machine, so that B gets moved at
/some_new_path/B.
Obviously A cannot find its objects anymore and its alternate info should be
updated.
Suppose that now one runs git gc on A.
Correctly git gc complains about the broken alternate link.
And then complains again as it cannot find some objects.
However, rather than trying to preserve the repo integrity, it then _removes_
all the references pointing to non existing objects.
With this when the alternate info of A is finally updated, A is broken, missing
many references and not having a head anymore.
Would it be better to have git gc not to take dangerous actions on potentially
problematic repos?
Thanks
Sergio
^ permalink raw reply
* Re: [PATCH] rebase -i: fix reword when using a terminal editor
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Björn Gustavsson
In-Reply-To: <1255674753-13949-1-git-send-email-bebarino@gmail.com>
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] describe: load refnames before calling describe()
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <4AD9F138.3080405@lsrfire.ath.cx>
Thanks, applied.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-19 8:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20091019064955.GB1457@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yep. I got comments from JSixt, but I never got around to re-rolling.
> Here it is, though still only lightly tested by me (happily, I have not
> had to touch CVS for a few years).
>
> -- >8 --
> Subject: [PATCH] cvsimport: fix relative argument filenames
Thanks, applied.
^ permalink raw reply
* Re: Re: Unapplied patches reminder
From: Heiko Voigt @ 2009-10-19 8:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi
In-Reply-To: <7vbpk4i8ii.fsf@alter.siamese.dyndns.org>
On Sun, Oct 18, 2009 at 04:31:49PM -0700, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
> > ...
> > From: Heiko Voigt <hvoigt@hvoigt.net>
> > Subject: [PATCH] fix testsuite to not use any hooks possibly provided by source
> > Date: Wed, 23 Sep 2009 20:30:28 +0200
> > Message-ID: <20090923183023.GA85456@book.hvoigt.net>
> >
> > This is useful if you are using the testsuite with local changes that
> > include activated default hooks suitable for your teams installation.
>
> This may be useful when Heiko or somebody actually has changes that needs
> this fix, but otherwise was an unnecessary code churn during pre-release
> code freeze. I am reasonably sure that Heiko will include it in a series
> that requires this one.
>
> In other words, I am not against it per-se, but I would prefer to see
> patches that actually depends on this change at the same time. Otherwise
> this "is supposed to be no-op, and promises it will help in the future",
> and needs extra mental effort to validate the latter claim.
Well, currently we do not have any activated hooks. They are all sample.
And because the use scenarios for git are so diverse we will probably
never have any default hook activated.
But I imagine that if you are creating a default installation for any
team you will activate some. For an example take this patch:
http://thread.gmane.org/gmane.comp.version-control.git/110874
it is not in master because it was to specific but I have such a hook
activated. It does not allow you to commit on master which breaks the
testsuite.
So in my opinion we should not run the testsuite with hooks even though
the current defaults are all deactivated.
I am afraid that I will never be able to persuade everyone on the list
to not commit on master... ;)
cheers Heiko
P.S.: Just thinking of previous hooks, I might make it an option like
hooks.doNotCommitOnMaster. But still the hooks would be
deactivated.
^ permalink raw reply
* denying branch creation in a shared repository
From: Mohit Aron @ 2009-10-19 8:32 UTC (permalink / raw)
To: git
Hello,
I'm setting up a shared repository and I'd like to prevent users from
creating branches in it (they can of course create local branches in
their own clone of this repository). How can I accomplish this ? I
looked at 'git help config' and it seems I need something similar to
the parameter receive.denyDeletes - this prevents deletion of
branches.
- Mohit
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Sitaram Chamarty @ 2009-10-19 8:43 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
On Mon, Oct 19, 2009 at 2:02 PM, Mohit Aron <mohit.aron@gmail.com> wrote:
> Hello,
>
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.
That was the main reason I wrote gitolite
(http://github.com/sitaramc/gitolite), though now it does a heck of a
lot more than just that.
Scroll down a bit on that page for the README.
People have said pretty nice things about it on #git, and (subject to
being in India time zone and the day job and all) I make sure I help
out as much as I can. Email or #git, both are fine.
Being somewhat familiar with ssh and authkeys is good. Otherwise,
*please* be sure to read
http://sitaramc.github.com/0-installing/9-gitolite-basics.html for
background
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Björn Steinbrink @ 2009-10-19 8:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Julian Phillips, Daniel Barkalow, James Pickens, Jeff King,
Nicolas Pitre, Jay Soffian, git
In-Reply-To: <7vws2snwum.fsf@alter.siamese.dyndns.org>
On 2009.10.18 15:47:13 -0700, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> > On 2009.10.17 02:04:02 -0700, Junio C Hamano wrote:
> > 1) No uncommitted changes => No problem
> > 2) Uncommitted changes merge cleanly => No problem
> > 3) Uncommitted changes causes conflicts =>
> > - User can resolve
> > - User can start over (git update --retry)
> > - User can give up (git update --abort)
>
> By "--abort", if you meant to discard the local change, that is only
> suitable for people who would say "what I was doing was minor anyway, and
> I'll redo them based on the updated upstream", and may not be so useful, I
> think. The user may want to pretend that he did not even start "update"
> (i.e. not pulled while he was still working on something) at this point,
> and if you meant by "give up" (aka --abort) to "reset --hard @{1} &&
> unstash", I think it makes quite a lot of sense. Then the user has an
> option to fork a topic at that point:
>
> git update --abort
> git checkout -b topic
> work on more with committing
> git checkout master
> git update
Yes, I meant the latter. The former would just be "git reset --hard" and
is pointless to be rewrapped in "git update --abort". Maybe "abort" is
the wrong word there? I'm not a native speaker and basically took that
from "git rebase", which returns you to your (unchanged) branch head,
i.e. the state you were in before you started the rebase.
> But then this starts to look more like an enhanced failure recovery mode
> for "git pull" command.
Yeah, I notice that, also while working on my "proof-of-concept"
implementation. Currently, I simply suggest "git pull" to the user when
the update is not a fast-forward one.
I'm probably influenced by a latent hatred for "git pull"... Explaining
that it is fetch+merge/rebase and uses defaults from the config which
are automagically setup is probably something my fingers can do on
their own by now. Confusion about "git pull" probably beats
misunderstandings about HEAD.
If it wasn't so inconvenient for people that actually commit, I'd even
dare to suggest:
git update
- FF update only, using branch.<name>.{remote,merge}
- suggests "git update --merge" or "git update --rebase" if non-ff
git update --merge
- Does a merge
git update --rebase
- Does a rebase
And "git pull" would stop using branch.<name>.{remote,merge} and require
command line arguments.
That would at least raise awareness that "git update --merge" is doing a
merge, unlike "git pull", which many new users simply treat as magic,
not realizing what actually happens (and thus they create butt-ugly
criss-cross merge histories). Of course, I can't tell whether being
aware that a merge happens actually makes the user realize that they
shouldn't update/pull/merge 50 times a day.
But passing --merge all the time seems just too inconvenient. And having
a config option to make --merge or --rebase the default would probably
end up with --merge as the "default default", ultimately turning "git
update" into "git pull".
Anyway, I'm probably getting quite far off the track here.
> In addition, I think that you would internally implement the "save" step
> with "stash" (which would be a sane thing to do), but then you would need
> to worry about the case where the user was in the middle of a merge (or
> "revert", "cherry-pick", "checkout -m") that did not complete. "git pull"
> fails upfront, says why and tells users what to do. "git update" should
> do the same.
Yup, got the same check in my PoC
> > I do see problems with a "stash around merge" thing ("stash" around
> > rebase seems easier, as that could just create a commit and reset later,
> > but I'm not exactly sure that such smartness is a good idea). As soon as
> > the merge has conflicts, you need to know that you have to unstash after
> > committing the merge, but what I have in mind is fast-forward only (or
> > possibly reset, when upstream was rewritten). Primarily for users that
> > don't commit at all, but just look at things [*1*].
>
> Ok. If you have a clean way to guarantee that "update" users won't
> commit, I think the above would sort of make sense and my earlier worries
> about (1) a user who wish he did not fetch and (2) a user who was doing
> something more complex and had conflicts already would go away.
Currently it's just:
test -z "$(git rev-list -1 $upstream..)"
As a "is a fast-forward" check, suggesting the user to use "git pull"
instead of "git update", if it is not. Maybe I should use "git
merge-base" there instead? Is that better? Not sure whether history
simplication might break the rev-list based test...
> If the sole target audience is "minor changes only, never committing"
> people, then I would even rescind my earlier suggestion on --abort; it
> should mean "remove the minor changes and get pristine copy of the
> upstream---the user will redo the minor changes to adjust to the updated
> upstream from scratch", to keep the end user experience simpler and
> clearer.
Hmhm... If the user can't resolve the conflict, but still keep those
changes, he might want to ask someone else for help. And then he might
want to present his changes to that other person, so I think allowing
the user to go back to the old commit with his changes on top is better.
Maybe "git update --drop" could do the "drop the user's changes", if the
user wants to do so. No support for going back is what's bad about "svn
update" (and, I guess, "git checkout --merge").
> I am undecided if it is a good thing to divide the userbase into two
> classes, "update" people and "work-commit-fetch-merge-resolve" people.
I expect that there are already two userbases. Developers in one
userbase and users that just want the latest code in the other. And
these users might have some uncommitted stuff (either self-made or
possibly found somewhere, or maybe a bit of both).
I just wonder what's easier/better: to cater to each one or trying to
unify them by trying to educate the one that actually doesn't care.
Björn
^ permalink raw reply
* Re: [RFC PATCH] hooks: add some defaults to support sane workflow to pre-commit
From: Junio C Hamano @ 2009-10-19 8:50 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git
In-Reply-To: <499EF2B6.7060103@hvoigt.net>
Heiko Voigt <git-list@hvoigt.net> writes:
> It sometimes happens that you move to a new machine and forget to setup your
> name and email address. To find this out after 10 commits can be quite
> frustrating.
Doesn't env_hint[] kick in in fmt_ident() in such a case, though?
^ permalink raw reply
* Re: denying branch creation in a shared repository
From: Björn Steinbrink @ 2009-10-19 8:51 UTC (permalink / raw)
To: Mohit Aron; +Cc: git
In-Reply-To: <ee22b09e0910190132u20931fb4i6a98fb87582a9e56@mail.gmail.com>
On 2009.10.19 01:32:24 -0700, Mohit Aron wrote:
> I'm setting up a shared repository and I'd like to prevent users from
> creating branches in it (they can of course create local branches in
> their own clone of this repository). How can I accomplish this ? I
> looked at 'git help config' and it seems I need something similar to
> the parameter receive.denyDeletes - this prevents deletion of
> branches.
You could write a pre-receive or update hook (depending on whether you
want the whole push to fail, or just the branch head creation, see
githooks(5)).
If a ref is created, the old value is 40 0 (just zeros, forty of them).
And if the refname starts with refs/heads/, then a branch head is being
created. And in that case, you could refuse the push.
Björn
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Johannes Sixt @ 2009-10-19 9:11 UTC (permalink / raw)
To: Sergio Callegari; +Cc: git
In-Reply-To: <loom.20091019T094924-194@post.gmane.org>
Sergio Callegari schrieb:
> Is there a means to have fsck to a truly full check on the sanity of a repo?
git fsck --full
RTFM, please.
-- Hannes
^ 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