<opublikowany i wysłany> It looks for me as permission problems, as thought loose objects get created unreadable by git daemon, or something... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git --

The find toolbar now searches only in one field at a time and the user can change the find-in field by clicking on the button. The button shows an icon so the user knows at all times what field is selected. We don't have the option to find in 2 or more fields at the same time anymore, but from day to day usage I noticed that I usually only want to search in one field at a time. It feels a lot better to me and makes it more like gitk. Signed-off-by: Roger C. Soares ...

Hello, This tig release brings many fixes and improvements to the user interface. Fix pager mode and disable view rely on git directory. The date and author columns as well as references can now be toggled on and off. Local (unsigned) tags are now shown as references and the builtin reference colors have been changed to highlight the current branch and the remote tracked by the current branch. The status and stage views are now reloaded after running external commands (e.g. git commit) so ...

Yes, it does. Unfortunately, it doesn't have any effect with --pretty=format. Actually, going back and testing this, it looks like I have a bug when handling --graph together with --pretty=format. There's a missing newline after the user's format message and the next graph line. I'll try to fix this and submit a patch later this evening. -- Adam Simpkins adam@adamsimpkins.net --

Signed-off-by: Teemu Likonen <tlikonen@iki.fi> --- contrib/completion/git-completion.bash | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 791e30f..cd26d0c 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -754,6 +754,7 @@ _git_log () --pretty= --name-status --name-only --raw --not --all --left-right ...

I don't know anything about the inside stuff but from user's point of view this is the kind of text-based graph I'd agree to be integrated to Git (well, I integrated it already to my Git). I like this a lot, thanks. Maybe git-doc.txt should be updated with new option(s)? --

Hi, Would "--decorate" help? Ciao, Dscho --

Ah, you're right, I forgot about that. I'll send out a new patch to update Documentation/rev-list-options.txt -- Adam Simpkins adam@adamsimpkins.net --

Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> --- graph.c | 22 +++++++++++++++------- revision.c | 3 --- 2 files changed, 15 insertions(+), 10 deletions(-) diff --git a/graph.c b/graph.c index e6d1d3a..be4000f 100644 --- a/graph.c +++ b/graph.c @@ -1,6 +1,8 @@ #include "cache.h" #include "commit.h" #include "graph.h" +#include "diff.h" +#include "revision.h" /* * TODO: @@ -174,17 +176,24 @@ static void graph_ensure_capacity(struct git_graph *graph, int ...

The --graph option causes a text-based representation of the history graph to be printed on the left-hand side of the output. Signed-off-by: Adam Simpkins <adam@adamsimpkins.net> --- The --graph option can be used with any --pretty format. If this change is too intrusive for people's liking, a smaller change could probably be done that only adds --pretty=graph and --pretty=graph:<user_fmt> options. At the moment, --graph and --reverse are mutually exclusive. With Junio's new --children ...

Trying to compile the following test code with gcc 4.1.2 results in a warning. test.c: #include <stdio.h> void test(struct strbuf *sb); int main(int argc, char **argv) { test(NULL); return 0; } $ gcc -c test.c test.c:3: warning: ‘struct strbuf’ declared inside parameter list test.c:3: warning: its scope is only this definition or declaration, which is probably not what you want -- Adam Simpkins adam@adamsimpkins.net --

I personally do not think this is worth it where a single "-i" is enough. --

Signed-off-by: Pascal Obry <pascal@obry.net> --- contrib/completion/git-completion.bash | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 791e30f..96a712b 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -865,7 +865,7 @@ _git_rebase () return ;; --*) - __gitcomp "--onto --merge --strategy" + __gitcomp "--onto --merge ...

I like unambiguous name (I do prefer --interactive instead of -i). It is painful to enter so the bash completion come quite handy here. The patch is safe, simple and clean, I see no reason to not include it. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| ...

Signed-off-by: Pascal Obry <pascal@obry.net> --- contrib/completion/git-completion.bash | 5 ++++- 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index 791e30f..618d278 100755 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -639,7 +639,9 @@ _git_diff () --find-copies-harder --pickaxe-all --pickaxe-regex --text --ignore-space-at-eol ...

It looks more like --shortlog, by the way... (Stupid backwards compatibility...) -- Jakub Narebski Warsaw, Poland ShadeHawk on #git --

Yup. :-) Acked-by: Shawn O. Pearce <spearce@spearce.org> -- Shawn. --

Except that only a positive offset value is here, as it is always a treated as a negative offset (you can only refer to a base that was before you, as that is the only way to know the base's offset Yes, that sounds correct. -- Shawn. --

Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> --- Documentation/technical/pack-format.txt | 16 +++++++++++++++- 1 files changed, 15 insertions(+), 1 deletions(-) diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index aa87756..6b2170f 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -103,10 +103,24 @@ Pack file entry: <+ packed object data: If it is not DELTA, then ...

It sounds like your remote repository has a bogus HEAD that points to a non-existent object. Can you ssh to <host> and confirm that you can do a "git show HEAD" in the remote repo? -Peff --

You are going to have to clarify what you mean by "local commit" and "local master". Those aren't terms that are commonly used, so I don't understand what you are talking about. Can you describe which git commands you used to create this situation? -Peff --

Hello, First of all I kindly ask you to put my e-mail in CC as I'm not subscribed to the list. Secondly, I did try to find similar issues on the archives, but failed to do so. I apologize if this is not a bug. I keep some local git repositories on my laptop, which are also used by other machines on my home network. In order to avoid unnecessary burden on the master servers, I've tried keeping a "local master" on the laptop and clone the repo's over ssh on the other machines. I have some ...

That shouldn't matter to git; it doesn't care at all about where commits Can you give an exact set of steps to reproduce? There doesn't seem to be anything wrong with those repos, and I was able to do: m1$ git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/ m1$ cd xf86-video-nouveau && echo foo >>COPYING && git commit -a -m foo m2$ git clone ssh://m1/path/to/xf86-video-nouveau So now my guess is when you make local changes, something funny is going on. Can you ...

This object is the correct HEAD, but it is a local commit (I rebase Sure, I just thought it would confuse more than it would help. I was obviously wrong, as I'm actually using git:// instead of http://.... sorry... ;) I'm experiencing this with both these repo's, as I have committed some local changes to them: git://anongit.freedesktop.org/git/nouveau/mesa git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/ On the other hand, I don't have this issue with this repo, ...

You've already done that. They are not what you _wrote_ so your name won't be on "Author:" lines, but you made into commits in the final history, and your name would appear on "Committer:" lines. A _better way_, especially because you are already pulling from them, would be just "pull", without having to cherry-pick to clean-up the history. The reason you are being forced to cherry-pick is probably _their_ histories you pulled are suboptimal and full of garbage commit, ...

Well, at that point, you are not the committer for their changes on their clean history, and you shouldn't expect to be recorded as such. Your contribution to the project might still be recorded as the committer of the merge commit that pulled their contributions in, though. Any history is just as valid as your integration branch's history. There may be hundreds of potential histories in the universe --- each and every contributor, anybody who clones and plays with the project may create ...

Right. Saying just "n-byte offset" can be mistaken as the offset from the Ah, I forgot about that one. --

I was mainly working from rebase--interactive, and a lot of what I have is Not at the moment. I've been busy with a new job recently, and my git work I haven't actually looked at it recently, so I don't entirely remember how far I got. I think my most recent code is based around the idea of having a sequence file and a file of saved options, but it's just kind of a sketch and most of the stuff isn't actually implemented. IIRC, the last thing I ran into was trying to decide where to ...

Yes. And thanks, your patch looks good, but please send a proper patch for it latter if you really care about it. (By proper I mean in its own email and not attached. And I know my patch included in my previous email was bad (corrupted tab, sorry about that, and not in its own email), but it was only for discussion, yours too granted.) Now I think that you should focus on your GSoC application as you don't have much time left to improve it and I just asked you for more ...

Yes, I take responsibility for the git Debian packages. Regards, Gerrit. --

Hi Linus, It sure is old-fashioned. My only excuse is that since git repack is a shell script around git-pack-objects I've always felt comfortable just using It was pretty much the result of (cd .git/objects ; find . -type f | tr -d './') Omitting that was quite silly on my part, but I was really convinced that because of the internal sorting the original ordering of objects So it seems that my list of objects was different from what git-rev- list/setup_revisions() would have ...

I'll add a belated "yes I agree" to this. This is what I was trying to describe earlier in the thread, but for some reason couldn't think of the obvious name "log" to replace merge.summary. :) -Peff --

This variable has the same effect, as 'merge.diffstat'. Also mention it in the documentation. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> --- Documentation/merge-config.txt | 4 ++++ Documentation/merge-options.txt | 2 +- git-merge.sh | 1 + 3 files changed, 6 insertions(+), 1 deletions(-) diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt index cc815cc..6d0a797 100644 --- a/Documentation/merge-config.txt +++ ...

This option has the same effect as '--(no-)summary' (i.e. whether to show a diffsat at the end of the merge or not), and it is consistent with the '--stat' option of other git commands. Documentation, tests, and bash completion are updaed accordingly. '--(no-)summary' options are still accepted, but are not advertised. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> --- Documentation/git-merge.txt | 2 +- Documentation/merge-options.txt | 4 ++-- ...

Also remove them from 'pull' and 'fmt-merge-msg'. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> --- builtin-fmt-merge-msg.c | 12 +++--------- git-merge.sh | 5 ++--- git-pull.sh | 4 ++-- 3 files changed, 7 insertions(+), 14 deletions(-) diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c index d49f545..0bf87c1 100644 --- a/builtin-fmt-merge-msg.c +++ b/builtin-fmt-merge-msg.c @@ -12,12 +12,7 @@ static int merge_summary; static int ...

Thanks for reminding me. I have applied it. Paul. --