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
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
lement 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 majordo
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 r
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
>> +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 ne
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
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:
>
>> 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 th
> 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
> clo
-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
> 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 th
> From: "Jordan DE GEA"
>> This document attempts to help you configure a Triangular Workflow.
>> +Here is an example of configuration:
>> +
>> +
>> + ---
>> +| UPSTREAM |
>> 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 yo
> 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 fr
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
> 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-sharin
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
> 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.
>
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
unsubscribe alsa-devel
21 matches
Mail list logo
