All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>
Subject: Re: Why does 'submodule add' stage the relevant portions?
Date: Mon, 25 Mar 2013 09:35:51 +0100	[thread overview]
Message-ID: <51500C67.9040308@web.de> (raw)
In-Reply-To: <CALkWK0=PHNmT5zfjEaWh_5=aV7wcPdGgyCWFhjaeVrrWhL0OBw@mail.gmail.com>

Am 24.03.2013 18:38, schrieb Ramkumar Ramachandra:
> I find this behavior very inconsistent and annoying.  Why would I want
> to commit the submodule change immediately?  Maybe I want to batch it
> up with other changes and stage it at a later time.  Why should I have
> to unstage them manually now?  I get the other side of the argument:
> what if the user commits the .gitmodule change at a different time
> from the file change?  In other words, the user should have a way of
> saying 'submodule stage' and 'submodule unstage'.

Hmm, AFAIK you are the first to bring up such a feature, as in most
use cases doing a "git (submodule) add <path>" is expected to stage
what you added. Maybe you could teach the stage/unstage code to also
stage/unstage the corresponding part of the .gitmodules file, but
I'm not sure it is worth the hassle.

> Now, for the implementation.  Do we have existing infrastructure to
> stage a hunk non-interactively?  (The ability to select a hunk to
> stage/ unstage programmatically).  If not, it might be quite a
> non-trivial thing to write.

Have fun when adding two submodules and unstage only one of them
later. I think this feature will not work unless you analyze
.gitmodules and stage/unstage section-wise.

  reply	other threads:[~2013-03-25  8:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-24 17:38 Why does 'submodule add' stage the relevant portions? Ramkumar Ramachandra
2013-03-25  8:35 ` Jens Lehmann [this message]
2013-03-25  8:59   ` Ramkumar Ramachandra
2013-03-25 18:43     ` Jens Lehmann
2013-03-25 19:57       ` Ramkumar Ramachandra
2013-03-25 22:57         ` Jens Lehmann
2013-03-26  7:57           ` Ramkumar Ramachandra
2013-03-26 16:57             ` Jens Lehmann
2013-03-25 17:51 ` Junio C Hamano
2013-03-25 18:02   ` Ramkumar Ramachandra
2013-03-25 18:20     ` Jonathan Nieder
2013-03-25 18:27       ` Ramkumar Ramachandra
2013-03-25 18:31         ` Junio C Hamano
2013-03-25 18:48           ` Ramkumar Ramachandra
2013-03-25 18:50             ` Jonathan Nieder
2013-03-25 19:06               ` Ramkumar Ramachandra
2013-03-25 19:13                 ` Jonathan Nieder
2013-03-26  3:27 ` Duy Nguyen

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=51500C67.9040308@web.de \
    --to=jens.lehmann@web.de \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.