is needed to just get the
branch name.
Signed-off-by: Daniels Umanovskis
---
Submitting v5 now that a week has passed since latest maintainer
comments.
This is basically v4 but with small fixes to the test, as proposed
by Junio on pu, and additionally replacing a subshell
with { .. } since Dscho
On 10/17/18 11:39 AM, Rafael Ascensão wrote:
> On Fri, Oct 12, 2018 at 03:33:21PM +0200, Daniels Umanovskis wrote:
>> Intended both for scripting and interactive/informative use.
>> Unlike git branch --list, no filtering is needed to just get the
>> branch name.
>
is needed to just get the
branch name.
Signed-off-by: Daniels Umanovskis
---
Compared to v3, fixed up test cases according to Junio's input
Documentation/git-branch.txt | 6 +-
builtin/branch.c | 25 +++--
t/t3203-branch-output.sh | 43
On 10/12/18 1:15 AM, Junio C Hamano wrote:
> It is a bit curious why you remove the branch but not the tag after
> this test. [..]
>
> So two equally valid choices are to remove "branch -d" and then
> either:
>
> (1) leave both branch and tag after this test in the test
> repository
>
>
On 10/12/18 12:56 AM, SZEDER Gábor wrote:
> Ah, OK, just noticed v3 which has already fixed this.
>
Yeah - squashed the wrong commits locally for v2. Thanks for pointing
this out anyway!
is needed to just get the
branch name.
Signed-off-by: Daniels Umanovskis
---
Cleaned up per suggestions, explicitly passing flags to clearly
denote intent. If you consider the patch good conceptually, this
implementation should hopefully be good enough to include.
Documentation/git-branch.txt | 6
On 10/11/18 10:35 PM, Rafael Ascensão wrote:
> The output of the proposed command is also a bit inconsistent with the
> usual output given by git branch, specifically the space alignment on
> the left, color and * marker.
The proposed command therefore takes a new switch. It's definitely not
This is definitely a low-level command, it's hard to argue
against it belonging in plumbing.
Signed-off-by: Daniels Umanovskis
---
command-list.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/command-list.txt b/command-list.txt
index c36ea3c18..966705358 100644
Also remove git-cherry from Bash completion because plumbing
commands do not belong there.
Signed-off-by: Daniels Umanovskis
---
Up to discussion whether cherry should be considered plumbing.
I lean towards considering it a rarely-used porcelain command, but
a case could be made either way so
On 10/11/18 8:54 AM, Junio C Hamano wrote:
> Is it a normal situation to have refname==NULL, or is it something
> worth reporting as an error?
Looks like that would be in the case of looping symrefs or file backend
failure, so seems a good idea to die() in that case.
> Without passing the
On 10/11/18 5:43 PM, Rafael Ascensão wrote:
> I agree it feels a bit out of place, and still think that
>
> $ git branch --list HEAD
>
> would be a good candidate to be taught how to print the current branch.
I am not a fan because it would be yet another inconsistency in the Git
command
On 10/11/18 12:26 AM, Junio C Hamano wrote:
> Among the remaining ones in the list, cherry and get-tar-commit-id
> are probably better classified as plumbing. I do not know why
> cherry is marked for completion; perhaps some crazy people use that
> on the command line?
I think cherry could go
-off-by: Daniels Umanovskis
---
command-list.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/command-list.txt b/command-list.txt
index c36ea3c18..e6364e167 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -153,7 +153,7 @@ git-rerere
is needed to just get the
branch name.
Signed-off-by: Daniels Umanovskis
---
Documentation/git-branch.txt | 6 +-
builtin/branch.c | 21 --
t/t3203-branch-output.sh | 41
3 files changed, 65 insertions(+), 3 deletions(-)
diff
. Is it accepted practice to
also include po edits in my patch in such a case, or should that be
left to the regular l10n workflow?
Daniels Umanovskis (1):
branch: introduce --show-current display option
Documentation/git-branch.txt | 6 +-
builtin/branch.c | 21 --
t/t3203
On 10/10/18 5:03 PM, Ævar Arnfjörð Bjarmason wrote:
>
> I'm mildly negative on this because git-rev-parse is plumbing, but
> git-branch is porcelain [..]
>
> We also list git-rev-parse as porcelain, just under "Porcelain / Ancillary
> Commands / Interrogators".
>
> Should we just move it to
Thanks for the feedback!
On 10/9/18 9:54 PM, Stefan Beller wrote:
> How does it play with worktrees? (I would expect it to just work as expected:
> each worktree would print its current branch, but a test might help?)
I'll see about writing a test for that. I've never used git-worktree so
this
Signed-off-by: Daniels Umanovskis
---
Documentation/git-branch.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index bf5316ffa..a7167df74 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git
with an asterisk, meaning sed or other
filtering is necessary to just get the current branch.
git rev-parse --abbrev-ref HEAD is the current way to achieve this
output, but that is not intuitive or easy to understand.
Signed-off-by: Daniels Umanovskis
---
builtin/branch.c | 17
welcome.
Daniels Umanovskis (2):
branch: introduce --current display option
doc/git-branch: Document the --current option
Documentation/git-branch.txt | 6 +-
builtin/branch.c | 16
t/t3203-branch-output.sh | 18 ++
3 files changed, 39
20 matches
Mail list logo
