Re: Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
- From
Heiko Voigt <hvoigt@hvoigt.net>
- Date
- Nov 17, 2012, 15:30 UTC
- Message-ID
- <20121117153007.GB7695@book.hvoigt.net>
- In-Reply-To
- <20121111150047.GA22608@odin.tremily.us>
Hi,
On Sun, Nov 11, 2012 at 10:00:48AM -0500, W. Trevor King wrote:
> On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote: > In order to avoid losing (or creating) local-only submodule commits, > I'll probably bail (with an error) on non-fast-forward pulls. Can > anyone else think of other safety concerns?
That sounds like a good thing to do. We can allow more flexibility later if people come up with usecases.
> This means that I'll probably drop Phil's $submodule_* export in v4, > because the only explicit use we have for it is this branch tracking. > I still think it is a useful idea, but it may not be useful enough to > be worth the complexity.
Yes lets concentrate on the branch following first.
Show 17 quoted lines
> > (2) "git diff [$path]" and friends in the superproject compares the > > HEAD of the checkout of the submodule at $path with the tip of > > the branch named by submodule.$name.branch in .gitmodules of > > the superproject, instead of the commit that is recorded in the > > index of the superproject. > > > > Hmm. ???git diff??? compares the working tree with the local HEAD (just a > SHA for submodules), so I don't think it should care about the status > of a remote branch. This sounds like you want something like: > > $ git submodule foreach 'git diff origin/$submodule_branch' > > Perhaps this is enough motivation for keeping $submodule_* exports? > > > and the option were called something like "--follow-branch=$branch", > > ???
I am not sure if hiding changes to the recorded SHA1 from the user is such a useful thing. In the first step I would like it if it was kept simple and only the submodule update machinery learned to follow a branch. If that results in local changes that should be shown. The user is still in charge of recording the updated SHA1 in his commit.
>From what I have heard of projects using this: They usually still have
something that records the SHA1s on a regular basis. Thinking further, why not record them in git? We could add an option to update which creates such a commit.
Since git is all about changes I am hesitant to hide them from the user.
> I'll replace -r/--record with --follow-branch in v4.
Sounds good.
Cheers Heiko