* Re: [PATCH] Deprecate git-lost-found
From: Junio C Hamano @ 2007-11-08 0:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711072253580.4362@racer.site>
Makes sort of sense. Add deprecation notice to Documentation/
as well, please.
^ permalink raw reply
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: Johannes Schindelin @ 2007-11-08 0:14 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <47324810.2010507@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1690 bytes --]
Hi,
On Thu, 8 Nov 2007, René Scharfe wrote:
> Johannes Schindelin schrieb:
>
> > On Wed, 7 Nov 2007, René Scharfe wrote:
> >
> >> By the way, the more intrusive surgery required when using
> >> strbuf_expand() leads to even faster operation. Here my measurements
> >> of most of Paul's test cases (best of three runs):
> >>
> >> [...]
> >
> > impressive timings. Although I wonder where the time comes from, as
> > the other substitutions should not be _that_ expensive.
>
> I haven't run a profiler, but my two suspects are the malloc()s and
> free()s done by interp_set_entry(), and the fact that
> format_commit_message() calls interpolate() twice.
But of course! *slapsthehead*
> > In any case, your approach seems much more sensible, now that we have
> > strbuf.
> >
> >> diff --git a/strbuf.h b/strbuf.h
> >> index cd7f295..95071d5 100644
> >> --- a/strbuf.h
> >> +++ b/strbuf.h
> >> @@ -102,6 +102,9 @@ static inline void strbuf_addbuf(struct strbuf *sb, struct strbuf *sb2) {
> >> strbuf_add(sb, sb2->buf, sb2->len);
> >> }
> >>
> >> +typedef void (*expand_fn_t) (struct strbuf *sb, const char *placeholder, void *context);
> >> +extern void strbuf_expand(struct strbuf *sb, const char *fmt, const char **placeholders, expand_fn_t fn, void *context);
> >
> > I wonder if it would even faster (but maybe not half as readable) if
> > expand_fd_t got the placeholder_index instead of the placeholder.
>
> I doubt it. All this would save is one pointer dereference per
> placeholder. I haven't tried and measured this, though.
My thinko. I thought that you save one prefixcmp(), but strbuf_expand()
offloads that to the callback function.
Thanks,
Dscho
^ permalink raw reply
* git-svn fetch doesn't like spaces in branch names
From: Michael J. Cohen @ 2007-11-08 0:14 UTC (permalink / raw)
To: Git Mailing List
mini:TextMateBundles mjc$ git-svn fetch
Found possible branch point: http://macromates.com/svn/Bundles/trunk/Tools/Dialog
PlugIn => http://macromates.com/svn/Bundles/branches/Dialog PlugIn
Completion Menu, 8089
Initializing parent: Dialog PlugIn Completion Menu@8089
Bad URL passed to RA layer: Malformed URL for repository at /opt/local/
bin/git-svn line 1607
looks like that might need to be %20 ?
-mjc
^ permalink raw reply
* Re: Inconsistencies with git log
From: David Symonds @ 2007-11-08 0:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711080009270.4362@racer.site>
On Nov 8, 2007 11:09 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Thu, 8 Nov 2007, David Symonds wrote:
>
> > On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
> > >
> > > However, Dave's suggestion of altering git-status output to be
> > > relative to (but not limited by) CWD has merit. Too bad I don't have
> > > time to work on it right now.
> >
> > I am happy to hack on this if there's not widespread revolt against the
> > concept.
>
> Too late ;-)
I see that you're revolting against relative paths in git-log; I agree
with you on that. I'm proposing changing the output to git-status so
that it produces relative paths, which are suitable for
git-add/git-rm/git-diff/...
Dave.
^ permalink raw reply
* [PATCH 2/2] git status: show relative paths when run in a subdirectory
From: Johannes Schindelin @ 2007-11-08 0:12 UTC (permalink / raw)
To: David Symonds; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List, gitster
In-Reply-To: <ee77f5c20711071531q5acc4d06u264f5daad7c04cc4@mail.gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This looks a bit ugly because quote_crlf() is now also called
on the untracked files, which are not NUL terminated.
Maybe someone has an idea how to do this more elegantly.
builtin-runstatus.c | 1 +
wt-status.c | 50 ++++++++++++++++++++++++++++++++++++++++++--------
wt-status.h | 1 +
3 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/builtin-runstatus.c b/builtin-runstatus.c
index 2db25c8..8d167a9 100644
--- a/builtin-runstatus.c
+++ b/builtin-runstatus.c
@@ -14,6 +14,7 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)
git_config(git_status_config);
wt_status_prepare(&s);
+ s.prefix = prefix;
for (i = 1; i < argc; i++) {
if (!strcmp(argv[i], "--color"))
diff --git a/wt-status.c b/wt-status.c
index 03b5ec4..7386d41 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -82,16 +82,48 @@ static void wt_status_print_trailer(struct wt_status *s)
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
}
-static const char *quote_crlf(const char *in, char *buf, size_t sz)
+static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
+ const char *prefix)
{
const char *scan;
char *out;
const char *ret = in;
+ int off = 0;
+
+ if (len < 0)
+ len = strlen(in);
+
+ if (prefix) {
+ while (prefix[off] && off < len && prefix[off] == in[off])
+ if (prefix[off] == '/') {
+ prefix += off + 1;
+ in += off + 1;
+ len -= off + 1;
+ off = 0;
+ } else
+ off++;
+ for (off = 0; *prefix; prefix++)
+ if (*prefix == '/') {
+ if (off + 4 >= sz) {
+ warning ("Could not prefix path: %s",
+ in);
+ return in;
+ }
+ strcpy(buf + off, "../");
+ off += 3;
+ }
+ ret = buf;
+ }
- for (scan = in, out = buf; *scan; scan++) {
+ for (scan = in, out = buf + off; len; scan++, len--) {
int ch = *scan;
int quoted;
+ if (out - buf + 3 >= sz) {
+ warning ("Could not quote path: %s", in);
+ break;
+ }
+
switch (ch) {
case '\n':
quoted = 'n';
@@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
const char *one, *two;
char onebuf[PATH_MAX], twobuf[PATH_MAX];
- one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
- two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
+ one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
+ two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
switch (p->status) {
@@ -215,8 +247,8 @@ static void wt_status_print_initial(struct wt_status *s)
for (i = 0; i < active_nr; i++) {
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
- quote_crlf(active_cache[i]->name,
- buf, sizeof(buf)));
+ quote_crlf(active_cache[i]->name, -1,
+ buf, sizeof(buf), s->prefix));
}
if (active_nr)
wt_status_print_trailer(s);
@@ -254,6 +286,7 @@ static void wt_status_print_untracked(struct wt_status *s)
const char *x;
int i;
int shown_header = 0;
+ char buf[PATH_MAX];
memset(&dir, 0, sizeof(dir));
@@ -291,8 +324,9 @@ static void wt_status_print_untracked(struct wt_status *s)
shown_header = 1;
}
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
- color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%.*s",
- ent->len, ent->name);
+ color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%s",
+ quote_crlf(ent->name, ent->len,
+ buf, sizeof(buf), s->prefix));
}
}
diff --git a/wt-status.h b/wt-status.h
index 7744932..f58ebcb 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -23,6 +23,7 @@ struct wt_status {
int workdir_untracked;
const char *index_file;
FILE *fp;
+ const char *prefix;
};
int git_status_config(const char *var, const char *value);
--
1.5.3.5.1597.g7191
^ permalink raw reply related
* [PATCH 1/2] Makefile: wt-status.h is also a lib header
From: Johannes Schindelin @ 2007-11-08 0:10 UTC (permalink / raw)
To: David Symonds; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List, gitster
In-Reply-To: <ee77f5c20711071531q5acc4d06u264f5daad7c04cc4@mail.gmail.com>
When a struct in wt-status.h changes, many files need to be rebuilt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Makefile | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index e5dc63b..dad9c5a 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,8 @@ LIB_H = \
run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
- mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h
+ mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h \
+ wt-status.h
DIFF_OBJS = \
diff.o diff-lib.o diffcore-break.o diffcore-order.o \
--
1.5.3.5.1597.g7191
^ permalink raw reply related
* Re: Inconsistencies with git log
From: Johannes Schindelin @ 2007-11-08 0:09 UTC (permalink / raw)
To: David Symonds; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List
In-Reply-To: <ee77f5c20711071531q5acc4d06u264f5daad7c04cc4@mail.gmail.com>
Hi,
On Thu, 8 Nov 2007, David Symonds wrote:
> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
> >
> > However, Dave's suggestion of altering git-status output to be
> > relative to (but not limited by) CWD has merit. Too bad I don't have
> > time to work on it right now.
>
> I am happy to hack on this if there's not widespread revolt against the
> concept.
Too late ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-branch --with=commit
From: Johannes Schindelin @ 2007-11-08 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpryl8x5t.fsf@gitster.siamese.dyndns.org>
Hi,
would it not be better to call it --containing=commit? Besides, I think
that the opt_parse_with_commit() function would be better named
opt_parse_commit() and be put into parse-options.[ch].
Ciao,
Dscho
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jon Smirl @ 2007-11-08 0:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711080003080.4362@racer.site>
On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> It is consistent, when you realise that the path arguments are interpreted
> relative to the project root.
Then why doesn't this work?
jonsmirl@terra:~/mpc5200b$ git log Documentation
all the log for Documentation....
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
fatal: ambiguous argument 'Documentation': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions
jonsmirl@terra:~/mpc5200b/Documentation$
>
> Hth,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Inconsistencies with git log
From: Johannes Schindelin @ 2007-11-08 0:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711071529m604f3b12v29b3a040074ea4e@mail.gmail.com>
Hi,
On Wed, 7 Nov 2007, Jon Smirl wrote:
> So if git log is always whole tree, why doesn't this work?
git log is not always the whole tree. git log without arguments is.
> cd arch/powerpc/platforms/52xx
> git log arch/powerpc/platforms/52xx
> fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> It's not consistent. git log with no parameters is relative to the
> project root, git log with a parameter is relative to the current
> directory.
It is consistent, when you realise that the path arguments are interpreted
relative to the project root.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] git-branch --with=commit
From: Jakub Narebski @ 2007-11-07 23:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vpryl8x5t.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> ---
> builtin-branch.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 files changed, 48 insertions(+), 2 deletions(-)
Documentation/git-branch.txt, please?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: Pierre Habouzit @ 2007-11-07 23:31 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <4732487A.4050100@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 1393 bytes --]
On Wed, Nov 07, 2007 at 11:21:30PM +0000, René Scharfe wrote:
> Pierre Habouzit schrieb:
> > {
> > const char *percent = strchrnul(fmt, '%');
> > while (*percent) {
> > strbuf_add(sb, fmt, percent - fmt);
> > fmt = percent + 1;
> >
> > /* do your stuff */
> >
> > percent = strchrnul(fmt, '%');
> > }
> > strbuf_add(sb, fmt, percent - fmt);
> > }
> >
> >
> > Which would require strchrnul, but it's trivial compat/ material for sure.
>
> Grepping through the source I see several places that can be simplified
> by converting them to strchrnul(), so I think introducing this GNU
> extension is a good idea in any case.
Yes, strchrnul is _very_ useful for parsing.
> Using strchr()/strchrnul() instead of strbuf_addch()'ing is sensible, of
> course. I don't like the duplicate code in your sketch above, though.
> I'll try to look into it later today.
Well you can alternatively write it this way of course:
for (;;) {
const char *percent = strchrnul(fmt, '%');
strbuf_add(sb, fmt, percent - fmt);
if (!*percent)
break /* or return probably */;
fmt = percent + 1;
/* do your stuff */
}
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Inconsistencies with git log
From: David Symonds @ 2007-11-07 23:31 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <243E1E6E-4723-42D3-933C-D2A0D1ACE287@silverinsanity.com>
On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>
> However, Dave's suggestion of altering git-status output to be
> relative to (but not limited by) CWD has merit. Too bad I don't have
> time to work on it right now.
I am happy to hack on this if there's not widespread revolt against the concept.
Dave.
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jon Smirl @ 2007-11-07 23:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711072309380.4362@racer.site>
On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 7 Nov 2007, Jon Smirl wrote:
>
> > On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > We also tend to take the approach of viewing the history as that of
> > > the whole project.
> >
> > But if you type 'git log' while cd'd into a subdirectory the whole log
> > is almost never what you want. It's this kind of thing that makes git
> > harder to use.
>
> When I am working in a subdirectory, I often want the whole history. For
> example, when I am working on the documentation, sometimes I need to look
> up a commit real quick, that touched other parts.
>
> Besides, adding a space and a dot is not what qualifies for "harder to
> use" with this developer.
So if git log is always whole tree, why doesn't this work?
cd arch/powerpc/platforms/52xx
git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions
It's not consistent. git log with no parameters is relative to the
project root, git log with a parameter is relative to the current
directory.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: René Scharfe @ 2007-11-07 23:21 UTC (permalink / raw)
To: Pierre Habouzit, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20071107001458.GE4382@artemis.corp>
Pierre Habouzit schrieb:
> {
> const char *percent = strchrnul(fmt, '%');
> while (*percent) {
> strbuf_add(sb, fmt, percent - fmt);
> fmt = percent + 1;
>
> /* do your stuff */
>
> percent = strchrnul(fmt, '%');
> }
> strbuf_add(sb, fmt, percent - fmt);
> }
>
>
> Which would require strchrnul, but it's trivial compat/ material for sure.
Grepping through the source I see several places that can be simplified
by converting them to strchrnul(), so I think introducing this GNU
extension is a good idea in any case.
Using strchr()/strchrnul() instead of strbuf_addch()'ing is sensible, of
course. I don't like the duplicate code in your sketch above, though.
I'll try to look into it later today.
Thanks!
René
^ permalink raw reply
* Re: [PATCH 3/3] pretty=format: Avoid some expensive calculations when not needed
From: René Scharfe @ 2007-11-07 23:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711062343050.4362@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Wed, 7 Nov 2007, René Scharfe wrote:
>
>> By the way, the more intrusive surgery required when using strbuf_expand()
>> leads to even faster operation. Here my measurements of most of Paul's
>> test cases (best of three runs):
>>
>> [...]
>
> impressive timings. Although I wonder where the time comes from, as the
> other substitutions should not be _that_ expensive.
I haven't run a profiler, but my two suspects are the malloc()s and
free()s done by interp_set_entry(), and the fact that
format_commit_message() calls interpolate() twice.
> In any case, your approach seems much more sensible, now that we have
> strbuf.
>
>> diff --git a/strbuf.h b/strbuf.h
>> index cd7f295..95071d5 100644
>> --- a/strbuf.h
>> +++ b/strbuf.h
>> @@ -102,6 +102,9 @@ static inline void strbuf_addbuf(struct strbuf *sb, struct strbuf *sb2) {
>> strbuf_add(sb, sb2->buf, sb2->len);
>> }
>>
>> +typedef void (*expand_fn_t) (struct strbuf *sb, const char *placeholder, void *context);
>> +extern void strbuf_expand(struct strbuf *sb, const char *fmt, const char **placeholders, expand_fn_t fn, void *context);
>
> I wonder if it would even faster (but maybe not half as readable) if
> expand_fd_t got the placeholder_index instead of the placeholder.
I doubt it. All this would save is one pointer dereference per
placeholder. I haven't tried and measured this, though.
René
^ permalink raw reply
* Re: Inconsistencies with git log
From: Brian Gernhardt @ 2007-11-07 23:19 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711071503va92a653s25fd978989d5917d@mail.gmail.com>
On Nov 7, 2007, at 6:03 PM, Jon Smirl wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> We also tend to take the approach of viewing the history as that of
>> the whole project.
>
> But if you type 'git log' while cd'd into a subdirectory the whole log
> is almost never what you want. It's this kind of thing that makes git
> harder to use.
Here's where I'd have to disagree with you. If I'm in git.git/
Documentation and am trying to remember which commit I'm trying to
document, suddenly having 90+% of the history vanish would make git
harder to use. Same with my rails projects, my mudlib, etc. Hiding
history is a bad default.
I think the problem is that you're still thinking in the CVS-style per-
file history. "git log" works on the history not the files, so the
automatic filtering simply doesn't make sense. Git's whole-tree
approach makes it much easier to find when Makefile or API changes
have broken your code. But if you know that the error is in a
specific place, then using "." lets you get at it.
However, Dave's suggestion of altering git-status output to be
relative to (but not limited by) CWD has merit. Too bad I don't have
time to work on it right now.
~~ Brian Gernhardt
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jon Smirl @ 2007-11-07 23:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711072309380.4362@racer.site>
On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Besides, adding a space and a dot is not what qualifies for "harder to
> use" with this developer.
It requires teaching people new to git to add the space dot.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] git-branch --with=commit
From: Junio C Hamano @ 2007-11-07 23:15 UTC (permalink / raw)
To: git
This teaches git-branch to limit its listing to branches that
are descendants to the named commit.
When you are using many topic branches, you often would want to
see which branch already includes a commit, so that you know
which can and cannot be rewound without disrupting other people.
One thing that sometimes happens to me is:
* Somebody sends a patch that is a good maint material. I
apply it to 'maint':
$ git checkout maint
$ git am -3 -s obvious-fix.patch
* Then somebody else sends another patch that is possibly a
good maint material, but I'd want to cook it in 'next' to be
extra sure. I fork a topic from 'maint' and apply the patch:
$ git checkout -b xx/maint-fix-foo
$ git am -3 -s ,xx-maint-fix-foo.patch
* A minor typo is found in the "obvious-fix.patch".
The above happens without pushing the results out, so I can
freely recover from it by amending 'maint', as long as I do not
forget to rebase the topics that were forked previously.
With this patch, I could do this to find out which topic
branches already contain the faulty commit:
$ git branch --with=maint^ | grep /
xx/maint-fix-foo
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 50 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3bf40f1..d13e64f 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -184,9 +184,30 @@ struct ref_item {
struct ref_list {
int index, alloc, maxwidth;
struct ref_item *list;
+ struct commit_list *with_commit;
int kinds;
};
+static int has_commit(const unsigned char *sha1, struct commit_list *with_commit)
+{
+ struct commit *commit;
+
+ if (!with_commit)
+ return 1;
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return 0;
+ while (with_commit) {
+ struct commit *other;
+
+ other = with_commit->item;
+ with_commit = with_commit->next;
+ if (in_merge_bases(other, &commit, 1))
+ return 1;
+ }
+ return 0;
+}
+
static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
@@ -206,6 +227,10 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
refname += 10;
}
+ /* Filter with with_commit if specified */
+ if (!has_commit(sha1, ref_list->with_commit))
+ return 0;
+
/* Don't add types the caller doesn't want */
if ((kind & ref_list->kinds) == 0)
return 0;
@@ -296,13 +321,14 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
}
}
-static void print_ref_list(int kinds, int detached, int verbose, int abbrev)
+static void print_ref_list(int kinds, int detached, int verbose, int abbrev, struct commit_list *with_commit)
{
int i;
struct ref_list ref_list;
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
+ ref_list.with_commit = with_commit;
for_each_ref(append_ref, &ref_list);
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
@@ -505,6 +531,22 @@ static void rename_branch(const char *oldname, const char *newname, int force)
die("Branch is renamed, but update of config-file failed");
}
+static int opt_parse_with_commit(const struct option *opt, const char *arg, int unset)
+{
+ unsigned char sha1[20];
+ struct commit *commit;
+
+ if (!arg)
+ return -1;
+ if (get_sha1(arg, sha1))
+ die("malformed object name %s", arg);
+ commit = lookup_commit_reference(sha1);
+ if (!commit)
+ die("no such commit %s", arg);
+ commit_list_insert(commit, opt->value);
+ return 0;
+}
+
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, force_delete = 0, force_create = 0;
@@ -512,6 +554,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
int verbose = 0, abbrev = DEFAULT_ABBREV, detached = 0;
int reflog = 0, track;
int kinds = REF_LOCAL_BRANCH, kind_remote = 0, kind_any = 0;
+ struct commit_list *with_commit = NULL;
struct option options[] = {
OPT_GROUP("Generic options"),
@@ -519,6 +562,9 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "track", &track, "set up tracking mode (see git-pull(1))"),
OPT_BOOLEAN( 0 , "color", &branch_use_color, "use colored output"),
OPT_BOOLEAN('r', NULL, &kind_remote, "act on remote-tracking branches"),
+ OPT_CALLBACK(0, "with", &with_commit, "commit",
+ "print only branches that contain the commit",
+ opt_parse_with_commit),
OPT__ABBREV(&abbrev),
OPT_GROUP("Specific git-branch actions:"),
@@ -566,7 +612,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, force_delete, kinds);
else if (argc == 0)
- print_ref_list(kinds, detached, verbose, abbrev);
+ print_ref_list(kinds, detached, verbose, abbrev, with_commit);
else if (rename && (argc == 1))
rename_branch(head, argv[0], force_rename);
else if (rename && (argc == 2))
--
1.5.3.5.1593.g5baf
^ permalink raw reply related
* Re: [PATCH v3] Add Documentation/CodingGuidelines
From: Junio C Hamano @ 2007-11-07 23:14 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Robin Rosenberg, Andreas Ericsson, Ralf Wildenhues, git
In-Reply-To: <Pine.LNX.4.64.0711072233010.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> new file mode 100644
> index 0000000..2d8656f
> --- /dev/null
> +++ b/Documentation/CodingGuidelines
> @@ -0,0 +1,106 @@
> +As a popular project, we also have some guidelines to keep to the
> +code. For git in general, two rough rules are:
I'd rather not to say "As a popular project" here. That is
something for others to decide, not for us to advertise.
Also we now have three rules here ;-).
> +
> + - Most importantly, we never say "It's in POSIX; we'll happily
> + ignore your needs should your system that does not conform."
"should your system not conform"? "if your system does not
conform"?
> +As for more concrete guidelines, just imitate the existing code
> +(this is a good guideline, no matter which project you are contributing
> +to...). But if you must have some list of rules, here they are.
s/\.\.\.//;
> +For C programs:
> +
> + - Use tabs to indent, and interpret tabs as taking up to 8 spaces
> +
> + - Try to keep to at most 80 characters per line
> +
> + - When declaring pointers, the star sides with the variable name, i.e.
> + "char *string", not "char* string" or "char * string". This makes
> + it easier to understand "char *string, c;"
End each sentence with a full stop "." for consistency.
> +
> + - Do not use curly brackets unnecessarily. I.e.
> +
> + if (bla) {
> + x = 1;
> + }
> +
> + is frowned upon. A gray area is when the statement extends over a
> + few lines, and/or you have a lengthy comment atop of it. Also,
> + like in the Linux kernel, if there is a long list of "else if"
> + statements, it can make sense to add curly brackets to single
> + line blocks.
As Robin suggests, s/Do not use/Avoid using/ feels more in line
with the spirit with the "A gray area is..." description.
I think the official name for {} are "braces", by the way.
> + Double negation is often harder to understand than no negation at
> + all.
> +
> + Some clever tricks, like using the !! operator with arithmetic
> + constructs, can be extremely confusing to others. Avoid them,
> + unless there is a compelling reason to use them.
Need a bullet point "-" before "Double" (but not "Some").
> + - #include system headers in git-compat-util.h. Some headers on some
> + systems show subtle breakages when you change the order, so it is
> + best to keep them in one place.
> +
The first #include in C files except platform specific compat/
implementation should be git-compat-util.h or another header
file that includes it, such as cache.h and builtin.h.
> + - if you are planning a new command, consider writing it in shell or
> + perl first, so that changes in semantics can be easily changed and
> + discussed. Many git commands started out like that, and a few are
> + still scripts.
Begin a statement with a Capital letter, for consistency.
^ permalink raw reply
* Re: Inconsistencies with git log
From: Johannes Schindelin @ 2007-11-07 23:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711071503va92a653s25fd978989d5917d@mail.gmail.com>
Hi,
On Wed, 7 Nov 2007, Jon Smirl wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > We also tend to take the approach of viewing the history as that of
> > the whole project.
>
> But if you type 'git log' while cd'd into a subdirectory the whole log
> is almost never what you want. It's this kind of thing that makes git
> harder to use.
When I am working in a subdirectory, I often want the whole history. For
example, when I am working on the documentation, sometimes I need to look
up a commit real quick, that touched other parts.
Besides, adding a space and a dot is not what qualifies for "harder to
use" with this developer.
Ciao,
Dscho
^ permalink raw reply
* Re: Inconsistencies with git log
From: Jon Smirl @ 2007-11-07 23:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711072255420.4362@racer.site>
On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Shouldn't git log default to "git log ."?
>
> Well, it is in line with the other commands being able to work on
> subdirectories, but doing the whole repository operation by default.
I agree with this and see how it got this way.
> We also tend to take the approach of viewing the history as that of
> the whole project.
But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.
> This approach also means that it is a much more expensive operation to log
> the history as seen by a subdirectory, which is another reason why it is
> not the default.
>
> Hth,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Inconsistencies with git log
From: David Symonds @ 2007-11-07 23:00 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711071445p7cfb6cffx83adb1d84d6bf9d8@mail.gmail.com>
On Nov 8, 2007 9:45 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 7 Nov 2007, Jon Smirl wrote:
> >
> > > In project root:
> > > git log arch/powerpc/platforms/52xx
> > > works as expected
> > >
> > > cd arch/powerpc/platforms/52xx
> > > git log arch/powerpc/platforms/52xx
> > > fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> > > revision or path not in the working tree.
> > > Use '--' to separate paths from revisions
> >
> > Try "git log ."
>
> Shouldn't git log default to "git log ."?
It might be nice if it did, but since Git tracks whole *trees* (not
files) then it makes more sense to show the log of the repository in
its default mode.
On the other hand, it'd sure be nice if git-status would show relative
paths when you're in subdirectories, especially when you're in a
deeply nested directory hierarchy. It's a lot easier to see that
"foo.txt" and "../bar.txt" have modifications. Furthermore, it is the
relative path that you have to pass to git-add anyway, so quick
copy-n-pasting from git-status output often doesn't work.
Dave.
^ permalink raw reply
* Re: Inconsistencies with git log
From: Johannes Schindelin @ 2007-11-07 22:58 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711071445p7cfb6cffx83adb1d84d6bf9d8@mail.gmail.com>
Hi,
On Wed, 7 Nov 2007, Jon Smirl wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 7 Nov 2007, Jon Smirl wrote:
> >
> > > In project root:
> > > git log arch/powerpc/platforms/52xx
> > > works as expected
> > >
> > > cd arch/powerpc/platforms/52xx
> > > git log arch/powerpc/platforms/52xx
> > > fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> > > revision or path not in the working tree.
> > > Use '--' to separate paths from revisions
> >
> > Try "git log ."
>
> Shouldn't git log default to "git log ."?
Well, it is in line with the other commands being able to work on
subdirectories, but doing the whole repository operation by default.
We also tend to take the approach of viewing the history as that of
the whole project.
This approach also means that it is a much more expensive operation to log
the history as seen by a subdirectory, which is another reason why it is
not the default.
Hth,
Dscho
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Luke Lu @ 2007-11-07 22:56 UTC (permalink / raw)
To: Luke Lu; +Cc: Lars Hjemli, Benoit SIGOURE, git
In-Reply-To: <B0D0BB75-58AF-4E4E-8C3F-6E615870016A@vicaya.com>
In case others encounter this problem and want to find a solution...
On Nov 3, 2007, at 2:26 PM, Luke Lu wrote:
> On Nov 3, 2007, at 1:52 PM, Lars Hjemli wrote:
>> On Nov 3, 2007 9:41 PM, Luke Lu <git@vicaya.com> wrote:
>>> On Nov 3, 2007, at 1:32 PM, Lars Hjemli wrote:
>>>> On Nov 3, 2007 9:01 PM, Luke Lu <git@vicaya.com> wrote:
>>>>> I did try to add a "fetch" line for the production branch like
>>>>> this:
>>>>>
>>>>> [svn-remote "svn"]
>>>>> url = svn+ssh://host/svn/project
>>>>> fetch = production:refs/remotes/svn-prod
>>>>> fetch = trunk:refs/remotes/git-svn
>>>>>
>>>>> which is modeled after http://lists-archives.org/git/420712-git-
>>>>> svn-
>>>>> remote-tracking-branch-question.html
>>>>>
>>>> Did you forget to run 'git svn fetch' after modifying your .git/
>>>> config?
>>>
>>> Yes, I did. It didn't seem to do anything.
>>
>> Hmm, it works for me, I've been adding and removing branches like
>> this
>> for months, but my .git/config is slightly different:
>>
>> [svn-remote "svn"]
>> url = svn://example.org
>> fetch = project/trunk:refs/remotes/svn/trunk
>> fetch = project/branches/topic:refs/remotes/svn/topic
>>
>> I don't know if this difference is important, though...
>
> I tried to test this on a local repository like file:///path/
> project. It seems to work and get everything properly upon git svn
> fetch. However it doesn't work for the production branch. If I
> modify the fetch line a bit to svn/prod instead of svn-prod and try
> git svn fetch again. It would hang for about 2 minutes and return 0
> and show nothing in progress. A .git/svn/svn/prod directory is
> created but it's empty.
>
> One thing that might be special for this branch is that it gets
> deleted and recreated/copied all the time from trunk. I wonder if
> git-svn use some kind of heuristics to determine if there is
> anything to fetch and silently failing...
After some permutations, this is the config that worked for me:
[svn-remote "svn"]
url = svn+ssh://host/svn
fetch = project/trunk:refs/remotes/git-svn
fetch = project/production:refs/remotes/svn/production
The primary difference is that I moved 'project' from url to the
fetch specs. My original single trunk config looked like this:
[svn-remote "svn"]
url = svn+ssh://host/svn/project/trunk
fetch = :refs/remotes/git-svn
I wish that "git svn fetch" could be more verbose about what's going
on in this case.
__Luke
^ 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