Duy Nguyen wrote:
> 044bbbc (Make git_dir a path relative to work_tree in
> setup_work_tree() - 2008-06-19)
Okay, so it does seem to be a significant optimization. Frankly,
e02ca72 only improves the relative_path() algorithm, and it's not
really doing anything Wrong: it's has just uncovered a pre
Duy Nguyen wrote:
> I was involved with this code (the gitdir setup code, not submodule)
> and am interested to know what's going on too. Could you produce a
> small script to reproduce it?
Here's your reduced testcase. Just point mygit to a HEAD build.
#!/bin/sh
mygit=~/src/git/git
cd /tm
Jiang Xin wrote:
> I change the EDITOR(GIT_EDITOR) environment in your test script
> as follows:
>
> GIT_EDITOR="echo PWD: $(pwd); echo REALPATH: $(pwd -P); echo" \
> git commit --amend
See, what stumps be about this is the no-submodule case:
#!/bin/sh
mygit=~/src/git/git
cd /tmp
Duy Nguyen wrote:
> I think instead of letting the kernel walk the path, emacs does it by
> itself.
If this were true, shouldn't we be able to reproduce the behavior with
my no-submodules symlink testcase? How can it resolve symlinks in one
case, and not in the other case?
--
To unsubscribe from
Duy Nguyen wrote:
> In the no-submodules symlink test case, the path given to the editor
> is .git/COMMIT_EDITMSG, no following ".." back in the symlink target.
Thanks, and sorry about the stupidity. I just patched
builtin/commit.c to check this.
> This bug can be reproduced without git involved
Duy Nguyen wrote:
> How about something like this as a workaround for emacs?
Even if we do manage to patch Emacs now, we still need to support
older versions: so yeah, this is an urgent candidate for maint. I'm
waiting for the word from Emacs-Devel before writing out a commit
message.
--
To unsub
Co-authored-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Ramkumar Ramachandra
---
Urgent candidate for maint. I wrote to emacs-devel, but nobody seems
to be interested; the sources are horrendously unmaintainable, and
the project should die soon.
editor.c | 2 +-
1 file changed, 1 insertion(+)
Ondřej Bílka wrote:
> diff --git a/builtin/log.c b/builtin/log.c
> index 2625f98..01b49b3 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -304,7 +304,7 @@ static void setup_early_output(struct rev_info *rev)
> * tenth of a second, don't even bother doing the
> * early-outp
Ralf Thielow wrote:
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 0039ecf..8d7659a 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -159,7 +159,7 @@ finish_rebase () {
> die "$(eval_gettext "Cannot store \$stash_sha1")"
> gettext 'Applyi
Junio C Hamano wrote:
> That's a bit strange---the patch text looks like the "how about
> this" patch Duy posted earlier. Shouldn't it be From: Duy with
> S-o-b: by two of you instead?
Feel free to amend as you see fit, as always.
> For editors that are not broken, this could be an annoying
> re
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>> Junio C Hamano wrote:
>>> That's a bit strange---the patch text looks like the "how about
>>> this" patch Duy posted earlier. Shouldn't it be From: Duy with
>>> S-o-b: by two of
Hi,
While going through the for-each-ref-pretty series that Duy and I were
developing, I noticed that this cleanup was independent and good
as-it-is.
So here it is.
Nguyễn Thái Ngọc Duy (1):
for-each-ref, quote: convert *_quote_print -> *_quote_buf
Ramkumar Ramachandra (2):
tar-t
,
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
) 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
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
Junio C Hamano wrote:
> Having said all that, the patch texts all look OK, so I'll queue
> them with updated log messages. It was the usual me reacting to
> unjustified value judgement made in log messages and cover letters.
Thanks. I'll look at how the log messages are different in the queued
v
Hi,
I was pulling in some changes in the morning to find:
Auto packing the repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Being my usual impatient self, I opened another prompt and started
merging changes. After the checkout, it
Nguyễn Thái Ngọc Duy wrote:
> This may happen when `git gc --auto` is run automatically, then the
> user, to avoid wait time, switches to a new terminal, keeps working
> and `git gc --auto` is started again because the first gc instance has
> not clean up the repository.
>
> This patch tries to avo
Junio C Hamano wrote:
> I am a bit hesitant to dismiss with "It's not the right model", as
> the original of accessing the repository from two terminals while
> one clearly is being accessed busily by gc falls into the same
> category.
As to why I think it makes sense: garbage collecting unreferen
Martin Fick wrote:
> https://gerrit-review.googlesource.com/#/c/35215/
Very cool. Of what I understood:
So, the problem is that my .git/objects/pack is polluted with little
packs everytime I fetch (or push, if you're the server), and this is
problematic from the perspective of a overtly (naively)
Junio C Hamano wrote:
> [...]
The other comments mostly make sense.
> After reading what the whole function does, I think the purpose of
> this function is to take gc-lock (with optionally force). Perhaps a
> name along the lines of "lock_gc", "gc_lock", "lock_repo_for_gc",
> would be more appro
Duy Nguyen wrote:
> Good point. I think that is because gc does not check if gc is already
> running. Adding such a check should not be too hard. I think gc could
> save its pid in $GIT_DIR/auto-gc.pid. The next auto-gc checks this, if
> the pid is valid, skip auto-gc.
Check. I also talked about
This is the rough explanation I wrote down after reading it:
So, the problem is that my .git/objects/pack is polluted with little
packs everytime I fetch (or push, if you're the server), and this is
problematic from the perspective of a overtly (naively) aggressive gc
that hammers out all fragment
Martin Fick wrote:
> I hope
> that someone more familiar with git gc than me might take
> this on some day. :)
More likely scenario: someone who is unfamiliar with it will read and
patch it little by little :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
Junio C Hamano wrote:
>>> After reading what the whole function does, I think the purpose of
>>> this function is to take gc-lock (with optionally force). Perhaps a
>>> name along the lines of "lock_gc", "gc_lock", "lock_repo_for_gc",
>>> would be more appropriate.
>>
>> The whole point of this ex
David Kastrup wrote:
> As you can see, the first message starting with "error: could not apply"
> outputs a reasonable rendition of the commit summary line. However, the
> final "Could not apply" message (starting with a capital C) converts
> instances of \t to a tab.
To get you started:
$ git
Martin Fick wrote:
> So, it has me wondering if there isn't a more accurate way
> to estimate the new packfile without wasting a ton of time?
I'm not sure there is. Adding the sizes of individual packs can be off
by a lot, because your deltification will be more effective if you
have more data to
Junio C Hamano wrote:
> Imagine we have a cheap way to enumerate the young objects without
> the usual history traversal.
Before we discuss the advantages, can you outline how we can possibly
get this data without actually walking downwards from the roots
(refs)? One way to do it is to pull data o
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4 +1,4 @@
-int cmd_whatchanged(int argc, const char **argv, const char *prefix)
+int cmd_log(int argc, const char **argv, const char *pref
Junio C Hamano wrote:
> The only thing it does is to scratch an irrelevant itch by people
> who peek the codebase and find an old command whose existence does
> not even hurt them. They may have too much time on their hand, but
> that is not an excuse to waste other people's time by adding extra
>
Junio C Hamano wrote:
> it is
> not a problem for the pack that consolidates young objects into a
> single pack to contain some unreachable crufts.
So far, we have never considered putting unreachable objects in packs.
Let me ask the obvious question first: what happens when I push? Do I
pack up a
Matthieu Moy wrote:
> ... but I do agree that the doc is really confusing. It would be much
> better if the doc could be reduced to:
>
> "This is a synonym for linkgit:git-log[1] --raw --some --other ---options.
> Please refer to the documentation of that command."
I don't think there's an exact c
Junio C Hamano wrote:
> So I do not see how that question is "obvious". The question
> obviously pointless and misses the mark by wide margin? The
> question makes it obvious that whoever asks it does not understand
> how Git works?
Shall we all sit and mourn over the fact that I don't understan
Damien Robert wrote:
> If I may chime in as a user
By all means. Do not feel inhibited to state your problems because you
are a "user": we are all users; we eventually became contributors
because we found certain things that needed fixing, and fixed them
little by little.
--
To unsubscribe from th
Junio C Hamano wrote:
> Martin Fick writes:
>> Assuming I understand what you are suggesting, would these
>> "young object" likely still get "deduped" in an efficient
>> way without doing history traversal (it sounds like they
>> would)?
>
> Yes.
>
> The very first thing pack-object machinery does
Junio C Hamano wrote:
>> 3. After a few days of working, the gc heuristics figure out that I
>> have too much garbage and too many packs; a cleanup is required. The
>> gc --auto which doesn't tolerate fragmentation: it tries to put
>> everything into one large pack.
>
> Today's "gc --auto" skims th
Jeff King wrote:
> It depends on what each side has it, doesn't it? We generally try to
> reuse on-disk deltas when we can, since they require no computation. If
> I have object A delta'd against B, and I know that the other side wants
> A and has B (or I am also sending B), I can simply send what
Junio C Hamano wrote:
> Documentation/git-whatchanged.txt | 41
> ---
> 1 file changed, 8 insertions(+), 33 deletions(-)
Looks good. Thanks for doing this.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@
Jeff King wrote:
> [...]
First off, thanks for the fabulous writeup. I hope more contributors
read this, and get interested in tackling the problems.
> You are missing a step in the preparation of the delta list. If we
> already have a delta on-disk, we will check whether it is usable and
> keep
Duy Nguyen wrote:
> Right. transport_get() is also run for push and it sets
> smart_options->thin = 1 unconditionally.
So, it looks like smart http implies the thin capability. I think
sop's patch (6 years ago) was about turning off thin on dumb http: can
we check that before deciding that push --
Deniz Türkoglu wrote:
> I have spoken to Shawn Pearce (gerrit project lead, google) and he
> said he is OK with hosting the gerrit instance.
>
> I would like to hear your thoughts on this.
I personally think email is by far the best interface for patches,
reviews, and discussions. Git patches are
Jason Timrod wrote:
> I'm looking for a way to make the "-sb" options to git-status the default
> somehow.
I've aliased `git status` to `git status -sb` too, and I think it's a
very sensible default; who wants to see
# Changes not staged for commit:
# (use "git add ..." to update what will
Hi Peff,
Jeff King wrote:
> An off-list discussion made me wonder if something like this would be
> useful:
>
> git log -p --submodule=log:' %m %an <%ae>: %s'
>
> where the format could be whatever you find useful.
Interesting. Don't you mean `git diff` in place of `git log -p`
though? I don
59893a88 (Documentation/log: add a CONFIGURATION section, 2010-05-08)
mentioned that `format.pretty` is the default for the `--format`
option. Such an option never existed, and the author meant
`--pretty`. Make this correction.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/git-log.txt
Felipe Contreras wrote:
> On Sun, Nov 11, 2012 at 11:32 AM, Ramkumar Ramachandra
> wrote:
>> I'm experiencing test failures in contrib/remote-helpers.
>
> Which are your versions of hg, and bzr?
Mercurial Distributed SCM (version 1.9.1)
Bazaar (bzr) 2.4.1
Ram
--
To uns
Felipe Contreras wrote:
> On Sun, Nov 11, 2012 at 11:41 AM, Ramkumar Ramachandra
> wrote:
>> test-hg.sh forgets to set ui.username, which is required for `hg
>> commit`. Fix this.
>
> Hmm, I get 'no username found, using 'felipec@nysa' instead', but
&
Hi again,
Ramkumar Ramachandra wrote:
> Don't you mean `git diff` in place of `git log -p`
> though? I don't think `git log --submodule` does anything differently
> from `git log`.
Sorry for the nonsense. I just realized that it affects the diffs
shown by `git log -p`.
Ra
Jeff King wrote:
> On Thu, Nov 01, 2012 at 04:13:49PM +0530, Ramkumar Ramachandra wrote:
>
>> diff --git a/builtin/diff.c b/builtin/diff.c
>> index 9650be2..6d00311 100644
>> --- a/builtin/diff.c
>> +++ b/builtin/diff.c
>> @@ -297,6 +297,10 @@ int cmd_diff(int
which both '--submodule'
and 'diff.submodule' use to set/ unset SUBMODULE_OPT.
Ram
Ramkumar Ramachandra (3):
Documentation: move diff.wordRegex from config.txt to diff-config.txt
diff: introduce diff.submodule configuration variable
submodule: display summary header in b
19299a8 (Documentation: Move diff..* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/diff-config.txt|7 ++
Documentation/diff-options.txt |3 +-
cache.h
e1 012b072..248d0fd:
Unfortunately, it's easy to miss in the output because it's not bold.
Change this.
Signed-off-by: Ramkumar Ramachandra
---
diff.c |2 +-
submodule.c |8
submodule.h |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/d
Hi Felipe,
Felipe Contreras wrote:
> The code finds the changes in each commit in the list, runs 'git blame'
> to see which other commits are relevant to those lines, and then adds
> the author and signer to the list.
>
> Finally, it calculates what percentage of the total relevant commits
> each
Hi Jonathan,
Jonathan Nieder wrote:
> Hi Ram,
>
> Ramkumar Ramachandra wrote:
>
>> 59893a88 (Documentation/log: add a CONFIGURATION section, 2010-05-08)
>> mentioned that `format.pretty` is the default for the `--format`
>> option. Such an option never existed,
ne_path)
> +d = bzrlib.bzrdir.BzrDir.open(clone_path)
> branch = d.open_branch()
> result = branch.pull(remote_branch, [], None, False)
> else:
>
> I have other fixes to run up to 2.0.
Works for me. All four tests pass now.
Reported-by: Ramkumar Ramac
to Peff's review of v3.
What changed:
* Functional code simplified and moved to git_diff_ui_config.
* Peff contributed one additional patch to the series.
Thanks.
Ram
Jeff King (1):
diff: rename "set" variable
Ramkumar Ramachandra (3):
Documentation: move diff.wordRegex fro
19299a8 (Documentation: Move diff..* from config.txt to
diff-config.txt, 2011-04-07) moved the diff configuration options to
diff-config.txt, but forgot about diff.wordRegex, which was left
behind in config.txt. Fix this.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt
Introduce a diff.submodule configuration variable corresponding to the
'--submodule' command-line option of 'git diff'.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/diff-config.txt|7 +++
Documentation/diff-options.txt |3 ++-
diff.c
uot; to show that it is the color for showing diff meta-info (it still
does not indicate that it is a "color", but at least it matches the
scheme of the other color variables).
Signed-off-by: Jeff King
Signed-off-by: Ramkumar Ramachandra
---
diff.c | 12 ++--
1 files change
e1 012b072..248d0fd:
Unfortunately, it's easy to miss in the output because it's not bold.
Change this.
Signed-off-by: Ramkumar Ramachandra
---
diff.c |2 +-
submodule.c |8
submodule.h |2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/d
Jeff King wrote:
> On Sun, Nov 11, 2012 at 10:29:05PM +0530, Ramkumar Ramachandra wrote:
>> @@ -223,6 +238,15 @@ int git_diff_basic_config(const char *var, const char
>> *value, void *cb)
>> return 0;
>> }
>>
>> + if (!strcmp(var, &qu
Jeff King wrote:
> It may be worth squashing this test into patch 3:
Looks good. Thanks.
> BTW, while writing the test, I noticed two minor nits with your tests:
>
> 1. They can use test_config, which is simpler (you do not need to
> unset yourself after the test) and safer (the unset hap
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> diff --git a/t/t4041-diff-submodule-option.sh
>> b/t/t4041-diff-submodule-option.sh
>> index 6c01d0c..e401814 100755
>> --- a/t/t4041-diff-submodule-option.sh
>> +++ b/t/t4041-diff-submodule-option.sh
&
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> Ramkumar Ramachandra writes:
>>> +test_expect_success 'added submodule, set diff.submodule' "
>>
>> s/added/add/;
>
> I see that the topic is already in `next`. Do you want to fix it up th
Hi,
This is the result of one lazy afternoon.
Ram
Ramkumar Ramachandra (4):
t4041 (diff-submodule-option): parse digests sensibly
t4041 (diff-submodule-option): rewrite add_file() routine
t4041 (diff-submodule-option): modernize style
t4041 (diff-submodule-option): change tense of test
`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.
Signed-off-by: Ramkumar Ramach
Instead of "cd there and then come back", use the "cd there in a
subshell" pattern. Also fix '&&' chaining in one place.
Suggested-by: Junio C Hamano
Signed-off-by: Ramkumar Ramachandra
---
t/t4041-diff-submodule-option.sh | 13 +
1 files
- Enclose tests in single quotes as opposed to double quotes. This is
the prevalent style in other tests.
- Remove the unused variable $head4_full.
- Indent the expected output so that it lines up with the rest of the
test text.
Signed-off-by: Ramkumar Ramachandra
---
t/t4041-diff
Change the tense of test names from past to present, as this is the
prevalent style.
Signed-off-by: Ramkumar Ramachandra
---
t/t4041-diff-submodule-option.sh | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t
Ugh, line wrapping breaks my patch. I've attached a copy.
Ram
0001-t4041-diff-submodule-option-don-t-hardcode-SHA-1-in-.patch
Description: Binary data
Hi,
v1 is here: 1354005692-2809-1-git-send-email-artag...@gmail.com
This is in response to Junio's review of v1.
Thanks.
Ram
Ramkumar Ramachandra (4):
t4041 (diff-submodule-option): don't hardcode SHA-1 in expected
outputs
t4041 (diff-submodule-option): parse digests sensib
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Ramkumar Ramachandra
---
t/t4041-diff-submodule-option.sh | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041
`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.
Signed-off-by: Ramkumar Ramach
Instead of "cd there and then come back", use the "cd there in a
subshell" pattern. Also fix '&&' chaining in one place.
Suggested-by: Junio C Hamano
Signed-off-by: Ramkumar Ramachandra
---
t/t4041-diff-submodule-option.sh | 23 +++
- Enclose tests in single quotes as opposed to double quotes. This is
the prevalent style in other tests.
- Remove the unused variable $head4_full.
- Indent the expected output so that it lines up with the rest of the
test text.
Signed-off-by: Ramkumar Ramachandra
---
t/t4041-diff
Felipe Contreras wrote:
> [...]
What happened to this code? I don't see it in `pu`.
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
ed on potentially non-existent files. Suppress this
error output.
Signed-off-by: Ramkumar Ramachandra
---
git-am.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index c092855..88aa438 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -446,8 +446,8 @@ done
$dotest/last.
Signed-off-by: Ramkumar Ramachandra
---
git-am.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-am.sh b/git-am.sh
index 88aa438..f4ef8fc 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -454,7 +454,7 @@ then
rm -fr "$dotest"
fi
-if test -d "$dote
We only need to do these two tasks
git gc --auto
rm -fr "$dotest"
ourselves if the script was invoked as a standalone program; when
invoked with --rebasing (from git-rebase--am.sh), cascade control back
to the ultimate caller git-rebase.sh to do this for us.
Signed-off-by
ature means that a caller like pull (with
pull.rebase set to true) can easily be patched to remove the
require_clean_work_tree restriction.
Signed-off-by: Ramkumar Ramachandra
---
Documentation/config.txt | 8 +++
Documentation/git-rebase.txt | 10 +++
git-rebase.sh
20 exercise all the cases sufficiently? Have I missed
anything?
Enjoy reading and reviewing this.
Ramkumar Ramachandra (8):
am: suppress error output from a conditional
rebase -i: don't error out if $state_dir already exists
am: tighten a conditional that checks for $dotest
rebase: prepare t
Return control to the caller git-rebase.sh to get these two tasks
rm -fr "$dotest"
git gc --auto
done by it.
Signed-off-by: Ramkumar Ramachandra
---
git-rebase--merge.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-rebase--merge.sh b/
Return control to the caller git-rebase.sh to get these two tasks
rm -fr "$dotest"
git gc --auto
done by it.
Signed-off-by: Ramkumar Ramachandra
---
git-rebase--interactive.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/git-rebase--interactiv
repare git-rebase.sh for later patches that return control from each
$backend script back to us, for performing this generic cleanup
routine.
Another advantage is that git-rebase.sh can implement a generic
finish_rebase() to possibly do additional tasks in addition to the
cleanup.
Signed-off-by
git-rebase.sh).
Signed-off-by: Ramkumar Ramachandra
---
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 5822b2c..3411139 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase
test-lib.sh already sets a sane GIT_AUTHOR_{NAME,EMAIL} for all test
scripts to use. Don't unnecessarily duplicate the work.
Signed-off-by: Ramkumar Ramachandra
---
t/t3400-rebase.sh | 4
1 file changed, 4 deletions(-)
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b5
'rm -f B' is a lone statement that isn't contained inside any
test_expect_* block. Use test_when_finished to execute it after the
preceding test has finished.
Signed-off-by: Ramkumar Ramachandra
---
t/t3400-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
A couple of tests execute 'git rebase' with GIT_TRACE set to 1, but
this trace output is not used anywhere. Remove it, since it is not
relevant to what we are testing.
Signed-off-by: Ramkumar Ramachandra
---
t/t3400-rebase.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
Otherwise they stick out like sore thumbs in the test output, where
all the other titles begin with a lowercase letter.
Signed-off-by: Ramkumar Ramachandra
---
t/t3400-rebase.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index
Hi,
I was just going through t3400 when wondering where to put the tests
for rebase.autostash. Here's a set of trivial patches.
Thanks.
Ramkumar Ramachandra (4):
t3400 (rebase): don't set GIT_AUTHOR_{NAME,EMAIL}
t3400 (rebase): downcase a couple of test titles
t3400 (rebase):
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> A couple of tests execute 'git rebase' with GIT_TRACE set to 1, but
>> this trace output is not used anywhere.
>
> Isn't it shown in "t4300-*.sh -v" output to help the debugger?
Um, but why
Eric Sunshine wrote:
> These values are intentionally bogus. Doesn't this change defeat the
> purpose of 43c2325 (am: use get_author_ident_from_commit instead of
> mailinfo when rebasing; 2010-06-16)?
Oh, oops. I paid too little attention to this series.
Thanks for catching.
--
To unsubscribe fr
Thomas Rast wrote:
> [1] correctly observed that we are already wrapping three different
> operations under the git-checkout command.
Incorrect. We merge_trees() and update refs. I see no reason to
create artificial abstractions on top of this.
> [...]
Let's not talk about how gross your imple
Junio C Hamano wrote:
> So it is either (1) the added code is unreachable and unexercised at
> this point in the series, or
Yeah, it's (1).
> Perhaps this should come a bit later in the series?
When exactly? I picked up on your suggestion to separate out the
preparation-for-$backend-to-return s
Junio C Hamano wrote:
> Perhaps because this is a test about "rebase" and a typical debugger
> does not want to trace other "git" things while debugging this?
Okay, let's drop this 4-part series: it's too minor.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mes
Junio C Hamano wrote:
> To me, most of them look like responses to valid issues, and that
> holds true even for [PATCH 1/4]. Even though your response may have
> been an incorrect one, the issue that triggered the response is
> still valid---the setting of these variables without explanation
> inv
Ramkumar Ramachandra wrote:
> I just comment out the test_expect_success and close-quote, and put a
> test_done after it. I would never advocate this GIT_TRACE thing
> anywhere, because I want to put GIT_TRACE=1 (and possibly other
> modifications) where I want it. Locally.
On th
Jonathan Nieder wrote:
> I use "-v -i" together quite frequently when debugging. I also use
> "-v" automatically to debug test failures when tests are invoked
> automatically on machines I do not have access to.
Yeah, it makes sense on remote machines. I just found out about -i,
and the -v -i co
Hi,
My push.default is current. I often end up doing:
# on master
$ git push
# switch to another terminal
$ git checkout rebase.autostash
$ git rebase master
# go back to previous terminal
# push has failed
This happens because push tries to push rebase.auto
Hi,
I often do:
$ git checkout t-rebase-cleanup
$ git push
$ git checkout -
$ git merge @{u}
$ git checkout rebase.autostash
$ git rebase master
$ git checkout -
# noop
# Aargh!
$ git checkout -
# noop again
Isn't this highly annoying?
Ram
--
To unsub
301 - 400 of 1623 matches
Mail list logo
