git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Kevin Bernard <kevin.bernard@fiveco.ch>
To: Philippe Blain <levraiphilippeblain@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: RE: bug: checkout --recurse-submodules discard uncommited changes in submodule
Date: Thu, 14 Jan 2021 16:40:28 +0000	[thread overview]
Message-ID: <1ce5bfa2e8b04bf79b831515e096a9f1@fiveco.ch> (raw)
In-Reply-To: <05afbdeb-6c72-f14c-cdf0-e14894de05a3@gmail.com>

Hi Philippe, 

I have no preferences whether the checkout should fail if any files are modified in the submodule
or allow the checkout to succeed if the modification can be carried out. 

I wrote a step by step procedure to reproduce the bug.

Step to reproduce my issue

git init  
git checkout -b master  
git submodule add https://github.com/kbernard-perso/recurse-bug.git  
git submodule init  
git add .  
git commit -m "Add submodule"  
cd recurse-bug/  
echo "file1 modified" >> file1.txt  
git add .  
git commit -m "file1.txt modified"  
cd ..  
git add .  
git commit -m "Modified file1 in submodule"  
cd recurse-bug/  
echo "file2 modified" >> file2.txt  
cd ..  
git status  
git checkout --recurse-submodules HEAD^  
git status  

The uncommitted modifications made with "echo "file2 modified" >> file2.txt" are  
discarded by git checkout --recurse-submodules HEAD^  

Thank you very much for making git a wonderful tool to use.

Cheers, 

Kevin

-----Message d'origine-----
De : Philippe Blain <levraiphilippeblain@gmail.com> 
Envoyé : jeudi, 14 janvier 2021 14:55
À : Kevin Bernard <kevin.bernard@fiveco.ch>; git@vger.kernel.org
Objet : Re: bug: checkout --recurse-submodules discard uncommited changes in submodule

Hi Kevin,

Le 2021-01-14 à 03:35, Kevin Bernard a écrit :
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
> 
> What did you do before the bug happened? (Steps to reproduce your 
> issue) Make a git repository with a submodule in it.
> Make two different commits in the main repository with two different 
> versions of the submodule, one of them is the head of the branch.
> Checkout the head of the branch in the main repository, and make a submodule update.
> Make a modification, do not commit it, in a submodule file that will 
> not result in a "error: Your local changes to the following files 
> would be overwritten by checkout" when the other version of the library will be checked out.

I assume that you confirmed that by running 'git checkout <other version>'
in the submodule, right ?

> Go back to the main repository and make a checkout of the other commit 
> with the switch --recurse-submodules.
> 
> What did you expect to happen? (Expected behavior) The checkout with 
> the switch --recurse-submodules should fail when there are uncommitted 
> changes in the submodule.
> 
> What happened instead? (Actual behavior) Uncommitted changes in the 
> submodule are discarded without any notifications.
> 
> What's different between what you expected and what actually happened?
> Loss of the uncommitted changes in the submodule.
> 
> Anything else you want to add:
> I stay at your disposal if you need more information.


Thanks for the report. This is a known problem that was reported in [1] and [2].
I'm currently working on fixing that bug. I'm not quite finished yet as I want to polish the end-user experience a bit, but if you want to compile from source, the heart of the fix is this change:

diff --git a/unpack-trees.c b/unpack-trees.c index 323280dd48..a3e3d98de1 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1872,7 +1872,7 @@ static int verify_uptodate_1(const struct cache_entry *ce,
  
  		if (submodule_from_ce(ce)) {
  			int r = check_submodule_move_head(ce,
-				"HEAD", oid_to_hex(&ce->oid), o);
+				"HEAD", empty_tree_oid_hex(), o);
  			if (r)
  				return add_rejected_path(o, error_type, ce->name);
  			return 0;


This should disallow switching branches with '--recurse-submodules' if *any* file in the submodule is modified.

However, I'm actually thinking that maybe it would be better to let the checkout succeed in the exact case you mention, i.e. when the modified files in the submodules are at the same version in both submodule commits (i.e. git checkout <other version> in the submodule succeeds and the modified files stay modified), and also carry over the modified files in the submodule. This would mimic the 'git checkout' experience without submodules, i.e. modified files that do not conflict are carried over to the branch you are checking out.

If you can write a complete reproducer (complete steps starting with 'git init',
etc.) I will make sure that your scenario is adequately tested in my patch series.


Cheers,

Philippe.


[1] https://lore.kernel.org/git/CAHsG2VT4YB_nf8PrEmrHwK-iY-AQo0VDcvXGVsf8cEYXws4nig@mail.gmail.com/
[2] https://lore.kernel.org/git/20200525094019.22padbzuk7ukr5uv@overdrive.tratt.net/

      reply	other threads:[~2021-01-14 16:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14  8:35 bug: checkout --recurse-submodules discard uncommited changes in submodule Kevin Bernard
2021-01-14 13:54 ` Philippe Blain
2021-01-14 16:40   ` Kevin Bernard [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

  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=1ce5bfa2e8b04bf79b831515e096a9f1@fiveco.ch \
    --to=kevin.bernard@fiveco.ch \
    --cc=git@vger.kernel.org \
    --cc=levraiphilippeblain@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.
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).