git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository

From
Heiko Voigt <hvoigt@hvoigt.net>
Date
Feb 13, 2011, 13:30 UTC
Message-ID
<20110213133019.GB31986@book.hvoigt.net>
In-Reply-To
<AANLkTimist_GXgRGdUW1PpxpRO=poYgD4HkDC5CsyLra@mail.gmail.com>
Hi Julian,
On Sat, Feb 12, 2011 at 03:32:43PM -0500, Julian Ibarz wrote:
Show 8 quoted lines
> Thanks for all your feedbacks. Before your first mail I had already
> implemented command 1 you are talking about and almost finished
> command 2. Today I could spend some time again on this side project
> and I have finished command 2. Here is what you do:
> 
> git submodulecheckout --find-versions <submodule> > <some_temp_file>
> cd <submodule>
> git submodulecheckout --find-closest < <some_temp_file>

I do not quite understand how this is used. I just tried it on the msysgit repository. Which is a good candidate for testing since you can easily verify the results because for each git version there is a corresponding tag in the superproject.

You can find it on repo: http://repo.or.cz/w/msysgit.git

As far as I understand the sha1 you are searching for is determined by the currently checked out revision. So here we go:

cd msysgit/git git checkout v1.7.2.3.msysgit.0~3 cd .. git submodulecheckout --find-versions git > git-versions.txt cd git git submodulecheckout --find-closest < ../git-versions.txt

> submodulecheckout: no commit found
Ok lets not be so hard:

git checkout v1.7.2.3.msysgit.0 cd .. git submodulecheckout --find-versions git > git-versions.txt cd git git submodulecheckout --find-closest < ../git-versions.txt

> 820fd48475eb72cdd4f2

Close but not quite the right commit. See the output of git log: 820fd48 Chomp CRLF before feeding to tar when building netinstaller. 83e164c Avoid quoting environment variable values. daafc61 (tag: Git-1.7.2.3-preview20100911) Updated git and git documents and ReleaseNotes to v1.7.2.3

Whats strange is that this commit did not even change the submodule.

I think currently it does not make sense to implement the scripting since the interface is not yet cleaned up enough. It should be possible to specify a commit as parameter and the path should probably go after that like the other commands do as well.

The other issue is that we need to change the working directory. IMO, everything should be possible to do from superproject. Have a look at add_submodule_odb() in submodule.c it lets you load the database of a submodule. This way you can run the --find-closest from the superproject.

So what I would be looking for is something like this:

# This looks up all commits of <submodule> ever registered in this # project git submodulecheckout --find-versions <submodule> > out.tmp

# This reads the previous list and outputs a list of of all the commits # that contain <treeish>. Function in_merge_bases(treeish, i&commit, 1) # can be of help here. Afterwards you have to prune all later commits # that contain earlier ones. I did this in find_first_merges(). I # suggest to refactor that code into a function so that you can use it. git submodulecheckout --find-closest <treeish> -- <submodule> < out.tmp > out2.tmp

# And now we can search for the commit in the other submodule C git submodulecheckout --list-commits <other submodule> < out2.tmp > out3.tmp

And if out3.tmp just contained one line we could checkout that one. I am still not sure in which command these options could go. Junio do you maybe have a suggestion? Since its all about submodules it would make sense to put it in 'git submodule' but thats already the script.

Maybe a new 'git-submodule-tool' ?

I suggest that you start implementing some basic tests if you found the right commits using the testsuite. Basically you build up a sample repository where you know which commits of the submodules are tied together with a sequence of commands. Then you check whether your commands find the correct one. Maybe have a look at the submodule tests Jens is implementing on his branch:

https://github.com/jlehmann/git-submod-enhancements
Hope that helps.
Cheers Heiko
Previous: Julian IbarzNext: Julian Ibarz
Message 17 of 20 in “Updating a submodule with a compatible version from another submodule version using the parent meta-repository”
  1. Julian IbarzJan 26, 2011
  2. Jens LehmannJan 26, 2011
  3. Julian IbarzJan 26, 2011
  4. Jens LehmannJan 26, 2011
  5. Julian IbarzJan 26, 2011
  6. Jens LehmannJan 26, 2011
  7. Julian IbarzJan 26, 2011
  8. Junio C HamanoJan 26, 2011
  9. Julian IbarzJan 26, 2011
  10. Junio C HamanoJan 26, 2011
  11. Heiko VoigtJan 29, 2011
  12. Julian IbarzJan 30, 2011
  13. Julian IbarzFeb 3, 2011
  14. Heiko VoigtFeb 6, 2011
  15. Heiko VoigtFeb 9, 2011
  16. Julian IbarzFeb 12, 2011
  17. Heiko VoigtFeb 13, 2011
  18. Julian IbarzFeb 13, 2011
  19. Heiko VoigtFeb 14, 2011
  20. Julian IbarzFeb 20, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.