From: "Avery Pennarun" <apenwarr@gmail.com>
To: "Tim Harper" <timcharper@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Making submodules easier to work with (auto-update on checkout or merge, stash & restore submodules)
Date: Wed, 30 Apr 2008 17:48:54 -0400 [thread overview]
Message-ID: <32541b130804301448i537a0b98ta01cecc472e20aec@mail.gmail.com> (raw)
In-Reply-To: <EFEF26F9-D5D6-4BAC-9A8F-6D96E45AFAF7@gmail.com>
On 4/30/08, Tim Harper <timcharper@gmail.com> wrote:
> > What about the following case:
> > - submodule matches the super module checkin
> > - make changes to submodule but to *not* commit them
> > - switch supermodule branches, which should checkout a different submodule
> > - submodule checkout causes a conflict with uncommitted files
> > [all of the above were meant to be steps in the same test case]
>
> Oooh - this could be a problem currently, especially if you're not on a
> branch. If you have to resolve conflicts the way to resolve them is to
> commit, and you can't switch to a branch to commit unless you resolve your
> issues. In which case, you'll probably want to resolve, commit, then create
> a new branch with your current HEAD, then merge it into a branch. I'll
> visit that as issues arise. This is bleeding edge experimentation here :)
I know how to deal with it manually, but I'm more concerned about what
would happen in the automatic case, that is, the submodule is dirty
and the supermodule tries to switch branches.
I guess the standard thing to do would be to just have git-checkout in
the supermodule check all the submodules first, and if any of them are
dirty, refuse to do anything at all.
> Here's a link to the bundle. It's written in ruby.:
> http://github.com/timcharper/git-tmbundle/
>
> What does it have to do with submodules? It's essentially a "GUI" for git.
> It provides automation for a lot of common tasks also. My team has a need
> for submodules, but unfortunately in their current state I couldn't
> recommend it to them, so I "smoothed over" the rough edges by automating a
> lot of the awkwardness. So far, it's been working well for us.
Hmm, so the bad news is that it doesn't really help me then :(
It would be awesome if you could turn the fancy behaviour of this
bundle into patches to git-submodule, for example, and then have your
textmate macros call the modified git-submodule. It might be a bit of
an uphill battle to get the patches accepted into the release, but I
think it's worth the effort, as git-submodule in its current state is
just a non-starter for my group at least.
Have fun,
Avery
next prev parent reply other threads:[~2008-04-30 21:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-30 4:08 Making submodules easier to work with (auto-update on checkout or merge, stash & restore submodules) Tim Harper
2008-04-30 4:47 ` Tim Harper
2008-04-30 6:14 ` Andreas Ericsson
2008-04-30 10:31 ` Johannes Schindelin
2008-04-30 16:47 ` Avery Pennarun
2008-04-30 17:21 ` Ping Yin
2008-04-30 19:55 ` Roman Shaposhnik
2008-04-30 20:26 ` Avery Pennarun
2008-04-30 20:19 ` Tim Harper
2008-04-30 20:31 ` Avery Pennarun
2008-04-30 21:37 ` Tim Harper
2008-04-30 21:48 ` Avery Pennarun [this message]
2008-04-30 22:23 ` Roman Shaposhnik
2008-04-30 22:28 ` Avery Pennarun
2008-05-01 18:38 ` Making submodules easier to work with Finn Arne Gangstad
2008-05-01 19:55 ` Avery Pennarun
2008-05-06 23:47 ` Roman Shaposhnik
2008-05-07 16:14 ` Avery Pennarun
2008-05-08 1:13 ` Ping Yin
2008-05-01 23:29 ` Steven Grimm
2008-05-06 23:17 ` Roman Shaposhnik
2008-05-01 4:56 ` Making submodules easier to work with (auto-update on checkout or merge, stash & restore submodules) Ping Yin
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=32541b130804301448i537a0b98ta01cecc472e20aec@mail.gmail.com \
--to=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=timcharper@gmail.com \
/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).