To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b
with the solution.
I hope it's an enjoyable read.
Ramkumar Ramachandra (4):
completion: prioritize ./git-completion.bash
completion: introduce __gitcomp_2 ()
completion: fix branch.autosetup(merge|rebase)
completion: fix remote.pushdefault
contrib/completion/git-completion.bash | 43
of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10
to not complete
$ git config branch.autosetupmerge.TAB
$ git config branch.autosetuprebase.TAB
with the usual branch.name. candidates.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff
remote.pushdefault.TAB
with the usual remote.name. candidates.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/for-each-ref.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 6551e7b..51798b4 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -92,7
Junio C Hamano wrote:
If we are looking at branch.autosetupmerge. followed by something,
who typed that final dot?
I admit that it's a very unlikely case. The user did:
$ branch.autosetupmerTAB
hit backspace to delete the trailing space, inserted a dot, and hit TAB again.
If you are
Junio C Hamano wrote:
__gitcomp_nl $(__git_heads) $pfx $cur_ .
__gitcomp_nl_append $autosetupmerge\nautosetuprebase\n $pfx
$cur_
This is not a bad idea at all. I'm just afraid that we might be
leaving open ends: What happens if the $pfx isn't the same in both
cases? Who
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b
of this kind, create a
variation of __gitcomp_nl () that accepts two sets of arguments and two
independent suffixes.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 30 ++
contrib/completion/git-completion.zsh | 10
Hi,
In this iteration, I've removed hunks to prevent completing:
$ git config remote.pushdefault.TAB
$ git config branch.autosetupmerge.TAB
$ git config branch.autosetuprebase.TAB
Since they're perfectly valid remote/ branch names.
Thanks.
Ramkumar Ramachandra (4):
completion
Junio C Hamano wrote:
You seem to be calling it incorrect to give the same degree of
completion for a branch the user named autosetupmerge as another
branch topic, but I think it is incorrect not to, so I cannot tell
if we are agreeing or disagreeing.
No, what's incorrect is providing
Hi Junio et al,
In v3, I've implemented __gitcomp_nl_append (), like you
suggested. After implementing it, I feel foolish about having gone
around my head to do __gitcomp_2 ().
Thanks.
Ramkumar Ramachandra (4):
completion: prioritize ./git-completion.bash
completion: introduce
To ease development, prioritize ./git-completion.bash over other
standard system paths.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b
completions of this kind, create a
variation of __gitcomp_nl () that appends to the existing list of
completion candidates, COMPREPLY.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 13 +
contrib/completion/git-completion.zsh | 8
When attempting to complete
$ git config remote.pushTAB
'pushdefault' doesn't come up. This is because $cur is matched with
remote.* and a list of remotes are completed. Add 'pushdefault' to the
list of remotes using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra artag
().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index bf358d6..75c7302 100644
--- a/contrib/completion/git
Junio C Hamano wrote:
Is it because going this route and doing it at such a low level
would make zsh completion (which I have no clue about ;-)
unnecessarily complex?
The zsh completion only cares to override __gitcomp_nl () and
__gitcomp_nl_append (), without bothering to re-implement the
directory than in those system default places.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git-completion.zsh
index
everytime. Save the user the extra keystrokes by
introducing format.defaultTo which can contain the name of a branch
against which to base patches.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/config.txt | 4
builtin/log.c | 7
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 51c2dd4..39b81f7 100644
--- a/contrib/completion/git
Ramkumar Ramachandra wrote:
Ramkumar Ramachandra (2):
completion: complete format.coverLetter
format-patch: introduce format.defaultTo
Any thoughts on checkout.defaultTo? I have a com alias to checkout 'master'.
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Hi,
On the latest git, I noticed that a rebase --onto doesn't abort
properly. Steps to reproduce:
# on some topic branch
$ git rebase --onto master @~10
^C # quickly!
$ git rebase --abort
# HEAD is still detached
I tried going back a few revisions, and the bug seems to be very old;
Junio C Hamano wrote:
- why is a single branch name sufficient?
It does accept a revision, so any form is allowed; but why would
anyone want that in a format.defaultTo? I'm not sure we want to impose
an artificial restriction on the configuration variable though.
- is it a better option to
Junio C Hamano wrote:
I do not think --abort was designed to abort an uncontrolled stop
like ^C in the first place.
Why not? All it requires is a reset --hard to
.git/rebase-apply/head-name, as usual, no?
To allow that kind of recovery, you
need to teach rebase to first record the state you
Jonathan Nieder wrote:
1. Most config settings are in noun form: e.g.,
[remote] pushDefault = foo. That makes their names easy to guess
and makes them easy to talk about: I set the default remote for
pushing by changing the remote.pushdefault setting.
'[url foo] insteadOf'
Junio C Hamano wrote:
I meant a single branch as opposed to depending on what branch
you are sending out, you may have to use a different upstream
starting point, and a single format.defaultTo that does not read
what your HEAD currently points at may not be enough.
Unless you set @{u} to
Jeff King wrote:
Yeah, I had similar thoughts. I personally use branch.*.merge as
forkedFrom, and it seems like we are going that way anyway with things
like git rebase and git merge defaulting to upstream.
My issue with that is that I no idea where my branch is with respect
to my forked
Junio C Hamano wrote:.
As I said in the different subthread, I am not convinced that you
would need the complexity of branch.*.forkedFrom. If you set your
upstream to the true upstream (not your publishing point), and
have remote.pushdefaultset to 'publish', you can expect
git push
John Szakmeister wrote:
Then where does it get pushed? Do you always specify where to save your work?
FWIW, I think the idea of treating @{u} as the eventual recipient of
your changes is good, but then it seems like Git is lacking the
publish my changes to this other branch concept.
Am I
Ramkumar Ramachandra wrote:
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
Junio: Please push this part via 'maint' independently.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
John Szakmeister wrote:
I guess it's not a good idea to
set 'push.default' to 'upstream' in this triangle workflow then,
otherwise the branch name being pushed to will be 'branch.*.merge'.
Is that correct? I just want to make sure I understand what's
happening here.
push.default = upstream
this new configuration variable.
Cc: Jeff King p...@peff.net
Cc: Junio C Hamano gis...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Since -M, -C, -D are left in the argc, checking argc 2 isn't
sufficient.
I wanted to get an early reaction before wiring up checkout
[Fixed typo in Junio's address]
On Wed, Jan 8, 2014 at 1:59 AM, Ramkumar Ramachandra artag...@gmail.com wrote:
A very common workflow for preparing patches involves working off a
topic branch and generating patches against 'master' to send off to the
maintainer. However, a plain
$ git
Junio C Hamano wrote:
I do not mind allowing laziness by defaulting to something, but I am
not enthused by an approach that adds the new variable whose value
is questionable. The description does not justify at all why
@{upstream} is not a good default (unless the workflow is screwed up
and
Jeff King wrote:
I have not carefully read some of the later bits of the discussion from
last night / this morning, so maybe I am missing something, but this
seems backwards to me from what Junio and I were discussing earlier.
The point was that the meaning of @{upstream} (and branch.*.merge)
Jeff King wrote:
My daily procedure is something like:
all_topics |
while read topic; do echo $topic $(git rev-parse $topic@{u}); done |
topo_sort |
while read topic upstream; do
git rebase $upstream $topic || exit 1
done
Ah, I was perhaps over-specializing for my own
Jeff King wrote:
I definitely respect the desire to reuse the existing tooling we have
for @{u}. At the same time, I think you are warping the meaning of
@{u} somewhat. It is _not_ your upstream here, but rather another
version of the branch that has useful changes in it. That might be
Jeff King wrote:
sha1_name.c | 83
++---
1 file changed, 52 insertions(+), 31 deletions(-)
Thanks. I applied this to my series as-it-is.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Jeff King wrote:
There's a fair bit of refactoring involved. I took a stab at it and came
up with the series below. No docs or tests, and some of the refactoring
in remote.c feels a little weird. I can't help but feel more of the
logic from git push should be shared here.
But it at least
Kevin wrote:
Either the documentation is wrong, and should be changed to nth
branch/commit checkout out before the current one, or the behavior of
@{-1} is wrong.
Yeah, the documentation needs to be updated. Patches welcome.
--
To unsubscribe from this list: send the line unsubscribe git in
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t1507-rev-parse-upstream.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index 2a19e79..15f2e7e 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t
.
Thanks.
Jeff King (1):
interpret_branch_name: factor out upstream handling
Ramkumar Ramachandra (2):
t1507 (rev-parse-upstream): fix typo in test title
remote: introduce and fill branch-pushremote
remote.c | 15 ++--
remote.h | 3
-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 83 ++---
1 file changed, 52 insertions(+), 31 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index b1873d8..7ebb8ee 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1046,6 +1046,54
and remote_name; pushremote and pushremote_name.
Helped-by: Jeff King p...@peff.net
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 15 ---
remote.h | 3 +++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/remote.c b/remote.c
index a89efab..286cdce 100644
Jeff King wrote:
2. If the current branch has a branch.*.pushremote set, but we want to
know where a _different_ branch would be pushed, we have no way to
access remote.pushdefault (it gets overwritten in the hunk above).
@{upstream} does not have this problem, because it is
Jeff King wrote:
As far as merging it to 'next', I had not really intended it to go that
far. :) It was more for Ram to use as a base.
Sorry about not having posted a follow-up yet; I'm adjusting to a new
timezone and environment.
I find some of the
refactoring questionable, including:
Hi,
This email tests that 01645b7 (send-email: /etc/ssl/certs/ directory
may not be usable as ca_path, 2014-01-15) doesn't cause a regression.
Ram
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Junio C Hamano wrote:
This change could introduce a regression for people on a platform
whose certificate directory is /etc/ssl/certs but its IO::Socket:SSL
somehow fails to use it as SSL_ca_path without being told.
I can confirm that my git-send-email doesn't regress to the
pre-35035bbf
Jeff King wrote:
- ideas ideas ideas
I'll throw in a few ideas from half-finished work.
1. Speed up git-rebase--am.sh
Currently, git-rebase--am.sh is really slow because it dumps each
patch to a file using git-format-patch, and picks it up to apply
subsequently using git-am. Find a way to
Jeff King wrote:
1. Speed up git-rebase--am.sh
Isn't the merge backend faster? I thought that was the point of it.
I suppose, but I thought git-rebase--am.sh (the default flavor) could
be improved by leveraging relatively new cherry-pick features; I
assumed that the reason it was using
Junio C Hamano wrote:
* jk/branch-at-publish-rebased (2014-01-17) 5 commits
- t1507 (rev-parse-upstream): fix typo in test title
- implement @{publish} shorthand
- branch_get: provide per-branch pushremote pointers
- branch_get: return early on error
- sha1_name: refactor upstream_mark
Replace git-pull and git-merge with the corresponding un-hyphenated
versions. While at it, use ` to mark it up instead of '.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/merge-strategies.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Fix a few minor things.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Philip,
I spotted a few obvious issues with your giteveryday patch in
pu. Maybe Junio can squash this into your patch? Contents are still a
bit stale, but I'm not sure what other markup problems
Philip Oakley wrote:
* po/everyday-doc (2014-01-27) 1 commit
- Make 'git help everyday' work
This may make the said command to emit something, but the source is
not meant to be formatted into a manual pages to begin with, and
also its contents are a bit stale. It may be a good first step in
Felipe Contreras wrote:
@@ -1068,23 +1069,35 @@ static const char *get_upstream_branch(const char
*name_buf, int len)
*/
if (!branch)
die(_(HEAD does not point to a branch));
- if (!branch-merge || !branch-merge[0]-dst) {
- if
Felipe Contreras wrote:
It's more efficient to check for the braces first.
Why is it more efficient? So you can error out quickly in the case of
a malformed string? I'm personally not thrilled about this change.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Felipe Contreras wrote:
sha1_name.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
I like this variable rename. This instance has annoyed me in the past.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Felipe Contreras wrote:
diff --git a/sha1_name.c b/sha1_name.c
index aa3f3e0..a36852d 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -415,9 +415,9 @@ static int ambiguous_path(const char *path, int len)
return slash;
}
-static inline int upstream_mark(const char *string, int len)
Felipe Contreras wrote:
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Please write a commit message, preferably showing the new git-branch output.
I noticed that this only picks up a publish-branch if
branch.*.pushremote is configured. What happened to the case when
Felipe Contreras wrote:
@@ -635,9 +637,10 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
}
if (opts-skip_empty is_index_unchanged() == 1) {
- warning(_(skipping %s... %s),
-
Felipe Contreras wrote:
Akin to 'am --skip' and 'rebase --skip'.
I don't recall why my original sequencer series didn't include this
option. Perhaps Jonathan remembers?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Felipe Contreras wrote:
So that we can load and store rewrites, as well as other operations on a
list of rewritten commits.
Please elaborate. Explain why this code shouldn't go in sequencer.c.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Felipe Contreras wrote:
If no action-name is specified, nothing is done.
Why? Is it because git-rebase implements its own notes-copy-on-rewrite logic?
Otherwise, I agree with the goal of making notes.rewrite.command
work for cherry-pick.
--
To unsubscribe from this list: send the line
Felipe Contreras wrote:
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 43631b4..fd085e1 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -248,7 +248,7 @@ pick_one () {
test -d $rewritten
, it missed this case in
git-rebase--interactive.sh. Since this case is unlike the other cases
which return control for housekeeping, assign it a special return status
and handle that return value explicitly in git-rebase.sh.
Reported-by: Karen Etheridge et...@cpan.org
Signed-off-by: Ramkumar
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 our
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
+`format`. The `format` is copied literally to stdout for each
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,
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, and
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 be
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 seems
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 is
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 -DBACKSAPCE
# er, what was the branch name again?
$ git checkout -
# Ah
$ git checkout
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
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 absolutely necessary atleast in the -i
codepath
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: send the line
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
Andreas Schwab wrote:
Ramkumar Ramachandra artag...@gmail.com 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 = $(git rev-parse
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 read
from
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 body of a
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 list:
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
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 char
Ondřej Bílka wrote:
http://marc.theaimsgroup.com/?l=gitm=112927316408690w=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
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
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 artag...@gmail.com
---
Another candidate for maint?
I'd also really like to squelch
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
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
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 where you got that
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
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 line
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
/home/artagnon/dotfiles
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
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
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 /tmp
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
rm
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
1 - 100 of 1485 matches
Mail list logo