Re: Translations system failing for debugHelper add-on Fwd: Cron <nvdal10n@exbi> cd ${PathToMrRepo}/addons/debugHelper && chronic mr addon2svn && chronic mr svn2addon

Noelia Ruiz
 

Hi, I didn't know the option -t for git checkout, and I recommend this if the maintainer has cloned firstly his own repo hosted on GitHub, and later adds the remote of Bitbucket.
But the main point is to understand what is needed, that is, push changes to a stable branch of the Bitbucket repo, and pull changes from there, since it's used to place translated and translatable messages. And this could be achieved in different ways, deppending on what repo was cloned firstly (probably the repo of the maintainer outside of Bitbucket, but this is not mandatory and for instance sometimes I cloned firstly the Bitbucket repo and later my GitHub repo.
A possible and the most probable procedure could be:

# Clone the maintainer repo
git clone https://github.com/githubRepo
Add the remote for Bitbucket repo
remote add b https://bitbucket.org/nvdaaddonteam/bitbucketRepo
# Fetch Bitbucket repo
git fetch b
# Track the stable branch
git checkout -t b/stable
Optionally, we can set two push URLS to the origin remote, to push changes to both repos in one only step, not two. I did it for my computer at home. Here is an explanation:

https://gist.githubusercontent.com/bjmiller121/f93cd974ff709d2b968f/raw/8f17c4d72ba8bd36aea0ec0cf344a8197fa648e8/multiple-push-urls.md


Also, you can look at this book about git
https://git-scm.com/book

I may reflect this in the Make add-ons translatable document, thanking to Luke for his contribution about git checkout -t tomorrow.

Cheers

El 06/09/2019 a las 14:20, Doug Lee escribió:
So out of all this, what's the final set of steps for managing this sort of thing in Git? Or if the directions are up to date, a URL would be enough. I'm trying to save a pointer for the day I get round to tackling Git myself,
which perhaps amazingly has not happened yet. (I've used CVS back in the day, Subversion, and bzr but not Git.)
On Fri, Sep 06, 2019 at 01:29:42PM +0200, Noelia Ruiz wrote:
No, you aren't wrong. I misunderstood your previous email. I thought
you simply want to do: git checkout remote/stable.
Cheers
2019-09-06 13:23 GMT+02:00, Luke Davis <luke@...>:
Hi Noelia

You wrote:

Hi, if you do what you suggest, you will be in detached head state,
Are you sure?

Detached head state in this context usually only happens when you checkout a

commit.

The checkout docs say:
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
-b <new_branch>
Create a new branch named <new_branch> and start it at <start_point>

It recommends looking at the branch documentation. In the branch
documentation,
it says this about start-point:

-t, --track
When creating a new branch, set up configuration to mark the start-point
branch as "upstream" from the new branch. This configuration will tell git
to show the relationship between the two branches in git status and git
branch -v. Furthermore, it directs git pull without arguments to pull from
the upstream when the new branch is checked out.
This behavior is the default when the start point is a remote-tracking
branch.

So I am not clear why this would result in a detached head, especially
because
git always tells you when you are in detached-head, and does not say it for

"checkout -b stable translate/stable" # From my former email

While still on stable after that initial command:

git branch -vv
master 2f0e719 [origin/master] Starting work on v1.1.0. New version of
changelog in readme.
* stable b2c20c4 [translate/stable] l10n updates

git status
# On branch stable
nothing to commit (working directory clean)

But if I checkout a commit, which detaches the head, I get:

git status
# Not currently on any branch.
nothing to commit (working directory clean)

> and then if you want to modify something, for instance merging changes
from the remote stable branch made after you have performed git
checkout to remote/stable, your stable branch won't be updated
Maybe that is where the miscommunication is? I did not mean to checkout to
remote/stable (or translate/stable, in my example) every time, just the
first.
I was only saying that in your original steps, to create the branch, instead
of
doing:

git checkout -b stable
git branch -u translate/stable # Which doesn't work on older git

You can just do:

git checkout -b stable translate/stable

Or even as simple as:

git checkout -t translate/stable

Branch stable set up to track remote branch stable from translate.
Switched to a new branch 'stable'

I am pretty sure that neither of those should create a detached head (which

sounds very painful, at least briefly).

Of course after that, you have to run:

git checkout stable

to reach the branch as usual from other branches.

Someone please correct me if I am wrong, but I am not getting any detached
heads
or confused branches in doing it this way, and it is a command that at least

seems to work for old and new git the same, which git branch's methods of
setting up tracking don't.

Luke




Join nvda-addons@nvda-addons.groups.io to automatically receive all group messages.