* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Junio C Hamano @ 2006-11-06 22:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611062258.08320.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Here is example code for this:
Ok. The issues I raised in the previous round seem to have been
addressed. Maybe you would want not to use nested 'sub' and it
is good to go, I think.
^ permalink raw reply
* Re: [PATCH] Documentation: Transplanting branch with git-rebase --onto
From: Junio C Hamano @ 2006-11-06 22:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Carl Worth
In-Reply-To: <200611061912.46436.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Added example of transplantig feature branch from one development
> branch (for example "next") into the other development branch (for
> example "master").
>
> [jn: with a little help from Junio]
>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> What about this?
I agree with Carl that the original example of --onto was not
clear why it is a good thing, so I am inclined to follow his
suggestion and drop the original example and keep your second
one yanked from your try#1 patch when committing, if it is Ok
with you.
^ permalink raw reply
* Re: [PATCH] Documentation: Transplanting branch with git-rebase --onto
From: Jakub Narebski @ 2006-11-06 23:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Carl Worth
In-Reply-To: <7v4ptcchli.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Added example of transplantig feature branch from one development
>> branch (for example "next") into the other development branch (for
>> example "master").
>>
>> [jn: with a little help from Junio]
>>
>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>> ---
>> What about this?
>
> I agree with Carl that the original example of --onto was not
> clear why it is a good thing, so I am inclined to follow his
> suggestion and drop the original example and keep your second
> one yanked from your try#1 patch when committing, if it is Ok
> with you.
That's O.K. by me.
Perhaps you can add the info that git-rebase with <branch> argument
switches to given branch (is equivalent to checkout + rebase without
<branch> argument).
P.S. The "transplanting from 'next' to 'master'" example was taken from
your mail, Junio:
Message-ID: <7vlkrfoaky.fsf@assigned-by-dhcp.cox.net>
http://permalink.gmane.org/gmane.comp.version-control.git/22923
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Jakub Narebski @ 2006-11-06 23:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xiochw0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Here is example code for this:
>
> Ok. The issues I raised in the previous round seem to have been
> addressed. Maybe you would want not to use nested 'sub' and it
> is good to go, I think.
Nested sub makes it easy to change gitweb quoting from Character Escape
Codes (CEC) to e.g. Unicode Printable Representation (PR).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Josef Weidendorfer @ 2006-11-06 23:26 UTC (permalink / raw)
To: git
- When requested to checkout read-only remote branches,
we try to create a new local development branch with same name.
- When we branch off a remote branch, set up default merge source.
---
This patch does the sensible thing when the user requests to
check-out a remote read-only branch (eg. origin/master).
It also automatically sets up the default merge source (with remote
entry) for a new branch.
Example to hack on git's next branch:
git-clone --use-separate-remote http://www.kernel.org/pub/scm/git/git.git
cd git
git-checkout origin/next
<hack on next>
git pull (to merge patches from remote 'next')
The checkout creates local branch 'master' to checkout read-only remote branch
'remotes/origin/master'. Additionally, it sets up 'remotes/origin/master' from
remote repository 'origin' as default merge source for the new development branch.
Missing:
- "git branch -D <branch>" should remove remote branch attributes like
"remote" and "merge"
- As "git-clone" already sets up a local development branch "master", it also
should set up a default merge source for it
Josef
git-checkout.sh | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/git-checkout.sh b/git-checkout.sh
index 119bca1..63b622e 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -12,6 +12,8 @@ force=
branch=
newbranch=
newbranch_log=
+remote=
+remotebranch=
merge=
while [ "$#" != "0" ]; do
arg="$1"
@@ -55,6 +57,11 @@ while [ "$#" != "0" ]; do
then
branch="$arg"
fi
+ if git-show-ref --verify --quiet -- "refs/remotes/$arg"
+ then
+ remote=$(echo $arg | sed -ne 's!/.*$!!p')
+ remotebranch=$(echo $arg | sed -e 's!^.*/!!')
+ fi
elif rev=$(git-rev-parse --verify "$arg^{tree}" 2>/dev/null)
then
# checking out selected paths from a tree-ish.
@@ -77,6 +84,20 @@ while [ "$#" != "0" ]; do
esac
done
+# Create a new local branch when checking out remote read-only branch
+if test -z "$newbranch" -a ! -z "$remotebranch"
+then
+ newbranch=$remotebranch
+ if git-show-ref --verify --quiet -- "refs/heads/$newbranch"
+ then
+ echo "Proposed new branch '$newbranch' to checkout read-only remote branch 'remotes/$remote/$remotebranch' exists!"
+ echo "To checkout, specify a new branch name with -b"
+ exit 1
+ fi
+ echo "Creating local branch '$newbranch' to checkout read-only remote branch 'remotes/$remote/$remotebranch'."
+fi
+
+
# The behaviour of the command with and without explicit path
# parameters is quite different.
#
@@ -211,6 +232,14 @@ if [ "$?" -eq 0 ]; then
touch "$GIT_DIR/logs/refs/heads/$newbranch"
fi
git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || exit
+
+ if test '' != "$remote"
+ then
+ echo "Using 'remotes/$remote/$remotebranch' from remote repository '$remote' as default merge source."
+ git-repo-config branch."$newbranch".remote "$remote"
+ git-repo-config branch."$newbranch".merge "remotes/$remote/$remotebranch"
+ fi
+
branch="$newbranch"
fi
[ "$branch" ] &&
--
1.4.3.rc2.gf8ffb
^ permalink raw reply related
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Josef Weidendorfer @ 2006-11-06 23:30 UTC (permalink / raw)
To: git
In-Reply-To: <200611070026.16425.Josef.Weidendorfer@gmx.de>
Oops.
Corrections in example:
On Tuesday 07 November 2006 00:26, Josef Weidendorfer wrote:
> Example to hack on git's next branch:
>
> git-clone --use-separate-remote http://www.kernel.org/pub/scm/git/git.git
> cd git
> git-checkout origin/next
> <hack on next>
> git pull (to merge patches from remote 'next')
>
> The checkout creates local branch 'master' to checkout read-only remote branch
^ next
> 'remotes/origin/master'. Additionally, it sets up 'remotes/origin/master' from
^next ^next
> remote repository 'origin' as default merge source for the new development branch.
^ permalink raw reply
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Jakub Narebski @ 2006-11-07 0:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt68b0f3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> Here is example code for this:
>>>
>>> Ok. The issues I raised in the previous round seem to have been
>>> addressed. Maybe you would want not to use nested 'sub' and it
>>> is good to go, I think.
>>
>> Nested sub makes it easy to change gitweb quoting from Character Escape
>> Codes (CEC) to e.g. Unicode Printable Representation (PR).
>
> Yes, sub makes it easy, it is not needed to be nested.
Well, this sub is of no use (I think) ourside esc_path subroutine.
Similarly for unq sub nested in unescape in PATCH 1/10.
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Junio C Hamano @ 2006-11-07 0:13 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200611070026.16425.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> Example to hack on git's next branch:
>
> git-clone --use-separate-remote http://www.kernel.org/pub/scm/git/git.git
> cd git
> git-checkout origin/next
> <hack on next>
> git pull (to merge patches from remote 'next')
>
> The checkout creates local branch 'next' to checkout read-only
> remote branch 'remotes/origin/next'. Additionally, it sets up
> 'remotes/origin/next' from remote repository 'origin' as
> default merge source for the new development branch.
I am disturbed by an inconsistency here.
> + if git-show-ref --verify --quiet -- "refs/heads/$newbranch"
> + then
> + echo "Proposed new branch '$newbranch' to checkout...
> + echo "To checkout, specify a new branch name with -b"
> + exit 1
> + fi
This logic is guarding against already having a local branch
that is called 'next', and that is why the "Proposed new branch"
message needs to be there. One explanation of why 'next' exists
in the local branch namespace in the first place is probably
there are other remote branches than origin that have 'next' and
the user previously checked it out. Or perhaps the user has
already done this "checkout origin/next" once already.
I wonder if it is more consistent and easy to use to just make
this:
git checkout origin/next
a synonym to:
git checkout -b origin/next remotes/origin/next
when remotes/origin/next exists and heads/origin/next does not.
Then "git checkout origin/next" would always mean "I want to
switch to the branch I use to hack on the branch 'next' Junio
has". Do it once and you will get exactly my tip, hack on it,
switch out of it and then do it again and you won't lose your
previous work but just switch to that branch.
That is, something like this...
---
diff --git a/git-checkout.sh b/git-checkout.sh
index 119bca1..f6486c6 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -4,6 +4,16 @@ USAGE='[-f] [-b <new_branch>] [-m] [<bra
SUBDIRECTORY_OK=Sometimes
. git-sh-setup
+# Automatic forking of local branch based on remote
+if test $# = 1 &&
+ git show-ref --verify --quiet -- "refs/remotes/$1" &&
+ ! git show-ref --verify --quiet -- "refs/heads/$1"
+then
+ set x -b "$1" "remotes/$1"
+ echo >&2 "* Forking local branch $1 off of remotes/$1..."
+ shift
+fi
+
old_name=HEAD
old=$(git-rev-parse --verify $old_name 2>/dev/null)
new=
^ permalink raw reply related
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Josef Weidendorfer @ 2006-11-07 1:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd580azbb.fsf@assigned-by-dhcp.cox.net>
On Tuesday 07 November 2006 01:13, Junio C Hamano wrote:
> I wonder if it is more consistent and easy to use to just make
> this:
>
> git checkout origin/next
>
> a synonym to:
>
> git checkout -b origin/next remotes/origin/next
>
> when remotes/origin/next exists and heads/origin/next does not.
Interesting.
I wonder how often there is a real need for that long branch names.
IMHO this convenience behavior of git-checkout should target
the majority of possible use cases. Is it really better to default
to long branch names instead of asking for explicit branch name
in the rare case of conflict (ie. multiple remote repositories with
same branch names and you want to develop on both these branches
locally)?
Suppose developer2 uses this scheme, and has a local development
branch "junio/next", which is based on your "next" branch.
Now I want to work on the "next" branch of developer2, getting
a local branch name "developer2/junio/next".
> Then "git checkout origin/next" would always mean "I want to
> switch to the branch I use to hack on the branch 'next' Junio
> has". Do it once and you will get exactly my tip, hack on it,
> switch out of it and then do it again and you won't lose your
> previous work but just switch to that branch.
Ah, now I understand your thinking.
I admit it has a compelling elegance.
However.
Would it not be confusing for newbies (and not only for them) to
first reference the remote branch with "origin/next", and afterwards, you
get your own development branch by using the exactly same name?
IMHO this kind of aliasing is awkward. When you want to start another
topic branch on the remote branch, or want to reference the remote
branch for diffs, you have to explicitly specify "remotes/origin/next",
making for more typing.
> That is, something like this...
>
> ---
>
> diff --git a/git-checkout.sh b/git-checkout.sh
> index 119bca1..f6486c6 100755
> --- a/git-checkout.sh
> +++ b/git-checkout.sh
> @@ -4,6 +4,16 @@ USAGE='[-f] [-b <new_branch>] [-m] [<bra
> SUBDIRECTORY_OK=Sometimes
> . git-sh-setup
>
> +# Automatic forking of local branch based on remote
> +if test $# = 1 &&
> + git show-ref --verify --quiet -- "refs/remotes/$1" &&
> + ! git show-ref --verify --quiet -- "refs/heads/$1"
> +then
> + set x -b "$1" "remotes/$1"
> + echo >&2 "* Forking local branch $1 off of remotes/$1..."
> + shift
> +fi
I didn't know about "set x" before.
Thanks, you never end learning :-)
"git-checkout remotes/origin/next" does not work as expected,
and if fixed, it still should guard against an existing
local branch "origin/next", don't you think?
(Ok, it does not work in my patch, too.)
What do you think about the setup of the default for "git-pull"?
^ permalink raw reply
* [PATCH] git-pickaxe: -L /regexp/,/regexp/
From: Junio C Hamano @ 2006-11-07 1:57 UTC (permalink / raw)
To: git; +Cc: pasky
With this change, you can specify the beginning and the ending
line of the range you wish to inspect with pattern matching.
For example, these are equivalent with the git.git sources:
git pickaxe -L 7,21 v1.4.0 -- commit.c
git pickaxe -L '/^struct sort_node/,/^}/' v1.4.0 -- commit.c
git pickaxe -L '7,/^}/' v1.4.0 -- commit.c
git pickaxe -L '/^struct sort_node/,21' v1.4.0 -- commit.c
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Pasky, the other day I overheard that you were moaning about
git-annotate using -S to mean something other than pickaxe,
and git-pickaxe needed to stay compatible with it. I think
this is a better way to do what you wanted.
builtin-pickaxe.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++-------
1 files changed, 90 insertions(+), 13 deletions(-)
diff --git a/builtin-pickaxe.c b/builtin-pickaxe.c
index f45edbd..007b1b8 100644
--- a/builtin-pickaxe.c
+++ b/builtin-pickaxe.c
@@ -17,6 +17,7 @@
#include <time.h>
#include <sys/time.h>
+#include <regex.h>
static char pickaxe_usage[] =
"git-pickaxe [-c] [-l] [-t] [-f] [-n] [-p] [-L n,m] [-S <revs-file>] [-M] [-C] [-C] [commit] [--] file\n"
@@ -1533,6 +1534,85 @@ static const char *add_prefix(const char
return prefix_path(prefix, strlen(prefix), path);
}
+static const char *parse_loc(const char *spec,
+ struct scoreboard *sb, long lno,
+ long begin, long *ret)
+{
+ char *term;
+ const char *line;
+ long num;
+ regex_t regexp;
+
+ num = strtol(spec, &term, 10);
+ if (term != spec) {
+ *ret = num;
+ return term;
+ }
+
+ if (spec[0] != '/')
+ return spec;
+
+ /* it could be a regexp of form /.../ */
+ for (term = (char*) spec + 1; *term && *term != '/'; term++) {
+ if (*term == '\\')
+ term++;
+ }
+ if (*term != '/')
+ return spec;
+ /* try [spec+1 .. term-1] as regexp */
+ *term = 0;
+ if (regcomp(®exp, spec + 1, REG_NEWLINE)) {
+ /* not a regexp */
+ error_return:
+ regfree(®exp);
+ *term = '/';
+ return spec;
+ }
+
+ /* Now find the first line that matches the regexp, after
+ * line "begin" in sb->final_buf.
+ */
+ while (begin < lno) {
+ char *nline;
+ int hit;
+
+ begin++;
+ line = nth_line(sb, begin);
+ if (begin < lno) {
+ nline = (char*) nth_line(sb, begin+1);
+ nline[-1] = 0;
+ }
+ hit = regexec(®exp, line, 0, NULL, 0);
+ if (begin < lno)
+ nline[-1] = '\n';
+ if (!hit) {
+ /* lines count from 1 in UI terms */
+ *ret = begin + 1;
+ regfree(®exp);
+ *term++ = '/';
+ return term;
+ }
+ }
+ goto error_return;
+}
+
+static void prepare_blame_range(struct scoreboard *sb,
+ const char *bottomtop,
+ long lno,
+ long *bottom, long *top)
+{
+ const char *term;
+
+ term = parse_loc(bottomtop, sb, lno, 0, bottom);
+ if (*term == ',') {
+ term = parse_loc(term + 1, sb, lno, *bottom + 1, top);
+ if (*term)
+ usage(pickaxe_usage);
+ }
+ if (*term)
+ usage(pickaxe_usage);
+}
+
int cmd_pickaxe(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
@@ -1547,11 +1627,11 @@ int cmd_pickaxe(int argc, const char **a
const char *revs_file = NULL;
const char *final_commit_name = NULL;
char type[10];
+ const char *bottomtop = NULL;
save_commit_buffer = 0;
opt = 0;
- bottom = top = 0;
seen_dashdash = 0;
for (unk = i = 1; i < argc; i++) {
const char *arg = argv[i];
@@ -1578,7 +1658,6 @@ int cmd_pickaxe(int argc, const char **a
blame_copy_score = parse_score(arg+2);
}
else if (!strncmp("-L", arg, 2)) {
- char *term;
if (!arg[2]) {
if (++i >= argc)
usage(pickaxe_usage);
@@ -1586,18 +1665,9 @@ int cmd_pickaxe(int argc, const char **a
}
else
arg += 2;
- if (bottom || top)
+ if (bottomtop)
die("More than one '-L n,m' option given");
- bottom = strtol(arg, &term, 10);
- if (*term == ',') {
- top = strtol(term + 1, &term, 10);
- if (*term)
- usage(pickaxe_usage);
- }
- if (bottom && top && top < bottom) {
- unsigned long tmp;
- tmp = top; top = bottom; bottom = tmp;
- }
+ bottomtop = arg;
}
else if (!strcmp("--score-debug", arg))
output_option |= OUTPUT_SHOW_SCORE;
@@ -1758,6 +1828,13 @@ int cmd_pickaxe(int argc, const char **a
num_read_blob++;
lno = prepare_lines(&sb);
+ bottom = top = 0;
+ if (bottomtop)
+ prepare_blame_range(&sb, bottomtop, lno, &bottom, &top);
+ if (bottom && top && top < bottom) {
+ long tmp;
+ tmp = top; top = bottom; bottom = tmp;
+ }
if (bottom < 1)
bottom = 1;
if (top < 1)
--
1.4.3.4.g9f05
^ permalink raw reply related
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Junio C Hamano @ 2006-11-07 2:03 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200611070225.24956.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> What do you think about the setup of the default for "git-pull"?
I personally feel that is loading "checkout" with too many
different things.
It might be easier to maintain in the long term to have a helper
command 'git-fork' to handle the gory details of forking off
from an existing branch (merge default setting, branch creation,
what else will we have next month? ;-) and perhaps automatically
call it from git-checkout as a short-hand.
^ permalink raw reply
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Junio C Hamano @ 2006-11-07 2:08 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <7vd5809fnh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
>> What do you think about the setup of the default for "git-pull"?
>
> I personally feel that is loading "checkout" with too many
> different things.
>
> It might be easier to maintain in the long term to have a helper
> command 'git-fork' to handle the gory details of forking off
> from an existing branch (merge default setting, branch creation,
> what else will we have next month? ;-) and perhaps automatically
> call it from git-checkout as a short-hand.
Ah, one should never open one's mouth before thinking things
twice and then sleeping on it.
I do not think we want a _new_ command. It may make sense to
enrich 'git-branch' for that.
If "git-checkout -b" does not use 'git-branch' to create a new
branch in the current code, maybe we should, regardless of the
usability enhancements under discussion.
^ permalink raw reply
* Re: how to show log for only one branch
From: Liu Yubao @ 2006-11-07 2:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslgwcueo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Liu Yubao <yubao.liu@gmail.com> writes:
>
>> ... For example, I want to know what happened in your
>> git's "next" branch, I hope to get logs like this:
>> Merge branch 'jc/pickaxe' into next
>> Merge branch 'master' into next
>> Merge branch 'js/modfix' into next
>> ...
>> some good work
>> ...
>> Merge branch ....
>>
>> I just want to *outline* what happened in "next" branch, if I am interested
>> in what have been merged from 'jc/pickaxe' I can follow the merge point again
>> or use something like "git log --follow-all-parents".
>
> My "next" is a bad example of this, because it is an integration
> branch and never gets its own development. It is also a bad
> example because I can answer that question with this command
> line:
>
> git log --grep='^Merge .* into next$' next
>
> and while it is a perfectly valid answer, I know it would leave
> you feeling somewhat cheated.
>
smart trick, but if the logs aren't consistent enough it's hard to
grep them out.
^ permalink raw reply
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Junio C Hamano @ 2006-11-07 2:27 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200611070225.24956.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> Then "git checkout origin/next" would always mean "I want to
>> switch to the branch I use to hack on the branch 'next' Junio
>> has". Do it once and you will get exactly my tip, hack on it,
>> switch out of it and then do it again and you won't lose your
>> previous work but just switch to that branch.
>
> Ah, now I understand your thinking.
> I admit it has a compelling elegance.
>
> However.
> Would it not be confusing for newbies (and not only for them) to
> first reference the remote branch with "origin/next", and afterwards, you
> get your own development branch by using the exactly same name?
When we get these per-branch attributes used widely enough, we
might add new vocabulary to our extended sha1 expressions that
denotes "the branch I forked this branch off of".
If refs/heads/next is created from refs/remotes/origin/next,
perhaps with an updated git-branch command that knows how to
help set things up, we might want to be able to refer to
remotes/origin/next as "next's upstream". While we are on
'next' branch, we might want to refer to "HEAD's upstream".
I am not sure what the syntax for that should be, though.
Perhaps "HEAD@upstream"?
Unlike the regular extended sha1 expression modifiers such as
name~n, name^n, and name^{type}, it does not work with arbitrary
object name; it can only work with a refname. Which is similar
to the '@{time}' notation we added when we started using
ref-log. Strictly speaking these should not belong to the sha1
naming layer, but we can have them anyway for the user's
convenience.
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Liu Yubao @ 2006-11-07 3:26 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <454F3BED.9010401@op5.se>
Andreas Ericsson wrote:
> Liu Yubao wrote:
>
> If "fake" commits (i.e., commits that doesn't change any content) are
> introduced for each merge, it will change the ancestry graph and the
> resulting tree(s) won't be mergable with the tree it merged with,
> because each such "back-merge" would result in
> * the "fake" commit becoming part of history
> * a new "fake" commit being introduced
>
> Consider what happens when Alice pulls in Bob's changes. The merge-base
> of Bob's tip is where Alice HEAD points to, so it results in a
> fast-forward, like below.
>
> a---b---c---d <--- Alice
> \
> e---f---g <--- Bob
>
>
> If, we would have created a fake commit instead, Alice would get a graph
> that looks like so:
>
> a---b---c---d-----------h <--- Alice
> \ /
> e---f---g <--- Bob
>
>
> Now, we would have two trees that are identical, because the merge can't
> cause conflicts, but Alice and Bob will have reached it in two different
> ways. When Bob decides he wants to go get the changes Alice has done,
> his tree will look something like this:
>
> a---b---c---d-----------h <--- Alice
> \ / \
> e---f---g---i <--- Bob
>
>
> He finds it odd that he's got two commits that, when checked out, lead
> to the exact same tree, so he asks Alice to get his tree and see what's
> going on. Alice will then end up with this:
>
> a---b---c---d-----------h---j <--- Alice
> \ / \ /
> e---f---g---i <--- Bob
>
>
> Now there's four commits that all point to identical trees, but the
> ancestry graphs differ between all developers. In the case above,
> there's only two people working at the same project. Imagine the amount
> of empty commits you'd get in a larger project, like the Linux kernel.
>
Oh, you remind me, but I have a naive solution for this problem: print
a hint and don't merge commits that contain fake commit, then I know I have
reached a stable merge point and have same tree with others.
We create a fake commit for fast forwarding style merge, this fake commit
is used to record the track of a branch, so we can always follow HEAD^1
to travel through the history of a branch. In fact, git pays more attention
to the history of *data modification* than history of *operation*, that is
right the subtle difference between content tracker and VCS, latter's branch
has more information(useful information, I think).
Even if no fake commit is created as git does now, there can be multiple
commits with identical tree object, and git can't prevent you from merging
two commits with identical tree object, it just creates an ancestry relation
to remember the merge point.
As git(7) says:
The "commit" object is an object that introduces the notion
of history into the picture. In contrast to the other objects,
it doesn't just describe the physical state of a tree, it
describes how we got there, and why.
So it's clearer to describe a revision graph with nodes for tree
objects and edges for commit objects(multiple edges for a merge
commit object, I know this will break your habit:-).
> Fast-forward is a Good Thing and the only sensible thing to do in a
> system designed to be fully distributed (i.e., where there isn't
> necessarily any middle point with which everybody syncs), while scaling
> beyond ten developers that merge frequently between each other.
>
>> If we throw away all compatibility, efficiency, memory and disk
>> consumption
>> problems,
>> (1) we can get the track of a branch without reflog because HEAD^1 is
>> always the tip of target branch(or working branch usually) before
>> merging.
>>
>> (2) with the track, branch mechanism in git is possibly easier to
>> understand,
>> especially for newbies from CVS or Subversion, I really like git's
>> light weight, simple but powerful design and great efficiency, but I
>> am really
>> surprised that 'git log' shows logs from other branches and a side
>> branch can become part of main line suddenly.
>>
>> A revision graph represents fast forwarding style merging like this:
>>
>> (fast forwarding)
>> ---- a ............ * ------> master
>> \ /
>> b----------c -----> test (three commits with three trees)
>>
>> can be changed to:
>>
>> ---- a (tree_1) ----------- d (tree_3) ------> master
>> \ /
>> b (tree_2) ------- c (tree_3) ----> test
>> (four commits with three trees, it's normal as more than one way can
>> reach Rome :-)
>>
>
> That's where our views differ. In my eyes, "d" and "c" are exactly
> identical, and I'd be very surprised if the scm tried to tell me that
> they aren't, by not giving them the same revid.
It doesn't matter, they have same tree, and it's normal too in git
multiple commits have same tree, if you use nodes for tree state,
that graph will be simple to understand:
a d
-----tree_1 -------------- tree_3 ----> master
\ / \
\ b d/c `-----> test
\ /
`--- tree_2 ---'
This is the familiar way we used in CVS, I believe there are more
than one people confused by fast forwarding style merge and 'git log'
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit
From: Liu Yubao @ 2006-11-07 3:42 UTC (permalink / raw)
To: git
In-Reply-To: <20061106133923.GB1151@robert.daprodeges.fqdn.th-h.de>
Rocco Rutte wrote:
> Hi,
>
> * Liu Yubao [06-11-06 21:00:07 +0800] wrote:
>
>> Then, what bad *logical* problem will happen if a merging that is
>> really a fast forwarding creates a new commit?
>
> I don't know what you expect by "logical" nor if I get you right, but if
> fast-forward merge a branch to another one, both branches now have
> exactly the same hash. If you create a commit object for a fast-forward
> merge, both tip hashes not identical anymore... which is bad.
Not so bad, you can know they point to same tree objects.
Fast forwarding style merge will blow away the *track* of your branch,
and this track is useful, that is why reflog appears.
>
> The identical hash important so that you really know they're identical
> and for future reference like ancestry.
I guess you have mixed identical commits with identical trees. Trees
is what we really need.
Fake commit doesn't mess the ancestry relation, you can refer to
my previous mail replied to Andreas Ericsson in this topic.
>
> bye, Rocco
^ permalink raw reply
* Re: how to show log for only one branch
From: Liu Yubao @ 2006-11-07 3:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eink3u$pmh$1@sea.gmane.org>
Jakub Narebski wrote:
> Perhaps what you want is git log --committer=<owner of repo>?
>
Thanks, it can't meet my requirement, if I create two branches
and merge them, I can't easily tell the track of those two branches.
^ permalink raw reply
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Karl Hasselström @ 2006-11-07 6:54 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Junio C Hamano, git
In-Reply-To: <200611070225.24956.Josef.Weidendorfer@gmx.de>
On 2006-11-07 02:25:24 +0100, Josef Weidendorfer wrote:
> On Tuesday 07 November 2006 01:13, Junio C Hamano wrote:
>
> > Then "git checkout origin/next" would always mean "I want to
> > switch to the branch I use to hack on the branch 'next' Junio
> > has". Do it once and you will get exactly my tip, hack on it,
> > switch out of it and then do it again and you won't lose your
> > previous work but just switch to that branch.
>
> Ah, now I understand your thinking. I admit it has a compelling
> elegance.
I agree. The name is slightly longer than necessary in the common case
of only one remote repository, but the reduction of newbie confusion
will be worth it. (Non-newbies know how to give the branch any name
they want.)
> However. Would it not be confusing for newbies (and not only for
> them) to first reference the remote branch with "origin/next", and
> afterwards, you get your own development branch by using the exactly
> same name?
Not necessarily. As long as they know that there are two kinds of
branches, remote and local, it should be perfectly obvious. You check
out and modify your local copy of a remote branch, and occasionally
pull updates from the remote branch. If there is no local branch
corresponding to a certain remote branch, git will make one for you.
> IMHO this kind of aliasing is awkward. When you want to start
> another topic branch on the remote branch, or want to reference the
> remote branch for diffs, you have to explicitly specify
> "remotes/origin/next", making for more typing.
Having more than one local branch for a remote branch is advanced
enough that the user should know how to create branches with any name
they choose.
But I do agree that calling it "origin/next" the first time you
branch, and "remotes/origin/next" subsequent times, is nonintuitive.
However, this could be solved by the following message being printed
the first time:
$ git checkout origin/next
No local branch "origin/next" exists. Creating new local branch
"origin/next" off of remote branch "remotes/origin/next".
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* [PATCH 0/2] Generate saner automatic patch names
From: Karl Hasselström @ 2006-11-07 6:57 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
This series fixes some quirks in the automatic patch name generation.
In particular, it limits the length of names, and makes sure that all
callers generate unique names so that name clashes won't be a problem.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* [PATCH 1/2] Generate shorter patch names
From: Karl Hasselström @ 2006-11-07 6:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061107065710.10728.85618.stgit@localhost>
From: Karl Hasselström <kha@treskal.com>
Not all commits are blessed with a really short first-line summary in
their commit messages. This means that we shouldn't blindly take the
entire first line of the comment, since that sometimes results in
truly spectacular patch names.
I chose 30 characters as a reasonable value, considering that we don't
yet have any tab-completion on patch names. There's probably not much
point in making it configurable.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/common.py | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 88b1b94..0e1bb44 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -286,10 +286,10 @@ def name_email_date(address):
def make_patch_name(msg):
"""Return a string to be used as a patch name. This is generated
- from the top line of the string passed as argument.
- """
+ from the first 30 characters of the top line of the string passed
+ as argument."""
if not msg:
return None
- subject_line = msg.lstrip().split('\n', 1)[0].lower()
+ subject_line = msg[:30].lstrip().split('\n', 1)[0].lower()
^ permalink raw reply related
* [PATCH 2/2] Generate unique patch names
From: Karl Hasselström @ 2006-11-07 6:59 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061107065710.10728.85618.stgit@localhost>
From: Karl Hasselström <kha@treskal.com>
"stg assimilate" was already making sure that automatically generated
patch names were non-empty and unique, by suffixing them with a dash
and a number if necessary. This patch moves that functionality into
the autogeneration function itself, so that all its callers can
benefit from it (and the user can benefit from uniform behavior from
all stgit commands).
As an added bonus, this permits the removal of a number of checks that
would abort with an error if the automatically generated name was
empty.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/commands/assimilate.py | 9 +--------
stgit/commands/common.py | 16 +++++++++++++++-
stgit/commands/imprt.py | 4 +---
stgit/commands/pick.py | 4 +---
stgit/commands/uncommit.py | 5 ++---
5 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/stgit/commands/assimilate.py b/stgit/commands/assimilate.py
index 0821024..a8b3bfe 100644
--- a/stgit/commands/assimilate.py
+++ b/stgit/commands/assimilate.py
@@ -73,14 +73,7 @@ def func(parser, options, args):
return name in name2patch or crt_series.patch_exists(name)
for victim in victims:
- patchname = make_patch_name(victim.get_log())
- if not patchname:
- patchname = 'patch'
- if name_taken(patchname):
- suffix = 0
- while name_taken('%s-%d' % (patchname, suffix)):
- suffix += 1
- patchname = '%s-%d' % (patchname, suffix)
+ patchname = make_patch_name(victim.get_log(), name_taken)
patch2name[victim] = patchname
name2patch[patchname] = victim
diff --git a/stgit/commands/common.py b/stgit/commands/common.py
index 0e1bb44..d986711 100644
--- a/stgit/commands/common.py
+++ b/stgit/commands/common.py
@@ -284,7 +284,7 @@ def name_email_date(address):
return str_list[0]
-def make_patch_name(msg):
+def patch_name_from_msg(msg):
"""Return a string to be used as a patch name. This is generated
from the first 30 characters of the top line of the string passed
as argument."""
@@ -293,3 +293,17 @@ def make_patch_name(msg):
subject_line = msg[:30].lstrip().split('\n', 1)[0].lower()
return re.sub('[\W]+', '-', subject_line).strip('-')
+
+def make_patch_name(msg, unacceptable, default_name = 'patch'):
+ """Return a patch name generated from the given commit message,
+ guaranteed to make unacceptable(name) be false. If the commit
+ message is empty, base the name on default_name instead."""
+ patchname = patch_name_from_msg(msg)
+ if not patchname:
+ patchname = 'patch'
+ if unacceptable(patchname):
+ suffix = 0
+ while unacceptable('%s-%d' % (patchname, suffix)):
+ suffix += 1
+ patchname = '%s-%d' % (patchname, suffix)
+ return patchname
diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
index c8cf42b..34cbf38 100644
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -240,9 +240,7 @@ def __import_patch(patch, filename, opti
__parse_patch(filename)
if not patch:
- patch = make_patch_name(message)
- if not patch:
- raise CmdException, 'Unknown patch name'
+ patch = make_patch_name(message, crt_series.patch_exists)
# refresh_patch() will invoke the editor in this case, with correct
# patch content
diff --git a/stgit/commands/pick.py b/stgit/commands/pick.py
index f8f3577..996e789 100644
--- a/stgit/commands/pick.py
+++ b/stgit/commands/pick.py
@@ -71,9 +71,7 @@ def func(parser, options, args):
elif len(patch_branch) == 2:
patch = patch_branch[0]
else:
- patch = make_patch_name(commit.get_log())
- if not patch:
- raise CmdException, 'Unknown patch name'
+ patch = make_patch_name(commit.get_log(), crt_series.patch_exists)
if options.parent:
parent = git_id(options.parent)
diff --git a/stgit/commands/uncommit.py b/stgit/commands/uncommit.py
index 45a2087..9798f19 100644
--- a/stgit/commands/uncommit.py
+++ b/stgit/commands/uncommit.py
@@ -97,9 +97,8 @@ def func(parser, options, args):
if patchnames:
patchname = patchnames[n]
else:
- patchname = make_patch_name(commit.get_log())
- if not patchname:
- raise CmdException, 'Unknown patch name for commit %s' % commit_id
+ patchname = make_patch_name(commit.get_log(),
+ crt_series.patch_exists)
crt_series.new_patch(patchname,
can_edit = False, before_existing = T
^ permalink raw reply related
* Re: [PATCH/RFC] Convenient support of remote branches in git-checkout
From: Junio C Hamano @ 2006-11-07 7:07 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200611070225.24956.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>> Then "git checkout origin/next" would always mean "I want to
>> switch to the branch I use to hack on the branch 'next' Junio
>> has". Do it once and you will get exactly my tip, hack on it,
>> switch out of it and then do it again and you won't lose your
>> previous work but just switch to that branch.
>
> Ah, now I understand your thinking.
> I admit it has a compelling elegance.
>
> However.
> Would it not be confusing for newbies (and not only for them) to
> first reference the remote branch with "origin/next", and afterwards, you
> get your own development branch by using the exactly same name?
In that example, the user types "git checkout origin/next". I
do not think there is any confusion.
You come from git background from the era git checkout did _not_
have this magic (in other words, "today"), so you implicitly see
remotes/ prefixed in front of the "origin/next" string there.
But new people do not see remotes/ prefixed there. To them, the
example command line says "Now I want to be on my 'origin/next'
branch", and there is nothing 'remote' about it.
The magic under discussion happens to create your 'origin/next'
branch automagically from 'remotes/origin/next' when it exists,
but that can be transparent to the user [*1*].
Well, your original magic did not propose it that way, but I
twisted it.
[Footnote]
*1* This is in line with what I wanted to say in my earlier "if
I were redoing git from scratch" message when I talked about
making "remotes" less visible.
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Liu Yubao @ 2006-11-07 7:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611060734490.25218@g5.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 6 Nov 2006, Liu Yubao wrote:
>> Then, what bad *logical* problem will happen if a merging that is really a
>> fast forwarding creates a new commit?
>
> You MUST NOT do that.
>
> If a fast-forward were to do a "merge commit", you'd never get into the
> situation where two people merging each other would really ever get a
> stable result. They'd just keep doing merge commits on top of each other.
They can stop merging a fake commit with a real commit that point to same
tree object, here they reach a stable result: we have same tree content.
>
> Git tracks history, not "your view of history". Trying to track "your
> view" is fundamentally wrong, because "your wiew" automatically means that
> the project history would not be distributed any more - it would be
> centralized around what _you_ think happened. That is not a sensible thing
> to have in a distributed system.
It's not my view, it's branch scope view, I can see how a branch evolves
relatively independently. In git, branch scope view is more or less neglected.
After fast forwarding merge, I can' tell where a branch come from -- I mean
the track of a branch.
If Junio publishes his reflog, I don't see what conflict will happen between
his local view (but now public, and naming it branch scope view seems more
sensible) and git's global view.
If this won't lead to problems, it seems also ok to use fake commit for
fast forwarding style merge, so we can follow HEAD^1 to travel through a
branch without reflog.
I hope I have expressed my thought clearly.
>
> For example, the way to break the "infinite merges" problem above is to
> say that _you_ would be special, and you would do a "fast-forward commit",
> and the other side would always just fast-forward without a commit. But
> that is very fundamentally against the whole point of being distributed.
> Now you're special.
No one is special as everybody can create fake commit, any branch (almost
a tag) will never be overwritten to point to a commit object in
another branch, branches are relatively independent, that's to say
'git log' will reflect what has happened really in current branch (a CVS
semantical branch, not only a tag that always points to a tip commit).
>
> In fact, even for "you", it would be horrible - because you personally
> might have 5 different repositories on five different machines. You'd have
> to select _which_ machine you want to track. That's simply insane. It's a
> totally broken model. (You can even get the same situation with just _one_
> repository, by just having five different branches - you have to decide
> which one is the "main" branch).
What's the mean of upstream branch then? I have to know I should track
Junio's public repository.
When does one say two branches reach a common point? have same commit(must
point to same tree) or have same tree(maybe a fake commit and a real commit)?
I think git takes the first way.
Fast forwarding style merge tends to *automatically* centralize many
branches, in CVS people merge two branches and drop side branch to
centralize them, they all have central semantics.
(I don't want to get flame war between CVS/SVN and GIT, I think
git is better than them really:-)
>
> Besides, doing an empty commit like that ("I fast forwarded") literally
> doesn't add any true history information. It literally views history not
> as history of the _project_, but as the history of just one of the
> repositories. And that's wrong.
Something like 'git log --follow-all-parent' can show history of the project
as 'git log' does now.
>
> So just get used to it. You MUST NOT do what you want to do. It's stupid.
Yes, I have understood the git way and am getting used to it, I like
its simple but powerful design and great efficiency, thank all for your
good work!
>
> If you want to track the history of one particular local branch, use the
> "reflog" thing. It allows you to see what one of your local branches
> contained at any particular time.
>
> See
>
> [core]
> logAllRefUpdates = true
>
Thanks, it's a pity I can't pull Junio's reflog :-(
> documentation in "man git-update-refs" (and maybe somebody can write more
> about it?)
>
> Linus
>
^ permalink raw reply
* Re: If merging that is really fast forwarding creates new commit [Was: Re: how to show log for only one branch]
From: Liu Yubao @ 2006-11-07 7:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0611060928180.3667@g5.osdl.org>
Linus Torvalds wrote:
>
> On Mon, 6 Nov 2006, Linus Torvalds wrote:
>> Besides, doing an empty commit like that ("I fast forwarded") literally
>> doesn't add any true history information. It literally views history not
>> as history of the _project_, but as the history of just one of the
>> repositories. And that's wrong.
>>
>> So just get used to it. You MUST NOT do what you want to do. It's stupid.
>
> Btw, absolutely the _only_ reason people seem to want to do this is
> because they want to "pee in the snow" and put their mark on things. They
> seem to want to show "_I_ did this", even if the "doing" was a total
> no-op and they didn't actually generate any real value.
We can kick out fake commits when calculate credits, we can grep logs with
author name to see what he/she has done.
Fake commit is only for digging branch scope history, I can *outline* what has
been merged to a branch and don't care about how these good work are done on
earth.
>
> That's absolutely the last thing you want to encourage, especially when
> the end result is a history that is totally unreadable and contains more
> "junk" than actual real work.
>
> I'll be the first to say that "merging code" is often as important as
> actually writing the code in the first place, and that it is important to
> show who actually did real work to make a patch appear in a project.
>
> In the kernel, for example, we have "sign-off" lines to show what route a
> patch took before it was accepted, and it's very instructive to see (for
> example) how man patches give credit to somebody like Andrew Morton for
> passing it on versus actually writing the code himself (he has a lot of
> authorship credit too, but it's absolutely _dwarfed_ by his importance as
> a maintainer - and if you were to ask any random kernel developer why
> Andrew is so important, I can pretty much guarantee that his importance is
> very much about those "sign-offs", and not about the patches he authors).
>
> But at the same time, when it comes to merging, because it actually
> clutters up history a lot, we actively try to _avoid_ it. Many subsystem
> maintainers purposefully re-generate a linear history, rebased on top of
> my current kernel, exactly because it makes the history less "branchy",
> and because that makes things easier to see.
>
> So we have actually done work to _encourage_ fast-forwarding over "merge
> with a commit", because the fast-forwarding ends up generating a much more
> readable and understandable history. Generating a _fake_ "merge commit"
> would be absolutely and utterly horrible. It gives fake credit for work
> that wasn't real work, and it makes history uglier and harder to read.
>
> So it's a real NEGATIVE thing to have, and you should run away from it as
> fast as humanly possible.
>
> Now, the kernel actually ends up being fairly branchy anyway, but that's
> simply because we actually have a lot of real parallel development (I bet
> more than almost any other project out there - we simply have more commits
> done by more people than most projects). I tend to do multiple merges a
> day, so even though people linearize their history individually, you end
> up seeing a fair amount of merges. But we'd have a lot _more_ of them if
> people didn't try to keep history clean.
That's right the central semantics I have said, git tends to and recommends
a trunk mode development *on a high level*. It's not a bad thing.
>
> Btw, in the absense of a merge, you can still tell who committed
> something, exactly because git keeps track of "committer" information in
> addition to "authorship" information. I don't understand why other
> distributed environments don't seem to do this - because separating out
> who committed something (and when) from who authored it (and when) is
> actually really really important.
Yes, agree.
>
> And that's not just because we use patches and other SCM's than just git
> to track things (so authorship and committing really are totally separate
> issues), but because even if the author and committer is the same person,
> it's very instructive to realize that it might have been moved around in
> history, so it might actually have been cherry-picked later, and the
> committer date differs from the author date even if the actual author and
> committer are the same person (but you might also have had somebody _else_
> re-linearize or otherwise cherry-pick the history: again, it's important
> to show the committer _separately_ both as a person and as a date).
>
> And because there is a committer field, if you actually want to linearize
> or log things by who _committed_ stuff, you can. Just do
>
> git log --committer=torvalds
>
> on the kernel, and you can see the log as it pertains for what _I_
> committed, for example. You can even show it graphically, although it
> won't be a connected graph any more, so it will tend to be very ugly
> (but you'll see the "linear stretches" when somebody did some work). Just
> do "gitk --committer=myname" to see in your own project.
>
> Linus
I want to separate a branch, not to separate commits by some author, for
example, many authors can contribute to git's master branch, I want to
know what happened in the master branch like this:
good work from A;
good work from C;
merge from next; -----> I don't care how this feature is realized.
good work from A;
....
As Junio points out, HEAD^1 is not always the tip of working branch,
so "git log" can't never satisfy me. There is reflog, but it's not public.
BTW: I have a great respect for any man who contributes to Linux and GIT,
especially you:-)
^ permalink raw reply
* Re: how to show log for only one branch
From: Jakub Narebski @ 2006-11-07 8:08 UTC (permalink / raw)
To: Liu Yubao, Junio C Hamano; +Cc: git
In-Reply-To: <455001EA.5040306@gmail.com>
Liu Yubao wrote:
> Jakub Narebski wrote:
>>
>> Perhaps what you want is git log --committer=<owner of repo>?
>>
> Thanks, it can't meet my requirement, if I create two branches
> and merge them, I can't easily tell the track of those two branches.
Use graphical history viewer then. git-show-branch, gitk (Tcl/Tk),
qgit (Qt), less used GitView (GTK+), tig (ncurses), least used
git-browser (JavaScript).
BTW. that is what subject line (first line of commit message) is for.
Note the "gitweb:", "Documentation:", "autoconf:", "Improve build:" in
the git log.
By the way, what is the status of the proposed "note" header extension
to the commit object? One could store name of branch we were/are on,
even though this is absolutely discouraged...
--
Jakub Narebski
^ 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