* 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 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
* [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 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 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
* 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
* 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
* 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: 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
* 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: [RFC/PATCHv8 00/10] git notes
From: Johannes Schindelin @ 2009-11-20 10:36 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Johan Herland, git, spearce
In-Reply-To: <20091120192800.6117@nanako3.lavabit.com>
Hi,
On Fri, 20 Nov 2009, Nanako Shiraishi wrote:
> Quoting Junio C Hamano <gitster@pobox.com>
>
> > So here is what I did tonight.
> >
> > 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?
Maybe it means "go back to the bottom of the old series"? ;-) IIUC it is
the equivalent of
$ git checkout $(git merge-base next jh/notes)
Hth,
Dscho
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Nanako Shiraishi @ 2009-11-20 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, spearce
In-Reply-To: <7vk4xl5y3z.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> So here is what I did tonight.
>
> 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)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Ambiguous ref names
From: Junio C Hamano @ 2009-11-20 10:26 UTC (permalink / raw)
To: Jeenu V; +Cc: git
In-Reply-To: <5195c8760911200218v5b75d690hbaaf00b44c8df6af@mail.gmail.com>
Jeenu V <jeenuv@gmail.com> writes:
> If I've two branches a.b.c and a.b.c.d, why does 'git checkout'
> complains about ambiguous ref names?
Because it doesn't???
: demo; git init
Initialized empty Git repository in /var/tmp/gomi/twelve/.git/
: demo/master; >f
: demo/master; git add f
: demo/master; git commit -a -m 'initial'
[master (root-commit) cb1d5f2] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 f
: demo/master; git branch a.b.c
: demo/master; git branch a.b.c.d
: demo/master; git checkout a.b.c
Switched to branch 'a.b.c'
It could be that you have a tag and a branch that are both named a.b.c,
though.
^ permalink raw reply
* Ambiguous ref names
From: Jeenu V @ 2009-11-20 10:18 UTC (permalink / raw)
To: git
Hi,
I'm re-posting this from the git-users Google Groups:
If I've two branches a.b.c and a.b.c.d, why does 'git checkout'
complains about ambiguous ref names? For example, if I'm in a.b.c.d,
896 $ git checkout a.b.c
warning: refname 'a.b.c' is ambiguous.
Switched to branch "a.b.c"
Is this some kind of a side effect of commit abbreviation? If so is
this kind of branch naming considered unsafe? Is there a way to make
git accept ref names verbatim, even if there's potential operation
that'd fail because of ambiguity?
--
:J
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Johan Herland @ 2009-11-20 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce
In-Reply-To: <7vk4xl5y3z.fsf@alter.siamese.dyndns.org>
On Friday 20 November 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > Here is the 8th iteration of the git-notes series.
>
> Thanks.
>
> While I try my best not to break other people's patches while
> applying, I prefer to see a re-rolled series based on the same commit
> while replacing an existing series, unless the re-roll truly depends
> on the newer base, so that people can more easily see what got
> updated.
Ah, I see. I was thinking I should do the rebase to resolve any
conflicts before sending it to you, but I now see that - in the case
where there are no conflicts - the non-rebased version is actually
preferable. I will try to keep that in mind in the future.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC PATCH] {checkout,reset} -p: make patch direction configurable
From: Štěpán Němec @ 2009-11-20 10:08 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <527e9296b638eb4c9993b3fb0d1c6f51b64f4c2c.1258667920.git.trast@student.ethz.ch>
Hello,
I bet it would get caught in the review process anyway, but just in
case -- a small typo:
> +With 'forward', diffs are taken forward and applied in reverse, i.e.,
> +if you added a block of code you see an addition patch and are asked
> +if you want to remove it. 'reverse' instead shows a removal patch
> +and asks if you to apply it. 'mixed' is the same as 'forward' when
Should be 'asks if you /want/ to apply it.'
Štěpán
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Björn Steinbrink @ 2009-11-20 9:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Abhijit Bhopatkar, git, teamgit
In-Reply-To: <20091120091209.GN17748@machine.or.cz>
On 2009.11.20 10:12:09 +0100, Petr Baudis wrote:
> On Fri, Nov 20, 2009 at 10:05:30AM +0100, Petr Baudis wrote:
> > Hi!
> >
> > On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> > > I plan to do this on LAN using bonjour service discovery
> >
> > I wonder why so much emphasis for this? It seems like a nifty
> > convenience bit, but I don't think making this idea too central is any
> > good. What if you get a second office at the other end of the world?
> > What if part of your team is working on a deployment at customer site?
> > What if part of your team works from home over a VPN? What if your
> > team is collaborating over the internet on an open project? What if...?
> >
> > That said, it sounds like a great idea to have let's say a post-commit
> > hook that will start an upload job:
> >
> > extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
>
> Thanks to sitaram, now I know that probably the best way is:
>
> extbranch="$(whoami)/$(git describe --contains --all HEAD)"
>
> (But now you *really* need to check if HEAD is a heads ref first or you
> will push out to something totally bogus.)
Hm, I'd go for:
$(whoami)/$(git rev-parse --symbolic-full-name HEAD | sed s,refs/heads/,,)
gives the shortname of the checked out branch head, or HEAD when you're
on a detached HEAD.
Bjoern ;-)
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Junio C Hamano @ 2009-11-20 9:44 UTC (permalink / raw)
To: Johan Herland; +Cc: git, spearce
In-Reply-To: <1258681154-2167-1-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Here is the 8th iteration of the git-notes series. Changes in this
> iteration are as follows:
>
> Changes to existing patches:
> - Rebased onto current 'next', dropping the early part of this series
> which has now been merged to 'next'.
> - Patch 8 (was patch 22): Major rewrite of fast-import's notes handling
> code based on comments from Shawn.
>
> New patches:
> - Patch 9: Rename t9301 to t9350, to make room for more fast-import tests
> - Patch 10: More fast-import tests
>
> TODO:
> - Builtin-ify git-notes shell script to take advantage of notes API
> - Garbage collect notes whose referenced object is unreachable (gc_notes())
> - Handle note objects that are not blobs, but trees
Thanks.
While I try my best not to break other people's patches while applying, I
prefer to see a re-rolled series based on the same commit while replacing
an existing series, unless the re-roll truly depends on the newer base, so
that people can more easily see what got updated.
So here is what I did tonight.
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
$ git rebase --onto HEAD next $M
$ N=$(git describe)
Step 2. Compare old and new series
$ git show-branch jh/notes HEAD
$ for i in 7 6 5 4 3 2 1 0
do
git diff jh/notes~$i HEAD~$(( $i + 2 ))
done
$ make -j test
Step 3. Make sure the result is what you intended to feed me.
$ git merge next
$ git diff $M
Step 4. Replace the tip of jh/notes
$ git branch -f jh/notes $N
^ permalink raw reply
* Re: [PATCH v4] git remote: Separate usage strings for subcommands
From: Junio C Hamano @ 2009-11-20 9:36 UTC (permalink / raw)
To: Tim Henigan; +Cc: Nanako Shiraishi, jrnieder, git
In-Reply-To: <32c343770911191058x7be7d34ascc3564064b880213@mail.gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> Using the 'add' subcommand as an example, the desired output is:
>
> Output of 'git remote -h':
> "git remote [-v | --verbose]"
> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
> etc.
>
> Output of 'git remote add -h':
> "git remote add [<options>...] <name> <url>"
> followed by the detailed description given by 'parse_options()'.
>
> Text in 'man git-remote':
> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
> with the options explained in detail later in the file.
>
> Thanks for your patience,
I think the above looks good; thank _you_ for your patience.
I often wonder if we want to add to the parse-options library a function
that takes a "const struct option *" and some other unspecified hints, and
fills a strbuf with a one-line description, e.g.
"[-t <branch>] [-m <master>] [-f] [--mirror]"
I expect we would eventually want to handle something like (this example
is from "git push"):
"[--all | --mirror | --tags] [-n | --dry-run]"
and walking elements in a "struct option" one by one wouldn't give us
enough information to group all/mirror/tags in "one of these" brackets,
and that is what I mean by "some other unspecified hints". Obviously we
could do the "[-n|--dry-run]" with existing information.
A helper function like that may make things a bit easier. parse_options()
may need to take a custom callback function of some sort so that you can
override what parse_options_usage() does when responding to "remote -h"
and generate the list of subcommands and their options on the fly, though.
But that is all outside the scope of this particular patch.
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Petr Baudis @ 2009-11-20 9:12 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, teamgit
In-Reply-To: <20091120090529.GM17748@machine.or.cz>
On Fri, Nov 20, 2009 at 10:05:30AM +0100, Petr Baudis wrote:
> Hi!
>
> On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> > I plan to do this on LAN using bonjour service discovery
>
> I wonder why so much emphasis for this? It seems like a nifty
> convenience bit, but I don't think making this idea too central is any
> good. What if you get a second office at the other end of the world?
> What if part of your team is working on a deployment at customer site?
> What if part of your team works from home over a VPN? What if your
> team is collaborating over the internet on an open project? What if...?
>
> That said, it sounds like a great idea to have let's say a post-commit
> hook that will start an upload job:
>
> extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
Thanks to sitaram, now I know that probably the best way is:
extbranch="$(whoami)/$(git describe --contains --all HEAD)"
(But now you *really* need to check if HEAD is a heads ref first or you
will push out to something totally bogus.)
P.S.: Heh, I would never guess what that git describe command already
does, talk about intuitiveness. ;-) (Of course, when you know exactly
what the switches do, it totally makes sense.)
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Petr Baudis @ 2009-11-20 9:05 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, teamgit
In-Reply-To: <2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com>
Hi!
On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> I plan to do this on LAN using bonjour service discovery
I wonder why so much emphasis for this? It seems like a nifty
convenience bit, but I don't think making this idea too central is any
good. What if you get a second office at the other end of the world?
What if part of your team is working on a deployment at customer site?
What if part of your team works from home over a VPN? What if your
team is collaborating over the internet on an open project? What if...?
That said, it sounds like a great idea to have let's say a post-commit
hook that will start an upload job:
extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
pushurl="$(melting_pot)"
git push --force "$pushurl" "HEAD:$extbranch" >/dev/null &
(untested, +corner cases). On the server side, cronjob or post-update
hook can do the integration testing. The complete setup should be
a matter of few-minutes hack.
Now, it seems totally irrelevant if melting_pot is
melting_pot() { git config teamgit.meltingpot }
or extra code that tries/caches some local discovery first.
P.S.: It's not clear if you want the information sharing with commit
granularity or less - in that case, things might get rather tricky e.g.
if you add new files and don't git add them until right before you
commit, and the work tree state might be total mess anyway.
P.P.S.: It's not clear if you strive after complete de-centralization of
the service, with no central melting pot. That would seem fancy, but
I think rather useless and hard in practice to arrange your reports
that you want, etc. It's not clear again then if the integration testing
should happen on single machine they all vote on (samba-like), or if
all machines should do integration-testing, and whether of all branches
or only some of them, and how to recognize the interesting branches, and
things are getting very hairy already... Your requirements are too
ambiguous.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: Default history simplification
From: Jan Krüger @ 2009-11-20 8:55 UTC (permalink / raw)
To: Tommy Wang; +Cc: git
In-Reply-To: <ae09c2a40911191530y626dd035q90de0212e0b4b6d8@mail.gmail.com>
Hi,
Tommy Wang <subscription@august8.net> wrote:
> [...] 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).
On my system, "only so many arguments" means about two megabytes worth
of command line. On several operating systems, "getconf ARG_MAX" can
tell you the approximate limit (which I think includes the space for
environment variables).
I don't really have any comments about the other things you said.
Jan
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-20 8:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sitaram Chamarty, git
In-Reply-To: <20091120074702.GW12890@machine.or.cz>
Petr Baudis wrote:
> Looks like this suddenly is a very popular area. High competition is good!
Absolutely agreed!
---
Intland
^ permalink raw reply
* Re: [PATCH] submodule.c: Squelch a "use before assignment" warning
From: Junio C Hamano @ 2009-11-20 8:05 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1258680785-42235-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> 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 it around by giving it a fake initialization.
We see the same "fake initialization" of 'left' on the same line. By
initializing it to NULL, you are hinting that initializing 'right' to
NULL actually means something.
> diff --git a/submodule.c b/submodule.c
> index 461faf0..0145a62 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 = NULL;
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Junio C Hamano @ 2009-11-20 8:03 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: git, peff, jaysoffian, drizzd, gitster, spearce
In-Reply-To: <1258680123-28684-2-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
> With smart http, git over http is likely to become much more common.
> To increase testing of smart http, enable the http tests by default.
Sorry, but no test that listens to network ports should be enabled by
default; otherwise it will break automated, unattended tests people have
already set up randomly, depending on when the port happens to be
available for use by the tests.
^ 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