Hi, git commit supports --author to overwrite the author information on a particular commit; it would be nice if git tag would offer the same. Regards, Daniel -- Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baumann@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -

That didn't work for me, but perhaps I'm not understanding what this user wants to do. I think it is about to create a tag object having another author different from committer. In such case, and looking at builtin-commit.c, I see that the code needed could came from the function determine_author_info(), just the part using force_author variable, to be added in the create_tag() function from builtin-tag.c. The only thing I don't know is if this should be different from git-commit in which bot...

Right click on patched file list view gives "External diff" popup menu entry, launching selected external diff tool. The diff tool is configurable through Edit/Preference/External diff tool. Signed-off-by: Thomas Arcila <tarcila@mc.com> --- Hi, Here is a patch to gitk that allows to run an external diff viewer. It can be configured in Edit/Preferences/External diff tool. To see the diff between two files: - select revisions to diff - right click on a file in the patched files list vi...

This is just a cosmetical flaw: When a tag is changed to point to a new commit, then the tag is pushed to a repo that still has the old tag, it is correctly pushed, but the old SHA1 is reported with all 40 digits: # make upstream repo $ mkdir A && cd A $ git init $ echo a > a; git add a; git commit -m a # clone, modify, push $ cd .. $ git clone A B $ cd B $ echo b > a; git commit -a -m b $ git push file://$PWD/../A # tag old state in upstream $ cd ../A $ git tag -m T T ...

Actually, it looks like we already handle a similar case: the null sha1, so the change isn't that big (and the null sha1 case folds nicely into the "missing" case). With the (lightly tested) patch below, find_unique_abbrev _always_ returns an answer, and for missing objects will show enough characters that it doesn't match any existing object. diff --git a/sha1_name.c b/sha1_name.c index 13e1164..c0e6af1 100644 --- a/sha1_name.c +++ b/sha1_name.c @@ -192,26 +192,24 @@ static int get_short_sha1(...

No idea. :) I will hold onto it and submit a cleaned up version post-1.5.4. -Peff -

The patch I just posted just figures out ahead of time whether the object exists. We can easily have it default to returning NULL but allow a special flag for the new behavior. Something like: diff --git a/builtin-send-pack.c b/builtin-send-pack.c index 8afb1d0..454ad8f 100644 --- a/builtin-send-pack.c +++ b/builtin-send-pack.c @@ -263,9 +263,8 @@ static void print_ref_status(char flag, const char *summary, struct ref *to, str static const char *status_abbrev(unsigned char sha1[20]) { - c...

No, that would be information hiding. I prefer an unabbreviated name. Nevertheless, if we know the name, we could be able to find a suitable abbreviation. But it's really not *that* important... -- Hannes -

That's very unfortunate. Whatever is expecting string value should check for NULL. Fix should probably be easy enough for any git-hacker-wannabe to tackle ;-) -

This command requires a revision to be specified on the command line, so remove '--default HEAD' from the arguments to git rev-list. They are unnecessary. Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> --- git-filter-branch.sh | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) diff --git a/git-filter-branch.sh b/git-filter-branch.sh index 5e3fe70..25f18f8 100755 --- a/git-filter-branch.sh +++ b/git-filter-branch.sh @@ -228,11 +228,10 @@ mkdir ../map || die "Could not ...

I do. But isn't that inconsistent with "git filter-branch" does _not_ work on HEAD by default and instead prints out usage information? If I do: git filter-branch -d /tmp/git_temp and it is successful, I think I would also expect this to succeed: git filter-branch So, I think the "operates on HEAD" by default is consistent with what other git tools do, but I think it is not consistent for filter-branch to sometimes operate on HEAD by default and sometimes error with usage information. ...

Actually, not erroring out but just returning doing nothing (if there truly isn't anything to do -- iow, the filtering operation turns out to be identity function) would be more sensible. No filter does not necessarily mean identity, by the way. Think "grafts" ;-). -

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> --- Documentation/git-filter-branch.txt | 2 +- git-filter-branch.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index e22dfa5..6145322 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -13,7 +13,7 @@ SYNOPSIS [--msg-filter <command>] [--commit-filter <command>...

I see you applied both this patch _and_ "filter-branch: assume HEAD if no revision supplied" The latter patch _does_ make the revision arg optional, so this "filter-branch docs" patch is unnecessary. -brandon -

Hi, Oh yes, oh yes. Count me in! ;-) Ciao, Dscho -

I meant I was trying to rewrite the history with grafts. :) -brandon -

I'd refrain from commenting on if it is consistent or not with "the git interface". But I would say I prefer your original better than this one. Will apply. -

No, I am just saying "I (Junio) is stupid and lazy, and I do not want to think about it right now, so I will not judge on that point". -

Well, I don't really think it matters. I doubt we'll break that code that invokes the pre-receive or post-receive hooks. And as those hooks are defined to never take arguments if we did suddenly start passing arguments we want the test to break. When tests break sometimes its not obvious why they have broken. Case in point, the "remote: " prefixing caused by the sideband demultiplexer really confused me for about 15 minutes. I could not figure out why the last test in this script was failing....

We heard the same argument when cloneurl was added, and a newcomer who does not know that may rightly use the same argument. But I think we should work towards _reducing_ the number of such ad-hoc one-line-per-information files, not using existing ones as an excuse to add _more_ of them. -

Currently gitweb parses repo config file _once_, using one call to git-config -z -l. We could simply add description to the projects_list file, but it will be a bit backwards incompatibile change. We have to call at least one git-for-each-ref per repo to get last While IIRC cvsimport or cvsserver has its own config parser in Perl, but which accepts only limited sensible subset of configuration syntax (and IIRC uses separate config file). -- Jakub Narebski Poland ShadeHawk on #git - ...

Okay, I agree with you. We need to centralize information. One idea use $GIT_DIR/config only, sharing any other information. But I don't like the idea do parse $GIT_DIR/config everytime. Unless it caches gitweb only information in one line. Another Idea is to use $GIT_DIR/gitweb.conf with information [like the cached above], but generated by the gitweb admin. Other to continue with all those files, but creating a gitweb.d/* . That's what I can think 1:02am =( Good night -- Bruno Ribas -...

I guess you can ask "show-branch --independent" to cull branches that are pure subset of other branches. But no matter how you do this, the resulting history would be less efficient to bisect if you make Octopus. As you can ask "git log --no-merges" to omit merges from the listing, I am not sure if it is worth it to avoid two-side merges and insist on making an Octopus these days. -

Something along these lines: %remotes = \ git for-each-ref \ --format='%(objname) %(refname)' \ refs/remotes/origin; @lines = \ git rev-list \ keys %remotes \ --not HEAD foreach $line in @lines { if $remotes contains $line git merge $remotes{$line} } That gets you the graph. The %(objname) string coming back from for-each-ref is in $line in the loop. If you see $line inside that map you built from for-each-ref then that commit isn't yet in the current branch....

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- here it is. Documentation/git-rev-parse.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index af98882..f02f6bb 100644 --- a/Documentation/git-rev-parse.txt +++ b/Documentation/git-rev-parse.txt @@ -234,8 +234,8 @@ blobs contained in a commit. (typically the current branch), and stage 3 is the version from the branch being me...