* Re: [ANNOUNCE] cgit v0.7
From: Nguyen Thai Ngoc Duy @ 2007-11-03 12:15 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git list
In-Reply-To: <8c5c35580711030408n658eb11fk19d554f0fa3b17@mail.gmail.com>
I wonder why this is not in git's contrib part. It requires git source
code to build and does not seem to require additional dependencies.
It's smaller than gitweb and does not need perl... MinGW porting guys
may even have a look at it while porting git (and I'm thinking about
porting busybox httpd so that it could run out of the box on Windows
;) ).
Any reasons?
On 11/3/07, Lars Hjemli <hjemli@gmail.com> wrote:
> cgit v0.7 (a fast webinterface for git) is now available at
>
> git://hjemli.net/pub/git/cgit
>
> This release includes better search capabilities, better diff,
> filtered and sorted branch/tag lists on the summary page, a simple way
> to switch between branches and finally a much needed restructuring of
> the user interface. There is even a brand new logo, and a number of
> bugfixes.
>
> The latest version can be seen in action on http://hjemli.net/git/
> (disclaimer: I'm not a web/user interface designer, and should not be
> held responsible for any eyeball-related damages).
>
> Big thanks to everyone who submitted patches and feedback!
>
> ---
> Sortlog since v0.6
>
>
> Chris Pickel (3):
> Makefile: add support for DESTDIR
> Make cgit honor CACHE_ROOT as defined in Makefile
> Improve the sample cgitrc file
>
> Lars Hjemli (47):
> Makefile: add missing references to DESTDIR
> cgit v0.6.1
> Revert "Makefile: add missing references to DESTDIR"
> Revert part of "Makefile: add support for DESTDIR"
> cgit v0.6.2
> ui-tree: specify parameter position for all htmlf formats
> ui-tree: show last line of blob
> Add cgit.conf to .gitignore, remove *~
> Remove a few compiler warnings
> Use trim_end() to remove trailing slashes
> Upgrade to GIT 1.5.3.2
> cgit v0.6.3
> Add support for a renamelimit option in cgitrc
> Add prefix parameter to cgit_diff_tree()
> Add prefix parameter to cgit_print_diff()
> ui-commit.c: link to diff instead of tree from diffstat
> css: remove the annoying tr:hover rule for diffstat
> gen-version.sh: don't sed the output from git describe
> ui-diff: add links to pre- and postversion of blobs
> cgit.css: make diff headers more visible
> Use git-1.5.3.3
> Skip unknown header fields when parsing tags and commits
> Add functions and types for ref lists
> Use reflist to print branch info
> Use reflist to print tag info
> Sort tags by age
> Add support for config param summary-tags
> Move logic for age comparision from cmp_tag_age into cmp_age()
> Add support for config param summary-branches
> Add descriptions of summary-branches and summary-tags to cgitrc
> Make cgit_print_branches()/cgit_print_tags() external
> Add support for refs view
> Add links to the new refs page from summary page
> Cleanup code introduced by the filter-refs topic
> cgit_parse_commit(): Add missing call to xstrdup()
> Add html_option() function
> Teach log search about --grep, --author and --committer
> Make print_branch() handle refs not pointing at commits
> Teach cgit_object_link() about tag objects
> Add config param 'index-info'
> Change the cgit layout
> Add search parameters to cgit_log_link
> Fix search form action/hidden fields
> Don't include current path in menu links
> Don't include current SHA1 in 'log' menu-item
> Use GIT-1.5.3.5
> CGIT 0.7
>
> Michael Krelin (2):
> fixed typo in cgitrc
> correct typo in CSS
>
> Shunichi Fuji (1):
> Fix typo in css
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Johannes Schindelin @ 2007-11-03 12:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0711030457se2f5f5bpd9aa463e878cd621@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1940 bytes --]
Hi,
On Sat, 3 Nov 2007, Nguyen Thai Ngoc Duy wrote:
> On 11/3/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Sat, 3 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> >
> > > Without this, work_tree handling code in setup_git_directory will be
> > > activated. If you stay in root work tree (no prefix), it does not
> > > harm. It does if you work from a subdirectory though.
> > >
> > > Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> > > ---
> > > Turns out my patch on NEED_WORK_TREE is fixing a wrong place.
> > >
> > > setup.c | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/setup.c b/setup.c
> > > index 145eca5..6f8f769 100644
> > > --- a/setup.c
> > > +++ b/setup.c
> > > @@ -240,6 +240,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
> > > if (chdir(work_tree_env) < 0)
> > > die ("Could not chdir to %s", work_tree_env);
> > > strcat(buffer, "/");
> > > + inside_work_tree = 1;
> >
> > I really have to wonder why this is needed, as it should be deduced
> > (correctly!) when you ask is_inside_work_tree().
>
> Because setup_git_directory() does not? From what I see,
> setup_git_directory() calls setup_git_directory_gently() then check
> for inside_work_tree variable almost immediately
> (check_repository_format() does not seem to ask
> is_inside_work_tree()).
Ah, I see the problem.
>From your commit message I assumed that you fixed the wrong spot... Which
you did not. It would have helped me if the message had read:
When both GIT_DIR and GIT_WORK_TREE are set, and
setup_git_directory_gently() changes the current working
directory accordingly, it should also set inside_work_tree = 1.
Your fix is the proper one, but it not only fixes setup_git_directory(),
but all callers of setup_git_directory_gently().
Thanks,
Dscho
^ permalink raw reply
* [PATCH] Delay pager setup in git blame
From: Mike Hommey @ 2007-11-03 12:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This avoids to launch the pager when git blame fails for any reason.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
builtin-blame.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 8432b82..aedc294 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2215,9 +2215,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
argv[unk++] = arg;
}
- if (!incremental)
- setup_pager();
-
if (!blame_move_score)
blame_move_score = BLAME_DEFAULT_MOVE_SCORE;
if (!blame_copy_score)
@@ -2411,6 +2408,9 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
read_mailmap(&mailmap, ".mailmap", NULL);
+ if (!incremental)
+ setup_pager();
+
assign_blame(&sb, &revs, opt);
if (incremental)
--
1.5.3.5
^ permalink raw reply related
* [PATCH] Allow 'git blame rev path' to work on bare repository
From: Mike Hommey @ 2007-11-03 12:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194092575-7133-1-git-send-email-mh@glandium.org>
While 'git blame rev -- path' works, 'git blame rev path' didn't.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
builtin-blame.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index aedc294..141287e 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2294,10 +2294,6 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
}
else if (i != argc - 1)
usage(blame_usage); /* garbage at end */
-
- if (!has_path_in_work_tree(path))
- die("cannot stat path %s: %s",
- path, strerror(errno));
}
}
--
1.5.3.5
^ permalink raw reply related
* [PATCH] Make git-blame fail when working tree is needed and we're not in one
From: Mike Hommey @ 2007-11-03 12:22 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194092575-7133-2-git-send-email-mh@glandium.org>
Signed-off-by: Mike Hommey <mh@glandium.org>
---
builtin-blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index 141287e..500ae77 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2338,6 +2338,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
* do not default to HEAD, but use the working tree
* or "--contents".
*/
+ setup_work_tree();
sb.final = fake_working_tree_commit(path, contents_from);
add_pending_object(&revs, &(sb.final->object), ":");
}
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Johannes Schindelin @ 2007-11-03 12:23 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <20071103121002.GA4295@glandium.org>
Hi,
On Sat, 3 Nov 2007, Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> > > +{
> > > + int i;
> > > + unsigned long size;
> > > + enum object_type type;
> > > + char *buf, *sp, *eol;
> > > + size_t len;
> > > +
> > > + sp = buf = read_sha1_file(sha1, &type, &size);
> > > + if (!buf)
> > > + return;
> > > + if (!size || (type != OBJ_TAG)) {
> >
> > Please lose the extra parents.
>
> What do you mean ?
Typo. I meant the parens, and my fingers typed parents. D'oh.
> (...)
> > This can be done much easier with 'sp = strstr(buf, "\n\n");'. You can
> > even do that before the previous if(), to free() && return if there is no
> > body.
> (...)
> > This can be done much easier with 'eob = strstr(sp, "\n" PGP_SIGNATURE
> > "\n");'.
>
> I must say I just stole most of it in show_reference() in the same file.
I agree for the "\n\n"; this was my mistake (IOW it should be fixed both
in show_reference() as well as in your code).
But for the signature, show_reference() _has_ to go line by line, because
the user is allowed to specify a maximal line count. This does not apply
for your function.
> (...)
> > Why not teach write_annotations() (or write_tag_body() like I would prefer
> > it to be called) to grok a null_sha1? It's not like we care for
> > performance here, but rather for readability and ease of use.
>
> I would have if I had looked up for is_null_sha1() earlier ;)
Hehe. This is what I really like about git's mailing list: it is a place
where you learn something new every day.
Ciao,
Dscho
^ permalink raw reply
* why the 'g' prefix on the SHA1 in git-describe output?
From: Jim Meyering @ 2007-11-03 12:25 UTC (permalink / raw)
To: git list
Hello,
Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in
git-describe output? Is there some version-parsing/comparing tool that
misbehaves on a component like the SHA1 that would otherwise start with a
digit but contain non-numeric bytes, too?
Why do I ask? Because I'm using a bastardized version of GIT-VERSION-GEN
in coreutils' build-aux/git-version-gen, and removed the 'g' to shorten
the string by a byte. If there's a good reason (i.e., other than vanity :-)
for the 'g', I'll propose comments for GIT-VERSION-GEN, so others
don't do what I've done.
Jim
^ permalink raw reply
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 12:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711031148460.4362@racer.site>
On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> Why not teach write_annotations() (or write_tag_body() like I would prefer
> it to be called) to grok a null_sha1? It's not like we care for
> performance here, but rather for readability and ease of use.
By the way, I think it would be much better if this function was made
more generic and would not write, but return an strbuf containing the
object body. It could also be used by e.g. git-commit --amend.
What would be the best suited place for such a function ?
Mike
^ permalink raw reply
* Re: [PATCH] Make git-blame fail when working tree is needed and we're not in one
From: Mike Hommey @ 2007-11-03 12:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194092575-7133-3-git-send-email-mh@glandium.org>
Oops, I forgot -n to format-patch. Wasn't there a proposal to have -n
automatically set when outputing several patches ?
Mike
^ permalink raw reply
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Johannes Schindelin @ 2007-11-03 12:36 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <20071103122707.GA7227@glandium.org>
Hi,
On Sat, 3 Nov 2007, Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> > Why not teach write_annotations() (or write_tag_body() like I would prefer
> > it to be called) to grok a null_sha1? It's not like we care for
> > performance here, but rather for readability and ease of use.
>
> By the way, I think it would be much better if this function was made
> more generic and would not write, but return an strbuf containing the
> object body. It could also be used by e.g. git-commit --amend.
>
> What would be the best suited place for such a function ?
editor.c, I'd say.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] cgit v0.7
From: Lars Hjemli @ 2007-11-03 12:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git list
In-Reply-To: <fcaeb9bf0711030515i24174694w5d4fd9b82ca85868@mail.gmail.com>
On Nov 3, 2007 1:15 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> I wonder why this is not in git's contrib part.
Well, there is at least one technical reason: cgit uses git as a
submodule, so if it got merged into contrib I believe it would require
all git cloners to use git 1.5.2 or newer. It could also be
potentially interesting if/when git-checkout becomes submodule-aware
;-)
--
larsh
^ permalink raw reply
* [PATCH 2/2] Small code readability improvement in show_reference() in builtin-tag.c
From: Mike Hommey @ 2007-11-03 13:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1194095285-18651-1-git-send-email-mh@glandium.org>
Signed-off-by: Mike Hommey <mh@glandium.org>
---
builtin-tag.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index e57f57f..3ed5759 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -84,14 +84,13 @@ static int show_reference(const char *refname, const unsigned char *sha1,
sp = buf = read_sha1_file(sha1, &type, &size);
if (!buf)
return 0;
- if (!size) {
+ /* skip header */
+ sp = strstr(buf, "\n\n");
+
+ if (!sp || !size) {
free(buf);
return 0;
}
- /* skip header */
- while (sp + 1 < buf + size &&
- !(sp[0] == '\n' && sp[1] == '\n'))
- sp++;
/* only take up to "lines" lines, and strip the signature */
for (i = 0, sp += 2;
i < filter->lines && sp < buf + size &&
--
1.5.3.5
^ permalink raw reply related
* [PATCH 1/2] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 13:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711031219530.4362@racer.site>
When forcing to overwrite an annotated tag, there are good chances one
wants to keep the old annotation, or modify it, not start from scratch.
This is obviously only triggered for annotated tagging (-a or -s).
Signed-off-by: Mike Hommey <mh@glandium.org>
---
builtin-tag.c | 41 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index 66e5a58..e57f57f 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -247,9 +247,40 @@ static int git_tag_config(const char *var, const char *value)
return git_default_config(var, value);
}
+static void write_tag_body(int fd, const unsigned char *sha1)
+{
+ unsigned long size;
+ enum object_type type;
+ char *buf, *sp, *eob;
+ size_t len;
+
+ if (is_null_sha1(sha1))
+ return;
+
+ sp = buf = read_sha1_file(sha1, &type, &size);
+ if (!buf)
+ return;
+ /* skip header */
+ sp = strstr(buf, "\n\n");
+
+ if (!sp || !size || type != OBJ_TAG) {
+ free(buf);
+ return;
+ }
+ sp += 2; /* skip the 2 CRs */
+ eob = strstr(sp, "\n" PGP_SIGNATURE "\n");
+ if (eob)
+ len = eob - sp;
+ else
+ len = buf + size - sp;
+ write_or_die(fd, sp, len);
+
+ free(buf);
+}
+
static void create_tag(const unsigned char *object, const char *tag,
struct strbuf *buf, int message, int sign,
- unsigned char *result)
+ unsigned char *prev, unsigned char *result)
{
enum object_type type;
char header_buf[1024];
@@ -282,7 +313,11 @@ static void create_tag(const unsigned char *object, const char *tag,
if (fd < 0)
die("could not create file '%s': %s",
path, strerror(errno));
- write_or_die(fd, tag_template, strlen(tag_template));
+
+ if (prev)
+ write_tag_body(fd, prev);
+ else
+ write_or_die(fd, tag_template, strlen(tag_template));
close(fd);
launch_editor(path, buf);
@@ -419,7 +454,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
die("tag '%s' already exists", tag);
if (annotate)
- create_tag(object, tag, &buf, message, sign, object);
+ create_tag(object, tag, &buf, message, sign, prev, object);
lock = lock_any_ref_for_update(ref, prev, 0);
if (!lock)
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 13:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711031236160.4362@racer.site>
On Sat, Nov 03, 2007 at 12:36:36PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 3 Nov 2007, Mike Hommey wrote:
>
> > On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> > > Why not teach write_annotations() (or write_tag_body() like I would prefer
> > > it to be called) to grok a null_sha1? It's not like we care for
> > > performance here, but rather for readability and ease of use.
> >
> > By the way, I think it would be much better if this function was made
> > more generic and would not write, but return an strbuf containing the
> > object body. It could also be used by e.g. git-commit --amend.
> >
> > What would be the best suited place for such a function ?
>
> editor.c, I'd say.
On which topic is this ?
Mike
^ permalink raw reply
* [PATCH] git-reset: do not be confused if there is nothing to reset
From: Johannes Schindelin @ 2007-11-03 13:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, jasampler, gitster
In-Reply-To: <20071103111743.GA29358@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3065 bytes --]
The purpose of the function update_index_from_diff() (which is the
callback function we give do_diff_cache()) is to update those index
entries which differ from the given commit.
Since do_diff_cache() plays games with the in-memory index, this function
discarded the cache and reread it.
Then, back in the function read_from_tree() we wrote the index.
Of course, this broke down when there were no changes and
update_index_from_diff() was not called, and therefore the mangled index
was not discarded.
The solution is to move the index writing into the function
update_index_from_diff().
Noticed by Björn Steinbrink.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-reset.c | 24 ++++++++++++++++++------
t/t7102-reset.sh | 7 +++++++
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index e1dc31e..5467e36 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -113,10 +113,17 @@ static int update_index_refresh(void)
return run_command_v_opt(argv_update_index, RUN_GIT_CMD);
}
+struct update_cb_data {
+ int index_fd;
+ struct lock_file *lock;
+ int exit_code;
+};
+
static void update_index_from_diff(struct diff_queue_struct *q,
struct diff_options *opt, void *data)
{
int i;
+ struct update_cb_data *cb = data;
/* do_diff_cache() mangled the index */
discard_cache();
@@ -133,29 +140,34 @@ static void update_index_from_diff(struct diff_queue_struct *q,
} else
remove_file_from_cache(one->path);
}
+
+ cb->exit_code = write_cache(cb->index_fd, active_cache, active_nr) ||
+ close(cb->index_fd) ||
+ commit_locked_index(cb->lock);
}
static int read_from_tree(const char *prefix, const char **argv,
unsigned char *tree_sha1)
{
- struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
- int index_fd;
struct diff_options opt;
+ struct update_cb_data cb;
memset(&opt, 0, sizeof(opt));
diff_tree_setup_paths(get_pathspec(prefix, (const char **)argv), &opt);
opt.output_format = DIFF_FORMAT_CALLBACK;
opt.format_callback = update_index_from_diff;
+ opt.format_callback_data = &cb;
- index_fd = hold_locked_index(lock, 1);
+ cb.lock = xcalloc(1, sizeof(struct lock_file));
+ cb.index_fd = hold_locked_index(cb.lock, 1);
+ cb.exit_code = 0;
read_cache();
if (do_diff_cache(tree_sha1, &opt))
return 1;
diffcore_std(&opt);
diff_flush(&opt);
- return write_cache(index_fd, active_cache, active_nr) ||
- close(index_fd) ||
- commit_locked_index(lock);
+
+ return cb.exit_code;
}
static void prepend_reflog_action(const char *action, char *buf, size_t size)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index f64b1cb..cea9afb 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -402,4 +402,11 @@ test_expect_success 'test resetting the index at give paths' '
'
+test_expect_success 'resetting an unmodified path is a no-op' '
+ git reset --hard &&
+ git reset -- file1 &&
+ git diff-files --exit-code &&
+ git diff-index --cached --exit-code HEAD
+'
+
test_done
--
1.5.3.5.1505.gd778c
^ permalink raw reply related
* Re: StGIT fails to clean patch series, and to go to a patch
From: Jakub Narebski @ 2007-11-03 13:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0711030332s49877dcep46460121fb6ec712@mail.gmail.com>
Catalin Marinas wrote:
> On 03/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> I have patch series with empty patch in the middle of the stack.
>> After trying to stg-clean (and failing) stack looks like below:
>
> Does 'stg delete gitweb-Update-INSTALL-file' work?
>
>> 1164:[gitweb/web!git]$ stg goto gitweb-Use-config-more
>> Checking for changes in the working directory ... done
>> Traceback (most recent call last):
>
> Does a simple 'stg push' work? I suspect there is something wrong with
> the gitweb-Update-INSTALL-file patch but not sure why or how it could
> get to this inconsistent state?
>
> It's worth checking the values of 'stg id
> gitweb-Update-INSTALL-file//top' and //bottom and whether they are
> commit ids or something else.
1168:[gitweb/web!git]$ stg id gitweb-Update-INSTALL-file
None
1169:[gitweb/web!git]$ stg id gitweb-Update-INSTALL-file//top
None
1170:[gitweb/web!git]$ stg id gitweb-Update-INSTALL-file//bottom
None
1171:[gitweb/web!git]$ stg delete gitweb-Update-INSTALL-file
Traceback (most recent call last):
File "/usr/bin/stg", line 43, in ?
main()
File "/usr/lib/python2.4/site-packages/stgit/main.py", line 284, in main
command.func(parser, options, args)
File "/usr/lib/python2.4/site-packages/stgit/commands/delete.py", line 76, in func
crt_series.delete_patch(patch)
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 919, in delete_patch
patch.delete()
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 160, in delete
for f in os.listdir(self._dir()):
OSError: [Errno 2] No such file or directory: '.git/patches/gitweb/web/patches/gitweb-Update-INSTALL-file'
I wonder how that happened... I'm just interested in recovering
the unapplied commits. There is always reflog, but StGIT does not
create reflog message as it should.
Hmmm... removing gitweb-Update-INSTALL-file line from 'unapplied' file
worked; nice.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Nguyễn Thái Ngọc Duy @ 2007-11-03 13:18 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <20071103100323.GA25305@laptop>
When both GIT_DIR and GIT_WORK_TREE are set, and
setup_git_directory_gently() changes the current working
directory accordingly, it should also set inside_work_tree = 1.
Without this, work_tree handling code in setup_git_directory()
will be activated. If you stay in root work tree (no prefix),
it does not harm. It does if you work from a subdirectory though.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Updated commit message accordingly
setup.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/setup.c b/setup.c
index 145eca5..6f8f769 100644
--- a/setup.c
+++ b/setup.c
@@ -240,6 +240,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (chdir(work_tree_env) < 0)
die ("Could not chdir to %s", work_tree_env);
strcat(buffer, "/");
+ inside_work_tree = 1;
return retval;
}
if (nongit_ok) {
--
1.5.3.rc4.3.gab089
^ permalink raw reply related
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Johannes Schindelin @ 2007-11-03 13:22 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <20071103131030.GA18670@glandium.org>
Hi,
On Sat, 3 Nov 2007, Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 12:36:36PM +0000, Johannes Schindelin wrote:
>
> > On Sat, 3 Nov 2007, Mike Hommey wrote:
> >
> > > On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> > > > Why not teach write_annotations() (or write_tag_body() like I
> > > > would prefer it to be called) to grok a null_sha1? It's not like
> > > > we care for performance here, but rather for readability and ease
> > > > of use.
> > >
> > > By the way, I think it would be much better if this function was
> > > made more generic and would not write, but return an strbuf
> > > containing the object body. It could also be used by e.g. git-commit
> > > --amend.
> > >
> > > What would be the best suited place for such a function ?
> >
> > editor.c, I'd say.
>
> On which topic is this ?
On none so far. But the plan was to move some functions used by both
builtin-tag and builtin-commit (such as launch_editor()) into the files
editor.[ch].
Unfortunately, that plan has not been executed by anybody. Yet.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Johannes Schindelin @ 2007-11-03 13:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20071103131806.GA25109@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 559 bytes --]
Hi,
On Sat, 3 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> When both GIT_DIR and GIT_WORK_TREE are set, and
> setup_git_directory_gently() changes the current working
> directory accordingly, it should also set inside_work_tree = 1.
>
> Without this, work_tree handling code in setup_git_directory()
> will be activated. If you stay in root work tree (no prefix),
> it does not harm. It does if you work from a subdirectory though.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Updated commit message accordingly
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Ronald Landheer-Cieslak @ 2007-11-03 13:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <472C3309.70109@op5.se>
On Nov 3, 2007 4:36 AM, Andreas Ericsson <ae@op5.se> wrote:
> Ronald Landheer-Cieslak wrote:
> >
> > This is also available through git at
> > git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
> >
>
> This mode of specifying a repository + branch was just thoroughly shot
> down in a list discussion, and git certainly doesn't grok it. I'd be a
> happier fella if you didn't use it.
>
Is there a canonical way to specify both the location and the branch
in one shot, then? I must admit that this is the way I've always seen
it specified, so I assumed that this is the way it was done
"canonically". If it isn't, please forgive my ignorance.
rlc
--
Ronald Landheer-Cieslak
Software Architect
http://www.landheer-cieslak.com/
New White Paper: "Three Good Reasons to Plan Ahead"
^ permalink raw reply
* Re: why the 'g' prefix on the SHA1 in git-describe output?
From: Lars Hjemli @ 2007-11-03 13:56 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <871wb7a53d.fsf@rho.meyering.net>
On Nov 3, 2007 1:25 PM, Jim Meyering <jim@meyering.net> wrote:
> Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in
> git-describe output?
I'm not sure what _motivated_ the 'g', but currently git-rev-parse
understands the output from git-describe _if_ the 'g' is present.
--
larsh
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Johannes Schindelin @ 2007-11-03 13:56 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
In-Reply-To: <1194017589-4669-4-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3546 bytes --]
Hi,
On Fri, 2 Nov 2007, Kristian Høgsberg wrote:
> +static char *
> +prepare_index(const char **files, const char *prefix)
> +{
> + int fd;
> + struct tree *tree;
> + struct lock_file *next_index_lock;
> +
> + fd = hold_locked_index(&lock_file, 1);
> + if (read_cache() < 0)
> + die("index file corrupt");
> +
> + if (all) {
> + add_files_to_cache(verbose, NULL, files);
> + if (write_cache(fd, active_cache, active_nr) || close(fd))
> + die("unable to write new_index file");
> + return lock_file.filename;
> + } else if (also) {
> + add_files_to_cache(verbose, prefix, files);
> + if (write_cache(fd, active_cache, active_nr) || close(fd))
> + die("unable to write new_index file");
> + return lock_file.filename;
> + }
Unless something slips by my mind, this could be written as
if (all || also) {
add_files_to_cache(verbose, also ? prefix : NULL, files);
...
}
> +
> + if (interactive)
> + interactive_add();
> +
> + if (*files == NULL) {
> + /* Commit index as-is. */
> + rollback_lock_file(&lock_file);
> + return get_index_file();
> + }
Would an interactive add not conflict with this rollback? And indeed with
the locked index to begin with?
> + /* update the user index file */
> + add_files_to_cache(verbose, prefix, files);
> + if (write_cache(fd, active_cache, active_nr) || close(fd))
> + die("unable to write new_index file");
Does that mean that the index is _always_ written? Even when not
specifying and paths on the command line?
> + /* Uh oh, abusing lock_file to create a garbage collected file */
It's not that bad. But I would mention that it is a temporary index which
you are building.
> +static const char sign_off_header[] = "Signed-off-by: ";
Funny, I thought it was a footer ;-)
> + } else if (!stat(template_file, &statbuf)) {
Should this not test "if (template_file && " first?
> +/* Find out if the message starting at position 'start' in the strbuf
> + * contains only whitespace and Signed-off-by lines. */
> +static int message_is_empty(struct strbuf *sb, int start)
> +{
> + struct strbuf tmpl;
> + const char *nl;
> + int eol, i;
> +
> + /* See if the template is just a prefix of the message. */
> + strbuf_init(&tmpl, 0);
> + if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
> + stripspace(&tmpl, 1);
> + if (start + tmpl.len <= sb->len &&
> + memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
> + start += tmpl.len;
> + }
> + strbuf_release(&tmpl);
The release could go inside the if block, no?
> +static int run_hook(const char *index_file, const char *name, const char *arg)
Would this function not prefer to live in run-command.c?
> +{
> + struct child_process hook;
> + const char *argv[3], *env[2];
> + char index[PATH_MAX];
> +
> + argv[0] = git_path("hooks/%s", name);
> + argv[1] = arg;
> + argv[2] = NULL;
> + snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
> + env[0] = index;
> + env[1] = NULL;
> +
> + if (access(argv[0], X_OK) < 0)
> + return 0;
That check logically belongs 6 lines higher...
> + rev.abbrev = 0;
> + rev.diff = 1;
> + rev.diffopt.output_format =
> + DIFF_FORMAT_SHORTSTAT | DIFF_FORMAT_SUMMARY;
> +
> + rev.verbose_header = 1;
> + rev.show_root_diff = 1;
> + rev.commit_format = get_commit_format("format:%h: %s");
That's interesting. Wouldn't have thought of that. Reusing the log_tree
machinery to output the summary. Cute.
Note that one relatively low-hanging fruit will be to teach builtin-commit
to use a cheaper "no changes?" check when no_edit = 1.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Johannes Schindelin @ 2007-11-03 13:58 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: Andreas Ericsson, git
In-Reply-To: <67837cd60711030646p6d7dc8e3t8a5f5f336e8bbad6@mail.gmail.com>
Hi,
On Sat, 3 Nov 2007, Ronald Landheer-Cieslak wrote:
> On Nov 3, 2007 4:36 AM, Andreas Ericsson <ae@op5.se> wrote:
> > Ronald Landheer-Cieslak wrote:
> > >
> > > This is also available through git at
> > > git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
> > >
> >
> > This mode of specifying a repository + branch was just thoroughly shot
> > down in a list discussion, and git certainly doesn't grok it. I'd be a
> > happier fella if you didn't use it.
> >
> Is there a canonical way to specify both the location and the branch
> in one shot, then?
Yes. Create a repository containing only that branch, as "master", and
point people to that repository.
Hth,
Dscho
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Lars Hjemli @ 2007-11-03 13:59 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Luke Lu, git
In-Reply-To: <87597D7C-60FB-4CD8-BB27-7E870001A899@lrde.epita.fr>
On Nov 3, 2007 11:56 AM, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> On Nov 3, 2007, at 9:19 AM, Luke Lu wrote:
> > 2. Is there a way to add a new svn branch like that (say production
> > or some_branch) to an existing git-svn repository that has trunk
> > cloned?
>
> I don't know, but that'd be great indeed.
>
You can simply add "fetch" lines to the relevant "svn-remote" section
in .git/config.
--
larsh
^ permalink raw reply
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711031321320.4362@racer.site>
On Sat, Nov 03, 2007 at 01:22:44PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 3 Nov 2007, Mike Hommey wrote:
>
> > On Sat, Nov 03, 2007 at 12:36:36PM +0000, Johannes Schindelin wrote:
> >
> > > On Sat, 3 Nov 2007, Mike Hommey wrote:
> > >
> > > > On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> > > > > Why not teach write_annotations() (or write_tag_body() like I
> > > > > would prefer it to be called) to grok a null_sha1? It's not like
> > > > > we care for performance here, but rather for readability and ease
> > > > > of use.
> > > >
> > > > By the way, I think it would be much better if this function was
> > > > made more generic and would not write, but return an strbuf
> > > > containing the object body. It could also be used by e.g. git-commit
> > > > --amend.
> > > >
> > > > What would be the best suited place for such a function ?
> > >
> > > editor.c, I'd say.
> >
> > On which topic is this ?
>
> On none so far. But the plan was to move some functions used by both
> builtin-tag and builtin-commit (such as launch_editor()) into the files
> editor.[ch].
>
> Unfortunately, that plan has not been executed by anybody. Yet.
Anyways, I took a quick glance at builtin-commit.c on pu, and it doesn't
look like it would benefit from having a shared function to get the
commit body. So I'll just forget about this idea for now.
Mike
^ 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