Re: [PATCH] send-email: new option to walkaround email server limits
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 a new email under several already-read emails. I would argue that this was reasonable behavior. Further, since email is near-instantaneous today, it really makes no difference which way the MUA sorts. Except for git send-email. It might be acceptable to put in a "practical hack" to help out MUAs in the context of "near instant forwarding". I would argue against it on grounds of it being an ugly hack, for very little benefit. The patch that began this thread is also ugly, but has the important consequence of enabling some people to use git send-email at all. p.s- We should probably allow emails from mobile devices on the list. It usually contains a HTML subpart.
Re: [PATCHv4] Documentation: triangular workflow
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 from contributors without mailing patches back-and-forth. Whether they send a pull request or commit directly to the master repository when review is done, is inconsequential. Essentially, they maintain forks of upstream, which they work on at their own pace. > > +* Code review is more efficient > > I have no idea what data you have to back this claim up. More > efficient compared to what? They're orthogonal. LLVM has one giant SVN server that everyone commits directly to. However, they review process is a lot more efficient than GitHub projects, because they use Phabricator. What does code review tool have to do with triangular workflow? > > +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` > > +=== It's much too simple now. Just `git clone `, `git remote add mine `, and `git config remote.pushdefault mine`. Only the last line requires an explanation. > Instead you would set default.pushRemote to publish > just once, and no matter how many branches you create later, you do > not have to do anything special. I think you meant remote.pushdefault here? -- 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] completion: suggest sequencer commands for revert
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.bash
+++ b/contrib/completion/git-completion.bash
@@ -2282,6 +2282,11 @@ _git_reset ()
_git_revert ()
{
+ local dir=$(__gitdir)
+ if [ -f $dir/REVERT_HEAD ]; then
+ __gitcomp --continue --quit --abort
+ return
+ fi
case $cur in
--*)
__gitcomp --edit --mainline --no-edit --no-commit --signoff
This corresponds exactly to what we do for git-cherry-pick:
local dir=$(__gitdir)
if [ -f $dir/CHERRY_PICK_HEAD ]; then
__gitcomp --continue --quit --abort
return
fi
Perhaps _git_revert() and _git_cherry_pick() should call into the same
function with different arguments.
This looks fine though.
--
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: [PULL] git-svn updates from Ramkumar
Eric Wong wrote: Adding it to GITPERLLIB should work... I tried everything including replicating the commands in the brew formula that does the Right thing: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/git.rb I'm clearly missing something. Can someone on Darwin tell us the right flags/ env variables? -- 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] .clang-format: introduce the use of clang-format
René Scharfe wrote: However, even then struct declarations that are combined with variable declaration and initialization get mangled: I'm pretty sure this is a bug in clang-format. It might be semi-trivial to fix too. Thanks for your inputs. -- 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] .clang-format: introduce the use of clang-format
Instead of manually eyeballing style in reviews, just ask all
contributors to run their patches through [git-]clang-format.
However, struct declarations that are combined with variable
declaration and initialization get mangled:
struct a {
int n;
const char *s;
} arr[] = {
{ 1, one },
{ 2, two }
};
becomes:
struct a {
int n;
const char *s;
} arr[] = { { 1, one }, { 2, two } };
It gets formatted better if arr is declared separately.
Helped-by: René Scharfe l@web.de
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
.clang-format | 11 +++
1 file changed, 11 insertions(+)
create mode 100644 .clang-format
diff --git a/.clang-format b/.clang-format
new file mode 100644
index 000..a336438
--- /dev/null
+++ b/.clang-format
@@ -0,0 +1,11 @@
+BasedOnStyle: LLVM
+IndentWidth: 8
+UseTab: Always
+BreakBeforeBraces: Linux
+AllowShortBlocksOnASingleLine: false
+AllowShortIfStatementsOnASingleLine: false
+IndentCaseLabels: false
+AllowShortFunctionsOnASingleLine: None
+ContinuationIndentWidth: 8
+Cpp11BracedListStyle: false
+BreakBeforeBraces: Stroustrup
--
2.2.1
--
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 v2] contacts: introduce --since and --min-percent
Ramkumar Ramachandra wrote: Signed-off-by: Ramkumar Ramachandra artag...@gmail.com Junio: this isn't in the latest rebuild of pu; I wonder if you've forgotten to pick it up. -- 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 v2] .clang-format: introduce the use of clang-format
Jeff King wrote:
On Wed, Jan 21, 2015 at 12:01:27PM -0500, Ramkumar Ramachandra wrote:
+BreakBeforeBraces: Linux
[...]
+BreakBeforeBraces: Stroustrup
Oh, oops.
- It really wants to break function declarations that go over the
column limit, even though we often do not do so. I think we're pretty
inconsistent here, and I'd be fine going either way with it.
- It really wanted to left-align some of my asterisks, like:
struct foo_list {
...
} * foo, **foo_tail;
The odd thing is that it gets the second one right, but not the first
one (which should be *foo with no space). Setting:
DerivePointerAlignment: false
PointerAlignment: Right
cleared it up, but I'm curious why the auto-deriver didn't work.
Sounds like a bug.
- It really doesn't like list-alignment, like:
#define FOO1
#define LONGER 2
and would prefer only a single space between FOO and 1. I think
I'm OK with that, but we have a lot of aligned bits in the existing
code.
- It really wants to put function __attribute__ macros on the same line
as the function. We often have it on a line above (especially it can
be so long). I couldn't find a way to specify this.
You have to compromise a bit if you want to use an auto-formatting
tool, without losing your head patching every little detail :)
- I had a long ternary operator broken across three lines, like:
foo = bar ?
some_long_thing(...) :
some_other_long_thing(...);
It put it all on one long line, which was much less readable. I set
BreakBeforeTernaryOperators to true, but it did nothing. I set it
to false, and then it broke. Which seems like a bug. It also
insisted on indenting it like:
foo = bar ?
some_long_thing(...) :
some_other_long_thing(...);
which I found less readable.
To be honest, the LLVM community doesn't fix bugs just because they
can be fixed: it's quite heavily driven by commercial interest. And I
really don't find long ternary operators in a modern C++ codebase.
I'm slightly dubious that
any automated formatter can ever be _perfect_ (sometimes
human-subjective readability trumps a hard-and-fast rule), but this
seems like it might have some promise.
It works almost perfectly for the LLVM umbrella of projects. When they
want to change a coding convention (like leading Uppercase for
variable names), they write a clang-tidy thing to do it automatically.
So overall I think it has some promise, but I do not think it is quite
flexible enough yet for us to use day-to-day.
The big negative is that it will probably never be. I'll try to look
at the larger issues later this week, if you can compromise on the
fine details that are probably too hard to fix.
2. It can operate on patches (and generates patches for you to apply!
You could add a git-add--interactive mode to selectively take its
suggestions).
There's a git-clang-format in the $CLANG_ROOT/tools/clang-format/. I do:
$ g cf @~
... with the appropriate aliases.
--
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] .clang-format: introduce the use of clang-format
Instead of manually eyeballing style in reviews, just ask all contributors to run their patches through [git-]clang-format. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- The idea is to introduce the community to this new toy I found called clang-format. Whether or not it's actually going to be used doesn't bother me too much. I'm not 100% sure of the style, but I'll leave you to tweak that using http://clang.llvm.org/docs/ClangFormatStyleOptions.html The current code isn't terribly conformant, but I suppose that'll change with time. .clang-format | 7 +++ 1 file changed, 7 insertions(+) create mode 100644 .clang-format diff --git a/.clang-format b/.clang-format new file mode 100644 index 000..63a53e0 --- /dev/null +++ b/.clang-format @@ -0,0 +1,7 @@ +BasedOnStyle: LLVM +IndentWidth: 8 +UseTab: Always +BreakBeforeBraces: Linux +AllowShortBlocksOnASingleLine: false +AllowShortIfStatementsOnASingleLine: false +IndentCaseLabels: false \ No newline at end of file -- 2.2.1 -- 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] contacts: introduce --since and --min-percent
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/contacts/git-contacts | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index dbe2abf..b06f2e1 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -8,12 +8,16 @@
use strict;
use warnings;
use IPC::Open2;
+use Getopt::Long qw/:config gnu_getopt no_ignore_case auto_abbrev/;
my $since = '5-years-ago';
my $min_percent = 10;
my $labels_rx = qr/Signed-off-by|Reviewed-by|Acked-by|Cc/i;
my %seen;
+my $rv = GetOptions('since=s' = \$since, 'min-percent=i' = \$min_percent);
+exit 1 if (!$rv);
+
sub format_contact {
my ($name, $email) = @_;
return $name $email;
--
2.2.1
--
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] contacts: introduce --since and --min-percent
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/contacts/git-contacts | 4
contrib/contacts/git-contacts.txt | 16
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index dbe2abf..5dde920 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -8,6 +8,7 @@
use strict;
use warnings;
use IPC::Open2;
+use Getopt::Long qw(:config gnu_getopt no_ignore_case auto_abbrev);
my $since = '5-years-ago';
my $min_percent = 10;
@@ -158,6 +159,9 @@ sub mailmap_contacts {
return \%mapped;
}
+my $rv = GetOptions('since=s' = \$since, 'min-percent=i' = \$min_percent);
+exit 1 if (!$rv);
+
if (!@ARGV) {
die No input revisions or patch files\n;
}
diff --git a/contrib/contacts/git-contacts.txt
b/contrib/contacts/git-contacts.txt
index dd914d1..a50c97f 100644
--- a/contrib/contacts/git-contacts.txt
+++ b/contrib/contacts/git-contacts.txt
@@ -31,6 +31,16 @@ discuss proposed changes, or for finding the list of
recipients to Cc: when
submitting a patch series via `git send-email`. For the latter case, `git
contacts` can be used as the argument to `git send-email`'s `--cc-cmd` option.
+OPTIONS
+---
+
+--min-percent::
+ The minimum threshold of blame percentage that a person must
+ exceed in order to be reported.
+
+--since::
+Depth of history to dig.
+
DISCUSSION
--
@@ -83,10 +93,8 @@ $ git send-email --cc-cmd='git contacts' feature/*.patch
LIMITATIONS
---
-Several conditions controlling a person's significance are currently
-hard-coded, such as minimum participation level (10%), blame date-limiting (5
-years), and `-C` level for detecting moved and copied lines (a single `-C`). In
-the future, these conditions may become configurable.
+The `-C` level for detecting moved and copied lines (a single `-C`) is
+hard-coded. In the future, this may become configurable.
GIT
--
2.2.1
--
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: [PULL] git-svn updates from Ramkumar
Junio C Hamano wrote: To which a natural reaction was Can the existing breakage demonstrated by a test?. There's a lot to do, if we really want to dig deeper. The second git-svn-basic test onwards doesn't pass for me, so I really can't do much in the way of contributing tests until that's fixed. Couldn't open a repository: Unable to connect to a repository at URL 'file:///Users/artagnon/src/git/t/trash%20directory.t9100-git-svn-basic/svnrepo': Unable to open an ra_local session to URL: Unable to open repository 'file:///Users/artagnon/src/git/t/trash%20directory.t9100-git-svn-basic/svnrepo': Expected FS format between '1' and '4'; found format '6' at /Users/artagnon/src/git/perl/blib/lib/Git/SVN.pm line 148. -- 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: [PULL] git-svn updates from Ramkumar
Eric Wong wrote: I haven't seen this before. Which SVN Perl binding version are you using? Perhaps your svnadmin tool is from a different SVN version or installation of SVN than your Perl bindings? I have two installations of Subversion: the system one is at /Library/Developer/CommandLineTools @ version 1.7.17, and the brew installed one is at /usr/local @ version 1.8.10. When I build git from scratch, it links to the dated SVN bindings for some reason. I suspect I have to tweak $PERL5LIB? Can we patch git-svn to link to the Right one on OS X? -- 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] git-svn: show progress in working_head_info()
Eric, I'm sorry, but this change isn't important enough for me to follow up. Please merge the other two patches, if you think they're good. Thanks. -- 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] git-svn: make it play nicely with submodules
It's a simple matter of opening the directory specified in the gitfile.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-svn.perl | 4
1 file changed, 4 insertions(+)
diff --git a/git-svn.perl b/git-svn.perl
index 6aa156c..8642783 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -337,6 +337,10 @@ for (my $i = 0; $i @ARGV; $i++) {
# make sure we're always running at the top-level working directory
if ($cmd $cmd =~ /(?:clone|init|multi-init)$/) {
$ENV{GIT_DIR} ||= .git;
+ # catch the submodule case
+ if (open(my $fh, '', $ENV{GIT_DIR})) {
+ $ENV{GIT_DIR} = $1 if $fh =~ /^gitdir: (.+)$/;
+ }
} else {
my ($git_dir, $cdup);
git_cmd_try {
--
2.2.1
--
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] Git::SVN: handle missing ref_id case correctly
Ramkumar Ramachandra wrote:
-our $default_ref_id = $ENV{GIT_SVN_ID} || 'git-svn';
+our $default_ref_id = defined $ENV{GIT_SVN_ID} ? $ENV{GIT_SVN_ID} :
'git-svn';
This is probably not a functional change; please look at the second hunk.
--
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] git-svn: show progress in working_head_info()
The working_head_info routine takes a very long time to execute on large
repositories. The least we can do is to comfort users that some progress
is being made.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
I was worried because of the long wait, so I wrote this to convince
myself that git-svn wasn't stuck.
git-svn.perl | 3 +++
1 file changed, 3 insertions(+)
diff --git a/git-svn.perl b/git-svn.perl
index 60f8814..6aa156c 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2022,6 +2022,9 @@ sub working_head_info {
next;
}
next unless s{^\s*(git-svn-id:)}{$1};
+ my $chomped = $_;
+ chomp $chomped;
+ print [Importing] $chomped\n;
my ($url, $rev, $uuid) = extract_metadata($_);
if (defined $url defined $rev) {
next if $max{$url} and $max{$url} $rev;
--
2.2.1
--
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] Git::SVN: handle missing ref_id case correctly
$ENV{GIT_SVN_ID} will return a string, so check it with defined. Also,
ref_id should not match refs/remotes/.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
perl/Git/SVN.pm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index d9a52a5..06ff216 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -40,7 +40,7 @@ BEGIN {
our $_follow_parent = 1;
our $_minimize_url = 'unset';
our $default_repo_id = 'svn';
-our $default_ref_id = $ENV{GIT_SVN_ID} || 'git-svn';
+our $default_ref_id = defined $ENV{GIT_SVN_ID} ? $ENV{GIT_SVN_ID} : 'git-svn';
my ($_gc_nr, $_gc_period);
@@ -2365,7 +2365,7 @@ sub _new {
# Older repos imported by us used $GIT_DIR/svn/foo instead of
# $GIT_DIR/svn/refs/remotes/foo when tracking refs/remotes/foo
- if ($ref_id =~ m{^refs/remotes/(.*)}) {
+ if ($ref_id =~ m{^refs/remotes/(.+)}) {
my $old_dir = $ENV{GIT_DIR}/svn/$1;
if (-d $old_dir ! -d $dir) {
$dir = $old_dir;
--
2.2.1
--
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] git-svn: make it play nicely with submodules
Eric Wong wrote: How portable is open on a directory? Perhaps it'd be better to check if it's a file, first: Sure, that works; feel free to fix it up locally before committing. -- 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] Git::SVN: handle missing ref_id case correctly
Ramkumar Ramachandra wrote: It is functional, maybe someone will use GIT_SVN_ID=0 ? Right. Kindly drop the first hunk. Amendment: there are actually many other places where variables are checked without defined, so I doubt we want to put up with the extra ugliness to allow 0. -- 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] Git::SVN: handle missing ref_id case correctly
Eric Wong wrote: It is functional, maybe someone will use GIT_SVN_ID=0 ? Right. Kindly drop the first hunk. -- 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 v5 2/2] test-config: Add tests for the config_set API
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 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] rebase -i: handle Nothing to do case with autostash
When a user invokes
$ git rebase -i @~3
with dirty files and rebase.autostash turned on, and exits the $EDITOR
with an empty buffer, the autostash fails to apply. Although the primary
focus of rr/rebase-autostash was to get the git-rebase--backend.sh
scripts to return control to git-rebase.sh, 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 et...@cpan.org
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Thanks to Karen for reporting this.
I chose 2 arbitrarily. Let me know if you have a rationale for other
return values.
git-rebase--interactive.sh | 4 ++--
git-rebase.sh | 11 ++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 6ec9d3c..f267d8b 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1049,14 +1049,14 @@ fi
has_action $todo ||
- die_abort Nothing to do
+ return 2
cp $todo $todo.backup
git_sequence_editor $todo ||
die_abort Could not execute editor
has_action $todo ||
- die_abort Nothing to do
+ return 2
expand_todo_ids
diff --git a/git-rebase.sh b/git-rebase.sh
index 4543815..47ca3b9 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -155,7 +155,7 @@ move_to_original_branch () {
esac
}
-finish_rebase () {
+apply_autostash () {
if test -f $state_dir/autostash
then
stash_sha1=$(cat $state_dir/autostash)
@@ -171,6 +171,10 @@ You can run git stash pop or git stash drop at any
time.
'
fi
fi
+}
+
+finish_rebase () {
+ apply_autostash
git gc --auto
rm -rf $state_dir
}
@@ -186,6 +190,11 @@ run_specific_rebase () {
if test $ret -eq 0
then
finish_rebase
+ elif test $ret -eq 2 # special exit status for rebase -i
+ then
+ apply_autostash
+ rm -rf $state_dir
+ die Nothing to do
fi
exit $ret
}
--
2.0.0.rc2.20.gfc2568d.dirty
--
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 v7 03/12] revert/cherry-pick: add --quiet option
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(commit-object.sha1,
DEFAULT_ABBREV),
- msg.subject);
+ if (!opts-quiet)
+ warning(_(skipping %s... %s),
+ find_unique_abbrev(commit-object.sha1,
DEFAULT_ABBREV),
+ msg.subject);
Personally, I don't see much value in inventing a new option for
suppressing one message.
--
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 v7 04/12] revert/cherry-pick: add --skip option
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 majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 06/12] builtin: add rewrite helper
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...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 12/12] cherry-pick: copy notes and run hooks
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.command work for cherry-pick. -- 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 v7 12/12] cherry-pick: copy notes and run hooks
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_preserving_merges $@ return
- output eval git cherry-pick $strategy_args $empty_args $ff $@
+ output eval git cherry-pick --action-name '' $strategy_args
$empty_args $ff $@
Passing an empty action-name looks quite ugly. Is there a better way
to achieve this?
--
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 v2 9/9] sha1_name: add support for @{publish} marks
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 (!ref_exists(branch-refname))
- die(_(No such branch: '%s'), name);
- if (!branch-merge) {
- die(_(No upstream configured for branch '%s'),
- branch-name);
+ switch (type) {
+ case 'u':
+ if (!branch-merge || !branch-merge[0]-dst) {
+ if (!ref_exists(branch-refname))
+ die(_(No such branch: '%s'), name);
+ if (!branch-merge) {
+ die(_(No upstream configured for branch
'%s'),
+ branch-name);
+ }
+ die(
+ _(Upstream branch '%s' not stored as a
remote-tracking branch),
+ branch-merge[0]-src);
+ }
+ tracking = branch-merge[0]-dst;
+ break;
+ case 'p':
+ if (!branch-push.dst) {
+ die(_(No publish configured for branch '%s'),
+ branch-name);
This assumes a push.default value of 'current' or 'matching'. What
happens if push.default is set to 'nothing' or 'upstream', for
instance?
p.s- Good to see you back on the list :)
--
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 v2 8/9] sha1_name: simplify track finding
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 message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 7/9] sha1_name: cleanup interpret_branch_name()
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...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 9/9] sha1_name: add support for @{publish} marks
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, int len)
+static inline int tracking_mark(const char *string, int len)
{
- const char *suffix[] = { upstream, u };
+ const char *suffix[] = { upstream, u, publish, p };
Oh, another thing: on some threads, people decided that @{push}
would be a more apt name (+ alias @{u} to @{pull} for symmetry).
--
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 v2 6/9] branch: display publish branch
Felipe Contreras wrote: Signed-off-by: Felipe Contreras felipe.contre...@gmail.com 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 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] Documentation/merge-strategies: avoid hyphenated commands
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 artag...@gmail.com
---
Documentation/merge-strategies.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/merge-strategies.txt
b/Documentation/merge-strategies.txt
index 12133b9..19f3a5d 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -1,10 +1,10 @@
MERGE STRATEGIES
-The merge mechanism ('git-merge' and 'git-pull' commands) allows the
+The merge mechanism (`git merge` and `git pull` commands) allows the
backend 'merge strategies' to be chosen with `-s` option. Some strategies
can also take their own options, which can be passed by giving `-Xoption`
-arguments to 'git-merge' and/or 'git-pull'.
+arguments to `git merge` and/or `git pull`.
resolve::
This can only resolve two heads (i.e. the current branch
--
1.9.0.431.g014438b
--
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 pu] Documentation/giteveryday: fix some obvious problems
Fix a few minor things. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- 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. Documentation/giteveryday.txt | 78 +-- 1 file changed, 38 insertions(+), 40 deletions(-) diff --git a/Documentation/giteveryday.txt b/Documentation/giteveryday.txt index 8dc298f..82ff8ec 100644 --- a/Documentation/giteveryday.txt +++ b/Documentation/giteveryday.txt @@ -35,8 +35,6 @@ following commands. * linkgit:git-init[1] to create a new repository. - * linkgit:git-show-branch[1] to see where you are. - * linkgit:git-log[1] to see what happened. * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch @@ -61,8 +59,8 @@ following commands. Examples -Use a tarball as a starting point for a new repository.:: -+ +Use a tarball as a starting point for a new repository: + $ tar zxf frotz.tar.gz $ cd frotz @@ -71,12 +69,12 @@ $ git add . 1 $ git commit -m import of frotz source tree. $ git tag v2.43 2 -+ + 1 add everything under the current directory. 2 make a lightweight, unannotated tag. -Create a topic branch and develop.:: -+ +Create a topic branch and develop: + $ git checkout -b alsa-audio 1 $ edit/compile/test @@ -95,7 +93,7 @@ $ git merge alsa-audio 10 $ git log --since='3 days ago' 11 $ git log v2.43.. curses/ 12 -+ + 1 create a new topic branch. 2 revert your botched changes in `curses/ux_audio_oss.c`. 3 you need to tell Git if you added a new file; removal and @@ -137,8 +135,8 @@ addition to the ones needed by a standalone developer. Examples -Clone the upstream and work on it. Feed changes to upstream.:: -+ +Clone the upstream and work on it. Feed changes to upstream: + $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6 @@ -151,7 +149,7 @@ $ git reset --hard ORIG_HEAD 6 $ git gc 7 $ git fetch --tags 8 -+ + 1 repeat as needed. 2 extract patches from your branch for e-mail submission. 3 `git pull` fetches from `origin` by default and merges into the @@ -166,8 +164,8 @@ area we are interested in. and store them under `.git/refs/tags/`. -Push into another repository.:: -+ +Push into another repository: + satellite$ git clone mothership:frotz frotz 1 satellite$ cd frotz @@ -185,7 +183,7 @@ mothership$ cd frotz mothership$ git checkout master mothership$ git merge satellite/master 5 -+ + 1 mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine. @@ -200,8 +198,8 @@ as a back-up method. 5 on mothership machine, merge the work done on the satellite machine into the master branch. -Branch off of a specific tag.:: -+ +Branch off of a specific tag: + $ git checkout -b private2.6.14 v2.6.14 1 $ edit/compile/test; git commit -a @@ -209,7 +207,7 @@ $ git checkout master $ git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k 2 -+ + 1 create a private branch based on a well known (but somewhat behind) tag. 2 forward port all changes in `private2.6.14` branch to `master` branch @@ -240,8 +238,8 @@ commands in addition to the ones needed by participants. Examples -My typical Git day.:: -+ +My typical Git day: + $ git status 1 $ git show-branch 2 @@ -261,10 +259,10 @@ $ git cherry-pick master~4 9 $ compile/test $ git tag -s -m GIT 0.99.9x v0.99.9x 10 $ git fetch ko git show-branch master maint 'tags/ko-*' 11 -$ git push ko 12 -$ git push ko v0.99.9x 13 +$ git push ko +$ git push ko v0.99.9x -+ + 1 see what I was in the middle of doing, if any. 2 see what topic branches I have and think about how ready they are. @@ -282,7 +280,7 @@ master, nor exposed as a part of a stable branch. 11 make sure I did not accidentally rewind master beyond what I already pushed out. `ko` shorthand points at the repository I have at kernel.org, and looks like this: -+ + $ cat .git/remotes/ko URL: kernel.org:/pub/scm/git/git.git @@ -294,7 +292,7 @@ Push: next Push: +pu Push: maint -+ + In the output from `git show-branch`, `master` should have everything `ko-master` has, and `next` should have everything `ko-next` has. @@ -322,24 +320,24 @@ example of managing a shared central repository. Examples We assume the following in /etc/services:: -+ + $ grep 9418 /etc/services git9418/tcp# Git Version Control System -Run git-daemon to serve /pub/scm from inetd.:: -+ +Run git-daemon to serve /pub/scm from inetd: + $ grep git /etc/inetd.conf gitstream tcp nowait nobody \ /usr/bin
Re: What's cooking in git.git (Mar 2014, #03; Fri, 14)
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 first step in
the right direction, but needs more work to at least get the
mark-up right before public consumption.
I'm not sure what elements you feel need adjustment. At the moment the
markup formats quite reasonably to my eyes, both as an HTML page and as a
man page.
I sent you a small patch fixing some minor markup issues.
That said, the (lack of) introduction could do with a paragraph to introduce
the guide. I have something in draft..
I had a thought that it may be worth a slight rearrangement to add a section
covering the setting up of one's remotes, depending whether it was forked,
corporate, or independent, but the lack of resolution on the next
{publish/push} topic makes such a re-write awkward at this stage. (Ram cc'd)
Before attempting to introduce remote.pushdefault and triangular
workflows, I'd first fix the main issue: stale content. I'm not sure
who uses git show-branch or mailx anymore, for instance.
--
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: What's cooking in git.git (Feb 2014, #06; Wed, 19)
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_mark
Give an easier access to the tracking branches from other side in
a triangular workflow by introducing B@{publish} that works in a
similar way to how B@{upstream} does.
Meant to be used as a basis for whatever Ram wants to build on.
Will hold.
Since I've decided that I don't have the time to work on this, we've
added this to the list of project ideas for GSoC 2014
(http://git.github.io/SoC-2014-Ideas.html). Hopefully, a student will
come along and volunteer to finish this.
--
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: Git GSoC 2014
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 format-patch/ am was because it
was written before cherry-pick matured. Alternatively, can you think
of a project that involves working on the sequencer?
3. Rewrite git-branch to use git-for-each-ref
I actually have this about 95% done, waiting for the patches to be
polished. So I don't think it makes a good GSoC project (it would be
stupid to start from scratch, and polishing my patches is a lame
project).
Oh. I look forward to using a nicer git-branch soon.
4. Implement @{publish}
I think this could be a good GSoC-sized topic. I'm going to adjust the
title to be better support for triangular workflows. I think they may
want to examine other issues in the area, rather than drilling down on
@{publish} in particular (but ultimately, it is up to the student to
propose what they want to do).
That makes the project a little more open-ended then. I like it.
I was hoping you'd have more comments on 3. Invent new conflict
style. Although I'm not sure the conflict style I proposed would be
terribly useful in the general case, it'll give the student an
opportunity to look at older/ lesser-known portions of the codebase.
--
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: Git GSoC 2014
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 speed this up, without
sacrificing safety. You can use the continuation features of
cherry-pick, and dump to file only to persist state in the case of a
failure.
Language: Shell script, C
Difficulty: Most of the difficulty lies in what to do, not so much
how to do it. Might require modifying cherry-pick to do additional
work on failure.
2. Invent new conflict style
As an alternative to the diff3 conflict style, invent a conflict style
that shows the original unpatched segment along with the raw patch
text. The user can then apply the patch by hand.
Language: C
Difficulty: Since it was first written, very few people have touched
the xdiff portion of the code. Since the area is very core to git, the
series will have to go through a ton of iterations.
3. Rewrite git-branch to use git-for-each-ref
For higher flexibility in command-line options and output format, use
git for-each-ref to re-implement git-branch. The first task is to grow
features that are in branch but not fer into fer (like --column,
--merged, --contains). The second task is to refactor fer so that an
external program can call into it.
Language: C
Difficulty: fer was never written with the idea of being reusable; it
therefore persists a lot of global state, and even leaks memory in
some places. Refactoring it to be more modern is definitely a
challenge.
4. Implement @{publish}
(I just can't find the time to finish this)
@{publish} is a feature like @{upstream}, showing the state of the
publish-point in the case of triangular workflows. Implement this
while sharing code with git-push, and polish it until the prompt shows
publish-state.
Language: C, Shell script
Difficulty: Once you figure out how to share code with git-push, this
task should be relatively straightforward.
--
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
[TEST EMAIL] Testing rk/send-email-ssl-cert in pu
Hi, This email tests that 01645b7 (send-email: /etc/ssl/certs/ directory may not be usable as ca_path, 2014-01-15) doesn't cause a regression. Ram -- 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] send-email: If the ca path is not specified, use the defaults
Junio C Hamano wrote: This change could introduce a regression for people on a platform whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL somehow fails to use it as SSL_ca_path without being told. I can confirm that my git-send-email doesn't regress to the pre-35035bbf state; my certificate directory is /etc/ssl/certs. I'm somewhat surprised that IO::Socket::SSL picks the right file/ directory on every platform without being told explicitly. This change definitely looks like the right fix. Thanks. -- 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 5/5] implement @{publish} shorthand
Jeff King wrote:
As far as merging it to 'next', I had not really intended it to go that
far. :) It was more for Ram to use as a base.
Sorry about not having posted a follow-up yet; I'm adjusting to a new
timezone and environment.
I find some of the
refactoring questionable, including:
1. The meaning of branch-pushremote is subtly different from that of
branch-remote. Ram's followup refactoring did a better job of
that (but he is missing the patches on top to finish out the
feature).
2. We are duplicating the where to push logic here. That should
probably be factored out so that git push and @{publish} use
the same logic.
And of course there are no tests or documentation. It might work,
though.
Actually, task (2) is somewhat involved: I still haven't figured out
how to share code with 'git push'.
I don't mind if you want to merge it and do more work in-tree, but I do
not think it should graduate as-is. And you may want check from Ram that
he is not in the middle of his own version based on the patches he sent
earlier, as reworking them on top of mine would probably just be
needless extra work.
On that note, can you hold off graduating
jk/branch-at-publish-rebased, Junio? Hopefully, I'll come up with a
replacement over the weekend.
Thanks.
--
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 3/3] remote: introduce and fill branch-pushremote
Jeff King wrote:
2. If the current branch has a branch.*.pushremote set, but we want to
know where a _different_ branch would be pushed, we have no way to
access remote.pushdefault (it gets overwritten in the hunk above).
@{upstream} does not have this problem, because it is _only_
defined if branch.*.remote is set. There is no such thing as
defaulting to a remote.default (or origin) there, and we never
need to look at default_remote_name.
For @{publish}, though, I think we will want that default. The
common config will be to simply set remote.pushdefault, rather
than setting up branch.*.pushremote for each branch, and we would
want @{publish} to handle that properly.
Not sure I understand what the problem is. Let's say we have two
branches: master, and side with remote.pushdefault = ram,
branch.*.remote = origin, and branch.side.pushremote = peff. Now, when
I query master's pushremote, I get ram and when I query side's
pushremote, I get peff; all the logic for falling-back from
branch.*.pushremote to remote.pushdefault to branch.*.remote is in
branch_get(), so I need to do nothing extra on the caller-side. From
the caller's perspective, why does it matter if the pushremote of a
particular branch is due to branch.*.pushremote or remote.pushdefault?
--
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: Error in documentation for @{-n} in gitrevisions
Kevin wrote:
Either the documentation is wrong, and should be changed to nth
branch/commit checkout out before the current one, or the behavior of
@{-1} is wrong.
Yeah, the documentation needs to be updated. Patches welcome.
--
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 1/3] t1507 (rev-parse-upstream): fix typo in test title
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t1507-rev-parse-upstream.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index 2a19e79..15f2e7e 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -54,7 +54,7 @@ test_expect_success 'my-side@{upstream} resolves to correct
full name' '
test refs/remotes/origin/side = $(full_name my-side@{u})
'
-test_expect_success 'refs/heads/my-side@{upstream} does not resolve to
my-side{upstream}' '
+test_expect_success 'refs/heads/my-side@{upstream} does not resolve to
my-side@{upstream}' '
test_must_fail full_name refs/heads/my-side@{upstream}
'
--
1.8.5.2.313.g5abf4c0.dirty
--
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 0/3] Minor preparation for @{publish}
Hi,
I'm getting ready to switch timezones in a few days, so the @{publish}
series is on hold for some time. In the meantime, I thought I'd send
in a few patches early.
[1/3] is a minor typo fix I happened to notice while writing tests.
[2/3] is an is an excellent patch by Peff, that greatly helped
prettify the code. It's a pure refactor and should have no effect on
functionality.
[3/3] introduces branch-pushremote corresponding to branch-remote,
which is crucial for getting @{publish} from the branch_get()
interface. Peff had sent a similar patch, but mine has some subtle
differences.
Thanks.
Jeff King (1):
interpret_branch_name: factor out upstream handling
Ramkumar Ramachandra (2):
t1507 (rev-parse-upstream): fix typo in test title
remote: introduce and fill branch-pushremote
remote.c | 15 ++--
remote.h | 3 ++
sha1_name.c | 83 +++
t/t1507-rev-parse-upstream.sh | 2 +-
4 files changed, 68 insertions(+), 35 deletions(-)
--
1.8.5.2.313.g5abf4c0.dirty
--
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 2/3] interpret_branch_name: factor out upstream handling
From: Jeff King p...@peff.net
This function checks a few different @{}-constructs. The
early part checks for and dispatches us to helpers for each
construct, but the code for handling @{upstream} is inline.
Let's factor this out into its own function. This makes
interpret_branch_name more readable, and will make it much
simpler to add more constructs in future patches.
While we're at it, let's also break apart the refactored
code into a few helper functions. These will be useful when
we implement similar @{upstream}-like constructs.
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 83 ++---
1 file changed, 52 insertions(+), 31 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b1873d8..7ebb8ee 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1046,6 +1046,54 @@ static int reinterpret(const char *name, int namelen,
int len, struct strbuf *bu
return ret - used + len;
}
+static void set_shortened_ref(struct strbuf *buf, const char *ref)
+{
+ char *s = shorten_unambiguous_ref(ref, 0);
+ strbuf_reset(buf);
+ strbuf_addstr(buf, s);
+ free(s);
+}
+
+static const char *get_upstream_branch(const char *branch_buf, int len)
+{
+ char *branch = xstrndup(branch_buf, len);
+ struct branch *upstream = branch_get(*branch ? branch : NULL);
+
+ /*
+* Upstream can be NULL only if branch refers to HEAD and HEAD
+* points to something different than a branch.
+*/
+ if (!upstream)
+ die(_(HEAD does not point to a branch));
+ if (!upstream-merge || !upstream-merge[0]-dst) {
+ if (!ref_exists(upstream-refname))
+ die(_(No such branch: '%s'), branch);
+ if (!upstream-merge) {
+ die(_(No upstream configured for branch '%s'),
+ upstream-name);
+ }
+ die(
+ _(Upstream branch '%s' not stored as a remote-tracking
branch),
+ upstream-merge[0]-src);
+ }
+ free(branch);
+
+ return upstream-merge[0]-dst;
+}
+
+static int interpret_upstream_mark(const char *name, int namelen,
+ int at, struct strbuf *buf)
+{
+ int len;
+
+ len = upstream_mark(name + at, namelen - at);
+ if (!len)
+ return -1;
+
+ set_shortened_ref(buf, get_upstream_branch(name, at));
+ return len + at;
+}
+
/*
* This reads short-hand syntax that not only evaluates to a commit
* object name, but also can act as if the end user spelled the name
@@ -1070,9 +1118,7 @@ static int reinterpret(const char *name, int namelen, int
len, struct strbuf *bu
int interpret_branch_name(const char *name, int namelen, struct strbuf *buf)
{
char *cp;
- struct branch *upstream;
int len = interpret_nth_prior_checkout(name, buf);
- int tmp_len;
if (!namelen)
namelen = strlen(name);
@@ -1094,36 +1140,11 @@ int interpret_branch_name(const char *name, int
namelen, struct strbuf *buf)
if (len 0)
return reinterpret(name, namelen, len, buf);
- tmp_len = upstream_mark(cp, namelen - (cp - name));
- if (!tmp_len)
- return -1;
+ len = interpret_upstream_mark(name, namelen, cp - name, buf);
+ if (len 0)
+ return len;
- len = cp + tmp_len - name;
- cp = xstrndup(name, cp - name);
- upstream = branch_get(*cp ? cp : NULL);
- /*
-* Upstream can be NULL only if cp refers to HEAD and HEAD
-* points to something different than a branch.
-*/
- if (!upstream)
- die(_(HEAD does not point to a branch));
- if (!upstream-merge || !upstream-merge[0]-dst) {
- if (!ref_exists(upstream-refname))
- die(_(No such branch: '%s'), cp);
- if (!upstream-merge) {
- die(_(No upstream configured for branch '%s'),
- upstream-name);
- }
- die(
- _(Upstream branch '%s' not stored as a remote-tracking
branch),
- upstream-merge[0]-src);
- }
- free(cp);
- cp = shorten_unambiguous_ref(upstream-merge[0]-dst, 0);
- strbuf_reset(buf);
- strbuf_addstr(buf, cp);
- free(cp);
- return len;
+ return -1;
}
int strbuf_branchname(struct strbuf *sb, const char *name)
--
1.8.5.2.313.g5abf4c0.dirty
--
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 3/3] remote: introduce and fill branch-pushremote
When a caller uses branch_get() to retrieve a struct branch, they get
the per-branch remote name and a pointer to the remote struct. However,
they have no way of knowing about the per-branch pushremote from this
interface. So, let's expose that information via fields similar to
remote and remote_name; pushremote and pushremote_name.
Helped-by: Jeff King p...@peff.net
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 15 ---
remote.h | 3 +++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index a89efab..286cdce 100644
--- a/remote.c
+++ b/remote.c
@@ -351,9 +351,10 @@ static int handle_config(const char *key, const char
*value, void *cb)
explicit_default_remote_name = 1;
}
} else if (!strcmp(subkey, .pushremote)) {
+ if (git_config_string(branch-pushremote_name, key,
value))
+ return -1;
if (branch == current_branch)
- if (git_config_string(pushremote_name, key,
value))
- return -1;
+ pushremote_name = branch-pushremote_name;
} else if (!strcmp(subkey, .merge)) {
if (!value)
return config_error_nonbool(key);
@@ -1543,7 +1544,9 @@ struct branch *branch_get(const char *name)
ret = current_branch;
else
ret = make_branch(name, 0);
- if (ret ret-remote_name) {
+ if (!ret)
+ return ret;
+ if (ret-remote_name) {
ret-remote = remote_get(ret-remote_name);
if (ret-merge_nr) {
int i;
@@ -1557,6 +1560,12 @@ struct branch *branch_get(const char *name)
}
}
}
+ if (ret-pushremote_name)
+ ret-pushremote = remote_get(ret-pushremote_name);
+ else if (pushremote_name)
+ ret-pushremote = remote_get(pushremote_name);
+ else
+ ret-pushremote = ret-remote;
return ret;
}
diff --git a/remote.h b/remote.h
index 00c6a76..ac5aadc 100644
--- a/remote.h
+++ b/remote.h
@@ -201,6 +201,9 @@ struct branch {
const char *remote_name;
struct remote *remote;
+ const char *pushremote_name;
+ struct remote *pushremote;
+
const char **merge_name;
struct refspec **merge;
int merge_nr;
--
1.8.5.2.313.g5abf4c0.dirty
--
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 2/5] interpret_branch_name: factor out upstream handling
Jeff King wrote: sha1_name.c | 83 ++--- 1 file changed, 52 insertions(+), 31 deletions(-) Thanks. I applied this to my series as-it-is. -- 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 0/5] branch@{publish} shorthand
Jeff King wrote: There's a fair bit of refactoring involved. I took a stab at it and came up with the series below. No docs or tests, and some of the refactoring in remote.c feels a little weird. I can't help but feel more of the logic from git push should be shared here. But it at least works with my rudimentary examples. I'm hoping it will make a good starting point for you to build on. Otherwise, I may get to it eventually, but it's not a high priority for me right now. Thanks; I'll see what I can do about getting it to share code with 'git push'. -- 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 1/2] completion: complete format.coverLetter
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] format-patch: introduce format.defaultTo
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 = upstream does not support triangular workflows. See
builtin/push.c:setup_push_upstream().
Given this new found knowledge, I'm not sure it makes sense for `git
status` to show me the status against the upstream vs. the publish
location. The latter makes a little more sense to me, though I see
the usefulness of either one.
Currently, status information is only against @{u}; we haven't
invented a @{publish} yet.
--
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] format-patch: introduce branch.*.forkedFrom
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git format-patch -o outgoing
is a no-op on a topic branch, and the user has to remember to specify
'master' explicitly everytime. This problem is not unique to
format-patch; even a
$ git rebase -i
is a no-op because the branch to rebase against isn't specified.
To tackle this problem, introduce branch.*.forkedFrom which can specify
the parent branch of a topic branch. Future patches will build
functionality around this new configuration variable.
Cc: Jeff King p...@peff.net
Cc: Junio C Hamano gis...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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.
But I wanted to discuss the overall idea of the patch.
builtin/log.c | 21 +
t/t4014-format-patch.sh | 20
2 files changed, 41 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index b97373d..525e696 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -674,6 +674,7 @@ static int thread;
static int do_signoff;
static const char *signature = git_version_string;
static int config_cover_letter;
+static const char *config_base_branch;
enum {
COVER_UNSET,
@@ -750,6 +751,22 @@ static int git_format_config(const char *var, const char
*value, void *cb)
config_cover_letter = git_config_bool(var, value) ? COVER_ON :
COVER_OFF;
return 0;
}
+ if (starts_with(var, branch.)) {
+ const char *name = var + 7;
+ const char *subkey = strrchr(name, '.');
+ struct strbuf buf = STRBUF_INIT;
+
+ if (!subkey)
+ return 0;
+ strbuf_add(buf, name, subkey - name);
+ if (branch_get(buf.buf) != branch_get(NULL))
+ return 0;
+ strbuf_release(buf);
+ if (!strcmp(subkey, .forkedfrom)) {
+ if (git_config_string(config_base_branch, var, value))
+ return -1;
+ }
+ }
return git_log_config(var, value, cb);
}
@@ -1324,6 +1341,10 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
die (_(--subject-prefix and -k are mutually exclusive.));
rev.preserve_subject = keep_subject;
+ if (argc 2 config_base_branch) {
+ argv[1] = config_base_branch;
+ argc++;
+ }
argc = setup_revisions(argc, argv, rev, s_r_opt);
if (argc 1)
die (_(unrecognized argument: %s), argv[1]);
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 73194b2..2ea94af 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1370,4 +1370,24 @@ test_expect_success 'cover letter auto user override' '
test_line_count = 2 list
'
+test_expect_success 'branch.*.forkedFrom matches' '
+ mkdir -p tmp
+ test_when_finished rm -rf tmp;
+ git config --unset branch.rebuild-1.forkedFrom
+
+ git config branch.rebuild-1.forkedFrom master
+ git format-patch -o tmp list
+ test_line_count = 2 list
+'
+
+test_expect_success 'branch.*.forkedFrom does not match' '
+ mkdir -p tmp
+ test_when_finished rm -rf tmp;
+ git config --unset branch.foo.forkedFrom
+
+ git config branch.foo.forkedFrom master
+ git format-patch -o tmp list
+ test_line_count = 0 list
+'
+
test_done
--
1.8.5.2.234.gba2dde8.dirty
--
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] format-patch: introduce branch.*.forkedFrom
[Fixed typo in Junio's address]
On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git format-patch -o outgoing
is a no-op on a topic branch, and the user has to remember to specify
'master' explicitly everytime. This problem is not unique to
format-patch; even a
$ git rebase -i
is a no-op because the branch to rebase against isn't specified.
To tackle this problem, introduce branch.*.forkedFrom which can specify
the parent branch of a topic branch. Future patches will build
functionality around this new configuration variable.
Cc: Jeff King p...@peff.net
Cc: Junio C Hamano gis...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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.
But I wanted to discuss the overall idea of the patch.
builtin/log.c | 21 +
t/t4014-format-patch.sh | 20
2 files changed, 41 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index b97373d..525e696 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -674,6 +674,7 @@ static int thread;
static int do_signoff;
static const char *signature = git_version_string;
static int config_cover_letter;
+static const char *config_base_branch;
enum {
COVER_UNSET,
@@ -750,6 +751,22 @@ static int git_format_config(const char *var, const char
*value, void *cb)
config_cover_letter = git_config_bool(var, value) ? COVER_ON
: COVER_OFF;
return 0;
}
+ if (starts_with(var, branch.)) {
+ const char *name = var + 7;
+ const char *subkey = strrchr(name, '.');
+ struct strbuf buf = STRBUF_INIT;
+
+ if (!subkey)
+ return 0;
+ strbuf_add(buf, name, subkey - name);
+ if (branch_get(buf.buf) != branch_get(NULL))
+ return 0;
+ strbuf_release(buf);
+ if (!strcmp(subkey, .forkedfrom)) {
+ if (git_config_string(config_base_branch, var,
value))
+ return -1;
+ }
+ }
return git_log_config(var, value, cb);
}
@@ -1324,6 +1341,10 @@ int cmd_format_patch(int argc, const char **argv,
const char *prefix)
die (_(--subject-prefix and -k are mutually exclusive.));
rev.preserve_subject = keep_subject;
+ if (argc 2 config_base_branch) {
+ argv[1] = config_base_branch;
+ argc++;
+ }
argc = setup_revisions(argc, argv, rev, s_r_opt);
if (argc 1)
die (_(unrecognized argument: %s), argv[1]);
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 73194b2..2ea94af 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1370,4 +1370,24 @@ test_expect_success 'cover letter auto user override' '
test_line_count = 2 list
'
+test_expect_success 'branch.*.forkedFrom matches' '
+ mkdir -p tmp
+ test_when_finished rm -rf tmp;
+ git config --unset branch.rebuild-1.forkedFrom
+
+ git config branch.rebuild-1.forkedFrom master
+ git format-patch -o tmp list
+ test_line_count = 2 list
+'
+
+test_expect_success 'branch.*.forkedFrom does not match' '
+ mkdir -p tmp
+ test_when_finished rm -rf tmp;
+ git config --unset branch.foo.forkedFrom
+
+ git config branch.foo.forkedFrom master
+ git format-patch -o tmp list
+ test_line_count = 0 list
+'
+
test_done
--
1.8.5.2.234.gba2dde8.dirty
--
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] format-patch: introduce branch.*.forkedFrom
Junio C Hamano wrote:
I do not mind allowing laziness by defaulting to something, but I am
not enthused by an approach that adds the new variable whose value
is questionable. The description does not justify at all why
@{upstream} is not a good default (unless the workflow is screwed up
and @{upstream} is set to point at somewhere that is _not_ a true
upstream, that is).
Did you find the explanation I gave in
http://article.gmane.org/gmane.comp.version-control.git/240077
reasonable? I don't know why label the respin-workflow as being
screwed up.
--
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] format-patch: introduce branch.*.forkedFrom
Jeff King wrote:
I have not carefully read some of the later bits of the discussion from
last night / this morning, so maybe I am missing something, but this
seems backwards to me from what Junio and I were discussing earlier.
The point was that the meaning of @{upstream} (and branch.*.merge)
is _already_ forked-from, and push -u and push.default=upstream
are the odd men out. If we are going to add an option to distinguish the
two branch relationships:
1. Where you forked from
2. Where you push to
we should leave @{upstream} as (1), and add a new option to represent
(2). Not the other way around.
I have a local branch 'forkedfrom' that has two sources: 'master'
and 'ram/forkedfrom'. 'ram/forkedfrom' isn't a dumb publish-point:
the relationship information I get between 'forkedfrom' and
'ram/forkedfrom' is very useful; it's what helps me tell how my
re-roll is doing with respect to the original series; I'd often want
to cherry-pick commits/ messages from my original series to prepare
the re-roll, so interaction with this source is quite high. On the
other hand, the relationship information I get between 'forkedfrom'
and 'master' is practically useless: 'forkedfrom' is always ahead of
'master', and a divergence indicates that I need to rebase; I'll never
really need to interact with this source.
I'm only thinking in terms of what infrastructure we've already built:
if @{u} is set to 'ram/forkedfrom', we get a lot of information for
free _now_. If @{u} is set to 'master', the current git-status is
unhelpful.
--
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 2/2] format-patch: introduce format.defaultTo
Jeff King wrote:
My daily procedure is something like:
all_topics |
while read topic; do echo $topic $(git rev-parse $topic@{u}); done |
topo_sort |
while read topic upstream; do
git rebase $upstream $topic || exit 1
done
Ah, I was perhaps over-specializing for my own usecase, where
everything is based off 'master'. I never considered 'master' a true
upstream because I throw away topic branches after the maintainer
merges them. If you have long-running branches that you work on a
daily basis, the issue is somewhat different.
While doing respins, the prompt doesn't aid you in any way. Besides,
on several occasions, I found myself working on the same forked-branch
from two different machines; then the publish-point isn't necessarily
always a publish-point: it's just another upstream for the branch.
Right, things get trickier then. But I don't think there is an automatic
way around that. Sometimes the published one is more up to date, and
sometimes the upstream thing is more up to date. You have to manually
tell git which you are currently basing your work on. I find in such a
situation that it tends to resolve itself quickly, though, as the first
step is to pull in the changes you pushed up from the other machine
anyway (either via git reset or git rebase).
My primary concern is that the proposed @{publish} should be a
first-class citizen; if it has everything that @{u} has, then we're
both good: you'd primarily use @{u}, while I'd primarily use
@{publish}.
--
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] format-patch: introduce branch.*.forkedFrom
Jeff King wrote:
I definitely respect the desire to reuse the existing tooling we have
for @{u}. At the same time, I think you are warping the meaning of
@{u} somewhat. It is _not_ your upstream here, but rather another
version of the branch that has useful changes in it. That might be
splitting hairs a bit, but I think you will find that the differences
leak through in inconvenient spots (like format-patch, where you really
_do_ want to default to the true upstream).
Thanks for the clear reasoning.
If we add @{publish} (and @{pu}), then it becomes very convenient to
refer to the ram/ version of your branch. That seems like an obvious
first step to me. We don't have to add new config, because
branch.*.pushremote already handles this.
Agreed. I'll start working on @{publish}. It's going to take quite a
bit of effort, because I won't actually start using it until my prompt
is @{publish}-aware.
Now you can do git rebase @{pu} which is nice, but not _quite_ as nice
as git rebase, which defaults to @{u}. That first step might be
enough, and I'd hold off there and try it out for a few days or weeks
first. But if you find in your workflow that you are having to specify
@{pu} a lot, then maybe it is worth adding an option to default rebase
to @{pu} instead of @{u}.
Actually, I'm not sure I'd use git rebase @{pu}; for me @{pu} is
mainly a source of information for taking apart to build a new series.
--
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 2/2] format-patch: introduce format.defaultTo
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git format-patch -o outgoing
is a no-op on a topic branch, and the user has to remember to specify
'master' 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 artag...@gmail.com
---
Documentation/config.txt | 4
builtin/log.c | 7 +++
contrib/completion/git-completion.bash | 1 +
t/t4014-format-patch.sh| 10 ++
4 files changed, 22 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a405806..b90abd1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1135,6 +1135,10 @@ format.coverLetter::
format-patch is invoked, but in addition can be set to auto, to
generate a cover-letter only when there's more than one patch.
+format.defaultTo::
+ The name of a branch against which to generate patches by
+ default. You'd usually want this to be 'master'.
+
filter.driver.clean::
The command which is used to convert the content of a worktree
file to a blob upon checkin. See linkgit:gitattributes[5] for
diff --git a/builtin/log.c b/builtin/log.c
index b97373d..ebc419e 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -674,6 +674,7 @@ static int thread;
static int do_signoff;
static const char *signature = git_version_string;
static int config_cover_letter;
+static const char *config_defaultto;
enum {
COVER_UNSET,
@@ -750,6 +751,8 @@ static int git_format_config(const char *var, const char
*value, void *cb)
config_cover_letter = git_config_bool(var, value) ? COVER_ON :
COVER_OFF;
return 0;
}
+ if (!strcmp(var, format.defaultto))
+ return git_config_string(config_defaultto, var, value);
return git_log_config(var, value, cb);
}
@@ -1324,6 +1327,10 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
die (_(--subject-prefix and -k are mutually exclusive.));
rev.preserve_subject = keep_subject;
+ if (argc 2 config_defaultto) {
+ argv[1] = config_defaultto;
+ argc++;
+ }
argc = setup_revisions(argc, argv, rev, s_r_opt);
if (argc 1)
die (_(unrecognized argument: %s), argv[1]);
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 39b81f7..75699d4 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1992,6 +1992,7 @@ _git_config ()
format.attach
format.cc
format.coverLetter
+ format.defaultTo
format.headers
format.numbered
format.pretty
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 73194b2..46c0337 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1370,4 +1370,14 @@ test_expect_success 'cover letter auto user override' '
test_line_count = 2 list
'
+test_expect_success 'defaultTo side' '
+ mkdir -p tmp
+ test_when_finished rm -rf tmp;
+ git config --unset format.defaultTo
+
+ git config format.defaultTo side
+ git format-patch -o tmp list
+ test_line_count = 3 list
+'
+
test_done
--
1.8.5.2.229.g4448466.dirty
--
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 1/2] completion: complete format.coverLetter
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- 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/contrib/completion/git-completion.bash @@ -1991,6 +1991,7 @@ _git_config () fetch.unpackLimit format.attach format.cc + format.coverLetter format.headers format.numbered format.pretty -- 1.8.5.2.229.g4448466.dirty -- 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 0/2] Minor convinience feature: format.defaultTo
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 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
[BUG] rebase --onto doesn't abort properly
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 surprised I didn't notice it earlier. Are others able to reproduce this? Thanks. Ram -- 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 2/2] format-patch: introduce format.defaultTo
Junio C Hamano wrote:
- why is a single branch name sufficient?
It does accept a revision, 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 default to @{u}, if one exists,
instead of failing?
I'm not sure @{u} is a good default. Personally, my workflow involves
publishing my fork before sending out patches; mainly so that I can
compare with @{u} when I do re-spins. People can put @{u} in
format.defaultTo if it suits their workflow though.
--
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: [BUG] rebase --onto doesn't abort properly
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 state you would want to go back to before doing anything, but then what happens if the ^C comes when you are still in the middle of doing so? I'm a bit puzzled: doesn't rebase write_basic_state() as soon as it starts? It's true that we can't recover from a ^C before that, but I would expect to be able to recover after a ^C somewhere in the middle. -- 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 2/2] format-patch: introduce format.defaultTo
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 foo] insteadOf' is an exception to that and a bit of an
aberration.
This new '[format] defaultTo' repeats the same end-with-a-preposition
mistake, while I think it would be better to learn from it.
I agree that it's somewhat unconventional to allow people to put a
revision as a configuration variable value, but I think it's useful.
url.url.insteadOf is incredibly useful, for instance.
2. Wouldn't a more natural default be @{u}..HEAD instead of relying on
the user to do the make-work of keeping a local branch that tracks
master up to date?
Like I said in my message to Junio, @{u} is not necessarily the best
default for all workflows, although you can fill that into
format.defaultTo.
--
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 2/2] format-patch: introduce format.defaultTo
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 @{u} to this new configuration, in which case the
choice becomes dynamic depending on the current branch, but
- if that is the only sane choice based on the current branch, why
not use that as the default without having to set the
configuration?
- Or if that is still insufficient, don't we need branch.*.forkedFrom
that is different from branch.*.merge, so that different branches
you want to show format-patch output can have different
reference points?
Ah, I was going for an equivalent of merge.defaultToUpstream, but I
guess branch.*.forkedFrom is a good way to go.
--
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 2/2] format-patch: introduce format.defaultTo
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 forked upstream; I find that extremely useful when doing
re-spins.
But then there
is git push -u and push.default = upstream, which treats the
upstream config as something else entirely.
push.default = upstream is a bit of a disaster, in my opinion. I've
advocated push.default = current on multiple occasions, and wrote the
initial remote.pushDefault series with that configuration in mind.
I wonder if it is too late to try to clarify this dual usage. It kind of
seems like the push config is this is the place I publish to. Which,
in many workflows, just so happens to be the exact same as the place you
forked from. Could we introduce a new branch.*.pushupstream variable
that falls back to branch.*.merge? Or is that just throwing more fuel on
the fire (more sand in the pit in my analogy, I guess).
We already have a branch.*.pushremote, and I don't see the value of
branch.*.pushbranch (what you're referring to as pushupstream, I
assume) except for Gerrit users. Frankly, I don't use full triangular
workflows myself mainly because my prompt is compromised: when I have
a branch.*.remote different from branch.*.pushremote, I'd like to see
where my branch is with respect to @{u} and @{publish} (not yet
invented); that's probably too much information to digest anyway, so I
use central workflow (pointing to my fork) for each of my branches,
except master (which points to Junio's repo).
I admit I haven't thought it through yet, though. And even if it does
work, it may throw a slight monkey wrench in the proposed push.default
transition.
We're transitioning to push.default = simple which is even simpler than current.
--
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 2/2] format-patch: introduce format.defaultTo
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.pushdefaultset to 'publish', you can expect
git push
to do the right thing, and then always say
git show-branch publish/topic topic
I think it's highly sub-optimal to have a local-branch @{u} for
several reasons; the prompt is almost useless in this case, and it
will always show your forked-branch ahead of 'master' (assuming that
'master' doesn't update itself in the duration of your development).
While doing respins, the prompt doesn't aid you in any way. Besides,
on several occasions, I found myself working on the same forked-branch
from two different machines; then the publish-point isn't necessarily
always a publish-point: it's just another upstream for the branch.
The point of a special branch.*.forkedFrom is that you can always show
the master..@ information in the prompt ignoring divergences; after
all, a divergence simply means that you need to rebase onto the latest
'master' ('master' is never going to get a non-ff update anyway).
So, instead of crippling the functionality around the publish-point,
let's build minimal required functionality around branch.*.forkedFrom.
I'd love a prompt like:
branch-forkedfrom5*:~/src/git$
Clearly, branch-forkedfrom has diverged from my publish-point (I'm
probably doing a respin), and has 5 commits (it's 5 commits ahead of
'master' ignoring divergences).
to see where your last published branch is relative to what you
have, no? Mapping topic@{publish} to refs/remotes/publish/topic
(or when you have 'topic' checked out, mapping @{publish} to it)
is a trivial but is a separate usefulness, I would guess.
I think a @{publish} is needed for when branch.*.remote is different
from remote.pushDefault. Like I said earlier, it's probably too much
information to give to the user: divergences with respect to two
remotes. So, we'll hold it off until someone finds a usecase for 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: [PATCH 2/2] format-patch: introduce format.defaultTo
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.
Am I missing something? If there is something other than @{u} to
represent this latter concept, I think `git push` should default to
that instead. But, at least with my current knowledge, that doesn't
exist--without explicitly saying so--or treating @{u} as that branch.
If there's a better way to do this, I'd love to hear it!
That's why we invented remote.pushdefault and branch.*.pushremote. When you say
$ git push
it automatically goes to the right remote instead of going to the
place you fetched from. You can read up on how push.default interacts
with this setting too, although I always recommend push.default =
current.
--
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 v3 2/4] completion: introduce __gitcomp_nl_append ()
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 lower-level functions; so it's no problem at all. I wrote mine out by thinking of a non-intrusive direct translation, while your version focuses on eliminating duplication. I don't have a strong preference either way, so I will resubmit with your version. -- 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 v4 1/4] zsh completion: find matching custom bash completion
If zsh completion is being read from a location that is different from
system-wide default, it is likely that the user is trying to use a
custom version, perhaps closer to the bleeding edge, installed in her
own directory. We will more likely to find the matching bash completion
script in the same directory than in those system default places.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z $script ]; then
local -a locations
local e
locations=(
+ $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu,
new debian
'/usr/share/bash-completion/git' # gentoo
- $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e script=$e break
--
1.8.5.2.227.g53f3478
--
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 1/4] completion: prioritize ./git-completion.bash
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z $script ]; then
local -a locations
local e
locations=(
+ $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu,
new debian
'/usr/share/bash-completion/git' # gentoo
- $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e script=$e break
--
1.8.5.2.227.g53f3478
--
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 2/4] completion: introduce __gitcomp_2 ()
There are situations where two classes of completions possible. For
example
branch.TAB
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ., and the second/ third candidates
have the suffix . To facilitate 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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10 ++
2 files changed, 40 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..64b20b8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,36 @@ __gitcomp_nl ()
__gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
+# Generates completion reply from two sets of completion words, with
+# configurable suffixes for each.
+#
+# It accepts 2 to 6 arguments:
+# 1: First set of possible completion words.
+# 2: Second set of possible completion words.
+# 3: A prefix to be added to each completion word (both $1 and $2)
+#(optional).
+# 4: Generate possible completion matches for this word (optional).
+# 5: A suffix to be appended to each completion word in the first set
+#($1) instead of the default space (optional).
+# 6: A suffix to be appended to each completion word in the second set
+#($2) instead of the default space (optional).
+__gitcomp_2 ()
+{
+ local pfx=${3-} cur_=${4-$cur} sfx=${5- } sfx2=${6- } i=0
+ local IFS=$' \t\n'
+
+ for x in $1; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx
+ fi
+ done
+ for x in $2; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx2
+ fi
+ done
+}
+
# Generates completion reply with compgen from newline-separated possible
# completion filenames.
# It accepts 1 to 3 arguments:
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 6fca145..261a7f5 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -76,6 +76,16 @@ __gitcomp_nl ()
compadd -Q -S ${4- } -p ${2-} -- ${=1} _ret=0
}
+__gitcomp_2 ()
+{
+ emulate -L zsh
+
+ local IFS=$' \t\n'
+ compset -P '*[=:]'
+ compadd -Q -S ${5- } -p ${3-} -- ${=1} _ret=0
+ compadd -Q -S ${6- } -p ${3-} -- ${=2} _ret=0
+}
+
__gitcomp_file ()
{
emulate -L zsh
--
1.8.5.2.227.g53f3478
--
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 0/4] Fix branch.autosetup(merge|rebase) completion
Hi, In this iteration, I've removed hunks to prevent completing: $ git config remote.pushdefault.TAB $ git config branch.autosetupmerge.TAB $ git config branch.autosetuprebase.TAB Since they're perfectly valid remote/ branch names. Thanks. 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.bash | 36 -- contrib/completion/git-completion.zsh | 12 +++- 2 files changed, 45 insertions(+), 3 deletions(-) -- 1.8.5.2.227.g53f3478 -- 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 3/4] completion: fix branch.autosetup(merge|rebase)
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 providing completions for $ git config branch.autosetupmerge.TAB when no branch called autosetupmerge exists. The purpose of the hunk (which I now removed) was to prevent such completions, but it has the side-effect of also preventing a legitimate completion in the case when the user really has a branch named autosetupmerge. What is your take on the issue? -- 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 v3 0/4] Fix branch.autosetup(merge|rebase) completion
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: introduce __gitcomp_nl_append () completion: fix branch.autosetup(merge|rebase) completion: fix remote.pushdefault contrib/completion/git-completion.bash | 15 +++ contrib/completion/git-completion.zsh | 10 +- 2 files changed, 24 insertions(+), 1 deletion(-) -- 1.8.5.2.227.g53f3478 -- 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 v3 1/4] completion: prioritize ./git-completion.bash
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z $script ]; then
local -a locations
local e
locations=(
+ $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu,
new debian
'/usr/share/bash-completion/git' # gentoo
- $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e script=$e break
--
1.8.5.2.227.g53f3478
--
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 v3 2/4] completion: introduce __gitcomp_nl_append ()
There are situations where multiple classes of completions possible. For
example
branch.TAB
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ., and the second/ third candidates
have the suffix . 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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 13 +
contrib/completion/git-completion.zsh | 8
2 files changed, 21 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..bf358d6 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,19 @@ __gitcomp_nl ()
__gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
+# Variation of __gitcomp_nl () that appends to the existing list of
+# completion candidates, COMPREPLY.
+__gitcomp_nl_append ()
+{
+ local IFS=$'\n'
+ local i=${#COMPREPLY[@]}
+ for x in $1; do
+ if [[ $x == $3* ]]; then
+ COMPREPLY[i++]=$2$x$4
+ fi
+ done
+}
+
# Generates completion reply with compgen from newline-separated possible
# completion filenames.
# It accepts 1 to 3 arguments:
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 6fca145..6b77968 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -76,6 +76,14 @@ __gitcomp_nl ()
compadd -Q -S ${4- } -p ${2-} -- ${=1} _ret=0
}
+__gitcomp_nl_append ()
+{
+ emulate -L zsh
+
+ local IFS=$'\n'
+ compadd -Q -S ${4- } -p ${2-} -- ${=1} _ret=0
+}
+
__gitcomp_file ()
{
emulate -L zsh
--
1.8.5.2.227.g53f3478
--
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 v3 4/4] completion: fix remote.pushdefault
When attempting to complete
$ git config remote.pushTAB
'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 ().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 75c7302..345ceff 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1883,6 +1883,7 @@ _git_config ()
remote.*)
local pfx=${cur%.*}. cur_=${cur#*.}
__gitcomp_nl $(__git_remotes) $pfx $cur_ .
+ __gitcomp_nl_append pushdefault $pfx $cur_
return
;;
url.*.*)
--
1.8.5.2.227.g53f3478
--
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 v3 3/4] completion: fix branch.autosetup(merge|rebase)
When attempting to complete
$ git config branch.autoTAB
'autosetupmerge' and 'autosetuprebase' don't come up. This is because
$cur is matched with branch.* and a list of branches are
completed. Add 'autosetupmerge', 'autosetuprebase' to the list of
branches using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1840,6 +1840,7 @@ _git_config ()
branch.*)
local pfx=${cur%.*}. cur_=${cur#*.}
__gitcomp_nl $(__git_heads) $pfx $cur_ .
+ __gitcomp_nl_append $'autosetupmerge\nautosetuprebase\n' $pfx
$cur_
return
;;
guitool.*.*)
--
1.8.5.2.227.g53f3478
--
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 3/4] completion: fix branch.autosetup(merge|rebase)
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.autosetupmerTAB
hit backspace to delete the trailing space, inserted a dot, and hit TAB again.
If you are working on a topic about
auto-setup-merge and named your branch autosetupmerge, don't you
want to be able to configure various aspect of that branch via
branch.autosetupmerge.{remote,merge} etc., just like you can do so
for your topic branch via branch.topic.{remote,merge} etc.,
regardless of your use of autosetupmerge option across branches?
My reasoning was that being correct was more important that being
complete. So, if by some horrible chance, the user names her branch
autosetupmerge, we don't aid her in completions.
Besides, it smells fishy to me that you need to enumerate and
special case these two here, and then you have to repeat them below
in a separate case arm.
I'm not too irked about correctness in this odd case; seeing that you
aren't either, I'll resubmit the series without this hunk (+ the hunk
in remote.pushdefault).
--
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 2/4] completion: introduce __gitcomp_2 ()
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 both cases? Who keeps track of the index i of COMPREPLY (it's currently a local variable)? If we make it global, doesn't every function that deals with COMPREPLY be careful to reset it? More importantly, can you see a usecase for more than two completion classes? -- 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 1/4] completion: prioritize ./git-completion.bash
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -30,10 +30,10 @@ if [ -z $script ]; then
local -a locations
local e
locations=(
+ $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
'/etc/bash_completion.d/git' # fedora, old debian
'/usr/share/bash-completion/completions/git' # arch, ubuntu,
new debian
'/usr/share/bash-completion/git' # gentoo
- $(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
)
for e in $locations; do
test -f $e script=$e break
--
1.8.5.2.227.g53f3478
--
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 0/4] Fix branch.autosetup(merge|rebase) completion
Hi, I figured that branch.autosetupmerge, branch.autosetuprebase and remote.pushdefault are very tedious to type out in full, and started looking into fixing their completions this evening. The solution turns out to be much more complex than I initally imagined, but I'm quite happy with 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.bash | 43 -- contrib/completion/git-completion.zsh | 12 +- 2 files changed, 52 insertions(+), 3 deletions(-) -- 1.8.5.2.227.g53f3478 -- 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 2/4] completion: introduce __gitcomp_2 ()
There are situations where two classes of completions possible. For
example
branch.TAB
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ., and the second/ third candidates
have the suffix . To facilitate 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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10 ++
2 files changed, 40 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..64b20b8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,36 @@ __gitcomp_nl ()
__gitcompadd $1 ${2-} ${3-$cur} ${4- }
}
+# Generates completion reply from two sets of completion words, with
+# configurable suffixes for each.
+#
+# It accepts 2 to 6 arguments:
+# 1: First set of possible completion words.
+# 2: Second set of possible completion words.
+# 3: A prefix to be added to each completion word (both $1 and $2)
+#(optional).
+# 4: Generate possible completion matches for this word (optional).
+# 5: A suffix to be appended to each completion word in the first set
+#($1) instead of the default space (optional).
+# 6: A suffix to be appended to each completion word in the second set
+#($2) instead of the default space (optional).
+__gitcomp_2 ()
+{
+ local pfx=${3-} cur_=${4-$cur} sfx=${5- } sfx2=${6- } i=0
+ local IFS=$' \t\n'
+
+ for x in $1; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx
+ fi
+ done
+ for x in $2; do
+ if [[ $x == $cur_* ]]; then
+ COMPREPLY[i++]=$pfx$x$sfx2
+ fi
+ done
+}
+
# Generates completion reply with compgen from newline-separated possible
# completion filenames.
# It accepts 1 to 3 arguments:
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index 6fca145..261a7f5 100644
--- a/contrib/completion/git-completion.zsh
+++ b/contrib/completion/git-completion.zsh
@@ -76,6 +76,16 @@ __gitcomp_nl ()
compadd -Q -S ${4- } -p ${2-} -- ${=1} _ret=0
}
+__gitcomp_2 ()
+{
+ emulate -L zsh
+
+ local IFS=$' \t\n'
+ compset -P '*[=:]'
+ compadd -Q -S ${5- } -p ${3-} -- ${=1} _ret=0
+ compadd -Q -S ${6- } -p ${3-} -- ${=2} _ret=0
+}
+
__gitcomp_file ()
{
emulate -L zsh
--
1.8.5.2.227.g53f3478
--
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 3/4] completion: fix branch.autosetup(merge|rebase)
When attempting to complete
$ git config branch.autoTAB
'autosetupmerge' and 'autosetuprebase' don't come up. This is because
$cur is matched with branch.* and a list of branches are
completed. Add 'autosetup(merge|rebase)' to the list of branches using
__gitcomp_2 ().
Also take care to not complete
$ git config branch.autosetupmerge.TAB
$ git config branch.autosetuprebase.TAB
with the usual branch.name. candidates.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 64b20b8..0bda757 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1851,12 +1851,18 @@ _git_config ()
;;
branch.*.*)
local pfx=${cur%.*}. cur_=${cur##*.}
+ if [ $pfx == branch.autosetupmerge. ] ||
+ [ $pfx == branch.autosetuprebase. ]; then
+ return
+ fi
__gitcomp remote pushremote merge mergeoptions rebase $pfx
$cur_
return
;;
branch.*)
local pfx=${cur%.*}. cur_=${cur#*.}
- __gitcomp_nl $(__git_heads) $pfx $cur_ .
+ __gitcomp_2 $(__git_heads)
+ autosetupmerge autosetuprebase
+$pfx $cur_ .
return
;;
guitool.*.*)
--
1.8.5.2.227.g53f3478
--
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 4/4] completion: fix remote.pushdefault
When attempting to complete
$ git config remote.pushTAB
'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 ().
Also take care to not complete
$ git config remote.pushdefault.TAB
with the usual remote.name. candidates.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0bda757..9e0213d 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1896,6 +1896,9 @@ _git_config ()
;;
remote.*.*)
local pfx=${cur%.*}. cur_=${cur##*.}
+ if [ $pfx == remote.pushdefault. ]; then
+ return
+ fi
__gitcomp
url proxy fetch push mirror skipDefaultUpdate
receivepack uploadpack tagopt pushurl
@@ -1904,7 +1907,7 @@ _git_config ()
;;
remote.*)
local pfx=${cur%.*}. cur_=${cur#*.}
- __gitcomp_nl $(__git_remotes) $pfx $cur_ .
+ __gitcomp_2 $(__git_remotes) pushdefault $pfx $cur_ .
return
;;
url.*.*)
--
1.8.5.2.227.g53f3478
--
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] for-each-ref: remove unused variable
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 struct {
*/
static const char **used_atom;
static cmp_type *used_atom_type;
-static int used_atom_cnt, sort_atom_limit, need_tagged, need_symref;
+static int used_atom_cnt, need_tagged, need_symref;
static int need_color_reset_at_eol;
/*
@@ -1105,7 +1105,6 @@ int cmd_for_each_ref(int argc, const char **argv, const
char *prefix)
if (!sort)
sort = default_sort();
- sort_atom_limit = used_atom_cnt;
/* for warn_ambiguous_refs */
git_config(git_default_config, NULL);
--
1.8.5.2.227.g53f3478
--
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 3/3] send-email: set SSL options through IO::Socket::SSL::set_client_defaults
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 socket class with an SSL socket, it does nothing to allow passing options to that socket. So the SSL-relevant options are lost. Both [1/3] and [2/3] look good. However, I'm curious about this one: Net::SMTP::SSL inherits from IO::Socket::SSL, where new() is defined. In the documentation for IO::Socket::SSL, $ perldoc IO::Socket::SSL I can see examples where SSL_verify_mode and SSL_ca_path are passed to new(). So, I'm not sure what this patch is about. -- 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: git-svn troubles with calendarserver SVN repo
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 testsvn::https://svn.calendarserver.org/repository/calendarserver/CalendarServer/ You might need to hack a bit to get it working properly, but you'll find that it's much faster than git-svn in the long-run. -- 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: branch annotations?
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 unhappy with the current 'git branch', and am looking to improve it. Branch descriptions will definitely be useful to display as well. Ramkumar (cc'd) was looking into that refactoring a while back, but I did not follow it closely (it looks like some of the underlying for-each-ref refactoring is on the 'next' branch?). The previous effort in collaboration with Duy fell apart, unfortunately. Currently, there are a few small patches enhancing f-e-r from the original series in 'next'. Once they graduate, the plan is to refactor f-e-r a bit so that 'git branch' can slowly be moved into using its machinery. -- 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: Git issues with submodules
[+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 explicitly (see diff-lib.c), while ls-files doesn't (see builtin/ls-files.c). My opinion is that this is a bug, and git ls-files needs to be taught to handle submodules properly. This leads to issues with Arcanist (which is a Phabricator's tool) who considers addons as uncommited changes and either complains on this or just adds this to commits. Does Arcanist use `git ls-files -m` to check? There're also some more issues which happens to our developers and which i can not quite reproduce. Do try to track down the other issues and let us know. Sometimes it happens so git checkout to another branch yields about uncommited changes to addons and doesn't checkout to another branch. I've seldom used submodules with branches, so I'll let others chime in. Cheers. -- 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: Git issues with submodules
Sergey Sharybin wrote: On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra artag...@gmail.com wrote: [+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 explicitly (see diff-lib.c), while ls-files doesn't (see builtin/ls-files.c). My opinion is that this is a bug, and git ls-files needs to be taught to handle submodules properly. Shall i fire report somewhere or it's being handled by the folks reading this ML? Bugs are reported and tackled on the list. This leads to issues with Arcanist (which is a Phabricator's tool) who considers addons as uncommited changes and either complains on this or just adds this to commits. Does Arcanist use `git ls-files -m` to check? Yes, Arcanist uses `git ls-files -m` to check whether there're local modifications. We might also contact phab developers asking to change it to `git diff --name-only HEAD --`. Is there a preferable way to get list of modified files and are this command intended to output the same results? 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. -- 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: Git issues with submodules
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 just `git diff --name-only` to compare the working tree and the index. Although in a script you'd probably want to use the plumbing `git diff-files` instead. Thanks for that. It's probably not worth fixing ls-files; I'll patch Arcanist to use diff-files instead. -- 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: Git issues with submodules
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 compare the worktree to the index (listing only unstaged changes), as Peff notes. Also apparently it became a known TODO for phabricator developers [1]. That was me :) So, after all is it expected behavior of ls-files or not and if not shall i report it as a separate thread? :) Actually, I doubt it's worth fixing ls-files. Your problem should be fixed when this is merged (hopefully in a few hours): https://github.com/facebook/arcanist/pull/121 Cheers. -- 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: Git issues with submodules
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 --name-only` will show changes to a submodule, only changes to that file which was changed in parent repo. - Make a git commit. It will not list changes to submodule as wll. - `git show HEAD` will show changes to both file from and parent repository (which is expected) and will also show changes to the submodule hash (which is unexpected i'd say). Thanks Sergey; I can confirm that this is a bug. For some reason, the `git add .` is adding the ignored submodule to the index. After that, $ git diff-index @ is not showing the ignored submodule. Let me see if I can dig through this in greater detail. -- 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: Git issues with submodules
Jens Lehmann wrote: But the question is if that is the right thing to do: should diff.ignoreSubmodules and submodule.name.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 might be ok here too). No, I think it's the wrong thing to do. We don't want to show false history. The ignore setting is documented to only affect diff output (including what checkout, commit and status show as modified). While I agree that this behavior is confusing for Sergey and not optimal for the floating branch model he uses, git is currently doing exactly what it should. And for people using the ignore setting to not having to stat submodules with huge and/or many files that behavior is what they want: don't bother me with what changed, but commit what I did change on purpose. We may have to rethink what should happen for users of the floating branch model though. I'd argue that the only reason the diff-family is blind is because the commit hash changes in the first place; if the hash didn't change (ie. floating submodules were represented by 0s hash or something), we wouldn't have this problem. The correct solution is to also make `git add' blind. -- 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: Re: Git issues with submodules
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. But after doing git add . the change to the submodule should be shown in status and diff regardless of the configuration. Yeah, I think this is a good direction. After that we can discuss whether add should add submodules that are tracked but not shown. How about commit -a ? Should it also ignore the change? Here, I think ignored submodules should behave like files matched by .gitignore: add should not add (`add -f` would be a good way to force it), and `commit -a` should also exclude 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: [PATCH v4 6/6] for-each-ref: avoid color leakage
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 order to show all information asked by the format string? (i.e. used_atom[] and need_tagged, respectively). It's mostly cruft carried over from my reset-color-after-each-token implementation. My severe distaste for global variables prevented me from looking for the simpler solution. Unlike need_tagged which asks is there any *refname that asks us to peel tags?, however, is the _last_ color:anything in the format string not 'reset'? depends on the order of appearance of atoms in the format string, so this needs to be done in a loop that scans the format string from left to right once at the very beginning, and we have a perfect place to do so in verify_format(). I should be shot for my laziness and lack of ingenuity. Yeah, verify_format() is a much better place to put the logic than populate_value(). So perhaps like this one on top? builtin/for-each-ref.c | 45 + 1 file changed, 21 insertions(+), 24 deletions(-) diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c index 04e35ba..5ff51d1 100644 --- a/builtin/for-each-ref.c +++ b/builtin/for-each-ref.c Thanks for taking the time to do this. And apologies for the laziness. -- 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 v4 0/6] Replacement for rr/for-each-ref-decoration
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 setup t6300 (for-each-ref): don't hardcode SHA-1 hexes for-each-ref: introduce %(HEAD) asterisk marker for-each-ref: introduce %(upstream:track[short]) for-each-ref: introduce %(color:...) for color for-each-ref: avoid color leakage Documentation/git-for-each-ref.txt | 14 +- builtin/for-each-ref.c | 93 +- t/t6300-for-each-ref.sh| 69 ++-- 3 files changed, 151 insertions(+), 25 deletions(-) -- 1.8.5.rc0.5.g70ebc73.dirty -- 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
