--- revision.c | 10 ++++------ 1 files changed, 4 insertions(+), 6 deletions(-) diff --git a/revision.c b/revision.c index 4231ea2..bcfcd2a 100644 --- a/revision.c +++ b/revision.c @@ -415,7 +415,6 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str { struct commit_list *parent = commit->parents; unsigned left_flag; - int add, rest; if (commit->object.flags & ADDED) return 0; @@ -462,19 +461,18 @@ static int add_parents_to_list(struc...

John mentioned on IRC that clone works. $ git-ls-remote http://newartisans.com/git/ledger.git 96751442d9eda537480867e599e4c604663f4530 refs/heads/master 365baca5174232cc35e4ed190fd8ce93c3611c84 refs/heads/v2.4.1 f972a89073843fdbb2a1bef969d9ca70509d4bfe refs/heads/v2.5 6a81d760dc4ab9028b27430124702c28c0b894ed refs/tags/cvs-20040410 fed3956a310a2ea8c8595b7fde7aaa0623492ca6 refs/tags/v0.1 ... $ git-ls-remote git://newartisans.com/ledger.git 96751442d9eda5374808...

I never managed to trace through the shell fetch code, but I suspect that it broke quite a long time ago (git-ls-remote.sh didn't list HEAD for http:// URLs, anyway). clone works because it uses entirely different code, and "git fetch origin" (when origin is an http URL) works, and "git fetch http://... branch" works (and is a workaround), and that's probably all that people use regularly. This only comes up because there's an automated fetch-and-build system that uses "<vcs> command &lt...

Probably, but even then, it also doesn't have a HEAD. Mike --

"function " noiseword is unnecessary and unportable. echo "\c" is unportable. Traditional trick to do this is to pipe it to tr to strip "\010". When you see "<anything>$@<anything>" in shell scripts, you usually do not mean it, but instead mean "<anything>$*<anything>". It does not make difference if you always feed a single parameter, but it is a good habit It is quite hard to read with backslashes inside dq. Please use single quote pairs without excess backslash...

This is yet another series of planned gitweb features. It expands more on tasks improving gitweb; new features are mentioned only in general view. Which tasks / features are most requested? Which tasks should be done first? All comments appreciated. 1. Cleanup * HTML: use classes for styling elements. There are still some places where we use presentational HTML elements like <i>. I'd rather have it replaced by adding class to appropriate element, and adding proper rule to CS...

I personally do not think the above is a particularly desirable output, but that's how rev-list worked for a long time and existing scripts probably expect it that way. rev-list is for script consumption, and giving --pretty=format that has %H in it would be asking for redundant information. --

This patch also describes the current behavior for "konqueror" and how to modify it using "man.<tool>.cmd" if needed. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- Documentation/config.txt | 5 ++++ Documentation/git-help.txt | 48 +++++++++++++++++++++++++++++++++++++++---- 2 files changed, 48 insertions(+), 5 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index c1c72e7..411e367 100644 --- a/Documentation/config.txt +++ b/Docu...

This patch documents the "man.<tool>.path" configuration variable. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> --- Documentation/config.txt | 4 ++++ Documentation/git-help.txt | 9 +++++++++ 2 files changed, 13 insertions(+), 0 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index b109bdf..c1c72e7 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -773,6 +773,10 @@ man.viewer:: Specify the programs that ...

I had some work in master, I decided to move to a branch to complete, so: % git checkout -b branch % git commit -a -m "Insightful message" Then, I decided this was not such a good idea, so I did a git reset --soft HEAD^, then git reset HEAD for each file I committed, thinking that this was a complete "undo". I then switched to branch master and got this: Switched to branch "master" Your branch is ahead of the tracked remote branch 'origin/master' by 1 commit. I'm not sure this is accurate...

Ah, ok, now I think I understand --- if I do a fetch (or pull) on master, switch over to the other branch, and then back, I see no such message. Thanks. Bill --

Hmm. Currently you can get the same effect by adding the escape codes to the format string directly. Arguably, --pretty=format should honour the config variable color.diff and the options --color and --no-color to make the colour placeholders useful (both your extended set and the current one). René --

Including this message, I agree with what Jakub said as comments to this series. Readers of "git log" 6 months from now should not have to suffer "See Documentation", and reviewers of this series right now should not have to guess why it is a good idea and is worth reviewing by actually reading the patch. --

I think I get the idea now. You want to generalize fast-forward merge, or what's equivalent make fast-formard merge to be special case of head reduction. This should be written both in commit message and in documentation. Do I understand your goal correctly? With head reduction comes three things: * the merge strategy used * recorded parents * generated merge commit message The simplest way would be to use reduced head for all three things, I think. But I also think that this commit ...

Thanks for following up on this, the Perl bits look good to me[1]. I commented in a separate email about the shell incompatibilities I experienced. Trivial fix: --- a/hash-object.c +++ b/hash-object.c @@ -6,6 +6,7 @@ */ #include "cache.h" #include "blob.h" Ugh, you added long (>80 char) lines to this and I'm having trouble following it. I believe the git (like Linux) coding style calls for 80 char lines unless there is really no other way[2]. This is also a gcc isn't smar...

Looking at the callers, I do not think you want that. I would suggest something defensive like: printf '%s' "$*" --

I have found three another Git-related Google Summer of Code 2008 projects by other organizations: Git plugin for Anjuta IDE (GNOME) KDevelop DVCS support (KDE) Git# implementation (Mono Project) Info from Shawn message, and above info can be found on git wiki at http://git.or.cz/gitwiki/SoC2008Projects -- Jakub Narebski Poland ShadeHawk on #git --

My first thought about the documentation was to put it in Documentation/config.txt but wouldn't that be strange if someone uses a git-gui other than the one bundled with the git version used? On the other hand, if the keys don't ever change that is not a big problem. I'll try to have a go at writing some docs, but it won't be until late next week because my daytime work is killing me right now. /Gustaf --

Hi Junio, I think it should be the other way: unremovable marks should leave the DOTEST behind. This way a rebase should refuse to start a new session and stumble accross the old marks and it's possible to run git rebase --abort after manually removing the marks. Bye, J=F6rg. --=20 Damit das M=F6gliche entsteht, mu=DF immer wieder das Unm=F6gliche versucht werden. (Hermann Hesse)