>>> "KK" == Konstantin Khomoutov <kos...@bswap.ru> writes:
Hi
Thanks very much for you detailed answer, I still have one question and
more importantly one problem left.
> On Fri, Nov 26, 2021 at 10:57:01PM +0100, Uwe Brauer wrote:
>>
>> By that logic I should run
>>
>> git push -f origin c945bf50251150e0d4ad7ee751c7e9615cb4b3e8:master
> That is correct.
>> But this seemed not to have helped.
> It had - read on ;-)
>> When I clone the repository
> That wasn't needed; you would have been better off by merely running
I cloned the repository again, because,
1. I wanted to see what other users see if they clone it now
2. If other maintainers fetch or pull (fortunately it seems nobody
will work at the weekend it ☺️
> git fetch origin
> which would update in your local repository the so-called "remote branches"
> for the remote repo known as "origin". Remote branches are sort of bookmarks
> which capture the state of the branches in a named remote repository last time
> they were observed.
>> I see in a different local directory again adn run
>>
>> git log --all
>>
>> @commit 89346f81fef27286bd3fb1ed3ddc94a6f3fb560d (origin/copyright,
>> origin/copy)
> [...]
>> * commit 66380013003549a6851d4e110b29a5a439e05609
> [...]
>> * commit c945bf50251150e0d4ad7ee751c7e9615cb4b3e8 (HEAD -> master,
>> origin/master, origin/HEAD)
>>
>> That is these two commits have not been removed.
> They had: please pay attention to the names of the "references" taken in
> parentheses - your two "extra" commits are at the tips of the branches
> named origin/copyright and origin/copy, while origin/master point at the
> correct commit - exactly that you have told remote Git to update its "master"
> branch with.
Ok, well, but I want to get rid of these two commits (mostly because
they are not ready and then the log message just sucks). I recall that
this was possible in bitbucket some time ago (of course with a big big
warning). But as I have to add that was for mercurial which is much more
rigid in deleting already pushed commits (read impossible)
It seems that you propose a command that I just use to get rid of these
commits, see below git branch -D copy
but they do not work, with worries me
> Now please note that there are more info attached to the commit c945bf there:
> * HEAD -> master tells you that c945bf is the commit currently checked out
> (HEAD always points at the commit which you're working on).
> And the arrow tells you which local branch will be updated should you
> record a new commit.
Ok so far so clear (that is @ in mercurial)
> So this bit tells you that you have the local branch "master" checked out,
> and it has the expected commit at its tip - just what you have requested
> by executing that `git push` command above.
> * origin/HEAD is of less interest but let's describe it, too.
> The HEAD in a remote repository points at a branch which will be "the
> default" one in the repositories which are created when that remote repo
> is cloned (the books usually say it's "master" but in fact it's what HEAD
> points at).
> In other words, it's the usage of the "--all" command-line option which
> tripped you: should you have examined just origin/master, you'd have seen that
> everything is normal.
> I'll try to expand on those "origin/" prefixes in a moment.
Right that for a mercurial user, is new and confusing.
>> Not sure how to proceed.
> Well, at first, note that all is in green area now.
> You might want to furthr adjust things a bit, if you want, but the "master"
> branch in the remote repository has the state you shought for it to be in your
> initial mail.
For better reading I cut some of these paragraphs
[Snip]...
> You could then reset your local branch master to that same commit c945bf.
> That could be done by, say,
> git checkout master
> git reset --hard origin/master
Aha that indeed makes a different (as a regular mercurial user I am
still confused by the distinction between remote and origin, I mean I
understand in principle its purpose but in practise
I find the difference
between
(HEAD -> master)
And
(HEAD -> master, origin/master, origin/HEAD)
Confusing, shouldn't that be
(HEAD -> remotes/master)
And
(HEAD -> master, origin/master, origin/HEAD)
Frankly also
git branch -a
Confuses me since it states
* master
remotes/origin/HEAD -> origin/master
remotes/origin/copy
I find this confusing because I thought it is either remotes (server) or
origin (local) but not remotes/origin.
> which would make the local master to point at the same commit master in the
> origin repo does.
> Then you might want to get rid of either of those branches - copy and
> copyright, - or both of them.
> If you do not need them both in your local repo and in the remote one, just do
> git branch -D copy copyright
That is precisely what I tried to so far
but I obtain
branch -D copy
error: branch 'copy' not found.
> If you need further clarifications or guidance, ask away.
I think if you could tell be why I can't delete the branches I would be
very relived.
Thanks again
Uwe
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/87bl24u3h4.fsf%40mat.ucm.es.
smime.p7s
Description: S/MIME cryptographic signature
