Junio C Hamano wrote:
>
> > contrib/completion/git-completion.bash | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/contrib/completion/git-completion.bash
> > b/contrib/completion/git-completion.bash
> > index bfc74e9..3c00acd 100644
> > --- a/contrib/completion/git-completion.
Junio C Hamano wrote:
> Jordan DE GEA wrote:
>
> > +* 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.
Triangular workflow is the ability to accept changes f
For the list, in plain text:
IIUC, they use the date received to sort. I think this might stem from
a historical cruft: emails sometimes took non-trivial amounts of time
to transit, back in the old days. MUAs (especially web-based ones)
probably did not want to violate user expectation by placing
Jeff King wrote:
> - ideas ideas ideas
I'll throw in a few ideas from half-finished work.
1. Speed up git-rebase--am.sh
Currently, git-rebase--am.sh is really slow because it dumps each
patch to a file using git-format-patch, and picks it up to apply
subsequently using git-am. Find a way to sp
Jeff King wrote:
>> 1. Speed up git-rebase--am.sh
>
> Isn't the merge backend faster? I thought that was the point of it.
I suppose, but I thought git-rebase--am.sh (the default flavor) could
be improved by leveraging relatively new cherry-pick features; I
assumed that the reason it was using form
Junio C Hamano wrote:
> * jk/branch-at-publish-rebased (2014-01-17) 5 commits
> - t1507 (rev-parse-upstream): fix typo in test title
> - implement @{publish} shorthand
> - branch_get: provide per-branch pushremote pointers
> - branch_get: return early on error
> - sha1_name: refactor upstream_
Jeff King wrote:
> Thus, config like:
>
> [branch "master"]
> pushremote = foo
> [remote]
> pushdefault = bar
>
> erroneously ends up pushing to "bar" from the master branch.
Oh, ouch. Thanks for fixing this.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
Replace git-pull and git-merge with the corresponding un-hyphenated
versions. While at it, use ` to mark it up instead of '.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/merge-strategies.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/
Fix a few minor things.
Signed-off-by: Ramkumar Ramachandra
---
Philip,
I spotted a few obvious issues with your giteveryday patch in
pu. Maybe Junio can squash this into your patch? Contents are still a
bit stale, but I'm not sure what other markup problems are there.
Document
Philip Oakley wrote:
>> * po/everyday-doc (2014-01-27) 1 commit
>> - Make 'git help everyday' work
>>
>> This may make the said command to emit something, but the source is
>> not meant to be formatted into a manual pages to begin with, and
>> also its contents are a bit stale. It may be a good fi
Felipe Contreras wrote:
> @@ -1068,23 +1069,35 @@ static const char *get_upstream_branch(const char
> *name_buf, int len)
> */
> if (!branch)
> die(_("HEAD does not point to a branch"));
> - if (!branch->merge || !branch->merge[0]->dst) {
> - if
Felipe Contreras wrote:
> It's more efficient to check for the braces first.
Why is it more efficient? So you can error out quickly in the case of
a malformed string? I'm personally not thrilled about this change.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a m
Felipe Contreras wrote:
> sha1_name.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
I like this variable rename. This instance has annoyed me in the past.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v
Felipe Contreras wrote:
> diff --git a/sha1_name.c b/sha1_name.c
> index aa3f3e0..a36852d 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -415,9 +415,9 @@ static int ambiguous_path(const char *path, int len)
> return slash;
> }
>
> -static inline int upstream_mark(const char *string, i
Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras
Please write a commit message, preferably showing the new git-branch output.
I noticed that this only picks up a publish-branch if
branch.*.pushremote is configured. What happened to the case when
remote.pushdefault is configured?
--
To u
Felipe Contreras wrote:
> @@ -635,9 +637,10 @@ static int do_pick_commit(struct commit *commit, struct
> replay_opts *opts)
> }
>
> if (opts->skip_empty && is_index_unchanged() == 1) {
> - warning(_("skipping %s... %s"),
> - find_unique_abbrev(co
Felipe Contreras wrote:
> Akin to 'am --skip' and 'rebase --skip'.
I don't recall why my original sequencer series didn't include this
option. Perhaps Jonathan remembers?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More ma
Felipe Contreras wrote:
> So that we can load and store rewrites, as well as other operations on a
> list of rewritten commits.
Please elaborate. Explain why this code shouldn't go in sequencer.c.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord.
Felipe Contreras wrote:
> If no action-name is specified, nothing is done.
Why? Is it because git-rebase implements its own notes-copy-on-rewrite logic?
Otherwise, I agree with the goal of making notes.rewrite.
work for cherry-pick.
--
To unsubscribe from this list: send the line "unsubscribe git
Felipe Contreras wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 43631b4..fd085e1 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -248,7 +248,7 @@ pick_one () {
>
> test -d "$rewritten" &&
> pick_one_pre
, it missed this case in
git-rebase--interactive.sh. Since this case is unlike the other cases
which return control for housekeeping, assign it a special return status
and handle that return value explicitly in git-rebase.sh.
Reported-by: Karen Etheridge
Signed-off-by: Ramkumar Ramachandra
A couple of quick nits.
Tanay Abhra wrote:
> +test_expect_success 'clear default config' '
> + rm -f .git/config
> +'
Unnecessary; a fresh temporary directory is created for each test run.
> +test_expect_success 'initialize default config' '
You might want to mark this as "setup".
--
To u
Junio C Hamano wrote:
> $ git show -s --format='%CredAnd%CyellowAreNotTheSameColor'
Ouch, this is quite a disaster.
> It would have been much saner if we started from %(color:yellow),
> %(subject), etc., i.e. have a single long-hand magic introducer
> %(...), and added a set of often-used sh
Hi,
v2 uses the more sane %(color:...) as opposed to %C(...) for changing
the color of the output, as suggested by Junio. Everything else is the
same.
Thanks.
Ramkumar Ramachandra (3):
for-each-ref: introduce %(HEAD) asterisk marker
for-each-ref: introduce %(upstream:track[short])
for
terisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%(color:green)%(refname:short)%(color:reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c
ef:
%(refname:short)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with "upstream", and error
out when used with anything else.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/g
Jason St. John wrote:
> + Backticks are used around options or commands:
> + `--pretty=oneline`
> + `git rev-list`
You might want to include configuration variables like
`remote.pushdefault` here.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj
Junio C Hamano wrote:
> builtin/for-each-ref.c: In function 'populate_value':
> builtin/for-each-ref.c:701:13: error: 'refname' may be used uninitialized in
> this function [-Werror=uninitialized]
In my defense, the gcc on my end (4.8.2) doesn't seem to complain. Are
you using extra cflags?
Howe
Junio C Hamano wrote:
> Perhaps like this (obviously not tested as these three patches did
> not add any tests ;-)
Sorry about that. I didn't notice t6300-for-each-ref.sh. Will fix in
the next round.
> I also think that there should be a mechanism to do "color:reset"
> after each record is issued
o-reset color.
I haven't included Junio's 78465bb (fixup! for-each-ref: introduce
%(upstream:track[short]), 2013-10-31), because my compiler doesn't
complain, and because it's ugly.
Thanks.
Ramkumar Ramachandra (6):
t6300 (for-each-ref): clearly demarcate setup
t6300 (for-eac
ef:
%(refname:short)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with "upstream", and error
out when used with anything else.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/g
Condense the two-step setup into one step, and give it an appropriate
name.
Signed-off-by: Ramkumar Ramachandra
---
t/t6300-for-each-ref.sh | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 752f5cb..72d282f 100755
terisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
t/t6300-for-each-ref.sh| 2 ++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/Documen
Use rev-parse in its place, making it easier for future patches to
modify the test script.
Signed-off-by: Ramkumar Ramachandra
---
t/t6300-for-each-ref.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%(color:green)%(refname:short)%(color:reset)
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c
of the format string as well.
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 22 ++
t/t6300-for-each-ref.sh | 2 +-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 2ff4e54..1050aea 1006
Eric Sunshine wrote:
> The "prompt" is not mentioned elsewhere in for-each-ref documentation,
> and a person not familiar with contrib/completion/ may be confused by
> this reference. It might make sense instead to explain the meanings of
> ">", "<", "<>", and "=" directly since they are not necess
Junio C Hamano wrote:
> If you are saying, by after each token, that
>
> --format='%(color:blue)%(A)literal string%(B)'
>
> should result in
>
>"literal string" B>
>
> then I would disagree.
Hm, I didn't think it was a bad idea to reset after each token. The
whole point of hav
Hi,
The major change since v3 is in [6/6]: color no more auto-resets after
each token, but instead only to avoid leakage (thanks to Junio). Other
minor changes are in accordance with Eric Sunshine's review.
Thanks.
Ramkumar Ramachandra (6):
t6300 (for-each-ref): clearly demarcate
Condense the two-step setup into one step, and give it an appropriate
name.
Signed-off-by: Ramkumar Ramachandra
---
t/t6300-for-each-ref.sh | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index 752f5cb..64301e7 100755
To make sure that an invocation like the following doesn't leak color,
$ git for-each-ref --format='%(subject)%(color:green)'
auto-reset at the end of the format string when the last color token
seen in the format string isn't a color-reset.
Signed-off-by: Ramkumar Ramac
terisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
t/t6300-for-each-ref.sh| 2 ++
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/Documen
Use rev-parse in its place, making it easier for future patches to
modify the test script.
Signed-off-by: Ramkumar Ramachandra
---
t/t6300-for-each-ref.sh | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
index
Enhance 'git for-each-ref' with color formatting options. You can now
use the following format in for-each-ref:
%(color:green)%(refname:short)%(color:reset)
where color names are described in color.branch.*.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-re
ef:
%(refname:short)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with "upstream", and error
out when used with anything else.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/g
Junio C Hamano wrote:
>> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
>> index 2ff4e54..04e35ba 100644
>> --- a/builtin/for-each-ref.c
>> +++ b/builtin/for-each-ref.c
>> @@ -23,6 +23,7 @@ typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME }
>> cmp_type;
>> struct atom_value {
>>
Junio C Hamano wrote:
> My knee-jerk "adding it to struct refinfo" is not correct, either,
> because what we want to know, i.e. "do we need an extra reset?" is
> not a property for each ref. It is similar to "what is the set of
> atoms the format string is using?" and "do we need to peel tags in
>
[+CC: Jens, the goto-guy for submodules]
Sergey Sharybin wrote:
> Namely, `git ls-files -m` will show addons as modified, regardless
> ignore=all configuration. In the same time `git diff-index --name-only
> HEAD --` will show no changes at all.
This happens because diff-index handles submodules
Sergey Sharybin wrote:
> On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra
> wrote:
>>
>> [+CC: Jens, the goto-guy for submodules]
>>
>> Sergey Sharybin wrote:
>> > Namely, `git ls-files -m` will show addons as modified, regardless
>> > igno
Jeff King wrote:
>> I just checked it out: it uses `git ls-files -m` to get the list of
>> unstaged changes; `git diff --name-only HEAD --` will list staged
>> changes as well.
>
> That diff command compares the working tree and HEAD; if you are trying
> to match `ls-files -m`, you probably wanted
Sergey Sharybin wrote:
> Ramkumar, not actually sure what you mean?
>
> For me `git diff --name-only HEAD --` ignores changes to submodules
> hash changes.
`git diff --name-only HEAD --` compares the worktree to HEAD (listing
both staged and unstaged changes); we want `git diff --name-only --`
to
Sergey Sharybin wrote:
> To reproduce the issue:
>
> - Run git submodule update --recursive to make sure their SHA is
> changed. Then `git add /path/to/changed submodule` or just `git add .`
> - Modify any file from the parent repository
> - Neither of `git status`, `git diff` and `git diff-files -
Jens Lehmann wrote:
> But the question is if that is the right thing to do: should
> diff.ignoreSubmodules and submodule..ignore only affect
> the diff family or also git log & friends? That would make
> users blind for submodule history (which they already are
> when using diff & friends, so that
Heiko Voigt wrote:
> What I think needs fixing here first is that the ignore setting should not
> apply to any diffs between HEAD and index. IMO, it should only apply
> to the diff between worktree and index.
>
> When we have that the user does not see the submodule changed when
> normally working.
Jeff King wrote:
> I think it makes sense to be able to show it as part of "git branch",
> but the verbose branch listing there is a bit of a mess. Doing it
> cleanly would probably involve refactoring the branch-display code to
> allow users to specify more flexible formats.
Certainly. I'm quite
Thomas Rast wrote:
> When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection,
> passing its ->new all the options that would otherwise go to
> Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the
> SSL options).
>
> However, while Net::SMTP::SSL replaces the underlying socke
Matěj Cepl wrote:
> I am trying to git-svn clone
> https://svn.calendarserver.org/repository/calendarserver/CalendarServer/
> and I cannot say I am much succesful.
Consider using (the somewhat experimental) git-remote-testsvn and the
underlying contrib/svn-fe/. For starters, try:
$ git clone
t
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion
h the solution.
I hope it's an enjoyable read.
Ramkumar Ramachandra (4):
completion: prioritize ./git-completion.bash
completion: introduce __gitcomp_2 ()
completion: fix branch.autosetup(merge|rebase)
completion: fix remote.pushdefault
contrib/completion/git-completion
cilitate completions of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10
f branches using
__gitcomp_2 ().
Also take care to not complete
$ git config branch.autosetupmerge.
$ git config branch.autosetuprebase.
with the usual branch.. candidates.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 8 +++-
1 file changed, 7 insert
lso take care to not complete
$ git config remote.pushdefault.
with the usual remote.. candidates.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 6551e7b..51798b4 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -92,7 +92,7 @@ static
Junio C Hamano wrote:
> If we are looking at "branch.autosetupmerge." followed by something,
> who typed that final dot?
I admit that it's a very unlikely case. The user did:
$ branch.autosetupmer
hit backspace to delete the trailing space, inserted a dot, and hit again.
> If you are working
Junio C Hamano wrote:
> __gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
> __gitcomp_nl_append $"autosetupmerge\nautosetuprebase\n" "$pfx"
> "$cur_" " "
This is not a bad idea at all. I'm just afraid that we might be
leaving open ends: What happens if the $pfx isn't the same in bo
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion
e list of branches using
__gitcomp_2 ().
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 64b20b8..cbb4eca 100644
---
When attempting to complete
$ git config remote.push
'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' to the
list of remotes using __gitcomp_2 ().
Sign
cilitate completions of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10
Hi,
In this iteration, I've removed hunks to prevent completing:
$ git config remote.pushdefault.
$ git config branch.autosetupmerge.
$ git config branch.autosetuprebase.
Since they're perfectly valid remote/ branch names.
Thanks.
Ramkumar Ramachandra (4):
completion: priori
Junio C Hamano wrote:
> You seem to be calling it "incorrect" to give the same degree of
> completion for a branch the user named "autosetupmerge" as another
> branch "topic", but I think it is incorrect not to, so I cannot tell
> if we are agreeing or disagreeing.
No, what's incorrect is providin
Junio C Hamano wrote:
> I am not sure what you are worried about $pfx; what does it do when
> you have strings with different prefix in COMPREPLY? If it breaks,
> then the answer is "don't do it then".
>
> Doesn't an array know its own length and give you a way to ask?
Right. I was just throwing c
Hi Junio et al,
In v3, I've implemented __gitcomp_nl_append (), like you
suggested. After implementing it, I feel foolish about having gone
around my head to do __gitcomp_2 ().
Thanks.
Ramkumar Ramachandra (4):
completion: prioritize ./git-completion.bash
completion: intr
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion
quot;. To facilitate completions of this kind, create a
variation of __gitcomp_nl () that appends to the existing list of
completion candidates, COMPREPLY.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 13 +
contrib/completion/git-completion.zsh | 8 +
When attempting to complete
$ git config remote.push
'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' to the
list of remotes using __gitcomp_nl_append ().
Sign
tuprebase' to the list of
branches using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bf358d6..75c7302
Junio C Hamano wrote:
> Is it because going this route and doing it at such a low level
> would make zsh completion (which I have no clue about ;-)
> unnecessarily complex?
The zsh completion only cares to override __gitcomp_nl () and
__gitcomp_nl_append (), without bothering to re-implement the
l
brian m. carlson wrote:
> I'm not clear on this change. It looks like this loads
> git-completion.bash from the same directory as git-completion.zsh. Is
> this correct?
Yes, and that's what I meant to convey with the "./". Junio's message
is clearer though, so I'll use that.
Thanks.
--
To unsub
Hi Junio et al,
Most significantly, [2/4] no longer duplicates __gitcompadd () in
__gitcomp_nl_append (). Other than that, the commit messages for the
other patches are improved.
Thanks.
Ramkumar Ramachandra (4):
zsh completion: find matching custom bash completion
completion: introduce
#x27; as candidates for
completion too, using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 20febff..
When attempting to complete
$ git config remote.push
'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' as a
candidate for completion too, using __gitcomp_nl_ap
quot;. To facilitate completions of this kind, create a
variation of __gitcomp_nl () that appends to the existing list of
completion candidates, COMPREPLY.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 22 ++
contrib/completion/git-completion.z
directory than in those system default places.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index fac5e71..6fca145
Hi,
This is inspired by merge.defaultToUpstream. Disclaimer: I have an
"fpm" alias for doing this (separate from "fp" for when I need to
generate patches against some other branch), which I'd like to get rid
of.
Thanks.
Ramkumar Ramachandra (2):
completion: co
ter' explicitly everytime. Save the user the extra keystrokes by
introducing format.defaultTo which can contain the name of a branch
against which to base patches.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt | 4
builtin/log.c |
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..39b81f7 100644
--- a/contrib/completion/git-completion.bash
+++ b
Ramkumar Ramachandra wrote:
> Ramkumar Ramachandra (2):
> completion: complete format.coverLetter
> format-patch: introduce format.defaultTo
Any thoughts on checkout.defaultTo? I have a "com" alias to checkout 'master'.
--
To unsubscribe from this list: send the
Hi,
On the latest git, I noticed that a rebase --onto doesn't abort
properly. Steps to reproduce:
# on some topic branch
$ git rebase --onto master @~10
^C # quickly!
$ git rebase --abort
# HEAD is still detached
I tried going back a few revisions, and the bug seems to be very old;
I'm
Junio C Hamano wrote:
> - why is a single branch name sufficient?
It does accept a , so any form is allowed; but why would
anyone want that in a format.defaultTo? I'm not sure we want to impose
an artificial restriction on the configuration variable though.
> - is it a better option to simply d
Junio C Hamano wrote:
> I do not think --abort was designed to abort an uncontrolled stop
> like ^C in the first place.
Why not? All it requires is a reset --hard to
.git/rebase-apply/head-name, as usual, no?
> To allow that kind of "recovery", you
> need to teach "rebase" to first record the sta
Jonathan Nieder wrote:
> 1. Most config settings are in noun form: e.g.,
> "[remote] pushDefault = foo". That makes their names easy to guess
> and makes them easy to talk about: I set the default remote for
> pushing by changing the remote.pushdefault setting.
>
> '[url ""] inste
Junio C Hamano wrote:
> I meant "a single branch" as opposed to "depending on what branch
> you are sending out, you may have to use a different upstream
> starting point", and a single "format.defaultTo" that does not read
> what your HEAD currently points at may not be enough.
>
> Unless you set
Jeff King wrote:
> Yeah, I had similar thoughts. I personally use "branch.*.merge" as
> "forkedFrom", and it seems like we are going that way anyway with things
> like "git rebase" and "git merge" defaulting to upstream.
My issue with that is that I no idea where my branch is with respect
to my fo
Junio C Hamano wrote:.
> As I said in the different subthread, I am not convinced that you
> would need the complexity of branch.*.forkedFrom. If you set your
> "upstream" to the true upstream (not your publishing point), and
> have "remote.pushdefault"set to 'publish', you can expect
>
>
John Szakmeister wrote:
> Then where does it get pushed? Do you always specify where to save your work?
>
> FWIW, I think the idea of treating @{u} as the eventual recipient of
> your changes is good, but then it seems like Git is lacking the
> "publish my changes to this other branch" concept.
>
Ramkumar Ramachandra wrote:
> contrib/completion/git-completion.bash | 1 +
> 1 file changed, 1 insertion(+)
Junio: Please push this part via 'maint' independently.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majo
John Szakmeister wrote:
> I guess it's not a good idea to
> set 'push.default' to 'upstream' in this triangle workflow then,
> otherwise the branch name being pushed to will be 'branch.*.merge'.
> Is that correct? I just want to make sure I understand what's
> happening here.
push.default = upstr
uild
functionality around this new configuration variable.
Cc: Jeff King
Cc: Junio C Hamano
Signed-off-by: Ramkumar Ramachandra
---
Since -M, -C, -D are left in the argc, checking argc < 2 isn't
sufficient.
I wanted to get an early reaction before wiring up checkout and
rebase.
Bu
1 - 100 of 1623 matches
Mail list logo
