Here: put this at the end of the series and autosquash.
-- 8< --
From: Ramkumar Ramachandra
Date: Thu, 30 May 2013 01:29:59 +0530
Subject: [PATCH] fixup! HEAD~2
Signed-off-by: Ramkumar Ramachandra
---
builtin/push.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/buil
Junio C Hamano wrote:
>> Some Git commands expect to be in the top level directory (e.g. git blame).
>
> "Git" things we can fix [*1*], but more importantly, build structure
> of many project may require you to go up to the top to build the
> whole thing, so being able to get a relative path to the
Felipe Contreras wrote:
> We should probably also add typical shortucts:
>
> d = diff
> l = log
> f = fetch
> p = push
> r = reset
> ci = commit
> rb = rebase
> co = checkout
> st = status
> pi = cherry-pick
> mt = mergetool
Terrible idea. We'll be eating up more subcommands that the user
cannot
Duy Nguyen wrote:
> It's because you don't pad enough spaces after %(refname:short) so the
> starting point of %(upstream:short) on each line is already unaligned,
> I think.
Yeah, my stupidity. I really meant %>|(30), and that works fine.
--
To unsubscribe from this list: send the line "unsubscr
Junio C Hamano wrote:
> The whole point of show-cdup is that people (especially those in
> java land) bury themselves in a hierarchy so deep that it is not
> feasible to tell "Go count the hierarchy and prefix that many ../
> yourself" to them.
Ah.
> The answer to "we cannot count ../" issue is "
Bráulio Bhavamitra wrote:
> Agree, these aliased should work as a fallback or as an automatic short
> version
Making builtins override'able is also a terrible idea. It opens doors
to potential bugs we don't want to deal with. Simple example:
am = log -1
log = am -3
--
To unsubscribe from
Jonathan Nieder wrote:
> That's detectable and could be made to error out, so it's not too bad.
Sure it's possible, but I'm arguing about whether it's worth the
effort. There can be loops like a -> b -> c -> d -> e -> a. Given
that nobody has even bothered to get git to print an error message
wh
Let's do one more review.
Felipe Contreras wrote:
> diff --git a/contrib/related/git-related b/contrib/related/git-related
> new file mode 100755
> index 000..1b9b1e7
> --- /dev/null
> +++ b/contrib/related/git-related
> @@ -0,0 +1,120 @@
> +#!/usr/bin/env ruby
> +
> +# This script finds peopl
Thomas Rast wrote:
> diff --git i/sha1_name.c w/sha1_name.c
> index 5ea16ff..a07558d 100644
> --- i/sha1_name.c
> +++ w/sha1_name.c
> @@ -538,7 +538,6 @@ static int get_sha1_basic(const char *str, int len,
> unsigned char *sha1)
> "back to %s.", len, str,
>
Alex Bennée wrote:
>>time /usr/bin/git --no-pager
> traversed 223 commits
>
> real0m4.817s
> user0m4.320s
> sys 0m0.464s
I'm quite clueless about why it is taking this long: I think it's IO
because there's nothing to compute? I really can't trace anything
unless you can reproduce it o
Felipe Contreras wrote:
> What's your objective? Block this patch from ever going in?
>
> Not a single one of these comments makes a difference at all, all of
> them can wait until after the patch is merged, many of them are a
> matter of preferences, and some of them have already been addressed as
Alex Bennée wrote:
> And through my "special" repo:
>
> 41.58% git libcrypto.so.1.0.0 [.] sha1_block_data_order_ssse3
> 33.62% git libz.so.1.2.3.4 [.] inflate_fast
> 10.39% git libz.so.1.2.3.4 [.] adler32
> 2.03% git [kernel.kallsyms] [k] clear_page_c
>
> I'm not sure w
Alex Bennée wrote:
> 15:50 ajb@sloy/x86_64 [work.git] >time git log --pretty=oneline | wc -l
> 24648
>
> real0m0.434s
> user0m0.388s
> sys 0m0.112s
>
> Although it doesn't take too long to walk the whole mainline history
> (obviously ignoring all the other branches).
Damn, non-starter.
Matthieu Moy wrote:
> Michael Campbell writes:
>> I have my global git config pager set to 'cat', but when I do a "git
>> help ", it still uses a pager. This is especially irksome in
>> emacs shell buffers, where I am most of the time. I know I can do a
>> M-x man -> git-, but wondered if this w
Matthieu Moy wrote:
> I find it a bit weird that Git sets the configuration for external
> commands, but it may make sense. No strong opinion here.
I don't mean a setenv() kind of thing: how would we unset it after
that? Perhaps something like execvpe(), passing in the environment as
an argument?
Thomas Rast wrote:
> diff --git a/commit.c b/commit.c
> index 888e02a..00e8d4a 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -31,8 +31,12 @@ static struct commit *check_commit(struct object *obj,
> struct commit *lookup_commit_reference_gently(const unsigned char *sha1,
>
Felipe Contreras wrote:
> I was going to make these stylistic changes to make you happy, but
> then I realized the only that does really make sense is to change msg
> = nil to msg = false, and it's not even worth to waste a thought on
> changes like that.
We don't have existing Ruby code in git.gi
Felipe Contreras wrote:
> When a reviewer reaches that point, (s)he usually says: other than
> cosmetic preferences: Reviewed-by: me.
Yes, you can have a Reviewed-by from me if you want.
And yes, it is appropriate not to CC me on v8 and v9, since I have no
further comments.
--
To unsubscribe from
Junio C Hamano wrote:
> [...]
I agree with everything else, and made changes accordingly.
> This transformation limits the set of filepairs to those
> that change specified strings between the preimage and the
> postimage in a certain way.
Definitely good.
> -S a
the patch text)
Inputs-from: Phil Hord
Co-authored-by: Junio C Hamano
Signed-off-by: Ramkumar Ramachandra
---
Documentation/diff-options.txt | 38 +++
Documentation/gitdiffcore.txt | 45 +-
2 files changed, 57 insertions(+
reference
Since the error has nothing to do with "log-grep", change the -G and -S
error messages to say "invalid regex".
Signed-off-by: Ramkumar Ramachandra
---
diffcore-pickaxe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/diffcore-pickaxe.c b/d
This means that it [-can-]{+will+} detect in-file (or what
rename-detection considers the same file) [-moves.-]{+moves, which is noise.+}
The
implementation runs diff twice and greps, and this can be quite
expensive.
When `-S` or `-G` are used without `--pickaxe-all`, only filepairs
that match th
Jeff King wrote:
> I wonder if simply sticking
> the reflog entries into a big GRAVEYARD reflog wouldn't be a great deal
> simpler and accomplish the "keep deleted reflogs" goal, which is what
> people actually want.
Exactly what I was thinking when I read your proposal. What is the
point of havi
Jeff King wrote:
> Why don't the branch names have significance? If I deleted branch "foo"
> yesterday evening, wouldn't I want to be able to say "show me foo from
> 2pm yesterday" or even "show me all logs for foo, so that I can pick the
> useful bit from the list"?
Oh, I misunderstood then. I d
Johannes Sixt wrote:
> +test_ln_s_add () {
> + if test_have_prereq SYMLINKS
> + then
> + ln -s "$1" "$2" &&
> + git update-index --add "$2"
> + else
> + printf '%s' "$1" >"$2" &&
> + ln_s_obj=$(git hash-object -w "$2") &&
> +
Nicolas Richard wrote:
> - A '*' can be used both in src and dest, and it matches any name,
> including subdirectories, but not partial names (i.e. refs/heads/foo*
> is invalid).
> - multiple fetch lines can be given in .git/config, each of them will be
> obeyed
>
> These are probably obvious
Johannes Sixt wrote:
> # - Use test_ln_s instead of "ln -s x y" when y has been added as a
> # symbolic link entry earlier.
Ah, sorry I skipped over the comments.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
Sitaram Chamarty wrote:
> I think I'd have to be playing with *several* branches simultaneously
> before I got to the point of forgetting the branch name!
Yeah, I work on lots of small unrelated things: the patch-series I
send in are usually the result of few hours of work (upto a few days).
I ke
Felipe Contreras wrote:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 1c35eef..2ce4f7d 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -427,14 +427,8 @@ __git_refs ()
>
mented. 'git format-patch' is used
without pathspec filtering most of the time, and it makes sense to
provide sensible completions using __git_refs.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Add support for completing 'git blame'. List only the common short
options.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/comp
making any functional changes.
Remove __git_complete_file, as it has no other callers.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/cont
Add support for completing 'git rev-parse'. List only the options that
are likely to be used on the command-line, as opposed to scripts.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff --git
'. No
functional changes.
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index f46964d..8d70c30 10064
Another lazy Sunday afternoon. All of these are trivial.
Thanks.
Ramkumar Ramachandra (6):
prompt: don't scream continuation state
completion: add common options for rev-parse
completion: add common options for blame
completion: correct completion for format-patch
completion: cl
-by: Ramkumar Ramachandra
---
contrib/completion/git-prompt.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index eaf5c36..f99d1f2 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib
Felipe Contreras wrote:
> This breaks 'git format-patch master..'.
Oh, ouch.
> Moreover, this is a perfectly fine usage of 'git format-patch':
>
> % git format-patch --full-diff master..fc/remote/hg-next --
> contrib/remote-helpers/git-remote-bzr
Never mind then. Drop this patch.
--
To unsubscr
They haven't been touched in six years.
Signed-off-by: Ramkumar Ramachandra
---
Another candidates for removal: contrib/blameview (6 years); anoyone
using this?
contrib/continuous/cidaemon| 503 -
contrib/continuous/post-receive-cin
Junio C Hamano wrote:
>> Why do a poor-man's version of --pickaxe-all here, when the last
>> paragraph already does justice to this?
>
> The point of the first paragraph is to serve to help both:
My question pertains to whether or not the explanation of
--pickaxe-all can wait till the last paragra
Thomas Rast wrote:
> Is this the first time we introduce completion (I guess you could call
> it "help") for short options? I only did a quick search for /-. -/ but
> it certainly seems that way.
Yeah. We generally prefer the long-form equivalents while doing
completions, but these blame options
Thomas Rast wrote:
> Do you have other ways of distinguishing the branch and the state?
> Colors? I'm a bit too lazy to check. Perhaps it could be made to only
> use caps if not in colored mode?
Currently, no. See git-prompt.sh:401, 403, 409; we don't have a
separate color for $r. I didn't in
Jiang Xin wrote:
> It will be nice to add this pretty formatter automatically when run
> `git reflog` in verbose mode. And in order to support verbose mode, add
> new flag "verbose" in struct rev_info.
Sorry I missed earlier revisions of this patch. Generally speaking,
"verbose" is a bad way to c
From: 乙酸鋰
Signed-off-by: Ramkumar Ramachandra
---
乙酸鋰: please read Documentation/SubmittingPatches and submit a
patch yourself next time. I've done it for you this time as an
example.
Junio: please (add-hook 'text-mode-hook 'flyspell-mode) to your
.emacs to c
Jeff King wrote:
> It seems silly to argue about output formats when we are writing a
> prompt in a convenient Turing-complete scripting language already.
> What about something like:
Could you have a look at __git_ps1_colorize_gitstring from
rr/zsh-color-prompt in pu? In the general case, wouldn
Junio C Hamano wrote:
> I think this is the same as 5/6 and better explained in a single
> patch, as the rationale is the same: these commands can all take the
> usual revs and then paths, so using misnamed complete_FILE helper is
> wrong.
>
> Mind if I squashed them together?
I'm okay with what y
nt_context with callback
pretty: allow passing NULL commit to format_commit_message()
for-each-ref: get --pretty using format_commit_message
for-each-ref: teach verify_format() about pretty's syntax
for-each-ref: introduce format specifier %>(*) and %<(*)
for-each-ref: improve r
,
convert the *_quote_print functions and callers to *_quote_buf.
[rr: commit message, minor modifications]
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 13 +
quote.c| 44 ++--
quote.h| 6 +++---
3
am)'. This is important because verify_format populates
used_atom, which get_value() and populate_value() later rely on.
Signed-off-by: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 15 +--
pretty.c | 4
2 files changed, 13 insertions(+), 6 deletions(-)
diff -
help of format().
Signed-off-by: Ramkumar Ramachandra
---
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 @@ static size_t parse_padding_placeholder(struc
y
are not handled.
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 @@ static size_t format_commit_one(struct s
format:" 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
---
Docu
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
---
builtin/tar-tree.c
might like to define their own builtins in
the future.
Signed-off-by: Ramkumar Ramachandra
---
commit.h | 1 +
pretty.c | 25 +
2 files changed, 26 insertions(+)
diff --git a/commit.h b/commit.h
index 04bd935..48424c9 100644
--- a/commit.h
+++ b/commit.h
@@ -113,6 +113,7
) 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
---
quote.c | 17 -
quote.h | 2 --
2 files changed, 19 deletio
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 works with upstream, and errors
out when used with anything else.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-eac
ormat code, they are advised to migrate to --pretty.
[rr: documentation]
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 22 -
builtin/for-each-ref.c | 67 --
2 files changed, 85 insertions(+), 4 deleti
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: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 49 +
1 file
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: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 7 +++
builtin/for-each-ref.c
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: Ramkumar Ramachandra
---
builtin/for-each-ref.c | 55 --
1 file changed, 35 insertions(+), 20
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: Ramkumar Ramachandra
---
commit.h | 8
pretty.c | 25 +
2 files changed, 33 inserti
)%(refname:short)%C(reset)
to display a red asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documen
Duy Nguyen wrote:
> Nobody should ever parse these output
> with scripts. The color can be generated from color.branch.*.
How do we implement color.branch.(current|local|remote|plain)? In the
current code, we take a crude approach by hand-constructing argc, argv
strings and passing it to cmd_for_
Duy Nguyen wrote:
> I'm still hung up one the detached HEAD thing. It's a bit quirky to
> put in for-each-ref, but for-each-ref can't truly replace branch
> --list until it can display detached HEAD. But I think we can finish
> this part and get it in first. Should be useful for some people
> alrea
Duy Nguyen wrote:
> I mentioned it before and I do it again. This is not optimal.
Yeah, I'll attempt to fix this, but it's not urgent.
> But I guess it's ok in this
> shape unless you run this over hundreds of refs.
Oh, you can run over a hundred refs just fine, for scripting purposes;
but why w
David Lang wrote:
> Perl use may or may not be declining (depending on how you measure it), but
> are you really willing to take on the task of re-writing everything that's
> in Perl into another language and force all developers of scripts to learn
> that other language? what's the ROI of this?
L
Johannes Schindelin wrote:
> My initial reaction, too. It was hard enough to get Perl included with Git
> for Windows (because of that pesky Subversion dependency).
Nevertheless, we had to do it, and we did it. We will do it again, if
we get enough important code written in Ruby.
> As you can se
Greg Troxel wrote:
> It's not about what I want. It's about making choices that affect other
> people, and trying to find a plan that will be overall reasonable;
> that's the essence of stewardship in packaging. Compiling for just
> myself is far easier.
Have you asked the SBCL or Google-Chrome
is in bold
This happens because the corresponding text in fetch-options.txt is
"refs/tags/*:refs/tags/*"; asciidoc renders the text between the two
asterisks in bold. Escape the first asterisk, correcting the text.
Signed-off-by: Ramkumar Ramachandra
---
Candidate for maint?
[+CC: jc, jk]
Leandro Lucarella wrote:
> I changed branch.master.remote to upstream and set
> branch.master.pushremote to origin, but when I do I git push I get an
> error:
>
> $ git push --dry-run --verbose
> fatal: You are pushing to remote 'origin', which is not the upstream of
> your current b
David Lang wrote:
> Well, Felipe is saying that Perl is dieing and we should re-write everything
> that exists in Perl to Ruby.
I don't agree with that opinion. More generally, I think the entire
discussion on what _should_ or _should not_ be done is rubbish. What
_will_ and _will not_ happen de
Junio C Hamano wrote:
> How about this?
Looks 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
Johannes Schindelin wrote:
> On Fri, 7 Jun 2013, Ramkumar Ramachandra wrote:
>> Johannes Schindelin wrote:
>> > My initial reaction, too. It was hard enough to get Perl included with Git
>> > for Windows (because of that pesky Subversion dependency).
>>
>> Ne
Junio C Hamano wrote:
> So at least for now, the conclusion is to take approach #1, i.e.
> somebody who finds "related" a good addition rewrites it in Perl to
> promote it out of contrib/ once the design issues settle (of course
> it is still a possibility that no such volunteer appears).
We'll th
Ramkumar Ramachandra wrote:
> Add support for completing 'git rev-parse'. List only the options that
> are likely to be used on the command-line, as opposed to scripts.
Can we get this patch? I use git rev-list quite a lot, and want completion.
--
To unsubscribe from this lis
Junio C Hamano wrote:
> This shows the "triangular" support in 1.8.3 is only half-finished;
> the other half was discussed a few weeks ago ($gmane/224604)
I intentionally omitted that detail, because it is not directly
related to this bug. We have to fix the existing simple and upstream,
whether
Leandro Lucarella wrote:
> Thanks for the detailed explanations, I think this would cover my use
> case. Just for clarification, here are some more details on this use
> case, which I think is becoming very popular among github users.
> We have a "blessed" repository (upstream in my case) and only
SZEDER Gábor wrote:
> Well, people out there might have completion scriplets for their
> aliases or custom git commands which use __git_complete_file().
> Removing this function would break those scripts.
What is the advantage of using __git_complete_file() over
__git_complete_revlist_file()? Isn
SZEDER Gábor wrote:
> the one at the top because
> of the reasons given in $gmane/226272
Sorry about the delay: I went to sleep for a couple of days :P
> the one at the bottom because
> of the misleading commit message (__git_complete_file() always
> completed refs first as part of the ref:file n
Leandro Lucarella wrote:
> I might try to just switch to current, I feel more comfortable with
> simple because I feel is safer to explicitly set the upstream branch,
> but is true that most of the time is not necessary.
Be more experimental! Use the lesser-known features, and tell us
about break
Matthieu Moy wrote:
> Reading Git for Windows's FAQ
> ( https://github.com/msysgit/msysgit/wiki/Frequently-Asked-Questions ),
> it seems rather clear that the TODO-list is already long to have a
> correct Perl support (I'm quite admirative of the work done already).
> The POSIX guys shouldn't move
Matthieu Moy wrote:
> I think it should be "the Git for Windows community", and my feeling is
> that the community developing Git for POSIX systems is far more active
> than the one making it work for Windows (although we may now have more
> windows users than unix users).
If I can be excused for
Matthieu Moy wrote:
> Visual Studio now has official Git support from MS (based on libgit2 if
> I understood correctly). That's cool, but not a reason to kill msysgit
> IMHO ;-).
Oh, I'm not interested in killing anything. If people want msysgit,
they will work on it: I'm nobody to say otherwise.
Junio C Hamano wrote:
> "git log -Gcomplete_file -p contrib/completion" found this one:
>
> Now I do not recall suggesting it, and you (and I today after 2
> years) may disagree with the rationale, but at least we can read
> what was the "intended" meaning, I think.
Having spent so much time docum
77c130 (completion: clarify ls-tree, archive, show completion,
2013-06-02) removed __git_complete_file () because it had no callers
left in the file. However, to avoid breaking user scripts that may
depend on this, add it back as a deprecated alias.
Signed-off-by: Ramkumar Ramachandra
Felipe Contreras wrote:
>> Also we heard from no regular/high-value reviewers
>> that they feel comfortable reviewing additions in Ruby.
>
> Correction; *current* regular/high-value reviewers.
Correct. The opinions of inactive community members and
non-contributors are less useful.
> We could ch
Felipe Contreras wrote:
> This is fine by me, but at some point we need to decide how we should
> prefix the functions that are supposed to be used by external scripts.
Yeah, I thought __ meant "internal" :/
> Also, maybe we should start adding '# TODO remove in v2.0' so we
> remember to do that
Felipe Contreras wrote:
> While at it, why not re-evaluate the whole msysgit approach? I bet we
> don't need a whole separate project just to create a Windows
> installer. I've written Windows installers before, it's very easy to
> do from Linux.
Yeah, taking the pain out of msysgit packaging woul
Ramkumar Ramachandra wrote:
> commit a lot of good ruby code to contrib*
Oh, by the way: I have a project idea. There's this really popular
project called hub[1] that has an implementation of the GitHub API in
ruby. Unfortunately, it's a terrible piece of software because it
cre
SZEDER Gábor wrote:
> because nowadays __git_complete_file() is a wrapper around
> __git_complete_revlist_file().
What? It was never anything different from a poorly-named alias for
__git_complete_revlist_file(). You have already agreed that
__git_complete_file() is a horrible name, so why not d
Felipe Contreras wrote:
> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh
> index a5e69f3..ff370a3 100755
> --- a/t/t3420-rebase-autostash.sh
> +++ b/t/t3420-rebase-autostash.sh
> @@ -71,8 +71,7 @@ testrebase() {
> test_must_fail git rebase$type related-onto-b
Felipe Contreras wrote:
> sequencer.c => builtin/sequencer.c | 160 +---
> sequencer.h => builtin/sequencer.h | 4 -
Why exactly? The plan was to unify continuation semantics, and get
all the continuation-commands to use the sequencer. That clearly
hasn't materi
Duy Nguyen wrote:
>> until libgit.a == libgit2. Done.
>
> Read up about the introduction of libgit2, why it was created in the
> first place instead of moving a few files around renaming libgit.a to
> libgit2.a. Unless you have a different definition of "==" than I do.
As far as I know, there was
Felipe Contreras wrote:
> Yes you do. The rest of the tests expect that the previous rebase has
> been aborted.
>
> In fact, all the tests depend on the previous test finishing
> correctly, which is not the way tests should be written.
How else am I supposed to write them? If there is a stale sta
Duy Nguyen wrote:
> I _think_ the reason is because git was never written as a reusable
> library in mind from the beginning.
We cannot reverse-engineer intents, but I tend to agree with this. My
question is: so what? Is it impossible to do now?
> So global states and die() exist.
> Worse, "run
Mathieu Lienard--Mayor wrote:
> @@ -170,30 +175,47 @@ static int check_local_mod(unsigned char *head, int
> index_only)
> * "intent to add" entry.
> */
> if (local_changes && staged_changes) {
> - if (!index_only || !(ce->ce_f
Mathieu Lienard--Mayor wrote:
> As an example, the message:
> error: 'foo.txt' has changes staged in the index
> (use --cached to keep the file, or -f to force removal)
>
> would look like, with advice.rmHints=true:
> error: 'foo.txt' has changes staged in the index
Um, hav
Felipe Contreras wrote:
>> Ofcourse they're implementation details. Even in this very test, I
>> check $dotest/autostash plenty of times.
>
> The more the test relies on implementation details, the worst.
I'm not convinced about this.
>> Then show me how to do it correctly.
>
> Something like th
Jorge Juan Garcia Garcia wrote:
> Some people always run 'git status -s'.
> The configuration variable status.short allows to set it by default.
Good feature.
> @@ -1112,6 +1112,15 @@ static int git_status_config(const char *k, const char
> *v, void *cb)
> s->submodule_su
Junio C Hamano wrote:
> * mm/color-auto-default (2013-05-15) 2 commits
> - make color.ui default to 'auto'
> - config: refactor management of color.ui's default value
>
> Flip the default for color.ui to 'auto', which is what many
> tutorials recommend new users to do. The updated code claims
Antoine Pelisse wrote:
>>> The more the test relies on implementation details, the worst.
>>
>> I'm not convinced about this.
>
> My understanding of these tests is that they make sure new/better
> implementations don't break the user experience/defined behavior. If
> the test relies on the impleme
601 - 700 of 1623 matches
Mail list logo
