Re: Global .git directory

> On Wed, Apr 28, 2010 at 07:33, Gerhard Wiesinger <lists@wiesinger.com> wrote:
>> On Tue, 27 Apr 2010, Erik Faye-Lund wrote:
>>> Please see Documentation/SubmittingPatches. It's difficult to
>>> comment on a non-inlined patch.
>>
>> Patch done on top of HEAD.
>
> The patches "done on top of HEAD" are usually useless for
> everyone, including the submitter. HEAD changes over time.
> for instance I wont be able to apply your patches on my HEAD,
> as I have a lot of changes in my Git repo.
>
> If you about to share your modifications, you better base your
> changes on stable points in history, like releases (marked by
> release tags, like "v1.7.1").
>

>> BTW2:
>> Why is it necessary to do:
>
> It is so you can distinguish between the changes in progress and
> the changes ready to be submitted (prepared for commit).
>
>> # Displays only changed files
>> git diff
>
> To be exact: the changes not yet staged for commit.
>
>> # Displays only added files
>> git diff --cached
>
> No, it displays the changes ready to be committed (staged).
>
>> I would like to have a full diff of my changes:
>> git diff -a
>
> You wouldn't use it. It is very useful to separate the phases of workflow.
>
> BTW, try using "git status". It'll show you both lists of changed files.
> Also "git gui", and "gitk" make the lists visible ("git gui" is more like
> "git status", and you can commit from it).
>
>> (or better "git diff -a" should be the default behaviour, I think that's
>> very confusing for new users)
>
> Only to unwilling to learn. You'd be probably the first to suggest
> to combine the two stages of change. Usually people understand
> (or get a feeling of understanding) the index even before they send
> first mail to the mailing list.