* Re: [RFC/PATCHv8 00/10] git notes
From: Junio C Hamano @ 2009-11-20 10:46 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johan Herland, git, spearce
In-Reply-To: <20091120192800.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
>> Step 0. Apply as you specified on top of 'next'
>>
>> $ git checkout next^0
>> $ git am -s your-10-patches
>> $ M=$(git describe)
>>
>> Step 1. Rebase back to the bottom of the old series
>>
>> $ git checkout next...jh/notes
>
> What do three-dots mean in this command?
>
>> $ git rebase --onto HEAD next $M
>> $ N=$(git describe)
Heh, good eyes.
I forgot that I had this toy hidden from the general public.
-- >8 --
Subject: [PATCH] "checkout A...B" switches to the merge base between A and B
When flipping commits around on topic branches, I often end up doing
this sequence:
* Run "log --oneline next..jc/frotz" to find out the first commit
on 'jc/frotz' branch not yet merged to 'next';
* Run "checkout $that_commit^" to detach HEAD to the parent of it;
* Rebuild the series on top of that commit; and
* "show-branch jc/frotz HEAD" and "diff jc/frotz HEAD" to verify.
Introduce a new syntax to "git checkout" to name the commit to switch to,
to make the first two steps easier. When the branch to switch to is
specified as A...B (you can omit either A or B but not both, and HEAD
is used instead of the omitted side), the merge base between these two
commits are computed, and if there is one unique one, we detach the HEAD
at that commit.
With this, I can say "checkout next...jc/frotz".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 7 +++++--
cache.h | 1 +
sha1_name.c | 42 ++++++++++++++++++++++++++++++++++++++++++
t/t2012-checkout-last.sh | 27 ++++++++++++++++++++++++++-
4 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..7167111 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -690,7 +690,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
* case 3: git checkout <something> [<paths>]
*
* With no paths, if <something> is a commit, that is to
- * switch to the branch or detach HEAD at it.
+ * switch to the branch or detach HEAD at it. As a special case,
+ * if <something> is A...B (missing A or B means HEAD but you can
+ * omit at most one side), and if there is a unique merge base
+ * between A and B, A...B names that merge base.
*
* With no paths, if <something> is _not_ a commit, no -t nor -b
* was given, and there is a tracking branch whose name is
@@ -716,7 +719,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (!strcmp(arg, "-"))
arg = "@{-1}";
- if (get_sha1(arg, rev)) {
+ if (get_sha1_mb(arg, rev)) {
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
if (!patch_mode &&
diff --git a/cache.h b/cache.h
index 71a731d..f8df15a 100644
--- a/cache.h
+++ b/cache.h
@@ -703,6 +703,7 @@ extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *
extern int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref);
extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
extern int interpret_branch_name(const char *str, struct strbuf *);
+extern int get_sha1_mb(const char *str, unsigned char *sha1);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..d5a240c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -794,6 +794,48 @@ release_return:
return retval;
}
+int get_sha1_mb(const char *name, unsigned char *sha1)
+{
+ struct commit *one, *two;
+ struct commit_list *mbs;
+ unsigned char sha1_tmp[20];
+ const char *dots;
+ int st;
+
+ dots = strstr(name, "...");
+ if (!dots)
+ return get_sha1(name, sha1);
+ if (dots == name)
+ st = get_sha1("HEAD", sha1_tmp);
+ else {
+ struct strbuf sb;
+ strbuf_init(&sb, dots - name);
+ strbuf_add(&sb, name, dots - name);
+ st = get_sha1(sb.buf, sha1_tmp);
+ strbuf_release(&sb);
+ }
+ if (st)
+ return st;
+ one = lookup_commit_reference_gently(sha1_tmp, 0);
+ if (!one)
+ return -1;
+
+ if (get_sha1(dots[3] ? (dots + 3) : "HEAD", sha1_tmp))
+ return -1;
+ two = lookup_commit_reference_gently(sha1_tmp, 0);
+ if (!two)
+ return -1;
+ mbs = get_merge_bases(one, two, 1);
+ if (!mbs || mbs->next)
+ st = -1;
+ else {
+ st = 0;
+ hashcpy(sha1, mbs->item->object.sha1);
+ }
+ free_commit_list(mbs);
+ return st;
+}
+
/*
* This is like "get_sha1_basic()", except it allows "sha1 expressions",
* notably "xyz^" for "parent of xyz"
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index 87b30a2..b44de9d 100755
--- a/t/t2012-checkout-last.sh
+++ b/t/t2012-checkout-last.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='checkout can switch to last branch'
+test_description='checkout can switch to last branch and merge base'
. ./test-lib.sh
@@ -91,4 +91,29 @@ test_expect_success 'switch to twelfth from the last' '
test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch13"
'
+test_expect_success 'merge base test setup' '
+ git checkout -b another other &&
+ echo "hello again" >>world &&
+ git add world &&
+ git commit -m third
+'
+
+test_expect_success 'another...master' '
+ git checkout another &&
+ git checkout another...master &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
+test_expect_success '...master' '
+ git checkout another &&
+ git checkout ...master &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
+test_expect_success 'master...' '
+ git checkout another &&
+ git checkout master... &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
test_done
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* Re: Ambiguous ref names
From: Jeenu V @ 2009-11-20 10:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl6h3319.fsf@alter.siamese.dyndns.org>
On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> [...]
> It could be that you have a tag and a branch that are both named a.b.c,
> though.
Hm, right. But I'm getting this from an existing local repo of mine. I
can't see any tags; 'git tag -l' is empty. Is there any more info that
I can provide?
FWIW, I'm running Git under Cygwin.
--
:J
^ permalink raw reply
* Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Adrian May @ 2009-11-20 10:51 UTC (permalink / raw)
To: git
In-Reply-To: <2d707e8c-2561-470c-beba-c81e16ac441c@k17g2000yqh.googlegroups.com>
Git is just plain wrong, because you can't split or merge repositories
or pull subtrees of them. It doesn't have the kind of triggers you
need to assert change control either, and these bolt-on scripts are
just making life messy. Will somebody please finish git itself instead
of working around it, or use a source control system that's up to the
job.
Adrian.
PS: In both cases, I had problems pulling the code.
^ permalink raw reply
* Re: Ambiguous ref names
From: Junio C Hamano @ 2009-11-20 10:59 UTC (permalink / raw)
To: Jeenu V; +Cc: Junio C Hamano, git
In-Reply-To: <5195c8760911200248v1f3d6b56q78987edfceae5541@mail.gmail.com>
Jeenu V <jeenuv@gmail.com> writes:
> On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> [...]
>> It could be that you have a tag and a branch that are both named a.b.c,
>> though.
>
> Hm, right. But I'm getting this from an existing local repo of mine. I
> can't see any tags; 'git tag -l' is empty. Is there any more info that
> I can provide?
man git-for-each-ref?
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Junio C Hamano @ 2009-11-20 11:02 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johan Herland, git, spearce
In-Reply-To: <7vk4xl1nkl.fsf@alter.siamese.dyndns.org>
By the way, we could probably use this to make the command sequence even
shorter.
I have to warn that this has never been used in real life, unlike the
"checkout A...B" one --- caveat emptor.
Also I didn't bother touching up "rebase -i"; it is left as an excercise
to the readers ;-)
-- >8 --
Subject: [PATCH] "rebase --onto A...B" replays history on the merge base between A and B
This is in spirit similar to "checkout A...B". To re-queue a new set of
patches for a series that the original author prepared to apply on 'next'
on the same base as before, you would do something like this:
$ git checkout next^0
$ git am -s rerolled-series.mbox
$ git rebase --onto next...jh/notes next
The first two commands recreates commits to be rebased as the original
author intended (i.e. applies directly on top of 'next'), and the rebase
command replays that history on top of the same commit the series being
replaced was built on (which is typically much older than the tip of
'next').
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-rebase.sh | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 6830e16..570e2b6 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -34,6 +34,8 @@ set_reflog_action rebase
require_work_tree
cd_to_toplevel
+LF='
+'
OK_TO_SKIP_PRE_REBASE=
RESOLVEMSG="
When you have resolved this problem run \"git rebase --continue\".
@@ -417,7 +419,22 @@ fi
# Make sure the branch to rebase onto is valid.
onto_name=${newbase-"$upstream_name"}
-onto=$(git rev-parse --verify "${onto_name}^0") || exit
+if left=$(expr "$onto_name" : '\(.*\)\.\.\.') &&
+ right=$(expr "$onto_name" : '\.\.\.\(.*\)$') &&
+ : ${left:=HEAD} ${right:=HEAD} &&
+ onto=$(git merge-base "$left" "$right")
+then
+ case "$onto" in
+ ?*"$LF"?*)
+ die "$onto_name: there are more than one merge bases"
+ ;;
+ '')
+ die "$onto_name: there is no merge base"
+ ;;
+ esac
+else
+ onto=$(git rev-parse --verify "${onto_name}^0") || exit
+fi
# If a hook exists, give it a chance to interrupt
run_pre_rebase_hook "$upstream_arg" "$@"
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* [PATCH 0/3] "log --stdin" updates
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
These three come on top of 61ab67a (Teach --stdin option to "log" family,
2009-11-03), which gave "--stdin" to the log family of commands (e.g. log,
rev-list). The earlier patch allowed you to feed only the revs (which was
what gitk originally wanted), but after zero or more revs (one rev per
line), you can now feed a line that consists of "--" and then pathspecs
(one path per line).
The whole series probably need to be updated to learn -z option to read
NUL terminated input.
Junio C Hamano (3):
read_revision_from_stdin(): use strbuf
setup_revisions(): do not call get_pathspec() too early
Make --stdin option to "log" family read also pathspecs
revision.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 82 insertions(+), 13 deletions(-)
^ permalink raw reply
* [PATCH 1/3] read_revision_from_stdin(): use strbuf
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
It is so 2005 (and Linus ;-) to have a fixed 1000-byte buffer that
reads from the user. Let's use strbuf to unlimit the input length.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/revision.c b/revision.c
index 45c5de8..f5b735f 100644
--- a/revision.c
+++ b/revision.c
@@ -955,19 +955,21 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
static void read_revisions_from_stdin(struct rev_info *revs)
{
- char line[1000];
+ struct strbuf sb;
- while (fgets(line, sizeof(line), stdin) != NULL) {
- int len = strlen(line);
- if (len && line[len - 1] == '\n')
- line[--len] = '\0';
+ strbuf_init(&sb, 1000);
+ while (strbuf_getwholeline(&sb, stdin, '\n') != EOF) {
+ int len = sb.len;
+ if (len && sb.buf[len - 1] == '\n')
+ sb.buf[--len] = '\0';
if (!len)
break;
- if (line[0] == '-')
+ if (sb.buf[0] == '-')
die("options not supported in --stdin mode");
- if (handle_revision_arg(line, revs, 0, 1))
- die("bad revision '%s'", line);
+ if (handle_revision_arg(sb.buf, revs, 0, 1))
+ die("bad revision '%s'", sb.buf);
}
+ strbuf_release(&sb);
}
static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* [PATCH 2/3] setup_revisions(): do not call get_pathspec() too early
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
This is necessary because in the next patch I'll allow pathspecs to be fed
from the standard input, and pathspecs taken from the command line (and
converted via get_pathspec() already) in revs->prune_data too early gets
in the way when we want to append from the standard input.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index f5b735f..4410a45 100644
--- a/revision.c
+++ b/revision.c
@@ -1230,6 +1230,7 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def)
{
int i, flags, left, seen_dashdash, read_from_stdin;
+ const char **prune_data = NULL;
/* First, search for "--" */
seen_dashdash = 0;
@@ -1240,7 +1241,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
argv[i] = NULL;
argc = i;
if (argv[i + 1])
- revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
+ prune_data = argv + i + 1;
seen_dashdash = 1;
break;
}
@@ -1321,12 +1322,14 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
for (j = i; j < argc; j++)
verify_filename(revs->prefix, argv[j]);
- revs->prune_data = get_pathspec(revs->prefix,
- argv + i);
+ prune_data = argv + i;
break;
}
}
+ if (prune_data)
+ revs->prune_data = get_pathspec(revs->prefix, prune_data);
+
if (revs->def == NULL)
revs->def = def;
if (revs->show_merge)
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* [PATCH 3/3] Make --stdin option to "log" family read also pathspecs
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
Similar to the command line arguments, after giving zero or more revs, you can
feed a line "--" and then feed pathspecs one at a time.
With this
(
echo ^maint
echo --
echo Documentation
) | git log --stat --oneline --stdin master -- t
lists commits that touch Documentation/ or t/ between maint and master.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 4410a45..8750c20 100644
--- a/revision.c
+++ b/revision.c
@@ -953,9 +953,38 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
return 0;
}
-static void read_revisions_from_stdin(struct rev_info *revs)
+static void read_pathspec_from_stdin(struct rev_info *revs, struct strbuf *sb, const char ***prune_data)
+{
+ const char **prune = *prune_data;
+ int prune_nr;
+ int prune_alloc;
+
+ /* count existing ones */
+ if (!prune)
+ prune_nr = 0;
+ else
+ for (prune_nr = 0; prune[prune_nr]; prune_nr++)
+ ;
+ prune_alloc = prune_nr; /* not really, but we do not know */
+
+ while (strbuf_getwholeline(sb, stdin, '\n') != EOF) {
+ int len = sb->len;
+ if (len && sb->buf[len - 1] == '\n')
+ sb->buf[--len] = '\0';
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr++] = xstrdup(sb->buf);
+ }
+ if (prune) {
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr] = NULL;
+ }
+ *prune_data = prune;
+}
+
+static void read_revisions_from_stdin(struct rev_info *revs, const char ***prune)
{
struct strbuf sb;
+ int seen_dashdash = 0;
strbuf_init(&sb, 1000);
while (strbuf_getwholeline(&sb, stdin, '\n') != EOF) {
@@ -964,11 +993,18 @@ static void read_revisions_from_stdin(struct rev_info *revs)
sb.buf[--len] = '\0';
if (!len)
break;
- if (sb.buf[0] == '-')
+ if (sb.buf[0] == '-') {
+ if (len == 2 && sb.buf[1] == '-') {
+ seen_dashdash = 1;
+ break;
+ }
die("options not supported in --stdin mode");
+ }
if (handle_revision_arg(sb.buf, revs, 0, 1))
die("bad revision '%s'", sb.buf);
}
+ if (seen_dashdash)
+ read_pathspec_from_stdin(revs, &sb, prune);
strbuf_release(&sb);
}
@@ -1220,6 +1256,34 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
ctx->argc -= n;
}
+static void append_prune_data(const char ***prune_data, const char **av)
+{
+ const char **prune = *prune_data;
+ int prune_nr;
+ int prune_alloc;
+
+ if (!prune) {
+ *prune_data = av;
+ return;
+ }
+
+ /* count existing ones */
+ for (prune_nr = 0; prune[prune_nr]; prune_nr++)
+ ;
+ prune_alloc = prune_nr; /* not really, but we do not know */
+
+ while (*av) {
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr++] = *av;
+ av++;
+ }
+ if (prune) {
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr] = NULL;
+ }
+ *prune_data = prune;
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -1294,7 +1358,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
}
if (read_from_stdin++)
die("--stdin given twice?");
- read_revisions_from_stdin(revs);
+ read_revisions_from_stdin(revs, &prune_data);
continue;
}
@@ -1322,7 +1386,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
for (j = i; j < argc; j++)
verify_filename(revs->prefix, argv[j]);
- prune_data = argv + i;
+ append_prune_data(&prune_data, argv + i);
break;
}
}
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Johannes Schindelin @ 2009-11-20 11:31 UTC (permalink / raw)
To: Adrian May; +Cc: git
In-Reply-To: <65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com>
Hi,
On Fri, 20 Nov 2009, Adrian May wrote:
> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them.
You are plain wrong, because that is possible. Did you maybe forget to do
your homework before coming here and shouting around as if you were right?
> It doesn't have the kind of triggers you need to assert change control
> either, and these bolt-on scripts are just making life messy.
To the contrary, these "bolt-on scripts" are superior to other solutions,
because they give the savvy user freedom to do _anything_ a program can
do.
> Will somebody please finish git itself instead of working around it, or
> use a source control system that's up to the job.
You obviously do not understand Open Source. If you have an itch, scratch
it, or pay somebody to scratch it for you.
> PS: In both cases, I had problems pulling the code.
If you had problems pulling the code, there are two possible sources of
problems: the program or a PEBCAK.
Ciao,
Dscho
P.S.: Feels fine to vent for me, too.
^ permalink raw reply
* [PATCH] submodule.c: Squelch a "use before assignment" warning
From: David Aguilar @ 2009-11-20 11:33 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7v8we17ha9.fsf@alter.siamese.dyndns.org>
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) compiler
(and probably others) mistakenly thinks variable 'right' is used
before assigned. Work around it by giving it a fake initialization.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
submodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/submodule.c b/submodule.c
index 461faf0..86aad65 100644
--- a/submodule.c
+++ b/submodule.c
@@ -38,7 +38,7 @@ void show_submodule_summary(FILE *f, const char *path,
const char *del, const char *add, const char *reset)
{
struct rev_info rev;
- struct commit *commit, *left = left, *right;
+ struct commit *commit, *left = left, *right = right;
struct commit_list *merge_bases, *list;
const char *message = NULL;
struct strbuf sb = STRBUF_INIT;
--
1.6.5.3.171.ge36e
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Petr Baudis @ 2009-11-20 11:50 UTC (permalink / raw)
To: Adrian May; +Cc: git
In-Reply-To: <65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com>
On Fri, Nov 20, 2009 at 06:51:32PM +0800, Adrian May wrote:
> It doesn't have the kind of triggers you
> need to assert change control either, and these bolt-on scripts are
> just making life messy.
Can you elaborate?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: Ambiguous ref names
From: Jeenu V @ 2009-11-20 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr7dzckl.fsf@alter.siamese.dyndns.org>
On Fri, Nov 20, 2009 at 4:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeenu V <jeenuv@gmail.com> writes:
>
>> On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> [...]
>>> It could be that you have a tag and a branch that are both named a.b.c,
>>> though.
>>
>> Hm, right. But I'm getting this from an existing local repo of mine. I
>> can't see any tags; 'git tag -l' is empty. Is there any more info that
>> I can provide?
>
> man git-for-each-ref?
It does list all refs that I know of, but I don't see any duplicate entries.
--
:J
^ permalink raw reply
* [PATCH] bash completion: add space between branch name and status flags
From: Roman Fietze @ 2009-11-20 12:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Hello Shawn, hello git list members,
Wouldn't it improve the readability of the bash prompt, if there would
be a space between the branch name and the status flags (dirty, stash,
untracked)?
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
---
contrib/completion/git-completion.bash | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-
completion.bash
index bd66639..407176b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -169,10 +169,12 @@ __git_ps1 ()
fi
fi
+ local f="$w$i$s$u$r"
+ f=${f:+ $f}
if [ -n "${1-}" ]; then
- printf "$1" "$c${b##refs/heads/}$w$i$s$u$r"
+ printf "$1" "$c${b##refs/heads/}$f"
else
- printf " (%s)" "$c${b##refs/heads/}$w$i$s$u$r"
+ printf " (%s)" "$c${b##refs/heads/}$f"
fi
fi
}
--
1.6.4.2
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Jakub Narebski @ 2009-11-20 12:46 UTC (permalink / raw)
To: Adrian May; +Cc: git
In-Reply-To: <65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com>
Adrian May <adrian.alexander.may@gmail.com> writes:
> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them. It doesn't have the kind of triggers you
> need to assert change control either, and these bolt-on scripts are
> just making life messy. Will somebody please finish git itself instead
> of working around it, or use a source control system that's up to the
> job.
Your complaing have the same sense as complaining that gcc does not
include functionality of Makefile, because you just can't manage
larger projects without it (or equivalent).
Do one thing, and do it well.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] let core.excludesfile default to ~/.gitignore.
From: Matthieu Moy @ 2009-11-20 13:23 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
It seems this is the value most users set, so let's make it the default.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
A funny experiment:
http://www.google.com/search?q=core.excludesfile+-%22~/.gitignore%22
Results 1 - 10 of about 3,890 for core.excludesfile -"~/.gitignore"
http://www.google.com/search?q=core.excludesfile+%22~/.gitignore%22
Results 1 - 10 of about 7,990 for core.excludesfile "~/.gitignore"
So, most of the time someone mentions core.excludesfile on the web,
~/.gitignore is mentionned right after.
I'd have expected a place near config.c to set the default value for
any config variable, but I can't find such thing, so I guess the
caller is the one that should set the default, which is what I do in
the patch.
Documentation/config.txt | 1 +
dir.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 39d1226..0c55e52 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -384,6 +384,7 @@ core.excludesfile::
of files which are not meant to be tracked. "~/" is expanded
to the value of `$HOME` and "~user/" to the specified user's
home directory. See linkgit:gitignore[5].
+ Default: ~/.gitignore.
core.editor::
Commands such as `commit` and `tag` that lets you edit
diff --git a/dir.c b/dir.c
index d0999ba..dcea6ad 100644
--- a/dir.c
+++ b/dir.c
@@ -914,9 +914,16 @@ void setup_standard_excludes(struct dir_struct *dir)
dir->exclude_per_dir = ".gitignore";
path = git_path("info/exclude");
+ if (!excludes_file) {
+ const char *home = getenv("HOME");
+ char *user_gitignore = malloc(strlen(home) + strlen("/.gitignore") + 1);
+ strcpy(user_gitignore, home);
+ strcat(user_gitignore, "/.gitignore");
+ excludes_file = user_gitignore;
+ }
if (!access(path, R_OK))
add_excludes_from_file(dir, path);
- if (excludes_file && !access(excludes_file, R_OK))
+ if (!access(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
}
--
1.6.5.2.152.gbbe9e
^ permalink raw reply related
* [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-20 13:31 UTC (permalink / raw)
To: git
Hello,
After a long time of silence, here is a brand new version of tig with
changes that has accummulated since version 0.14.1. It mainly brings
minor improvements for tweaking tig usage via keybindings and options.
Thanks to everybody who provided patches.
What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.
- Homepage: http://jonas.nitro.dk/tig/
- Manual: http://jonas.nitro.dk/tig/manual.html
- Tarballs: http://jonas.nitro.dk/tig/releases/
- Git URL: git://repo.or.cz/tig.git
- Gitweb: http://repo.or.cz/w/tig.git
Release notes
-------------
Incompatibilities:
- Setting the cursor color no longer automatically sets the text to
bold. The old 'lazy' behavior was a bug.
- Remove check for git-repo-config, which was officially deprecated in
git version 1.5.4. The configure script no longer depends on git
being installed.
Improvements:
- Provide the manual as a man page named tigmanual(7).
- Add ability to toggle between showing shorter dates (without time
info) and relative dates. Use 'D' to toggle between date formats.
- Show the active (instead of the default) keybindings in the help
view. Furthermore, honor the keymap when suggesting actions in the
help messages.
- Add branch view for choosing which branch to display in the main
view. Bound to 'H' by default.
- Tree view: show entry to parent directory ('..') when running from
subdirectory.
- Tree view: sort entries by name, date or author. Toggling is bound to
'i' by default, with 'I' controlling whether or not to sort in
ascending order.
- Make height of the lower view in a split view configurable by setting
the 'split-view-height' variable to a number or a percentage.
Defaults to 2/3 of the total view height.
- Allow multiple text attributes for color commands:
color cursor white blue underline bold
Bug fixes:
- Blame view: fix loading of blame data when opened from the tree view
and CWD is not the repo root. (Debian bug 540766)
- Tree view: fix searching.
Change summary
--------------
The diffstat and log summary for changes made in this release.
.gitignore | 1 +
INSTALL | 40 +-
Makefile | 13 +-
NEWS | 39 ++
TODO | 3 -
VERSION | 2 +-
configure.ac | 7 -
contrib/aspell.dict | 8 +-
manual.txt | 249 ++++----
tig.1.txt | 2 +-
tig.c | 1549 ++++++++++++++++++++++++++++++-------------
tigmanual.7.txt | 20 +
tigrc.5.txt | 365 +++++------
13 files changed, 1497 insertions(+), 801 deletions(-)
Giuseppe Bilotta (2):
Fix previous/next with branch+main view
Predefined external command: git commit
Ingmar Vanhassel (1):
Makefile: Fix typo in 157ebf54
Jeff King (1):
Add missing NULL in blame_grep
Jonas Fonseca (40):
Add small cache for author names to reduce memory foot-print
Reduce memory and startup time by storing author times as time_t
Simplify searching in view lines by defining grep_text utility
Define a tree_grep and fixing searching
Make the granular allocators more customizable using macros
Remove the need for alloc variables
Define an allocator for run requests
Update the current branch information when reloading all references
Fix a potential problem with reading tokens larger then BUFSIZ
Add primitive branch view
Minor fix to always sort even if allocation fails in get_refs
Use temporary variable in refs loop in main_draw
Branch view: fix loading to handle when two branches have same commit
Add support for sorting tree entries by name, date or author
Add support for sorting branch entries by name, date and author
Fix reloading of references to not cause access to freed memory
Restore the branch view position after refreshing
Add simple support for showing menues and use it for showing option menu
Use menus with the commit subject to present selectable commit parents
Fix memory allocation check in open_commit_parent_menu
Manual: document that :<number> jumps to the line number
Remove macros which are only used for default option values
Allow multiple text attributes for color commands
Build with asciidoc-8.4.5
Show the active (instead of the default) keybindings in the help view
Merge remote branch 'samb/short-dates'
NEWS: Mention date-shorten feature
Add support for displaying relative dates
Fix draw_date to not format anything when time arg is NULL
Fix loading of blame data when opened from the tree view
NEWS: Improve bug fix description
Update asciidoc table syntax to the one supported by version 8.4.4
tigmanual(7): provide the manual as a man page
Remove build dependency on git from the configure script
begin_update: simplify control flow
run_io_dir: take dir argument
run_io_rd_dir: obsolete by switching call sites to run_io_rd_dir
io_open: take path as a vararg format
Status view: special case revert of unmerged entries with no physical file
tig-0.15
Samuel Bronson (1):
Add an option (and toggle) for shortening the date column by skipping the time.
Sebastian Harl (1):
Fixed some uninitialized variable warnings
Tilo Schwarz (1):
Make height of split view configurable
bill lam (1):
Fix whitespace
--
Jonas Fonseca
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-20 13:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20091120133117.GA26917@diku.dk>
On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> Build with asciidoc-8.4.5
..
> Update asciidoc table syntax to the one supported by version 8.4.4
sciidoc -aversion=0.15-dirty -asysconfdir=/usr/etc -b docbook -d manpage tigmanual.7.txt
FAILED: /home/bill/src/tig/manual.txt: line 314: illegal [paradef-default] options: header: header
make: *** [tigmanual.7.xml] Error 1
May be the asciidoc 8.2.7 in debian lenny is not new enough. make install-doc
failed with the above message. Any workaround other than upgrading asciidoc ?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: Name/documentation on git-log --full-diff is insufficient
From: Miklos Vajna @ 2009-11-20 14:01 UTC (permalink / raw)
To: Phil Miller; +Cc: Git Mailing List
In-Reply-To: <81f018ac0911191526o1cfa8e56r79f8db33256a4e9c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Thu, Nov 19, 2009 at 05:26:33PM -0600, Phil Miller <mille121@illinois.edu> wrote:
> PS: I sent in a patch for git-cvsserver a week ago, and have seen no
> response or action on it. Is there something I should have done
> differently?
From MaintNotes:
"If you sent a patch that you did not hear from anybody for three days,
that is a very good indication that it was dropped on the floor ---
please do not hesitate to remind me."
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Name/documentation on git-log --full-diff is insufficient
From: Tim Henigan @ 2009-11-20 14:19 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Phil Miller, Git Mailing List
In-Reply-To: <20091120140138.GB23718@genesis.frugalware.org>
On Fri, Nov 20, 2009 at 9:01 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Nov 19, 2009 at 05:26:33PM -0600, Phil Miller <mille121@illinois.edu> wrote:
>> PS: I sent in a patch for git-cvsserver a week ago, and have seen no
>> response or action on it. Is there something I should have done
>> differently?
>
> From MaintNotes:
>
> "If you sent a patch that you did not hear from anybody for three days,
> that is a very good indication that it was dropped on the floor ---
> please do not hesitate to remind me."
...also as noted in 'Documentation/SubmittingPatches':
- Patches should be placed inline in your email rather than attached.
- Patches should be addressed to both:
* gitster@pobox.com
* git@vger.kernel.org
You should also double-check your patch against the rest of the
guidelines in 'SubmittingPatches', to be sure it will apply cleanly.
^ permalink raw reply
* Re: [PATCH] let core.excludesfile default to ~/.gitignore.
From: Stefan Naewe @ 2009-11-20 14:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git@vger.kernel.org, gitster@pobox.com
In-Reply-To: <1258723430-31684-1-git-send-email-Matthieu.Moy@imag.fr>
On 11/20/2009 2:23 PM, Matthieu Moy wrote:
> It seems this is the value most users set, so let's make it the default.
I like the idea but would suggest to use ~/.gitexcludes instead.
That way it doesn't clash with .gitignore if your $HOME is
under git-control.
Regards
Stefan
--
----------------------------------------------------------------
/dev/random says: INTERLACE: To tie two boots together.
^ permalink raw reply
* Re: [PATCH 0/3] "log --stdin" updates
From: Jeff King @ 2009-11-20 14:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
On Fri, Nov 20, 2009 at 03:25:12AM -0800, Junio C Hamano wrote:
> These three come on top of 61ab67a (Teach --stdin option to "log" family,
> 2009-11-03), which gave "--stdin" to the log family of commands (e.g. log,
> rev-list). The earlier patch allowed you to feed only the revs (which was
> what gitk originally wanted), but after zero or more revs (one rev per
> line), you can now feed a line that consists of "--" and then pathspecs
> (one path per line).
This looks like a good API feature, though I am curious about the
missing "4/3" that was the motivation (of course, with a feature
like this, it may be for your out-of-git script, but as I said, I am
curious :) ). Is it a response to
http://article.gmane.org/gmane.comp.version-control.git/133268
?
The implementation looks good from my cursory reading. Tests and docs
are of course missing. We don't seem to have any rev-list --stdin tests
already. Maybe even something as simple as:
git rev-list HEAD -- file >expect &&
(echo HEAD; echo --; echo file) | git rev-list --stdin >actual &&
test_cmp expect actual
For docs, maybe squash this in (it mentions the pathspecs, but also
loosens --stdin to be available for "git log" and friends, which should
have been part of 61ab67a).
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index bf66116..b44fdd9 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -243,12 +243,14 @@ endif::git-rev-list[]
Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed
on the command line as '<commit>'.
-ifdef::git-rev-list[]
--stdin::
In addition to the '<commit>' listed on the command
- line, read them from the standard input.
+ line, read them from the standard input. If a '--' separator is
+ seen, stop reading commits and start reading paths to limit the
+ result.
+ifdef::git-rev-list[]
--quiet::
Don't print anything to standard output. This form
^ permalink raw reply related
* Re: Default history simplification
From: Jeff King @ 2009-11-20 14:41 UTC (permalink / raw)
To: Tommy Wang; +Cc: git
In-Reply-To: <ae09c2a40911191530y626dd035q90de0212e0b4b6d8@mail.gmail.com>
On Thu, Nov 19, 2009 at 05:30:43PM -0600, Tommy Wang wrote:
> I'm working on a small perl script that needs to reproduce the results
> of the default git history simplification used by log & rev-list when
> a list of paths is given. It is important that I reproduce its
> results exactly. I would love to simply use the rev-list built-in to
> do my work for me; but I fear that I may have much too many path
> limiters than the linux command-line can handle (which if I'm correct,
> can only take so many arguments).
FYI, Junio just posted a patch for handling pathspec limiting over
--stdin, which would solve this problem for you.
http://article.gmane.org/gmane.comp.version-control.git/133333
-Peff
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Dmitry Potapov @ 2009-11-20 15:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: George Dennie, 'Jan Krüger', git
In-Reply-To: <7vmy2h904e.fsf@alter.siamese.dyndns.org>
On Thu, Nov 19, 2009 at 10:33:05PM -0800, Junio C Hamano wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
> > It is more difficult to make this mistake with Git than many others
> > VCSes, because Git shows the list of files that are changed but not
> > committed as well as the list of untracked files when you try to commit
> > something.
>
> Not really in practice. Too many people carry their existing practice of
> using -m to write a useless single liner commit log message that they
> acquired while using their previous SCM.
Well, at least, Git allows to avoid this mistake and produce good commit
messages, but you are right it is difficult to break old bad habits...
> Arguably, useless log messages
> are less of a problem on systems like CVS/SVN because they do not do
> useful log summarization such as "log -- paths..." or "shortlog", so they
> can be excused for learning the practice in the first place, though.
I think quite often commits in CVS/SVN cannot be summarized, because a
single commit often contains what would be a short series of patches in
Git plus a few separated fix-ups that are completely unrelated to the
whole series. It is trivial to split your changes in a few separate
commits in Git, but it is difficult to do that with CVS/SVN.
> That incidentally is exactly why earlier we (mostly me and Linus)
> recommended people not to teach "commit -m" to new people, but of course
> nobody listened ;-).
Those who got used to '-m' in another VCS will quickly find it on their
own... BTW, Git User's Manual uses "git commit -m" 8 times in different
examples, largely to explain what is committed here, and I think it is
similar with other introductions to Git. Though, clearly '-m' is rarely
useful in practice...
Dmitry
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-20 15:55 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091120135004.GA3919@debian.b2j>
On Fri, Nov 20, 2009 at 08:50, bill lam <cbill.lam@gmail.com> wrote:
> On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> Build with asciidoc-8.4.5
> ..
>> Update asciidoc table syntax to the one supported by version 8.4.4
>
> sciidoc -aversion=0.15-dirty -asysconfdir=/usr/etc -b docbook -d manpage tigmanual.7.txt
> FAILED: /home/bill/src/tig/manual.txt: line 314: illegal [paradef-default] options: header: header
> make: *** [tigmanual.7.xml] Error 1
>
> May be the asciidoc 8.2.7 in debian lenny is not new enough. make install-doc
> failed with the above message. Any workaround other than upgrading asciidoc ?
No, not if you want to build the man pages yourself.
How about adding a script or a make rule to optionally install man
pages from the release branch. For example:
install-release-doc-man:
for doc in $(MANDOC); do \
git checkout origin/release $$doc; \
done
$(MAKE) install-doc-man
--
Jonas Fonseca
^ 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