* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Björn Steinbrink @ 2007-11-03 15:06 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
In-Reply-To: <1194017589-4669-4-git-send-email-krh@redhat.com>
On 2007.11.02 11:33:09 -0400, Kristian Høgsberg wrote:
> + if (all && interactive)
> + die("Cannot use -a, --interactive or -i at the same time.");
Shouldn't that be "if (all && (interactive || also))"?
Björn
^ permalink raw reply
* Re: [PATCH] Make git-blame fail when working tree is needed and we're not in one
From: Andreas Ericsson @ 2007-11-03 15:01 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <20071103123031.GA7425@glandium.org>
Mike Hommey wrote:
> Oops, I forgot -n to format-patch. Wasn't there a proposal to have -n
> automatically set when outputing several patches ?
>
No. There was a patch to skip numbering when only one patch was created.
I suppose a different implementation of that patch could make the default
to number when multiple patches are created but not when a single one is.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Alex Riesen @ 2007-11-03 14:58 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: Andreas Ericsson, git
In-Reply-To: <67837cd60711030646p6d7dc8e3t8a5f5f336e8bbad6@mail.gmail.com>
Ronald Landheer-Cieslak, Sat, Nov 03, 2007 14:46:27 +0100:
> 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? ...
Something like this:
Please fetch from
git://vlinder.landheer-cieslak.com/git/git.git topic/git-log-changelog
If one uses git-fetch the result will be in FETCH_HEAD, a pull will
merge it nicely with the commit message like:
"Merge branch 'topic/git-log-changelog' of git://vlinder.landheer-cieslak.com/git/git"
which fits, I believe.
^ permalink raw reply
* Re: That new progress meter
From: Nicolas Pitre @ 2007-11-03 14:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, git
In-Reply-To: <20071103120953.GC13417@artemis.corp>
On Sat, 3 Nov 2007, Pierre Habouzit wrote:
> On Fri, Nov 02, 2007 at 06:36:35PM +0000, Johannes Schindelin wrote:
> > Hi Nico,
> >
> > that new progress meter sure is amazing and useful!
>
> I do agree. There seems to be some glitches though, here is how my
> output looks after a git fetch I just did on git.git:
>
> remote: Generating pack...
> remote: Done counting 310 objects.
> remote: Deltifying 310 objects... | Here we have a glitch |
> remote: 100% (310/310) done `-------vvvv----------'
> remote: Total 310 (delta 160), reused 178 (delta 112)iB/s
> Receiving objects: 100% (310/310), 379.98 KiB | 136 KiB/s, done.
> Resolving deltas: 100% (160/160), done.
I know. This is why i TRIED TO KEEP THE "Receiving objects" line as
short as possible.
> FWIW, maybe instead using spaces to erase lines we could use minimal
> vt100 codes[0] like:
>
> Erase End of Line <ESC>[K
> Erases from the current cursor position to the end of the current line.
I thought about that too, but this is not perfectly portable to all
terminals according to a quick glance at /etc/termcap. Does the Windows
console support it? Also we might prefer not to rely on termcap/terminfo
library calls.
The other solution is to make the remote object summary line a bit
longer, but this will be effective only when remote servers are
upgraded. Might that be good enough?
Nicolas
^ permalink raw reply
* Re: [StGit RFC] A more structured way of calling git
From: Yann Dirson @ 2007-11-03 14:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: Karl Hasselström, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0711030356j4dcd31cbl54d838107240b3d0@mail.gmail.com>
On Sat, Nov 03, 2007 at 10:56:36AM +0000, Catalin Marinas wrote:
> On 26/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> > I wanted to build an StGit command that coalesced adjacent patches to
> > a single patch. Because the end result tree would still be the same,
> > this should be doable without ever involving HEAD, the index, or the
> > worktree.
>
> Wouldn't HEAD need to be modified since the commit log changes
> slightly, even though the tree is the same. Or am I misunderstanding
> this?
This reminds me of someone suggesting that some patches could be
represented by more than one commit. But I'm not sure such a beast
would be useful - I fear that would make StGIT much more complicated,
but would it really make things better ?
Best regards,
--
Yann
^ permalink raw reply
* [PATCH] builtin-reset: do not call "ls-files --unmerged"
From: Johannes Schindelin @ 2007-11-03 14:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Rica, git
In-Reply-To: <7v3axlodw9.fsf@gitster.siamese.dyndns.org>
Since reset is a builtin now, it can use the full power of libgit.a
and check for unmerged entries itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 11 Sep 2007, Junio C Hamano wrote:
> Carlos Rica <jasampler@gmail.com> writes:
>
> > +static int unmerged_files(void)
> > +{
> > [...]
> > +}
>
> Not that git-reset is so performance sensitive, but you could do
> this from built-in without exec, by just reading the index and
> checking if you have a higher-stage entry yourself.
Hereby done.
builtin-reset.c | 28 ++++++++--------------------
t/t7102-reset.sh | 9 +++++++++
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 5467e36..79792ee 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -46,26 +46,14 @@ static inline int is_merge(void)
static int unmerged_files(void)
{
- char b;
- ssize_t len;
- struct child_process cmd;
- const char *argv_ls_files[] = {"ls-files", "--unmerged", NULL};
-
- memset(&cmd, 0, sizeof(cmd));
- cmd.argv = argv_ls_files;
- cmd.git_cmd = 1;
- cmd.out = -1;
-
- if (start_command(&cmd))
- die("Could not run sub-command: git ls-files");
-
- len = xread(cmd.out, &b, 1);
- if (len < 0)
- die("Could not read output from git ls-files: %s",
- strerror(errno));
- finish_command(&cmd);
-
- return len;
+ int i;
+ read_cache();
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ if (ce_stage(ce))
+ return 1;
+ }
+ return 0;
}
static int reset_index_file(const unsigned char *sha1, int is_hard_reset)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index cea9afb..506767d 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -59,6 +59,15 @@ test_expect_success 'giving a non existing revision should fail' '
check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
'
+test_expect_success 'reset --soft with unmerged index should fail' '
+ touch .git/MERGE_HEAD &&
+ echo "100644 44c5b5884550c17758737edcced463447b91d42b 1 un" |
+ git update-index --index-info &&
+ ! git reset --soft HEAD &&
+ rm .git/MERGE_HEAD &&
+ git rm --cached -- un
+'
+
test_expect_success \
'giving paths with options different than --mixed should fail' '
! git reset --soft -- first &&
--
1.5.3.5.1506.g83995
^ permalink raw reply related
* [PATCH] RelNotes-1.5.3.5: fix typo
From: David D Kilzer @ 2007-11-03 14:04 UTC (permalink / raw)
To: git; +Cc: David D Kilzer
Signed-off-by: David D Kilzer <ddkilzer@kilzer.net>
---
Documentation/RelNotes-1.5.3.5.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/RelNotes-1.5.3.5.txt b/Documentation/RelNotes-1.5.3.5.txt
index 4e46d2c..f99a2cd 100644
--- a/Documentation/RelNotes-1.5.3.5.txt
+++ b/Documentation/RelNotes-1.5.3.5.txt
@@ -63,8 +63,8 @@ Fixes since v1.5.3.4
* Git segfaulted when reading an invalid .gitattributes file. Fixed.
- * post-receive-email example hook fixed was fixed for
- non-fast-forward updates.
+ * post-receive-email example hook was fixed for non-fast-forward
+ updates.
* Documentation updates for supported (but previously undocumented)
options of "git-archive" and "git-reflog".
--
1.5.3.4
^ permalink raw reply related
* 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
* 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] 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: [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: 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] 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: [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] 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
* [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: 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] 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: [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 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
* [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
* 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
* 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: [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: 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
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