[no subject]
unsubscribe alsa-devel
[PATCH] Allow the short-hand - replacing @{-1} in git worktree add
Since `git worktree add` uses `git checkout` when `[]` is used,
and `git checkout -` is already supported, it makes sense to allow the
same shortcut in `git worktree add`.
Signed-off-by: Matthieu Moy , Jordan DE GEA
---
Documentation/git-worktree.txt | 3 ++-
builtin/worktree.c | 3 +++
t/t2025-worktree-add.sh| 17 +
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index c622345..28dc559 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -48,7 +48,8 @@ add []::
Create `` and checkout `` into it. The new working directory
is linked to the current repository, sharing everything except working
-directory specific files such as HEAD, index, etc.
+directory specific files such as HEAD, index, etc. You may also specify
+`-` as `` which is synonymous with `"@{-1}"`.
+
If `` is omitted and neither `-b` nor `-B` nor `--detached` used,
then, as a convenience, a new branch based at HEAD is created automatically,
diff --git a/builtin/worktree.c b/builtin/worktree.c
index d8e3795..d800d47 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -340,6 +340,9 @@ static int add(int ac, const char **av, const char *prefix)
path = prefix ? prefix_filename(prefix, strlen(prefix), av[0]) : av[0];
branch = ac < 2 ? "HEAD" : av[1];
+ if (!strcmp(branch, "-"))
+ branch = "@{-1}";
+
opts.force_new_branch = !!new_branch_force;
if (opts.force_new_branch) {
struct strbuf symref = STRBUF_INIT;
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 3acb992..3f8437b 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -18,6 +18,23 @@ test_expect_success '"add" an existing empty worktree' '
git worktree add --detach existing_empty master
'
+test_expect_success '"add" using shorthand - fails when no previous branch' '
+ test_must_fail git worktree add existing -
+'
+
+test_expect_success '"add" using shorthand' '
+ git checkout -b newbranch &&
+ echo hello >myworld &&
+ git add myworld &&
+ git commit -m myworld &&
+ git checkout master &&
+ git worktree add short-hand - &&
+ (
+ cd short-hand &&
+ git status | head -1 | grep newbranch
+ )
+'
+
test_expect_success '"add" refuses to checkout locked branch' '
test_must_fail git worktree add zere master &&
! test -d zere &&
--
2.7.4 (Apple Git-66)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCHv2] Allow the short-hand - replacing @{-1} in git worktree add
Since `git worktree add` uses `git checkout` when `[]` is used,
and `git checkout -` is already supported, it makes sense to allow the
same shortcut in `git worktree add`.
Signed-off-by: Matthieu Moy
Signed-off-by: Jordan DE GEA
---
Documentation/git-worktree.txt | 3 ++-
builtin/worktree.c | 3 +++
t/t2025-worktree-add.sh| 17 +
3 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index c622345..28dc559 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -48,7 +48,8 @@ add []::
Create `` and checkout `` into it. The new working directory
is linked to the current repository, sharing everything except working
-directory specific files such as HEAD, index, etc.
+directory specific files such as HEAD, index, etc. You may also specify
+`-` as `` which is synonymous with `"@{-1}"`.
+
If `` is omitted and neither `-b` nor `-B` nor `--detached` used,
then, as a convenience, a new branch based at HEAD is created automatically,
diff --git a/builtin/worktree.c b/builtin/worktree.c
index d8e3795..d800d47 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -340,6 +340,9 @@ static int add(int ac, const char **av, const char *prefix)
path = prefix ? prefix_filename(prefix, strlen(prefix), av[0]) : av[0];
branch = ac < 2 ? "HEAD" : av[1];
+ if (!strcmp(branch, "-"))
+ branch = "@{-1}";
+
opts.force_new_branch = !!new_branch_force;
if (opts.force_new_branch) {
struct strbuf symref = STRBUF_INIT;
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 3acb992..ef81bc6 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -18,6 +18,23 @@ test_expect_success '"add" an existing empty worktree' '
git worktree add --detach existing_empty master
'
+test_expect_success '"add" using shorthand - fails when no previous branch' '
+ test_must_fail git worktree add existing -
+'
+
+test_expect_success '"add" using shorthand' '
+ git checkout -b newbranch &&
+ echo hello >myworld &&
+ git add myworld &&
+ git commit -m myworld &&
+ git checkout master &&
+ git worktree add short-hand - &&
+ (
+ cd short-hand &&
+ test $(git rev-parse --symbolic-full-name HEAD) =
"refs/heads/newbranch"
+ )
+'
+
test_expect_success '"add" refuses to checkout locked branch' '
test_must_fail git worktree add zere master &&
! test -d zere &&
--
2.7.4 (Apple Git-66)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Asymetric implementation
Hi everyone, here is the fact, working with an asymetric workflow is not as easy as it could be. There are many options only setting by hands. And they are not easy to use, to understand and sometimes there are not suitable. This is an example of what git could do : Environment : - You have the main repository -> A. - You have the fork repository of A -> fA - You have the clone of fA on your computer. - You want to work on fA/master and synchronize your branch A/branch1 with A/master So, you need to link the pull request to A/master and the push request to fA/branchA. Configuration : - branch.branchA.remote with A - remote.pushDefault with fA or branch.branchA.pushRemote with fA - branch.branchA.merge with fA. The steps to set those parameters are not user friendly, not complete and mistakes can happen(with --set-upstream for example) We are working on it and have solutions about it. Please, tell me what is the best for you and why ? Here is the solutions : 1. a. add the config var : remote.pullDefault b. add the config var : branch..pullRemote c. add `git pull --set-default` in order to set remote.pushDefault d. add `git pull --set-remote` in order to set branch..pullRemote With that solution, git will have a complete configuration with : - branch.remote, branch.pullRemote and branch..pushRemote. - remote.pullDefault, remote.pushDefault 2. a. add `git pull --set-default` in order to move branch..remote to remote.pushDefault b. add git pull --set-remote` in order to move branch..remote to branch..pushRemote With this solution, we only add options for commands and not in config file. You can add your solution. I think that the first one is the best for now and for the future. The second one seems to be the easy way to implement but not the best. What is your opinion ? Best Regards. Jordan DE GEA ENSIMAG 2A - ISI jordan.de-...@ensimag.grenoble-inp.fr -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Triangular Workflow: user friendly full implementation
We are working on full implementation of triangular workflow feature. For now, the main options available are: - branch..pushRemote - remote.pushDefault And only setable by hands. As it can be difficult to understand, here is what we want to do. Context: - One main remote repository, e.g. git/git. - A remote fork (e.g. a GitHub fork) of git/git, e.g. me/git. - A local clone of me/git on the machine Purposes: - the local branch master has to fetch to git/git by default - the local branch master has to push to me/git by default Configuration wanted: - Add a remote to git/git e.g. `git remote add ...` - Set the fetch remote for branch as default. For now, we can do that by setting: - branch..remote to git/git - branch..pushRemote to me/git But many options set `branch..remote`, a suitable solution is to implement an option for the fetch for example. Here is what we want to implement: 1. a. add the config var: remote.fetchDefault b. add the config var: branch..fetchRemote c. add `git fetch --set-default` in order to set remote.fetchDefault d. add `git fetch --set-remote` in order to set branch..fetchRemote e. add `git pull --set-default` in order to set remote.fetchDefault f. add `git pull --set-remote` in order to set branch..fetchRemote 2. a. add `git push --set-default` in order to set remote.pushDefault b. add `git push --set-remote` in order to set branch..pushRemote What's your opinion about this feature ? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] worktree: allow "-" short-hand for @{-1} in add command
From: Jordan DE GEA
Since `git worktree add` uses `git checkout` when `[]` is used,
and `git checkout -` is already supported, it makes sense to allow the
same shortcut in `git worktree add`.
Signed-off-by: Matthieu Moy
Signed-off-by: Jordan DE GEA
---
Documentation/git-worktree.txt | 3 ++-
builtin/worktree.c | 3 +++
t/t2025-worktree-add.sh| 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index c622345..48e5fdf 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -48,7 +48,8 @@ add []::
Create `` and checkout `` into it. The new working directory
is linked to the current repository, sharing everything except working
-directory specific files such as HEAD, index, etc.
+directory specific files such as HEAD, index, etc. The last branch you
+were on can be specify with `-` as `` which is synonymous with
`"@{-1}"`.
+
If `` is omitted and neither `-b` nor `-B` nor `--detached` used,
then, as a convenience, a new branch based at HEAD is created automatically,
diff --git a/builtin/worktree.c b/builtin/worktree.c
index d8e3795..d800d47 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -340,6 +340,9 @@ static int add(int ac, const char **av, const char *prefix)
path = prefix ? prefix_filename(prefix, strlen(prefix), av[0]) : av[0];
branch = ac < 2 ? "HEAD" : av[1];
+ if (!strcmp(branch, "-"))
+ branch = "@{-1}";
+
opts.force_new_branch = !!new_branch_force;
if (opts.force_new_branch) {
struct strbuf symref = STRBUF_INIT;
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 3acb992..b713efb 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -18,6 +18,24 @@ test_expect_success '"add" an existing empty worktree' '
git worktree add --detach existing_empty master
'
+test_expect_success '"add" using shorthand - fails when no previous branch' '
+ test_must_fail git worktree add existing -
+'
+
+test_expect_success '"add" using - shorthand' '
+ git checkout -b newbranch &&
+ echo hello >myworld &&
+ git add myworld &&
+ git commit -m myworld &&
+ git checkout master &&
+ git worktree add short-hand - &&
+ cd short-hand &&
+ test $(git rev-parse --symbolic-full-name HEAD) = "refs/heads/newbranch"
+ branch=$(cd short-hand && git rev-parse --symbolic-full-name HEAD) &&
+ test "$branch" = refs/heads/newbranch &&
+ cd ..
+'
+
test_expect_success '"add" refuses to checkout locked branch' '
test_must_fail git worktree add zere master &&
! test -d zere &&
--
2.7.4 (Apple Git-66)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] worktree: allow "-" short-hand for @{-1} in add command
>> +test_expect_success '"add" using shorthand - fails when no previous branch' >> ' >> +test_must_fail git worktree add existing - >> +' > > Just an observation, but the error message we would see here might > be interesting. Of course, that’s useful to be sure of the error, I will do in next preroll. > >> +branch=$(cd short-hand && git rev-parse --symbolic-full-name HEAD) && >> +test "$branch" = refs/heads/newbranch && >> +cd .. > > If any of the command between "cd short-hand" and "cd .." failed, > after correcting the broken &&-chain, the next test will end up > running in short-hand directory, which it is not expecting. A > canonical way to avoid this problem is to replace the above with: > > ... >git worktree add short-hand - && >( > cd short-hand && >... >test "$branch" = refs/heads/newbranch > ) > > In this particular case, alternatively, you could also do something > like this: > >git worktree add short-hand - && > echo refs/heads/newbranch >expect && > git -C short-hand rev-parse --symbolic-full-name HEAD >actual && > test_cmp expect actual Yes, that’s a good idea. I take these lines. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] worktree: allow "-" short-hand for @{-1} in add command
Since `git worktree add` uses `git checkout` when `[]` is used,
and `git checkout -` is already supported, it makes sense to allow the
same shortcut in `git worktree add`.
Signed-off-by: Matthieu Moy
Signed-off-by: Jordan DE GEA
---
Changes since v1:
- improved tests.
- improved documentation.
Documentation/git-worktree.txt | 3 ++-
builtin/worktree.c | 3 +++
t/t2025-worktree-add.sh| 18 ++
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index c622345..8358a3e 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -48,7 +48,8 @@ add []::
Create `` and checkout `` into it. The new working directory
is linked to the current repository, sharing everything except working
-directory specific files such as HEAD, index, etc.
+directory specific files such as HEAD, index, etc. `-` may also be
+specified as ``; it is synonymous with `@{-1}`.
+
If `` is omitted and neither `-b` nor `-B` nor `--detached` used,
then, as a convenience, a new branch based at HEAD is created automatically,
diff --git a/builtin/worktree.c b/builtin/worktree.c
index d8e3795..d800d47 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -340,6 +340,9 @@ static int add(int ac, const char **av, const char *prefix)
path = prefix ? prefix_filename(prefix, strlen(prefix), av[0]) : av[0];
branch = ac < 2 ? "HEAD" : av[1];
+ if (!strcmp(branch, "-"))
+ branch = "@{-1}";
+
opts.force_new_branch = !!new_branch_force;
if (opts.force_new_branch) {
struct strbuf symref = STRBUF_INIT;
diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh
index 3acb992..c4f5177 100755
--- a/t/t2025-worktree-add.sh
+++ b/t/t2025-worktree-add.sh
@@ -18,6 +18,24 @@ test_expect_success '"add" an existing empty worktree' '
git worktree add --detach existing_empty master
'
+test_expect_success '"add" using shorthand - fails when no previous branch' '
+ echo "fatal: invalid reference: @{-1}" >expect &&
+ test_must_fail git worktree add existing_short - 2>actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '"add" using - shorthand' '
+ git checkout -b newbranch &&
+ echo hello >myworld &&
+ git add myworld &&
+ git commit -m myworld &&
+ git checkout master &&
+ git worktree add short-hand - &&
+ echo refs/heads/newbranch >expect &&
+ git -C short-hand rev-parse --symbolic-full-name HEAD >actual &&
+ test_cmp expect actual
+'
+
test_expect_success '"add" refuses to checkout locked branch' '
test_must_fail git worktree add zere master &&
! test -d zere &&
--
2.7.4 (Apple Git-66)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Triangular Workflow UI improvement
In my last message, I forgot to add some important contributors linked to this feature. Some of you already replied to me. I will answer shortly. Sorry for the noise. > > We are working on full implementation of triangular workflow feature. > For now, the main options available are: >- branch..pushRemote >- remote.pushDefault > And only setable by hands. > > As it can be difficult to understand, here is what we want to do. > > > Context: > - One main remote repository, e.g. git/git. > - A remote fork (e.g. a GitHub fork) of git/git, e.g. me/git. > - A local clone of me/git on the machine > > Purposes: > - the local branch master has to fetch to git/git by default > - the local branch master has to push to me/git by default > > Configuration wanted: > - Add a remote to git/git e.g. `git remote add ...` > - Set the fetch remote for branch as default. > > For now, we can do that by setting: > - branch..remote to git/git > - branch..pushRemote to me/git > But many options set `branch..remote`, a suitable solution is to > implement an option for the fetch for example. > > > Here is what we want to implement: > > 1. > a. add the config var: remote.fetchDefault > b. add the config var: branch..fetchRemote > c. add `git fetch --set-default` in order to set remote.fetchDefault > d. add `git fetch --set-remote` in order to set > branch..fetchRemote > e. add `git pull --set-default` in order to set remote.fetchDefault > f. add `git pull --set-remote` in order to set branch..fetchRemote > > 2. > a. add `git push --set-default` in order to set remote.pushDefault > b. add `git push --set-remote` in order to set branch..pushRemote > > > What's your opinion about this feature ? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Triangular Workflow UI improvement
>> We are working on full implementation of triangular workflow feature. >> For now, the main options available are: >> - branch..pushRemote >> - remote.pushDefault >> And only setable by hands. > > And once it is set, you do not have to worry about it. I am not > sure per-branch thing is all that useful, unless you are always > working on a single branch like 'master', but the latter would be > just set once and forget about it. We got the example of our fork of git(e.g. GitHub). We want : - some branches that only fetch from git/git and push to our/git - the others branches fetch from and push to our/git. For now, we have to change branch..remote and branch..pushRemote(or remote.pushDefault). With branch..fetchRemote, we only have to set this one. fetchRemote is more explicit than remote for that case. Another point is that many commands can erase the old value of branch..remote. >> Context: >> - One main remote repository, e.g. git/git. >> - A remote fork (e.g. a GitHub fork) of git/git, e.g. me/git. >> - A local clone of me/git on the machine >> Purposes: >> - the local branch master has to fetch to git/git by default >> - the local branch master has to push to me/git by default > > Wouldn't remote.pushDefault be the single thing you need to set just > once and forget about it? Why would your users even want to do > these things … remote.pushDefault overrides branch..remote for all branches. The goal is to give an easily understandable config for complex configuration. Having all the configuration in the same part (e.g [branch « master »]) is easier to understand and edit. > >> c. add `git fetch --set-default` in order to set remote.fetchDefault >> d. add `git fetch --set-remote` in order to set >> branch..fetchRemote >> e. add `git pull --set-default` in order to set remote.fetchDefault >> f. add `git pull --set-remote` in order to set branch..fetchRemote >> a. add `git push --set-default` in order to set remote.pushDefault >> b. add `git push --set-remote` in order to set branch..pushRemote > > ... just to configure many variables every time they work on a new > branch? branch..pushRemote and all these options are optional. Options in commands may not be added. It just gives user friendly interaction with these options. To conclude: This feature is more about configuration clarity than possibility itself. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Triangular Workflow UI improvments
> Le 27 mai 2016 à 09:32, Philip Oakley a écrit : > For me, the first step would be to actually document a (the?) Triangular > Workflow in the documentation, so we are all taking about the same broad > method. > > At the moment there is a choice (assuming a ithub like service) of either > clone and then fork, or fork and clone the fork, which leave the user with > different fixups of their config's being required, so describing the easier > one would help folk. > > Likewise there are missing terms such as for the third place (the personal > fork) that is neither the upstream, nor the local repo. Making sure the > terminology is crisp and clean will greatly ease any implementation issues. > And then there are the possible workflows... Yes, you’re right. Writing a complete tutorial is a good idea. I start this job and the content will depend on the result of this discussion. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] Triangular Workflow UI improvement: Documentation
Currently, Triangular Workflow can be configured, but there is no Documentation about it. A documentation is useful to keep configuration possibilities up-to-date. The new documentation file gittriangularworkflow explains how to configure a triangular workflow. Signed-off-by: Matthieu Moy Signed-off-by: Jordan DE GEA --- Documentation/Makefile | 1 + Documentation/gittriangularworkflow.txt | 120 2 files changed, 121 insertions(+) create mode 100644 Documentation/gittriangularworkflow.txt diff --git a/Documentation/Makefile b/Documentation/Makefile index f6e288b..e9f6c80 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -34,6 +34,7 @@ MAN7_TXT += gitrevisions.txt MAN7_TXT += gittutorial-2.txt MAN7_TXT += gittutorial.txt MAN7_TXT += gitworkflows.txt +MAN7_TXT += gittriangularworkflow.txt MAN_TXT = $(MAN1_TXT) $(MAN5_TXT) $(MAN7_TXT) MAN_XML = $(patsubst %.txt,%.xml,$(MAN_TXT)) diff --git a/Documentation/gittriangularworkflow.txt b/Documentation/gittriangularworkflow.txt new file mode 100644 index 000..803eee3 --- /dev/null +++ b/Documentation/gittriangularworkflow.txt @@ -0,0 +1,120 @@ +gittriangularworkflow(7) +=== + +NAME + +gittriangularworkflow - A tutorial about the configuration of a +Triangular Workflow + +SYNOPSIS + +[verse] +git fetch +git remote +git config +Options in git-config: +- `remote.pushDefault` +- `branch..pushRemote` +- `branch..origin` + +DESCRIPTION +--- + +Triangular Workflow (or Asymmetric Workflow) is a workflow which gives +the possibility to: + +- fetch (or pull) from a repository +- push to another repository + +In some projects, you don't have to push directly to the project but +have to suggest your commits to the maintainer (e.g. pull requests). +Using Triangular Workflow is a common way for these projects. + +This document attempts to help you configure a Triangular Workflow. +Here is an example of configuration: + + + --- +| UPSTREAM | maintainer | ORIGIN | +| git/git |- - - - - - - -| me/git | + ← --- + \ / + \ / + fetch↓\ /↑push +\ / + \ / + - + | LOCAL | + - + + +CREATE YOUR REPOSITORY +-- +The first step is to create your own repository. To do that you can: + +- a. fork (e.g. GitHub) the main project (e.g git/git), or +- b. create an empty repository + +a. Fork the project +~~~ +Go to the repository of the project (e.g. git/git) you want +and fork it. + +b. Create from scratch +~~ +Create a repository on your prefered Git repository hosting service. + +Clone it + +Clone your repository on your machine. + + +CONFIGURE BRANCHES +-- +In many projects, the branch `master` have to be pulled from +the main repository(e.g. git/git) and pushed to your repository +(e.g. me/git). + +Adding the main project remote +~~ +Add a new remote (e.g. upstream): + +=== +`git remote add upstream ` +=== + +Pull from upstream by default +~ + +=== +`git config branch.master.remote upstream` +=== + + +Push to origin by default +~ + +=== +`git config branch.master.pushRemote origin` +=== + + +GET YOUR PROJECT UP TO DATE +--- + +Now that `branch.master.remote` and `branch.master.pushRemote` are +set, you can use the following commands to be up to date: += + * `git pull` + * `git push` += + + +SEE ALSO + +linkgit:git-config[1] +linkgit:git-remote[1] +linkgit:git-fetch[1] + + + -- 2.7.4 (Apple Git-66) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation
> Jordan DE GEA writes: >> Currently, Triangular Workflow can be configured, but there is no >> Documentation about it. A documentation is useful to keep >> configuration possibilities up-to-date. > > You're using capitalization in a strange way. I don't think Triangular > Workflow deserves to be capitalized, and Documentation certainly > doesn't. > > Also, you're wrapping your text in a strange way. You did see the > exchange with Antoine about this, right? Yes, thank you. I will fix that. > A question about your final goal: I had understood that you wanted to > improve the UI, and to design a proper UI you wanted to write a tutorial > about the future UI, and then implement it. Did I mis-understand? What > are the next steps in your plan? The first goal is to write a documentation on "how to set up a triangular workflow" with the current options. After that, we can discuss about the UI improvement. >> Documentation/Makefile | 1 + >> Documentation/gittriangularworkflow.txt | 120 >> > [...] >> --- a/Documentation/Makefile >> +++ b/Documentation/Makefile >> @@ -34,6 +34,7 @@ MAN7_TXT += gitrevisions.txt >> MAN7_TXT += gittutorial-2.txt >> MAN7_TXT += gittutorial.txt >> MAN7_TXT += gitworkflows.txt >> +MAN7_TXT += gittriangularworkflow.txt > > Adding documentation is one thing, but it needs to be discoverable. No > one is going to type "man gittriangularworkflow" or open > https://git-scm.com/docs/gittriangularworkflow without being told to. > > Two obvious questions/suggestions seeing the above: > > * Why not add the new documentation as a subsection of gitworkflows.txt? > > * If not, then at the very least a link to gittriangularworkflow should > appear in the SEE ALSO section of gitworkflows.txt. Yes, adding a subsection in gitworkflows seems to be a better choice. > >> +DESCRIPTION >> +--- >> + >> +Triangular Workflow (or Asymmetric Workflow) is a workflow which gives >> +the possibility to: >> + >> +- fetch (or pull) from a repository >> +- push to another repository > > I wouldn't say "gives the possibility to": you already have this > possibility all the time when using Git. > > I find Michael Haggerty's definition of triangular workflow much > clearer: > > https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows#improved-support-for-triangular-workflows > > I don't see a licence on the GitHub blog, so I don't think it's legal to > copy-past directly to our docs, but Michael might allow us to do so? You’re right. Can Michael Taggerty allow us to use his text ? > >> +In some projects, you don't have to push directly > > s/don't have to/cannot/ Done > ? > >> +Here is an example of configuration: >> + >> + >> + --- >> +| UPSTREAM | maintainer | ORIGIN | >> +| git/git |- - - - - - - -| me/git | >> + ← --- >> + \ / >> + \ / >> + fetch↓\ /↑push >> +\ / >> + \ / >> + - >> + | LOCAL | >> + - >> + > > The most important is missing: what is the role of each repo? which one > is public and which one is private? > > I'd rather avoid using "ORIGIN" here, as the name is used for the > default remote when cloning, and it's a valid workflow to "git clone" > from UPSTREAM and then "git remote add" your public fork. Perhaps > PUBLIC-FORK? With Michael Taggerty’s text, it will be more understandable. > >> +CREATE YOUR REPOSITORY >> +-- >> +The first step is to create your own repository. To do that you can: >> + >> +- a. fork (e.g. GitHub) the main project (e.g git/git), or >> +- b. create an empty repository >> + >> +a. Fork the project >> +~~~ >> +Go to the repository of the project (e.g. git/git) you want >> +and fork it. >> + >> +b. Create from scratch >> +~~ >> +Create a repository on your prefered Git repository hosting service. >> + >> +Clone it >> + >> +Clone your repository on your machine. > > I don't think this section helps much. If the user knows that he or she > wants
Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation
> From: "Jordan DE GEA" >> This document attempts to help you configure a Triangular Workflow. >> +Here is an example of configuration: >> + >> + >> + --- >> +| UPSTREAM | maintainer | ORIGIN | > > UPSTREAM and ORIGIN are two different types of description. Origin being a > too generic Git name that is used multiply elsewhere. > > That said, trying to find a good name for that 'third place' is not easy. > It's neither upstream, nor downstream (for Junio - the maintainer special > case - git.git would be his downstream). The me/git repo is like a ferryman's > landing across the other side of the river flow, a safe harbour if you will. > > Finding a suitable name has all the same issues as deciding the generic > public name for the staging area / index. The ability to have a second > perfect copy is very new - historically all the dictionary names relate to > copies or forgeries (you could only have one master - DVCS breaks that > mould). Perhaps (poorly) "MyFork", or "MyServer". There maybe a good French > word we can use. > You’re right, finding a good name is not easy. Firstly, I wanted to use DOWNSTREAM and UPSTREAM. But git doesn’t make the difference between those words. Looking for the description of the third place, I wrote that it’s the remote used to push modifications. Assembling the main words push and remote, it creates PUSH_REMOTE which seems a good name. e.g. That’s clear to say "I push to the push_remote". As the option `branch..pushRemote` exists, a little text has to be added in order to prevent confusion. By the way, in the documentation, confusions will be avoided by using `branch..pushRemote` and ‘push_remote`. Like PUSH_REMOTE, the remote where we fetch can be called FETCH_REMOTE. e.g. That’s clear to say "I fetch from fetch_remote". Do you agree? > >> + ← --- >> + \ / >> + \ / >> + fetch↓\ /↑push >> +\ / >> + \ / >> + - >> + | LOCAL | >> + - >> + >> + >> +CREATE YOUR REPOSITORY >> +-- >> +The first step is to create your own repository. To do that you can: >> + >> +- a. fork (e.g. GitHub) the main project (e.g git/git), or >> +- b. create an empty repository >> + >> +a. Fork the project >> +~~~ >> +Go to the repository of the project (e.g. git/git) you want >> +and fork it. > > As I understand it one issue is to clearly suggest that it is best to fork > and then clone from your me/fork project such that the origin and it's > fetch/push are set up the easiest way. > > If the user clones the main project before forking and then tries to add the > me/fork there are more hoops to jump through to get all the fetch/push > settings re-arranged (this does depend on the Github fork method, but at > least the issue of which repo is cloned should be noted) Thank you, I will work on it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation
>> Like PUSH_REMOTE, the remote where we fetch can be called FETCH_REMOTE. >> e.g. That’s clear to say "I fetch from fetch_remote". >> >> Do you agree? > > That is technically correct, but to illustrate the overall flow, I'd > rather avoid naming the repositories in terms of git commands. If you do > so, you will probably end up with tautological explanations like this > later in the text: "FETCH_REMOTE is the remote from where you fetch, > PUSH_REMOTE is the remote to which you push, and LOCAL is local". > > I suggested PUBLIC-FORK earlier, and didn't get any feedback on it. I > think it translates the intent better than PUSH_REMOTE. An alternative > would be PUBLISH (= the repository you use to publish your changes so > that the maintainer can pick them). PUBLISH sounds good. I take it for the next patch. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation
> Matthieu Moy a écrit : > > That is technically correct, but to illustrate the overall flow, I'd > rather avoid naming the repositories in terms of git commands. If you do > so, you will probably end up with tautological explanations like this > later in the text: "FETCH_REMOTE is the remote from where you fetch, > PUSH_REMOTE is the remote to which you push, and LOCAL is local". > > I suggested PUBLIC-FORK earlier, and didn't get any feedback on it. I > think it translates the intent better than PUSH_REMOTE. An alternative > would be PUBLISH (= the repository you use to publish your changes so > that the maintainer can pick them). > "Philip Oakley" writes: > However your gitster/git repo feels like it would match the me/git viewpoint, > in that while it is 'open', it isn't really a formal publishing place. > Certainly I don't think that I 'publish' what's in my personal github repos, > which I use as an open backup (and any PR's I put to the G4W project repo are > referenced from there). For Philip Oakley, PUBLISH seems to not be a good name. For PUBLIC-FORK, a fork can be private so I think that’s not a good idea. As the third-place is the repository used to work on commits/patches, a simple name can be WORK_REPOSITORY. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCHv2] Documentation: triangular workflow
Currently, triangular workflow can be configured, but there is no
documentation about it. A documentation is useful to keep
configuration possibilities up-to-date.
A new subsection is created in gitworkflow.
Signed-off-by: Michael Haggerty
Signed-off-by: Matthieu Moy
Signed-off-by: Jordan DE GEA
---
Changes since version 1:
- content moved in gitworktree
- content improved
Documentation/gitworkflows.txt | 155 +
1 file changed, 155 insertions(+)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index f16c414..cd77893 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -463,6 +463,157 @@ if you get conflicts: `git am -3` will use index
information contained
in patches to figure out the merge base. See linkgit:git-am[1] for
other options.
+TRIANGULAR WORKFLOW
+---
+
+In some projects, you cannot push directly to the project but have to
+suggest your commits to the maintainer (e.g. pull requests).
+For these projects, it's common to use what's called a *triangular
+workflow*:
+
+- Taking the last version of the project by fetching (e.g.
+ **UPSTREAM**)
+- Writing modifications and push them to a fork (e.g. **PUBLIC-FORK**)
+- Opening a pull request
+- Checking of changes by the maintainer and, merging them into the
+ **UPSTREAM** repository if accepted
+
+
+
+-- -
+| UPSTREAM | maintainer | PUBLIC-FORK |
+| git/git |- - - - - - - -| me/remote|
+-- ← -
+ \ /
+ \ /
+ fetch↓\ /↑push
+ \ /
+ \ /
+ -
+ | LOCAL |
+ -
+
+
+Git options to use:
+~~~
+ - `branch..remote`
+ - `branch..pushRemote`
+ - `remote.pushDefault`
+ - `push.default`
+
+See linkgit:git-config[1].
+
+Push behaviour
+~~
+
+Setting the behavior of push for the triangular workflow:
+
+===
+* `git config push.default current`
+===
+
+
+Case 1: LOCAL is a clone of **PUBLIC-FORK**
+~~~
+
+'In this case, the remote named `origin` corresponds to **PUBLIC-FORK**.'
+
+Adding **UPSTREAM** remote:
+
+===
+* `git remote add upstream `
+===
+
+Setting `branch..remote` and `branch..pushRemote` in
+order to:
+
+ - pull from **UPSTREAM** without argument for pull
+ - push to **PUBLIC-FORK** (`origin`) without argument for push
+
+Example with master as :
+===
+* `git config branch.master.remote upstream`
+* `git config branch.master.pushRemote origin`
+===
+
+Case 2: LOCAL is a clone of **UPSTREAM**
+
+
+'In this case, the remote named `origin` corresponds to
+**UPSTREAM**.'
+
+Adding **PUBLIC-FORK** remote:
+
+===
+* `git remote add public_fork `
+===
+
+**Method 1: One option for all branches**
+
+Setting `remote.pushDefault` in order to push to **PUBLIC-FORK** without
+argument for push.
+
+===
+* `git config remote.pushDefault public_fork`
+===
+
+**Method 2: Each branch its option**
+
+Setting `branch..pushRemote` in order to push to **PUBLIC-FORK**
+without argument to push.
+
+Example with master as :
+===
+* `git config branch.master.pushRemote public_fork`
+===
+
+
+Stay up-to-date
+~~~
+
+Retrieving updates from **UPSTREAM** with `git pull` and sending
+them to **PUBLIC-FORK** with `git push`.
+
+Checks
+~~
+
+Uses of command line shorthand `@{push}` and `@{upstream}`.
+
+**Display the push remote's name: **
+
+===
+* `git rev-parse --abbrev-ref '@{push}'`
+===
+
+The shorthand `@{push}` denotes the remote-tracking branch
+where the would be pushed to. If no is specified
+(`@{push}`), takes the value of the current branch.
+
+See linkgit:git-rev-parse[1].
+
+**Display the fetch remote's name: **
+
+===
+* `git rev-parse --abbrev-ref '@{upstream}'`
+===
+
+The shorthand "@{upstream}" substitutes the name of the
+"upstream" of the branch. If no is specified (`@{upstream}`),
+ takes the value of the current branch.
+
+**Display commits added to the current branch since last push: **
+
+===
+* `git log @{push
Re: [RFC/PATCHv2] Documentation: triangular workflow
> Le 7 juin 2016 à 08:58, Matthieu Moy a écrit : > > "Philip Oakley" writes: > >> Given that clarification I'd be happier to go with it being one's >> 'Publish' repo. >> >> My initial reticence was because of the association of "publish" with >> vanity publishing and other forms of over-sharing and self promotion. >> >> A clarification/explanation that calling it a 'publish' repo is about >> granting access, and possible open access, would make it more >> acceptable. > > I think "publish" is the best we found up to now. > It seems that we choose ‘publish’. I’ll send the v3 of the patch soon. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3] Documentation: triangular workflow
Currently, triangular workflow can be configured, but there is no
documentation about it. A documentation is useful to keep
configuration possibilities up-to-date.
A new subsection is created in gitworkflow.
Signed-off-by: Michael Haggerty
Signed-off-by: Matthieu Moy
Signed-off-by: Jordan DE GEA
---
Changes since version 2:
- PUBLIC-FORK renamed for PUBLISH
Changes since version 1:
- content moved in gitworktree
- content improved
Documentation/gitworkflows.txt | 154 +
1 file changed, 154 insertions(+)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index f16c414..3b5fd09 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -463,6 +463,156 @@ if you get conflicts: `git am -3` will use index
information contained
in patches to figure out the merge base. See linkgit:git-am[1] for
other options.
+TRIANGULAR WORKFLOW
+---
+
+In some projects, you cannot push directly to the project but have to
+suggest your commits to the maintainer (e.g. pull requests).
+For these projects, it's common to use what's called a *triangular
+workflow*:
+
+- Taking the last version of the project by fetching (e.g.
+ **UPSTREAM**)
+- Writing modifications and push them to a fork (e.g. **PUBLISH**)
+- Opening a pull request
+- Checking of changes by the maintainer and, merging them into the
+ **UPSTREAM** repository if accepted
+
+
+
+-- -
+| UPSTREAM | maintainer | PUBLISH |
+| git/git |- - - - - - - -| me/remote|
+-- ← -
+ \ /
+ \ /
+ fetch↓\ /↑push
+ \ /
+ \ /
+ -
+ | LOCAL |
+ -
+
+
+Git options to use:
+~~~
+ - `branch..remote`
+ - `branch..pushRemote`
+ - `remote.pushDefault`
+ - `push.default`
+
+See linkgit:git-config[1].
+
+Push behaviour
+~~
+
+Setting the behavior of push for the triangular workflow:
+
+===
+* `git config push.default current`
+===
+
+
+Case 1: LOCAL is a clone of **PUBLISH**
+~~~
+
+'In this case, the remote named `origin` corresponds to **PUBLISH**.'
+
+Adding **UPSTREAM** remote:
+
+===
+* `git remote add upstream `
+===
+
+Setting `branch..remote` and `branch..pushRemote` in
+order to:
+
+ - pull from **UPSTREAM** without argument for pull
+ - push to **PUBLISH** (`origin`) without argument for push
+
+Example with master as :
+===
+* `git config branch.master.remote upstream`
+* `git config branch.master.pushRemote origin`
+===
+
+Case 2: LOCAL is a clone of **UPSTREAM**
+
+
+'In this case, the remote named `origin` corresponds to **UPSTREAM**.'
+
+Adding **PUBLISH** remote:
+
+===
+* `git remote add publish `
+===
+
+**Method 1: One option for all branches**
+
+Setting `remote.pushDefault` in order to push to **PUBLISH** without
+argument for push.
+
+===
+* `git config remote.pushDefault publish`
+===
+
+**Method 2: Each branch its option**
+
+Setting `branch..pushRemote` in order to push to **PUBLISH**
+without argument to push.
+
+Example with master as :
+===
+* `git config branch.master.pushRemote publish`
+===
+
+
+Stay up-to-date
+~~~
+
+Retrieving updates from **UPSTREAM** with `git pull` and sending
+them to **PUBLISH** with `git push`.
+
+Checks
+~~
+
+Uses of command line shorthand `@{push}` and `@{upstream}`.
+
+**Display the push remote's name: **
+
+===
+* `git rev-parse --abbrev-ref '@{push}'`
+===
+
+The shorthand `@{push}` denotes the remote-tracking branch
+where the would be pushed to. If no is specified
+(`@{push}`), takes the value of the current branch.
+
+See linkgit:git-rev-parse[1].
+
+**Display the fetch remote's name: **
+
+===
+* `git rev-parse --abbrev-ref '@{upstream}'`
+===
+
+The shorthand "@{upstream}" substitutes the name of the
+"upstream" of the branch. If no is specified (`@{upstream}`),
+ takes the value of the current branch.
+
+**Display commits added to the current branch since last push: **
+
+===
+* `git
Re: [PATCHv3] Documentation: triangular workflow
> Le 7 juin 2016 à 21:12, Junio C Hamano a écrit : > > Jordan DE GEA writes: > >> + >> +- Taking the last version of the project by fetching (e.g. >> + **UPSTREAM**) > > "by fetching (e.g. UPSTREAM)" does not finish the sentence nicely. > > "... by fetching from **UPSTREAM**" would work better. So would > "Fetching the latest version from the project (e.g. UPSTREAM) ». Ok. Changed for the next iteration. >> +- Writing modifications and push them to a fork (e.g. **PUBLISH**) >> +- Opening a pull request >> +- Checking of changes by the maintainer and, merging them into the >> + **UPSTREAM** repository if accepted > > You'd want to end these sentences with full-stop, by the way > OK too. >> + >> +-- - >> +| UPSTREAM | maintainer | PUBLISH | >> +| git/git |- - - - - - - -| me/remote| >> +-- ← - >> + \ / >> + \ / >> + fetch↓\ /↑push >> + \ / >> + \ / >> + - >> + | LOCAL | >> + - >> + >> + >> +Git options to use: >> +~~~ >> + - `branch..remote` >> + - `branch..pushRemote` >> + - `remote.pushDefault` >> + - `push.default` >> + >> +See linkgit:git-config[1]. > > The title says "options" but listed are configuration variables and > the referred document is also about git-config. Perhaps retitle it to > > Useful configuration variables >~~ > Ok too. > or something like that? > > One thing after reading the above lines that immediately came to my > mind was this: > >After listing these four and telling the reader to "See ...", is >there anything else the reader needs to learn from below? > > It may make the result a lot more useful document if this gives an > impression to the reader as if you are saying (you do not have to > actually say it) "We will guide you how to set up your workflow in > triangular way, and here are the key configuration variables you > will end up using; don't worry about the details of them, we'll > teach you all about them soon in the following paragraphs." > > And I found that "See linkgit:git-config[1]" go directly against > that line of narrative. A link is already added at the end of the document. So I delete this one. > >> +Push behaviour >> +~~ >> + ... >> + >> +Case 2: LOCAL is a clone of **UPSTREAM** >> + >> + >> +'In this case, the remote named `origin` corresponds to **UPSTREAM**.' >> + >> +Adding **PUBLISH** remote: >> + >> +=== >> +* `git remote add publish ` >> +=== > > It may perhaps be only me, but these blind instructions puts me off, > and what I find lacking is "Why should I do this?" "What benefit do > I get by doing this". Start it perhaps like this? > > Because you will be pushing into the publish repository > often, instead of having to type its URL every time, you > want a short name you can use to call it. > > and then give that "remote add". Ok. Similar text added for the next iteration. >> + >> +**Method 1: One option for all branches** >> + >> +Setting `remote.pushDefault` in order to push to **PUBLISH** without >> +argument for push. >> + >> +=== >> +* `git config remote.pushDefault publish` >> +=== > > This is not too bad, but I'd say > > With the "remote add" above, you can say "git push publish" > to push there, instead of saying its URL. But you may want > to be even lazier and say just "git push". To do so: > Ok too. Similar text added for the next iteration. > As a document that is geared toward being a tutorial, I personally > think it is better to stick to one arrangement rather than > presenting case 1/2 as two equivalently valid arrangements and > describe them to equal degree of detail. Otherwise, after finishing > reading Case 1 and immediately reading Case 2 heading
[PATCHv4] Documentation: triangular workflow
Currently, triangular workflow can be configured, but there is no
documentation about it. A documentation is useful to keep
configuration possibilities up-to-date.
A new subsection is created in gitworkflow.
Signed-off-by: Michael Haggerty
Signed-off-by: Matthieu Moy
Signed-off-by: Jordan DE GEA
---
Changes since v3:
* Text reorganized to follow:
- Introduction
- Preparation
- Staying up-to-date
- Alternatively
* Texts added to explain why we use commands in:
- Preparation
- Alternatively
Documentation/gitworkflows.txt | 177 -
1 file changed, 176 insertions(+), 1 deletion(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index f16c414..1ec1f63 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -463,6 +463,178 @@ if you get conflicts: `git am -3` will use index
information contained
in patches to figure out the merge base. See linkgit:git-am[1] for
other options.
+TRIANGULAR WORKFLOW
+---
+
+In some projects, you cannot push directly to the project but have to
+suggest your commits to the maintainer (e.g. pull requests).
+For these projects, it's common to use what's called a *triangular
+workflow*:
+
+- Taking the last version of the project by fetching from **UPSTREAM**
+- Writing modifications and push them to a fork (e.g. **PUBLISH**)
+- Opening a pull request
+- If the maintainer accepts the changes, he merges them into the
+ **UPSTREAM** repository.
+
+
+
+-- -
+| UPSTREAM | maintainer | PUBLISH |
+| git/git |- - - - - - - -| me/remote|
+-- ← -
+ \ /
+ \ /
+ fetch↓\ /↑push
+ \ /
+ \ /
+ -
+ | LOCAL |
+ -
+
+
+Motivations
+~~~
+
+* Allows contributors to work with Git even though they do not have
+write access to **UPSTREAM**.
+
+* Allows maintainers to receive code from contributors they may not
+trust.
+
+* Code review is more efficient
+
+* Encourages clean history by using `rebase -i` and `push --force` to
+your public fork before the code is merged
+
+Preparation
+~~~
+
+Cloning from **PUBLISH**, which is a fork of **UPSTREAM** or an empty
+repository.
+
+==
+`git clone `
+==
+
+Setting the behavior of push for the triangular workflow:
+
+===
+`git config push.default current`
+===
+
+Adding **UPSTREAM** remote:
+
+===
+`git remote add upstream `
+===
+
+With the `remote add` above, using `git pull upstream` pulls there,
+instead of saying its URL. In addition, `git pull` can pull from
+**UPSTREAM** without argument.
+
+For each branch requiring a triangular workflow, set
+`branch..remote` and `branch..pushRemote`.
+
+Example with master as :
+===
+* `git config branch.master.remote upstream`
+* `git config branch.master.pushRemote origin`
+===
+
+Stay up-to-date
+~~~
+
+Retrieve updates from **UPSTREAM** with `git pull` and send them to
+**PUBLISH** with `git push`.
+
+Checks
+~~
+
+.Display the push remote's name:
+[caption="Recipe: "]
+
+=
+`git rev-parse --abbrev-ref @{push}`
+=
+
+The shorthand `@{push}` denotes the remote-tracking branch
+where the would be pushed to. If no is specified
+(`@{push}`), takes the value of the current branch.
+
+
+.Display the fetch remote's name:
+[caption="Recipe: "]
+
+===
+`git rev-parse --abbrev-ref @{upstream}`
+===
+
+The shorthand `@{upstream}` substitutes the upstream name of
+the branch. If no is specified (`@{upstream}`),
+takes the value of the current branch.
+
+.Display commits added to the current branch since last push:
+[caption="Recipe: "]
+
+===
+`git log @{push}..`
+===
+
+.Display commits added to a specific branch since last push:
+[caption="Recipe: "]
+
+
+`git log @{push}..`
+
+
+Alternative configuration
+~
+
+.Cloning from **UPSTREAM**
+[caption="Recipe: "]
+
+In the preparation above, a clone from **PUBLISH** was used. Starting
+with a clone of **UPSTREAM** is possible too.
+
+Cloning from **UPSTREAM**
+
+==
+`git clone `
+==
+
+Setting the behavior of push for the triangu
