* missing object on git-gc
From: Yossi Leybovich @ 2007-11-08 0:59 UTC (permalink / raw)
To: git
In-Reply-To: <6C2C79E72C305246B504CBA17B5500C902535D9C@mtlexch01.mtl.com>
I am running the git-gc tool over my repository and get the following error:
> git-gc
...
deltifying 3308 objects...
error: corrupt loose object '<sha1>'
fatal: object <sha1> cannot be read .
error: failed to run repack
when sha1 is 40 bytes number
Does any one know how I can solve thus issue?
Thanks
YOssi
^ permalink raw reply
* Re: [PATCH] hooks--update: allow deleting a tag through git push <remote> :<tag>
From: Junio C Hamano @ 2007-11-08 0:54 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20071107103450.29849.qmail@c27a4ce40673ff.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> The update hook interpretes deleting a tag, no matter if annotated or not,
> through git push <remote> :<tag> as unannotated tag, and declines it by
> default:
> ...
> With this patch deleting a tag is allowed unconditionally, just as
> deleting a branch.
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> templates/hooks--update | 9 ++++++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
Since you are allowing deletion for anything, wouldn't this be
much simpler, I wonder...
---
templates/hooks--update | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--update b/templates/hooks--update
index d8c7626..e12904a 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -41,9 +41,9 @@ if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file t
fi
# --- Check types
-# if $newrev is 0000...0000, it's a commit to delete a branch
+# if $newrev is 0000...0000, it's a commit to delete a ref.
if [ "$newrev" = "0000000000000000000000000000000000000000" ]; then
- newrev_type=commit
+ exit 0 ;# allow anything to be deleted
else
newrev_type=$(git-cat-file -t $newrev)
fi
^ permalink raw reply related
* Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory
From: David Symonds @ 2007-11-08 0:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brian Gernhardt, Jon Smirl, Git Mailing List, gitster
In-Reply-To: <Pine.LNX.4.64.0711080011170.4362@racer.site>
On Nov 8, 2007 11:12 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> 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(-)
Tested, and looks good.
Now that I play with it, though, it seems that a few other bits of git
need updating to handle relative paths okay:
$ cd gitweb/test
$ rm ../../wt-status.h
[oops, what a silly thing to do -- better checkout the latest
revision of it]
$ git status
# On branch next
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: ../../wt-status.h
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout HEAD ../../wt-status.h
fatal: git-ls-files: cannot generate relative filenames containing '..'
[grr....]
$ cd ../..
$ git checkout HEAD .
[that works]
Dave.
^ permalink raw reply
* [PATCH] Re: git-svn fetch doesn't like spaces in branch names
From: Michael J. Cohen @ 2007-11-08 0:53 UTC (permalink / raw)
To: Michael J. Cohen; +Cc: Git Mailing List
In-Reply-To: <654A4D1D-712F-4978-9812-E8FA411FAE0D@mac.com>
> 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 ?
Hacky, but it works.
Signed-off-by: Michael J. Cohen <mjc@cruiseplanners.com>
diff --git a/git-svn.perl b/git-svn.perl
index dd93e32..5dc3b9c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1976,6 +1976,7 @@ sub find_parent_branch {
my $r = $i->{copyfrom_rev};
my $repos_root = $self->ra->{repos_root};
my $url = $self->ra->{url};
+ $branch_from =~ s@([\s])@sprintf("%%%02X", ord($1))@seg;
my $new_url = $repos_root . $branch_from;
print STDERR "Found possible branch point: ",
"$new_url => ", $self->full_url, ", $r\n";
--
1.5.3.5.1590.gfadfad-dirty
^ permalink raw reply related
* Re: Inconsistencies with git log
From: Brian Gernhardt @ 2007-11-08 0:52 UTC (permalink / raw)
To: David Symonds; +Cc: Johannes Schindelin, Jon Smirl, Git Mailing List
In-Reply-To: <ee77f5c20711071614g7f0b9f84oc419590a586e16b7@mail.gmail.com>
On Nov 7, 2007, at 7:14 PM, David Symonds wrote:
> On Nov 8, 2007 11:09 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de
> > wrote:
>> 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
Johannes was referring to the fact that he already produced that
patches for it. :-)
~~ Brian
^ permalink raw reply
* [PATCH v2] Deprecate git-lost-found
From: Johannes Schindelin @ 2007-11-08 0:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk998u6r.fsf@gitster.siamese.dyndns.org>
"git fsck" learnt the option "--lost-found" in v1.5.3-rc0~5, to make
"git lost-found" obsolete. It is time to deprecate "git lost-found".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/RelNotes-1.5.4.txt | 3 +++
Documentation/git-lost-found.txt | 4 ++++
git-lost-found.sh | 2 ++
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/RelNotes-1.5.4.txt b/Documentation/RelNotes-1.5.4.txt
index 133fa64..65dd1b0 100644
--- a/Documentation/RelNotes-1.5.4.txt
+++ b/Documentation/RelNotes-1.5.4.txt
@@ -46,6 +46,9 @@ Updates since v1.5.3
* Various Perforce importer updates.
+ * git-lost-found was deprecated in favor of git-fsck's --lost-found
+ option.
+
Fixes since v1.5.3
------------------
diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt
index bc73911..7f808fc 100644
--- a/Documentation/git-lost-found.txt
+++ b/Documentation/git-lost-found.txt
@@ -11,6 +11,10 @@ SYNOPSIS
DESCRIPTION
-----------
+
+*NOTE*: this command is deprecated. Use gitlink:git-fsck[1] with
+the option '--lost-found' instead.
+
Finds dangling commits and tags from the object database, and
creates refs to them in the .git/lost-found/ directory. Commits and
tags that dereference to commits are stored in .git/lost-found/commit,
diff --git a/git-lost-found.sh b/git-lost-found.sh
index a5a32e7..9cedaf8 100755
--- a/git-lost-found.sh
+++ b/git-lost-found.sh
@@ -5,6 +5,8 @@ SUBDIRECTORY_OK='Yes'
OPTIONS_SPEC=
. git-sh-setup
+echo "WARNING: '$0' is deprecated in favor of 'git fsck --lost-found'" >&2
+
if [ "$#" != "0" ]
then
usage
--
1.5.3.5.1597.g7191
^ permalink raw reply related
* Re: [PATCH v4] Add Documentation/CodingGuidelines
From: Junio C Hamano @ 2007-11-08 0:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Robin Rosenberg, Andreas Ericsson, Ralf Wildenhues, git
In-Reply-To: <Pine.LNX.4.64.0711080033080.4362@racer.site>
Ok, will queue this for 'maint' ;-).
^ permalink raw reply
* Re: [PATCH] Deprecate git-lost-found
From: Johannes Schindelin @ 2007-11-08 0:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk998u6r.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 7 Nov 2007, Junio C Hamano wrote:
> Makes sort of sense. Add deprecation notice to Documentation/
> as well, please.
Of course. Will resend in a minute.
Ciao,
Dscho
^ permalink raw reply
* Re: Inconsistencies with git log
From: Johannes Schindelin @ 2007-11-08 0:35 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711071609t3e5412f1mf02e501b2d820bb3@mail.gmail.com>
Hi,
On Wed, 7 Nov 2007, Jon Smirl wrote:
> 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
Because you are in the subdirectory Documentation/, relative to the
project root. So when you say "Documentation", it tries to find the
file/directory Documentation/Documentation.
Therefore, just say "git log ." and you will get what you want.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v4] Add Documentation/CodingGuidelines
From: Johannes Schindelin @ 2007-11-08 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, Andreas Ericsson, Ralf Wildenhues, git
In-Reply-To: <7vtznx8x86.fsf@gitster.siamese.dyndns.org>
Even if our code is quite a good documentation for our coding style,
some people seem to prefer a document describing it.
The part about the shell scripts is clearly just copied from one of
Junio's helpful mails, and some parts were added from comments by
Junio, Andreas Ericsson and Robin Rosenberg.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/CodingGuidelines | 112 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 112 insertions(+), 0 deletions(-)
create mode 100644 Documentation/CodingGuidelines
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
new file mode 100644
index 0000000..3b042db
--- /dev/null
+++ b/Documentation/CodingGuidelines
@@ -0,0 +1,112 @@
+Like other projects, we also have some guidelines to keep to the
+code. For git in general, three rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+ ignore your needs should your system not conform to it."
+ We live in the real world.
+
+ - However, we often say "Let's stay away from that construct,
+ it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+ this is not in POSIX, it (is so convenient | makes the code
+ much more readable | has other good characteristics) and
+ practically all the platforms we care about support it, so
+ let's use it".
+
+ Again, we live in the real world, and it is sometimes a
+ judgement call, the decision based more on real world
+ constraints people face than what the paper standard says.
+
+
+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 a list of rules,
+here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+ properly nests. It should have been the way Bourne spelled
+ it from day one, but unfortunately isn't.
+
+ - We use ${parameter-word} and its [-=?+] siblings, and their
+ colon'ed "unset or null" form.
+
+ - We use ${parameter#word} and its [#%] siblings, and their
+ doubled "longest matching" form.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - No "Substring Expansion" ${parameter:offset:length}.
+
+ - No shell arrays.
+
+ - No strlen ${#parameter}.
+
+ - No regexp ${parameter/pattern/string}.
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write the noiseword "function" in front of shell
+ functions.
+
+For C programs:
+
+ - We use tabs to indent, and interpret tabs as taking up to
+ 8 spaces.
+
+ - We 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 code
+ like "char *string, c;".
+
+ - We avoid using braces 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 braces to
+ single line blocks.
+
+ - Try to make your code understandable. You may put comments
+ in, but comments invariably tend to stale out when the code
+ they were describing changes. Often splitting a function
+ into two makes the intention of the code much clearer.
+
+ - 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.
+
+ - Use the API. No, really. We have a strbuf (variable length
+ string), several arrays with the ALLOC_GROW() macro, a
+ path_list for sorted string lists, a hash map (mapping struct
+ objects) named "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - The first #include in C files, except in platform specific
+ compat/ implementations, should be git-compat-util.h or another
+ header file that includes it, such as cache.h or 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.
+
+ - Avoid introducing a new dependency into git. This means you
+ usually should stay away from scripting languages not already
+ used in the git core command set (unless your command is clearly
+ separate from it, such as an importer to convert random-scm-X
+ repositories to git).
--
1.5.3.5.1597.g7191
^ permalink raw reply related
* 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
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