GithubHelp home page GithubHelp logo

moz-git-tools's Introduction

Tools for working with Git at Mozilla.

In order to set this up, clone this repository somewhere, run the git submodule init and then git submodule update command, and add your clone to $PATH.

Some commands require python2. If using mozilla-build on windows, python2 might be missing, but python exists and is actually python 2 (check by running python -V). On such case, you can create a copy of python.exe as python2.exe at the same location - probably at <mozilla-build>/python/.

Many of these tools rely on a notion of your current branch's "upstream branch". For example, git push-to-try pushes to try all patches in your current branch that aren't upstream. See the git-tracks section below for details on how to change your upstream branch.

git-bz

Push commits from git to bugzilla. For example, to push the two top commits in your repository, run

git bz attach -e HEAD^^..

(This will complain if your commits don't mention the same bug number in their summaries.)

If a commit's message starts with "FOLD", it will be folded into the previous commit before pushing to bugzilla.

(Actually, git-bz can do more than push commits from git to bugzilla. But I don't use it for anything else, so I'm not sure which of the other features work with bugzilla.mozilla.org.)

git-bzexport

Usage: git bzexport [-t/--tip] PATH_TO_HG_REPO [GIT_REVS]

Push commits from git to bugzilla using the bzexport Mercurial extension from the Mozilla version control tools repo.

The bzexport extension has some advantages over bz attach - for example, if multiple Bugzilla reviewers match the reviewer name you specify, bzexport will let you choose between them using a menu - so some users may prefer it.

This command is implemented using git-push-to-hg, so see that command's documentation for more details on the argument syntax.

git-new-workdir

Create a new working directory based off an existing local git repository.

git-tracks

Gets the name of the current branch's upstream branch. With -d or --default, git-tracks outputs "origin/master" if there's no upstream branch.

You can set this with git branch --set-upstream CURRENT_BRANCH UPSTREAM_BRANCH. (Don't do git branch --set-upstream BRANCH; that won't work right!)

Many other tools in this package use git tracks -d as your branch's "upstream branch".

git-to-hg-commit

Find the hg commit corresponding to a git commit.

git-push-to-hg

Usage: git push-to-hg [-t/--tip] PATH_TO_HG_REPO [GIT_REVS]

Push commits from git to a new qqueue in an hg repository. If GIT_REVS is omitted, push the commits $(git merge-base HEAD $(git-tracks))..HEAD (i.e. everything in the current branch that's not upstream).

If -t or --tip is specified, pull and update the hg repository to latest tip before pushing. Otherwise, update the hg repository to the revision atop which the git commits are based.

git-push-to-try

Usage: git push-to-try [-r/--rev REVISION_OR_RANGE] [-t/--tip] PATH_TO_HG_REPO TRYCHOOSER_PARAMS

Push the commits $(git merge-base HEAD $(git-tracks))..HEAD (i.e. everything in the current branch that's not upstream) to try, by way of the given hg repository.

If -r/--rev REVISION_OR_RANGE is supplied, then push those commits to try instead of $(git merge-base HEAD $(git-tracks))..HEAD. For example, if you are working on a feature branch that was branched off of master, and want to push everything on that branch to try, use --rev master..HEAD.

TRYCHOOSER_PARAMS should be, e.g. -b do -p all -u all -t none.

git-push-to-mozreview

Usage: git push-to-review [-r/--rev REVISION_OR_RANGE] [-t/--tip] PATH_TO_HG_REPO

PLEASE NOTE git-cinnabar combined with git-mozreview is the better-supported way to push to mozreview using git!

Push the commits $(git merge-base HEAD $(git-tracks))..HEAD (i.e. everything in the current branch that's not upstream) to mozreview, by way of the given hg repository.

If -r/--rev REVISION_OR_RANGE is supplied, then push those commits to mozreview instead of $(git merge-base HEAD $(git-tracks))..HEAD. For example, if you are working on a feature branch that was branched off of master, and want to push everything on that branch to try, use --rev master..HEAD.

git-push-to-trychooser

Usage: git push-to-trychooser [-t/--tip] PATH_TO_HG_REPO [GIT_REVS]

The same as git push-to-hg, but also runs the interactive trychooser command before pushing the commits to try from the given hg repository.

To use this, you must install the trychooser Mercurial extension from its repository. (There are some out-of-date versions of this extension floating around, so be sure to use this repository.)

git-qparent

Outputs the last common revision of the current branch and upstream. (This command is a synonym for git merge-base HEAD $(git-tracks).)

git-qrebase

An alias for git rebase -i $(git qparent). This lets you interactively rebase your current branch without moving the commits to a new upstream base.

git-edit-files

Open all the files modified in the specified rev range in your $EDITOR. (If no rev range is specified, open the files modified in your current checkout.)

git-fix-whitespace

Eliminate any trailing whitespace from your uncommitted changes.

Note that this will reset your index; that is, any changes you've git add'ed will need to be added again. But it won't (or at least, shouldn't!) erase any changes.

git-qapplied

Like hg qapplied, output the commits in this branch which are not upstream.

git-patch-to-hg-patch

Format a patch from git format-patch as an hg patch.

git-branchname

Output the name of the active git branch, but if there's no git repository below the cwd, output nothing. This is useful when you want to display the current branch name on the command line.

For example, I have in my ~/.bashrc:

function vcs-branchname() {
  git_branch=`git branchname`
  if [[ "$git_branch" != "" ]]; then
    echo " ($git_branch)"
  fi
}

PROMPT_COLOR="35m"
PROMPT_COMMAND='BRANCH_NAME=`vcs-branchname`'
PS1='\[\033[01;$PROMPT_COLOR\]\u@\h\[\033[00m\]:\[\033[01;$PROMPT_COLOR\]\w\[\033[00m\]$BRANCH_NAME\$ '

which makes my prompt look like

jlebar@hostname:~/current/path (name-of-git-branch)$

pre-commit

A pre-commit hook which checks for .orig files and trailing whitespace.

To install this hook, symlink it into your repository's .git/hooks directory (with the name pre-commit).

moz-git-tools's People

Contributors

aethanyc avatar aknow avatar amccreight avatar andreastt avatar avih avatar bill-mccloskey avatar chenpighead avatar ehsan avatar fitzgen avatar glandium avatar heycam avatar indygreg avatar jlebar avatar jrmuizel avatar jryans avatar marshall avatar mhammond avatar mozilla-github-standards avatar mrbkap avatar muxator avatar nephyrin avatar saschanaz avatar sethfowler avatar simonlindholm avatar standard8 avatar strugee avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

moz-git-tools's Issues

Make upstream-branch optional

I'm happy with running:

git-push-to-try -t -r fx-team..HEAD ~/hg-fx-team 'try_options'

It contains all the information to push it to try. Upstream-branch seems not necessary here.

`[PATCH]` prefix in commit message not removed with git-patch-to-hg-patch

We use the github mirror a lot to work on patches for Firefox. When it comes to landing those patches I always have to manually edit the summary because the tool doesn't remove the [PATCH] prefix as set by git. Given our check-in rules that should not be present. So can the git-patch-to-hg-patch tool please remove that prefix?

push-to-try complains about merge bases even when I specify a revision range

If I specify a revision range, it shouldn't need to find any merge bases or anything as far as I can tell, but it tries anways and then when it fails to find one it aborts.

$ git push-to-try -r master.. -t ../hg-mozilla-central/ "-b do -p all -u jittests,jittest-1,jittest-2 -t none"
You are not using the latest revision of moz-git-tools.  Consider updating your tree.
master..
On branch saved-frame-iter.
4ad3b97 Bug 1202028 - Implement range based for loops for SavedFrame stacks; r=terrence
Warning: Could not find a upstream for HEAD
usage: git merge-base [-a | --all] <commit> <commit>...
   or: git merge-base [-a | --all] --octopus <commit>...
   or: git merge-base --independent <commit>...
   or: git merge-base --is-ancestor <commit> <commit>
   or: git merge-base --fork-point <ref> [<commit>]

    -a, --all             output all common ancestors
    --octopus             find ancestors for a single n-way merge
    --independent         list revs not reachable from others
    --is-ancestor         is the first one ancestor of the other?
    --fork-point          find where <commit> forked from reflog of <ref>

git-push-to-try invokes git merge-base incorrectly

$ git push-to-try -t -r master..jemalloc3-partitions ../mozilla-central.hg/ '-b do -p all -u all -t none'
master..jemalloc3-partitions
On branch jemalloc3-partitions.
a369460 Add malloc_create_partition and {m,re,c}alloc_from_partition to mozmemory's API.
aca2f73 Use a separate partition for all SpiderMonkey allocations.
usage: git merge-base [-a|--all] <commit> <commit>...
   or: git merge-base [-a|--all] --octopus <commit>...
   or: git merge-base --independent <commit>...
   or: git merge-base --is-ancestor <commit> <commit>
   or: git merge-base --fork-point <ref> [<commit>]

    -a, --all             output all common ancestors
    --octopus             find ancestors for a single n-way merge
    --independent         list revs not reachable from others
    --is-ancestor         is the first one ancestor of the other?
    --fork-point          find where <commit> forked from reflog of <ref>

I think this has to do with the fact that, since 90c8108, git-tracks -d will no longer print origin/master. Hacking it to reintroduce that behavior fixes the problem for me.

Clarify what is PATH_TO_HG_REPO?

I'm learning how to use these, and looking at doing a push to try server with git-push-to-trychooser. The main page readme.MD talks about PATH_TO_HG_REPO, however I don't quite understand what that refers to. Do I need to have mozilla-central Mercurial repository cloned locally and PATH_TO_HG_REPO should point to that, e.g. ~/mozilla-central/? (If so, why? is gecko-dev mirror not enough?) Or should PATH_TO_HG_REPO point perhaps to https://hg.mozilla.org/mozilla-central/ ?

Incorrect format

When I run git patch-format I get a file like this:

From fb6aa073d6648b58e92f1d7ecb903044c3c7c61c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomasz=20Ko=C5=82odziejski?= <[email protected]>
Date: Wed, 13 Aug 2014 15:59:46 -0700
Subject: [PATCH 1/1] Bug 1051187 - "Match case" button does not refresh the
 number of occurences. r=mikedeboer

---
 toolkit/content/widgets/findbar.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/toolkit/content/widgets/findbar.xml b/toolkit/content/widgets/findbar.xml
index 3f09ffd..d55f7aa 100644
--- a/toolkit/content/widgets/findbar.xml
+++ b/toolkit/content/widgets/findbar.xml
@@ -307,6 +307,7 @@
             case "accessibility.typeaheadfind.casesensitive":
               this._self._typeAheadCaseSensitive = prefsvc.getIntPref(aPrefName);
               this._self._updateCaseSensitivity();
+              this._self._find();
               if (this._self.getElement("highlight").checked)
                 this._self._setHighlightTimeout();
               break;
-- 
2.0.4

Which gets converted to:

# HG changeset patch 
# User Tomasz Kołodziejski <[email protected]>

[PATCH 1/1] Bug 1051187 - "Match case" button does not refresh the number of occurences. r=mikedeboer

---
 toolkit/content/widgets/findbar.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/toolkit/content/widgets/findbar.xml b/toolkit/content/widgets/findbar.xml
index 3f09ffd..d55f7aa 100644
--- a/toolkit/content/widgets/findbar.xml
+++ b/toolkit/content/widgets/findbar.xml
@@ -307,6 +307,7 @@
             case "accessibility.typeaheadfind.casesensitive":
               this._self._typeAheadCaseSensitive = prefsvc.getIntPref(aPrefName);
               this._self._updateCaseSensitivity();
+              this._self._find();
               if (this._self.getElement("highlight").checked)
                 this._self._setHighlightTimeout();
               break;
-- 
2.0.4

It looks like the part -- 2.0.4 should not be there because its just the git version. Its actually pretty weird that git includes that. I tried to find the documentation of git format but I somehow couldn't.

Tag a release?

Hello,
It would be great to have a tagged release so we could include moz-git-tools in the Homebrew core.
Thanks!

Real example for git-push-to-try

Could I ask that you include an actual example of how to use the git-push-to-try. I can't work out how to use it from the description 😿.

`git push-to-try` complains about try not being local?

I'm slightly confused about why

git push-to-try -t ssh://hg.mozilla.org/try/ -b do -p all -u all -t none

fails with the following error message:

abort: repository 'ssh://hg.mozilla.org/try/' is not local

I'm trying to push a patch to Mozilla's try server. How could something like that be local? How can I push my patch to try?

`git bz apply` fails to detect patch format

It seems to always fail to detect the patch format lately:

$ git bz apply 1218817
Debug: searching for Bugzilla cookies in Firefox profile

Bug 1218817 - Extend the debugger protocol to list all service worker registrations.

patch
Apply? [yn] y

Patch format detection failed.
Patch left in /tmp/patch-v7nIPq.patch

But then:

$ git apply /tmp/patch-v7nIPq.patch
# success

git-push-to-hg msys issues

[1] Using latest mozilla-build (2.1RC1) and latest git-for-windows (2.6.3), the following code:

if [[ $OSTYPE == "msys" ]]; then
  # mozbuild uses msys (which uses "/c/somedir" paths), but git seems to be
  # based on cygwin (which uses "c:/somedir") - but markh *actually* sees
  # "c:/somedir\filename" - which upsets most $0 usage.
  # So fix it up and store the result in $this
  this="/${this/:/}" # change "c:" to "/c/"
  this="${this/\\//}" # change "\" to "/"
fi

PATH="$(dirname $this):$PATH"

Produces $this as //c/some/path (two slashes instead of one). If I remove this msys workaround, then it continues correctly.

[2] Once it continues past that part, I'm seeing (specific to my command):

51e64c0d2c7e6f74786413331db6ebcc943f7004..HEAD
On branch before1167601.
82cf98e instrument BOT
/usr/bin/env: python2: No such file or directory

And indeed there's no python2, and my mercurial dir state is now different than before I invoked git-push-to-try (e.g. all my mq patches got messed up).

Here are the tab completion options for python within msys (mozilla-build 2.1RC1):
python python.exe python2.7.exe python27.dll pythonw.exe

I'd suggest that before git-push-to-hg starts executing, it will:

  1. Make sure it has what it needs (python, possibly others).
  2. If the hg dir has a patch queue, possibly with some applied patches, print out the command which can be used to restore them in case something goes wrong, or refuse to execute if it can't handle existing patch queue well.

CODE_OF_CONDUCT.md file missing

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

  1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
  2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.