What's cooking in git.git (topics)

What's cooking in git.git (topics)

[Junio C Hamano]

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

Re: What's cooking in git.git (topics)

[Nicolas Pitre]

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

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Sat, 27 Jan 2007, Junio C Hamano wrote:
>
>> * 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).

Re: What's cooking in git.git (topics)

[Nicolas Pitre]

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

[PATCH] git-log -g --pretty=oneline should display the reflog message

[Nicolas Pitre]

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 <nico@cam.org>

---

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);

Re: What's cooking in git.git (topics)

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> Well, it _is_ recorded:

It is recorded but not in a readily accessible way.  You have to
scan it.

I think the --pretty=oneline change to the git-log walker you
did would help it somewhat.

By the way, I think there is something wrong for an anonymous
user when coming back from detached HEAD to an existing branch.

An user 'u' (who has empty Gecos) on machine 'git.ster' did:

	$ git checkout master^
        $ git checkout -f master

and got these two entries:

9414... f491... u <u@git.ster> 1169971276 -0800 checkout: moving to master^
f491... 9414... u <>        checkout: moving to master

The latter entry is corrupt; adding setup_ident() before
git_config() in builtin-symbolic-ref.c would fix it.

diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
index d41b406..c184679 100644
--- a/builtin-symbolic-ref.c
+++ b/builtin-symbolic-ref.c
@@ -27,6 +27,7 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
 	int quiet = 0;
 	const char *msg = NULL;
 
+	setup_ident();
 	git_config(git_default_config);
 
 	while (1 < argc) {

But now I am thinking maybe we should rearrange things so that
we do not have to do setup_ident() in each and every programs.

It used to be a sensible way because only commit and tag making
program needed to do so, but with reflog leaving the committer
names from everywhere, it does not make much sense anymore.

-- >8 --
[PATCH] don't force everybody to call setup_ident().

Back when only handful commands that created commit and tag were
the only users of committer identity information it made sense
to explicitly calling setup_ident() to pre-fill the default
value from the gecos information.  But it is much simpler for
programs to make the call automatic when get_ident() is called.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 ident.c                |   51 ++++++++++++++++++++++++++++++++---------------
 builtin-branch.c       |    1 -
 builtin-commit-tree.c  |    1 -
 builtin-log.c          |    1 -
 builtin-update-ref.c   |    1 -
 cache.h                |    1 -
 fetch-pack.c           |    1 -
 http-fetch.c           |    1 -
 http-push.c            |    1 -
 local-fetch.c          |    1 -
 receive-pack.c         |    1 -
 ssh-fetch.c            |    1 -
 var.c                  |    1 -
 13 files changed, 35 insertions(+), 28 deletions(-)

diff --git a/ident.c b/ident.c
index f967790..6de7eea 100644
--- a/ident.c
+++ b/ident.c
@@ -43,19 +43,13 @@ static void copy_gecos(struct passwd *w, char *name, int sz)
 
 }
 
-int setup_ident(void)
+static void copy_email(struct passwd *pw)
 {
-	int len;
-	struct passwd *pw = getpwuid(getuid());
-
-	if (!pw)
-		die("You don't exist. Go away!");
-
-	/* Get the name ("gecos") */
-	copy_gecos(pw, git_default_name, sizeof(git_default_name));
-
-	/* Make up a fake email address (name + '@' + hostname [+ '.' + domainname]) */
-	len = strlen(pw->pw_name);
+	/*
+	 * Make up a fake email address
+	 * (name + '@' + hostname [+ '.' + domainname])
+	 */
+	int len = strlen(pw->pw_name);
 	if (len > sizeof(git_default_email)/2)
 		die("Your sysadmin must hate you!");
 	memcpy(git_default_email, pw->pw_name, len);
@@ -68,13 +62,37 @@ int setup_ident(void)
 		len = strlen(git_default_email);
 		git_default_email[len++] = '.';
 		if (he && (domainname = strchr(he->h_name, '.')))
-			strlcpy(git_default_email + len, domainname + 1, sizeof(git_default_email) - len);
+			strlcpy(git_default_email + len, domainname + 1,
+				sizeof(git_default_email) - len);
 		else
-			strlcpy(git_default_email + len, "(none)", sizeof(git_default_email) - len);
+			strlcpy(git_default_email + len, "(none)",
+				sizeof(git_default_email) - len);
 	}
+}
+
+static void setup_ident(void)
+{
+	struct passwd *pw = NULL;
+
+	/* Get the name ("gecos") */
+	if (!git_default_name[0]) {
+		pw = getpwuid(getuid());
+		if (!pw)
+			die("You don't exist. Go away!");
+		copy_gecos(pw, git_default_name, sizeof(git_default_name));
+	}
+
+	if (!git_default_email[0]) {
+		if (!pw)
+			pw = getpwuid(getuid());
+		if (!pw)
+			die("You don't exist. Go away!");
+		copy_email(pw);
+	}
+
 	/* And set the default date */
-	datestamp(git_default_date, sizeof(git_default_date));
-	return 0;
+	if (!git_default_date[0])
+		datestamp(git_default_date, sizeof(git_default_date));
 }
 
 static int add_raw(char *buf, int size, int offset, const char *str)
@@ -174,6 +192,7 @@ static const char *get_ident(const char *name, const char *email,
 	char date[50];
 	int i;
 
+	setup_ident();
 	if (!name)
 		name = git_default_name;
 	if (!email)
diff --git a/builtin-branch.c b/builtin-branch.c
index b709b2f..869e753 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -395,7 +395,6 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
 	int kinds = REF_LOCAL_BRANCH;
 	int i;
 
-	setup_ident();
 	git_config(git_branch_config);
 
 	for (i = 1; i < argc; i++) {
diff --git a/builtin-commit-tree.c b/builtin-commit-tree.c
index 0651e59..2a818a0 100644
--- a/builtin-commit-tree.c
+++ b/builtin-commit-tree.c
@@ -94,7 +94,6 @@ int cmd_commit_tree(int argc, const char **argv, const char *prefix)
 	unsigned int size;
 	int encoding_is_utf8;
 
-	setup_ident();
 	git_config(git_default_config);
 
 	if (argc < 2)
diff --git a/builtin-log.c b/builtin-log.c
index 56acc13..982d871 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -380,7 +380,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	char message_id[1024];
 	char ref_message_id[1024];
 
-	setup_ident();
 	git_config(git_format_config);
 	init_revisions(&rev, prefix);
 	rev.commit_format = CMIT_FMT_EMAIL;
diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index b34e598..1461937 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -13,7 +13,6 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
 	int i, delete;
 
 	delete = 0;
-	setup_ident();
 	git_config(git_default_config);
 
 	for (i = 1; i < argc; i++) {
diff --git a/cache.h b/cache.h
index 2873f9f..3902a14 100644
--- a/cache.h
+++ b/cache.h
@@ -320,7 +320,6 @@ int parse_date(const char *date, char *buf, int bufsize);
 void datestamp(char *buf, int bufsize);
 unsigned long approxidate(const char *);
 
-extern int setup_ident(void);
 extern const char *git_author_info(int);
 extern const char *git_committer_info(int);
 
diff --git a/fetch-pack.c b/fetch-pack.c
index 83a1d7b..c787106 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -670,7 +670,6 @@ int main(int argc, char **argv)
 	struct stat st;
 
 	setup_git_directory();
-	setup_ident();
 	git_config(fetch_pack_config);
 
 	if (0 <= transfer_unpack_limit)
diff --git a/http-fetch.c b/http-fetch.c
index 67dfb0a..efd494a 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1003,7 +1003,6 @@ int main(int argc, const char **argv)
 	int arg = 1;
 	int rc = 0;
 
-	setup_ident();
 	setup_git_directory();
 	git_config(git_default_config);
 
diff --git a/http-push.c b/http-push.c
index 0a15f53..b128c01 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2299,7 +2299,6 @@ int main(int argc, char **argv)
 	struct ref *ref;
 
 	setup_git_directory();
-	setup_ident();
 
 	remote = xcalloc(sizeof(*remote), 1);
 
diff --git a/local-fetch.c b/local-fetch.c
index cf99cb7..7cfe8b3 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -210,7 +210,6 @@ int main(int argc, const char **argv)
 	char **commit_id;
 	int arg = 1;
 
-	setup_ident();
 	setup_git_directory();
 	git_config(git_default_config);
 
diff --git a/receive-pack.c b/receive-pack.c
index c4a4757..c51f417 100644
--- a/receive-pack.c
+++ b/receive-pack.c
@@ -429,7 +429,6 @@ int main(int argc, char **argv)
 	if (is_repository_shallow())
 		die("attempt to push into a shallow repository");
 
-	setup_ident();
 	git_config(receive_pack_config);
 
 	if (0 <= transfer_unpack_limit)
diff --git a/ssh-fetch.c b/ssh-fetch.c
index 4c172b6..bdf51a7 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -124,7 +124,6 @@ int main(int argc, char **argv)
 	prog = getenv("GIT_SSH_PUSH");
 	if (!prog) prog = "git-ssh-upload";
 
-	setup_ident();
 	setup_git_directory();
 	git_config(git_default_config);
 
diff --git a/var.c b/var.c
index 39977b9..e585e59 100644
--- a/var.c
+++ b/var.c
@@ -56,7 +56,6 @@ int main(int argc, char **argv)
 	}
 
 	setup_git_directory();
-	setup_ident();
 	val = NULL;
 
 	if (strcmp(argv[1], "-l") == 0) {

Re: What's cooking in git.git (topics)

[Nicolas Pitre]

On Sat, 27 Jan 2007, Nicolas Pitre wrote:

> 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.

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