Junio C Hamano wrote:
I have largedir I want to get rid of, but there is a directory
I want to save, largedir/precious, in it, so I do
cp -R largedir/precious precious
and then run 'rm -rf largedir' in another terminal in parallel.
I would argue that there is something
Alessandro Di Marco wrote:
this is a hack I made a couple of years ago in order to store my current
location in git commits (I travel a lot and being able to associate a
place with the commit date helps me to quickly recover what were doing
at that time). Long story short, the screeenshot at
Theodore Ts'o wrote:
Right now I do this just by being careful, but if there was an
automatic safety mechanism, it would save me a bit of work, since
otherwise I might not catch my mistake until I do the git push
publish, at which point I curse and then start consulting the reflog
to back the
Junio C Hamano wrote:
And that was done with extensivility your example implied in mind:
you may later be allowed to push other branches as well to origin.
That is why the refspec definition for 'origin' does not hardcode
the name of the branch you are permitted to push there at this
moment.
Junio C Hamano wrote:
If you have to ask why, and cannot answer the question yourself,
then you would not know if such a caller exists. After a code
audit, I know there is no such caller that appends @{u} but if you
were writing a quick-and-dirty caller, I would not be surprised if
you find
missing something?
Thanks.
(based on rr/die-on-missing-upstream)
Ramkumar Ramachandra (7):
sha1_name: abstract upstream_mark() logic
sha1_name: factor out die_no_upstream()
sha1_name: remove upstream_mark()
remote: expose parse_push_refspec()
remote: expose get_ref_match()
sha1_name
() logic to accept any suffix, while preserving the
upstream_mark() interface.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index
parse_fetch_refspec() is already available to other callers via
remote.h. There's no reason why parse_push_refspec() shouldn't be.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 2 +-
remote.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/remote.c b
Introduce an AT_KIND_PUSH to be represented as @{p[ush]}. Determine
it using branch.remote.push_refspec.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index
Try this now: configure your current branch's pushremote to push to
refs/heads/*:refs/heads/rr/*. Now, type 'git show @{p}'. Voila!
It currently only works when:
1. remote.name.push is explicitly specified.
2. There is a pattern to match (*).
Proof-of-concept only.
Signed-off-by: Ramkumar
We need it.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
remote.c | 2 +-
remote.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index 99c44da..9ae1fc5 100644
--- a/remote.c
+++ b/remote.c
@@ -1168,7 +1168,7 @@ static int
with an upstream_mark() call capturing at_kind and
using it in a switch statement to perform the appropriate action.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index
Junio C Hamano wrote:
I am not saying default=single would be _the_ single right way to
solve it, but when you have default=single, remote.$name.push is
used only to describe the mapping, not forcing you to push
everything out at once is one possible solution to that.
The big advantage it
Theodore Ts'o wrote:
Spekaing of which, what I'd really appreciate is timestamps associated
with the reflog. That's because the most common time when I've
screwed something up is after doing a git rebase -i and so the
reflog has a *huge* number of entries on it, and figuring out which
entry
Ramkumar Ramachandra wrote:
you'd essentially have to grab the remote.name.push refspec, rewrite
it to replace refs/heads/*: with $HEAD: and feed that refspec to the
transport layer
Um, sorry. It involves two independent steps:
1. add_refspec() $HEAD:$HEAD@{push} to feed to the transport
[1/2] clarifies the commit message to say that a grep didn't find
@{u} or @{upstream} hard-coded by any callers. Thanks to Junio.
[2/2] fixes a small grammar error in the commit message. Thanks to
Eric Sunshine.
Ramkumar Ramachandra (2):
sha1_name: fix error message for @{u}
sha1_name: fix
in the first
place? A grep reveals that no part of the code hard-codes either
@{u} or @{upstream}. So, these callers will never hit the
codepath touched by the patch.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 11 +--
t/t1507-rev-parse
has 2005 entries.
$ git show master@{1}
fatal: Log for 'master' only has 7 entries.
Simple, consistent, and informative; suitable for output even from
plumbing commands like rev-parse.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 10 ++
1 file changed
Junio C Hamano wrote:
[...]
I agree with the other comments, and have made suitable changes.
Let's review your block now.
This transformation is used to find filepairs that represent
two kinds of changes, and is controlled by the -S, -G and
--pickaxe-all options.
Why
.
diffcore-order: For Sorting the Output Based on Filenames
-
Ramkumar Ramachandra (2):
diffcore-pickaxe: make error messages more consistent
diffcore-pickaxe doc: document -S and -G properly
Documentation/diff-options.txt | 38
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
)
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 | 43
Hi,
I'm not able to sort completions for some weird reason. No matter
what I order I insert stuff into COMPREPLY, bash seems to auto-sort
them lexically. I tried to pass --sort='-committerdate' to git
for-each-ref so I can get a sensible 'git checkout TAB' reply, and
I'm very annoyed that it
Felipe Contreras wrote:
git push branch@{push}
Is not clear at all: push push of branch?
We can pick the name later. I had to pick a name to write code, and
that happens to be @{push}.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
. :track[short] is a formatp like :short.
There is no need to use a hammer and coerce everything into an atom,
or throw everything out the window and start from scratch to conform
to pretty-formats perfectly. Let's extend the existing format to be
_useful_ sensibly.
Thanks.
Ramkumar Ramachandra (3
)
to display a red asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/for-each-ref.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 1563b25..63d3a85 100644
:
%C(green)%(refname:short)%C(reset)
To display refs in green. Future patches will attempt to extend the
format even more to get useful output.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/for-each-ref.c | 26 ++
1 file changed, 22 insertions(+), 4
)%(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 artag...@gmail.com
---
builtin/for-each-ref.c | 42
Duy Nguyen wrote:
Usefulness is one thing. Another is maintenance and in that regard I
still think we should be able to remove -v and -vv code (not the
functionality) with this topic.
Why? The topic adds good functionality, doesn't break anything,
doesn't paint us into any corner, and has
Phil Hord wrote:
It fits the beginning of the
document where it says this:
Ah, I missed that. Either way, I'm quite happy with v3: we can change
the first paragraph to use the word transformation if we really
want.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of
Duy Nguyen wrote:
On Thu, May 23, 2013 at 10:12 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Try this now: configure your current branch's pushremote to push to
refs/heads/*:refs/heads/rr/*. Now, type 'git show @{p}'. Voila!
Voila what? Why not avoid guessing game and describe what
SZEDER Gábor wrote:
I don't know who does the sorting (Bash or readline), and I don't know
any way to disable it.
Damn; so it's impossible to have a custom-sorted completion list in
bash. Any idea about zsh? I know that there are completion groups,
but I'd really like custom sorting.
--
To
Duy Nguyen wrote:
Then show @{p} should show the tip commit of rr/master, not the ref
name.
Yes, that is correct.
rev-parse (with an option, maybe) may be a better place for
this.
Er, no. I actually want things like diff @{p}..HEAD. I want it to be
a first-class revision, just like @{u}.
Junio C Hamano wrote:
What is this meant to update? I recall rewriting this part on
purpose.
I was being verbose to show that I handle the detached HEAD case too,
which I missed last time.
Even though it appears unusual and invites confusion, it is very
consistent to say '' when the user
Junio C Hamano wrote:
That is why I rewrote it like so:
The empty string '' is confusing and does not convey information
about whose logs we are inspecting. Change this so that...
Ah, I didn't notice the rewrite in pu. Thanks.
--
To unsubscribe from this list: send the line
Junio C Hamano wrote:
I am having this feeling that we see more and more of this line of
bad behaviours from some on the list recently to call something that
is working in which they find itch using unnecessarily derogatory
terms, and it makes people simply avoid any discussion that starts
Junio C Hamano wrote:
Yes, the aim of the topic should be to make the machinery flexible
enough so that we can lose -v/-vv implementation and replace them
with calls to the new machinery with canned set of output format
templates.
Definitely. I don't want to keep my ugly alias around
Junio C Hamano wrote:
rev-parse (with an option, maybe) may be a better place for
this.
Er, no. I actually want things like diff @{p}..HEAD. I want it to be
a first-class revision, just like @{u}.
I think Duy's suggestion makes perfect sense; rev-parse already has
a mechanism to expand
Antoine Pelisse wrote:
I think sorting is required for faster look-up, most likely with
dichotomic search. Otherwise it would have to search the whole list
each time.
Oh, it's probably keeping just one copy of the completions in memory
(which has to be sorted for search); this is also used to
Duy Nguyen wrote:
Ram, fetch the url above again. Its tip now is 5b4aa27 (for-each-ref:
introduce format specifier %(*) and %(*) - 2013-05-25). Those
changes make for-each-ref --format a superset of pretty. You can add
new %(xxx) on top and resend the whole thing to the list for review.
You
Antoine Pelisse wrote:
Is it not possible for color to be used uninitialized here ?
My compiler didn't complain; what am I missing? Doesn't the
declaration char color[COLOR_MAXLEN]; initialize an empty string?
More importantly, aren't there numerous instances of this in the
codebase?
--
To
David Aguilar wrote:
Can you please also update Documentation/?
Yeah, will do in the re-roll. Duy is bringing in pretty-formats.
We'll probably need a separate document called pretty-ref-formats or
some such thing.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
John Keeping wrote:
Section 6.7.9 of the C11 standard says:
If an object that has automatic storage duration is not initialized
explicitly, its value is indeterminate.
Ah, thanks. I'll initialize it to an empty string.
More importantly, aren't there numerous instances of this in
via -m.
Reported-by: Mislav Marohnić mislav.maroh...@gmail.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/commit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/commit.c b/builtin/commit.c
index d2f30d9..1f5da9d 100644
--- a/builtin/commit.c
+++ b/builtin
Ramkumar Ramachandra wrote:
builtin/commit.c | 2 ++
1 file changed, 2 insertions(+)
I just made this dependent on the order in which options are parsed.
If --allow-empty-message is specified before -m , it works.
Otherwise, not.
Sorry about the stupidity.
--
To unsubscribe from this list
launching $EDITOR.
Reported-by: Mislav Marohnić mislav.maroh...@gmail.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Works?
builtin/commit.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d2f30d9..7d72ba7 100644
Antoine Pelisse wrote:
So now we have two fixes for the same issue, don't we ?
You probably missed $gmane/225534.
Gah, missed that. Sorry for the noise.
--
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
Hi Duy,
I just woke up and started looking at the series: it's rather well
done, and I'm confident that this is the way forward. To reciprocate,
I've done some work at gh:artagnon/git for-each-ref-pretty. See:
https://github.com/artagnon/git/commits/for-each-ref-pretty
There is one major
Oh, and by the way:
We're pretty close we are to replacing branch -v and branch -vv.
brv = for-each-ref --format='%(HEAD)
%C(green)%(*)%(refname:short)%C(reset) %(*)%(objectname:short)
%(subject)' refs/heads
brvv = for-each-ref --format='%(HEAD)
%C(green)%(*)%(refname:short)%C(reset)
Ramkumar Ramachandra wrote:
%(N) doesn't work properly with f-e-r, and I'm not sure why. I'm not
talking about your last patch where you compute * -- that works fine;
it's just that %(N) doesn't when N is a concrete number.
Try this:
%(refname:short)%(30)%(upstream:short)
(assuming that you
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
Junio C Hamano wrote:
Is there something you're not happy with?
By the way, you probably should stop thinking in terms of me being
(un)happy. I am just trying to help by preventing (collectively) us
making silly mistakes.
As a general principle, okay.
IIRC, nobody else had comments on this
Bráulio Bhavamitra wrote:
root = rev-parse --show-toplevel
What is your usecase for this?
upstream = !git for-each-ref --format='%(upstream:short)' $(git
symbolic-ref -q HEAD)
Again, what is the usecase? What doesn't @{u} do?
upstream-remote = !git upstream | sed -e 's/\\/.*$//g'
The commit message in [3/3] is rewritten although I've mentioned the
original motivation at the end.
No other changes.
Ramkumar Ramachandra (3):
push: factor out the detached HEAD error message
push: fail early with detached HEAD and current
push: make push.default = current resolve HEAD
is not unique to upstream or simple: current cannot push with
a detached HEAD either. So, factor out the error string in preparation
for using it in current.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/push.c | 14 --
1 file changed, 8 insertions(+), 6 deletions
are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push ram HEAD:name-of-remote-branch
Just like in the upstream and simple cases.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/push.c | 4
1 file changed, 4
with the 'git push' on the first terminal. Although this patch does not
solve the core problem (there is still no guarantee that 'git push' on
the first terminal will resolve HEAD before 'git checkout' changes HEAD
on the second), it works in practice.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
Junio C Hamano wrote:
case PUSH_DEFAULT_CURRENT:
+ if (!branch)
+ die(_(message_detached_head_die), remote-name);
add_refspec(HEAD);
break;
Would it hurt to do
if (!branch_get(NULL))
die(...);
Felipe Contreras wrote:
On Wed, May 29, 2013 at 1:26 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Bráulio Bhavamitra wrote:
root = rev-parse --show-toplevel
What is your usecase for this?
Some Git commands expect to be in the top level directory (e.g. git blame).
Um, git blame
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 top
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 override.
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 unsubscribe
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 :(top)
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
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?
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
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 ()
-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
201 - 300 of 1485 matches
Mail list logo
