* Re: Wrong damage counting in diffcore_count_changes?
From: Linus Torvalds @ 2009-12-04 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0912041419540.24579@localhost.localdomain>
On Fri, 4 Dec 2009, Linus Torvalds wrote:
>
> It also looks a bit like diffcore-break actually worked around this whole
> thing, and does
>
> /* sanity */
> if (src->size < src_copied)
> src_copied = src->size;
> if (dst->size < literal_added + src_copied) {
> if (src_copied < dst->size)
> literal_added = dst->size - src_copied;
> else
> literal_added = 0;
> }
> src_removed = src->size - src_copied;
>
> so this _may_ change what -B does, but I get the feeling that it should
> improve that too. I'm running a before-and-after "git log -M -B --summary"
> on the kernel now, but it's a pretty expensive operation, so it hasn't
> finished yet.
Ok, somewhat confirmed. Before-and-after changes:
- commit 2def7b8bcd4c49ca71a950611c9d456fd35282d2
- 2 files changed, 187 insertions(+), 218 deletions(-)
- delete mode 100644 drivers/staging/hv/include/ChannelMessages.h
+ 1 files changed, 109 insertions(+), 4 deletions(-)
+ rename drivers/staging/hv/{include/ChannelMessages.h => ChannelMgmt.h} (70%)
ie it _used_ to get broken up, now it shows up as a rename, presumably
due to better scoring.
- commit 64a1403d797d38c0bd18ba43bda5653c012c0d58. Similar.
- commit 3ce0a23d2d253185df24e22e3d5f89800bb3dd1c
- 34 files changed, 8316 insertions(+), 633 deletions(-)
- create mode 100644 drivers/gpu/drm/radeon/avivod.h
+ 34 files changed, 8287 insertions(+), 643 deletions(-)
+ copy drivers/gpu/drm/radeon/{radeon_share.h => avivod.h} (50%)
that looks like a smaller diff, judging by the line counts
- commit 9f77da9f40045253e91f55c12d4481254b513d2d
- 4 files changed, 358 insertions(+), 328 deletions(-)
+ 4 files changed, 132 insertions(+), 420 deletions(-)
rewrite include/linux/rcutree.h (73%)
+ rename {include/linux => kernel}/rcutree.h (80%)
- commit d15dd3e5d74186a3b0a4db271b440bbdc0f6da36
- 6 files changed, 75 insertions(+), 41 deletions(-)
- create mode 100644 drivers/net/wireless/ath/ath.h
+ 6 files changed, 59 insertions(+), 47 deletions(-)
+ copy drivers/net/wireless/ath/{main.c => ath.h} (73%)
- commit cf4f1e76c49dacfde0680b170b9a9b6a42f296bb
- 2 files changed, 716 insertions(+), 714 deletions(-)
+ 2 files changed, 371 insertions(+), 1034 deletions(-)
rewrite drivers/usb/host/r8a66597.h (62%)
+ rename {drivers/usb/host => include/linux/usb}/r8a66597.h (65%)
- commit d69864158e24f323e818403c6b89ad4871aea6f6
- 4 files changed, 172 insertions(+), 238 deletions(-)
+ 3 files changed, 90 insertions(+), 106 deletions(-)
+ rename arch/sparc/include/asm/{dma-mapping_64.h => dma-mapping.h} (71%)
delete mode 100644 arch/sparc/include/asm/dma-mapping_32.h
- delete mode 100644 arch/sparc/include/asm/dma-mapping_64.h
etc. From what I can see, it looks like in general it picked better things
with the new diffcore_count_changes() implementation, Looking at just the
"files changed" summaries, it tends to look like this:
- 21 files changed, 5659 insertions(+), 3227 deletions(-)
+ 19 files changed, 5723 insertions(+), 2285 deletions(-)
- 3 files changed, 645 insertions(+), 654 deletions(-)
+ 3 files changed, 387 insertions(+), 820 deletions(-)
- 11 files changed, 187 insertions(+), 177 deletions(-)
+ 10 files changed, 166 insertions(+), 109 deletions(-)
- 100 files changed, 1114 insertions(+), 3388 deletions(-)
+ 99 files changed, 1102 insertions(+), 3337 deletions(-)
- 2 files changed, 127 insertions(+), 106 deletions(-)
+ 2 files changed, 113 insertions(+), 92 deletions(-)
- 7 files changed, 128 insertions(+), 59 deletions(-)
+ 7 fileas changed, 87 insertions(+), 69 deletions(-)
- 154 files changed, 3641 insertions(+), 4232 deletions(-)
+ 154 files changed, 3635 insertions(+), 4233 deletions(-)
- 24 files changed, 162 insertions(+), 226 deletions(-)
+ 23 files changed, 61 insertions(+), 77 deletions(-)
- 4 files changed, 1995 insertions(+), 2114 deletions(-)
+ 3 files changed, 796 insertions(+), 814 deletions(-)
- 3 files changed, 1104 insertions(+), 1114 deletions(-)
+ 3 files changed, 886 insertions(+), 1038 deletions(-)
- 46 files changed, 17743 insertions(+), 5986 deletions(-)
+ 46 files changed, 16239 insertions(+), 6636 deletions(-)
- 9 files changed, 295 insertions(+), 284 deletions(-)
+ 9 files changed, 203 insertions(+), 291 deletions(-)
ie I can see several cases where the new break choice resulted in fewer
files changed and/or fewer over-all lines changed (due to better rename
choices), and I haven't seen any going the other way. There's probably
some, but it does seem that in general the patch results in better picks
(when it makes any difference in the first place - there seems to be only
71 commits in the kernel git tree that are affected at all)
Linus
^ permalink raw reply
* [PATCH] Add commit.infodisplay option to give message editor empty file
From: James P. Howard, II @ 2009-12-04 23:04 UTC (permalink / raw)
To: git; +Cc: James P. Howard, II
This patch creates commit.infodisplay which causes git commit to
display the status information on the standard output rather
than in the temporary file for the commit message. By doing
this, it becomes feasible to set core.editor for commit messages
to be a line editor, e.g. ex or ed.
Signed-off-by: James P. Howard, II <jh@jameshoward.us>
---
Documentation/config.txt | 5 +++++
builtin-commit.c | 31 ++++++++++++++++++-------------
cache.h | 1 +
environment.c | 3 +++
4 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a1e36d7..56b3238 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -705,6 +705,11 @@ color.ui::
terminal. When more specific variables of color.* are set, they always
take precedence over this setting. Defaults to false.
+commit.infodisplay::
+ When true and a commit message is not specified on the command line,
+ the status information is not placed in the message template but is
+ printed to the standard output.
+
commit.template::
Specify a file to use as the template for new commit messages.
"{tilde}/" is expanded to the value of `$HOME` and "{tilde}user/" to the
diff --git a/builtin-commit.c b/builtin-commit.c
index e93a647..e4db374 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -463,7 +463,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
int commitable, saved_color_setting;
struct strbuf sb = STRBUF_INIT;
char *buffer;
- FILE *fp;
+ FILE *fp, *infofp;
const char *hook_arg1 = NULL;
const char *hook_arg2 = NULL;
int ident_shown = 0;
@@ -540,7 +540,12 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
if (fwrite(sb.buf, 1, sb.len, fp) < sb.len)
die_errno("could not write commit template");
-
+ if (info_display)
+ infofp = stdout;
+ else {
+ infofp = fp;
+ fprintf(infofp, "\n");
+ }
strbuf_release(&sb);
determine_author_info();
@@ -552,7 +557,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
const char *committer_ident;
if (in_merge)
- fprintf(fp,
+ fprintf(infofp,
"#\n"
"# It looks like you may be committing a MERGE.\n"
"# If this is not correct, please remove the file\n"
@@ -561,28 +566,27 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
"#\n",
git_path("MERGE_HEAD"));
- fprintf(fp,
- "\n"
+ fprintf(infofp,
"# Please enter the commit message for your changes.");
if (cleanup_mode == CLEANUP_ALL)
- fprintf(fp,
+ fprintf(infofp,
" Lines starting\n"
"# with '#' will be ignored, and an empty"
" message aborts the commit.\n");
else /* CLEANUP_SPACE, that is. */
- fprintf(fp,
+ fprintf(infofp,
" Lines starting\n"
"# with '#' will be kept; you may remove them"
" yourself if you want to.\n"
"# An empty message aborts the commit.\n");
if (only_include_assumed)
- fprintf(fp, "# %s\n", only_include_assumed);
+ fprintf(infofp, "# %s\n", only_include_assumed);
author_ident = xstrdup(fmt_name(author_name, author_email));
committer_ident = fmt_name(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"));
if (strcmp(author_ident, committer_ident))
- fprintf(fp,
+ fprintf(infofp,
"%s"
"# Author: %s\n",
ident_shown++ ? "" : "#\n",
@@ -590,18 +594,18 @@ static int prepare_to_commit(const char *index_file, const char *prefix,
free(author_ident);
if (!user_ident_explicitly_given)
- fprintf(fp,
+ fprintf(infofp,
"%s"
"# Committer: %s\n",
ident_shown++ ? "" : "#\n",
committer_ident);
if (ident_shown)
- fprintf(fp, "#\n");
+ fprintf(infofp, "#\n");
saved_color_setting = s->use_color;
s->use_color = 0;
- commitable = run_status(fp, index_file, prefix, 1, s);
+ commitable = run_status(infofp, index_file, prefix, 1, s);
s->use_color = saved_color_setting;
} else {
unsigned char sha1[20];
@@ -1006,7 +1010,8 @@ static int git_commit_config(const char *k, const char *v, void *cb)
if (!strcmp(k, "commit.template"))
return git_config_pathname(&template_file, k, v);
-
+ if (!strcmp(k, "commit.infodisplay"))
+ info_display = git_config_bool(k, v);
return git_status_config(k, v, s);
}
diff --git a/cache.h b/cache.h
index bf468e5..2b36fb3 100644
--- a/cache.h
+++ b/cache.h
@@ -529,6 +529,7 @@ extern int auto_crlf;
extern int read_replace_refs;
extern int fsync_object_files;
extern int core_preload_index;
+extern int info_display;
enum safe_crlf {
SAFE_CRLF_FALSE = 0,
diff --git a/environment.c b/environment.c
index 5171d9f..ac7cfed 100644
--- a/environment.c
+++ b/environment.c
@@ -55,6 +55,9 @@ int grafts_replace_parents = 1;
/* Parallel index stat data preload? */
int core_preload_index = 0;
+/* Controls whether commit information is appended to message text or displayed */
+int info_display = 0;
+
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
static char *work_tree;
--
1.6.5.3
^ permalink raw reply related
* [PATCH] bash: update 'git commit' completion
From: SZEDER Gábor @ 2009-12-05 0:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, SZEDER Gábor
I just wanted to add the recently learnt '--reset-author' option, but
then noticed that there are many more options missing. This patch
adds support for all of 'git commit's options, except '--allow-empty',
because it is primarily there for foreign scm interfaces.
Furthermore, this patch also adds support for completing the arguments
of those options that take a non-filename argument: valid modes are
offered for '--cleanup' and '--untracked-files', while refs for
'--reuse-message' and '--reedit-message', because these two take a
commit as argument.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 11bf17a..7c18b0c 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -896,11 +896,31 @@ _git_commit ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
+ --cleanup=*)
+ __gitcomp "default strip verbatim whitespace
+ " "" "${cur##--cleanup=}"
+ return
+ ;;
+ --reuse-message=*)
+ __gitcomp "$(__git_refs)" "" "${cur##--reuse-message=}"
+ return
+ ;;
+ --reedit-message=*)
+ __gitcomp "$(__git_refs)" "" "${cur##--reedit-message=}"
+ return
+ ;;
+ --untracked-files=*)
+ __gitcomp "all no normal" "" "${cur##--untracked-files=}"
+ return
+ ;;
--*)
__gitcomp "
--all --author= --signoff --verify --no-verify
--edit --amend --include --only --interactive
- --dry-run
+ --dry-run --reuse-message= --reedit-message=
+ --reset-author --file= --message= --template=
+ --cleanup= --untracked-files --untracked-files=
+ --verbose --quiet
"
return
esac
--
1.6.6.rc1.54.g791207
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.6.5.4
From: Junio C Hamano @ 2009-12-05 7:28 UTC (permalink / raw)
To: Todd Zullinger; +Cc: Andreas Schwab, Michael J Gruber, git
In-Reply-To: <20091204193355.GC4629@inocybe.localdomain>
Todd Zullinger <tmz@pobox.com> writes:
> This does set MAN_BASE_URL unconditionally, pointing to kernel.org.
> That way anyone building with recent DocBook and taking no new action
> will have something useful in the man page links.
I'd rather see it set to an empty string by default which will essentially
keep the old output. An alternative would be to default to the location
the install-html target installs, i.e. $HOME/share/doc/git-doc pointed by
$(htmldir) in Documentation/Makefile.
Distro people should be strongly encouraged to repoint the variable to
somewhere local that does not require connections to k.org or anywhere
outside the end-user's installation, but that is a slightly separate and
different topic.
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Junio C Hamano @ 2009-12-05 7:30 UTC (permalink / raw)
To: James P. Howard, II; +Cc: git
In-Reply-To: <1259967879-65517-1-git-send-email-jh@jameshoward.us>
"James P. Howard, II" <jh@jameshoward.us> writes:
> This patch creates commit.infodisplay which causes git commit to
> display the status information on the standard output rather
> than in the temporary file for the commit message. By doing
> this, it becomes feasible to set core.editor for commit messages
> to be a line editor, e.g. ex or ed.
Two points and a half:
- Why does info_display need to be visible to everybody else by being in
cache.h and environment.c? Shouldn't its scope be similar to that of
template_file, that is static to builtin-commit.c?
- A configuration variable that does not allow the users to override from
the command line is a no-no. We usually do command line option first
and then (or at the same time) configuration variable as a typesaver.
- While the amount of change necessary for this change doesn't look too
bad, is it really worth it? What is wrong with "1,$p" while using ed
as your editor?
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: Dilip M @ 2009-12-05 7:37 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4B161B15.2020106@syntevo.com>
2009/12/2 Marc Strapetz <marc.strapetz@syntevo.com>:
> We are proud to announce the general availability of our Git client
> SmartGit[1]:
>
> http://www.syntevo.com/smartgit/index.html
>
> Thank you, Git community, for the great DVCS you are building and the
> feed-back to SmartGit!
Man! this is what missing for GIT! Way to go!
--
Dilip
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Junio C Hamano @ 2009-12-05 7:39 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, Junio C Hamano, Matthieu Moy,
Michael J Gruber, Michael Haggerty, git
In-Reply-To: <20091205062708.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> I think Junio is referring to this thread:
>
> http://thread.gmane.org/gmane.comp.version-control.git/127923/focus=121874
Yes, that was the one I had in mind, and it is a shame that we somehow
ended up not taking it, perhaps in an improved form, back then. Even
today alone, I missed the "mark for later fixing/squashing and then rebase
at the end" feature twice at dayjob.
> I too think Michael's "fix" is a good feature, and in the
> workflow by Shawn, he knows he is fixing up an earlier
> commit, and he knows he doesn't want to add anything to
> the message by the fix-up commit when he makes that commit
> (how else would he have messages like "a", "s", or "foo").
There is a slight distinction between "Shawn's fix-up commits have garbage
message and he does not want any part of them in the final commit message"
and "Shawn is happy with the message of the original commit whose tree
these fix-up commits are meant to correct." He may still not be entirely
happy with the original message. Wanting to edit the commit log message,
and not wanting to use the messages from follow-up commits, are two
different things.
I would agree that it is a good idea for "rebase -i" with only "fix" and
not "squash" to skip the editing of the final message. You manually move,
or tell your "rebase --autosquash" option to automatically move, the
follow-up commits next to the ones they are meant to correct while editing
the rebase-i insn, and you change their "pick" to "fix" (or "fixup" as
Dscho and others suggested in the earlier round you quoted) only when you
know you want to keep the message of the original commit. Otherwise you
can change them to "squash" not to "fix", and you can edit the final log
message that way.
If Michael rolls his second round with your "--autosquash", or you do so
yourself on top of his patch, I think it _might_ be safer to mark the ones
automatically moved as "squash", and not as "fix", and have the users
explicitly change the "squash" they want to "fix" themselves.
Alternatively, you can also use two magic tokens (i.e. instead of one
"fixup!", allow people to use "squash!" and "fixup!") and change the
action chosen for the moved commits to "squash" and "fixup" respectively.
> I don't think your objection should block *others* (like
> Shawn and Junio) who can decide when they make commits
> from using the feature from my old patch to make it even
> easier to clean up their topics. If *you* can't decide if
> you want to amend or not when you make a fix-up commit, you
> can leave your fix-up commits unmarked, run interactive
> rebase without the --autosquash option, and use Michael's
> 'fix' manually. People who can sometimes but not always
> decide when they make commits can do the same when they
> can't.
>
> Isn't it what Junio suggested by his "on top of this feature",
> and wouldn't that make everybody happy?
The answer to the first question is "yes"---I did't understand why Dscho
objected to a feature he can choose not to use if he doesn't want to, and
I still don't (unless I was misreading your earlier patch back then and it
somehow forced all rebase-i users to decide upfront at the commit time,
but I highly doubt it).
I don't know about the second one but I am guessing it would also be
"yes".
^ permalink raw reply
* Re: git gsoc money
From: Christian Couder @ 2009-12-05 10:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, git, Junio C Hamano
In-Reply-To: <20091203153935.GB23281@spearce.org>
On jeudi 03 décembre 2009, Shawn O. Pearce wrote:
> Jeff King <peff@peff.net> wrote:
> > However, we still have about $500 USD remaining.
> >
> > Some possibilities are:
> >
> > 1. Become an affiliated project of an organization like The Software
> > Freedom Conservancy or Software in the Public Interest.
>
> Try to join the Software Freedom Conservancy and retain the funds
> for Git's use? Maybe you can slide in before the Dec 31st deadline.
Yeah, that would be a great. Thanks for doing that!
> I know a few users of Git have said they can't contribute code, but
> they would like to throw $25-50 towards a developer to say thank you.
> This would give them an easier vehicle to do that.
>
> I'm not saying we should actively seek donations, we have virtually
> no expenses and don't need them.
>
> But we do sometimes have these GitTogether things, or one of us is
> going to a Linux Plumbers conference or something to give a talk
> promoting Git. Having $500 from a handful of donations available
> to defray Git related travel costs for some of our more active
> developers is more useful than having a user send something from
> an Amazon wish list [1][2].
I benefited from the GSoC fund last year and much appreciated having my
travel expenses to go to the GitTogether reimbursed.
But I think it is ok too for developers to have an amazon wish list, so
donors can choose. And by the way Junio has one:
http://www.amazon.com/gp/registry/wishlist/1513KNZE30W63
so everyone is welcome to buy him something!
> At worst, if we collect a bunch of money and realize "Oh, wait,
> we have like $8000 USD and we haven't spent any of it in the past
> 5 years!" we can have the SFC do a big donation to FSF or something
> and say "thanks for GCC!".
>
> If joining the SFC proves too difficult, just donate the $500 to
> the FSF. That's what we did the first year we were in GSoC.
Another way we could perhaps use the funds (especially if we have to do that
before the end of the year) could be to defray membership costs if some
developers want to join (or are already member of) some related
organisation like the Linux Foundation:
http://www.linuxfoundation.org/about/join/individual/
or the FSF:
http://www.fsf.org/associate/
Best regards,
Christian.
^ permalink raw reply
* Re: [RFC PATCH v2 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Johannes Sixt @ 2009-12-05 11:57 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Marius Storm-Olsen, Johannes Schindelin, GIT Mailing-list
In-Reply-To: <4B1997A0.9000004@ramsay1.demon.co.uk>
[Removed Junio from Cc because IIUC, he prefers to be left out of the loop in
Windows related matters until they have settled.]
On Samstag, 5. Dezember 2009, Ramsay Jones wrote:
> The patch is still marked RFC because:
> - I'm still not sure if the flexibility to support both 32- and 64-bit
> time_t is required.
> - should -D_USE_32BIT_TIME_T be added to the Makefile?
If *not* using -D_USE_32BIT_TIME_T produces a build or code base that is in
some way superior, why should we require it? For example, its absence could
help a 64bit build.
-- Hannes
^ permalink raw reply
* Re: [RFC PATCH v2 4/8] Support remote helpers implementing smart transports
From: Ilari Liusvaara @ 2009-12-05 13:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091204183713.GE1483@spearce.org>
On Fri, Dec 04, 2009 at 10:37:13AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>
> Why not 'fallback' to remain consistent with this protocol and many
> others in git where we stick to lowercase ASCII?
Changed.
> Why is the initial advertisement special? If the helper always
> flushes both sides, it shouldn't ever deadlock the protocol. Also,
> note that a helper should be able to implement a tiny delay like
> Nagle's algorithm does in TCP. It just can't sit on a byte forever.
That's just extremely badly worded. The point is that only place where
buffering has even seemed useful is initial adverts. Those can
really trigger large numbers of small transfers if unbuffered.
Granted, small delay should work quite well.
I'll reword it.
> This hunk appears to be unrelated. And actually, if transport has
> no remote, shouldn't the arg here be NULL so the helper gets only
> 1 argument and not 2 arguments?
Actually, it can't be NULL (the code would have already die()'d in
that case). Fixed.
> I think exec winds up defaulting to name if --upload-pack was not
> used on the command line, and remote.$name.uploadpack was not set.
> See transport.c where you initialize the git options struct, these
> fields were defaulted in.
Actually, there was bug in initializing git options struct. It was
properly initialized if one used foo://, but not with foo::bar://.
Tripping it caused NULL exec to be passed if you didn't override.
I fixed that bug and now the servpath code has just strcmp.
> My point is, we shouldn't send option servpath to the helper if
> name is equal to servpath, because the helper might not support
> servpath and the option command will issue a warning above for no
> reason at all.
This is exactly what happens (and yes, I tested). No --receive-pack
doesn't trip warning, with --receive-pack it does.
-Ilari
^ permalink raw reply
* Re: [RFC PATCH v2 1/8] Pass unknown protocols to external protocol handlers
From: Ilari Liusvaara @ 2009-12-05 13:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091204175545.GC1483@spearce.org>
On Fri, Dec 04, 2009 at 09:55:45AM -0800, Shawn O. Pearce wrote:
<fd dupping code>
> This is an entirely unrelated change. Please split it into its
> own commit so its easier to review, test, blah blah blah.
Moved to 3/8, since that's where it actually will be needed (latter
rearrangement renumbered that patch to 5/8).
-Ilari
^ permalink raw reply
* Re: [RFC PATCH v2 3/8] Support taking over transports
From: Ilari Liusvaara @ 2009-12-05 13:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091204182753.GD1483@spearce.org>
On Fri, Dec 04, 2009 at 10:27:53AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> > Add support for taking over transports that turn out to be smart.
>
> Why can't you expose git_take_over_transport as a public function
> and then the transport-helper.c code can instead do:
>
> ... setup connect with helper ...
> transport_takeover(transport, child);
> return transport->fetch(....);
>
> Would this make the code simpler?
The code complexity difference is not big. The magic return was for
historic reasons that no longer apply (and didn't get fixed when
corresponding upstream changes happned).
Namely, the push/push_refs impedance mismatch. Helpers used push,
smart transports used push_refs. But now that both use push_refs,
the handler can be invoked directly from push_refs of helper.
Fixed.
-Ilari
^ permalink raw reply
* Re: rev-parse --show-cdup in .git
From: Michael J Gruber @ 2009-12-05 13:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vhbs6skzi.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 04.12.2009 18:32:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> I'm sure this was discussed somewhere, but I can't find it:
>>
>> When called from within .git, git rev-parse --show-cdup returns nothing
>> rather than "..", not even an error code. Is this intended?
>
> I do not think --show-cdup should be linked to --is-inside-work-tree in
> any way, if that is what you are getting at by mentioning "error code".
It's just difficult to tell from the output whether you are at the
toplevel (empty relative path) or you're within .git or somewhere else.
>> This is all the more disturbing since the cwd of hooks seems to be
>> GIT_DIR. Is that something one can rely upon? In that case one can
>> simply use ".." for cdup.
>
> I think you will see something that is different from and is more sensible
> than ".." when you use GIT_WORK_TREE environment variable (or its
> corresponding configuration variable).
All that I want is a reliable method for a hook to cd to the toplevel of
the worktree of a non-bare repositity. cd_to_toplevel (from
git-sh-setup) does not work. I don't think I should have to set any
worktree config in a non-bare repository with standard layout, should I?
Michael
^ permalink raw reply
* Re: [PATCH RESEND] git gui: make current branch default in "remote delete branch" merge check
From: Jens Lehmann @ 2009-12-05 13:19 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Shawn O. Pearce, git, Junio C Hamano
In-Reply-To: <20091204212648.GA3979@book.hvoigt.net>
Heiko Voigt schrieb:
> We already do the same when locally deleting a branch.
+1
This is very useful in a workflow where the reviewer deletes the remote
feature branch right after merging and pushing it.
Jens
^ permalink raw reply
* Re: [RFC PATCH v2 2/2] MSVC: Fix an "incompatible pointer types" compiler warning
From: Johannes Schindelin @ 2009-12-05 14:57 UTC (permalink / raw)
To: Ramsay Jones
Cc: Junio C Hamano, Marius Storm-Olsen, Johannes Sixt,
GIT Mailing-list
In-Reply-To: <4B1997A0.9000004@ramsay1.demon.co.uk>
Hi,
On Fri, 4 Dec 2009, Ramsay Jones wrote:
> Changes from v1:
> - moved the new declarations to msvc.h rather than clutter mingw.h
> with msvc related code.
Thanks,
Dscho
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: Johannes Schindelin @ 2009-12-05 15:01 UTC (permalink / raw)
To: Dilip M; +Cc: Marc Strapetz, git
In-Reply-To: <c94f8e120912042337n43d5bcd0qc61a2820a8009dc4@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 490 bytes --]
Hi,
On Sat, 5 Dec 2009, Dilip M wrote:
> 2009/12/2 Marc Strapetz <marc.strapetz@syntevo.com>:
>
> > We are proud to announce the general availability of our Git client
> > SmartGit[1]:
> >
> > http://www.syntevo.com/smartgit/index.html
> >
> > Thank you, Git community, for the great DVCS you are building and the
> > feed-back to SmartGit!
>
> Man! this is what missing for GIT! Way to go!
As for "missing", do you refer to "paid service", or "yet another GUI"?
Just curious,
Dscho
^ permalink raw reply
* [PATCH 0/2] Refactor status producers and make status -s use color
From: Michael J Gruber @ 2009-12-05 15:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This is is the refactoring as suggested by Junio, and rebased on top is
the patch which makes status -s obey color.status. I also adjusted the
latter to not color the space separating the (colored) status letters
from the (uncolored) file name.
This mini series is directly on top of 91691ec (Merge branch
'jk/1.7.0-status' into next, 2009-11-27).
Michael J Gruber (2):
builtin-commit: refactor short-status code into wt-status.c
status -s: obey color.status
builtin-commit.c | 105 ++++-------------------------------------------------
wt-status.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++
wt-status.h | 2 +
3 files changed, 106 insertions(+), 97 deletions(-)
^ permalink raw reply
* [PATCH 1/2] builtin-commit: refactor short-status code into wt-status.c
From: Michael J Gruber @ 2009-12-05 15:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1260025135.git.git@drmicha.warpmail.net>
Currently, builtin-commit.c contains most code producing the
short-status output, whereas wt-status.c contains most of the code for
the long format.
Refactor so that most of the long and short format producing code
resides in wt-status.c and is named analogously.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
builtin-commit.c | 101 ++---------------------------------------------------
wt-status.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++
wt-status.h | 2 +
3 files changed, 95 insertions(+), 97 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index c103beb..548bbf5 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -79,8 +79,6 @@ static enum {
STATUS_FORMAT_PORCELAIN,
} status_format = STATUS_FORMAT_LONG;
-static void short_print(struct wt_status *s, int null_termination);
-
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt->value;
@@ -387,10 +385,10 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
switch (status_format) {
case STATUS_FORMAT_SHORT:
- short_print(s, null_termination);
+ wt_shortstatus_print(s, null_termination);
break;
case STATUS_FORMAT_PORCELAIN:
- short_print(s, null_termination);
+ wt_shortstatus_print(s, null_termination);
break;
case STATUS_FORMAT_LONG:
wt_status_print(s);
@@ -982,97 +980,6 @@ static int git_status_config(const char *k, const char *v, void *cb)
return git_diff_ui_config(k, v, NULL);
}
-#define quote_path quote_path_relative
-
-static void short_unmerged(int null_termination, struct string_list_item *it,
- struct wt_status *s)
-{
- struct wt_status_change_data *d = it->util;
- const char *how = "??";
-
- switch (d->stagemask) {
- case 1: how = "DD"; break; /* both deleted */
- case 2: how = "AU"; break; /* added by us */
- case 3: how = "UD"; break; /* deleted by them */
- case 4: how = "UA"; break; /* added by them */
- case 5: how = "DU"; break; /* deleted by us */
- case 6: how = "AA"; break; /* both added */
- case 7: how = "UU"; break; /* both modified */
- }
- printf("%s ", how);
- if (null_termination) {
- fprintf(stdout, "%s%c", it->string, 0);
- } else {
- struct strbuf onebuf = STRBUF_INIT;
- const char *one;
- one = quote_path(it->string, -1, &onebuf, s->prefix);
- printf("%s\n", one);
- strbuf_release(&onebuf);
- }
-}
-
-static void short_status(int null_termination, struct string_list_item *it,
- struct wt_status *s)
-{
- struct wt_status_change_data *d = it->util;
-
- printf("%c%c ",
- !d->index_status ? ' ' : d->index_status,
- !d->worktree_status ? ' ' : d->worktree_status);
- if (null_termination) {
- fprintf(stdout, "%s%c", it->string, 0);
- if (d->head_path)
- fprintf(stdout, "%s%c", d->head_path, 0);
- } else {
- struct strbuf onebuf = STRBUF_INIT;
- const char *one;
- if (d->head_path) {
- one = quote_path(d->head_path, -1, &onebuf, s->prefix);
- printf("%s -> ", one);
- strbuf_release(&onebuf);
- }
- one = quote_path(it->string, -1, &onebuf, s->prefix);
- printf("%s\n", one);
- strbuf_release(&onebuf);
- }
-}
-
-static void short_untracked(int null_termination, struct string_list_item *it,
- struct wt_status *s)
-{
- if (null_termination) {
- fprintf(stdout, "?? %s%c", it->string, 0);
- } else {
- struct strbuf onebuf = STRBUF_INIT;
- const char *one;
- one = quote_path(it->string, -1, &onebuf, s->prefix);
- printf("?? %s\n", one);
- strbuf_release(&onebuf);
- }
-}
-
-static void short_print(struct wt_status *s, int null_termination)
-{
- int i;
- for (i = 0; i < s->change.nr; i++) {
- struct wt_status_change_data *d;
- struct string_list_item *it;
-
- it = &(s->change.items[i]);
- d = it->util;
- if (d->stagemask)
- short_unmerged(null_termination, it, s);
- else
- short_status(null_termination, it, s);
- }
- for (i = 0; i < s->untracked.nr; i++) {
- struct string_list_item *it;
-
- it = &(s->untracked.items[i]);
- short_untracked(null_termination, it, s);
- }
-}
-
int cmd_status(int argc, const char **argv, const char *prefix)
{
struct wt_status s;
@@ -1115,10 +1022,10 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_SHORT:
if (s.relative_paths)
s.prefix = prefix;
- short_print(&s, null_termination);
+ wt_shortstatus_print(&s, null_termination);
break;
case STATUS_FORMAT_PORCELAIN:
- short_print(&s, null_termination);
+ wt_shortstatus_print(&s, null_termination);
break;
case STATUS_FORMAT_LONG:
s.verbose = verbose;
diff --git a/wt-status.c b/wt-status.c
index 3c2f580..93af994 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -600,3 +600,92 @@ void wt_status_print(struct wt_status *s)
printf("nothing to commit (working directory clean)\n");
}
}
+
+static void wt_shortstatus_unmerged(int null_termination, struct string_list_item *it,
+ struct wt_status *s)
+{
+ struct wt_status_change_data *d = it->util;
+ const char *how = "??";
+
+ switch (d->stagemask) {
+ case 1: how = "DD"; break; /* both deleted */
+ case 2: how = "AU"; break; /* added by us */
+ case 3: how = "UD"; break; /* deleted by them */
+ case 4: how = "UA"; break; /* added by them */
+ case 5: how = "DU"; break; /* deleted by us */
+ case 6: how = "AA"; break; /* both added */
+ case 7: how = "UU"; break; /* both modified */
+ }
+ printf("%s ", how);
+ if (null_termination) {
+ fprintf(stdout, "%s%c", it->string, 0);
+ } else {
+ struct strbuf onebuf = STRBUF_INIT;
+ const char *one;
+ one = quote_path(it->string, -1, &onebuf, s->prefix);
+ printf("%s\n", one);
+ strbuf_release(&onebuf);
+ }
+}
+
+static void wt_shortstatus_status(int null_termination, struct string_list_item *it,
+ struct wt_status *s)
+{
+ struct wt_status_change_data *d = it->util;
+
+ printf("%c%c ",
+ !d->index_status ? ' ' : d->index_status,
+ !d->worktree_status ? ' ' : d->worktree_status);
+ if (null_termination) {
+ fprintf(stdout, "%s%c", it->string, 0);
+ if (d->head_path)
+ fprintf(stdout, "%s%c", d->head_path, 0);
+ } else {
+ struct strbuf onebuf = STRBUF_INIT;
+ const char *one;
+ if (d->head_path) {
+ one = quote_path(d->head_path, -1, &onebuf, s->prefix);
+ printf("%s -> ", one);
+ strbuf_release(&onebuf);
+ }
+ one = quote_path(it->string, -1, &onebuf, s->prefix);
+ printf("%s\n", one);
+ strbuf_release(&onebuf);
+ }
+}
+
+static void wt_shortstatus_untracked(int null_termination, struct string_list_item *it,
+ struct wt_status *s)
+{
+ if (null_termination) {
+ fprintf(stdout, "?? %s%c", it->string, 0);
+ } else {
+ struct strbuf onebuf = STRBUF_INIT;
+ const char *one;
+ one = quote_path(it->string, -1, &onebuf, s->prefix);
+ printf("?? %s\n", one);
+ strbuf_release(&onebuf);
+ }
+}
+
+void wt_shortstatus_print(struct wt_status *s, int null_termination)
+{
+ int i;
+ for (i = 0; i < s->change.nr; i++) {
+ struct wt_status_change_data *d;
+ struct string_list_item *it;
+
+ it = &(s->change.items[i]);
+ d = it->util;
+ if (d->stagemask)
+ wt_shortstatus_unmerged(null_termination, it, s);
+ else
+ wt_shortstatus_status(null_termination, it, s);
+ }
+ for (i = 0; i < s->untracked.nr; i++) {
+ struct string_list_item *it;
+
+ it = &(s->untracked.items[i]);
+ wt_shortstatus_untracked(null_termination, it, s);
+ }
+}
diff --git a/wt-status.h b/wt-status.h
index 09fd9f1..39c9aef 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -56,4 +56,6 @@ void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
+void wt_shortstatus_print(struct wt_status *s, int null_termination);
+
#endif /* STATUS_H */
--
1.6.6.rc1.282.ge6667
^ permalink raw reply related
* [PATCH 2/2] status -s: obey color.status
From: Michael J Gruber @ 2009-12-05 15:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <cover.1260025135.git.git@drmicha.warpmail.net>
Make the short version of status obey the color.status boolean. We color
the status letters only, because they carry the state information and are
potentially colored differently, such as for a file with staged changes
as well as changes in the worktree against the index.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
builtin-commit.c | 4 ++++
wt-status.c | 21 ++++++++++++++-------
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 548bbf5..ddcfffb 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -1022,6 +1022,10 @@ int cmd_status(int argc, const char **argv, const char *prefix)
case STATUS_FORMAT_SHORT:
if (s.relative_paths)
s.prefix = prefix;
+ if (s.use_color == -1)
+ s.use_color = git_use_color_default;
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
wt_shortstatus_print(&s, null_termination);
break;
case STATUS_FORMAT_PORCELAIN:
diff --git a/wt-status.c b/wt-status.c
index 93af994..a8b6d05 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -616,14 +616,14 @@ static void wt_shortstatus_unmerged(int null_termination, struct string_list_ite
case 6: how = "AA"; break; /* both added */
case 7: how = "UU"; break; /* both modified */
}
- printf("%s ", how);
+ color_fprintf(s->fp, color(WT_STATUS_UNMERGED, s), "%s", how);
if (null_termination) {
- fprintf(stdout, "%s%c", it->string, 0);
+ fprintf(stdout, " %s%c", it->string, 0);
} else {
struct strbuf onebuf = STRBUF_INIT;
const char *one;
one = quote_path(it->string, -1, &onebuf, s->prefix);
- printf("%s\n", one);
+ printf(" %s\n", one);
strbuf_release(&onebuf);
}
}
@@ -633,9 +633,15 @@ static void wt_shortstatus_status(int null_termination, struct string_list_item
{
struct wt_status_change_data *d = it->util;
- printf("%c%c ",
- !d->index_status ? ' ' : d->index_status,
- !d->worktree_status ? ' ' : d->worktree_status);
+ if (d->index_status)
+ color_fprintf(s->fp, color(WT_STATUS_UPDATED, s), "%c", d->index_status);
+ else
+ putchar(' ');
+ if (d->worktree_status)
+ color_fprintf(s->fp, color(WT_STATUS_CHANGED, s), "%c", d->worktree_status);
+ else
+ putchar(' ');
+ putchar(' ');
if (null_termination) {
fprintf(stdout, "%s%c", it->string, 0);
if (d->head_path)
@@ -663,7 +669,8 @@ static void wt_shortstatus_untracked(int null_termination, struct string_list_it
struct strbuf onebuf = STRBUF_INIT;
const char *one;
one = quote_path(it->string, -1, &onebuf, s->prefix);
- printf("?? %s\n", one);
+ color_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), "??");
+ printf(" %s\n", one);
strbuf_release(&onebuf);
}
}
--
1.6.6.rc1.282.ge6667
^ permalink raw reply related
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: James P. Howard, II @ 2009-12-05 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr6t6fnz.fsf@alter.siamese.dyndns.org>
On Fri, Dec 04, 2009 at 11:30:56PM -0800, Junio C Hamano wrote:
> Two points and a half:
>
> - Why does info_display need to be visible to everybody else by being in
> cache.h and environment.c? Shouldn't its scope be similar to that of
> template_file, that is static to builtin-commit.c?
>
> - A configuration variable that does not allow the users to override from
> the command line is a no-no. We usually do command line option first
> and then (or at the same time) configuration variable as a typesaver.
I can make these changes in the next few days.
> - While the amount of change necessary for this change doesn't look too
> bad, is it really worth it? What is wrong with "1,$p" while using ed
> as your editor?
I tried a few variants of this, and shell script wrappers for ex (and
gate, which is a specizalized text editor that actually works kind of
well for commit message editing), and it worked fairly well.
The real motivation is that this feature ditches all assumptions about
the capabilities of the text editor. I am not sure where that leads
yet, but I'd rather make it possible.
James
--
James P. Howard, II, MPA MBCS
jh@jameshoward.us
^ permalink raw reply
* Re: [PATCH] Cast &cp to eliminate a compile-time warning on FreeBSD 8-STABLE.
From: Jeff King @ 2009-12-05 16:14 UTC (permalink / raw)
To: James P. Howard, II; +Cc: git
In-Reply-To: <1259968322-66072-1-git-send-email-jh@jameshoward.us>
On Fri, Dec 04, 2009 at 06:12:02PM -0500, James P. Howard, II wrote:
> --- a/utf8.c
> +++ b/utf8.c
> @@ -449,7 +449,7 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
> cp = (iconv_ibp)in;
>
> while (1) {
> - size_t cnt = iconv(conv, &cp, &insz, &outpos, &outsz);
> + size_t cnt = iconv(conv, (const char **)&cp, &insz, &outpos, &outsz);
>
> if (cnt == -1) {
> size_t sofar;
Aren't you now introducing a warning for all of the other platforms
which take a "char **"? Should you instead just be building with
OLD_ICONV=Yes on your platform? See commit fd547a9 for details.
-Peff
^ permalink raw reply
* Re: [PATCH] Add commit.infodisplay option to give message editor empty file
From: Jeff King @ 2009-12-05 16:28 UTC (permalink / raw)
To: James P. Howard, II; +Cc: Junio C Hamano, git
In-Reply-To: <20091205154753.GA3717@thermopylae.local>
On Sat, Dec 05, 2009 at 10:47:53AM -0500, James P. Howard, II wrote:
> > - While the amount of change necessary for this change doesn't look too
> > bad, is it really worth it? What is wrong with "1,$p" while using ed
> > as your editor?
>
> I tried a few variants of this, and shell script wrappers for ex (and
> gate, which is a specizalized text editor that actually works kind of
> well for commit message editing), and it worked fairly well.
>
> The real motivation is that this feature ditches all assumptions about
> the capabilities of the text editor. I am not sure where that leads
> yet, but I'd rather make it possible.
Is your problem that your editor doesn't show the template content and
you want to see it, or is it that your editor isn't pleasant to use when
the buffer is pre-filled with the template?
If the former, it seems like just dumping it to stdout isn't all that
satisfying, either. What happens when your editing causes the
information to scroll off the screen and you want to see it again?
Couldn't you get the same thing just by doing "git status; git commit"?
If the latter, I think we would be better served by an option to simply
turn off the template. Then that is also helpful for the case of people
using decent editors, but who don't want to waste the CPU time on
generating the template information (which can be substantial for things
like media repositories).
I suspect your answer will be that it is some of both, but this just
really feels like we are putting hacks into git because of one
featureless editor. Hacks like that would be better suited (IMHO) to a
wrapper script for the editor.
-Peff
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: Dilip M @ 2009-12-05 16:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marc Strapetz, git
In-Reply-To: <alpine.DEB.1.00.0912051601040.4985@pacific.mpi-cbg.de>
On Sat, Dec 5, 2009 at 8:31 PM, <Johannes.Schindelin@gmx.de> wrote:
> As for "missing", do you refer to "paid service", or "yet another GUI"?
Ahaha! I can say "a good gui" :)
I was not knowing that this was "paid service". I saw the screenshot
and tried it. No doubt, it has a _great_ ui interface. While installation I
realized that it is licensed.
- SOFTWARE Non-Commercial License,
- SOFTWARE Commercial License,
- SOFTWARE Enterprise License.
-- Dilip
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Junio C Hamano @ 2009-12-05 18:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Maarten Lankhorst, git
In-Reply-To: <7vljhislbj.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ... The test already checks that the change won't break soft reset,
> which is good, but it does not seem to check/specify what should happen in
> the mixed reset in this case (I think it should be allowed).
Heh, I was not thinking straight. A bare repository does not have the
index, so allowing (cd .git && git reset) is Ok but mixed in a bare
repository (cd bare.git && git reset) is not.
Let's cover a few more missing cases.
t/t7103-reset-bare.sh | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/t/t7103-reset-bare.sh b/t/t7103-reset-bare.sh
index 3ddf0ac..68041df 100755
--- a/t/t7103-reset-bare.sh
+++ b/t/t7103-reset-bare.sh
@@ -21,20 +21,32 @@ test_expect_success 'merge reset requires a worktree' '
test_must_fail git reset --merge)
'
+test_expect_success 'mixed reset is ok' '
+ (cd .git && git reset)
+'
+
+test_expect_success 'soft reset is ok' '
+ (cd .git && git reset --soft)
+'
+
test_expect_success 'setup bare' '
git clone --bare . bare.git &&
cd bare.git
'
-test_expect_success 'hard reset is not allowed' '
- test_must_fail git reset --hard HEAD^
+test_expect_success 'hard reset is not allowed in bare' '
+ test_must_fail git reset --hard HEAD^
'
-test_expect_success 'merge reset is not allowed' '
+test_expect_success 'merge reset is not allowed in bare' '
test_must_fail git reset --merge HEAD^
'
-test_expect_success 'soft reset is allowed' '
+test_expect_success 'mixed reset is not allowed in bare' '
+ test_must_fail git reset --mixed HEAD^
+'
+
+test_expect_success 'soft reset is allowed in bare' '
git reset --soft HEAD^ &&
test "`git show --pretty=format:%s | head -n 1`" = "one"
'
^ permalink raw reply related
* Re: [PATCH 3/3] Add a command "fix" to rebase --interactive.
From: Junio C Hamano @ 2009-12-05 18:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Michael Haggerty, git
In-Reply-To: <alpine.DEB.1.00.0912041943160.21557@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Fri, 4 Dec 2009, Junio C Hamano wrote:
>
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>> > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
>> > index 0bd3bf7..539413d 100755
>> > --- a/git-rebase--interactive.sh
>> > +++ b/git-rebase--interactive.sh
>> > @@ -302,7 +302,7 @@ nth_string () {
>> >
>> > make_squash_message () {
>> > if test -f "$SQUASH_MSG"; then
>> > - COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
>> > + COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
> ...
> IIRC "|" was not correctly handled by BSD sed (used e.g. in MacOSX).
You are right; we actually have seen and fixed a similar breakage. For
example, "git log --all-match --grep=BRE --grep=ERE" finds:
commit 1883a0d3b7ad7c9de1ac790bda6f1a6181237439
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Sep 19 23:52:49 2008 -0700
diff: use extended regexp to find hunk headers
Using ERE elements such as "|" (alternation) by backquoting in BRE
is a GNU extension and should not be done in portable programs.
and "sed" is defined to take BRE.
Tentatively I'd queue this on top of 3/3 for eventual squashing.
Thanks
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Sat, 5 Dec 2009 10:42:44 -0800
Subject: [PATCH] [squash to Add a command "fix"] Avoid "\(alternatives\|choices\)" in sed script
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 539413d..c30209e 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -302,7 +302,7 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
- COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)\(th\|st\|nd\|rd\) commit message.*:/\1/p" \
+ COUNT=$(($(sed -n "s/^# Th[^0-9]*\([1-9][0-9]*\)[tsnr][htd] commit message.*:$/\1/p" \
< "$SQUASH_MSG" | sed -ne '$p')+1))
echo "# This is a combination of $COUNT commits."
sed -e 1d -e '2,/^./{
--
1.6.6.rc1.31.g1a56b
^ 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