* 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: why the 'g' prefix on the SHA1 in git-describe output?
From: Andreas Ericsson @ 2007-11-03 15:18 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jim Meyering, git list
In-Reply-To: <8c5c35580711030656h23d5910ah824de41a2cf4eafe@mail.gmail.com>
Lars Hjemli wrote:
> 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.
>
It's been there since 908e5310b958619559d34b0b6da122f058faa47e, which
has the commit-subject 'Add a "git-describe" command'.
I think it'd be more trouble removing it now than it is to keep it,
since a lot of script depend on it being there for parsing out
versioning info in various autobuild- and release scripts.
If you want to change it, I'd suggest adding a "--no-sha1" option
that makes the entire "-g%s" part of the output go away, or
perhaps adding a --format="%v-%d-%g" (for the default behaviour).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] builtin-reset: avoid forking "update-index --refresh"
From: Johannes Schindelin @ 2007-11-03 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Rica, git
In-Reply-To: <7v3axlodw9.fsf@gitster.siamese.dyndns.org>
Instead of forking update-index, call refresh_cache() directly.
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 update_index_refresh(void)
> > +{
> > + const char *argv_update_index[] = {"update-index", "--refresh", NULL};
> > + return run_command_v_opt(argv_update_index, RUN_GIT_CMD);
> > +}
>
> Instead of making a call to this one after read_from_tree()
> returns, immediately before writing the index out at the end of
> read_from_tree(), you have the index in core. I think you can
> call read-cache.c::refresh_index() at that point and then do the
> write_cache(), no?
A little more complicated now, since this is (obviously) on top of
the bug fix I sent out earlier.
I just realised that it partially undoes the changes of that
commit. If you want to, I will redo this mini-series, changing
the first commit to something more similar to this patch.
builtin-reset.c | 53 +++++++++++++++++++++++++++++------------------------
t/t7102-reset.sh | 10 ++++++++++
2 files changed, 39 insertions(+), 24 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 79792ee..44582f2 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -95,26 +95,34 @@ static void print_new_head_line(struct commit *commit)
printf("\n");
}
-static int update_index_refresh(void)
+static int update_index_refresh(int fd, struct lock_file *index_lock)
{
- const char *argv_update_index[] = {"update-index", "--refresh", NULL};
- return run_command_v_opt(argv_update_index, RUN_GIT_CMD);
-}
+ int result;
+
+ if (!index_lock) {
+ index_lock = xcalloc(1, sizeof(struct lock_file));
+ fd = hold_locked_index(index_lock, 1);
+ }
-struct update_cb_data {
- int index_fd;
- struct lock_file *lock;
- int exit_code;
-};
+ if (read_cache() < 0)
+ return error("Could not read index");
+ result = refresh_cache(0) ? 1 : 0;
+ if (write_cache(fd, active_cache, active_nr) ||
+ close(fd) ||
+ commit_locked_index(index_lock))
+ return error ("Could not refresh index");
+ return result;
+}
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;
+ int *discard_flag = data;
/* do_diff_cache() mangled the index */
discard_cache();
+ *discard_flag = 1;
read_cache();
for (i = 0; i < q->nr; i++) {
@@ -128,34 +136,33 @@ 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, index_was_discarded = 0;
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;
+ opt.format_callback_data = &index_was_discarded;
- cb.lock = xcalloc(1, sizeof(struct lock_file));
- cb.index_fd = hold_locked_index(cb.lock, 1);
- cb.exit_code = 0;
+ index_fd = hold_locked_index(lock, 1);
+ index_was_discarded = 0;
read_cache();
if (do_diff_cache(tree_sha1, &opt))
return 1;
diffcore_std(&opt);
diff_flush(&opt);
- return cb.exit_code;
+ if (!index_was_discarded)
+ /* The index is still clobbered from do_diff_cache() */
+ discard_cache();
+ return update_index_refresh(index_fd, lock);
}
static void prepend_reflog_action(const char *action, char *buf, size_t size)
@@ -225,9 +232,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
else if (reset_type != NONE)
die("Cannot do %s reset with paths.",
reset_type_names[reset_type]);
- if (read_from_tree(prefix, argv + i, sha1))
- return 1;
- return update_index_refresh() ? 1 : 0;
+ return read_from_tree(prefix, argv + i, sha1);
}
if (reset_type == NONE)
reset_type = MIXED; /* by default */
@@ -264,7 +269,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
case SOFT: /* Nothing else to do. */
break;
case MIXED: /* Report what has not been updated. */
- update_index_refresh();
+ update_index_refresh(0, NULL);
break;
}
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 506767d..e5c9f30 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -418,4 +418,14 @@ test_expect_success 'resetting an unmodified path is a no-op' '
git diff-index --cached --exit-code HEAD
'
+cat > expect << EOF
+file2: needs update
+EOF
+
+test_expect_success '--mixed refreshes the index' '
+ echo 123 >> file2 &&
+ git reset --mixed HEAD > output &&
+ git diff --exit-code expect output
+'
+
test_done
--
1.5.3.5.1506.g83995
^ permalink raw reply related
* [PATCH] Add support for # in URLs in git-remote (was: Re: [PATCH] New script: git-changelog.perl - revised)
From: Ronald Landheer-Cieslak @ 2007-11-03 15:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, git
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
The attached patch adds support for # signs in URLs passed to git-remote add.
The suggestion that, in stead of putting a # in the URL I should set
up a new public repository with just the topic branch in it triggers a
reaction of dismay in me: to me, Git is a fast and resource-sparing
SCM and setting up a second repository just for publishing a branch
seems more than awkward to me - it's a waste of space and a waste of
(my) time.
So I've taken a look at the git-remote code and added a small patch to
support # signs in git-remote add URLs
1 files changed, 6 insertions(+), 1 deletions(-)
This makes git-remote add behave as if whatever comes after the # in
the URL was passed as a -t option. Other options are still allowed, so
with # in the URL, nothing else changes
HTH
rlc
On Nov 3, 2007 9:58 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.
--
Ronald Landheer-Cieslak
Software Architect
http://www.landheer-cieslak.com/
New White Paper: "Three Good Reasons to Plan Ahead"
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 9aa00ba7096d050bb62e48334a400270afd65735.patch --]
[-- Type: text/x-diff; name=9aa00ba7096d050bb62e48334a400270afd65735.patch, Size: 678 bytes --]
commit 9aa00ba7096d050bb62e48334a400270afd65735
Author: Ronald Landheer-Cieslak <ronald@landheer-cieslak.com>
Date: Sat Nov 3 10:47:00 2007 -0400
Support # in URLs and interpret them as tracking branches
diff --git a/git-remote.perl b/git-remote.perl
index d13e4c1..6b26523 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -271,7 +271,12 @@ sub show_remote {
}
sub add_remote {
- my ($name, $url, $opts) = @_;
+ my ($name, $url_, $opts) = @_;
+
+ my ($url, $branch) = split(/#/, $url_);
+ $opts->{'track'} ||= [];
+ push @{$opts->{'track'}}, $branch if ($branch);
+
if (exists $remote->{$name}) {
print STDERR "remote $name already exists.\n";
exit(1);
^ permalink raw reply related
* Re: [PATCH] Add support for # in URLs in git-remote (was: Re: [PATCH] New script: git-changelog.perl - revised)
From: Johannes Schindelin @ 2007-11-03 15:27 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: Andreas Ericsson, git
In-Reply-To: <67837cd60711030826q6b3b5c00l5b228531ab6a323e@mail.gmail.com>
Hi,
On Sat, 3 Nov 2007, Ronald Landheer-Cieslak wrote:
> The attached patch adds support for # signs in URLs passed to git-remote
> add.
NACK!
Please be polite enough to read up on the _many_ emails on this list about
this very subject.
Not doing so just _wastes_ our time.
Sorry for being so harsh, but this very subject easily cost me 20 hours in
total(!) in the last few weeks.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-format-patch: Number patches when there are more than one
From: Mike Hommey @ 2007-11-03 15:44 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson, Johannes Schindelin, spearce
In-Reply-To: <Pine.LNX.4.64.0710221044080.25221@racer.site>
Automagically enable numbering if we output more than one patch.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
On Mon, Oct 22, 2007 at 10:44:12AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 21 Oct 2007, Andreas Ericsson wrote:
>
> > [PATCH 1/1] looks a bit silly, and automagically handling this in
> > git-format-patch makes some scripting around it a lot more pleasant.
>
> I think you should not use "-n" if you do not want to have the numbers.
> In circumstances as yours, where you can have patch series larger than
> one, I imagine that the "[PATCH 1/1]" bears an important information,
> which is not present in "[PATCH]": this patch series contains only one
> patch.
>
> IOW I do not like your patch: too much DWIDNS (Do What I Did NOT Say) for
> me.
How about the contrary ?
Documentation/git-format-patch.txt | 3 ++-
builtin-log.c | 2 ++
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index f0617ef..b77daed 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -56,7 +56,8 @@ If -o is specified, output files are created in <dir>. Otherwise
they are created in the current working directory.
If -n is specified, instead of "[PATCH] Subject", the first line
-is formatted as "[PATCH n/m] Subject".
+is formatted as "[PATCH n/m] Subject". This is the default when
+there is more than one commit to prepare patches for.
If given --thread, git-format-patch will generate In-Reply-To and
References headers to make the second and subsequent patch mails appear
diff --git a/builtin-log.c b/builtin-log.c
index 8b2bf63..640d6e7 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -642,6 +642,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
list[nr - 1] = commit;
}
total = nr;
+ if (!keep_subject && total > 1)
+ numbered = 1;
if (numbered)
rev.total = total + start_number - 1;
rev.add_signoff = add_signoff;
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Andreas Ericsson @ 2007-11-03 15:59 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Johannes Schindelin, spearce
In-Reply-To: <1194104694-12530-1-git-send-email-mh@glandium.org>
Mike Hommey wrote:
> Automagically enable numbering if we output more than one patch.
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
>
> On Mon, Oct 22, 2007 at 10:44:12AM +0100, Johannes Schindelin wrote:
>> Hi,
>>
>> On Sun, 21 Oct 2007, Andreas Ericsson wrote:
>>
>>> [PATCH 1/1] looks a bit silly, and automagically handling this in
>>> git-format-patch makes some scripting around it a lot more pleasant.
>> I think you should not use "-n" if you do not want to have the numbers.
>> In circumstances as yours, where you can have patch series larger than
>> one, I imagine that the "[PATCH 1/1]" bears an important information,
>> which is not present in "[PATCH]": this patch series contains only one
>> patch.
>>
>> IOW I do not like your patch: too much DWIDNS (Do What I Did NOT Say) for
>> me.
>
> How about the contrary ?
>
Works for me. How does one turn it off?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Mike Hommey @ 2007-11-03 16:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Johannes Schindelin, spearce
In-Reply-To: <472C9AFC.3000509@op5.se>
On Sat, Nov 03, 2007 at 04:59:56PM +0100, Andreas Ericsson wrote:
> Mike Hommey wrote:
>> Automagically enable numbering if we output more than one patch.
>> Signed-off-by: Mike Hommey <mh@glandium.org>
>> ---
>> On Mon, Oct 22, 2007 at 10:44:12AM +0100, Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Sun, 21 Oct 2007, Andreas Ericsson wrote:
>>>
>>>> [PATCH 1/1] looks a bit silly, and automagically handling this in
>>>> git-format-patch makes some scripting around it a lot more pleasant.
>>> I think you should not use "-n" if you do not want to have the numbers.
>>> In circumstances as yours, where you can have patch series larger than
>>> one, I imagine that the "[PATCH 1/1]" bears an important information,
>>> which is not present in "[PATCH]": this patch series contains only one
>>> patch.
>>>
>>> IOW I do not like your patch: too much DWIDNS (Do What I Did NOT Say) for
>>> me.
>> How about the contrary ?
>
> Works for me. How does one turn it off?
Does it make sense to turn it off ?
Mike
^ permalink raw reply
* Re: That new progress meter
From: Alex Riesen @ 2007-11-03 16:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Pierre Habouzit, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.9999.0711031042390.21255@xanadu.home>
Nicolas Pitre, Sat, Nov 03, 2007 15:53:25 +0100:
> 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?
How about keeping track of the length of the last lines the remote end
sent (recv_sideband in sideband.c)? So that we always know how much
spaces to add to clear up to the end of line.
^ permalink raw reply
* Re: why the 'g' prefix on the SHA1 in git-describe output?
From: Jim Meyering @ 2007-11-03 16:10 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Lars Hjemli, git list
In-Reply-To: <472C915E.8070205@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Lars Hjemli wrote:
>> 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.
>>
>
> It's been there since 908e5310b958619559d34b0b6da122f058faa47e, which
> has the commit-subject 'Add a "git-describe" command'.
>
> I think it'd be more trouble removing it now than it is to keep it,
> since a lot of script depend on it being there for parsing out
> versioning info in various autobuild- and release scripts.
>
> If you want to change it, I'd suggest adding a "--no-sha1" option
> that makes the entire "-g%s" part of the output go away, or
> perhaps adding a --format="%v-%d-%g" (for the default behaviour).
Thanks to both of you for the feedback.
FYI, I didn't propose to change it in git.
I was wondering whether to restore the 'g' in snapshot version
numbers for coreutils, autoconf, etc.:
http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/9784/focus=9811
Since coreutils version strings will end up having at least one more "."
(currently they look like this: 6.9-375-3e3f8), that means transforming
a version string into input for git-rev-parse will require the reverse
xform. Once you're doing some transformation, an additional one to
insert the required 'g' is no big deal, so I expect to continue omitting
the 'g' from version strings: makes file names 1 byte shorter.
^ permalink raw reply
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Johannes Schindelin @ 2007-11-03 16:31 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Andreas Ericsson, spearce
In-Reply-To: <1194104694-12530-1-git-send-email-mh@glandium.org>
Hi,
On Sat, 3 Nov 2007, Mike Hommey wrote:
> Automagically enable numbering if we output more than one patch.
>
> Signed-off-by: Mike Hommey <mh@glandium.org>
> ---
>
> On Mon, Oct 22, 2007 at 10:44:12AM +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > On Sun, 21 Oct 2007, Andreas Ericsson wrote:
> >
> > > [PATCH 1/1] looks a bit silly, and automagically handling this in
> > > git-format-patch makes some scripting around it a lot more pleasant.
> >
> > I think you should not use "-n" if you do not want to have the numbers.
> > In circumstances as yours, where you can have patch series larger than
> > one, I imagine that the "[PATCH 1/1]" bears an important information,
> > which is not present in "[PATCH]": this patch series contains only one
> > patch.
> >
> > IOW I do not like your patch: too much DWIDNS (Do What I Did NOT Say) for
> > me.
>
> How about the contrary ?
Still DWIDNSAA.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Andreas Ericsson @ 2007-11-03 16:32 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Johannes Schindelin, spearce
In-Reply-To: <20071103160323.GA13284@glandium.org>
Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 04:59:56PM +0100, Andreas Ericsson wrote:
>> Mike Hommey wrote:
>>> Automagically enable numbering if we output more than one patch.
>>> Signed-off-by: Mike Hommey <mh@glandium.org>
>>> ---
>>> On Mon, Oct 22, 2007 at 10:44:12AM +0100, Johannes Schindelin wrote:
>>>> Hi,
>>>>
>>>> On Sun, 21 Oct 2007, Andreas Ericsson wrote:
>>>>
>>>>> [PATCH 1/1] looks a bit silly, and automagically handling this in
>>>>> git-format-patch makes some scripting around it a lot more pleasant.
>>>> I think you should not use "-n" if you do not want to have the numbers.
>>>> In circumstances as yours, where you can have patch series larger than
>>>> one, I imagine that the "[PATCH 1/1]" bears an important information,
>>>> which is not present in "[PATCH]": this patch series contains only one
>>>> patch.
>>>>
>>>> IOW I do not like your patch: too much DWIDNS (Do What I Did NOT Say) for
>>>> me.
>>> How about the contrary ?
>> Works for me. How does one turn it off?
>
> Does it make sense to turn it off ?
>
Sometimes, yes. I frequently gather several small fixes on a branch and then
send all of them at once. They rarely depend on each other, and apply order
is usually not important, so it doesn't make sense to order them.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-format-patch: Number patches when there are more than one
From: Andreas Ericsson @ 2007-11-03 16:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mike Hommey, git, spearce
In-Reply-To: <Pine.LNX.4.64.0711031631020.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sat, 3 Nov 2007, Mike Hommey wrote:
>
>> Automagically enable numbering if we output more than one patch.
>>
>> Signed-off-by: Mike Hommey <mh@glandium.org>
>> ---
>>
>> On Mon, Oct 22, 2007 at 10:44:12AM +0100, Johannes Schindelin wrote:
>>> Hi,
>>>
>>> On Sun, 21 Oct 2007, Andreas Ericsson wrote:
>>>
>>>> [PATCH 1/1] looks a bit silly, and automagically handling this in
>>>> git-format-patch makes some scripting around it a lot more pleasant.
>>> I think you should not use "-n" if you do not want to have the numbers.
>>> In circumstances as yours, where you can have patch series larger than
>>> one, I imagine that the "[PATCH 1/1]" bears an important information,
>>> which is not present in "[PATCH]": this patch series contains only one
>>> patch.
>>>
>>> IOW I do not like your patch: too much DWIDNS (Do What I Did NOT Say) for
>>> me.
>> How about the contrary ?
>
> Still DWIDNSAA.
>
Every piece of DWIM can be translated as "do what I didn't say". If you had to
say it, it wouldn't be DWIM after all.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [BUG] Invalid rebase command leaves unclean status
From: Frans Pop @ 2007-11-03 17:04 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
The first command results in the creation of an empty .dotest-merge/output
file which blocks any next attempt to do an interactive rebase until it is
manually removed.
$ git rebase master -i
Invalid branchname: -i
$ git rebase -i master
Interactive rebase already started
$ ls .git/.dotest-merge/
output
$ cat .git/.dotest-merge/output
$ rm -r .git/.dotest-merge/
$ git rebase -i master
<works>
This is with git version 1.5.3.5.
Cheers,
Frans Pop
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Strange git-show-branch behavior.
From: Sergei Organov @ 2007-11-03 17:46 UTC (permalink / raw)
To: git
Hello,
I need to ask about git-show-branch once again as I really can't
understand its behavior myself. Could please anybody either confirm bug(s) in
git-show-branch, or explain why does it work this way.
Consider its invocation in a toy repository that has total 6 commits, as
can be seen from this output:
$ git branch
* master
mybranch
$ git rev-list master mybranch --pretty=oneline
e9217caffebd6311073867d410f0c6e46910a13d Go to sleep
5f19837be87493e9b284fe7db03f00f23d006d2e Merged mybranch
2e2a4956db9737faf5f4f296b895500fafab7350 Some fun.
6478a15c48b0a7ce28069310ff5e51f95b250c7c Some work.
48d3660dc2005471c27f1d5b09d334885b612380 Commit message
2c14c05709bde3c1a7bbdd7effbf73a5667fa265 Initial commit
$
Or, using git-show-branch itself:
$ git-show-branch --more=9 master
[master] Go to sleep
[master^] Merged mybranch
[master^^2] Some work.
[master~2] Some fun.
[master~3] Commit message
[master~4] Initial commit
$
[NOTE: the format of this output contradicts the manual page, but it's
not the topic of this post]
Now comes the confusion:
$ git-show-branch --more=9 master mybranch
* [master] Go to sleep
! [mybranch] Some work.
--
* [master] Go to sleep
*+ [mybranch] Some work.
* [master~2] Some fun.
*+ [master~3] Commit message
*+ [master~4] Initial commit
$
In this output, why git doesn't show the merge commit having "Merged
mybranch" commit message?
Yet another confusion:
$ git-show-branch master mybranch
* [master] Go to sleep
! [mybranch] Some work.
--
* [master] Go to sleep
*+ [mybranch] Some work.
$
Why does it stop at "Some work." commit? The manual page says: "Usually
the command stops output upon showing the commit that is the common
ancestor of all the branches.", so I'd expect it should go down to
"Commit message" commit that is the fork point.
$ git --version
git version 1.5.3.5.529.ge3d6d
$
[The version is from today's master, but I tried with git version 1.5.3.4
as well, and with the same result]
--
Sergei.
^ permalink raw reply
* [PATCH 10/5] Migrate git-quiltimport.sh to use git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-03 17:50 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194112219-19968-4-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-quiltimport.sh | 38 +++++++++++++++-----------------------
1 files changed, 15 insertions(+), 23 deletions(-)
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 880c81d..b6c24c8 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -1,5 +1,11 @@
#!/bin/sh
-USAGE='--dry-run --author <author> --patches </path/to/quilt/patch/directory>'
+OPTIONS_SPEC="\
+git-quiltimport [options]
+--
+n,dry-run dry run
+author= author name and email address for patches without any
+patches= path to the quilt series and patches
+"
SUBDIRECTORY_ON=Yes
. git-sh-setup
@@ -8,39 +14,25 @@ quilt_author=""
while test $# != 0
do
case "$1" in
- --au=*|--aut=*|--auth=*|--autho=*|--author=*)
- quilt_author=$(expr "z$1" : 'z-[^=]*\(.*\)')
- shift
- ;;
-
- --au|--aut|--auth|--autho|--author)
- case "$#" in 1) usage ;; esac
+ --author)
shift
quilt_author="$1"
- shift
;;
-
- --dry-run)
- shift
+ -n|--dry-run)
dry_run=1
;;
-
- --pa=*|--pat=*|--patc=*|--patch=*|--patche=*|--patches=*)
- QUILT_PATCHES=$(expr "z$1" : 'z-[^=]*\(.*\)')
- shift
- ;;
-
- --pa|--pat|--patc|--patch|--patche|--patches)
- case "$#" in 1) usage ;; esac
- shift
+ --patches)
QUILT_PATCHES="$1"
shift
;;
-
+ --)
+ shift
+ break;;
*)
- break
+ usage
;;
esac
+ shift
done
# Quilt Author
--
1.5.3.5.1496.gcb1d6-dirty
^ permalink raw reply related
* [PATCH 5/5 FIX SPACING] Migrate git-am.sh to use git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-03 17:50 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194043193-29601-5-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-am.sh | 93 +++++++++++++++++++++++++++++++-----------------------------
1 files changed, 48 insertions(+), 45 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 2514d07..2d2b1c6 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -2,11 +2,25 @@
#
# Copyright (c) 2005, 2006 Junio C Hamano
-USAGE='[--signoff] [--dotest=<dir>] [--keep] [--utf8 | --no-utf8]
- [--3way] [--interactive] [--binary]
- [--whitespace=<option>] [-C<n>] [-p<n>]
- <mbox>|<Maildir>...
- or, when resuming [--skip | --resolved]'
+OPTIONS_SPEC="\
+git-am [options] <mbox>|<Maildir>...
+git-am [options] --resolved
+git-am [options] --skip
+--
+d,dotest= use <dir> and not .dotest
+i,interactive= run interactively
+b,binary pass --allo-binary-replacement to git-apply
+3,3way allow fall back on 3way merging if needed
+s,signoff add a Signed-off-by line to the commit message
+u,utf8 recode into utf8 (default)
+k,keep pass -k flagg to git-mailinfo
+whitespace= pass it through git-apply
+C= pass it through git-apply
+p= pass it through git-apply
+resolvemsg= override error message when patch failure occurs
+r,resolved to be used after a patch failure
+skip skip the current patch"
+
. git-sh-setup
set_reflog_action am
require_work_tree
@@ -110,49 +124,38 @@ git_apply_opt=
while test $# != 0
do
case "$1" in
- -d=*|--d=*|--do=*|--dot=*|--dote=*|--dotes=*|--dotest=*)
- dotest=`expr "z$1" : 'z-[^=]*=\(.*\)'`; shift ;;
- -d|--d|--do|--dot|--dote|--dotes|--dotest)
- case "$#" in 1) usage ;; esac; shift
- dotest="$1"; shift;;
-
- -i|--i|--in|--int|--inte|--inter|--intera|--interac|--interact|\
- --interacti|--interactiv|--interactive)
- interactive=t; shift ;;
-
- -b|--b|--bi|--bin|--bina|--binar|--binary)
- binary=t; shift ;;
-
- -3|--3|--3w|--3wa|--3way)
- threeway=t; shift ;;
- -s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
- sign=t; shift ;;
- -u|--u|--ut|--utf|--utf8)
- utf8=t; shift ;; # this is now default
- --no-u|--no-ut|--no-utf|--no-utf8)
- utf8=; shift ;;
- -k|--k|--ke|--kee|--keep)
- keep=t; shift ;;
-
- -r|--r|--re|--res|--reso|--resol|--resolv|--resolve|--resolved)
- resolved=t; shift ;;
-
- --sk|--ski|--skip)
- skip=t; shift ;;
-
- --whitespace=*|-C*|-p*)
- git_apply_opt="$git_apply_opt $1"; shift ;;
-
- --resolvemsg=*)
- resolvemsg=${1#--resolvemsg=}; shift ;;
-
+ -i|--interactive)
+ interactive=t ;;
+ -b|--binary)
+ binary=t ;;
+ -3|--3way)
+ threeway=t ;;
+ -s--signoff)
+ sign=t ;;
+ -u|--utf8)
+ utf8=t ;; # this is now default
+ --no-utf8)
+ utf8= ;;
+ -k|--keep)
+ keep=t ;;
+ -r|--resolved)
+ resolved=t ;;
+ --skip)
+ skip=t ;;
+ -d|--dotest)
+ shift; dotest=$1;;
+ --resolvemsg)
+ shift; resolvemsg=$1 ;;
+ --whitespace)
+ git_apply_opt="$git_apply_opt $1=$2"; shift ;;
+ -C|-p)
+ git_apply_opt="$git_apply_opt $1$2"; shift ;;
--)
- shift; break ;;
- -*)
- usage ;;
+ shift; break ;;
*)
- break ;;
+ usage ;;
esac
+ shift
done
# If the dotest directory exists, but we have finished applying all the
--
1.5.3.5.1496.gcb1d6-dirty
^ permalink raw reply related
* [PATCH 8/5] Migrate git-instaweb.sh to use git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-03 17:50 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194112219-19968-2-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-instaweb.sh | 73 ++++++++++++++++++++++---------------------------------
1 files changed, 29 insertions(+), 44 deletions(-)
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 95c3e5a..d912bf5 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -2,9 +2,20 @@
#
# Copyright (c) 2006 Eric Wong
#
-USAGE='[--start] [--stop] [--restart]
- [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
- [--module-path=<path> (for Apache2 only)]'
+
+OPTIONS_SPEC="\
+git-instaweb [options] (--start | --stop | --restart)
+--
+l,local only bind on 127.0.0.1
+p,port= the port to bind to
+d,httpd= the command to launch
+b,browser= the browser to launch
+m,module-path= the module path (only needed for apache2)
+ Action
+stop stop the web server
+start start the web server
+restart restart the web server
+"
. git-sh-setup
@@ -78,52 +89,26 @@ do
start_httpd
exit 0
;;
- --local|-l)
+ -l|--local)
local=true
;;
- -d|--httpd|--httpd=*)
- case "$#,$1" in
- *,*=*)
- httpd=`expr "$1" : '-[^=]*=\(.*\)'` ;;
- 1,*)
- usage ;;
- *)
- httpd="$2"
- shift ;;
- esac
+ -d|--httpd)
+ shift
+ httpd="$1"
+ ;;
+ -b|--browser)
+ shift
+ browser="$1"
;;
- -b|--browser|--browser=*)
- case "$#,$1" in
- *,*=*)
- browser=`expr "$1" : '-[^=]*=\(.*\)'` ;;
- 1,*)
- usage ;;
- *)
- browser="$2"
- shift ;;
- esac
+ -p|--port)
+ shift
+ port="$1"
;;
- -p|--port|--port=*)
- case "$#,$1" in
- *,*=*)
- port=`expr "$1" : '-[^=]*=\(.*\)'` ;;
- 1,*)
- usage ;;
- *)
- port="$2"
- shift ;;
- esac
+ -m|--module-path)
+ shift
+ module_path="$1"
;;
- -m|--module-path=*|--module-path)
- case "$#,$1" in
- *,*=*)
- module_path=`expr "$1" : '-[^=]*=\(.*\)'` ;;
- 1,*)
- usage ;;
- *)
- module_path="$2"
- shift ;;
- esac
+ --)
;;
*)
usage
--
1.5.3.5.1496.gcb1d6-dirty
^ permalink raw reply related
* [PATCH 6/5] Migrate git-merge.sh to use git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-03 17:50 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194112219-19968-1-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
git-merge.sh | 125 ++++++++++++++++++++++++---------------------------------
1 files changed, 53 insertions(+), 72 deletions(-)
diff --git a/git-merge.sh b/git-merge.sh
index b9f0519..d19bfc2 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,18 @@
# Copyright (c) 2005 Junio C Hamano
#
-USAGE='[-n] [--summary] [--[no-]commit] [--[no-]squash] [--[no-]ff] [-s <strategy>] [-m=<merge-message>] <commit>+'
+OPTIONS_SPEC="\
+git-merge [options] <remote>...
+git-merge [options] <msg> HEAD <remote>
+--
+summary show a diffstat at the end of the merge
+n,no-summary don't show a diffstat at the end of the merge
+squash create a single commit instead of doing a merge
+commit perform a commit if the merge sucesses (default)
+ff allow fast forward (default)
+s,strategy= merge strategy to use
+m,message= message to be used for the merge commit (if any)
+"
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -132,72 +143,47 @@ merge_name () {
fi
}
-parse_option () {
- case "$1" in
- -n|--n|--no|--no-|--no-s|--no-su|--no-sum|--no-summ|\
- --no-summa|--no-summar|--no-summary)
- show_diffstat=false ;;
- --summary)
- show_diffstat=t ;;
- --sq|--squ|--squa|--squas|--squash)
- allow_fast_forward=t squash=t no_commit=t ;;
- --no-sq|--no-squ|--no-squa|--no-squas|--no-squash)
- allow_fast_forward=t squash= no_commit= ;;
- --c|--co|--com|--comm|--commi|--commit)
- allow_fast_forward=t squash= no_commit= ;;
- --no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
- allow_fast_forward=t squash= no_commit=t ;;
- --ff)
- allow_fast_forward=t squash= no_commit= ;;
- --no-ff)
- allow_fast_forward=false squash= no_commit= ;;
- -s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
- --strateg=*|--strategy=*|\
- -s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
- case "$#,$1" in
- *,*=*)
- strategy=`expr "z$1" : 'z-[^=]*=\(.*\)'` ;;
- 1,*)
- usage ;;
- *)
- strategy="$2"
- shift ;;
- esac
- case " $all_strategies " in
- *" $strategy "*)
- use_strategies="$use_strategies$strategy " ;;
- *)
- die "available strategies are: $all_strategies" ;;
- esac
- ;;
- -m=*|--m=*|--me=*|--mes=*|--mess=*|--messa=*|--messag=*|--message=*)
- merge_msg=`expr "z$1" : 'z-[^=]*=\(.*\)'`
- have_message=t
- ;;
- -m|--m|--me|--mes|--mess|--messa|--messag|--message)
- shift
- case "$#" in
- 1) usage ;;
- esac
- merge_msg="$1"
- have_message=t
- ;;
- -*) usage ;;
- *) return 1 ;;
- esac
- shift
- args_left=$#
-}
-
parse_config () {
- while test $# -gt 0
- do
- parse_option "$@" || usage
- while test $args_left -lt $#
- do
+ while test $# != 0; do
+ case "$1" in
+ -n|--no-summary)
+ show_diffstat=false ;;
+ --summary)
+ show_diffstat=t ;;
+ --squash)
+ allow_fast_forward=t squash=t no_commit=t ;;
+ --no-squash)
+ allow_fast_forward=t squash= no_commit= ;;
+ --commit)
+ allow_fast_forward=t squash= no_commit= ;;
+ --no-commit)
+ allow_fast_forward=t squash= no_commit=t ;;
+ --ff)
+ allow_fast_forward=t squash= no_commit= ;;
+ --no-ff)
+ allow_fast_forward=false squash= no_commit= ;;
+ -s|--strategy)
+ shift
+ case " $all_strategies " in
+ *" $1 "*)
+ use_strategies="$use_strategies$1 " ;;
+ *)
+ die "available strategies are: $all_strategies" ;;
+ esac
+ ;;
+ -m|--message)
shift
- done
+ merge_msg="$1"
+ have_message=t
+ ;;
+ --)
+ shift
+ break ;;
+ *) usage ;;
+ esac
+ shift
done
+ args_left=$#
}
test $# != 0 || usage
@@ -209,17 +195,12 @@ then
mergeopts=$(git config "branch.${branch#refs/heads/}.mergeoptions")
if test -n "$mergeopts"
then
- parse_config $mergeopts
+ parse_config $mergeopts --
fi
fi
-while parse_option "$@"
-do
- while test $args_left -lt $#
- do
- shift
- done
-done
+parse_config "$@"
+while test $args_left -lt $#; do shift; done
if test -z "$show_diffstat"; then
test "$(git config --bool merge.diffstat)" = false && show_diffstat=false
--
1.5.3.5.1496.gcb1d6-dirty
^ permalink raw reply related
* [PATCH 9/5] Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-dashdash
From: Pierre Habouzit @ 2007-11-03 17:50 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194112219-19968-3-git-send-email-madcoder@debian.org>
Also fix some space versus tabs issues.
---
git-checkout.sh | 99 +++++++++++++++++++++++++++----------------------------
1 files changed, 49 insertions(+), 50 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 8993920..5424745 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -1,6 +1,16 @@
#!/bin/sh
-USAGE='[-q] [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
+PARSEOPT_OPTS=--keep-dashdash
+OPTIONS_SPEC="\
+git-branch [options] [<branch>] [<paths>...]
+--
+b= create a new branch started at <branch>
+l create the new branchs reflog
+track tells if the new branch should track the remote branch
+f proceed even if the index or working tree is not HEAD
+m performa three-way merge on local modifications if needed
+q,quiet be quiet
+"
SUBDIRECTORY_OK=Sometimes
. git-sh-setup
require_work_tree
@@ -20,13 +30,12 @@ quiet=
v=-v
LF='
'
-while [ "$#" != "0" ]; do
- arg="$1"
- shift
- case "$arg" in
- "-b")
- newbranch="$1"
+
+while test $# != 0; do
+ case "$1" in
+ -b)
shift
+ newbranch="$1"
[ -z "$newbranch" ] &&
die "git checkout: -b needs a branch name"
git show-ref --verify --quiet -- "refs/heads/$newbranch" &&
@@ -34,64 +43,54 @@ while [ "$#" != "0" ]; do
git check-ref-format "heads/$newbranch" ||
die "git checkout: we do not like '$newbranch' as a branch name."
;;
- "-l")
+ -l)
newbranch_log=-l
;;
- "--track"|"--no-track")
- track="$arg"
+ --track|--no-track)
+ track="$1"
;;
- "-f")
+ -f)
force=1
;;
-m)
merge=1
;;
- "-q")
+ -q|--quiet)
quiet=1
v=
;;
--)
+ shift
break
;;
- -*)
- usage
- ;;
*)
- if rev=$(git rev-parse --verify "$arg^0" 2>/dev/null)
- then
- if [ -z "$rev" ]; then
- echo "unknown flag $arg"
- exit 1
- fi
- new_name="$arg"
- if git show-ref --verify --quiet -- "refs/heads/$arg"
- then
- rev=$(git rev-parse --verify "refs/heads/$arg^0")
- branch="$arg"
- fi
- new="$rev"
- elif rev=$(git rev-parse --verify "$arg^{tree}" 2>/dev/null)
- then
- # checking out selected paths from a tree-ish.
- new="$rev"
- new_name="$arg^{tree}"
- branch=
- else
- new=
- new_name=
- branch=
- set x "$arg" "$@"
- shift
- fi
- case "$1" in
- --)
- shift ;;
- esac
- break
+ usage
;;
- esac
+ esac
+ shift
done
+arg="$1"
+if rev=$(git rev-parse --verify "$arg^0" 2>/dev/null)
+then
+ [ -z "$rev" ] && die "unknown flag $arg"
+ new_name="$arg"
+ if git show-ref --verify --quiet -- "refs/heads/$arg"
+ then
+ rev=$(git rev-parse --verify "refs/heads/$arg^0")
+ branch="$arg"
+ fi
+ new="$rev"
+ shift
+elif rev=$(git rev-parse --verify "$arg^{tree}" 2>/dev/null)
+then
+ # checking out selected paths from a tree-ish.
+ new="$rev"
+ new_name="$arg^{tree}"
+ shift
+fi
+[ "$1" = "--" ] && shift
+
case "$newbranch,$track" in
,--*)
die "git checkout: --track and --no-track require -b"
@@ -138,8 +137,8 @@ Did you intend to checkout '$@' which can not be resolved as commit?"
git ls-files -- "$@" |
git checkout-index -f -u --stdin
- # Run a post-checkout hook -- the HEAD does not change so the
- # current HEAD is passed in for both args
+ # Run a post-checkout hook -- the HEAD does not change so the
+ # current HEAD is passed in for both args
if test -x "$GIT_DIR"/hooks/post-checkout; then
"$GIT_DIR"/hooks/post-checkout $old $old 0
fi
@@ -294,5 +293,5 @@ fi
# Run a post-checkout hook
if test -x "$GIT_DIR"/hooks/post-checkout; then
- "$GIT_DIR"/hooks/post-checkout $old $new 1
+ "$GIT_DIR"/hooks/post-checkout $old $new 1
fi
--
1.5.3.5.1496.gcb1d6-dirty
^ permalink raw reply related
* Re: *[PATCH 2/2] Let git-add--interactive read colors from .gitconfig
From: Junio C Hamano @ 2007-11-03 18:11 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Shawn O. Pearce, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071103022626.253dcd93@paradox.zwell.net>
Dan Zwell <dzwell@zwell.net> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> In addition to a small matter of testing, a more practical issue
>> would be to add PAGER support there, I think.
>
> You mean in general, so that users can view a hunk in the PAGER, then
> be prompted for what to do with it? (Because it doesn't solve the color
> problems, because calling "diff --color" here creates other problems.)
Yes. I see it a much bigger problem that we let a long hunk
scroll off the top of the screen then ask the user what to do
with it, than any coloring of diff.
> ... but it does not highlight
> whitespace at the end of lines or space/tab errors.
No, but you can make it so if you want.
Personally, I think it is not so useful for "add -i" to do so,
as it is too late in the workflow, unless you add it ways to let
you edit and fix the whitespace errors.
^ permalink raw reply
* [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use
From: Linus Torvalds @ 2007-11-03 18:11 UTC (permalink / raw)
To: Marco Costalba, Junio C Hamano; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0711021809060.3342@woody.linux-foundation.org>
This adds support for "--early-output[=n]" as a flag to the "git log"
family of commands. This allows GUI programs to state that they want to
get some output early, in order to be able to show at least something
quickly, even if the full output may take longer to generate.
If no count is specified, a default count of a hundred commits will be
used, although the actual numbr of commits output may be smaller
depending on how many commits were actually found in the first tenth of
a second (or if *everything* was found before that, in which case no
early output will be provided, and only the final list is made
available).
When the full list is generated, there will be a "Final output:" string
prepended to it, regardless of whether any early commits were shown or
not, so that the consumer can always know the difference between early
output and the final list.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
This replaces my 2/2 patch from yesterday, but still relies on the
topo-sorting cleanups in 1/2 (which are really totally independent, and
probably could go in regardless of any of this series).
Instead of having a generic replay mechanism, this one just does *one*
replay, and discards even that if it can generate all the commits really
quickly.
The timeout right now is set to a pretty aggressive one-tenth-of-a-
second, and realistically that could/should probably be longer, but making
it short makes sure that we actually trigger this in normal use, so I
think this is the right approach for the initial implementation.
Try it out, with
git log --early-output=2
and look at what happens: if it cannot generate all the commits in the
first 0.1 seconds, it will take what it *could* generate, sort it
topologically (you can add "--date-order" if you want), and show the first
two commits.
When it then generates the rest, it will add a "Final output:" line, and
then re-generate it all.
The intent is for a GUI front-end to be able to use the first one-hundred
or so commits to populate the commit log, and show the window, and not
have to worry about the fact that the rest of the data (how-ever many
hundred thousand commits there are) may take much more time to arrive.
So not only is this patch pretty straightforward in itself, I think usage
should be pretty straightforward too.
builtin-log.c | 67 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
revision.c | 22 ++++++++++++++++++
revision.h | 4 +++
3 files changed, 93 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index e8b982d..707add2 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -77,11 +77,78 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
}
}
+static void log_show_early(struct rev_info *revs, struct commit_list *list)
+{
+ int i = revs->early_output;
+
+ sort_in_topological_order(&list, revs->lifo);
+ while (list && i) {
+ struct commit *commit = list->item;
+ log_tree_commit(revs, commit);
+ list = list->next;
+ i--;
+ }
+}
+
+static void early_output(int signal)
+{
+ show_early_output = log_show_early;
+}
+
+static void setup_early_output(struct rev_info *rev)
+{
+ struct sigaction sa;
+ struct itimerval v;
+
+ /*
+ * Set up the signal handler, minimally intrusively:
+ * we only set a single volatile integer word (not
+ * using sigatomic_t - trying to avoid unnecessary
+ * system dependencies and headers), and using
+ * SA_RESTART.
+ */
+ memset(&sa, 0, sizeof(sa));
+ sa.sa_handler = early_output;
+ sigemptyset(&sa.sa_mask);
+ sa.sa_flags = SA_RESTART;
+ sigaction(SIGALRM, &sa, NULL);
+
+ /*
+ * If we can get the whole output in less than a
+ * tenth of a second, don't even bother doing the
+ * early-output thing..
+ *
+ * This is a one-time-only trigger.
+ */
+ memset(&v, 0, sizeof(v));
+ v.it_value.tv_sec = 0;
+ v.it_value.tv_usec = 100000;
+ setitimer(ITIMER_REAL, &v, NULL);
+}
+
+static void finish_early_output(struct rev_info *rev)
+{
+ signal(SIGALRM, SIG_IGN);
+ if (rev->shown_one) {
+ rev->shown_one = 0;
+ if (rev->commit_format != CMIT_FMT_ONELINE)
+ putchar(rev->diffopt.line_termination);
+ }
+ printf("Final output:\n");
+}
+
static int cmd_log_walk(struct rev_info *rev)
{
struct commit *commit;
+ if (rev->early_output)
+ setup_early_output(rev);
+
prepare_revision_walk(rev);
+
+ if (rev->early_output)
+ finish_early_output(rev);
+
while ((commit = get_revision(rev)) != NULL) {
log_tree_commit(rev, commit);
if (!rev->reflog_info) {
diff --git a/revision.c b/revision.c
index e85b4af..26610bb 100644
--- a/revision.c
+++ b/revision.c
@@ -10,6 +10,8 @@
#include "reflog-walk.h"
#include "patch-ids.h"
+volatile show_early_output_fn_t show_early_output;
+
static char *path_name(struct name_path *path, const char *name)
{
struct name_path *p;
@@ -533,6 +535,7 @@ static int limit_list(struct rev_info *revs)
struct commit_list *entry = list;
struct commit *commit = list->item;
struct object *obj = &commit->object;
+ show_early_output_fn_t show;
list = list->next;
free(entry);
@@ -550,6 +553,13 @@ static int limit_list(struct rev_info *revs)
if (revs->min_age != -1 && (commit->date > revs->min_age))
continue;
p = &commit_list_insert(commit, p)->next;
+
+ show = show_early_output;
+ if (!show)
+ continue;
+
+ show(revs, newlist);
+ show_early_output = NULL;
}
if (revs->cherry_pick)
cherry_pick_list(newlist, revs);
@@ -991,6 +1001,18 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
revs->topo_order = 1;
continue;
}
+ if (!prefixcmp(arg, "--early-output")) {
+ int count = 100;
+ switch (arg[14]) {
+ case '=':
+ count = atoi(arg+15);
+ /* Fallthrough */
+ case 0:
+ revs->topo_order = 1;
+ revs->early_output = count;
+ continue;
+ }
+ }
if (!strcmp(arg, "--parents")) {
revs->parents = 1;
continue;
diff --git a/revision.h b/revision.h
index 1f64576..d8a5a50 100644
--- a/revision.h
+++ b/revision.h
@@ -30,6 +30,8 @@ struct rev_info {
void *prune_data;
prune_fn_t *prune_fn;
+ unsigned int early_output;
+
/* Traversal flags */
unsigned int dense:1,
no_merges:1,
@@ -105,6 +107,8 @@ struct rev_info {
#define REV_TREE_DIFFERENT 2
/* revision.c */
+typedef void (*show_early_output_fn_t)(struct rev_info *, struct commit_list *);
+volatile show_early_output_fn_t show_early_output;
extern void init_revisions(struct rev_info *revs, const char *prefix);
extern int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def);
^ permalink raw reply related
* Re: Strange git-show-branch behavior.
From: Björn Steinbrink @ 2007-11-03 18:22 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <871wb79q80.fsf@osv.gnss.ru>
On 2007.11.03 20:46:39 +0300, Sergei Organov wrote:
> Hello,
>
> I need to ask about git-show-branch once again as I really can't
> understand its behavior myself. Could please anybody either confirm bug(s) in
> git-show-branch, or explain why does it work this way.
>
> Consider its invocation in a toy repository that has total 6 commits, as
> can be seen from this output:
>
> $ git branch
> * master
> mybranch
> $ git rev-list master mybranch --pretty=oneline
> e9217caffebd6311073867d410f0c6e46910a13d Go to sleep
> 5f19837be87493e9b284fe7db03f00f23d006d2e Merged mybranch
> 2e2a4956db9737faf5f4f296b895500fafab7350 Some fun.
> 6478a15c48b0a7ce28069310ff5e51f95b250c7c Some work.
> 48d3660dc2005471c27f1d5b09d334885b612380 Commit message
> 2c14c05709bde3c1a7bbdd7effbf73a5667fa265 Initial commit
> $
>
> Or, using git-show-branch itself:
>
> $ git-show-branch --more=9 master
> [master] Go to sleep
> [master^] Merged mybranch
> [master^^2] Some work.
> [master~2] Some fun.
> [master~3] Commit message
> [master~4] Initial commit
> $
>
> [NOTE: the format of this output contradicts the manual page, but it's
> not the topic of this post]
>
> Now comes the confusion:
>
> $ git-show-branch --more=9 master mybranch
> * [master] Go to sleep
> ! [mybranch] Some work.
> --
> * [master] Go to sleep
> *+ [mybranch] Some work.
> * [master~2] Some fun.
> *+ [master~3] Commit message
> *+ [master~4] Initial commit
> $
>
> In this output, why git doesn't show the merge commit having "Merged
> mybranch" commit message?
Because you didn't pass --sparse.
>
> Yet another confusion:
>
> $ git-show-branch master mybranch
> * [master] Go to sleep
> ! [mybranch] Some work.
> --
> * [master] Go to sleep
> *+ [mybranch] Some work.
> $
>
> Why does it stop at "Some work." commit? The manual page says: "Usually
> the command stops output upon showing the commit that is the common
> ancestor of all the branches.", so I'd expect it should go down to
> "Commit message" commit that is the fork point.
Common ancestor means, that the commit is reachable through all refs.
Let's take a look at your history:
.-F-. mybranch
/ \
A---B---C---D---E master
There you can see that mybranch can of course reach F, and that master
can reach it, too. E -> D -> F. So the output stops at F, not at B.
Björn
^ permalink raw reply
* [PATCH 11/5] Migrate git-repack.sh to use git-rev-parse --parseopt
From: Pierre Habouzit @ 2007-11-03 18:35 UTC (permalink / raw)
To: gitster, Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <1194112219-19968-5-git-send-email-madcoder@debian.org>
---
git-repack.sh | 23 ++++++++++++++++++-----
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 7220635..4d4840e 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,7 +3,21 @@
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a|-A] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
+OPTIONS_SPEC="\
+git-repack [options]
+--
+a pack everything in a single pack
+A same as -a, and keep unreachable objects too
+d remove redundant packs, and run git-prune-packed
+f pass --no-reuse-delta to git-pack-objects
+q,quiet be quiet
+l pass --local to git-pack-objects
+ Packing constraints
+window= size of the window used for delta compression
+window-memory= same as the above, but limit memory size instead of entries count
+depth= limits the maximum delta depth
+max-pack-size= maximum size of each packfile
+"
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -20,10 +34,9 @@ do
-q) quiet=-q ;;
-f) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
- --max-pack-size=*) extra="$extra $1" ;;
- --window=*) extra="$extra $1" ;;
- --window-memory=*) extra="$extra $1" ;;
- --depth=*) extra="$extra $1" ;;
+ --max-pack-size|--window|--window-memory|--depth)
+ extra="$extra $1=$2"; shift ;;
+ --) shift; break;;
*) usage ;;
esac
shift
--
1.5.3.5.1498.gf0d63-dirty
^ permalink raw reply related
* Re: [PATCH 1/2] Reuse previous annotation when overwriting a tag
From: Junio C Hamano @ 2007-11-03 18:47 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <1194095285-18651-1-git-send-email-mh@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> +static void write_tag_body(int fd, const unsigned char *sha1)
> +{
> ...
> + sp = buf = read_sha1_file(sha1, &type, &size);
> + if (!buf)
> + return;
> + /* skip header */
> + sp = strstr(buf, "\n\n");
I was relieved to see this second assignment to "sp" here.
Why?
Because I wanted to say something about the first assignment to
it, that is done this way:
> + sp = buf = read_sha1_file(sha1, &type, &size);
The original git codebase, as it came from Linus, tends to avoid
assignment to multiple variables in a single statement like this
(and that style is written down in the kernel coding style
document). As I do not have a strong opinion against that
coding style, I've tried to follow it myself. However, I do not
personaly have a strong argument to support enforcing the style
to others.
But in this case, as the variable "sp" is never used before it
is reassigned, I can easily say "drop the useless assignment to
sp there". ;-)
> +
> + if (!sp || !size || type != OBJ_TAG) {
> + free(buf);
> + return;
> + }
> + sp += 2; /* skip the 2 CRs */
You are not skipping carriage returns. You are skipping line
feeds (i.e. s/CRs/LFs/).
> @@ -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);
When prev is not NULL but points at a null_sha1 nobody writes
anything out. Is this intended?
In fact, the calling site always passes prev which is
prev[] in cmd_tag() and cannot be non-NULL.
Why is there "else" in the first place? Even if you start with
the previous tag's message, you are launching the editor for the
user to further edit it, and you would want to give some
instructions, wouldn't you?
^ 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