[no subject]

[FIGADERE, LAURENT]

Hi,

Coming back to you with some updates.

I understand finally interest of difference between 'from' and 'at'.

The point is: is it a bug if the 'git status' provide the origin/HEAD instead 
of HEAD SHA1? 

If you want a test case with screenshots, let me know.

Regards,
Laurent

_
From: FIGADERE, LAURENT 
Sent: Thursday, September 20, 2018 3:26 PM
To: 'git@vger.kernel.org' <mailto:git@vger.kernel.org>
Subject: git status - difference between from and at


Hi guys,

Recently I used git on a top repository which integrated few other submodules.

The 'git submodule' command provides the right information on SHA1 used for 
each submodule.
When I 'cd' into a submodule and run the command 'git status', I got this 
message:
HEAD detached from 55846b8
nothing to commit, working tree clean
Which was not the right checked out SHA1: it should be 2422597

I verified in a git log command, and I was using really the '2422597' SHA1 and 
not 55846b8.
The command: 
  git log --graph --oneline --abbrev-commit --all
Output:
*   55846b8 (tag: 01.050.002, origin/master, origin/HEAD, master) 
...
*   2422597 (HEAD)
...

After running :
git co master
cd ..
git submodule update

I ran again git status command inside the submodule.
This time, I got this message:
HEAD detached at 2422597
nothing to commit, working tree clean

First question: do you confirm that 'HEAD detached FROM' provides the SHA1 of 
origin/HEAD?
And 'HEAD detached AT' provides the SHA1 we are using : HEAD?

Second question: what is the goal of such information?
Because from my opinion it can be difficult for end users to understand what 
SHA1 they are using in the submodule.

Thanks by advance for you feedbacks.

Regards,
Laurent Figadere

2.15.1 - merge with submodule output issue

[FIGADERE, LAURENT]

Dear git,

I use since few weeks now git 2.15.1.

I did few trials but please find here my outputs.

To reproduce:
Use a top module git which include a submodule
First step: from a work area, I changed selected version of submodule in master 
branch.
Then git add + git commit + git push
   A new commit on master branch has been published on my origin 
repository with the version v1.2 of submodule

Second step: in my second workarea, I created a user branch mybranch, then 
selected another release of submodule
I added the update and then commit in mybranch.
   A new commit with release v2.0 of submodule is in my last SHA1 of 
mybranch

Last step: in the second workarea, in mybranch, I first run ‘git fetch’ and 
then ‘git merge origin/master’
I got a CONFLICT message of course due to the 2 different versions of submodule.
Here the message:
warning: Failed to merge submodule submodule (commits don't follow merge-base) 
Auto-merging submodule 
CONFLICT (submodule): Merge conflict in submodule 
Automatic merge failed; fix conflicts and then commit the result. 

Now I thought that the command ‘git submodule’ provided an output with both 
versions of modules (local and remote).
But this is not the case in my environment:
[15:20:10] $ git submodule status 
U submodule

And when I run the mergetool command I have this output:
[14:54:41] $ git mergetool 
Merging: 
submodule 
Submodule merge conflict for 'submodule': 
  {local}: submodule commit 08f86f2404d9f8f616262971a3127e69f39f9d11 
  {remote}: submodule commit b3dd6fde4f02258b88ad0b2dba6474c126b499f7 
Use (l)ocal or (r)emote, or (a)bort? 

So, it means it’s not usefull to determine which version has to be selected.
Is it a bug or perhaps I make something wrong?

It will be usefull if we can hav e this information during git mergetool 
command like with git describe .

Thanks for your help. 


-

Laurent FIGADERE
CAD Engineer
GBDS RD Asic Verification
+33130805361
laurent.figad...@atos.net
Rue Jean Jaures BP 68
78340 Les Clayes-sous-Bois
France
www.Atos.net



This e-mail and the documents attached are confidential and intended solely for 
the addressee; it may also be privileged. If you receive this e-mail in error, 
please notify the sender immediately and destroy it. As its integrity cannot be 
secured on the Internet, the Atos group liability cannot be triggered for the 
message content. Although the sender endeavors to maintain a computer 
virus-free network, the sender does not warrant that this transmission is 
virus-free and will not be liable for any damages resulting from any virus 
transmitted.