Jeff King wrote:
Sorry, I don't have patches. It is a hard problem for which I do not
have the solution, which is kind of my point.
So, what is the problem? We are moving towards what we think is the
way forward. Nobody said that it is the theoretical best, but it's
_much_ better than doing
Thomas Rast wrote:
The arguments arise to a large degree from attempting to review his
work. Not doing so is not an option, see e.g.:
I don't recall saying that you shouldn't review his work (?). What I
_am_ saying is that there is absolutely no point belaboring over
what's wrong with
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 never
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 state
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_flags
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, have you
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 this.
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_summary
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 the
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 implementation,
Felipe Contreras wrote:
There's no libgit, and there will never be, every object file in Git is
the same, and there's wish to organize them in any way; they are *all*
for the 'git' binary and its builtin commands.
Nice joke patch to illustrate your point ;)
On a more serious note, please be a
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 artag...@gmail.com
---
Candidate for maint?
Documentation
[+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 branch
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
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
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 think
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 list: send the line
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 or
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 a few
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't
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
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
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 being
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 documenting
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 artag
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 in
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 would
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
creates an extra
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
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-branch
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
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?
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 see
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
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
already.
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
: 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 responsiveness of %(upstream:track)
Ramkumar
to write to,
convert the *_quote_print functions and callers to *_quote_buf.
[rr: commit message, minor modifications]
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/for-each-ref.c | 13 +
quote.c| 44
populates
used_atom, which get_value() and populate_value() later rely on.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/for-each-ref.c | 15 +--
pretty.c | 4
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/builtin/for-each
of format().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
obvious that they
are not handled.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
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 artag...@gmail.com
---
Documentation/git-for-each
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 artag...@gmail.com
might like to define their own builtins in
the future.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
) 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 artag...@gmail.com
---
quote.c | 17 -
quote.h | 2 --
2 files changed, 19
)
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 artag...@gmail.com
---
Documentation/git-for-each-ref.txt | 6 +-
builtin/for-each-ref.c | 42
code, they are advised to migrate to --pretty.
[rr: documentation]
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-for-each-ref.txt | 22 -
builtin/for-each-ref.c | 67 --
2 files changed, 85 insertions(+), 4
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 artag...@gmail.com
---
builtin/for-each-ref.c | 49 +
1
, 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 artag...@gmail.com
---
Documentation/git-for-each-ref.txt | 7 +++
builtin/for-each-ref.c | 38
() helper that 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 artag...@gmail.com
---
builtin/for-each-ref.c | 55 --
1
(to set 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 artag...@gmail.com
---
commit.h | 8
pretty.c | 25
)
to display a red asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-for-each-ref.txt | 4
builtin/for-each-ref.c | 13 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-for-each
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
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 do
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
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 control
From: 乙酸鋰 ch3co...@gmail.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
乙酸鋰: 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
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't
-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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Add support for completing 'git blame'. List only the common short
options.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib
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 artag...@gmail.com
---
contrib/completion/git-completion.bash | 11 +++
1 file changed, 11 insertions(+)
diff
.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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 100644
--- a/contrib
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: clarify
-by: Ramkumar Ramachandra artag...@gmail.com
---
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
Felipe Contreras wrote:
This breaks 'git format-patch master..TAB'.
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
They haven't been touched in six years.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Another candidates for removal: contrib/blameview (6 years); anoyone
using this?
contrib/continuous/cidaemon| 503 -
contrib/continuous/post-receive
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 paragraph.
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 having
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 didn't
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)
+ git
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 for
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 majordomo
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
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 ()
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.git
)
Inputs-from: Phil Hord phil.h...@gmail.com
Co-authored-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/diff-options.txt | 38 +++
Documentation/gitdiffcore.txt | 45
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 artag...@gmail.com
---
diffcore-pickaxe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 63722f8
that match their respective criterion are kept in the output. When
Ramkumar Ramachandra (2):
diffcore-pickaxe: make error messages more consistent
diffcore-pickaxe doc: document -S and -G properly
Documentation/diff-options.txt | 38 +++
Documentation/gitdiffcore.txt
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
when a
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 people that
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 on a
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 why
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:
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?
other interesting
things in the meantime (see hot-branch and @{push}).
Thanks.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 709ef6b..5906757 100755
--- a/git
Junio C Hamano wrote:
* rr/rebase-autostash (2013-05-12) 7 commits
- rebase: implement --[no-]autostash and rebase.autostash
- rebase --merge: return control to caller, for housekeeping
- rebase -i: return control to caller, for housekeeping
- am: return control to caller, for
Thomas Rast wrote:
So until this changes, my $0.02 is a blanket NAK and a refusal to spend
my time reviewing.
Then don't review the damn thing. With Felipe, I have the following
rule of thumb: make some concrete suggestions and forget about
follow-ups. He's not going to accept any general
Felipe Contreras wrote:
Akin to 'am --skip' and 'rebase --skip'.
This ranged-cherry-pick can be useful for small ranges. As pointed
out by others on the list, it hemorrhages memory quite horribly (and
this problem is non-trivial to fix). Perhaps we should document this
in limitations or bugs
Felipe Contreras wrote:
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)
+
Felipe Contreras wrote:
I think a lot of the functionality of 'git rebase' should move to 'git
cherry-pick', and then all the 'git rebase' code can be simplified
greatly, and tests like these would help a lot.
What do we do about the leakages? Want to take on the task of fixing
the
Matthieu Moy wrote:
the manual of git init says: An initial HEAD file that references the
HEAD of the master branch is also created.
However, after creating the repository using git init there's no
master branch.
Right, but HEAD still points to it ;-). We sometimes call this an
unborn
Ákos, Tajti wrote:
Cannot merge multiple branches into empty head
The command was:
git pull ../dump.dmp refs/heads/*:refs/heads/*
Is this a better way of doing this?
pull runs a fetch, which updated .git/FETCH_HEAD. Now, if
.git/FETCH_HEAD has just one branch (and other not-for-merge
Felipe Contreras wrote:
Did you miss the -q option passed to 'git commit'?
Ah, yes.
It would help if you mentioned:
Introduce --quiet to suppress warning about skipped commits (when
using --skip-empty) and output from 'git commit'.
in the commit message.
Thanks.
--
To unsubscribe from
Felipe Contreras wrote:
What you are really complaining about is that I don't agree with
*every* single suggestion you make. And since you made them, they must
be sensible, and single I don't agree with you, I must not be
sensible, is that right?
Oh, I have no problems: I reviewed
Junio C Hamano wrote:
As I wasn't the one who were disagreeing, that would not work
well.
I meant in the tiny details like echo + gettext versus gettext.
From the review of v3, nobody had any disagreements; just minor
suggestions: that's what this patch is about anyway.
--
To unsubscribe from
601 - 700 of 1485 matches
Mail list logo
