* Re: [PATCH] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 20:06 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <4c70c935ab67266684aa14e38e276795cf1776db.1255337211.git.trast@student.ethz.ch>
Thomas Rast wrote:
> diff --git a/log-tree.c b/log-tree.c
> index 1618f3c..f7d54f2 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
> if (!loaded) {
> loaded = 1;
> for_each_ref(add_ref_decoration, &flags);
> + head_ref(add_ref_decoration, &flags);
> }
> }
Damn, this fails tests and I only just noticed while testing another
series. Sorry for the noise, reroll upcoming...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Supressing sorting of trees
From: Salvatore Mangano @ 2009-10-12 20:02 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90910121236x6bbe258bwa3bc3fdcc54de524@mail.gmail.com>
On Oct 12, 2009, at 3:36 PM, Martin Langhoff wrote:
> On Mon, Oct 12, 2009 at 6:51 PM, Sal Mangano
> <smangano@into-technology.com> wrote:
>> 2) I can use Git unchanged but preserve order by storing some
>> information in
>> each sub tree (e.g. an extra blob) which retains the real order. I
>> can also
>
> This #2 is your best bet by far. An extra blob in each subdir is just
> one option, you can handle this "extra metadata" in a number of ways
> -- maybe external to git, on a separate history will work best.
>
> The downsides of messing with internal tree handling of git are so
> staggering that you'd do better to throw git away.
>
> (this is from experience of abusing git to various purposes that have
> little to do with version control :-) )
>
> In other words: Shaun and Dscho are right, so right that it hurts.
>
Thanks Martin. I suspect you, Shaun and Dscho are correct. But, can
anyone point to specific code
that would allow me to see first hand that this is hopeless. So far,
based on the code I looked at, I see
it as problematic but not hopeless. Here I define "problematic" as
having to change a few files and/or
avoid using some features while "hopeless" meaning I'd have to change
almost very single plumbing
command.
^ permalink raw reply
* Re: Supressing sorting of trees
From: Martin Langhoff @ 2009-10-12 20:24 UTC (permalink / raw)
To: Salvatore Mangano; +Cc: git
In-Reply-To: <DF65B4B0-62B1-4469-99E1-3305434F9D59@into-technology.com>
On Mon, Oct 12, 2009 at 10:02 PM, Salvatore Mangano
<smangano@into-technology.com> wrote:
> point to specific code
Shaun pointed out some very core code. And it is just a core concept.
Just read up on the core organizing concept that is the "tree". Git
relies on the layout of the tree being strictly deterministic.
It is a prevalent assumption in the whole codebase.
Yes you can change it, but assume you will have to audit/rewrite 80%
of the core code.
Want "proof"? Go change it, then try "make test", or reimport a large
repository try to use the git commands over it. We'll relax and watch
the fireworks :-)
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
* [PATCH v2] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 20:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, René Scharfe
In-Reply-To: <200910122206.23044.trast@student.ethz.ch>
'git log --graph --oneline --decorate --all' is a useful way to get a
general overview of the repository state, similar to 'gitk --all'.
Let it indicate the position of HEAD by loading that ref too, so that
the --decorate code can see it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
I wrote:
> Damn, this fails tests and I only just noticed while testing another
> series. Sorry for the noise, reroll upcoming...
log-tree.c | 1 +
t/t4013/diff.log_--decorate=full_--all | 2 +-
t/t4013/diff.log_--decorate_--all | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 1618f3c..f7d54f2 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
if (!loaded) {
loaded = 1;
for_each_ref(add_ref_decoration, &flags);
+ head_ref(add_ref_decoration, &flags);
}
}
diff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all
index 903d9d9..d155e0b 100644
--- a/t/t4013/diff.log_--decorate=full_--all
+++ b/t/t4013/diff.log_--decorate=full_--all
@@ -1,5 +1,5 @@
$ git log --decorate=full --all
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (refs/heads/master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:04:00 2006 +0000
diff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all
index 954210e..fd7c3e6 100644
--- a/t/t4013/diff.log_--decorate_--all
+++ b/t/t4013/diff.log_--decorate_--all
@@ -1,5 +1,5 @@
$ git log --decorate --all
-commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (master)
+commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)
Merge: 9a6d494 c7a2ab9
Author: A U Thor <author@example.com>
Date: Mon Jun 26 00:04:00 2006 +0000
--
1.6.5.62.g4370d.dirty
^ permalink raw reply related
* [PATCH] git: add --no-replace-objects option to disable replacing
From: Christian Couder @ 2009-10-12 20:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jakub Narebski, Johannes Sixt, bill lam, Andreas Schwab
Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.
So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.
For example:
$ git cat-file -p N
would output information about the replacement commit if commit N is
replaced.
With the "--no-replace-objects" option that this patch adds it is
possible to get information about the original commit using:
$ git --no-replace-objects cat-file -p N
While at it, let's add some documentation about this new option in the
"git replace" man page too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-replace.txt | 21 +++++++++++++++++++++
Documentation/git.txt | 6 +++++-
git.c | 4 +++-
t/t6050-replace.sh | 7 +++++++
4 files changed, 36 insertions(+), 2 deletions(-)
Here is a patch with some tests and documentation.
The new option is now called "--no-replace-objects" instead of
"--no-replace".
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index 915cb77..8adc1ef 100644
--- a/Documentation/git-replace.txt
+++ b/Documentation/git-replace.txt
@@ -23,6 +23,26 @@ replacement object.
Unless `-f` is given, the replace reference must not yet exist in
`.git/refs/replace/` directory.
+Replace references will be used by default by all git commands except
+those doing reachability traversal (prune, pack transfer and fsck).
+
+It is possible to disable use of replacement refs for any command
+using the --no-replace-objects option just after "git".
+
+For example if commit "foo" has been replaced by commit "bar":
+
+------------------------------------------------
+$ git --no-replace-object cat-file commit foo
+------------------------------------------------
+
+show information about commit "foo", while:
+
+------------------------------------------------
+$ git cat-file commit foo
+------------------------------------------------
+
+show information about commit "bar".
+
OPTIONS
-------
-f::
@@ -54,6 +74,7 @@ SEE ALSO
--------
linkgit:git-tag[1]
linkgit:git-branch[1]
+linkgit:git[1]
Author
------
diff --git a/Documentation/git.txt b/Documentation/git.txt
index d97aaf5..2f45417 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git' [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
- [-p|--paginate|--no-pager]
+ [-p|--paginate|--no-pager] [--no-replace-objects]
[--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
[--help] COMMAND [ARGS]
@@ -237,6 +237,10 @@ help ...`.
environment is not set, it is set to the current working
directory.
+--no-replace-objects::
+ Do not use replacement refs to replace git objects. See
+ linkgit:git-replace[1] for more information.
+
FURTHER DOCUMENTATION
---------------------
diff --git a/git.c b/git.c
index 9883009..80ebb04 100644
--- a/git.c
+++ b/git.c
@@ -6,7 +6,7 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]\n"
- " [-p|--paginate|--no-pager]\n"
+ " [-p|--paginate|--no-pager] [--no-replace_objects]\n"
" [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]\n"
" [--help] COMMAND [ARGS]";
@@ -87,6 +87,8 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
use_pager = 0;
if (envchanged)
*envchanged = 1;
+ } else if (!strcmp(cmd, "--no-replace-objects")) {
+ read_replace_refs = 0;
} else if (!strcmp(cmd, "--git-dir")) {
if (*argc < 2) {
fprintf(stderr, "No directory given for --git-dir.\n" );
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 8b8bd81..d4818b4 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -70,6 +70,13 @@ test_expect_success 'replace the author' '
git show $HASH2 | grep "O Thor"
'
+test_expect_success 'test --no-replace-objects option' '
+ git cat-file commit $HASH2 | grep "author O Thor" &&
+ git --no-replace-objects cat-file commit $HASH2 | grep "author A U Thor" &&
+ git show $HASH2 | grep "O Thor" &&
+ git --no-replace-objects show $HASH2 | grep "A U Thor"
+'
+
cat >tag.sig <<EOF
object $HASH2
type commit
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: [PATCH v2] Let --decorate show HEAD position
From: Junio C Hamano @ 2009-10-12 21:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, René Scharfe
In-Reply-To: <36861d16d0e21c662430882140893ad9a0b2fb25.1255379242.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> 'git log --graph --oneline --decorate --all' is a useful way to get a
> general overview of the repository state, similar to 'gitk --all'.
> Let it indicate the position of HEAD by loading that ref too, so that
> the --decorate code can see it.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
I think this makes sense.
I see HEAD is given at the front in the sample output, which I think also
makes sense. Is it because it is pushed the last? If so, the same commit
at the tip of branch alpha and beta are decorated with beta and then
alpha, I have to wonder...?
>
> I wrote:
>> Damn, this fails tests and I only just noticed while testing another
>> series. Sorry for the noise, reroll upcoming...
>
>
> log-tree.c | 1 +
> t/t4013/diff.log_--decorate=full_--all | 2 +-
> t/t4013/diff.log_--decorate_--all | 2 +-
> 3 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/log-tree.c b/log-tree.c
> index 1618f3c..f7d54f2 100644
> --- a/log-tree.c
> +++ b/log-tree.c
> @@ -43,6 +43,7 @@ void load_ref_decorations(int flags)
> if (!loaded) {
> loaded = 1;
> for_each_ref(add_ref_decoration, &flags);
> + head_ref(add_ref_decoration, &flags);
> }
> }
>
> diff --git a/t/t4013/diff.log_--decorate=full_--all b/t/t4013/diff.log_--decorate=full_--all
> index 903d9d9..d155e0b 100644
> --- a/t/t4013/diff.log_--decorate=full_--all
> +++ b/t/t4013/diff.log_--decorate=full_--all
> @@ -1,5 +1,5 @@
> $ git log --decorate=full --all
> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (refs/heads/master)
> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, refs/heads/master)
> Merge: 9a6d494 c7a2ab9
> Author: A U Thor <author@example.com>
> Date: Mon Jun 26 00:04:00 2006 +0000
> diff --git a/t/t4013/diff.log_--decorate_--all b/t/t4013/diff.log_--decorate_--all
> index 954210e..fd7c3e6 100644
> --- a/t/t4013/diff.log_--decorate_--all
> +++ b/t/t4013/diff.log_--decorate_--all
> @@ -1,5 +1,5 @@
> $ git log --decorate --all
> -commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (master)
> +commit 59d314ad6f356dd08601a4cd5e530381da3e3c64 (HEAD, master)
> Merge: 9a6d494 c7a2ab9
> Author: A U Thor <author@example.com>
> Date: Mon Jun 26 00:04:00 2006 +0000
> --
> 1.6.5.62.g4370d.dirty
^ permalink raw reply
* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jonathan Nieder, Junio C Hamano, Jens Lehmann, git
In-Reply-To: <20091012143922.GL9261@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Jonathan Nieder <jrnieder@gmail.com> wrote:
>> +valid_ref_normalized 'heads/foo' 'heads/foo'
>> +valid_ref_normalized 'refs///heads/foo' 'refs/heads/foo'
>> +invalid_ref_normalized 'foo'
>> +invalid_ref_normalized 'heads/foo/../bar'
>> +invalid_ref_normalized 'heads/./foo'
>> +invalid_ref_normalized 'heads\foo'
>
> What about '/refs/heads/foo'? Shouldn't that drop the leading /?
>
> I actually had someone enter that into Gerrit Code Review once,
> exposing a bug I have yet to fix that permits that as a valid
> branch name. *sigh*
>
> FWIW, I think this is heading in the right direction. Rather
> than teaching the UIs how clean up a name, give us a tool to
> do the normalization and validation, and let us call it when
> we get user input.
I understand that you prefer the latter between "there is no tool; the
caller is responsibile to make sure it feeds us canonical representation"
and "there is a tool that makes a slightly malformed string into canonical
form for the callers to use before calling us." And that would be my
preference between these two as well.
But that is based on the current behaviour of accepting slightly malformed
and silently making it canonical. If we throw a third alternative,
Jonathan's original patch, that did "we reject malformed string", in the
mix, what would be your preference?
I moderately favour the "tool to canonicalize is given, and it would be a
bug for the caller not to use it" approach this series takes primarily
because that approach won't break scripts that do something like this to
make a new branch, optionally grouped by the owner (e.g. 'sp/smart-http'
or 'next'):
owner=$1 topic=$2
branch=$owner/$topic
git branch "$branch"
This currently works as expected as long as it does not later try to
compare for-each-ref output with "refs/heads/$branch" and expects a match.
With the third approach, the optional username grouping becomes mandatory
for such a script, as 'git branch' will error out. To keep the grouping
still optinal, such a script needs to be written perhaps like:
if test -z "$2"
then
branch="$1"
else
branch="$1/$2"
fi
and that would be a hassle for the scripters, but this _could_ be a kind
of backward incompatible tightening we might want to consider for 1.7.0,
as somebody suggested earlier.
But now I have spelled this out, I do not see much upside for rejecting,
and more importantly, I think it would be an independent issue. We can
reject or just keep normalizing silently, and a tool to show the
normalized name would be useful and necessary regardless of that.
^ permalink raw reply
* Re: quote in help code example
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091012102926.GA3937@debian.b2j>
bill lam <cbill.lam@gmail.com> writes:
> In git man, eg. git help filter-branch
> The code examples for command line or shell scripts inside .ft pairs
> use (smart?) quote instead of single quotes, like
>
> .ft C
> git filter-branch --tree-filter ´rm filename´ HEAD
> .ft
>
> Is this intentional or just some configuration problem during
> compiling.
I see these in Documentation/Makefile:
#
# For asciidoc ...
# -7.1.2, no extra settings are needed.
# 8.0-, set ASCIIDOC8.
#
#
# For docbook-xsl ...
# -1.68.1, set ASCIIDOC_NO_ROFF? (based on changelog from 1.73.0)
# 1.69.0, no extra settings are needed?
# 1.69.1-1.71.0, set DOCBOOK_SUPPRESS_SP?
# 1.71.1, no extra settings are needed?
# 1.72.0, set DOCBOOK_XSL_172.
# 1.73.0-, set ASCIIDOC_NO_ROFF
#
#
# If you had been using DOCBOOK_XSL_172 in an attempt to get rid
# of 'the ".ft C" problem' in your generated manpages, and you
# instead ended up with weird characters around callouts, try
# using ASCIIDOC_NO_ROFF instead (it works fine with ASCIIDOC8).
^ permalink raw reply
* Re: Questions about the new
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Johannes Sixt, git
In-Reply-To: <4AD3619C.6010808@gmail.com>
Sergio Callegari <sergio.callegari@gmail.com> writes:
> If I want to replace some commit X by some commit X' I merely need to
> modify the
> parent information of all the commits that are child of X so that they
> pretend
> to be child of X', or am I missing something?
You need to find all the commits that are child of X in the first place.
What should happen if your colleague has such a commit in his repository
(which you haven't fetched from yet), you enumerated all children of X
known to you in your graft file and then you fetch from him? You need to
enumerate all children of X again to keep the graft file up to date.
> Thanks for the explanation. Can this be made possible for grafts too?
> Wouldn't it be a matter of having history walkers never obey grafts but
> keep track of them (i.e. of the history of the parenthood they
> reference)?
In the past we discussed the possibility of that for quite a while but
never saw a successful implementation. The replace mechanism seemed a
cleaner way to do this, and it turned out to be the case.
You are welcome to try doing that for the grafts, of course.
^ permalink raw reply
* [RFC PATCH 1/5] reflog-walk: refactor the branch@{num} formatting
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
We'll use the same output in an upcoming commit, so refactor its
formatting (which was duplicated anyway) into a separate function.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
reflog-walk.c | 56 ++++++++++++++++++++++++++++++++++----------------------
1 files changed, 34 insertions(+), 22 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 5623ea6..9478dbc 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -241,36 +241,48 @@ void fake_reflog_parent(struct reflog_walk_info *info, struct commit *commit)
commit->object.flags &= ~(ADDED | SEEN | SHOWN);
}
-void show_reflog_message(struct reflog_walk_info *info, int oneline,
+void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return;
+
+ strbuf_addf(sb, "%s@{", commit_reflog->reflogs->ref);
+ if (commit_reflog->flag || dmode) {
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ strbuf_addf(sb, "%s", show_date(info->timestamp,
+ info->tz,
+ dmode));
+ } else {
+ strbuf_addf(sb, "%d", commit_reflog->reflogs->nr
+ - 2 - commit_reflog->recno);
+ }
+
+ strbuf_addch(sb, '}');
+}
+
+void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
- if (info && info->last_commit_reflog) {
- struct commit_reflog *commit_reflog = info->last_commit_reflog;
+ if (reflog_info && reflog_info->last_commit_reflog) {
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
struct reflog_info *info;
+ struct strbuf selector = STRBUF_INIT;
info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ get_reflog_selector(&selector, reflog_info, dmode);
if (oneline) {
- printf("%s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("}: %s", info->message);
+ printf("%s: %s", selector.buf, info->message);
}
else {
- printf("Reflog: %s@{", commit_reflog->reflogs->ref);
- if (commit_reflog->flag || dmode)
- printf("%s", show_date(info->timestamp,
- info->tz,
- dmode));
- else
- printf("%d", commit_reflog->reflogs->nr
- - 2 - commit_reflog->recno);
- printf("} (%s)\nReflog message: %s",
- info->email, info->message);
+ printf("Reflog: %s (%s)\nReflog message: %s",
+ selector.buf, info->email, info->message);
}
+
+ strbuf_release(&selector);
}
}
--
1.6.5.64.g01287
^ permalink raw reply related
* [RFC PATCH 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen, Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <20091012175201.GA10263@coredump.intra.peff.net>
[I forgot to address the list on the first batch, sorry for the spam.]
Jeff King wrote:
> On Mon, Oct 12, 2009 at 05:47:34PM +0200, Jef Driesen wrote:
>
> > Is it possible to make "git stash list" show more than 10 items?
>
> Try "git stash list -30".
>
> Stash listing is internally just "git log -g refs/stash", so you can
> pass any formatting or limiting arguments you want there (see the git
> log documentation for ideas). If no arguments are given, we pass "-10".
This seems fairly arbitrary, doesn't it? My own working theory is
that Nanako put it in because the git-log|sed construct inherently
bars any way to a pager, so it needs to be cut short.
So suppose we could somehow get rid of the |sed... like if we had
--pretty specifiers for the reflog information.
Sadly
git log -g --format="%h %g: %G"
still fails to exactly replicate the reflog format: if the reflog was
cut off during garbage collection, the last entry refers to a no
longer existing commit causing a stray ':' on that line. Oh, well.
It's also still RFC because:
* I don't like the massive code churn in 2/5, maybe someone sees a
better option.
* 5/5 has a pretty lame excuse. I could also just change it in 'git
stash list' to limit the backwards-incompatibility damage, but
that's also a maintenance headache.
Thomas Rast (5):
reflog-walk: refactor the branch@{num} formatting
Introduce new pretty formats %g and %G for reflog information
stash: Use new %g/%G formats instead of sed
stash list: drop the default limit of 10 stashes
stash: change built-in ref to 'stash' instead of 'refs/stash'
archive.c | 2 +-
builtin-branch.c | 3 +-
builtin-checkout.c | 2 +-
builtin-commit.c | 4 +-
builtin-log.c | 2 +-
builtin-merge.c | 2 +-
builtin-rev-list.c | 2 +-
builtin-shortlog.c | 2 +-
builtin-show-branch.c | 2 +-
commit.h | 7 +++-
git-stash.sh | 10 +-----
log-tree.c | 4 +-
pretty.c | 20 +++++++++++--
reflog-walk.c | 72 ++++++++++++++++++++++++++++++++++---------------
reflog-walk.h | 7 +++++
15 files changed, 94 insertions(+), 47 deletions(-)
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0910121237540.2223@dr-wily.mit.edu>
Anders Kaseorg <andersk@MIT.EDU> writes:
> ‘git bisect reset’ could already checkout an arbitrary commit if you
> were on a detached HEAD before starting the bisection. This lets you
> specify an arbitrary commit to ‘git bisect reset <commit>’.
>
> This also provides a way to clean the bisection state without moving
> HEAD: ‘git bisect reset HEAD’.
>
> Signed-off-by: Anders Kaseorg <andersk@mit.edu>
> ---
> git-bisect.sh | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index 6f6f039..d319b9f 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -311,8 +311,7 @@ bisect_reset() {
> }
> case "$#" in
> 0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
> - 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
> - die "$1 does not seem to be a valid branch"
> + 1) git rev-parse --verify "$1^{commit}" || exit
> branch="$1" ;;
> *)
> usage ;;
Thanks.
The "one parameter" case dates back to the original bisect implementation
in commit 8cc6a08 (Making it easier to find which change introduced a bug,
2005-07-30), and the only reason of existence for that case was that the
code looked like this back then:
bisect_reset() {
case "$#" in
0) branch=master ;;
1) test -f "$GIT_DIR/refs/heads/$1" || {
echo >&2 "$1 does not seem to be a valid branch"
exit 1
}
branch="$1" ;;
*)
usage ;;
esac
...
An important difference to notice, compared to a more recent version, is
that we did not remember (nor use) the original branch, and without an
argument we always switched to 'master'. Back then, the user who started
bisecting a side branch needed to remember the name of the branch before
starting the bisection, and needed to give that to the reset subcommand.
Because we remember where we came from these days, I do not think it makes
much sense to even keep this "one parameter" case, let alone extending
this interface to allow switching to an arbitrary commit.
I even think that the support for an explicit branch name in the reset
subcommand should eventually be deprecated, perhaps unless it matches what
is stored in BISECT_START.
The documentation, does not even talk about what the optional <branch>
argument is good for, even though it lists the optional <branch> in the
synopsis section.
Having said all that, four years and two months are looooooong time in git
timescale, and I am discounting, without any evidence to judge either way,
the possibility that people may have learned during that time to (ab)use
this as a (very useful?) shortcut to finish the current bisection and
switch to some entirely different branch.
I offhand do not see a good rationale for such a shortcut to finish bisect
and switch to another branch (IOW, I understand "it is shorter to type",
but I do not see "it is often done and very useful"), but I am open to be
enlightened by a workflow where such a shortcut is useful.
^ permalink raw reply
* [RFC PATCH 3/5] stash: Use new %g/%G formats instead of sed
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
With the new formats, we can rewrite 'git stash list' in terms of an
appropriate pretty format, instead of hand-editing with sed. This has
the advantage that it obeys the normal settings for git-log, notably
the pager.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 4febbbf..8fbf10a 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -205,8 +205,7 @@ have_stash () {
list_stash () {
have_stash || return 0
- git log --no-color --pretty=oneline -g "$@" $ref_stash -- |
- sed -n -e 's/^[.0-9a-f]* refs\///p'
+ git log --format="%g: %G" -g "$@" $ref_stash
}
show_stash () {
--
1.6.5.64.g01287
^ permalink raw reply related
* [RFC PATCH 2/5] Introduce new pretty formats %g and %G for reflog information
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
Add two new pretty escapes: %g expands to the reflog selector (i.e.,
branch@{number} or branch@{date}) and %G expands to the reflog
message.
We use the newly refactored selector formatting function and introduce
another wrapper to get the reflog message.
Unfortunately, we also need to pass down the reflog_walk_info from
show_log(), so this commit touches a lot of (unrelated) callers to
pretty_print_commit() and format_commit_message() to accomodate the
extra argument.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
archive.c | 2 +-
builtin-branch.c | 3 ++-
builtin-checkout.c | 2 +-
builtin-commit.c | 4 ++--
builtin-log.c | 2 +-
builtin-merge.c | 2 +-
builtin-rev-list.c | 2 +-
builtin-shortlog.c | 2 +-
builtin-show-branch.c | 2 +-
commit.h | 7 +++++--
log-tree.c | 4 ++--
pretty.c | 20 +++++++++++++++++---
reflog-walk.c | 16 ++++++++++++++++
reflog-walk.h | 7 +++++++
14 files changed, 58 insertions(+), 17 deletions(-)
diff --git a/archive.c b/archive.c
index 0cc79d2..d325ce3 100644
--- a/archive.c
+++ b/archive.c
@@ -48,7 +48,7 @@ static void format_subst(const struct commit *commit,
strbuf_add(&fmt, b + 8, c - b - 8);
strbuf_add(buf, src, b - src);
- format_commit_message(commit, fmt.buf, buf, DATE_NORMAL);
+ format_commit_message(commit, fmt.buf, buf, DATE_NORMAL, NULL);
len -= c + 1 - src;
src = c + 1;
}
diff --git a/builtin-branch.c b/builtin-branch.c
index 9f57992..d90bfaf 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -388,7 +388,8 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
commit = item->commit;
if (commit && !parse_commit(commit)) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &subject, 0, NULL, NULL, 0, 0);
+ &subject, 0, NULL, NULL, 0, 0,
+ NULL);
sub = subject.buf;
}
diff --git a/builtin-checkout.c b/builtin-checkout.c
index d050c37..b6b9c45 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -303,7 +303,7 @@ static void describe_detached_head(char *msg, struct commit *commit)
{
struct strbuf sb = STRBUF_INIT;
parse_commit(commit);
- pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, 0, NULL, NULL, 0, 0);
+ pretty_print_commit(CMIT_FMT_ONELINE, commit, &sb, 0, NULL, NULL, 0, 0, NULL);
fprintf(stderr, "%s %s... %s\n", msg,
find_unique_abbrev(commit->object.sha1, DEFAULT_ABBREV), sb.buf);
strbuf_release(&sb);
diff --git a/builtin-commit.c b/builtin-commit.c
index 200ffda..d63d467 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -685,7 +685,7 @@ static int message_is_empty(struct strbuf *sb)
commit = get_revision(&revs);
if (commit) {
strbuf_release(&buf);
- format_commit_message(commit, "%an <%ae>", &buf, DATE_NORMAL);
+ format_commit_message(commit, "%an <%ae>", &buf, DATE_NORMAL, NULL);
return strbuf_detach(&buf, NULL);
}
die("No existing author found with '%s'", name);
@@ -943,7 +943,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
if (!log_tree_commit(&rev, commit)) {
struct strbuf buf = STRBUF_INIT;
- format_commit_message(commit, format + 7, &buf, DATE_NORMAL);
+ format_commit_message(commit, format + 7, &buf, DATE_NORMAL, NULL);
printf("%s\n", buf.buf);
strbuf_release(&buf);
}
diff --git a/builtin-log.c b/builtin-log.c
index 25e21ed..57df76e 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -1305,7 +1305,7 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
if (verbose) {
struct strbuf buf = STRBUF_INIT;
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &buf, 0, NULL, NULL, 0, 0);
+ &buf, 0, NULL, NULL, 0, 0, NULL);
printf("%c %s %s\n", sign,
sha1_to_hex(commit->object.sha1), buf.buf);
strbuf_release(&buf);
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..70f1488 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -291,7 +291,7 @@ static void squash_message(void)
strbuf_addf(&out, "commit %s\n",
sha1_to_hex(commit->object.sha1));
pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
- NULL, NULL, rev.date_mode, 0);
+ NULL, NULL, rev.date_mode, 0, NULL);
}
if (write(fd, out.buf, out.len) < 0)
die_errno("Writing SQUASH_MSG");
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 4ba1c12..78659c8 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -98,7 +98,7 @@ static void show_commit(struct commit *commit, void *data)
struct strbuf buf = STRBUF_INIT;
pretty_print_commit(revs->commit_format, commit,
&buf, revs->abbrev, NULL, NULL,
- revs->date_mode, 0);
+ revs->date_mode, 0, NULL);
if (revs->graph) {
if (buf.len) {
if (revs->commit_format != CMIT_FMT_ONELINE)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 4d4a3c8..128b382 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -160,7 +160,7 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
struct strbuf buf = STRBUF_INIT;
pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf,
- DEFAULT_ABBREV, "", "", DATE_NORMAL, 0);
+ DEFAULT_ABBREV, "", "", DATE_NORMAL, 0, NULL);
insert_one_record(log, author, buf.buf);
strbuf_release(&buf);
return;
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index be95930..73ea7ce 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -294,7 +294,7 @@ static void show_one_commit(struct commit *commit, int no_name)
if (commit->object.parsed) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
- &pretty, 0, NULL, NULL, 0, 0);
+ &pretty, 0, NULL, NULL, 0, 0, NULL);
pretty_str = pretty.buf;
}
if (!prefixcmp(pretty_str, "[PATCH] "))
diff --git a/commit.h b/commit.h
index f4fc5c5..93efeeb 100644
--- a/commit.h
+++ b/commit.h
@@ -69,14 +69,17 @@ enum cmit_fmt {
extern char *reencode_commit_message(const struct commit *commit,
const char **encoding_p);
extern void get_commit_format(const char *arg, struct rev_info *);
+struct reflog_walk_info;
extern void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
- enum date_mode dmode);
+ enum date_mode dmode,
+ struct reflog_walk_info *reflog_info);
extern void pretty_print_commit(enum cmit_fmt fmt, const struct commit*,
struct strbuf *,
int abbrev, const char *subject,
const char *after_subject, enum date_mode,
- int need_8bit_cte);
+ int need_8bit_cte,
+ struct reflog_walk_info *reflog_info);
void pp_user_info(const char *what, enum cmit_fmt fmt, struct strbuf *sb,
const char *line, enum date_mode dmode,
const char *encoding);
diff --git a/log-tree.c b/log-tree.c
index 1618f3c..e75f953 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -179,7 +179,7 @@ void get_patch_filename(struct commit *commit, int nr, const char *suffix,
if (commit) {
int max_len = start_len + FORMAT_PATCH_NAME_MAX - suffix_len;
- format_commit_message(commit, "%f", buf, DATE_NORMAL);
+ format_commit_message(commit, "%f", buf, DATE_NORMAL, NULL);
if (max_len < buf->len)
strbuf_setlen(buf, max_len);
strbuf_addstr(buf, suffix);
@@ -408,7 +408,7 @@ void show_log(struct rev_info *opt)
need_8bit_cte = has_non_ascii(opt->add_signoff);
pretty_print_commit(opt->commit_format, commit, &msgbuf,
abbrev, subject, extra_headers, opt->date_mode,
- need_8bit_cte);
+ need_8bit_cte, opt->reflog_info);
if (opt->add_signoff)
append_signoff(&msgbuf, opt->add_signoff);
diff --git a/pretty.c b/pretty.c
index f5983f8..0b67580 100644
--- a/pretty.c
+++ b/pretty.c
@@ -7,6 +7,7 @@
#include "mailmap.h"
#include "log-tree.h"
#include "color.h"
+#include "reflog-walk.h"
static char *user_format;
@@ -443,6 +444,7 @@ struct chunk {
struct format_commit_context {
const struct commit *commit;
enum date_mode dmode;
+ struct reflog_walk_info *reflog_info;
unsigned commit_header_parsed:1;
unsigned commit_message_parsed:1;
@@ -701,6 +703,14 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'd':
format_decoration(sb, commit);
return 1;
+ case 'g': /* reflog handle */
+ if (c->reflog_info)
+ get_reflog_selector(sb, c->reflog_info, c->dmode);
+ return 1;
+ case 'G': /* reflog message */
+ if (c->reflog_info)
+ get_reflog_message(sb, c->reflog_info);
+ return 1;
}
/* For the rest we have to parse the commit header. */
@@ -741,13 +751,15 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void format_commit_message(const struct commit *commit,
const void *format, struct strbuf *sb,
- enum date_mode dmode)
+ enum date_mode dmode,
+ struct reflog_walk_info *reflog_info)
{
struct format_commit_context context;
memset(&context, 0, sizeof(context));
context.commit = commit;
context.dmode = dmode;
+ context.reflog_info = reflog_info;
strbuf_expand(sb, format, format_commit_item, &context);
}
@@ -902,7 +914,8 @@ void pp_remainder(enum cmit_fmt fmt,
void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
struct strbuf *sb, int abbrev,
const char *subject, const char *after_subject,
- enum date_mode dmode, int need_8bit_cte)
+ enum date_mode dmode, int need_8bit_cte,
+ struct reflog_walk_info *reflog_info)
{
unsigned long beginning_of_body;
int indent = 4;
@@ -911,7 +924,8 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
const char *encoding;
if (fmt == CMIT_FMT_USERFORMAT) {
- format_commit_message(commit, user_format, sb, dmode);
+ format_commit_message(commit, user_format, sb, dmode,
+ reflog_info);
return;
}
diff --git a/reflog-walk.c b/reflog-walk.c
index 9478dbc..929f025 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -265,6 +265,22 @@ void get_reflog_selector(struct strbuf *sb,
strbuf_addch(sb, '}');
}
+void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info)
+{
+ struct commit_reflog *commit_reflog = reflog_info->last_commit_reflog;
+ struct reflog_info *info;
+
+ if (!commit_reflog)
+ return;
+
+ info = &commit_reflog->reflogs->items[commit_reflog->recno+1];
+ size_t len = strlen(info->message);
+ if (len > 0)
+ len--;
+ strbuf_add(sb, info->message, len);
+}
+
void show_reflog_message(struct reflog_walk_info *reflog_info, int oneline,
enum date_mode dmode)
{
diff --git a/reflog-walk.h b/reflog-walk.h
index 74c9096..986121f 100644
--- a/reflog-walk.h
+++ b/reflog-walk.h
@@ -3,6 +3,8 @@
#include "cache.h"
+struct reflog_walk_info;
+
extern void init_reflog_walk(struct reflog_walk_info** info);
extern int add_reflog_for_walk(struct reflog_walk_info *info,
struct commit *commit, const char *name);
@@ -10,5 +12,10 @@ extern void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit);
extern void show_reflog_message(struct reflog_walk_info *info, int,
enum date_mode);
+extern void get_reflog_message(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info);
+extern void get_reflog_selector(struct strbuf *sb,
+ struct reflog_walk_info *reflog_info,
+ enum date_mode dmode);
#endif
--
1.6.5.64.g01287
^ permalink raw reply related
* Re: [PATCH 1/2] user-manual: add global config section
From: Junio C Hamano @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Felipe Contreras, git, J. Bruce Fields
In-Reply-To: <20091011222729.GA5114@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> This is very early in the manual, where every word counts. I am not
> very good at wording and do not have any better suggestions, but would
> it be possible to more efficiently convey this:
>
> Git reads its per-user configuration from ~/.gitignore.
>
> That file can also be manipulated with the "git config"
> command, which can be convenient in scripts or when using
> operating systems like Windows where it is not clear where
> the home directory is.
>
> For example, if your terminal supports it, you can tell Git
> to use color in the output for commands such as "git diff"
> with "git config --global color.ui auto".
>
> For more information and a list of possible settings, see
> git-config(1).
The way how the above introduces the "git config" command to people who
see git for the first time makes sense. Unfortunately, --global and
per-user do not "click" together when given in isolation, and I think it
would help if it is explained this way, using a setting that can validly
be either per-user or project specific:
Various configuration variables affect how git operates. Some are
specific to the user (e.g. if you prefer to see the output in colour),
while some are specific to a repository (e.g. what other repositories
it interacts with). Git reads from ~/.gitconfig file to learn your
personal settings and .git/config file of the repository you are
working in to learn the repository settings.
These are plain text files that you can view or edit in your text
editor, but they also can be manipulated with the "git config"
command, which is convenient in scripts or ...
For example, if you want to use a particular e-mail address only while
working in the current repository, you would set "user.email" variable
to that e-mail address in the repository configuration file (i.e.
.git/config) with this command:
git config user.email your@email.address.xz
If on the other hand you want to use the same address for any project
you work with, you can instead set this in your personal configuration
file (i.e. ~/.gitconfig) with this command:
git config --global user.email your@email.address.xz
For more information ...
Since this is an end-user material, I deliberately omitted talking about
the --system (i.e. /etc/gitconfig) in the above.
^ permalink raw reply
* [RFC PATCH 4/5] stash list: drop the default limit of 10 stashes
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
'git stash list' had an undocumented limit of 10 stashes, unless other
git-log arguments were specified. This surprised at least one user,
but possibly served to cut the output below a screenful without using
a pager.
Since the last commit, 'git stash list' will fire up a pager according
to the same rules as the 'git log' it calls, so we can drop the limit.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 8fbf10a..08a7669 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -382,11 +382,6 @@ test -n "$seen_non_option" || set "save" "$@"
case "$1" in
list)
shift
- if test $# = 0
- then
- set x -n 10
- shift
- fi
list_stash "$@"
;;
show)
--
1.6.5.64.g01287
^ permalink raw reply related
* [RFC PATCH 5/5] stash: change built-in ref to 'stash' instead of 'refs/stash'
From: Thomas Rast @ 2009-10-12 21:06 UTC (permalink / raw)
To: Jef Driesen; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
'git stash list' now always shows 'refs/stash@{...}' instead of
'stash@{...}', because that's what we specify for the ref.
Since git checks .git/$ref, .git/refs/$ref and only then
.git/refs/{branches,tags,remotes}, we can drop the prefix. This only
affects people who have .git/stash, who were never able to refer to
their stashes by stash@{...}. (Sadly, now they won't be able to use
git-stash anymore at all.)
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-stash.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 08a7669..8bf464b 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -19,7 +19,7 @@ cd_to_toplevel
TMP="$GIT_DIR/.git-stash.$$"
trap 'rm -f "$TMP-*"' 0
-ref_stash=refs/stash
+ref_stash=stash
if git config --get-colorbool color.interactive; then
help_color="$(git config --get-color color.interactive.help 'red bold')"
--
1.6.5.64.g01287
^ permalink raw reply related
* Re: [PATCH v2] Let --decorate show HEAD position
From: Thomas Rast @ 2009-10-12 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, René Scharfe
In-Reply-To: <7vk4z0e31e.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> I see HEAD is given at the front in the sample output, which I think also
> makes sense. Is it because it is pushed the last? If so, the same commit
> at the tip of branch alpha and beta are decorated with beta and then
> alpha, I have to wonder...?
Indeed. I wrote this off as a lucky coincidence coming from HEAD
sorting before any lowercase letters, but it's exactly as you say:
commit a0f7579d38feb8c4d87282a6cecbc6778908f19f (test-b, test-a, next)
Merge: 01287fd 548bc3a
Author: Thomas Rast <trast@student.ethz.ch>
[...]
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Filesystem has no item: Working copy path [...] does not exist in repository at /usr/bin/git-svn line 3856
From: Daniele Segato @ 2009-10-12 21:26 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List
In-Reply-To: <20091012182018.GA14143@dcvr.yhbt.net>
Il giorno lun, 12/10/2009 alle 11.20 -0700, Eric Wong ha scritto:
> First I thought this was a problem fixed in
> 83c2fcff214fe89649fcd88e095d9961a36b53dd (git v1.6.2 or later),
> but then I tried running it just to make sure.
thank you for taking the time
> This is a namespace conflict, the "trunk" ref is conflicting with a
> (what seems to be a miscreated) branch named "trunk". I anticipated
> this problem originally but figured it was rare/uncommon enough that I
> didn't want to burden users by prefixing all branches with something:
>
> ------------------------------------------------------------------------
> r25364 | michael.hashimoto | 2009-01-21 14:06:53 -0800 (Wed, 21 Jan 2009) | 1 line
> Changed paths:
> A /plugins/branches/trunk
>
> Created directory 'plugins/branches/trunk'.
> ------------------------------------------------------------------------
> r25365 | michael.hashimoto | 2009-01-21 14:07:15 -0800 (Wed, 21 Jan 2009) | 1 line
> Changed paths:
> D /plugins/branches/trunk
>
> Removed plugins/branches/trunk
>
> Since it looks pretty obvious that "trunk" was miscreated here from the
> revision history, you can skip these two revisions in your import by
> recontinuing the clone with "git svn fetch -r25365:HEAD"
I thought it could be a problem like this but I asked before re-fetching
all the repository (just to be sure)..
unfurtunately I already deleted all the .git directory so i'll have to
start again...
> Replace:
> [svn-remote "svn"]
> branches = plugins/branches/*:refs/remotes/svn/*
>
> With:
>
> [svn-remote "svn"]
> branches = plugins/branches/*:refs/remotes/svn/branches/*
>
> I didn't do this by default since I figured very few people would create
> a branch named "trunk" (and those who did, did it accidentally as it
> seems to be the case here).
>
> Hope that helps.
Yes it really help...
But I'll change it like this instead:
[svn-remote "svn"]
url = http://svn.liferay.com/repos/public
fetch = plugins/trunk:refs/remotes/svn/master
branches = plugins/branches/*:refs/remotes/svn/*
I think it will do as long as they didn't created some branch named
"master" :)
In this case the repo was public, what should I do to debug some git-svn
issue like that if I encounter a problem with a non-public repo?
May be there is some debug flag I could enable? Or I had to
guess/explore the svn tree?
thank you Eric
regards,
Daniele
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-12 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5t8coex.fsf@alter.siamese.dyndns.org>
On Mon, 12 Oct 2009, Junio C Hamano wrote:
> I offhand do not see a good rationale for such a shortcut to finish
> bisect and switch to another branch (IOW, I understand "it is shorter to
> type", but I do not see "it is often done and very useful"), but I am
> open to be enlightened by a workflow where such a shortcut is useful.
I agree that ‘git bisect reset <branch>’ is a confusing shortcut. It only
really made sense before Git supported detached HEADs, and you needed to
be on a branch all the time. I think that lifting the arbitrary
restriction to branch names makes it less confusing, but if you want to
remove the argument altogether, that would eliminate the confusion
entirely.
I had in mind only one case where ‘git bisect reset <commit>’ would be
useful. I often don’t even remember what commit I was on before I started
a bisect, much less believe that I want to immediately switch back to it.
I would prefer to be able to clean the bisection state without checking
out another commit at all, because that takes forever and invalidates my
compiled tree. This is what ‘git bisect reset HEAD’ would do if it
worked.
Perhaps it makes sense to add a command that just clears the bisection
state. ‘git bisect stop’?
Anders
^ permalink raw reply
* Re: [RFC PATCH 0/5] Pretty formats for reflog data
From: Jeff King @ 2009-10-12 21:37 UTC (permalink / raw)
To: Thomas Rast; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <cover.1255380039.git.trast@student.ethz.ch>
On Mon, Oct 12, 2009 at 11:02:29PM +0200, Thomas Rast wrote:
> > Stash listing is internally just "git log -g refs/stash", so you can
> > pass any formatting or limiting arguments you want there (see the git
> > log documentation for ideas). If no arguments are given, we pass "-10".
>
> This seems fairly arbitrary, doesn't it? My own working theory is
> that Nanako put it in because the git-log|sed construct inherently
> bars any way to a pager, so it needs to be cut short.
Yes, it's arbitrary, though it is probably a reasonable estimate for the
intended use of stash. It's a stack, so you generally are only
interested in the last couple of entries.
What's much worse though is that the logic is not "if you told me how
many to show, show that; otherwise, show 10". Instead it is "if you
gave me no options, default the size of the list. But if you gave me
any options, even if they have nothing whatsoever to do with limiting
the size of the list, then show all".
So something like "git stash list --date=relative" suddenly shows many more
stashes than just "git stash list". It would be nice to fix that.
> So suppose we could somehow get rid of the |sed... like if we had
> --pretty specifiers for the reflog information.
I'm not sure if people will like having a longer list in a pager than a
shorter list without one (I personally can't remember ever using "git
stash list", so I have no strong opinion).
But certainly the idea of adding pretty format specifiers to access
reflog data seems like a good idea on its own.
-Peff
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Daniele Segato @ 2009-10-12 21:37 UTC (permalink / raw)
To: sylvain; +Cc: git
In-Reply-To: <20091012012826.7sffggwmm8sk0cc8@webmail.demarque.qc.ca>
Il giorno lun, 12/10/2009 alle 01.28 -0400, sylvain@demarque.qc.ca ha
scritto:
> localhost / # git init
I don't see the point of using git on the root directory :)
but that made me think that it could actually be a good idea
for /etc/ :)
I happen to modify some configuration and then I forgot which one... and
sometimes updates broke something
And that make me think of another question...
is there a way to have a git repo for a subset of directory that match a
pattern?
for instance...
can I have a git report of $HOME/.* (without . and ..)? (all user
setting)
Or better: provide a list of directory under $HOME I want to track
Instead of providing the list of directory I want to ignore i would like
to provide the list of the directory and files I want to track :)
I probably am going out of topic here but I hope you forgive me :)
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-12 21:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <alpine.DEB.1.00.0910120941150.4985@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> On Tue, 6 Oct 2009, Euguess@gmail.com wrote:
> > in case if you didn't do that and you try to checkout you will end up
> > having detached HEAD which is quite scary;) for non-experienced user and
> > as i see might lead to some unnecessary questions in this list or on IRC
> > channel...
[...]
> One thing one might add for the technically inclined folks (i.e. those who
> need to implement, and to see that Git is in dear need of some
> user-friendliness first): "git checkout" is a porcelain (i.e. a program
> meant for end-user consumption), and as such should not have a problem to
> react to isatty(0) (i.e. "is the input coming directly from the
> console?").
Sadly git-checkout seems to be stuck between being declared a
porcelain, but at the same time being an extremely important command
for scripts all over. (There are probably others in the same place:
reset comes to mind.)
Your idea is also a backwards incompatible change, so we can just as
well implement the original suggestion and force scripts (or us) to
use some other means when they want to detach. Say, why not just
invent an option along the lines of
git checkout {-d|--detach} $ref
to make it explicit. We have to resort to more arcane means to
*reliably* detach anyway, like 'git checkout master^0'. Then in some
future release, git-checkout will start making DWIM branches if the -d
is not given.
And while we're there, --attach would be a nice complement to force
refs/heads/foo to attach.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Eugene Sajine @ 2009-10-12 21:48 UTC (permalink / raw)
To: Johannes Schindelin, Jakub Narebski; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0910120201350.4985@pacific.mpi-cbg.de>
Hi,
Somebody from development camp recently complained here that there is
no many end users "chiming" about issues in the mailing list. Well,
don't tell i didn't try;)
First I tried to use gitweb.url, gitweb.description and gitweb.owner
files and none of them worked... gitweb is unable to pickup the info
from those files.
Although it successfully interactively picks up info from description
and cloneurl files. I didn't find a substitution for gitweb.owner...
I might be sent to RTFM again, but i would like to bring an attention
to the fact that setting up bare repo with these simplest parameters
as well as setting up gitweb is a USABILITY NIGHTMARE for beginners. I
would even say more: while gitweb is very flexible and powerful, all
its flexibility and power is hidden behind unusable management
interface, which IMHO requires a lot of improvements . Rebuilding to
configure? Perl look-and-feel for configuration variables? I think
this is not the way to configure web applications no matter how smart
and flexible application should be. There are some problems with XML,
I don't care. Let's use simple property file. 1 property file! and let
gitweb read it. don;t like this solution, propose yours..
But leaving the emotions aside and once again -
On Sun, 11 Oct 2009, Jakub Narebski wrote:
>And this would be best left for a custom script creating repositories
>and their git hosting related configuration. Such script of necessity
>would have to be site-specific, or at least contain site-specific
>configuration, like:
>* whether to use gitweb.owner or filesystem uid + GECOS is enough
>* whether to use gitweb.description or description file
>* whether to use gitweb.url, cloneurl file, or let gitweb autogenerate
>clone / fetch URL from base URL
I don't get it. I'm talking specifically about gitweb bundled into git
package by default. It was bundled as i understand to provide full
solution (I don't see any other reason). What the heck is wrong with
continuing to move in this direction? I'm not talking about to enforce
gitweb usage, but just simplify the setup and configuration of a tool
provided by default...
If the user chooses default solution, what is wrong with providing
some usable way of doing things?
Don't want to use git clone, fine. But, please, please save me from
rebuilding gitweb, creating manually those files and putting info
inside... It is 21st century or what?;)
>* gitosis / gitlite configuration, if needed, or setup of public keys
>for SSH authentication
Are they included into git bundle? I didn't see those tools there...
>* project README.html file, if used
>etc.
Yes, I might be stubborn, but is just because i feel that i can
contribute into making git better, although I'm not a developer. And i
think usability is the thing which all beginners would thank you
for... i understand that this issue is not the end of the world and i
will finally overcome the burden, i will develop my script and stuff,
I hope somebody would support me in this:)
Thanks,
Eugene
^ permalink raw reply
* Re: Questions about the new
From: Christian Couder @ 2009-10-12 21:54 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Johannes Sixt, git
In-Reply-To: <4AD3619C.6010808@gmail.com>
On Monday 12 October 2009, Sergio Callegari wrote:
> Thanks Johannes for all the detailed explanations
>
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
[...]
> > With grafts you can only change parenthood; with replace entries you
> > can change parenthood *and* all other aspects of a commit (message,
> > author, committer, dates).
> >
> > Hence, replace entries are more general than grafts.
>
> Limiting the discussion to commit objects, I think there are two
> possible scenarios.
>
> 1) You create new commits objects as needed
> 2) You do not.
>
> If you follow 1), I believe grafts and replace entries have exactly the
> same flexibility.
>
> If I happen not to like commit B in A---B---C and I want A---B'---C
> where B' has
> completely different aspects from B I can either replace B by B' or
> graft away
> B, pretending that the parent of A is B
You mean "pretending that the parent of C is A", right?
> But there are many things that can be done with grafts merely adding a
> graft (e.g. cutting away a part of history, joining history), that
> cannot be done with replace entries without creating new commits objects.
Yes, but when you create a graft, you add a new line in the graft file. You
don't get the grafts for free.
> I was asking because I was wandering whether replace entries were first
> or later
> meant to make grafts deprecated. I hope not, because for a few things
> working on
> arcs seems still nice.
I don't think they will be deprecated soon. And anyway there will probably
be a warning when a graft is used if it is deprecated.
[...]
> > > Conversely, I guess
> > > you can always simulate a replace entry with the graft mechanism,
>
> without the
>
> > > need to add any extra commit object. Am I overlooking something?
> >
> > You cannot; see above.
>
> Well, I meant for what regards commit objects only.
>
> If I want to replace some commit X by some commit X' I merely need to
> modify the
> parent information of all the commits that are child of X so that they
> pretend
> to be child of X', or am I missing something?
If you use git replace you just need to create commit X' and then use "git
replace X X'". If you use grafts, yes, you have to modify the parent
information of all the commits that are child of X.
> > You can even replace tree objects and blob objects
> > using replace entries, IIUC, but you cannot do that with grafts.
>
> Definitely right!
>
> > > 2) Is it currently possible to use a replace entry to replace a
>
> commit object
>
> > > with nothing? Namely if B has A as its sole parent, is it possible
>
> to have a
>
> > > replace entry such as A-sha1 becomes null, to pretend that B is a
>
> hierarchy
>
> > > root?
> >
> > Sure. Just make a commit object that does not have parents.
>
> OK, you need to create a new commit object. At the beginning for some
> reason I
> thought that you could replace an object
> with "nothing" or 00000000000000000000000000000000000000000000
>
> > > 3) If I remember correctly, there was a reason why grafts were not
>
> considered
>
> > > suitable for transferring across repos. Can someone remind me about
>
> it? How
>
> > > does the replace mechanism address this issue?
> >
> > The problem with grafts was that, for example, git-pack-objects
>
> obeyed the
>
> > graft, and could create a broken repository by removing grafted-away
> > objects. And since git-fsck also obeyed the graft, it did not notice
> > the breakage.
> >
> > OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> > never obey replace entries in the history. But they do keep track of
> > them (and the history that they reference) because they are referenced
>
> from the
>
> > refs/replace namespace.
>
> Thanks for the explanation. Can this be made possible for grafts too?
> Wouldn't
> it be a matter of having history walkers never obey grafts but keep track
> of them (i.e. of the history of the parenthood they reference)?
The problem is that grafts are special, so all the history walking commands
should be changed to deal with them specially. With the replace mechanism,
commits and refs are used, and all the commands already know how to deal
with them.
> Like we have "annotated" or heavyweight tags living as objects in the
> database,
> would it be possible or make sense to have annotated grafts or replace
> entries,
> so that one can express why, by whom and when history was changed?
There is a patch series about "notes" floating around that deals with
annotating any commit. So it could be used for that.
And anyway when you create the replacement commit, you can state in the
commit message that it is a replacement commit, who created it, etc.
Regards,
Christian.
^ 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