On Wed, Apr 28, 2010 at 07:33, Gerhard Wiesinger <lists@xxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html