From: Stefan Beller <firstname.lastname@example.org> To: Junio C Hamano <email@example.com> Cc: Patrick Lehmann <Patrick.Lehmann@plc2.de>, Lars Schneider <firstname.lastname@example.org>, Git Mailinglist <email@example.com> Subject: Re: Restoring detached HEADs after Git operations Date: Mon, 19 Jun 2017 12:11:47 -0700 Message-ID: <CAGZ79kYrEexbn1j46DQTNWhksFeU=WbvnP7gqiUoj4Uynduvkw@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Mon, Jun 19, 2017 at 10:55 AM, Junio C Hamano <email@example.com> wrote: > Stefan Beller <firstname.lastname@example.org> writes: > >> On Mon, Jun 19, 2017 at 2:52 AM, Patrick Lehmann >> <Patrick.Lehmann@plc2.de> wrote: >>> Hello Lars, >>> >>> for your questions: >>>> If there are multiple branches with the same hash then your script would pick the first one. Can you imagine a situation where this would be a problem? >>> >>> I can't think of a good solution to resolve it automatically. Maybe a script could print that there are multiple possibilities and it choose the first branch in the list. >>> >>> >>>> Plus, you are looking only at local branches. Wouldn't it make sense to look at remote branches, too? >>> >>> This is also related to restoring tags. If we go this way, we should have this priority list: >>> - local branches >>> - remote branches >> >> For remote branches you would create a local branch of the same name >> (if such a branch would not exist, possibly setting it up to track that remote >> branch)? >> >>> - tags >> >> as said in the other email and similar to remote branches, we'd not want to have >> HEAD pointing to them directly but somehow have a local branch. > > Let's step back a bit. We detach the HEAD for a good reason, no? And the 'good reason' being that at the time git-submodule was written we did not know what would be best, and having a detached HEAD would be (a) easy to implement, and (b) removing one moving thing from the whole construction, hence making it a bit safer, (c) it sort of follows the mental model: the superproject said it had the submodule at X (and not at branch Y!) the submodule itself is a whole repo on its own (it doesn't need to be aware of the superproject) so in this world detaching at X is the best we can do. > Why is it a good idea to move them back on to a branch picked among > multiple ones that all happen to be pointing at the same commit? This (rhetorical?) question reads like 2 questions actually: (a) "Why is it a good idea to move them back on to a branch?" It makes working easier as the submodule is not detached, but on a proper branch (b) "picked among multiple ones that all ..." I think this is a bad idea and we'd rather want to follow some configuration instead of wild-guessing by Git. > The user may build on a history of a submodule, and then may push > the result out to a particular branch at the other side; that is > when being on a named branch in the submodule becomes useful, but > even then I do not think randomly picking one branch and be on it > is a good thing to do. so you provide one reason why it is useful, but then claiming it is 'not a good thing' (yet). Can you give a reason why this is a 'bad thing'? > I would understand the workflow would go more like so: > > - You do something at the superproject (e.g. create a new branch X > from an existing commit and check it out), which results in > submodules' HEADs getting detached at the commits bound to the > superproject's tree. And here we'd want to discuss if we *really* want to detach the HEADs or rather have a symbolic ref "following the superproject". > - Because you want to make changes to both submodules and the > superproject in a consistent way, you'd want to commit changes to > all of these repositories and the push the result out in an > atomic way. Committing and pushing are different things. You should not care if I commit atomically as you (in the general "upstream" sense) cannot observe my local commits. For pushing we would want to have an atomic push, but that is not the scope of this discussion. (As a Gerrit user, we implemented the submodule atomicity serverside, but in plain Git server you'd not need the atomicity either: git commit -a -m "update submodule pointers" git submodule foreach git push git push should be fine w.r.t. any non-atomic race condition.) > - Hence you tell "Hey, Git, I want all the submodules that I > modified to be on branch X" from the superproject. > > - This may succeed in a submodule where X is a new name, or the > current tip of branch X is an ancestor of the detached HEAD. so we'd allow fast forward for X. This seems arbitrary to me. I could also say "If X exists I allow a merge to be made between old X and the object name given by the superproject". (maybe as a config option) > - This may fail in a submodule where there is branch X that does > not want to move to the detached HEAD's state. In this latter > case, the user needs to deal with the situation (perhaps the > old X is expendable; perhaps the HEAD's commit may need to be > merged to old X; perhaps there are other cases). makes sense. > > though.
next prev parent reply index Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-06-19 8:46 Patrick Lehmann 2017-06-19 9:30 ` Lars Schneider 2017-06-19 9:52 ` AW: " Patrick Lehmann 2017-06-19 16:37 ` Stefan Beller 2017-06-19 17:34 ` AW: " Patrick Lehmann 2017-06-19 17:47 ` Stefan Beller 2017-06-19 18:09 ` AW: " Patrick Lehmann 2017-06-19 19:21 ` Stefan Beller 2017-06-19 20:13 ` AW: " Patrick Lehmann 2017-06-19 17:55 ` Junio C Hamano 2017-06-19 19:11 ` Stefan Beller [this message] 2017-06-19 16:31 ` Stefan Beller 2017-06-19 17:01 ` Jeff King 2017-06-19 17:56 ` Ævar Arnfjörð Bjarmason
Reply instructions: You may reply publically 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='CAGZ79kYrEexbn1j46DQTNWhksFeU=WbvnP7gqiUoj4Uynduvkw@mail.gmail.com' \ --email@example.com \ --cc=Patrick.Lehmann@plc2.de \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox