* [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Junio C Hamano @ 2009-10-16 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <1255681702-5215-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. It does
not "wrap" using the line-wrap code, but lifting the change by Dscho
and plugging it in should be a trivial exercise.
The overall idea is to parse something like "%[w(72,4,8)%an %ae %s%]" in
these steps:
#1 "%[" introduces the nested string function.
#2 After that, a name identifies what function to call.
#3 The function parses its parameters ("(72,4,8)" in the above example),
and makes a nested expansion on the remainder of the format string.
#4 The nested expansion is terminated at "%]" and returned to the
function.
#5 The function massages the string returned from #4, and the result
becomes the expansion of the whole thing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
pretty.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 84 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 587101f..a8a38c3 100644
--- a/pretty.c
+++ b/pretty.c
@@ -595,6 +595,80 @@ 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 size_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;
+ 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;
+
+ /*
+ * NEEDSWORK: here you wrap the contents of substr with
+ * strbuf_wrap(&substr, width, indent1, indent2);
+ *
+ * ... but I am too lazy to do that here, and I just demonstrate
+ * how it should work by just upcasing the result ;-)
+ */
+ {
+ int i;
+ for (i = 0; i < sb->len; i++)
+ sb->buf[i] = toupper(sb->buf[i]);
+ }
+ return template - placeholder;
+}
+
+static struct {
+ const char *name;
+ string_fmt_fn fn;
+} format_fn_list[] = {
+ { "w(", 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 size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -603,9 +677,19 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
const char *msg = commit->buffer;
struct commit_list *p;
int h1, h2;
+ size_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, ')');
--
1.6.5.99.g9ed7e
^ permalink raw reply related
* [PATCH 2/3] strbuf_nested_expand(): allow expansion to interrupt in the middle
From: Junio C Hamano @ 2009-10-16 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <1255681702-5215-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>
---
strbuf.c | 23 +++++++++++++++++++----
strbuf.h | 3 ++-
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index a6153dc..2bbc49c 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -214,25 +214,40 @@ 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;
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 ((ssize_t) 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,
diff --git a/strbuf.h b/strbuf.h
index d05e056..e602899 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -109,8 +109,9 @@ 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 size_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;
--
1.6.5.99.g9ed7e
^ permalink raw reply related
* Re: [PATCH v2 3/5] Introduce new pretty formats %g[sdD] for reflog information
From: Thomas Rast @ 2009-10-16 8:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091016053230.GB10629@coredump.intra.peff.net>
Jeff King wrote:
> > + if (shorten) {
> > + if (last_ref != commit_reflog->reflogs->ref) {
> > + free(last_short_ref);
> > + last_short_ref = shorten_unambiguous_ref(commit_reflog->reflogs->ref, 0);
> > + }
> > + printed_ref = last_short_ref;
>
> Clever. I hadn't considered caching, but you are right that
> shorten_unambiguous_ref is a bit heavyweight to be calling for every
> entry.
I had a slightly better idea today: We can just put an extra member
into the complete_reflogs struct, i.e., a short_ref to go along with
the ref. It'll take a bit of auditing to verify that all allocations
are zeroed, but since the struct is local to the file that shouldn't
be so hard.
> A test for '%gd' would be nice. A squashable one is below. I am tempted
> to test all three forms in t6006, since the intent of that script is to
> test all format specifiers. However, those tests would be somewhat
> redundant with your t1411 tests.
Ah, yeah, I looked for "reflog" instead of something about pretty, so
I ended up with t1411. t6006 is a better fit. Thanks for the extra
test!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH v2 0/5] Pretty formats for reflog data
From: Jakub Narebski @ 2009-10-16 9:00 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091016052003.GA10629@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Oct 16, 2009 at 12:41:43AM +0200, Thomas Rast wrote:
> > I think going for %(...) wouldn't be too bad since we already have
> > that in for-each-ref, and it can be backwards compatible. So we would
> > have different sets of short and long specifiers, e.g.
> >
> > %ae = %(authoremail)
> > %aE = %(authoremail:mailmap)
> >
> > We can then pass arguments via some yet-to-be decided syntax, say,
> > %(body:indent(10)).
>
> That seems reasonable to me, though if we can limit ourselves to one
> argument per specifier (I suspect most specifiers would simply be
> boolean, but a few may take numbers or strings), then something like
> %(body:indent=10) might be a little more readable.
>
> It would also be nice to have some sort of conditional inclusion, which
> could deal with your extra ": " in patch 3. Either something like:
>
> %(reflog:short)%(reflog:+: )
>
> or even
>
> %(reflog:short:prefix=\: )
>
> and note that allowing arbitrary arguments means we get to deal with
> quoting.
>
> But that is all for another potential series.
Or we could go the whole nine miles, and implement some subset of
advanced shell syntax,
%(parameter:-word)
%(parameter:=word)
%(parameter:?word)
%(parameter:+word)
RPM spec syntax,
%(?parameter) # expand if exists
%(!?parameter) # expand if does not exists
%(?parameter:literal)
%(!?parameter:literal)
or RPM queryformat
%10(parameter)
%-30(parameter)
[ %(messagebody)\n] # messagebody is list of lines
[%(=param) %(list)\n] # param is not a list; repeat it
%|parameter?{present}:{missing}|
%(parameter:date)
%(parameter:shescape)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] grep: do not segfault when -f is used
From: Matt Kraai @ 2009-10-16 8:53 UTC (permalink / raw)
To: git, gitster; +Cc: Matt Kraai
"git grep" would segfault if its -f option was used because it would
try to use an uninitialized strbuf, so initialize the strbuf.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
builtin-grep.c | 2 +-
t/t7002-grep.sh | 4 ++++
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 761799d..1df25b0 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -631,7 +631,7 @@ static int file_callback(const struct option *opt, const char *arg, int unset)
struct grep_opt *grep_opt = opt->value;
FILE *patterns;
int lno = 0;
- struct strbuf sb;
+ struct strbuf sb = STRBUF_INIT;
patterns = fopen(arg, "r");
if (!patterns)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ae56a36..762f815 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -44,6 +44,10 @@ test_expect_success 'grep should not segfault with a bad input' '
test_must_fail git grep "("
'
+test_expect_success 'grep should not segfault with -f' '
+ test_must_fail git grep -f /dev/null
+'
+
for H in HEAD ''
do
case "$H" in
--
1.6.5
^ permalink raw reply related
* Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-16 9:07 UTC (permalink / raw)
To: git
Hi all,
I would like to say Hi! Git is great.
I made a hack to import the wikipedia changelogs into git, it is free
software and all checked in. I will be improving it to keep the git
repo in sync.
Here is the discussion on foundation-l :
http://www.gossamer-threads.com/lists/wiki/foundation/181163
the question is, is there a blame tool that we can use for multiple
horizontal diffs on the same line that will be needed for wikipedia
articles?
If not, I would work on this, if you give me some pointers.
thanks,
mike
^ permalink raw reply
* [PATCH v4] git-gui: adjust the minimum height of diff pane for shorter screen height
From: Vietor Liu @ 2009-10-16 9:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Schindelin, Junio C Hamano
When the main window is maximized, if the screen height is shorter (e.g.
Netbook screen 1024x600), both the partial commit pane and the status bar
are hidden. The diff pane is resizable, so that it can use less vertical
height, allowing the overall window to be shorter and still display both
the entire commit pane and status bar.
Signed-off-by: Vietor Liu <vietor@vxwo.org>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 09b2720..037a1f2 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3083,7 +3083,7 @@ frame .vpane.lower.diff.body
set ui_diff .vpane.lower.diff.body.t
text $ui_diff -background white -foreground black \
-borderwidth 0 \
- -width 80 -height 15 -wrap none \
+ -width 80 -height 5 -wrap none \
-font font_diff \
-xscrollcommand {.vpane.lower.diff.body.sbx set} \
-yscrollcommand {.vpane.lower.diff.body.sby set} \
--
1.6.5
^ permalink raw reply related
* Re: [PATCH] grep: do not segfault when -f is used
From: Johannes Sixt @ 2009-10-16 10:34 UTC (permalink / raw)
To: Matt Kraai; +Cc: git, gitster
In-Reply-To: <1255683204-28988-1-git-send-email-kraai@ftbfs.org>
Matt Kraai schrieb:
> "git grep" would segfault if its -f option was used because it would
> try to use an uninitialized strbuf, so initialize the strbuf.
Thanks for noticing and for the patch.
But...
> +test_expect_success 'grep should not segfault with -f' '
> + test_must_fail git grep -f /dev/null
> +'
there must be a better way to test whether grep -f behaves correctly.
-- Hannes
^ permalink raw reply
* Q: supplying large sets of path to git commands
From: Constantine Plotnikov @ 2009-10-16 10:40 UTC (permalink / raw)
To: Git Mailing List
Some git commands like git check-attr supports receiving paths from
stdin. For other commands like "git diff" and "git commit --only" I
have not found a way to supply a lot of paths (say 1000). Is there a
standard way pass a additional paths to git commands that works on
windows and unix? It would be nice to have --stdin option for all
commands that might receive a set of paths. Or even better would
something like "--options-from-stdin" and
"--options-from-file=file.txt" as a possible last argument specified
on the command line.
Constantine
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Johannes Schindelin @ 2009-10-16 11:26 UTC (permalink / raw)
To: jamesmikedupont@googlemail.com; +Cc: git
In-Reply-To: <ee9cc730910160207x49feb40ej692188abb0a57473@mail.gmail.com>
Hi,
On Fri, 16 Oct 2009, jamesmikedupont@googlemail.com wrote:
> I made a hack to import the wikipedia changelogs into git, it is free
> software and all checked in. I will be improving it to keep the git
> repo in sync.
This is cool! I actually wanted this for quite some time, and could not
find the time to do it myself.
> Here is the discussion on foundation-l :
> http://www.gossamer-threads.com/lists/wiki/foundation/181163
I found the link to the bazaar repository there, but do you have a Git
repository, too?
> the question is, is there a blame tool that we can use for multiple
> horizontal diffs on the same line that will be needed for wikipedia
> articles?
I am not quite sure what you want to do horizontally there... Can you
explain what you want to see?
Ciao,
Dscho
^ permalink raw reply
* Re: Efficient cloning from svn (with multiple branches/tags subdirs)
From: Bruno Harbulot @ 2009-10-16 11:20 UTC (permalink / raw)
To: git; +Cc: Eric Wong
In-Reply-To: <28c656e20910151029s2e053f75q56e968f313d12b21@mail.gmail.com>
B Smith-Mannschott wrote:
>> I've had a quick look at the git-svn code to see how this ID was generated,
>> but couldn't find anything obvious.
>> I realise this isn't the cleanest approach possible, but any suggestion
>> would be appreciated.
>
> When I 'git svn clone' from a svnsync mirror I pass
> --use-svnsync-props. Have you tried that?
Thank you, I hadn't noticed this option, but it was the right one indeed.
Best wishes,
Bruno.
^ permalink raw reply
* Re: [PATCH 2/3] strbuf_nested_expand(): allow expansion to interrupt in the middle
From: Johannes Schindelin @ 2009-10-16 11:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1255681702-5215-3-git-send-email-gitster@pobox.com>
Hi,
On Fri, 16 Oct 2009, Junio C Hamano wrote:
> consumed = fn(sb, format, context);
> - if (consumed)
> + if ((ssize_t) consumed < 0)
> + break;
Would it not be much better to fix the signature of fn in a separate
commit before this one?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation
From: Johannes Schindelin @ 2009-10-16 11:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1255681702-5215-4-git-send-email-gitster@pobox.com>
Hi,
maybe "rewrap" would be a better name than "w"?
On Fri, 16 Oct 2009, Junio C Hamano wrote:
> #1 "%[" introduces the nested string function.
>
> #2 After that, a name identifies what function to call.
>
> #3 The function parses its parameters ("(72,4,8)" in the above example),
> and makes a nested expansion on the remainder of the format string.
Can't we parse it once, i.e. the first time?
Ciao,
Dscho
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Martin Langhoff @ 2009-10-16 11:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jamesmikedupont@googlemail.com, git
In-Reply-To: <alpine.DEB.1.00.0910161321550.4985@pacific.mpi-cbg.de>
On Fri, Oct 16, 2009 at 1:26 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> I am not quite sure what you want to do horizontally there... Can you
> explain what you want to see?
Highlight the changed bits on the line. Example - the red-bold highlight in:
http://en.wikipedia.org/w/index.php?title=David_Letterman&action=historysubmit&diff=320061135&oldid=320060840
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-16 11:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910161321550.4985@pacific.mpi-cbg.de>
On Fri, Oct 16, 2009 at 1:26 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> Here is the discussion on foundation-l :
>> http://www.gossamer-threads.com/lists/wiki/foundation/181163
>
> I found the link to the bazaar repository there, but do you have a Git
> repository, too?
Not yet. Where should I put it? Any suggestions.
>> the question is, is there a blame tool that we can use for multiple
>> horizontal diffs on the same line that will be needed for wikipedia
>> articles?
>
> I am not quite sure what you want to do horizontally there... Can you
> explain what you want to see?
Yes, I would like to see all the contributors to each word or line.
Basically one line of blame per contributor, so many lines of output.
Ideally we would have something that is usable in a html display. Lets
say, just an blame attribute for each word. so on one line :
This is a line with two changes first change Second change end of line
It would look like this in html :
This is a line with two changes <span blame=revisionid>first
change</span><span blame=revisionid>Second change</span> end of line
The blame edit could look like this :
REVISION ID 1 48 : This is a line with two changes first
change first change \
REVISTION ID 2 48 C: Second change end of line
let me see if I can find an online example.
Here is a blame tool with links to the edits:
http://hewgill.com/journal/entries/461-wikipedia-blame
here is the wikitrust tool that could be interesting :
http://wikitrust.soe.ucsc.edu/
http://wikitrust.collaborativetrust.com/screenshots
Thanks,
mike
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Schindelin @ 2009-10-16 11:48 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, Jeff King, Daniel Barkalow, Johannes Sixt,
Euguess, Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <200910141133.11386.trast@student.ethz.ch>
Hi,
On Wed, 14 Oct 2009, Thomas Rast wrote:
> [On the other hand, some users appear unwilling to learn something new
> because they "just want to version control this" or "just need to make a
> commit to this project".]
Frankly, if the choice is between "I just want to make a commit to this
project" and "Then I'll not use version control at all", I'd rather choose
the former.
Which is exactly what I did the other day, having to write a non-trivial
script to allow the user to do what he wants to do.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-16 12:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Daniel Barkalow, Johannes Sixt,
Euguess, Mikael Magnusson, Matthieu Moy, Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0910161346560.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 14 Oct 2009, Thomas Rast wrote:
>
> > [On the other hand, some users appear unwilling to learn something new
> > because they "just want to version control this" or "just need to make a
> > commit to this project".]
>
> Frankly, if the choice is between "I just want to make a commit to this
> project" and "Then I'll not use version control at all", I'd rather choose
> the former.
Using your automatic gearbox analogy, I should point out that people
still spend significant amounts of time and money on learning how to
drive, despite the fact that learning the internals of the engine is
no longer required.
Yet for some reason, the same people want computers to read their
minds instead of learning how to operate (the more involved parts of)
it.
(Yeah, call me arrogant...)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Julian Phillips @ 2009-10-16 12:15 UTC (permalink / raw)
To: Daniel Barkalow
Cc: James Pickens, Jeff King, Junio C Hamano, Nicolas Pitre,
Jay Soffian, git
In-Reply-To: <alpine.LNX.2.00.0910151523020.32515@iabervon.org>
On Thu, 15 Oct 2009, Daniel Barkalow wrote:
> On Thu, 15 Oct 2009, James Pickens wrote:
>
>> How about not detaching the head at all if the user checks out any ref, and
>> reject commits if he checked out a tag or remote branch. For example:
>>
>> $ git checkout origin/master
>> $ git status
>> # On branch origin/master
>> $ git commit ;# complain
>
> $ git checkout origin/master
> $ git fetch
> $ git checkout origin/next
> Uncommited file '...' would be overwritten.
How about:
$ git checkout origin/master
$ git fetch
Refusing to fetch, as it would update a checkedout branch
"git fetch -f" will force the update, but you will need to run "git
reset --hard HEAD" to update your checkout to match.
?
--
Julian
---
If you care, you just get disappointed all the time. If you don't care
nothing matters so you are never upset. -- Calvin
^ permalink raw reply
* Re: Git gui and gitk documentation
From: Michael J Gruber @ 2009-10-16 13:10 UTC (permalink / raw)
To: chris miles; +Cc: git
In-Reply-To: <BLU149-W532BC93AF99F2B8D4C90F1E3C50@phx.gbl>
chris miles venit, vidit, dixit 15.10.2009 22:51:
>
> Hi
>
> I'm looking for documentation on gitk and the gui that is distributed with git.
> Could anyone point me in the right direction?
How about
man gitk
man git-gui
The latter is the same as "git help gui". There is no "git help k",
though :)
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] grep: do not segfault when -f is used
From: Matt Kraai @ 2009-10-16 13:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AD84C2F.5000809@viscovery.net>
On Fri, Oct 16, 2009 at 12:34:23PM +0200, Johannes Sixt wrote:
> Matt Kraai schrieb:
> > +test_expect_success 'grep should not segfault with -f' '
> > + test_must_fail git grep -f /dev/null
> > +'
>
> there must be a better way to test whether grep -f behaves correctly.
How about the following test cases instead?
test_expect_success 'grep -f, non-existent file' '
test_must_fail git grep -f patterns
'
cat >expected <<EOF
file:foo mmap bar
file:foo_mmap bar
file:foo_mmap bar mmap
file:foo mmap bar_mmap
file:foo_mmap bar mmap baz
EOF
cat >pattern <<EOF
mmap
EOF
test_expect_success 'grep -f, one pattern' '
git grep -f pattern >actual &&
test_cmp expected actual
'
cat >expected <<EOF
file:foo mmap bar
file:foo_mmap bar
file:foo_mmap bar mmap
file:foo mmap bar_mmap
file:foo_mmap bar mmap baz
t/a/v:vvv
t/v:vvv
v:vvv
EOF
cat >patterns <<EOF
mmap
vvv
EOF
test_expect_success 'grep -f, multiple patterns' '
git grep -f patterns >actual &&
test_cmp expected actual
'
cat >expected <<EOF
file:foo mmap bar
file:foo_mmap bar
file:foo_mmap bar mmap
file:foo mmap bar_mmap
file:foo_mmap bar mmap baz
t/a/v:vvv
t/v:vvv
v:vvv
EOF
cat >patterns <<EOF
mmap
vvv
EOF
test_expect_success 'grep -f, ignore empty lines' '
git grep -f patterns >actual &&
test_cmp expected actual
'
--
Matt Kraai http://ftbfs.org/
^ permalink raw reply
* Re: [PATCH] grep: do not segfault when -f is used
From: Johannes Sixt @ 2009-10-16 13:46 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <20091016133908.GA3172@ftbfs.org>
Matt Kraai schrieb:
> On Fri, Oct 16, 2009 at 12:34:23PM +0200, Johannes Sixt wrote:
>> there must be a better way to test whether grep -f behaves correctly.
>
> How about the following test cases instead?
*MUCH* better! Now, if you could wrap them up in a patch...
-- Hannes
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: Johannes Schindelin @ 2009-10-16 14:11 UTC (permalink / raw)
To: jamesmikedupont@googlemail.com; +Cc: git
In-Reply-To: <ee9cc730910160443k7e5f718bs964923a796cf38d1@mail.gmail.com>
Hi,
On Fri, 16 Oct 2009, jamesmikedupont@googlemail.com wrote:
> On Fri, Oct 16, 2009 at 1:26 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> Here is the discussion on foundation-l :
> >> http://www.gossamer-threads.com/lists/wiki/foundation/181163
> >
> > I found the link to the bazaar repository there, but do you have a Git
> > repository, too?
>
> Not yet. Where should I put it? Any suggestions.
github.com has a nice interface.
BTW after reading some of the code, I am a bit surprised that you did not
do it as a .php script outputting fast-import capable text...
> >> the question is, is there a blame tool that we can use for multiple
> >> horizontal diffs on the same line that will be needed for wikipedia
> >> articles?
> >
> > I am not quite sure what you want to do horizontally there... Can you
> > explain what you want to see?
>
> Yes, I would like to see all the contributors to each word or line.
>
> Basically one line of blame per contributor, so many lines of output.
> Ideally we would have something that is usable in a html display. Lets
> say, just an blame attribute for each word. so on one line :
>
> This is a line with two changes first change Second change end of line
>
> It would look like this in html :
> This is a line with two changes <span blame=revisionid>first
> change</span><span blame=revisionid>Second change</span> end of line
>
> The blame edit could look like this :
> REVISION ID 1 48 : This is a line with two changes first
> change first change \
> REVISTION ID 2 48 C: Second change end of line
Okay, so basically you want to analyze the text on a word-by-word basis
rather than line-by-line.
Or maybe even better: you want to analyze the text character-by-character.
That would also nicely circumvent to specify just what makes a word a word
(subject for a lot of heated discussion during the design of the
--color-words=<regex> patch).
Basically, if I had to implement that, I would not try to modify
builtin-blame.c, but write a new program linking to libgit.a, calling the
revision walker on the file you want to calculate the blame for. (One of
the best examples is probably in builtin-shortlog.c.)
Then I would introduce a linked-list structure which will hold the blamed
regions in this form:
struct region {
int start;
struct region *next;
};
Initially, this would have a start element with the start offset 0
pointing to the end element with start offset being set to the size of the
blob.
Most likely you will have to add members to this struct, such as the
original offsets (as you will have to adjust the offsets to the different
file revisions while you go back in time), and the commit it was
attributed to.
Then I would make modified "texts" from the blob of the file in the
current revision and its parent revision, by inserting newlines after
every single byte (probably replacing the original newlines by other
values, such as \x01).
The reason for this touchup is that the diff machinery in Git only handles
line-based diffs.
Then you can parse the hunk headers, adjust the offsets accordingly, and
attribute the +++ regions to the current commit (by construction, the
offsets are equal to the line number in the hunk header). Here it is most
likely necessary to split the regions.
You should also have a counter how many regions are still unattributed so
you can stop early.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] grep: do not segfault when -f is used
From: Matt Kraai @ 2009-10-16 14:13 UTC (permalink / raw)
To: git, gitster, Johannes Sixt; +Cc: Matt Kraai
In-Reply-To: <4AD8791A.8060500@viscovery.net>
"git grep" would segfault if its -f option was used because it would
try to use an uninitialized strbuf, so initialize the strbuf.
Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the
test cases.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
---
builtin-grep.c | 2 +-
t/t7002-grep.sh | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 761799d..1df25b0 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -631,7 +631,7 @@ static int file_callback(const struct option *opt, const char *arg, int unset)
struct grep_opt *grep_opt = opt->value;
FILE *patterns;
int lno = 0;
- struct strbuf sb;
+ struct strbuf sb = STRBUF_INIT;
patterns = fopen(arg, "r");
if (!patterns)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ae56a36..ae5290a 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -213,6 +213,72 @@ test_expect_success 'grep -e A --and --not -e B' '
test_cmp expected actual
'
+test_expect_success 'grep -f, non-existent file' '
+ test_must_fail git grep -f patterns
+'
+
+cat >expected <<EOF
+file:foo mmap bar
+file:foo_mmap bar
+file:foo_mmap bar mmap
+file:foo mmap bar_mmap
+file:foo_mmap bar mmap baz
+EOF
+
+cat >pattern <<EOF
+mmap
+EOF
+
+test_expect_success 'grep -f, one pattern' '
+ git grep -f pattern >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<EOF
+file:foo mmap bar
+file:foo_mmap bar
+file:foo_mmap bar mmap
+file:foo mmap bar_mmap
+file:foo_mmap bar mmap baz
+t/a/v:vvv
+t/v:vvv
+v:vvv
+EOF
+
+cat >patterns <<EOF
+mmap
+vvv
+EOF
+
+test_expect_success 'grep -f, multiple patterns' '
+ git grep -f patterns >actual &&
+ test_cmp expected actual
+'
+
+cat >expected <<EOF
+file:foo mmap bar
+file:foo_mmap bar
+file:foo_mmap bar mmap
+file:foo mmap bar_mmap
+file:foo_mmap bar mmap baz
+t/a/v:vvv
+t/v:vvv
+v:vvv
+EOF
+
+cat >patterns <<EOF
+
+mmap
+
+vvv
+
+EOF
+
+test_expect_success 'grep -f, ignore empty lines' '
+ git grep -f patterns >actual &&
+ test_cmp expected actual
+'
+
cat >expected <<EOF
y:y yy
--
--
1.6.5
^ permalink raw reply related
* [PATCH v3 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-16 14:20 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091016053230.GB10629@coredump.intra.peff.net>
Next round :-)
I only changed 3/5, as per your comments:
Jeff King wrote:
> On Fri, Oct 16, 2009 at 12:41:46AM +0200, Thomas Rast wrote:
> > +- '%gD': reflog selector, e.g., `refs/stash@{1}`
> > +- '%gd': shortened reflog selector, e.g., `stash@{1}`
> > +- '%gs': reflog subject
>
> Should we give a note that these do nothing if "-g" was not given?
I tried for some time, but all attempts at interrupting the lists
ended up terminating it again, so that the %g family list would not
line up with the rest of the parameters. Having the note there would
be nice, but I think keeping the list together optically is more
important. However, AFAICS it really is the first character that only
works with certain options (%m makes little sense without A...B, but
still expands to >).
Looking at it did make me notice that @{1} is invalid asciidoc and
needs to be spelled @\{1\} though :-)
> A test for '%gd' would be nice. A squashable one is below. I am tempted
> to test all three forms in t6006, since the intent of that script is to
> test all format specifiers. However, those tests would be somewhat
> redundant with your t1411 tests.
I added yours and moved my tests to t6006 too, as indicated in the
other mail.
I also changed the caching, as outlined earlier:
I wrote:
> I had a slightly better idea today: We can just put an extra member
> into the complete_reflogs struct, i.e., a short_ref to go along with
> the ref. It'll take a bit of auditing to verify that all allocations
> are zeroed, but since the struct is local to the file that shouldn't
> be so hard.
There's in fact only a single allocation (with xcalloc).
Thomas Rast (5):
Refactor pretty_print_commit arguments into a struct
reflog-walk: refactor the branch@{num} formatting
Introduce new pretty formats %g[sdD] for reflog information
stash list: use new %g formats instead of sed
stash list: drop the default limit of 10 stashes
Documentation/pretty-formats.txt | 3 +
builtin-branch.c | 3 +-
builtin-checkout.c | 3 +-
builtin-log.c | 3 +-
builtin-merge.c | 7 ++-
builtin-rev-list.c | 7 ++-
builtin-shortlog.c | 9 +++-
builtin-show-branch.c | 4 +-
commit.h | 20 ++++++---
git-stash.sh | 8 +---
log-tree.c | 21 +++++-----
pretty.c | 44 ++++++++++++++------
reflog-walk.c | 83 ++++++++++++++++++++++++++++----------
reflog-walk.h | 8 ++++
t/t6006-rev-list-format.sh | 18 ++++++++
15 files changed, 170 insertions(+), 71 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Shawn O. Pearce @ 2009-10-16 14:21 UTC (permalink / raw)
To: Mike Hommey; +Cc: H. Peter Anvin, Antti-Juhani Kaijanaho, git
In-Reply-To: <20091016071942.GC3009@glandium.org>
Mike Hommey <mh@glandium.org> wrote:
> On Thu, Oct 15, 2009 at 10:59:25PM -0700, H. Peter Anvin wrote:
> > On 10/10/2009 03:12 AM, Antti-Juhani Kaijanaho wrote:
> > > On 2009-10-09, Junio C Hamano <gitster@pobox.com> wrote:
> > >>> +If there is no repository at $GIT_URL, the server MUST respond with
> > >>> +the '404 Not Found' HTTP status code.
> > >>
> > >> We may also want to add
> > >>
> > >> If there is no object at $GIT_URL/some/path, the server MUST respond
> > >> with the '404 Not Found' HTTP status code.
> > >>
> > >> to help dumb clients.
> > >
> > > In both cases - is it really necessary to forbid the use of 410 (Gone)?
My original text got taken a bit out of context here. I guess MUST
was too strong of a word. I more ment something like:
If there is no repository at $GIT_URL, the server MUST NOT respond
with '200 OK' and a valid info/refs response. A server SHOULD
respond with '404 Not Found', '410 Gone', or any other suitable
HTTP status code which does not imply the resource exists as
requested.
> > 410 means "we once had it, it's no longer here, no idea where it went."
> > It's a largely useless code...
>
> There is an additional meaning to it, that is "it will never ever
> return". It thus has a stronger meaning than 404. Sadly, not even search
> engine spiders consider it as a hint to not crawl there in the future...
I know. I broke a URL on a site back in Janurary, MSN keeps crawling
it anyway. F'king spiders.
--
Shawn.
^ 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