* 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
* [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
* [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
* 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
* 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: [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: [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 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
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