From: "Hedges Alexander" <ahedges@student.ethz.ch>
To: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Feature Request: Branch-Aware Submodules
Date: Fri, 26 Aug 2016 15:12:49 +0000 [thread overview]
Message-ID: <51671371-C59A-4304-99B2-B2C2256C4001@student.ethz.ch> (raw)
In-Reply-To: 5EA7D232-5D41-4653-9E35-21C502C79C92@student.ethz.ch
> On 25 Aug 2016, at 19:45, Stefan Beller <sbeller@google.com> wrote:
>
> +cc Jacob and Lars who work with submodules as well.
>
> On Thu, Aug 25, 2016 at 2:00 AM, Hedges Alexander
> <ahedges@student.ethz.ch> wrote:
>>
>> Right now updating a submodule in a topic branch and merging it into master
>> will not change the submodule index in master leading to at least two commit
>> for the same change (one in any active branch). This happened to me quite a few
>> times. To a newcomer this behavior is confusing and it leads to unnecessary
>> commits.
>
> So you roughly do
>
> git checkout -b new-topic
> # change the submodule to point at the latest upstream version:
> git submodule update --remote <submodule-path>
> git commit -a -m "update submodule"
> git checkout master
> git merge new-topic
> # here seems to be your point of critic?
> # now the submodule pointer would still point to the latest
> upstream version?
>
Excuse my poor wording above. The problem is the following:
# assume a repo with a few branches and one submodules
git checkout -b new_feature
git commit -am "some new commits"
cd submodule/path
git commit -am "dirty hacking on a library"
cd ../..
git commit -am "changes and update library"
git status
# all is well
git checkout master
git status
# it says new submodule commits ??
git commit -am "update library again…"
git merge new_feature
git checkout old_feature_that_never_made_it
git status
# still ???
git commit -am …
Now reading the comments below, I overlooked git submodule update. I used update
only the first time after a clone with the init flag. As a remedy I could just
run git submodule update after every merge, but then I always get a detached
head which is also not ideal.
The second thing I overlooked is just merging without worrying about the git
status telling me the repository is dirty. But here my muscle memory does a
commit when the repository is dirty, before running any other git commands.
Obviously, its confusing to people without a certain amount of experience.
>> The proposed change would be to have a submodule either ignored or tracked by
>> the .gitmodules file.
>> If it is ignored, as for instance after a clone of the superproject, git simply
>> ignores all files in the submodule directory. The content of the gitmodules
>> file is then also not updated by git.
>> If it is not ignored, the .gitmodules is updated every time a commit happens in
>> the submodule.
>
> So
>
> git -C <submodule-path> commit
>
> should trigger a commit in the superproject as well, that changes the gitmodules
> file? What do you record in the git modules file that needs updating?
> As the version is tracked via the gitlink entry, I do not see the
> information that
> needs tracking here?
I guess nothing has to be done here. I mistakenly thought the .gitmodules stores
the SHA.
>
>> On branch switches the revision shown in the gitmodules from
>> that branch is checked out.
>
> So you are proposing to put the revision into the gitmodules file?
> That would be redundant with the actual gitlink entry in your tree.
> (as shown via `git submodule status`)
> What would happen if the recorded revision in the gitmodules file and the
> gitlink are out of sync?
>
> Oh, are you just proposing to actually make `git checkout` aware of the
> submodules? See[1]. I would welcome such a change and be happy th
>
> [1] https://github.com/jlehmann/git-submod-enhancements
> which has some attempts for checkout including the submodules.
> I also tried writing some patches which integrate checking out submodules
> via checkout as well. A quicker `solution` would be a config option that
> just runs `git submodule update` after each checkout/pull etc.
>
I see. The quick fix is almost what I’m looking for, except that it leaves
the repo in a detached head state. Could the submodule update be made
automatically and intelligently pick the branch?
>
>> This change would have submodules conceptually behave more like files to the
>> superproject.
>>
>>
>> Like current behavior, git status would display whether the submodule has
>> uncommitted changes or is at a new commit.
>
> See config options diff.submodule and status.submoduleSummary.
>
I meant that git status works fine the way it is implemented right now.
>
>>
>> I couldn't find any discussions on the initial implementation of git-submodule
>> or any previous proposals related to this in nature due to gmane being down
>> right now and the mailing list archives on the other sites are not great for
>> searching. So please excuse me if I'm bringing up already discussed stuff.
>
> https://public-inbox.org/git for reading on the web, or
>
> git clone https://public-inbox.org/git
>
> for reading offline.
>
Thanks.
Best Regards,
Alexander Hedges
next parent reply other threads:[~2016-08-26 15:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5EA7D232-5D41-4653-9E35-21C502C79C92@student.ethz.ch>
2016-08-26 15:12 ` Hedges Alexander [this message]
2016-08-29 2:17 ` Feature Request: Branch-Aware Submodules Jacob Keller
2016-09-01 11:34 ` Hedges Alexander
2016-08-25 9:00 Hedges Alexander
2016-08-25 17:45 ` Stefan Beller
2016-08-25 20:50 ` Junio C Hamano
2016-08-25 20:55 ` Stefan Beller
2016-08-25 21:25 ` Junio C Hamano
2016-08-25 17:46 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51671371-C59A-4304-99B2-B2C2256C4001@student.ethz.ch \
--to=ahedges@student.ethz.ch \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).