Jeff King wrote:
> If your intent is to let people stop disastrous pushes before they
> complete, I think there are two failings:
>
> 1. It does not tell very much about how the refspecs are expanded or
> what is going to happen. "git push --dry-run" gives a much more
> complete view of
Ramkumar Ramachandra wrote:
> 11920d2 (Add a built-in alias for 'stage' to the 'add' command,
> 2008-12-01) added a the 'git stage' command which simply calls
> cmd_add(). Since then, no references to it have been made anywhere on
> the internet; there i
Jeff King wrote:
> Leaving aside the transport API for a minute, you are always going to
> have this lack-of-information versus time problem. A refspec like ":"
> says nothing particularly useful, but it can only be expanded once
> contact is made with the other side (which is what takes time).
Ri
Junio C Hamano wrote:
> If we want to continue that tried-and-proven approach as a
> short-term fix, a patch may look like this.
I don't like this special-casing for show_branch at all. What is the
problem with skipping branch configuration altogether and going
straight to diff-ui configuration,
Santi Béjar wrote:
> If you think it's not worth testing the merge logic with remotes in
> {branches,remotes}-files you can consider just removing these remotes and
> the associated result files.
Thanks, but Junio has already decided to keep them and dropped these patches.
--
To unsubscribe from t
Vicent Marti wrote:
> $ time ../git/git pack-objects --all --stdout
> Counting objects: 3053537, done.
> Compressing objects: 100% (495706/495706), done.
> Total 3053537 (delta 2529614), reused 3053537 (delta 2529614)
>
> real0m36.686s
> user0
: Ramkumar Ramachandra
---
Documentation/config.txt | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1153585..5a10169 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -934,6 +934,9
Junio C Hamano wrote:
> One micronit (read: if you think the suggested change is a good
> idea, I could just locally amend it) is that it would read better
> and also easier to maintain to say
>
> These options control
>
> without "three". Both 'man' and 'html' output looked good.
Sure, a
SZEDER Gábor wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 912fb988..b68024c6 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1697,6 +1697,8 @@ _git_stage ()
>
> _git_statu
Ramkumar Ramachandra wrote:
>> + __git_complete_index_file "--with-tree=HEAD --cached --deleted"
>
> Might as well go all the way with "--cached --deleted --unmerged
> --others" no? What is the point of --with-tree=HEAD?
Ugh, --deleted doesn't wo
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 4
1 file changed, 4 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 6c3bafe..b51c9e3 100644
--- a/contrib/completion/git-completion.bash
+++ b
Hi,
An older iteration of [2/4] was just reviewed by SZEDER on the list.
[1/4] and [3/4] have been sent out in the past, but haven't been
picked up. [4/4] is new.
Thanks.
Ramkumar Ramachandra (4):
completion: complete rebase --edit-todo
completion: add completer for status
compl
Helped-by: SZEDER Gábor
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 27 +++
1 file changed, 27 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b51c9e3..278018f 100644
git-completion.zsh looks in various "default" locations for
git-completion.bash. During development, the location
$(dirname ${funcsourcetrace[1]%:*})/git-completion.bash
is the most obvious and up-to-date version. Push it up on the list of
locations.
Signed-off-by: Ramkumar R
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 14 ++
1 file changed, 14 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 278018f..f2959a7 100644
--- a/contrib/completion/git
The fixup-builtins script is only used by an unused remove-dashes target
in the Makefile: remove that along with the script.
Signed-off-by: Ramkumar Ramachandra
---
Makefile | 3 ---
fixup-builtins | 16
2 files changed, 19 deletions(-)
delete mode 100755 fixup-builtins
Jeff King wrote:
> This script was added in 36e5e70 (Start deprecating "git-command" in
> favor of "git command", 2007-06-30) with the intent of aiding the
> transition away from dashed forms. However, nobody is really working
> on that transition, and even if they did, this tool will proba
SZEDER Gábor wrote:
> Either way, why these five options? 'git rev-parse' has a lot more
> options than that.
We have to start somewhere, so I put in the options that I personally use.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ker
SZEDER Gábor wrote:
> -test_expect_success 'ls-files --delete' '
> +test_expect_success 'ls-files --deleted' '
> setup_absent &&
> test -z "$(git ls-files -d)"
While at it, change this to --deleted?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
SZEDER Gábor wrote:
> The code is OK, the rest of the function is pretty straightforward,
> but I think this line would warrant a sentence in the log message,
Okay.
Complete untracked pathspecs (--others), and overlay HEAD tree on
index (--with-tree=HEAD) to complete pathspecs that have been re
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-check-ignore.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-check-ignore.txt
b/Documentation/git-check-ignore.txt
index 8e1f7ab..d2df487 100644
--- a/Documentation/git-check-ignore.txt
+++ b
Sedat Dilek wrote:
> for my Linux-kernel build-script I am searching for a reliable check
> of getting the ***latest*** version.
$ git describe HEAD
If you want a sorted list of tags,
$ git for-each-ref --sort=taggerdate --format="%(refname:short)" refs/tags
Are you looking for something el
Alois Mahdal wrote:
> This [has been reported][1] to this list about half a year ago
> but with no response so I'm not even sure if it's been
> acknowledged as bug.
Yes, this is a bug. However, it is not at all easy to fix; so I would
recommend that you contribute a documentation patch/ failing
Sedat Dilek wrote:
> Sometimes I need to bisect a previous Linux-Next version.
>
> What I am doing is to have the latest Linux-v3.x.y(-rcX) as stable base.
>
> $ git checkout upstream
> $ git checkout -b Linux-v3.10-rc7 v3.10-rc7
>
> Afterwards I checkout the latest Linux-Next remote repository wit
Hi,
I figured that we should quickly read through git-multimail and give
it an on-list review. Hopefully, it'll educate the list about what
this is, and help improve the script itself.
Sources: https://github.com/mhagger/git-multimail
git_multimail.py wrote:
> #! /usr/bin/env python2
Do all di
John Keeping wrote:
> I have to say that I don't think this is a particularly useful review,
> you seem to have skipped huge portions of the code and spent a lot of
> time making us read your thought process rather than providing
> constructive feedback. What feedback there is mostly seems to be
>
Michael Haggerty wrote:
> On 07/02/2013 09:23 PM, Ramkumar Ramachandra wrote:
>> git_multimail.py wrote:
>>> #! /usr/bin/env python2
>>
>> Do all distributions ship it as python2 now?
>
> No, but nor is "python" always Python version 2.x (I beli
Junio C Hamano wrote:
> It is not "nobody is working on", but "it has already been used to
> help the transision and served its purpose, and is no longer is very
> useful for follow-up work because the majority of remaining matches
> it finds are false positives."
Please amend the commit message a
Junio C Hamano wrote:
> For --short and --symbolic-full-name, I have a feeling that we
> should make "describe" a front-end for these.
> [...]
All very good. If and when someone does write that functionality (I
personally find the task boring), we can remove this completer. Until
such a time, th
Ramkumar Ramachandra wrote:
>>> New-style class. I wonder why you suddenly switched.
>>
>> ? All of the classes are new-style classes.
>
> When you say class Foo:, aren't you declaring an old-style class by
> default in python2? New-style classes are those th
brian m. carlson wrote:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index bd13cc8..ca86a13 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1199,9 +1199,11 @@ X-Mailer: git-send-email $gitversion
> else {
> require Net::SMTP
ation.
***
Fix this by explicitly specifying SSL_verify_mode => SSL_VERIFY_NONE in
Net::SMTP::SSL->start_SSL().
Helped-by: brian m. carlson
Signed-off-by: Ramkumar Ramachandra
---
git-send-email.perl | 4 +++-
1 file changed, 3 insertions(+),
John Keeping wrote:
> I don't think this is really "fix", it's more plastering over the
> problem.
It defaulted to SSL_VERIFY_NONE before Net::SMTP::SSL was updated, and
the behavior hasn't changed now. The new version simply asks us to be
explicit about SSL_VERIFY_NONE, so we are aware about it.
ation.
***
Fix this by explicitly specifying SSL_verify_mode => SSL_VERIFY_NONE in
Net::SMTP::SSL->start_SSL().
Helped-by: brian m. carlson
Signed-off-by: Ramkumar Ramachandra
---
git-send-email.perl | 4 +++-
1 file changed, 3 insertions(+),
Use the ca-certificates in /etc/ssl/certs by default (that's where most
distributions put it). SSL_VERIFY_NONE is now the fallback mode.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt | 3 +++
Documentation/git-send-email.txt | 4
git-send-email
Hi,
Since nobody stepped up to write it, I wrote [2/2] myself. It will be
tested when I send out this series.
Thanks.
Ramkumar Ramachandra (2):
send-email: squelch warning from Net::SMTP::SSL
send-email: introduce sendemail.smtpsslcertpath
Documentation/config.txt | 3
Eric Sunshine wrote:
>> + $smtp_ssl_cert_path |=
>> "/etc/ssl/certs";
>
> You're going to want to use logical ||= here. Bitwise |= on a string
> does not do what you expect[1]:
>
> my $s = '/usr/local/etc/ssl/certs';
> $s |= '/etc/ssl/certs';
> print $s,
brian m. carlson wrote:
> You've covered the STARTTLS case, but not the SSL one right above it.
> Someone using smtps on port 465 will still see the warning. You can
> pass SSL_verify_mode to Net::SMTP::SSL->new just like you pass it to
> start_SSL.
Thanks. On a related note, how do I find out a
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-name-rev.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index 7cde4b3..94bded8 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation
scribe --contains @~1
v1.8.3~1
$ git describe --contains --all @~1
foom~1
In other words, --contains implies --tags in name-rev, which gives
precedence to tags; --all cancels that effect thereby giving precedence
to branches in the case of a tie.
Signed-off-by: Ramkumar Ramachandra
---
D
re pleasant and consistent. Obviously, hacking around
this problem in the prompt script is the Wrong thing to do.
Thanks.
Ramkumar Ramachandra (3):
name-rev: fix assumption about --name-only usage
name-rev: strip trailing ^0 in when --name-only
name-rev doc: rewrite --stdin paragraph
Do
not suffer from this defect). Fix this.
Signed-off-by: Ramkumar Ramachandra
---
builtin/name-rev.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 37207a9..8ba5d72 100644
--- a/builtin/name-rev.c
+++ b/builtin/name-rev.c
When GIT_PS1_SHOWCOLORHINTS is turned on, there is no need to put a
detached HEAD within parenthesis: the color can be used to discriminate
the detached HEAD.
Signed-off-by: Ramkumar Ramachandra
---
For cuteness :)
contrib/completion/git-prompt.sh | 5 -
t/t9903-bash-prompt.sh
Duy Nguyen wrote:
> Ram, are you still interested in the awesome branch series?
Yep, but it got stalled due to lack of reviewer-interest :/
I'm a bit under the weather at the moment, but it's good to see that
you're back: let's finish this soon.
>>> Perhaps we need
>>>
>>> git cat-file --batch
Junio C Hamano wrote:
> "git name-rev" is supposed to convert 40-hex object names into
> strings that name the same objects based on refs, that can be fed to
> "git rev-parse" to get the same object names back, so
>
> $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --stdin
> 8af06057d0c31a24
Junio C Hamano wrote:
> But I do not think "name-rev" is limited
> to commits, in the sense that you would see this:
>
> $ git rev-parse v1.8.3 v1.8.3^0 | git name-rev --stdin
> 8af06057d0c31a24e8737ae846ac2e116e8bafb9
> edca4152560522a431a51fc0a06147fc680b5b18 (tags/v1.8.3^0)
>
> The s
Junio C Hamano wrote:
> With this on top of the other patches in this series, you would get:
>
> $ git describe --contains $(git rev-parse v1.8.3 v1.8.3^0)
> v1.8.3
> v1.8.3
>
> while you can still differentiate tags and the commits they point at
> with:
>
> $ git name-rev --refs=ta
Junio C Hamano wrote:
>> would get name-rev to print output in the same format as describe,
>>
>> $ git describe --contains --all v1.8.3~1
>> tags/v1.8.3~1
>>
>> would not strip the leading "tags/".
>
> If you _know_ v1.8.3 does not appear outside "tags/", this does look
> inconsistent, but I d
Duy Nguyen wrote:
> The short/long naming is the least I worry about. We could add long
> names to pretty specifiers. The thing about the last attempt is, you
> add some extra things on top elsewhere, but format_commit_item code
> may need to be aware of those changes, which are not obvious when
>
Junio C Hamano wrote:
> +1; I find red on many terminal emulators to be too dark to tell,
> especially in a small font, from black myself.
It's a matter of taste anyway. I hope everyone's not going colorblind
from writing too much C89 and Bourne shell ;)
Eduardo R. D'Avila wrote:
> I think color
Duy Nguyen wrote:
> - We might overlook something. The best way to avoid missing is
> finish and verify it.
> - A promise to do things later could happen really late, or never
> happens. As you are sastisfied with the functionality you have less
> motivation to clean the code. Meanwhile the maint
y
are not handled.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
pretty.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/pretty.c b/pretty.c
index 0063f2d..816aa32 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1156,6 +1156,9 @@ s
) and %<(*)
for-each-ref: improve responsiveness of %(upstream:track)
Ramkumar Ramachandra (7):
tar-tree: remove dependency on sq_quote_print()
quote: remove sq_quote_print()
pretty: limit recursion in format_commit_one()
for-each-ref: introduce %(HEAD) marker
for-each-ref: introduce %(up
calls show_ref() in
a loop to avoid cluttering up cmd_for_each_ref() with the task of
initializing/freeing the strbuf.
[rr: commit message]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 55 --
1
) for the purpose of printing argv for $GIT_TRACE. Today, we
achieve this using trace_argv_printf() -> sq_quote_argv() ->
sq_quote_buf(), which ultimately fills in a strbuf.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
quote.c | 17 -
quote.h
ormat code, they are advised to migrate to --pretty.
[rr: documentation]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 23 ++-
builtin/for-each-ref.c | 72 +-
t/t6300-for-each-ref
,
convert the *_quote_print functions and callers to *_quote_buf.
[rr: commit message, minor modifications]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 13 +
quote.c| 44
the substitution). The callback should return
the length of the original string parsed, and optionally set
placeholder_subst.
[rr: commit message, minor modifications]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
commit.h | 8
pretty.c |
help of format().
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pretty.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/pretty.c b/pretty.c
index 095e5ba..0063f2d 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1061,7 +1061,8 @@ stati
Currently, there is exactly one caller of sq_quote_print(), namely
cmd_tar_tree(). In the interest of removing sq_quote_print() and
simplification, replace it with an equivalent call to sq_quote_argv().
No functional changes intended.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn
)%(refname:short)%C(reset)
to display a red asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
2 files changed, 15 insertions(+)
database access, then it will fill all atoms that need odb.
Which is not a bad thing. We don't want to access odb once at sorting
phase and again at display phase.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 49 ++
am)'. This is important because verify_format populates
used_atom, which get_value() and populate_value() later rely on.
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 15 +--
pretty.c | 4
2 files changed, 13
might like to define their own builtins in
the future.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
---
commit.h | 1 +
pretty.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/commit.h b/commit.h
index ced7100..331a2db 100644
--- a
is automatically stripped and
ignored. Separator semantics are not configurable (yet).
2. No built-in formats are available. The ones specified in
pretty-formats (oneline, short etc) don't make sense when displaying
refs anyway.
Signed-off-by: Ramkumar Ramachandra
g format in for-each-ref:
%C(green)%(refname:short)%C(reset)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with upstream, and error out
when used with anything else.
Signed-off-by: Ramkumar Ramachandra
Signed-off-by: Nguyễn Thái Ngọc Duy
--
rs, not ones coming from pretty.c). They calculate
the best width for the %(fieldname), ignoring ansi escape sequences if
any.
[rr: documentation]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 7 +++
builtin/fo
Junio C Hamano wrote:
> $ git describe $(git rev-parse v1.8.3)
> v1.8.3
> $ git describe --contains $(git rev-parse v1.8.3)
> v1.8.3^0
This is a correct observation, and I've already submitted the correct
fix: "name-rev: strip trailing ^0 in when --name-only".
> $ git describe
Jeff King wrote:
> That does O(n log n) offset comparisons, and profiling shows
> that we spend most of our time in cmp_offset. However, since
> we are sorting on a simple off_t, we can use numeric sorts
> that perform better. A radix sort can run in O(k*n), where k
> is the number of "digits" in o
Jeff King wrote:
> +If `--batch` or `--batch-check` is given, `cat-file` will read objects
> +from stdin, one per line, and print information about them.
> +
> +You can specify the information shown for each object by using a custom
> +``. The `` is copied literally to stdout for each
> +object, wi
Jeff King wrote:
> git rev-list --objects HEAD |
> git cat-file --batch-check='%(objectsize) %(text)'
If anything, I would have expected %(rest), not %(text). This atom is
specific to commands that accept input via stdin (i.e. not log, f-e-r,
branch, or anything else I can think of).
Also, t
Torsten Bögershausen wrote:
> /usr/bin/perl -MIO::Socket::SSL -e 'print "$IO::Socket::SSL::VERSION\n";'
> 1.22
This is ancient! (I have 1.84). Is it not possible to do an
ssl-verify-peer in older versions (is it exported as something else)?
The older versions don't display the warning anyway, an
brian m. carlson wrote:
> I didn't stick the require in the eval because git-send-email will fail
> in this case anyway if you don't have it, since Net::SMTP::SSL requires
> it. Let me know if you want a patch for this on top of the existing two
> in this series and I'll provide one.
Yeah, that'd
Junio C Hamano wrote:
> Ramkumar, as you will still be the primary author of the resulting
> commit, I tentatively added a line for your sign-off even though you
> haven't signed off _this_ version yet, so that I would not forget.
> If this version looks good, please tell us you would.
Yeah, it se
Allan Acheampong wrote:
> I could write a script with for each in but thats way too much hassle
$ git for-each-ref --format="%(refname)" refs/remotes/origin/ | sed
's/refs\/remotes\/origin\///;/HEAD\|master/d' | xargs git checkout -b
(completely untested ofcourse)
Do you see what the problem i
Hi,
I'm often work on small topic branches, and find myself doing this quite often:
# on branch master
$ git checkout um-build
$ git rebase master
This is horribly inefficient; the first operation takes a _really_
long time to complete, since master updates itself very often and I
have to
Hi,
Many of my ideas turn out to be really stupid, and I need to throw
away my feature branch. So, I find myself doing this often:
# on branch menuconfig-jk
$ git checkout master
$ git branch -D
# er, what was the branch name again?
$ git checkout -
# Ah
$ git checkout master
$ g
Sebastian Staudt wrote:
> Isn't this what you want?
>
> $ git rebase master um-build
Ha, yes. Sorry about the stupidity.
--
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/majordom
Ramkumar Ramachandra wrote:
> Sebastian Staudt wrote:
>> Isn't this what you want?
>>
>> $ git rebase master um-build
>
> Ha, yes. Sorry about the stupidity.
Hm, I'm not entirely sure how to optimize the codepath to eliminate
the checkout. It seems to be a
Ramkumar Ramachandra wrote:
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 0039ecf..7405d9a 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
Er, sorry. I think it suffices to check that $branch_name equals
HEAD, for this optimization.
--
To unsubscribe from this list: s
Damn it: checkout doesn't get executed at all because the $mb = $onto
condition fails; I was looking in the wrong place. It's format-patch
and am that are slowing things down terribly. Has anyone looked into
stripping out the dependency? Why is cherry-pick deficient?
My current workaround is to
Andreas Schwab wrote:
> Ramkumar Ramachandra writes:
>
>> # er, what was the branch name again?
>> $ git checkout -
>
> You could take a look in the reflog.
Yeah, or use the @{-N} revision to do that for me. My scripted
version is essentially:
test "true&qu
Junio C Hamano wrote:
> Did you know that the general way to spell the branch previously you
> were on is "@{-1}" and "checkout -" is an ugly special case that is
> possible only because "checkout" does not happen to take a "-" as a
> valid argument that means something else (like the more usual "r
Junio C Hamano wrote:
> git branch -t "$branchname" "origin/$branchname"
A couple of notes here:
1. I use git branch -u personally. Why the -t variant?
2. Don't we auto-track? (or is that only on checkout)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
Junio C Hamano wrote:
> You would at least need "xargs -n 1" for the produced command line
> to make any sense, and it is wasteful to actually check out each
> and every branch to the working tree only to create it.
Right. xargs -n 1, git branch, and refname:short.
--
To unsubscribe from this lis
Junio C Hamano wrote:
> That limits the context we could use "-" and we cannot consistently
> use it everywhere. I find _that_ ugly from the "design cleanliness"
> point of view.
Right, noted.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@v
Benoit Sigoure wrote:
> diff --git a/compat/unsetenv.c b/compat/unsetenv.c
> index 4ea1856..addf3dc 100644
> --- a/compat/unsetenv.c
> +++ b/compat/unsetenv.c
> @@ -1,5 +1,10 @@
> #include "../git-compat-util.h"
>
> +#ifdef __APPLE__
> +// On OS X libc headers don't define this symbol.
> +extern c
Ondřej Bílka wrote:
> http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
Just run a sed 's|http://marc.theaimsgroup.com|http://marc.info|', and
submit the resulting patch.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Ondřej Bílka wrote:
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 7fe0bff..9f29bb2 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -1137,7 +1137,7 @@ int cmd_checkout(int argc, const char **argv, const
> char *prefix)
> * 3) git checkout []
>
Junio C Hamano wrote:
> * mv/merge-ff-tristate (2013-07-02) 1 commit
> (merged to 'next' on 2013-07-09 at c32b95d)
> + merge: handle --ff/--no-ff/--ff-only as a tri-state option
Sorry I didn't notice sooner, but I was confused by the second test
title this added:
test_expect_success 'option --
uniformly, just like config.txt does.
Signed-off-by: Ramkumar Ramachandra
---
Candidate for maint?
Documentation/git-config.txt | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 34b0894
case of a ranged pick, as a 'git
reset' will fail to remove $GIT_DIR/sequencer, failing a subsequent
cherry-pick or revert. Change the advice to:
git cherry-pick --abort
Signed-off-by: Ramkumar Ramachandra
---
Another candidate for maint?
I'd also really like to squelch this
Jeff King wrote:
> Hmm. I don't think I've run across this message myself, so perhaps I do
> not understand the situation.
It's very simple.
# on branch master
$ git checkout -b test
$ git cherry-pick master
$ ls .git/sequencer
# missing
In the pseudo multi-pick case (I say "pseudo" be
Jeff King wrote:
> Ah. I don't mind improving the message in the meantime, but it sounds
> like this is a deficiency in sequenced cherry-pick that needs addressed
> eventually.
I'm especially irked by how slow rebase--am is, and want to replace it.
--
To unsubscribe from this list: send the line "
Jeff King wrote:
> builtin/commit.c | 25 ++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
Overall, highly inelegant. The single-commit pick has been special
cased only because we needed to preserve backward compatibility: I
would hate for the detail to be user-visibl
Jonathan Nieder wrote:
>> Your patch is just swapping out "git reset" for "cherry-pick --abort",
>> so I think that is a good improvement in the meantime.
>
> Um, wasn't the idea of the original message that you can run "git
> reset" and then "git cherry-pick --continue"?
No, and I don't know wher
Hi,
I noticed a regression in the latest master, and I've been trying to
debug it for 30 minutes now. I'm still clueless about the root cause,
but I'll list whatever I found so far:
I suddenly noticed that I wasn't able to commit to a certain
repository with submodules anymore. This was because
Ramkumar Ramachandra wrote:
> *scratches head*
Just took a much-needed shower and came back. It was trivial to find.
$ git log v1.8.3.4.. -- path.c
e02ca72 (path.c: refactor relative_path(), not only strip prefix,
2013-06-25) is the offender.
--
To unsubscribe from this list: send the l
Ramkumar Ramachandra wrote:
> e02ca72 (path.c: refactor relative_path(), not only strip prefix,
> 2013-06-25) is the offender.
The problem is the callsite in setup.c:setup_work_tree(). When
relative_path() is called with
"/home/artagnon/dotfiles/.git/modules/.elisp/flx" and
Fredrik Gustafsson wrote:
> When I hear submodules
The only reason this bug has something to do with submodules is
because of the relative path in the gitfile (although I'm yet to
corner the exact issue). Otherwise, it doesn't exercise any new code
in submodule.c/ git-submodule.sh.
--
To unsubscr
201 - 300 of 1623 matches
Mail list logo
