git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Riesen" <raa.lkml@gmail.com>
To: "Junio C Hamano" <junkio@cox.net>
Cc: "Git Mailing List" <git@vger.kernel.org>
Subject: Re: [RFC] Add --index to git-commit: just commit current index
Date: Fri, 16 Mar 2007 10:37:49 +0100	[thread overview]
Message-ID: <81b0412b0703160237l90dd158x87646be6c2731886@mail.gmail.com> (raw)
In-Reply-To: <7vird2yr1w.fsf@assigned-by-dhcp.cox.net>

On 3/16/07, Junio C Hamano <junkio@cox.net> wrote:
>
> > First use of new --quiet :)
>
> You do not need to say --exit-code if you use --quiet.

Just forgot it in

> > Refreshing index takes a long time on big repositories with
> > many files, especially if the developer was unlucky enough to
> > stick to a slow filesystem or a broken OS. In this situation
> > explicit git-update-index with git-commit --index will speedup
> > the workflow.
>
> Does it?

IFF you use git-update-index, yes

> A typical workflow would go something like this:
>
>         - repeat from here
>         - "edit foo"
>         - "edit bar"
>         - "git diff" to help me see what I changed
>         - "git add foo" as the change is sane
>         - test and see breakage
>         - "git diff HEAD" to help me see what I broke
>         - go back to 'here' to fix it up
>         - "git diff HEAD" to help me see what I changed
>         - "git add foo bar" to include what I changed
>         - "git commit"

- edit
- test
- edit
- test
- update-index (or add) file(s)
- git commit --index <--- this is faster than before
- repeat

> If I have a large project on a filesystem with slow lstat(2), I
> would imagine your development is slowed anyway because you
> would use diff far more often than commit.  I wonder if it may

I avoid using diff-files for the whole project. diff-index --cached is
fast always. It is ok even on windows

> be a better idea to use (and extend if needed) existing 'assume
> unchanged' on such a system, exactly because "diff" side would
> take more time than final "commit", and if you do use 'assume
> unchanged', then it also makes --refresh a no-op.

Forgot about it too. It didn't seem to work properly, the last time
I tried (for a long time, I admit). Besides, sometimes I want to do a
refresh, and having to switch the option on and off is annoying.

> In any case, I think your --index is a misnomer, as we do commit
> the current index.  If the sole purpose of your patch is to omit
> refreshing it, then it should be named as such.

--no-refresh?

      reply	other threads:[~2007-03-16  9:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-15  9:43 [RFC] Add --index to git-commit: just commit current index Alex Riesen
2007-03-16  0:23 ` Junio C Hamano
2007-03-16  9:37   ` Alex Riesen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81b0412b0703160237l90dd158x87646be6c2731886@mail.gmail.com \
    --to=raa.lkml@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).