Inconsistencies with git log

Inconsistencies with git log

[Jon Smirl]

In project root:
 git log arch/powerpc/platforms/52xx
works as expected

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

still in arch/powerpc/platforms/52xx
git log
get log for the whole project

Shouldn't git log give the the log for the tree under the current directory?

jonsmirl@terra:~/mpc5200b/arch/powerpc/platforms/52xx$ git --version
git version 1.5.3.4.1458.g3e72e

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Johannes Schindelin]

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

> In project root:
>  git log arch/powerpc/platforms/52xx
> works as expected
> 
>  cd arch/powerpc/platforms/52xx
>  git log arch/powerpc/platforms/52xx
> fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions

Try "git log ."

Hth,
Dscho

Re: Inconsistencies with git log

[Jon Smirl]

On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 7 Nov 2007, Jon Smirl wrote:
>
> > In project root:
> >  git log arch/powerpc/platforms/52xx
> > works as expected
> >
> >  cd arch/powerpc/platforms/52xx
> >  git log arch/powerpc/platforms/52xx
> > fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> > revision or path not in the working tree.
> > Use '--' to separate paths from revisions
>
> Try "git log ."

Shouldn't git log default to "git log ."?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Johannes Schindelin]

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 7 Nov 2007, Jon Smirl wrote:
> >
> > > In project root:
> > >  git log arch/powerpc/platforms/52xx
> > > works as expected
> > >
> > >  cd arch/powerpc/platforms/52xx
> > >  git log arch/powerpc/platforms/52xx
> > > fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> > > revision or path not in the working tree.
> > > Use '--' to separate paths from revisions
> >
> > Try "git log ."
> 
> Shouldn't git log default to "git log ."?

Well, it is in line with the other commands being able to work on 
subdirectories, but doing the whole repository operation by default.

We also tend to take the approach of viewing the history as that of 
the whole project.

This approach also means that it is a much more expensive operation to log 
the history as seen by a subdirectory, which is another reason why it is 
not the default.

Hth,
Dscho

Re: Inconsistencies with git log

[Jon Smirl]

On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Shouldn't git log default to "git log ."?
>
> Well, it is in line with the other commands being able to work on
> subdirectories, but doing the whole repository operation by default.

I agree with this and see how it got this way.

> We also tend to take the approach of viewing the history as that of
> the whole project.

But if you type 'git log' while cd'd into a subdirectory the whole log
is almost never what you want. It's this kind of thing that makes git
harder to use.

> This approach also means that it is a much more expensive operation to log
> the history as seen by a subdirectory, which is another reason why it is
> not the default.
>
> Hth,
> Dscho
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Johannes Schindelin]

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 
> > We also tend to take the approach of viewing the history as that of 
> > the whole project.
> 
> But if you type 'git log' while cd'd into a subdirectory the whole log 
> is almost never what you want. It's this kind of thing that makes git 
> harder to use.

When I am working in a subdirectory, I often want the whole history.  For 
example, when I am working on the documentation, sometimes I need to look 
up a commit real quick, that touched other parts.

Besides, adding a space and a dot is not what qualifies for "harder to 
use" with this developer.

Ciao,
Dscho

Re: Inconsistencies with git log

[Jon Smirl]

On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Besides, adding a space and a dot is not what qualifies for "harder to
> use" with this developer.

It requires teaching people new to git to add the space dot.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Jon Smirl]

On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 7 Nov 2007, Jon Smirl wrote:
>
> > On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > We also tend to take the approach of viewing the history as that of
> > > the whole project.
> >
> > But if you type 'git log' while cd'd into a subdirectory the whole log
> > is almost never what you want. It's this kind of thing that makes git
> > harder to use.
>
> When I am working in a subdirectory, I often want the whole history.  For
> example, when I am working on the documentation, sometimes I need to look
> up a commit real quick, that touched other parts.
>
> Besides, adding a space and a dot is not what qualifies for "harder to
> use" with this developer.

So if git log is always whole tree, why doesn't this work?

 cd arch/powerpc/platforms/52xx
 git log arch/powerpc/platforms/52xx
fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
revision or path not in the working tree.
Use '--' to separate paths from revisions

It's not consistent. git log with no parameters is relative to the
project root, git log with a parameter is relative to the current
directory.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Johannes Schindelin]

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

> So if git log is always whole tree, why doesn't this work?

git log is not always the whole tree.  git log without arguments is.

>  cd arch/powerpc/platforms/52xx
>  git log arch/powerpc/platforms/52xx
> fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions
> 
> It's not consistent. git log with no parameters is relative to the 
> project root, git log with a parameter is relative to the current 
> directory.

It is consistent, when you realise that the path arguments are interpreted 
relative to the project root.

Hth,
Dscho

Re: Inconsistencies with git log

[Jon Smirl]

On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> It is consistent, when you realise that the path arguments are interpreted
> relative to the project root.

Then why doesn't this work?

jonsmirl@terra:~/mpc5200b$ git log Documentation
all the log for Documentation....
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
fatal: ambiguous argument 'Documentation': unknown revision or path
not in the working tree.
Use '--' to separate paths from revisions
jonsmirl@terra:~/mpc5200b/Documentation$



>
> Hth,
> Dscho
>
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Andreas Ericsson]

Jon Smirl wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> It is consistent, when you realise that the path arguments are interpreted
>> relative to the project root.
> 
> Then why doesn't this work?
> 
> jonsmirl@terra:~/mpc5200b$ git log Documentation
> all the log for Documentation....
> jonsmirl@terra:~/mpc5200b$ cd Documentation
> jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
> fatal: ambiguous argument 'Documentation': unknown revision or path
> not in the working tree.
> Use '--' to separate paths from revisions
> jonsmirl@terra:~/mpc5200b/Documentation$
> 

Because your current working directory, relative to the project root, is
prepended to the path you're in, so git sees "Documentation/Documentation".
I'm unsure why

	cd Documentation; git log -- /Documentation

doesn't do the trick though. I know that particular trick used to work for
some other command a while back anyways.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Inconsistencies with git log

[Johannes Schindelin]

Hi,

On Wed, 7 Nov 2007, Jon Smirl wrote:

> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > It is consistent, when you realise that the path arguments are interpreted
> > relative to the project root.
> 
> Then why doesn't this work?
> 
> jonsmirl@terra:~/mpc5200b$ git log Documentation
> all the log for Documentation....
> jonsmirl@terra:~/mpc5200b$ cd Documentation
> jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
> fatal: ambiguous argument 'Documentation': unknown revision or path
> not in the working tree.
> Use '--' to separate paths from revisions

Because you are in the subdirectory Documentation/, relative to the 
project root.  So when you say "Documentation", it tries to find the 
file/directory Documentation/Documentation.

Therefore, just say "git log ." and you will get what you want.

Ciao,
Dscho

Re: Inconsistencies with git log

[Linus Torvalds]

On Wed, 7 Nov 2007, Jon Smirl wrote:
> 
> Then why doesn't this work?

Jon, lookie here:

> jonsmirl@terra:~/mpc5200b$ git log Documentation
> all the log for Documentation....
> jonsmirl@terra:~/mpc5200b$ cd Documentation
> jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation

Instead of the above sequence, do:

	jonsmirl@terra:~/mpc5200b$ ls Documentation
	.. all the files in Documentation ..
	jonsmirl@terra:~/mpc5200b$ cd Documentation
	jonsmirl@terra:~/mpc5200b/Documentation$ ls Documentation

and now tell me, why doesn't that work? And can't you see how *stupid* 
your complaint is?

The rule is:
 - git log without arguments gives the whole, unabridged, and full 
   history.
 - git log with arguments gives the *simplified* history for those 
   arguments.

But the arguments - if they exist - are always relative. You want things 
like filename completion to work. Making the pathname arguments absolute 
would be horrible. Think about it: it's just much more logical to always 
be able to say "I want the log for file xyz", and you don't want that to 
be absolute, since you shouldn't care where in the tree you are.

And the fact that git log gives the whole history when you don't give any 
arguments at all IN NO WAY makes it any more sensible to give "absolute" 
pathnames. The history being "whole" has nothing to do with the pathnames 
being "absolute". The two are totally independent issues.

			Linus

Re: Inconsistencies with git log

[Jon Smirl]

On 11/9/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 7 Nov 2007, Jon Smirl wrote:
> >
> > Then why doesn't this work?
>
> Jon, lookie here:
>
> > jonsmirl@terra:~/mpc5200b$ git log Documentation
> > all the log for Documentation....
> > jonsmirl@terra:~/mpc5200b$ cd Documentation
> > jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
>
> Instead of the above sequence, do:
>
>         jonsmirl@terra:~/mpc5200b$ ls Documentation
>         .. all the files in Documentation ..
>         jonsmirl@terra:~/mpc5200b$ cd Documentation
>         jonsmirl@terra:~/mpc5200b/Documentation$ ls Documentation
>
> and now tell me, why doesn't that work? And can't you see how *stupid*
> your complaint is?

I never expected that to work it was just a response to the earlier
misstatement that the paths were relative to the project root. It
demonstrated that they were not.

The summary of this is that new users do not expect "git log" to give
them the whole log when the command is executed in a subdirectory.
This causes a training burden because of the unexpected behavior. They
try 'git log' and then I have to tell them to use "git log ."

>
> The rule is:
>  - git log without arguments gives the whole, unabridged, and full
>    history.
>  - git log with arguments gives the *simplified* history for those
>    arguments.
>
> But the arguments - if they exist - are always relative. You want things
> like filename completion to work. Making the pathname arguments absolute
> would be horrible. Think about it: it's just much more logical to always
> be able to say "I want the log for file xyz", and you don't want that to
> be absolute, since you shouldn't care where in the tree you are.
>
> And the fact that git log gives the whole history when you don't give any
> arguments at all IN NO WAY makes it any more sensible to give "absolute"
> pathnames. The history being "whole" has nothing to do with the pathnames
> being "absolute". The two are totally independent issues.
>
>                         Linus
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Linus Torvalds]

On Fri, 9 Nov 2007, Jon Smirl wrote:
> 
> The summary of this is that new users do not expect "git log" to give
> them the whole log when the command is executed in a subdirectory.
> This causes a training burden because of the unexpected behavior. They
> try 'git log' and then I have to tell them to use "git log ."

No. The summary is that *you* are confused.

The fact is, "git log" always has given the whole log, and there is no 
confusion at all. The only people who may be confused are people who 
misread the documentation on purpose, or who came from some broken other 
SCM, and are confused just because of *that*.

Git makes it very clear indeed at all points that it tracks whole history. 
It's a big deal. We *make* a big deal about it, and "git log" follows that 
very consistently.

In fact, even at the top-of-tree, "git log" and "git log ." are two 
totally different things, even if in practice the differences are often 
hard to see. But one gives the "full history", and the other gives the 
"simplified history for the pathnames given", and the two are REALLY 
REALLY different.

Try it. Do

	git log origin/pu > full
	git log origin/pu . > limited

in the git tree, and look at the differences (it might be useful to use 
gitk instead, and look at where the differences start! That visual 
difference is going to give you a lot more of an "Ahaa!" moment when you 
understand it). When you can explain and understand those differences, 
then you *really* understand git (and quite frankly, it's actually rather 
simple, but you have to really *think* about what those things things 
are).

Now, for normal use you never need to really to care. Git does a lot of 
things, and some random user will seldom need the full power of git, nor 
do they need to really care about why "git log ." and "git log" are 
actually not the same thing at all, even at the top level.

But you're blaming git for your *own* confusion, which probably comes from 
crap systems that don't even know what "history" is because they can't 
really track it right anyway.

		Linus

Re: Inconsistencies with git log

[Linus Torvalds]

On Fri, 9 Nov 2007, Linus Torvalds wrote:
> 
> In fact, even at the top-of-tree, "git log" and "git log ." are two 
> totally different things [...]

Btw, the reason (and really the *only* reason) this is interesting at all 
is just to show that the notion of "full history" and "relative pathnames" 
really have nothing to do with each other. They really are in totally 
different and orthogonal dimensions.

"Full history" is something that exist *independently* of the pathnames. 

So the fact is, "git log" on its own is really about the *project*. It is 
totally pathname-independent, and I'd argue that many people are often 
just interested in the explanations (even though you obviously can also 
see the patches and the files changed too!) so I seriously doubt that this 
is just an implementation issue or my personal hang-up.

In other words "git log" simply is something *global*. It doesn't matter 
where in the tree you are, the end result is the same - it's about the 
project as a whole.

In contrast, "git log <filename>" is fundamentally different. Now you're 
explicitly stating that it's not something global any more, and that it's 
about the *files*. That's also why "git log" and "git log ." are acually 
different even at the top level.

Because when you're interested in the files, by implication you're not 
interested in commits that don't change the files - and there can be such 
commits even when you give the *total* file list.  

			Linus

Re: Inconsistencies with git log

[Jon Smirl]

On 11/9/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 9 Nov 2007, Linus Torvalds wrote:
> >
> > In fact, even at the top-of-tree, "git log" and "git log ." are two
> > totally different things [...]
>
> Btw, the reason (and really the *only* reason) this is interesting at all
> is just to show that the notion of "full history" and "relative pathnames"
> really have nothing to do with each other. They really are in totally
> different and orthogonal dimensions.

Should "git log" and "git log path"  have two different command names?

> "Full history" is something that exist *independently* of the pathnames.
>
> So the fact is, "git log" on its own is really about the *project*. It is
> totally pathname-independent, and I'd argue that many people are often
> just interested in the explanations (even though you obviously can also
> see the patches and the files changed too!) so I seriously doubt that this
> is just an implementation issue or my personal hang-up.
>
> In other words "git log" simply is something *global*. It doesn't matter
> where in the tree you are, the end result is the same - it's about the
> project as a whole.
>
> In contrast, "git log <filename>" is fundamentally different. Now you're
> explicitly stating that it's not something global any more, and that it's
> about the *files*. That's also why "git log" and "git log ." are acually
> different even at the top level.
>
> Because when you're interested in the files, by implication you're not
> interested in commits that don't change the files - and there can be such
> commits even when you give the *total* file list.
>
>                         Linus
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Inconsistencies with git log

[Linus Torvalds]

On Fri, 9 Nov 2007, Jon Smirl wrote:
> 
> Should "git log" and "git log path"  have two different command names?

Do you think that would really help?

We actually have people complaining about the numebr of git commands 
already. And the thing is, "git log" is actually what things like "gitk" 
use to visualize the history, and all *those* commands want the two 
different modes too! You want a "global history" view in gitk, but you 
also want a "file limited view". So having two different commands is 
actually what people absolutely DO NOT want.

On the same note: several git commands have totally different fundamental 
behaviour based on arguments - in ways even more different than "git log". 
At least "git log" always shows a log, the arguments just change what 
*part* of the log they show.

For example, think about "git checkout": you can use it to check out 
individual files and directories, but you can obviously use it to switch 
branches (and create them!) too.  That's actually a much bigger difference 
than the different modes of "git log", but considering how many people 
have complained about "many different commands", I think people seem to be 
happier with commands that do somewhat related things just depending on 
the kinds of arguments they get.

		Linus

Re: Inconsistencies with git log

[Peter Baumann]

On Fri, Nov 09, 2007 at 09:53:00AM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 9 Nov 2007, Linus Torvalds wrote:
> > 
> > In fact, even at the top-of-tree, "git log" and "git log ." are two 
> > totally different things [...]
> 
> Btw, the reason (and really the *only* reason) this is interesting at all 
> is just to show that the notion of "full history" and "relative pathnames" 
> really have nothing to do with each other. They really are in totally 
> different and orthogonal dimensions.
> 
> "Full history" is something that exist *independently* of the pathnames. 
> 
> So the fact is, "git log" on its own is really about the *project*. It is 
> totally pathname-independent, and I'd argue that many people are often 
> just interested in the explanations (even though you obviously can also 
> see the patches and the files changed too!) so I seriously doubt that this 
> is just an implementation issue or my personal hang-up.
> 
> In other words "git log" simply is something *global*. It doesn't matter 
> where in the tree you are, the end result is the same - it's about the 
> project as a whole.
> 
> In contrast, "git log <filename>" is fundamentally different. Now you're 
> explicitly stating that it's not something global any more, and that it's 
> about the *files*. That's also why "git log" and "git log ." are acually 
> different even at the top level.
> 
> Because when you're interested in the files, by implication you're not 
> interested in commits that don't change the files - and there can be such 
> commits even when you give the *total* file list.  
> 

Hm. I tried to run your 'git log' and 'git log .' example and a diff
revealed that the output of those two isn't the same, contrary to what I
thought.

In the 'git-log .' case, there should be done a history simplification,
but then only commits which don't change anything are pruned and AFAIR
'git commit' doesn't allow this. Using core git, one could create commits
with the same tree as their parent, but I don't think that all the commits
which get removed in the '.' case where produced that way. There has to be
another case I can't figure out.

A little confused,
Peter

Re: Inconsistencies with git log

[Junio C Hamano]

Peter Baumann <waste.manager@gmx.de> writes:

> Hm. I tried to run your 'git log' and 'git log .' example and a diff
> revealed that the output of those two isn't the same, contrary to what I
> thought.
>
> In the 'git-log .' case, there should be done a history simplification,
> but then only commits which don't change anything are pruned and AFAIR
> 'git commit' doesn't allow this. Using core git, one could create commits
> with the same tree as their parent, but I don't think that all the commits
> which get removed in the '.' case where produced that way. There has to be
> another case I can't figure out.

The answer is "merges".

If a merge does not change the tree from one of the ancestors,
the side branches are pruned out, to give you _one_ explanation
of how you got there.  And by pruning such side branches, you
get the simpler explanation.

Linus gave the example of "log origin/pu ."; there is at least
one merge I am aware of that did not change any path (it is the
one that merges "jc/maint-format-patch-encoding" topic).  With
the path limiter, the merge commit and the two commits that
leads to it on the side branch are hidden away.

Re: Inconsistencies with git log

[Jakub Narebski]

Junio C Hamano wrote:

> Peter Baumann <waste.manager@gmx.de> writes:
> 
>> Hm. I tried to run your 'git log' and 'git log .' example and a diff
>> revealed that the output of those two isn't the same, contrary to what I
>> thought.
>>
>> In the 'git-log .' case, there should be done a history simplification,
>> but then only commits which don't change anything are pruned and AFAIR
>> 'git commit' doesn't allow this. Using core git, one could create commits
>> with the same tree as their parent, but I don't think that all the commits
>> which get removed in the '.' case where produced that way. There has to be
>> another case I can't figure out.
> 
> The answer is "merges".
> 
> If a merge does not change the tree from one of the ancestors,
> the side branches are pruned out, to give you _one_ explanation
> of how you got there.  And by pruning such side branches, you
> get the simpler explanation.
> 
> Linus gave the example of "log origin/pu ."; there is at least
> one merge I am aware of that did not change any path (it is the
> one that merges "jc/maint-format-patch-encoding" topic).  With
> the path limiter, the merge commit and the two commits that
> leads to it on the side branch are hidden away.

Does it mean that "git log" and "git log --full-history ." produce
the same output?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Inconsistencies with git log

[Peter Baumann]

On Fri, Nov 09, 2007 at 10:35:00AM -0800, Junio C Hamano wrote:
> Peter Baumann <waste.manager@gmx.de> writes:
> 
> > Hm. I tried to run your 'git log' and 'git log .' example and a diff
> > revealed that the output of those two isn't the same, contrary to what I
> > thought.
> >
> > In the 'git-log .' case, there should be done a history simplification,
> > but then only commits which don't change anything are pruned and AFAIR
> > 'git commit' doesn't allow this. Using core git, one could create commits
> > with the same tree as their parent, but I don't think that all the commits
> > which get removed in the '.' case where produced that way. There has to be
> > another case I can't figure out.
> 
> The answer is "merges".
> 
> If a merge does not change the tree from one of the ancestors,
> the side branches are pruned out, to give you _one_ explanation
> of how you got there.  And by pruning such side branches, you
> get the simpler explanation.
> 
> Linus gave the example of "log origin/pu ."; there is at least
> one merge I am aware of that did not change any path (it is the
> one that merges "jc/maint-format-patch-encoding" topic).  With
> the path limiter, the merge commit and the two commits that
> leads to it on the side branch are hidden away.

Doh. Could have figured this out myself. But thank your for the explanation.

-Peter

Re: Inconsistencies with git log

[Linus Torvalds]

On Fri, 9 Nov 2007, Peter Baumann wrote:
> 
> Hm. I tried to run your 'git log' and 'git log .' example and a diff
> revealed that the output of those two isn't the same, contrary to what I
> thought.

Btw, you can *make* them the same by using

	git log --full-history --sparse .

which basically tells git that you do not want any of the history 
simplification that git log does by default.

There's two different kinds of simplifications (which is why there are two 
kinds of switches above):

 - the "simplify merges to just the parent that is identical"

   This basically means that if a merge result comes 100% from one of the 
   parents, by default we will only look at that parent. Using 
   --full-history avoids this.

 - the "dense" history, which removes simple commits that don't make any 
   changes

   This is the "--sparse" thing: it says that we're interested even in 
   regular commits that simply don't make any changes.

> In the 'git-log .' case, there should be done a history simplification,
> but then only commits which don't change anything are pruned and AFAIR
> 'git commit' doesn't allow this.

Actually, git itself creates these commits under several circumstances:

 - you can *force* it. No, "git commit" on its own doesn't allow it, but 
   you can do it quite easily with "git commit-tree" and setting things 
   up by hand.

 - you can import history from other SCM's. I think all importers will 
   honor other SCM's, and if they allow empty commits then the end result 
   will have empty commits in it too!

 - merges. This is the common case. You have a "git merge --ours" or 
   similar, which basically merges just one side (or, even without 
   "--ours", this is really common for the non-"." case: a merge just 
   doesn't touch some files at all). Then, the merge simplifier will first 
   turn it into a "single parent", and then densification will remove that 
   (now uninteresting) empty merge.

> Using core git, one could create commits with the same tree as their 
> parent, but I don't think that all the commits which get removed in the 
> '.' case where produced that way. There has to be another case I can't 
> figure out.

See above. Three cases, in fact.

		Linus

Re: Inconsistencies with git log

[Jakub Narebski]

Jon Smirl wrote:

> The summary of this is that new users do not expect "git log" to give
> them the whole log when the command is executed in a subdirectory.
> This causes a training burden because of the unexpected behavior. They
> try 'git log' and then I have to tell them to use "git log ."

That's too bad, that they have to unlearn bad expectations. Having
"git log" _always_ meaning whole history is very useful. You can always
do "git log ." (two characters more); how do you propose to request
full history from within subdirectory if by default "git log" output
would limit history to current directory only?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Inconsistencies with git log

[Wincent Colaiuta]

El 8/11/2007, a las 0:29, Jon Smirl escribió:

> It's not consistent. git log with no parameters is relative to the
> project root, git log with a parameter is relative to the current
> directory.

A minor quibble: git log with no parameters isn't "relative" to  
anything. It shows the history of the entire project. There is no  
inconsistency.

Cheers,
Wincent

Re: Inconsistencies with git log

[Daniel Barkalow]

On Wed, 7 Nov 2007, Jon Smirl wrote:

> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 7 Nov 2007, Jon Smirl wrote:
> >
> > > On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > > We also tend to take the approach of viewing the history as that of
> > > > the whole project.
> > >
> > > But if you type 'git log' while cd'd into a subdirectory the whole log
> > > is almost never what you want. It's this kind of thing that makes git
> > > harder to use.
> >
> > When I am working in a subdirectory, I often want the whole history.  For
> > example, when I am working on the documentation, sometimes I need to look
> > up a commit real quick, that touched other parts.
> >
> > Besides, adding a space and a dot is not what qualifies for "harder to
> > use" with this developer.
> 
> So if git log is always whole tree, why doesn't this work?
> 
>  cd arch/powerpc/platforms/52xx
>  git log arch/powerpc/platforms/52xx
> fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> revision or path not in the working tree.
> Use '--' to separate paths from revisions
> 
> It's not consistent. git log with no parameters is relative to the
> project root, git log with a parameter is relative to the current
> directory.

git log with no parameters is still relative to the current directory. 
It's just not limited by paths at all, so what it's relative to doesn't 
matter.

Since it shows is commits that change any of the given paths, the 
perfectly consistant thing to do without any paths would be to show no 
commits. Of course, that's totally useless, so we default to making no 
limitation instead.

If there were any other options that took paths or filenames, they'd be 
relative to the subdirectory, regardless of whether there were any paths, 
and having no paths would still show history for the project without 
regard to whether commits touch paths.

	-Daniel
*This .sig left intentionally blank*

Re: Inconsistencies with git log

[Brian Gernhardt]

On Nov 7, 2007, at 6:03 PM, Jon Smirl wrote:

> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>> We also tend to take the approach of viewing the history as that of
>> the whole project.
>
> But if you type 'git log' while cd'd into a subdirectory the whole log
> is almost never what you want. It's this kind of thing that makes git
> harder to use.

Here's where I'd have to disagree with you.  If I'm in git.git/ 
Documentation and am trying to remember which commit I'm trying to  
document, suddenly having 90+% of the history vanish would make git  
harder to use.  Same with my rails projects, my mudlib, etc.  Hiding  
history is a bad default.

I think the problem is that you're still thinking in the CVS-style per- 
file history.  "git log" works on the history not the files, so the  
automatic filtering simply doesn't make sense.  Git's whole-tree  
approach makes it much easier to find when Makefile or API changes  
have broken your code.  But if you know that the error is in a  
specific place, then using "." lets you get at it.

However, Dave's suggestion of altering git-status output to be  
relative to (but not limited by) CWD has merit.  Too bad I don't have  
time to work on it right now.

~~ Brian Gernhardt

Re: Inconsistencies with git log

[David Symonds]

On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>
> However, Dave's suggestion of altering git-status output to be
> relative to (but not limited by) CWD has merit.  Too bad I don't have
> time to work on it right now.

I am happy to hack on this if there's not widespread revolt against the concept.


Dave.

Re: Inconsistencies with git log

[Johannes Schindelin]

Hi,

On Thu, 8 Nov 2007, David Symonds wrote:

> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
> >
> > However, Dave's suggestion of altering git-status output to be 
> > relative to (but not limited by) CWD has merit.  Too bad I don't have 
> > time to work on it right now.
> 
> I am happy to hack on this if there's not widespread revolt against the 
> concept.

Too late ;-)

Ciao,
Dscho

Re: Inconsistencies with git log

[David Symonds]

On Nov 8, 2007 11:09 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Thu, 8 Nov 2007, David Symonds wrote:
>
> > On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
> > >
> > > However, Dave's suggestion of altering git-status output to be
> > > relative to (but not limited by) CWD has merit.  Too bad I don't have
> > > time to work on it right now.
> >
> > I am happy to hack on this if there's not widespread revolt against the
> > concept.
>
> Too late ;-)

I see that you're revolting against relative paths in git-log; I agree
with you on that. I'm proposing changing the output to git-status so
that it produces relative paths, which are suitable for
git-add/git-rm/git-diff/...


Dave.

Re: Inconsistencies with git log

[Brian Gernhardt]

On Nov 7, 2007, at 7:14 PM, David Symonds wrote:

> On Nov 8, 2007 11:09 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de 
> > wrote:
>> Too late ;-)
>
> I see that you're revolting against relative paths in git-log; I agree
> with you on that. I'm proposing changing the output to git-status so
> that it produces relative paths

Johannes was referring to the fact that he already produced that  
patches for it.  :-)

~~ Brian

[PATCH 1/2] Makefile: wt-status.h is also a lib header

[Johannes Schindelin]

When a struct in wt-status.h changes, many files need to be rebuilt.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index e5dc63b..dad9c5a 100644
--- a/Makefile
+++ b/Makefile
@@ -288,7 +288,8 @@ LIB_H = \
 	run-command.h strbuf.h tag.h tree.h git-compat-util.h revision.h \
 	tree-walk.h log-tree.h dir.h path-list.h unpack-trees.h builtin.h \
 	utf8.h reflog-walk.h patch-ids.h attr.h decorate.h progress.h \
-	mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h
+	mailmap.h remote.h parse-options.h transport.h diffcore.h hash.h \
+	wt-status.h
 
 DIFF_OBJS = \
 	diff.o diff-lib.o diffcore-break.o diffcore-order.o \
-- 
1.5.3.5.1597.g7191

Re: Inconsistencies with git log

[Andreas Ericsson]

David Symonds wrote:
> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>> However, Dave's suggestion of altering git-status output to be
>> relative to (but not limited by) CWD has merit.  Too bad I don't have
>> time to work on it right now.
> 
> I am happy to hack on this if there's not widespread revolt against the concept.
> 

I'd definitely like that feature, but I wonder how many people will run
"git commit -a" in a subdir after seeing only what they want to see in the
output, and then accidentally committing junk somewhere else in the repo.

So perhaps git-commit -a should also be path-delimited, but where would we
end up then? It might be better to just let git-status accept a path
delimiter and let the path delimiter default to current work-dir.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Inconsistencies with git log

[Peter Baumann]

On Thu, Nov 08, 2007 at 01:11:01AM +0100, Andreas Ericsson wrote:
> David Symonds wrote:
>> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>>> However, Dave's suggestion of altering git-status output to be
>>> relative to (but not limited by) CWD has merit.  Too bad I don't have
>>> time to work on it right now.
>>
>> I am happy to hack on this if there's not widespread revolt against the concept.
>>
>
> I'd definitely like that feature, but I wonder how many people will run
> "git commit -a" in a subdir after seeing only what they want to see in the
> output, and then accidentally committing junk somewhere else in the repo.
>
> So perhaps git-commit -a should also be path-delimited, but where would we
> end up then? It might be better to just let git-status accept a path
> delimiter and let the path delimiter default to current work-dir.
>

I agree that 'git status' should show the *whole* tree and if it will work
in subdirectories with 'git status .' or 'git status Documentation', it
would be a nice UI improvement.

But please don't make it always show only the current subdir.

-Peter

Re: Inconsistencies with git log

[David Symonds]

On Nov 8, 2007 11:11 AM, Andreas Ericsson <ae@op5.se> wrote:
>
> David Symonds wrote:
> > On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
> >> However, Dave's suggestion of altering git-status output to be
> >> relative to (but not limited by) CWD has merit.  Too bad I don't have
> >> time to work on it right now.
> >
> > I am happy to hack on this if there's not widespread revolt against the concept.
> >
>
> I'd definitely like that feature, but I wonder how many people will run
> "git commit -a" in a subdir after seeing only what they want to see in the
> output, and then accidentally committing junk somewhere else in the repo.

I never suggested path *limited*, only path *relative*. git-status
would still show all the same files, but their paths would be relative
to your current directory, so there'd be no confusion like you
mentioned. This is how Johannes' patch works.


Dave.

Re: Inconsistencies with git log

[Andreas Ericsson]

David Symonds wrote:
> On Nov 8, 2007 11:11 AM, Andreas Ericsson <ae@op5.se> wrote:
>> David Symonds wrote:
>>> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>>>> However, Dave's suggestion of altering git-status output to be
>>>> relative to (but not limited by) CWD has merit.  Too bad I don't have
>>>> time to work on it right now.
>>> I am happy to hack on this if there's not widespread revolt against the concept.
>>>
>> I'd definitely like that feature, but I wonder how many people will run
>> "git commit -a" in a subdir after seeing only what they want to see in the
>> output, and then accidentally committing junk somewhere else in the repo.
> 
> I never suggested path *limited*, only path *relative*. git-status
> would still show all the same files, but their paths would be relative
> to your current directory, so there'd be no confusion like you
> mentioned. This is how Johannes' patch works.
> 

Ah, that'd be a different matter entirely then. Thanks for clarifying. I
have no further objections then.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Inconsistencies with git log

[Alex Riesen]

David Symonds, Thu, Nov 08, 2007 14:16:59 +0100:
> I never suggested path *limited*, only path *relative*. git-status
> would still show all the same files, but their paths would be relative
> to your current directory, so there'd be no confusion like you
> mentioned. This is how Johannes' patch works.

Relative? Like this?

$ cd project/foo/bar
$ git status
...
    M file1.c
    M file2.c
    M ../baz/file3.c
    R ../bax/file4 => file4.c

Re: Inconsistencies with git log

[Alex Riesen]

Alex Riesen, Thu, Nov 08, 2007 22:21:23 +0100:
> David Symonds, Thu, Nov 08, 2007 14:16:59 +0100:
> > I never suggested path *limited*, only path *relative*. git-status
> > would still show all the same files, but their paths would be relative
> > to your current directory, so there'd be no confusion like you
> > mentioned. This is how Johannes' patch works.
> 
> Relative? Like this?
> 
> $ cd project/foo/bar
> $ git status
> ...
>     M file1.c
>     M file2.c
>     M ../baz/file3.c
>     R ../bax/file4 => file4.c
> 

Oh, I see. Yes. Cool.

[PATCH 2/2] git status: show relative paths when run in a subdirectory

[Johannes Schindelin]

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	This looks a bit ugly because quote_crlf() is now also called
	on the untracked files, which are not NUL terminated.

	Maybe someone has an idea how to do this more elegantly.

 builtin-runstatus.c |    1 +
 wt-status.c         |   50 ++++++++++++++++++++++++++++++++++++++++++--------
 wt-status.h         |    1 +
 3 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/builtin-runstatus.c b/builtin-runstatus.c
index 2db25c8..8d167a9 100644
--- a/builtin-runstatus.c
+++ b/builtin-runstatus.c
@@ -14,6 +14,7 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)
 
 	git_config(git_status_config);
 	wt_status_prepare(&s);
+	s.prefix = prefix;
 
 	for (i = 1; i < argc; i++) {
 		if (!strcmp(argv[i], "--color"))
diff --git a/wt-status.c b/wt-status.c
index 03b5ec4..7386d41 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -82,16 +82,48 @@ static void wt_status_print_trailer(struct wt_status *s)
 	color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
 }
 
-static const char *quote_crlf(const char *in, char *buf, size_t sz)
+static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
+	const char *prefix)
 {
 	const char *scan;
 	char *out;
 	const char *ret = in;
+	int off = 0;
+
+	if (len < 0)
+		len = strlen(in);
+
+	if (prefix) {
+		while (prefix[off] && off < len && prefix[off] == in[off])
+			if (prefix[off] == '/') {
+				prefix += off + 1;
+				in += off + 1;
+				len -= off + 1;
+				off = 0;
+			} else
+				off++;
+		for (off = 0; *prefix; prefix++)
+			if (*prefix == '/') {
+				if (off + 4 >= sz) {
+					warning ("Could not prefix path: %s",
+						in);
+					return in;
+				}
+				strcpy(buf + off, "../");
+				off += 3;
+			}
+		ret = buf;
+	}
 
-	for (scan = in, out = buf; *scan; scan++) {
+	for (scan = in, out = buf + off; len; scan++, len--) {
 		int ch = *scan;
 		int quoted;
 
+		if (out - buf + 3 >= sz) {
+			warning ("Could not quote path: %s", in);
+			break;
+		}
+
 		switch (ch) {
 		case '\n':
 			quoted = 'n';
@@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
 	const char *one, *two;
 	char onebuf[PATH_MAX], twobuf[PATH_MAX];
 
-	one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
-	two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
+	one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
+	two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);
 
 	color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
 	switch (p->status) {
@@ -215,8 +247,8 @@ static void wt_status_print_initial(struct wt_status *s)
 	for (i = 0; i < active_nr; i++) {
 		color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
 		color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
-				quote_crlf(active_cache[i]->name,
-					   buf, sizeof(buf)));
+				quote_crlf(active_cache[i]->name, -1,
+					   buf, sizeof(buf), s->prefix));
 	}
 	if (active_nr)
 		wt_status_print_trailer(s);
@@ -254,6 +286,7 @@ static void wt_status_print_untracked(struct wt_status *s)
 	const char *x;
 	int i;
 	int shown_header = 0;
+	char buf[PATH_MAX];
 
 	memset(&dir, 0, sizeof(dir));
 
@@ -291,8 +324,9 @@ static void wt_status_print_untracked(struct wt_status *s)
 			shown_header = 1;
 		}
 		color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
-		color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%.*s",
-				ent->len, ent->name);
+		color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%s",
+				quote_crlf(ent->name, ent->len,
+					buf, sizeof(buf), s->prefix));
 	}
 }
 
diff --git a/wt-status.h b/wt-status.h
index 7744932..f58ebcb 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -23,6 +23,7 @@ struct wt_status {
 	int workdir_untracked;
 	const char *index_file;
 	FILE *fp;
+	const char *prefix;
 };
 
 int git_status_config(const char *var, const char *value);
-- 
1.5.3.5.1597.g7191

Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory

[David Symonds]

On Nov 8, 2007 11:12 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
>         This looks a bit ugly because quote_crlf() is now also called
>         on the untracked files, which are not NUL terminated.
>
>         Maybe someone has an idea how to do this more elegantly.
>
>  builtin-runstatus.c |    1 +
>  wt-status.c         |   50 ++++++++++++++++++++++++++++++++++++++++++--------
>  wt-status.h         |    1 +
>  3 files changed, 44 insertions(+), 8 deletions(-)

Tested, and looks good.

Now that I play with it, though, it seems that a few other bits of git
need updating to handle relative paths okay:

$ cd gitweb/test
$ rm ../../wt-status.h
    [oops, what a silly thing to do -- better checkout the latest
revision of it]
$ git status
# On branch next
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#
#       deleted:    ../../wt-status.h
no changes added to commit (use "git add" and/or "git commit -a")
$ git checkout HEAD ../../wt-status.h
fatal: git-ls-files: cannot generate relative filenames containing '..'
    [grr....]
$ cd ../..
$ git checkout HEAD .
    [that works]



Dave.

Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory

[Johannes Schindelin]

Hi,

On Thu, 8 Nov 2007, David Symonds wrote:

> On Nov 8, 2007 11:12 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> >
> >         This looks a bit ugly because quote_crlf() is now also called
> >         on the untracked files, which are not NUL terminated.
> >
> >         Maybe someone has an idea how to do this more elegantly.
> >
> >  builtin-runstatus.c |    1 +
> >  wt-status.c         |   50 ++++++++++++++++++++++++++++++++++++++++++--------
> >  wt-status.h         |    1 +
> >  3 files changed, 44 insertions(+), 8 deletions(-)
> 
> Tested, and looks good.
> 
> Now that I play with it, though, it seems that a few other bits of git
> need updating to handle relative paths okay:
> 
> $ cd gitweb/test
> $ rm ../../wt-status.h
>     [oops, what a silly thing to do -- better checkout the latest
> revision of it]
> $ git status
> # On branch next
> # Changed but not updated:
> #   (use "git add/rm <file>..." to update what will be committed)
> #
> #       deleted:    ../../wt-status.h
> no changes added to commit (use "git add" and/or "git commit -a")
> $ git checkout HEAD ../../wt-status.h
> fatal: git-ls-files: cannot generate relative filenames containing '..'
>     [grr....]
> $ cd ../..
> $ git checkout HEAD .
>     [that works]

Well, now that I did all the hard work with git-status, I leave this easy 
exercise for you ;-)

Ciao,
Dscho

Re: [PATCH 2/2] git status: show relative paths when run in a subdirectory

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> -static const char *quote_crlf(const char *in, char *buf, size_t sz)
> +static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
> +	const char *prefix)
>  {

This is not quote_*crlf* anymore.

> @@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
>  	const char *one, *two;
>  	char onebuf[PATH_MAX], twobuf[PATH_MAX];
>  
> -	one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
> -	two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
> +	one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
> +	two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);

I wonder if it makes more sense to use strbuf here...

[PATCH REPLACEMENT for 2/2] git status: show relative paths when run in a subdirectory

[Johannes Schindelin]

To show the relative paths, the function formerly called quote_crlf()
(now called quote_path()) takes the prefix as an additional argument.

While at it, the static buffers were replaced by strbufs.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	On Thu, 8 Nov 2007, Junio C Hamano wrote:

	> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
	> 
	> > -static const char *quote_crlf(const char *in, char *buf, size_t sz)
	> > +static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
	> > +	const char *prefix)
	> >  {
	> 
	> This is not quote_*crlf* anymore.
	> 
	> > @@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
	> >  	const char *one, *two;
	> >  	char onebuf[PATH_MAX], twobuf[PATH_MAX];
	> >  
	> > -	one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
	> > -	two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
	> > +	one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
	> > +	two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);
	> 
	> I wonder if it makes more sense to use strbuf here...

	Here you are.

 builtin-runstatus.c |    1 +
 t/t7502-status.sh   |   91 +++++++++++++++++++++++++++++++++++++++++++++++++++
 wt-status.c         |   69 ++++++++++++++++++++++++++-------------
 wt-status.h         |    1 +
 4 files changed, 139 insertions(+), 23 deletions(-)
 create mode 100755 t/t7502-status.sh

diff --git a/builtin-runstatus.c b/builtin-runstatus.c
index 2db25c8..8d167a9 100644
--- a/builtin-runstatus.c
+++ b/builtin-runstatus.c
@@ -14,6 +14,7 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)
 
 	git_config(git_status_config);
 	wt_status_prepare(&s);
+	s.prefix = prefix;
 
 	for (i = 1; i < argc; i++) {
 		if (!strcmp(argv[i], "--color"))
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
new file mode 100755
index 0000000..269b334
--- /dev/null
+++ b/t/t7502-status.sh
@@ -0,0 +1,91 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='git-status'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+	: > tracked &&
+	: > modified &&
+	mkdir dir1 &&
+	: > dir1/tracked &&
+	: > dir1/modified &&
+	mkdir dir2 &&
+	: > dir1/tracked &&
+	: > dir1/modified &&
+	git add . &&
+	test_tick &&
+	git commit -m initial &&
+	: > untracked &&
+	: > dir1/untracked &&
+	: > dir2/untracked &&
+	echo 1 > dir1/modified &&
+	echo 2 > dir2/modified &&
+	echo 3 > dir2/added &&
+	git add dir2/added
+'
+
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#	new file:   dir2/added
+#
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
+#
+#	modified:   dir1/modified
+#
+# Untracked files:
+#   (use "git add <file>..." to include in what will be committed)
+#
+#	dir1/untracked
+#	dir2/modified
+#	dir2/untracked
+#	expect
+#	output
+#	untracked
+EOF
+
+test_expect_success 'status' '
+
+	git status > output &&
+	git diff expect output
+
+'
+
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+#   (use "git reset HEAD <file>..." to unstage)
+#
+#	new file:   ../dir2/added
+#
+# Changed but not updated:
+#   (use "git add <file>..." to update what will be committed)
+#
+#	modified:   ../dir1/modified
+#
+# Untracked files:
+#   (use "git add <file>..." to include in what will be committed)
+#
+#	untracked
+#	../dir2/modified
+#	../dir2/untracked
+#	../expect
+#	../output
+#	../untracked
+EOF
+
+test_expect_success 'status with relative paths' '
+
+	(cd dir1 && git status) > output &&
+	git diff expect output
+
+'
+
+test_done
diff --git a/wt-status.c b/wt-status.c
index 03b5ec4..0d25362 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -82,33 +82,46 @@ static void wt_status_print_trailer(struct wt_status *s)
 	color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
 }
 
-static const char *quote_crlf(const char *in, char *buf, size_t sz)
+static char *quote_path(const char *in, int len,
+		struct strbuf *out, const char *prefix)
 {
-	const char *scan;
-	char *out;
-	const char *ret = in;
+	if (len > 0)
+		strbuf_grow(out, len);
+	strbuf_setlen(out, 0);
+
+	if (prefix) {
+		int off = 0;
+		while (prefix[off] && off < len && prefix[off] == in[off])
+			if (prefix[off] == '/') {
+				prefix += off + 1;
+				in += off + 1;
+				len -= off + 1;
+				off = 0;
+			} else
+				off++;
+
+		for (; *prefix; prefix++)
+			if (*prefix == '/')
+				strbuf_addstr(out, "../");
+	}
 
-	for (scan = in, out = buf; *scan; scan++) {
-		int ch = *scan;
-		int quoted;
+	for (; (len < 0 && *in) || len > 0; in++, len--) {
+		int ch = *in;
 
 		switch (ch) {
 		case '\n':
-			quoted = 'n';
+			strbuf_addstr(out, "\\n");
 			break;
 		case '\r':
-			quoted = 'r';
+			strbuf_addstr(out, "\\r");
 			break;
 		default:
-			*out++ = ch;
+			strbuf_addch(out, ch);
 			continue;
 		}
-		*out++ = '\\';
-		*out++ = quoted;
-		ret = buf;
 	}
-	*out = '\0';
-	return ret;
+
+	return out->buf;
 }
 
 static void wt_status_print_filepair(struct wt_status *s,
@@ -116,10 +129,12 @@ static void wt_status_print_filepair(struct wt_status *s,
 {
 	const char *c = color(t);
 	const char *one, *two;
-	char onebuf[PATH_MAX], twobuf[PATH_MAX];
+	struct strbuf onebuf, twobuf;
 
-	one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
-	two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
+	strbuf_init(&onebuf, 0);
+	strbuf_init(&twobuf, 0);
+	one = quote_path(p->one->path, -1, &onebuf, s->prefix);
+	two = quote_path(p->two->path, -1, &twobuf, s->prefix);
 
 	color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
 	switch (p->status) {
@@ -151,6 +166,8 @@ static void wt_status_print_filepair(struct wt_status *s,
 		die("bug: unhandled diff status %c", p->status);
 	}
 	fprintf(s->fp, "\n");
+	strbuf_release(&onebuf);
+	strbuf_release(&twobuf);
 }
 
 static void wt_status_print_updated_cb(struct diff_queue_struct *q,
@@ -205,8 +222,9 @@ static void wt_read_cache(struct wt_status *s)
 static void wt_status_print_initial(struct wt_status *s)
 {
 	int i;
-	char buf[PATH_MAX];
+	struct strbuf buf;
 
+	strbuf_init(&buf, 0);
 	wt_read_cache(s);
 	if (active_nr) {
 		s->commitable = 1;
@@ -215,11 +233,12 @@ static void wt_status_print_initial(struct wt_status *s)
 	for (i = 0; i < active_nr; i++) {
 		color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
 		color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
-				quote_crlf(active_cache[i]->name,
-					   buf, sizeof(buf)));
+				quote_path(active_cache[i]->name, -1,
+					   &buf, s->prefix));
 	}
 	if (active_nr)
 		wt_status_print_trailer(s);
+	strbuf_release(&buf);
 }
 
 static void wt_status_print_updated(struct wt_status *s)
@@ -254,7 +273,9 @@ static void wt_status_print_untracked(struct wt_status *s)
 	const char *x;
 	int i;
 	int shown_header = 0;
+	struct strbuf buf;
 
+	strbuf_init(&buf, 0);
 	memset(&dir, 0, sizeof(dir));
 
 	dir.exclude_per_dir = ".gitignore";
@@ -291,9 +312,11 @@ static void wt_status_print_untracked(struct wt_status *s)
 			shown_header = 1;
 		}
 		color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
-		color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%.*s",
-				ent->len, ent->name);
+		color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%s",
+				quote_path(ent->name, ent->len,
+					&buf, s->prefix));
 	}
+	strbuf_release(&buf);
 }
 
 static void wt_status_print_verbose(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 7744932..f58ebcb 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -23,6 +23,7 @@ struct wt_status {
 	int workdir_untracked;
 	const char *index_file;
 	FILE *fp;
+	const char *prefix;
 };
 
 int git_status_config(const char *var, const char *value);
-- 
1.5.3.5.1645.g1f4df

Re: [PATCH REPLACEMENT for 2/2] git status: show relative paths when run in a subdirectory

[Michel Marti]

Untracked files in the current dir don't include the relative path 
to the project-root, but changed/updated files do:

# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file: ../subdir/hello
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       world

With the patch below (on top of your changes), the output becomes

# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file: hello
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       world

Cheers,

- Michel

diff --git a/wt-status.c b/wt-status.c
index 0d25362..2cdc8ce 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -133,8 +133,8 @@ static void wt_status_print_filepair(struct wt_status *s,
 
        strbuf_init(&onebuf, 0);
        strbuf_init(&twobuf, 0);
-       one = quote_path(p->one->path, -1, &onebuf, s->prefix);
-       two = quote_path(p->two->path, -1, &twobuf, s->prefix);
+       one = quote_path(p->one->path, strlen(p->one->path), &onebuf, s->prefix);
+       two = quote_path(p->two->path, strlen(p->two->path), &twobuf, s->prefix);
 
        color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
        switch (p->status) {
@@ -233,7 +233,8 @@ static void wt_status_print_initial(struct wt_status *s)
        for (i = 0; i < active_nr; i++) {
                color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
                color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
-                               quote_path(active_cache[i]->name, -1,
+                               quote_path(active_cache[i]->name,
+                                       strlen(active_cache[i]->name),
                                           &buf, s->prefix));
        }
        if (active_nr)

Re: [PATCH REPLACEMENT for 2/2] git status: show relative paths when run in a subdirectory

[Johannes Schindelin]

Hi,

please, please, please do not cull the Cc list.  I consider it rude to 
reply to _me_, but _address_ the mail to me, either the To: (preferred) or 
the Cc: (not so preferred).

On Sat, 10 Nov 2007, Michel Marti wrote:

> Untracked files in the current dir don't include the relative path 
> to the project-root, but changed/updated files do:
> 
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #       new file: ../subdir/hello
> #
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #       world
> 
> With the patch below (on top of your changes), the output becomes
> 
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #       new file: hello
> #
> # Untracked files:
> #   (use "git add <file>..." to include in what will be committed)
> #
> #       world
> 
> Cheers,
> 
> - Michel
> 
> diff --git a/wt-status.c b/wt-status.c
> index 0d25362..2cdc8ce 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -133,8 +133,8 @@ static void wt_status_print_filepair(struct wt_status *s,
>  
>         strbuf_init(&onebuf, 0);
>         strbuf_init(&twobuf, 0);
> -       one = quote_path(p->one->path, -1, &onebuf, s->prefix);
> -       two = quote_path(p->two->path, -1, &twobuf, s->prefix);
> +       one = quote_path(p->one->path, strlen(p->one->path), &onebuf, s->prefix);
> +       two = quote_path(p->two->path, strlen(p->two->path), &twobuf, s->prefix);
>  
>         color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
>         switch (p->status) {
> @@ -233,7 +233,8 @@ static void wt_status_print_initial(struct wt_status *s)
>         for (i = 0; i < active_nr; i++) {
>                 color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
>                 color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
> -                               quote_path(active_cache[i]->name, -1,
> +                               quote_path(active_cache[i]->name,
> +                                       strlen(active_cache[i]->name),
>                                            &buf, s->prefix));
>         }
>         if (active_nr)
> 

This patch is wrong.

If you want to go that way, move the strlen() call _into_ quote_path(), 
like I had it earlier.

But then we will have a double traversal of the strings again.  That's 
what I tried to avoid, but I missed one place:

In line 94, it says "... && off < len && ...".  This should read something 
like "((len < 0 && !in[off]) || off < len)" instead.  Or maybe even "(len 
< 0 || off < len)" and have an "} else if (in[off]) off++; else break;" in 
the loop block.

Besides, you completely ignored the nice examples how other people 
contribute their patches, with mail bodies that double as a commit 
message, a diffstat, and with a test case.

Hth,
Dscho

Re: Inconsistencies with git log

[Wincent Colaiuta]

El 8/11/2007, a las 0:03, Jon Smirl escribió:

> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>>
>> We also tend to take the approach of viewing the history as that of
>> the whole project.
>
> But if you type 'git log' while cd'd into a subdirectory the whole log
> is almost never what you want. It's this kind of thing that makes git
> harder to use.

At least in my case, that's completely untrue. Whole-project history  
is basically *always* what I want even if I am cd'd into a  
subdirectory. If I wanted to path-limit the project history I'd do  
"git log ."

Cheers,
Wincent

Re: Inconsistencies with git log

[Miles Bader]

"Jon Smirl" <jonsmirl@gmail.com> writes:
> But if you type 'git log' while cd'd into a subdirectory the whole log
> is almost never what you want. It's this kind of thing that makes git
> harder to use.

Actually I almost always want the "whole project history" when cd'd to a
subdir.

Git's convention of doing the whole project by default, but allowing "."
(or any other directory name) to narrow it down seems almost perfect to
me.

-Miles

-- 
"Don't just question authority,
Don't forget to question me."
-- Jello Biafra

Re: Inconsistencies with git log

[David Symonds]

On Nov 8, 2007 9:45 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Hi,
> >
> > On Wed, 7 Nov 2007, Jon Smirl wrote:
> >
> > > In project root:
> > >  git log arch/powerpc/platforms/52xx
> > > works as expected
> > >
> > >  cd arch/powerpc/platforms/52xx
> > >  git log arch/powerpc/platforms/52xx
> > > fatal: ambiguous argument 'arch/powerpc/platforms/52xx': unknown
> > > revision or path not in the working tree.
> > > Use '--' to separate paths from revisions
> >
> > Try "git log ."
>
> Shouldn't git log default to "git log ."?

It might be nice if it did, but since Git tracks whole *trees* (not
files) then it makes more sense to show the log of the repository in
its default mode.

On the other hand, it'd sure be nice if git-status would show relative
paths when you're in subdirectories, especially when you're in a
deeply nested directory hierarchy. It's a lot easier to see that
"foo.txt" and "../bar.txt" have modifications. Furthermore, it is the
relative path that you have to pass to git-add anyway, so quick
copy-n-pasting from git-status output often doesn't work.


Dave.