* 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
* Gui criticism
From: Ram Rachum @ 2009-12-05 18:51 UTC (permalink / raw)
To: git
Hello!
This is my first time on this list. I'm a Python developer who's been using git
for about a year. I generally like it, but I have several gripes about the GUI.
(My development machine is on Windows XP.) Would specifying these criticisms be
helpful to you?
Best Wishes,
Ram Rachum.
^ permalink raw reply
* Re: git reset --hard in .git causes a checkout in that directory
From: Junio C Hamano @ 2009-12-05 19:06 UTC (permalink / raw)
To: Jeff King; +Cc: Maarten Lankhorst, Junio C Hamano, git
In-Reply-To: <20091204111158.GE27495@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Dec 03, 2009 at 12:30:46PM +0100, Maarten Lankhorst wrote:
>
>> When I was working on my code and made a mess that I wanted to undo,
>> I accidentally did it in the .git directory, and had a whole clone of
>> my last committed tree there.
>>
>> It can be triggered easily:
>>
>> mkdir test; cd test; git init; touch foo; git add foo; git commit -m
>> 'add foo'; cd .git; git reset --hard; [ -f foo ] && echo hello beauty
>>
>> Other parts of git could be affected, I haven't checked where exactly
>> the bug hides, so I was afraid to send in a patch
>
> Yuck. Thanks for the bug report. This is due to a too-loose check on my
> part in 49b9362 (git-reset: refuse to do hard reset in a bare
> repository, 2007-12-31).
>
> Junio, I think the following should go to maint (I didn't bother
> splitting the --merge and --hard code; --merge is in v1.6.2. I assumed
> we don't care about maint releases that far back).
Although I'll apply your patch to 'maint' and will merge it for 1.6.6, I
am not quite sure if this is the best fix in the longer run. Shouldn't we
go back to the top of the work tree and running what was asked there?
^ permalink raw reply
* Re: Gui criticism
From: Michael J Gruber @ 2009-12-05 19:25 UTC (permalink / raw)
To: Ram Rachum; +Cc: git
In-Reply-To: <loom.20091205T194800-496@post.gmane.org>
Ram Rachum venit, vidit, dixit 05.12.2009 19:51:
> Hello!
>
> This is my first time on this list. I'm a Python developer who's been using git
> for about a year. I generally like it, but I have several gripes about the GUI.
> (My development machine is on Windows XP.) Would specifying these criticisms be
> helpful to you?
No, unless they are specific bug reports.
The main problem is that we have too many GUIs, and the "main" ones are
in tcl/tk which not many people write. So there's a small developer base
for the standard GUI, and the rest prefers to split up and each do their
own GUI rather than work on a coordinated project. (I've tried to change
that before.)
Michael
^ permalink raw reply
* Re: Gui criticism
From: Felipe Contreras @ 2009-12-05 19:37 UTC (permalink / raw)
To: Ram Rachum; +Cc: git
In-Reply-To: <loom.20091205T194800-496@post.gmane.org>
Hello Ram,
On Sat, Dec 5, 2009 at 8:51 PM, Ram Rachum <cool-rr@cool-rr.com> wrote:
> This is my first time on this list. I'm a Python developer who's been using git
> for about a year. I generally like it, but I have several gripes about the GUI.
> (My development machine is on Windows XP.) Would specifying these criticisms be
> helpful to you?
I don't think the mailing list is the best place for this, that's why
I just started a project in SourceForge, so that users can post these
kinds of issues in the ideatorrent:
https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
I haven't made the announcement yet, but soon :)
--
Felipe Contreras
^ permalink raw reply
* Re: Speedlimit at "git clone"
From: Stefan Kuhne @ 2009-12-05 19:40 UTC (permalink / raw)
To: git
In-Reply-To: <4B17AA6B.7030000@access.denied>
[-- Attachment #1: Type: text/plain, Size: 141 bytes --]
Stefan Kuhne schrieb:
Hello,
>
> how can i limit the download speed at "git clone"?
>
no one any idea?
Regards,
Stefan Kuhne
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 552 bytes --]
^ permalink raw reply
* Re: Gui criticism
From: Martin Langhoff @ 2009-12-05 19:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051137u682a3a99ved9d19338b881b13@mail.gmail.com>
On Sat, Dec 5, 2009 at 8:37 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> I don't think the mailing list is the best place for this
Mailing lists and face to face events are _the_ best places.
> I just started a project in SourceForge
A new project is for code. And the existing GUIs need help, your help,
in the already existing mailing lists and codebases they have.
>, so that users can post these
> kinds of issues
In a safe place where developers won't read?
> I haven't made the announcement yet, but soon :)
How about picking an existing git GUI project you're prepared to help,
and... just... help? Code, documentation, screen mockups, graphic art?
Is it too... normal? Maybe too... productive?
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Gui criticism
From: Junio C Hamano @ 2009-12-05 20:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051137u682a3a99ved9d19338b881b13@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> I don't think the mailing list is the best place for this, that's why
> I just started a project in SourceForge, so that users can post these
> kinds of issues in the ideatorrent:
> https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
Two issues and a half offhand after entering one:
- I found the experience of adding an "idea" too clunky and slow.
Writing a well thought out e-mail can be done in the same time.
- Although enforcing a minimum structure of "idea" description is a good
thing to do, I found the current structure presented by that web page
lacks focus. It has problem description and a rather broad and vague
"idea", and it feels to me that it is promoting entering any garbage
without discussing feasibility, "pros-and-cons" or necessary steps to
achieve a particular goal.
- The largest issue of this kind of system is who will be moderating and
how capable they are.
^ permalink raw reply
* Re: Gui criticism
From: Felipe Contreras @ 2009-12-05 20:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ram Rachum, git
In-Reply-To: <7v3a3prxdt.fsf@alter.siamese.dyndns.org>
On Sat, Dec 5, 2009 at 10:14 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I don't think the mailing list is the best place for this, that's why
>> I just started a project in SourceForge, so that users can post these
>> kinds of issues in the ideatorrent:
>> https://sourceforge.net/apps/ideatorrent/git-ux/ideatorrent/
>
> Two issues and a half offhand after entering one:
>
> - I found the experience of adding an "idea" too clunky and slow.
> Writing a well thought out e-mail can be done in the same time.
Yeah, I agree; it's too slow right now, but it's the only way I've
found to host some kind of ideastorm.
The difference with e-mails is that ideas get votes, which helps to
find out what users really want:
http://brainstorm.ubuntu.com/
Also, the main action to do in this system should be "vote", that's
the action that should be fast.
> - Although enforcing a minimum structure of "idea" description is a good
> thing to do, I found the current structure presented by that web page
> lacks focus. It has problem description and a rather broad and vague
> "idea", and it feels to me that it is promoting entering any garbage
> without discussing feasibility, "pros-and-cons" or necessary steps to
> achieve a particular goal.
That's why ideas go to a sandbox, and then maintainers approve or reject them.
> - The largest issue of this kind of system is who will be moderating and
> how capable they are.
Indeed, that's one issue, but also, it needs a large inflow of votes,
and when popular ideas are identified, then it needs people to
actually implement them.
--
Felipe Contreras
^ permalink raw reply
* Re: Gui criticism
From: Junio C Hamano @ 2009-12-05 20:41 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Ram Rachum, git
In-Reply-To: <94a0d4530912051225y2d193a1fqfb38ebcce95719c3@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Also, the main action to do in this system should be "vote", that's
> the action that should be fast.
Actually I do not think you would want that, especially as a moderator (I
am assuming that you would be self-appointing to be one). What will you
do to help a "broad, vague, and infeasible idea" forward when it gets many
votes?
That is why I prefer a system that requires substance when voicing an
opinion ("Yes I like the solution because in addition to the original
problem description it will also help this use case"), and it also is the
reason I tend to ignore e-mails that only say "+1" on this list.
In other words, this is not a democracy, and you do not necessarily want a
democracy that is prone to populism.
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: David Aguilar @ 2009-12-05 20:44 UTC (permalink / raw)
To: Dilip M; +Cc: Johannes Schindelin, Marc Strapetz, git
In-Reply-To: <c94f8e120912050832o6d43672bla3beb1e3cedd7db3@mail.gmail.com>
On Sat, Dec 05, 2009 at 10:02:08PM +0530, Dilip M wrote:
> 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.
Aside from the other good GUIs out there, have you tried
git-cola?
http://cola.tuxfamily.org/
It's GPL and not too shabby.
The screenshots on the webpage are a bit out of date, though.
I should probably get to writing the release announcment and
updating the screenshots ;)
It probably also depends on your platform of choice.
I know some Windows users like explorer-integration, so stuff
like git-cheetah make a lot of sense for them. I was a little
sad to see that the tortoise-git guys didn't get the joke
(who wants a tortoise when you have a cheetah?) and didn't
just work on cheetah instead, but hey, it's all good.
Another example: eclipse users like eclipse integration so for
them egit makes perfect sense.
Maybe that makes git-cola the poor man's smartgit?
If that's the case then it looks like the poor man is still
winning according to the feature matrix on the git wiki ;)
I don't know.. I haven't used smartgit, but if there are
any features that people are itching to have that git-cola
doesn't then feel free to throw it on the backlog:
http://github.com/davvid/git-cola/issues
At first glance, the gitk-like history widget in smartgit
is very nice. I've been thinking about how to implement that in
PyQt for a while but haven't yet hammered it out.
Have fun,
--
David
^ permalink raw reply
* Re: [PATCH] bash: update 'git commit' completion
From: Shawn O. Pearce @ 2009-12-05 21:17 UTC (permalink / raw)
To: SZEDER G??bor; +Cc: Junio C Hamano, git
In-Reply-To: <1259974301-11593-1-git-send-email-szeder@ira.uka.de>
SZEDER G??bor <szeder@ira.uka.de> wrote:
> 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>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/git-completion.bash | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
--
Shawn.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox