Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* sp/describe (Sat Jan 27 01:54:21 2007 -0500) 3 commits
- Compute accurate distances in git-describe before output.
- Update describe documentation.
- Teach git-describe to display distances from tags.
Meant for 1.5.0, but I haven't reviewed the code fully yet, so
it is parked in 'pu' for now.
* np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits
- add reflog when moving HEAD to a new branch
- create_symref(): do not assume pathname from git_path() persists
long enough
- add logref support to git-symbolic-ref
- move create_symref() past log_ref_write()
- add reflog entries for HEAD when detached
- enable separate reflog for HEAD
- lock_ref_sha1_basic(): remember the original name of a ref when
resolving it
- make reflog filename independent from struct ref_lock
Perhaps 1.5.0 material, but I do not think anybody in the
current code pays attention to reflog for HEAD ("HEAD@{....}"
syntax and log or show-branch with -g option would look at the
underlying ref and prune and friends do not protect its
entries), so merge it post 1.5.0 after these issues are fixed.
* jc/fetch (Tue Jan 16 13:43:28 2007 -0800) 5 commits
- git-fetch: rewrite expand_ref_wildcard in C
- git-fetch: rewrite another shell loop in C
- git-fetch: move more code into C.
- git-fetch--tool: start rewriting parts of git-fetch in C.
- git-fetch: split fetch_main into fetch_dumb and fetch_native
This is an early attempt to make "fetch between repositories
with thousand refs" go faster, and it seems to work as
advertised. Backburnered as I do not personally have need for
it and haven't heard much feedback on it.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
I kept saying this will wait until February, 6 months after its
counterpart, "part 1", was merged. That time is just around the
corner and it is becoming tempting to have it in 1.5.0.
* js/reverse (Sat Jan 20 23:04:02 2007 +0100) 1 commit
+ Teach revision machinery about --reverse
* jc/merge-base (Tue Jan 9 02:23:42 2007 -0800) 6 commits
- Teach "git-merge-base --check-ancestry" about refs.
- git-merge-base: --check-ancestry option
+ in_merge_bases(): optimization
+ merge_base(): move traversal into a separate function.
+ Allow in_merge_bases() to take more than one reference commits.
+ Make merge-base a built-in.
* sp/merge (Thu Dec 28 02:35:17 2006 -0500) 1 commit
- Avoid git-fetch in `git-pull .` when possible.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
Will rehash post 1.5.0
On Sat, 27 Jan 2007, Junio C Hamano wrote:
* np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits
- add reflog when moving HEAD to a new branch
- create_symref(): do not assume pathname from git_path() persists
long enough
- add logref support to git-symbolic-ref
- move create_symref() past log_ref_write()
- add reflog entries for HEAD when detached
- enable separate reflog for HEAD
- lock_ref_sha1_basic(): remember the original name of a ref when
resolving it
- make reflog filename independent from struct ref_lock
Perhaps 1.5.0 material, but I do not think anybody in the
current code pays attention to reflog for HEAD ("HEAD@{....}"
syntax and log or show-branch with -g option would look at the
underlying ref and prune and friends do not protect its
entries), so merge it post 1.5.0 after these issues are fixed.
I might be partial of course, but I think it is preferable to merge it
before 1.5.0 since this causes a behavior change. Currently HEAD@{n}
inherits the reflog of the branch HEAD is currently on. With this patch
serie HEAD@{n} is the true reflog for HEAD regardless of where it is now
and where it has been independently of the current branch. Of course I
consider the later behavior to be more sensible and it might be a good
idea to give it to 1.5.0 users at the same time as the detached head
support rather than creating a behavior change later on when reflogs are
more popular.
I'll look at prune and friend for teaching them about the new reflog
entries.
Nicolas
Nicolas Pitre [off-list ref] writes:
On Sat, 27 Jan 2007, Junio C Hamano wrote:
quoted
* np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits
I might be partial of course, but I think it is preferable to merge it
before 1.5.0 since this causes a behavior change. Currently HEAD@{n}
inherits the reflog of the branch HEAD is currently on. With this patch
serie HEAD@{n} is the true reflog for HEAD regardless of where it is now
and where it has been independently of the current branch. Of course I
consider the later behavior to be more sensible and it might be a good
idea to give it to 1.5.0 users at the same time as the detached head
support rather than creating a behavior change later on when reflogs are
more popular.
My understanding of the situation after your patch (disregarding
the problem that prune and friends may happily break the logs
for detached HEAD), is that if you say "git show HEAD@{...}",
while on a branch, it looks at the log of the current branch but
while on a detached HEAD it shows the log from .git/logs/HEAD.
I have a feeling that this would be confusing. Ideally, while
on a branch, say 'master', these two should behave differently:
$ git show 'master@{5.minutes.ago}'
$ git show 'HEAD@{5.minutes.ago}'
The former talks only about where the tip of that particular
branch were while the latter also should tell you on which
branch you were on.
But then that raises two new problems:
- We always said: 'HEAD' means the same thing as your current branch.
This is not true anymore.
- You do not record which branch you were on in the log for
HEAD itself (it is merely a dup), so while the latter would
report which commit you were at, you cannot tell which branch
you were on (or if your head was detached).
While I am sure that prune problem is solvable, I have a feeling
that it would take some time to iron out the semantic issues
like the above (and I suspect there might be even more).
On Sat, 27 Jan 2007, Junio C Hamano wrote:
My understanding of the situation after your patch (disregarding
the problem that prune and friends may happily break the logs
for detached HEAD), is that if you say "git show HEAD@{...}",
while on a branch, it looks at the log of the current branch but
while on a detached HEAD it shows the log from .git/logs/HEAD.
I have a feeling that this would be confusing.
It would indeed. But that's not exactly what's happening.
Ideally, while
on a branch, say 'master', these two should behave differently:
$ git show 'master@{5.minutes.ago}'
$ git show 'HEAD@{5.minutes.ago}'
The former talks only about where the tip of that particular
branch were while the latter also should tell you on which
branch you were on.
Exactly!
Try this script:
git init
echo 1 > foo
git add foo
git commit -m 1
echo 2 > foo
git add foo
git commit -m 2
echo 3 > foo
git add foo
git commit -m 3
git checkout -b otherbranch
echo 4 > foo
git add foo
git commit -m 4
echo 5 > foo
git add foo
git commit -m 5
echo 6 > foo
git add foo
git commit -m 6
git checkout master
echo 7 > foo
git add foo
git commit -m 7
echo 8 > foo
git add foo
git commit -m 8
git checkout otherbranch
git checkout master
Then you should get the following results:
$ git log -g --pretty=oneline master
58cc540d459fc0c796c2eef796b84cb003ebbf3e master@{0}: 8
b68b1cd29ad2d6157174338a3e9f871c59b5aedd master@{1}: 7
9dfb1ec50c44d0057981cccda90ee29c644ae336 master@{2}: 3
014bdcf6604056e1cda8b6d8d88d6c846db73826 master@{3}: 2
007ed39dd47696c4ab8e8ccdfcb536b8e21ec8e7 master@{4}: 1
$ git log -g --pretty=oneline otherbranch
2483023022b3167343670b209a5d98e4f192430a otherbranch@{0}: 6
3ae298d1b258c24dd2180de9b6cdb93148399920 otherbranch@{1}: 5
ca18ea0eb4e1aabde80add1761f74da9136c59ec otherbranch@{2}: 4
9dfb1ec50c44d0057981cccda90ee29c644ae336 otherbranch@{3}: 3
And finally:
$ git log -g --pretty=oneline HEAD
58cc540d459fc0c796c2eef796b84cb003ebbf3e HEAD@{0}: 8
b68b1cd29ad2d6157174338a3e9f871c59b5aedd HEAD@{1}: 7
9dfb1ec50c44d0057981cccda90ee29c644ae336 HEAD@{2}: 3
3ae298d1b258c24dd2180de9b6cdb93148399920 HEAD@{3}: 5
ca18ea0eb4e1aabde80add1761f74da9136c59ec HEAD@{4}: 4
9dfb1ec50c44d0057981cccda90ee29c644ae336 HEAD@{5}: 3
014bdcf6604056e1cda8b6d8d88d6c846db73826 HEAD@{6}: 2
007ed39dd47696c4ab8e8ccdfcb536b8e21ec8e7 HEAD@{7}: 1
OK there is kind of a screw-up with HEAD@{2} since it should have shown
"6", and I think it should have shown the movement between branches as
well, but clearly the output for HEAD doesn't depend on the current
branch already.
But then that raises two new problems:
- We always said: 'HEAD' means the same thing as your current branch.
This is not true anymore.
I think reflogs are a different concept from branch history and that we
should make sure this is well understood. And since we seem to agree on
what the ideal behavior should be I think this has to go in before
1.5.0 in order to avoid changing this behavior later when more people
are accustomed to reflogs.
- You do not record which branch you were on in the log for
HEAD itself (it is merely a dup), so while the latter would
report which commit you were at, you cannot tell which branch
you were on (or if your head was detached).
Well, it _is_ recorded:
$ sed 's/.*\t//' < .git/logs/HEAD
commit (initial): 1
commit: 2
commit: 3
checkout: moving to otherbranch
commit: 4
commit: 5
commit: 6
checkout: moving to master
commit: 7
commit: 8
checkout: moving to otherbranch
checkout: moving to master
While I am sure that prune problem is solvable, I have a feeling
that it would take some time to iron out the semantic issues
like the above (and I suspect there might be even more).
I think that the problem with HEAD@{n} is that it doesn't take all
entries into account. For example the log output skips over the "moving
to" entries. If that can be fixed then the difference in semantic
between git-log HEAD and git-log -g HEAD should be obvious enough simply
looking at the reflog message lines.
The --pretty=oneline output when using -g should probably display the
reflog message instead of the commit message as well.
Nicolas
In the context of reflog output the reflog message is more useful than
the commit message's first line. When relevant the reflog message
will contain
that line anyway.
Signed-off-by: Nicolas Pitre <redacted>
---
On Sat, 27 Jan 2007, Nicolas Pitre wrote:
The --pretty=oneline output when using -g should probably display the
reflog message instead of the commit message as well.
And this patch does just that.
diff --git a/log-tree.c b/log-tree.c
index c0fa096..d8ca36b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -224,9 +224,14 @@ void show_log(struct rev_info *opt, const char *sep)
printf("%s",
diff_get_color(opt->diffopt.color_diff, DIFF_RESET));
putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
- if (opt->reflog_info)
+ if (opt->reflog_info) {
show_reflog_message(opt->reflog_info,
opt->commit_format == CMIT_FMT_ONELINE);;
+ if (opt->commit_format == CMIT_FMT_ONELINE) {
+ printf("%s", sep);
+ return;
+ }
+ }
}
/*diff --git a/reflog-walk.c b/reflog-walk.c
index 8e2cd2f..8262160 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -233,7 +233,7 @@ void show_reflog_message(struct reflog_walk_info* info, int oneline)
else
printf("%d", commit_reflog->reflogs->nr
- 2 - commit_reflog->recno);
- printf("}: ");
+ printf("}: %s", info->message);
}
else {
printf("Reflog: %s@{", commit_reflog->reflogs->ref);On Sat, 27 Jan 2007, Nicolas Pitre wrote:
On Sat, 27 Jan 2007, Junio C Hamano wrote:
quoted
My understanding of the situation after your patch (disregarding
the problem that prune and friends may happily break the logs
for detached HEAD), is that if you say "git show HEAD@{...}",
while on a branch, it looks at the log of the current branch but
while on a detached HEAD it shows the log from .git/logs/HEAD.
I have a feeling that this would be confusing.
It would indeed. But that's not exactly what's happening.
Well... It is a mess. That's not what's happening for git-log
obviously, but what you describe is indeed the case for git-rev-parse.
There needs to be a dwim_reflog() function that looks for a matching
reflog file by itself instead of using dwim_ref() and simply prefixing
the resolved ref with "logs/". Unfortunately this tackling of reflog
path built on top of resolve_ref() seems to be a popular assumption and
chasing and fixing all those cases properly would require more time than
I can spare right now.
Nicolas