* 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: [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
* [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] 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] 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
* [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
* 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
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Björn Steinbrink @ 2007-11-03 15:06 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
In-Reply-To: <1194017589-4669-4-git-send-email-krh@redhat.com>
On 2007.11.02 11:33:09 -0400, Kristian Høgsberg wrote:
> + if (all && interactive)
> + die("Cannot use -a, --interactive or -i at the same time.");
Shouldn't that be "if (all && (interactive || also))"?
Björn
^ permalink raw reply
* Re: [PATCH] Make git-blame fail when working tree is needed and we're not in one
From: Andreas Ericsson @ 2007-11-03 15:01 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <20071103123031.GA7425@glandium.org>
Mike Hommey wrote:
> Oops, I forgot -n to format-patch. Wasn't there a proposal to have -n
> automatically set when outputing several patches ?
>
No. There was a patch to skip numbering when only one patch was created.
I suppose a different implementation of that patch could make the default
to number when multiple patches are created but not when a single one is.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Alex Riesen @ 2007-11-03 14:58 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: Andreas Ericsson, git
In-Reply-To: <67837cd60711030646p6d7dc8e3t8a5f5f336e8bbad6@mail.gmail.com>
Ronald Landheer-Cieslak, Sat, Nov 03, 2007 14:46:27 +0100:
> On Nov 3, 2007 4:36 AM, Andreas Ericsson <ae@op5.se> wrote:
> > Ronald Landheer-Cieslak wrote:
> > >
> > > This is also available through git at
> > > git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
> > >
> >
> > This mode of specifying a repository + branch was just thoroughly shot
> > down in a list discussion, and git certainly doesn't grok it. I'd be a
> > happier fella if you didn't use it.
> >
> Is there a canonical way to specify both the location and the branch
> in one shot, then? ...
Something like this:
Please fetch from
git://vlinder.landheer-cieslak.com/git/git.git topic/git-log-changelog
If one uses git-fetch the result will be in FETCH_HEAD, a pull will
merge it nicely with the commit message like:
"Merge branch 'topic/git-log-changelog' of git://vlinder.landheer-cieslak.com/git/git"
which fits, I believe.
^ permalink raw reply
* Re: That new progress meter
From: Nicolas Pitre @ 2007-11-03 14:53 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, git
In-Reply-To: <20071103120953.GC13417@artemis.corp>
On Sat, 3 Nov 2007, Pierre Habouzit wrote:
> On Fri, Nov 02, 2007 at 06:36:35PM +0000, Johannes Schindelin wrote:
> > Hi Nico,
> >
> > that new progress meter sure is amazing and useful!
>
> I do agree. There seems to be some glitches though, here is how my
> output looks after a git fetch I just did on git.git:
>
> remote: Generating pack...
> remote: Done counting 310 objects.
> remote: Deltifying 310 objects... | Here we have a glitch |
> remote: 100% (310/310) done `-------vvvv----------'
> remote: Total 310 (delta 160), reused 178 (delta 112)iB/s
> Receiving objects: 100% (310/310), 379.98 KiB | 136 KiB/s, done.
> Resolving deltas: 100% (160/160), done.
I know. This is why i TRIED TO KEEP THE "Receiving objects" line as
short as possible.
> FWIW, maybe instead using spaces to erase lines we could use minimal
> vt100 codes[0] like:
>
> Erase End of Line <ESC>[K
> Erases from the current cursor position to the end of the current line.
I thought about that too, but this is not perfectly portable to all
terminals according to a quick glance at /etc/termcap. Does the Windows
console support it? Also we might prefer not to rely on termcap/terminfo
library calls.
The other solution is to make the remote object summary line a bit
longer, but this will be effective only when remote servers are
upgraded. Might that be good enough?
Nicolas
^ permalink raw reply
* Re: [StGit RFC] A more structured way of calling git
From: Yann Dirson @ 2007-11-03 14:28 UTC (permalink / raw)
To: Catalin Marinas
Cc: Karl Hasselström, David Kågedal, Git Mailing List
In-Reply-To: <b0943d9e0711030356j4dcd31cbl54d838107240b3d0@mail.gmail.com>
On Sat, Nov 03, 2007 at 10:56:36AM +0000, Catalin Marinas wrote:
> On 26/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> > I wanted to build an StGit command that coalesced adjacent patches to
> > a single patch. Because the end result tree would still be the same,
> > this should be doable without ever involving HEAD, the index, or the
> > worktree.
>
> Wouldn't HEAD need to be modified since the commit log changes
> slightly, even though the tree is the same. Or am I misunderstanding
> this?
This reminds me of someone suggesting that some patches could be
represented by more than one commit. But I'm not sure such a beast
would be useful - I fear that would make StGIT much more complicated,
but would it really make things better ?
Best regards,
--
Yann
^ permalink raw reply
* [PATCH] builtin-reset: do not call "ls-files --unmerged"
From: Johannes Schindelin @ 2007-11-03 14:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlos Rica, git
In-Reply-To: <7v3axlodw9.fsf@gitster.siamese.dyndns.org>
Since reset is a builtin now, it can use the full power of libgit.a
and check for unmerged entries itself.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 11 Sep 2007, Junio C Hamano wrote:
> Carlos Rica <jasampler@gmail.com> writes:
>
> > +static int unmerged_files(void)
> > +{
> > [...]
> > +}
>
> Not that git-reset is so performance sensitive, but you could do
> this from built-in without exec, by just reading the index and
> checking if you have a higher-stage entry yourself.
Hereby done.
builtin-reset.c | 28 ++++++++--------------------
t/t7102-reset.sh | 9 +++++++++
2 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index 5467e36..79792ee 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -46,26 +46,14 @@ static inline int is_merge(void)
static int unmerged_files(void)
{
- char b;
- ssize_t len;
- struct child_process cmd;
- const char *argv_ls_files[] = {"ls-files", "--unmerged", NULL};
-
- memset(&cmd, 0, sizeof(cmd));
- cmd.argv = argv_ls_files;
- cmd.git_cmd = 1;
- cmd.out = -1;
-
- if (start_command(&cmd))
- die("Could not run sub-command: git ls-files");
-
- len = xread(cmd.out, &b, 1);
- if (len < 0)
- die("Could not read output from git ls-files: %s",
- strerror(errno));
- finish_command(&cmd);
-
- return len;
+ int i;
+ read_cache();
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ if (ce_stage(ce))
+ return 1;
+ }
+ return 0;
}
static int reset_index_file(const unsigned char *sha1, int is_hard_reset)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index cea9afb..506767d 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -59,6 +59,15 @@ test_expect_success 'giving a non existing revision should fail' '
check_changes 3ec39651e7f44ea531a5de18a9fa791c0fd370fc
'
+test_expect_success 'reset --soft with unmerged index should fail' '
+ touch .git/MERGE_HEAD &&
+ echo "100644 44c5b5884550c17758737edcced463447b91d42b 1 un" |
+ git update-index --index-info &&
+ ! git reset --soft HEAD &&
+ rm .git/MERGE_HEAD &&
+ git rm --cached -- un
+'
+
test_expect_success \
'giving paths with options different than --mixed should fail' '
! git reset --soft -- first &&
--
1.5.3.5.1506.g83995
^ permalink raw reply related
* [PATCH] RelNotes-1.5.3.5: fix typo
From: David D Kilzer @ 2007-11-03 14:04 UTC (permalink / raw)
To: git; +Cc: David D Kilzer
Signed-off-by: David D Kilzer <ddkilzer@kilzer.net>
---
Documentation/RelNotes-1.5.3.5.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/RelNotes-1.5.3.5.txt b/Documentation/RelNotes-1.5.3.5.txt
index 4e46d2c..f99a2cd 100644
--- a/Documentation/RelNotes-1.5.3.5.txt
+++ b/Documentation/RelNotes-1.5.3.5.txt
@@ -63,8 +63,8 @@ Fixes since v1.5.3.4
* Git segfaulted when reading an invalid .gitattributes file. Fixed.
- * post-receive-email example hook fixed was fixed for
- non-fast-forward updates.
+ * post-receive-email example hook was fixed for non-fast-forward
+ updates.
* Documentation updates for supported (but previously undocumented)
options of "git-archive" and "git-reflog".
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Mike Hommey @ 2007-11-03 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711031321320.4362@racer.site>
On Sat, Nov 03, 2007 at 01:22:44PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 3 Nov 2007, Mike Hommey wrote:
>
> > On Sat, Nov 03, 2007 at 12:36:36PM +0000, Johannes Schindelin wrote:
> >
> > > On Sat, 3 Nov 2007, Mike Hommey wrote:
> > >
> > > > On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> > > > > Why not teach write_annotations() (or write_tag_body() like I
> > > > > would prefer it to be called) to grok a null_sha1? It's not like
> > > > > we care for performance here, but rather for readability and ease
> > > > > of use.
> > > >
> > > > By the way, I think it would be much better if this function was
> > > > made more generic and would not write, but return an strbuf
> > > > containing the object body. It could also be used by e.g. git-commit
> > > > --amend.
> > > >
> > > > What would be the best suited place for such a function ?
> > >
> > > editor.c, I'd say.
> >
> > On which topic is this ?
>
> On none so far. But the plan was to move some functions used by both
> builtin-tag and builtin-commit (such as launch_editor()) into the files
> editor.[ch].
>
> Unfortunately, that plan has not been executed by anybody. Yet.
Anyways, I took a quick glance at builtin-commit.c on pu, and it doesn't
look like it would benefit from having a shared function to get the
commit body. So I'll just forget about this idea for now.
Mike
^ permalink raw reply
* Re: git-svn questions: how to clone/init non-standard layout branches/tags?
From: Lars Hjemli @ 2007-11-03 13:59 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Luke Lu, git
In-Reply-To: <87597D7C-60FB-4CD8-BB27-7E870001A899@lrde.epita.fr>
On Nov 3, 2007 11:56 AM, Benoit SIGOURE <tsuna@lrde.epita.fr> wrote:
> On Nov 3, 2007, at 9:19 AM, Luke Lu wrote:
> > 2. Is there a way to add a new svn branch like that (say production
> > or some_branch) to an existing git-svn repository that has trunk
> > cloned?
>
> I don't know, but that'd be great indeed.
>
You can simply add "fetch" lines to the relevant "svn-remote" section
in .git/config.
--
larsh
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Johannes Schindelin @ 2007-11-03 13:58 UTC (permalink / raw)
To: Ronald Landheer-Cieslak; +Cc: Andreas Ericsson, git
In-Reply-To: <67837cd60711030646p6d7dc8e3t8a5f5f336e8bbad6@mail.gmail.com>
Hi,
On Sat, 3 Nov 2007, Ronald Landheer-Cieslak wrote:
> On Nov 3, 2007 4:36 AM, Andreas Ericsson <ae@op5.se> wrote:
> > Ronald Landheer-Cieslak wrote:
> > >
> > > This is also available through git at
> > > git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
> > >
> >
> > This mode of specifying a repository + branch was just thoroughly shot
> > down in a list discussion, and git certainly doesn't grok it. I'd be a
> > happier fella if you didn't use it.
> >
> Is there a canonical way to specify both the location and the branch
> in one shot, then?
Yes. Create a repository containing only that branch, as "master", and
point people to that repository.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 4/4] Implement git commit and status as a builtin commands.
From: Johannes Schindelin @ 2007-11-03 13:56 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: Junio C Hamano, git
In-Reply-To: <1194017589-4669-4-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3546 bytes --]
Hi,
On Fri, 2 Nov 2007, Kristian Høgsberg wrote:
> +static char *
> +prepare_index(const char **files, const char *prefix)
> +{
> + int fd;
> + struct tree *tree;
> + struct lock_file *next_index_lock;
> +
> + fd = hold_locked_index(&lock_file, 1);
> + if (read_cache() < 0)
> + die("index file corrupt");
> +
> + if (all) {
> + add_files_to_cache(verbose, NULL, files);
> + if (write_cache(fd, active_cache, active_nr) || close(fd))
> + die("unable to write new_index file");
> + return lock_file.filename;
> + } else if (also) {
> + add_files_to_cache(verbose, prefix, files);
> + if (write_cache(fd, active_cache, active_nr) || close(fd))
> + die("unable to write new_index file");
> + return lock_file.filename;
> + }
Unless something slips by my mind, this could be written as
if (all || also) {
add_files_to_cache(verbose, also ? prefix : NULL, files);
...
}
> +
> + if (interactive)
> + interactive_add();
> +
> + if (*files == NULL) {
> + /* Commit index as-is. */
> + rollback_lock_file(&lock_file);
> + return get_index_file();
> + }
Would an interactive add not conflict with this rollback? And indeed with
the locked index to begin with?
> + /* update the user index file */
> + add_files_to_cache(verbose, prefix, files);
> + if (write_cache(fd, active_cache, active_nr) || close(fd))
> + die("unable to write new_index file");
Does that mean that the index is _always_ written? Even when not
specifying and paths on the command line?
> + /* Uh oh, abusing lock_file to create a garbage collected file */
It's not that bad. But I would mention that it is a temporary index which
you are building.
> +static const char sign_off_header[] = "Signed-off-by: ";
Funny, I thought it was a footer ;-)
> + } else if (!stat(template_file, &statbuf)) {
Should this not test "if (template_file && " first?
> +/* Find out if the message starting at position 'start' in the strbuf
> + * contains only whitespace and Signed-off-by lines. */
> +static int message_is_empty(struct strbuf *sb, int start)
> +{
> + struct strbuf tmpl;
> + const char *nl;
> + int eol, i;
> +
> + /* See if the template is just a prefix of the message. */
> + strbuf_init(&tmpl, 0);
> + if (template_file && strbuf_read_file(&tmpl, template_file, 0) > 0) {
> + stripspace(&tmpl, 1);
> + if (start + tmpl.len <= sb->len &&
> + memcmp(tmpl.buf, sb->buf + start, tmpl.len) == 0)
> + start += tmpl.len;
> + }
> + strbuf_release(&tmpl);
The release could go inside the if block, no?
> +static int run_hook(const char *index_file, const char *name, const char *arg)
Would this function not prefer to live in run-command.c?
> +{
> + struct child_process hook;
> + const char *argv[3], *env[2];
> + char index[PATH_MAX];
> +
> + argv[0] = git_path("hooks/%s", name);
> + argv[1] = arg;
> + argv[2] = NULL;
> + snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
> + env[0] = index;
> + env[1] = NULL;
> +
> + if (access(argv[0], X_OK) < 0)
> + return 0;
That check logically belongs 6 lines higher...
> + rev.abbrev = 0;
> + rev.diff = 1;
> + rev.diffopt.output_format =
> + DIFF_FORMAT_SHORTSTAT | DIFF_FORMAT_SUMMARY;
> +
> + rev.verbose_header = 1;
> + rev.show_root_diff = 1;
> + rev.commit_format = get_commit_format("format:%h: %s");
That's interesting. Wouldn't have thought of that. Reusing the log_tree
machinery to output the summary. Cute.
Note that one relatively low-hanging fruit will be to teach builtin-commit
to use a cheaper "no changes?" check when no_edit = 1.
Thanks,
Dscho
^ permalink raw reply
* Re: why the 'g' prefix on the SHA1 in git-describe output?
From: Lars Hjemli @ 2007-11-03 13:56 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <871wb7a53d.fsf@rho.meyering.net>
On Nov 3, 2007 1:25 PM, Jim Meyering <jim@meyering.net> wrote:
> Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in
> git-describe output?
I'm not sure what _motivated_ the 'g', but currently git-rev-parse
understands the output from git-describe _if_ the 'g' is present.
--
larsh
^ permalink raw reply
* Re: [PATCH] New script: git-changelog.perl - revised
From: Ronald Landheer-Cieslak @ 2007-11-03 13:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <472C3309.70109@op5.se>
On Nov 3, 2007 4:36 AM, Andreas Ericsson <ae@op5.se> wrote:
> Ronald Landheer-Cieslak wrote:
> >
> > This is also available through git at
> > git://vlinder.landheer-cieslak.com/git/git.git#topic/git-log-changelog
> >
>
> This mode of specifying a repository + branch was just thoroughly shot
> down in a list discussion, and git certainly doesn't grok it. I'd be a
> happier fella if you didn't use it.
>
Is there a canonical way to specify both the location and the branch
in one shot, then? I must admit that this is the way I've always seen
it specified, so I assumed that this is the way it was done
"canonically". If it isn't, please forgive my ignorance.
rlc
--
Ronald Landheer-Cieslak
Software Architect
http://www.landheer-cieslak.com/
New White Paper: "Three Good Reasons to Plan Ahead"
^ permalink raw reply
* Re: [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Johannes Schindelin @ 2007-11-03 13:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20071103131806.GA25109@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 559 bytes --]
Hi,
On Sat, 3 Nov 2007, Nguyễn Thái Ngọc Duy wrote:
> When both GIT_DIR and GIT_WORK_TREE are set, and
> setup_git_directory_gently() changes the current working
> directory accordingly, it should also set inside_work_tree = 1.
>
> Without this, work_tree handling code in setup_git_directory()
> will be activated. If you stay in root work tree (no prefix),
> it does not harm. It does if you work from a subdirectory though.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Updated commit message accordingly
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Reuse previous annotation when overwriting a tag
From: Johannes Schindelin @ 2007-11-03 13:22 UTC (permalink / raw)
To: Mike Hommey; +Cc: git, Junio C Hamano
In-Reply-To: <20071103131030.GA18670@glandium.org>
Hi,
On Sat, 3 Nov 2007, Mike Hommey wrote:
> On Sat, Nov 03, 2007 at 12:36:36PM +0000, Johannes Schindelin wrote:
>
> > On Sat, 3 Nov 2007, Mike Hommey wrote:
> >
> > > On Sat, Nov 03, 2007 at 11:54:38AM +0000, Johannes Schindelin wrote:
> > > > Why not teach write_annotations() (or write_tag_body() like I
> > > > would prefer it to be called) to grok a null_sha1? It's not like
> > > > we care for performance here, but rather for readability and ease
> > > > of use.
> > >
> > > By the way, I think it would be much better if this function was
> > > made more generic and would not write, but return an strbuf
> > > containing the object body. It could also be used by e.g. git-commit
> > > --amend.
> > >
> > > What would be the best suited place for such a function ?
> >
> > editor.c, I'd say.
>
> On which topic is this ?
On none so far. But the plan was to move some functions used by both
builtin-tag and builtin-commit (such as launch_editor()) into the files
editor.[ch].
Unfortunately, that plan has not been executed by anybody. Yet.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add missing inside_work_tree setting in setup_git_directory_gently
From: Nguyễn Thái Ngọc Duy @ 2007-11-03 13:18 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <20071103100323.GA25305@laptop>
When both GIT_DIR and GIT_WORK_TREE are set, and
setup_git_directory_gently() changes the current working
directory accordingly, it should also set inside_work_tree = 1.
Without this, work_tree handling code in setup_git_directory()
will be activated. If you stay in root work tree (no prefix),
it does not harm. It does if you work from a subdirectory though.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Updated commit message accordingly
setup.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/setup.c b/setup.c
index 145eca5..6f8f769 100644
--- a/setup.c
+++ b/setup.c
@@ -240,6 +240,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (chdir(work_tree_env) < 0)
die ("Could not chdir to %s", work_tree_env);
strcat(buffer, "/");
+ inside_work_tree = 1;
return retval;
}
if (nongit_ok) {
--
1.5.3.rc4.3.gab089
^ permalink raw reply related
* Re: StGIT fails to clean patch series, and to go to a patch
From: Jakub Narebski @ 2007-11-03 13:17 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0711030332s49877dcep46460121fb6ec712@mail.gmail.com>
Catalin Marinas wrote:
> On 03/11/2007, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> I have patch series with empty patch in the middle of the stack.
>> After trying to stg-clean (and failing) stack looks like below:
>
> Does 'stg delete gitweb-Update-INSTALL-file' work?
>
>> 1164:[gitweb/web!git]$ stg goto gitweb-Use-config-more
>> Checking for changes in the working directory ... done
>> Traceback (most recent call last):
>
> Does a simple 'stg push' work? I suspect there is something wrong with
> the gitweb-Update-INSTALL-file patch but not sure why or how it could
> get to this inconsistent state?
>
> It's worth checking the values of 'stg id
> gitweb-Update-INSTALL-file//top' and //bottom and whether they are
> commit ids or something else.
1168:[gitweb/web!git]$ stg id gitweb-Update-INSTALL-file
None
1169:[gitweb/web!git]$ stg id gitweb-Update-INSTALL-file//top
None
1170:[gitweb/web!git]$ stg id gitweb-Update-INSTALL-file//bottom
None
1171:[gitweb/web!git]$ stg delete gitweb-Update-INSTALL-file
Traceback (most recent call last):
File "/usr/bin/stg", line 43, in ?
main()
File "/usr/lib/python2.4/site-packages/stgit/main.py", line 284, in main
command.func(parser, options, args)
File "/usr/lib/python2.4/site-packages/stgit/commands/delete.py", line 76, in func
crt_series.delete_patch(patch)
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 919, in delete_patch
patch.delete()
File "/usr/lib/python2.4/site-packages/stgit/stack.py", line 160, in delete
for f in os.listdir(self._dir()):
OSError: [Errno 2] No such file or directory: '.git/patches/gitweb/web/patches/gitweb-Update-INSTALL-file'
I wonder how that happened... I'm just interested in recovering
the unapplied commits. There is always reflog, but StGIT does not
create reflog message as it should.
Hmmm... removing gitweb-Update-INSTALL-file line from 'unapplied' file
worked; nice.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git-reset: do not be confused if there is nothing to reset
From: Johannes Schindelin @ 2007-11-03 13:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, jasampler, gitster
In-Reply-To: <20071103111743.GA29358@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3065 bytes --]
The purpose of the function update_index_from_diff() (which is the
callback function we give do_diff_cache()) is to update those index
entries which differ from the given commit.
Since do_diff_cache() plays games with the in-memory index, this function
discarded the cache and reread it.
Then, back in the function read_from_tree() we wrote the index.
Of course, this broke down when there were no changes and
update_index_from_diff() was not called, and therefore the mangled index
was not discarded.
The solution is to move the index writing into the function
update_index_from_diff().
Noticed by Björn Steinbrink.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-reset.c | 24 ++++++++++++++++++------
t/t7102-reset.sh | 7 +++++++
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/builtin-reset.c b/builtin-reset.c
index e1dc31e..5467e36 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -113,10 +113,17 @@ static int update_index_refresh(void)
return run_command_v_opt(argv_update_index, RUN_GIT_CMD);
}
+struct update_cb_data {
+ int index_fd;
+ struct lock_file *lock;
+ int exit_code;
+};
+
static void update_index_from_diff(struct diff_queue_struct *q,
struct diff_options *opt, void *data)
{
int i;
+ struct update_cb_data *cb = data;
/* do_diff_cache() mangled the index */
discard_cache();
@@ -133,29 +140,34 @@ static void update_index_from_diff(struct diff_queue_struct *q,
} else
remove_file_from_cache(one->path);
}
+
+ cb->exit_code = write_cache(cb->index_fd, active_cache, active_nr) ||
+ close(cb->index_fd) ||
+ commit_locked_index(cb->lock);
}
static int read_from_tree(const char *prefix, const char **argv,
unsigned char *tree_sha1)
{
- struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
- int index_fd;
struct diff_options opt;
+ struct update_cb_data cb;
memset(&opt, 0, sizeof(opt));
diff_tree_setup_paths(get_pathspec(prefix, (const char **)argv), &opt);
opt.output_format = DIFF_FORMAT_CALLBACK;
opt.format_callback = update_index_from_diff;
+ opt.format_callback_data = &cb;
- index_fd = hold_locked_index(lock, 1);
+ cb.lock = xcalloc(1, sizeof(struct lock_file));
+ cb.index_fd = hold_locked_index(cb.lock, 1);
+ cb.exit_code = 0;
read_cache();
if (do_diff_cache(tree_sha1, &opt))
return 1;
diffcore_std(&opt);
diff_flush(&opt);
- return write_cache(index_fd, active_cache, active_nr) ||
- close(index_fd) ||
- commit_locked_index(lock);
+
+ return cb.exit_code;
}
static void prepend_reflog_action(const char *action, char *buf, size_t size)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index f64b1cb..cea9afb 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -402,4 +402,11 @@ test_expect_success 'test resetting the index at give paths' '
'
+test_expect_success 'resetting an unmodified path is a no-op' '
+ git reset --hard &&
+ git reset -- file1 &&
+ git diff-files --exit-code &&
+ git diff-index --cached --exit-code HEAD
+'
+
test_done
--
1.5.3.5.1505.gd778c
^ permalink raw reply related
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