Metacello/Iceberg detached head of cascade loaded requirements
I have a query about "Detached HEAD" status after a Metacello/Iceberg cascade load of required packages. Starting with the general questions... Is that a common status for this scenario? How to leave the status looking good as "Up to date"? Here is a case example... To avoid the a Filetree repo "filename too long" error on Windows, I pre-cloned the repo to specify s shorter path name... Repositories > Add > Clone from github.com Owner: dionisiydk Project name: Mocketry Local directory: C:\Temp\Mocketry Protocol: SSH Then in Playground evaluated... Metacello new baseline: 'Mocketry'; repository: 'github://dionisiydk/Mocketry'; load This cascade loaded Ghost and StateSpecs repos leaving them with a status of "Detached HEAD". What does this mean? And how to have these load cleanly so they are left "Up to date" ? To ease others testing on Windows, I forked the repo and converted to Tonel, so the same result comes by just evaluating.... Metacello new baseline: 'Mocketry'; repository: 'github://bencoman/Mocketry'; load cheers -ben P.S. I've issued a PR upstream for the Tonel conversion.
If the dependencies are pinned to a git tag it's a normal situation. You don't need to do nothing unless you want to change some of the code in the dependencies in which case just create a branch On Sat, May 11, 2019, 05:40 Ben Coman <btc@openinworld.com> wrote:
I have a query about "Detached HEAD" status after a Metacello/Iceberg cascade load of required packages. Starting with the general questions... Is that a common status for this scenario? How to leave the status looking good as "Up to date"?
Here is a case example... To avoid the a Filetree repo "filename too long" error on Windows, I pre-cloned the repo to specify s shorter path name... Repositories > Add > Clone from github.com Owner: dionisiydk Project name: Mocketry Local directory: C:\Temp\Mocketry Protocol: SSH
Then in Playground evaluated... Metacello new baseline: 'Mocketry'; repository: 'github://dionisiydk/Mocketry'; load
This cascade loaded Ghost and StateSpecs repos leaving them with a status of "Detached HEAD". What does this mean? And how to have these load cleanly so they are left "Up to date" ?
To ease others testing on Windows, I forked the repo and converted to Tonel, so the same result comes by just evaluating.... Metacello new baseline: 'Mocketry'; repository: 'github://bencoman/Mocketry'; load
cheers -ben
P.S. I've issued a PR upstream for the Tonel conversion.
Hi Ben, Iâll complement a bit Gabrielâs answer. See inline
El 11 may 2019, a las 10:39, Ben Coman <btc@openinworld.com> escribió:
I have a query about "Detached HEAD" status after a Metacello/Iceberg cascade load of required packages. Starting with the general questions... Is that a common status for this scenario?
Yes. A git repository can be mainly in two states (Iâm not being really accurate here, just simplifying the explanation). - youâre working on a branch, and thus commit, merge and other operations will affect the current branch - youâre working on a commit, outside of a branch. In this case some operations do not work, others will work but with different semantics. The thing that is clear is that operations do not affect any branch. To understand it a bit better: there is a git variable called HEAD which points to the current commitish we are working on. A git repository is said to be in `Detached HEAD` when HEAD does point to a commitish other than a branch. To put in in bare command-line git, in general youâll see that HEAD points to a branch, mostly when we clone a fresh repository, or when we `checkout` a branch: ``` $ git checkout myBranch ``` However, when checking out a tag or a commit, HEAD points respectively to the commit referenced by the tag (recursivelyâ¦) or to the checked out commit. ``` $ git checkout tagV1.0 or $ git checkout abcd123 ``` This happens in your scenario because the project youâre loading has some dependency that has a version corresponding to a tag. Detached HEAD does not mean your repository is broken, it means that to work properly you need to check out a branch. Now, letâs imagine we decide to do a tool that automatically leaves you in the âcorrect branchâ to avoid Detached HEAD state, the reality is that it is no straight forward. Case 1) Take the simple case where the tagged commit is referenced directly by two branches. There is no good automatic way to decide which branch is the good one without knowing the intentions of the user, or the conventions of the project⦠Even creating an automatic branch may not be what the user wanted... Case 2) Still simple but even more complicated: the two branches have diverged from the tagged commit. The tagged commit is in the history of both branches, and there is no good automatic way to determine which branch is the good. They are actually both equally good. And even more dangerous, if we silently checkout one of the branches, we may be checking out a version that does not work!
How to leave the status looking good as "Up to dateâ?
Well, usually you have nothing to do. First thing to understand is that in git there is not such thing as "Up to dateâ. The best you can do is to say that [a branch] is up to date [with respect to a remote repository] Which means that a particular branch has everything from that specific remote repository. But * maybe there is another repository that has more commits (typical case of forks in github for example) * while there could be in your repository a branch that is up to date, other branches may not. Now, I understand that you want to âupdate your projectâ to the latest version. Looking at the graph in Case 2 above, what you need to do is to checkout the correct branch. The selection of the correct branch would depend on the decisions of the developer, or the conventions of the community. Right now we have no such conventions, and even if we had them, we should give some alternative for those who donât want to strictly follow them.
Here is a case example... To avoid the a Filetree repo "filename too long" error on Windows, I pre-cloned the repo to specify s shorter path name... Repositories > Add > Clone from github.com Owner: dionisiydk Project name: Mocketry Local directory: C:\Temp\Mocketry Protocol: SSH
Then in Playground evaluated... Metacello new baseline: 'Mocketry'; repository: 'github://dionisiydk/Mocketry'; load
This cascade loaded Ghost and StateSpecs repos leaving them with a status of "Detached HEAD". What does this mean? And how to have these load cleanly so they are left "Up to dateâ ?
Hope I answered those questions :). If not, keep asking! Cheers, Guille
On Tue, 14 May 2019 at 18:02, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi Ben,
Iâll complement a bit Gabrielâs answer. See inline
El 11 may 2019, a las 10:39, Ben Coman <btc@openinworld.com> escribió:
I have a query about "Detached HEAD" status after a Metacello/Iceberg cascade load of required packages. Starting with the general questions... Is that a common status for this scenario?
Yes.
A git repository can be mainly in two states (Iâm not being really accurate here, just simplifying the explanation). - youâre working on a branch, and thus commit, merge and other operations will affect the current branch - youâre working on a commit, outside of a branch. In this case some operations do not work, others will work but with different semantics. The thing that is clear is that operations do not affect any branch.
To understand it a bit better: there is a git variable called HEAD which points to the current commitish we are working on. A git repository is said to be in `Detached HEAD` when HEAD does point to a commitish other than a branch.
To put in in bare command-line git, in general youâll see that HEAD points to a branch, mostly when we clone a fresh repository, or when we `checkout` a branch:
``` $ git checkout myBranch ```
However, when checking out a tag or a commit, HEAD points respectively to the commit referenced by the tag (recursivelyâ¦) or to the checked out commit.
``` $ git checkout tagV1.0
or
$ git checkout abcd123 ```
This happens in your scenario because the project youâre loading has some dependency that has a version corresponding to a tag. Detached HEAD does not mean your repository is broken, it means that to work properly you need to check out a branch.
Now, letâs imagine we decide to do a tool that automatically leaves you in the âcorrect branchâ to avoid Detached HEAD state, the reality is that it is no straight forward.
Case 1) Take the simple case where the tagged commit is referenced directly by two branches. There is no good automatic way to decide which branch is the good one without knowing the intentions of the user, or the conventions of the project⦠Even creating an automatic branch may not be what the user wanted...
Case 2) Still simple but even more complicated: the two branches have diverged from the tagged commit. The tagged commit is in the history of both branches, and there is no good automatic way to determine which branch is the good. They are actually both equally good. And even more dangerous, if we silently checkout one of the branches, we may be checking out a version that does not work!
How to leave the status looking good as "Up to dateâ?
Well, usually you have nothing to do. First thing to understand is that in git there is not such thing as "Up to dateâ. The best you can do is to say that
[a branch] is up to date [with respect to a remote repository]
Which means that a particular branch has everything from that specific remote repository. But * maybe there is another repository that has more commits (typical case of forks in github for example) * while there could be in your repository a branch that is up to date, other branches may not.
Now, I understand that you want to âupdate your projectâ to the latest version. Looking at the graph in Case 2 above, what you need to do is to checkout the correct branch. The selection of the correct branch would depend on the decisions of the developer, or the conventions of the community. Right now we have no such conventions, and even if we had them, we should give some alternative for those who donât want to strictly follow them.
Here is a case example... To avoid the a Filetree repo "filename too long" error on Windows, I pre-cloned the repo to specify s shorter path name... Repositories > Add > Clone from github.com Owner: dionisiydk Project name: Mocketry Local directory: C:\Temp\Mocketry Protocol: SSH
Then in Playground evaluated... Metacello new baseline: 'Mocketry'; repository: 'github://dionisiydk/Mocketry'; load
This cascade loaded Ghost and StateSpecs repos leaving them with a status of "Detached HEAD". What does this mean? And how to have these load cleanly so they are left "Up to dateâ ?
Hope I answered those questions :). If not, keep asking!
Cheers, Guille
got it. Thx Guille. I knew what Detached head was but not its behavior in relation to checking out tags. I found more info... https://stackoverflow.com/questions/5582208/checking-out-git-tag-leads-to-de... https://git-scm.com/book/en/v2/Git-Basics-Tagging Now I agree we don't want the system to be trying to decide which branch1 or branch2 to select, but what would be nice is when a tag v0.2 was checked out, a new branch "Branched-from-v0.2" was created for that commit. This could have two benefits: 1. It requires extra experience to know what "Detached HEAD" means. Now this is more Git issue rather Iceberg, but it "feels" like an error (and is the sort of thing to make French royalty nervous). A quick google skim indicates that you can lose commits with a Detached HEAD - by changing to another branch. Maybe Iceberg could have some guards against that, but I still carry that sense of foreboding looking at it. So avoiding a detached state is nicer 2. The Repository list would record which versions of packages were chain loaded by Metacello. cheers -ben
participants (3)
-
Ben Coman -
Gabriel Cotelli -
Guillermo Polito