Re: Poor performance of git describe in big repos
On 31 May 2013 10:57, Alex Bennée kernel-hac...@bennee.com wrote: On 31 May 2013 09:46, Thomas Rast tr...@inf.ethz.ch wrote: So that deleted all unannotated tags pointing at commits, and then it was fast. Curious. However, if that turns out to be the culprit, it's not fixable currently[1]. Having commits with insanely long messages is just, well, insane. [1] unless we do a major rework of the loading infrastructure, so that we can teach it to load only the beginning of a commit as long as we are only interested in parents and such I'll do a bit of scripting to dig into the nature of these uber-commits and try and work out how they cam about. I suspect they are simply start of branch states in our broken and disparate history. I'll get back to you once I've dug a little deeper. So I wrote a little script [1] which I ran to remove all tags that did not exist on any branches: git-tag-cleaner.py -d no-branch After a lot of churning: 17:26 ajb@sloy/x86_64 [work.git] time /usr/bin/git --no-pager describe --long --tags ajb-build-test-5225-2-gdc0b771 real0m0.799s user0m0.024s sys 0m0.052s So at least I can fix up my repo. All the big ones look at least as though they were weird cvs2svn creations that exist to represent the detached state of a strange CVS tag from the converted repository. However it does raise one question. Why is git attempting to parse a commit not on the DAG for the branch I'm attempting to describe? Anyway as I have a work around I'm going to do a slightly more conservative clean of the repo with my script and move on. [1] https://github.com/stsquad/git-tag-cleaner -- Alex, homepage: http://www.bennee.com/~alex/ -- 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
Re: [PATCH 3/6] completion: add common options for blame
Ramkumar Ramachandra artag...@gmail.com writes:
Add support for completing 'git blame'. List only the common short
options.
[...]
+_git_blame ()
+{
+ __git_has_doubledash return
+
+ case $cur in
+ -*)
+ __gitcomp -M -C -L -s -w
+ esac
+ __git_complete_revlist_file
+}
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.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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
Re: [PATCH 3/6] completion: add common options for blame
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 not have equivalent long-forms. -- 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
Re: [PATCH 1/6] prompt: don't scream continuation state
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 introduce a color in this series because it would conflict with rr/zsh-color-prompt which is in pu: we can introduce it after that graduates. I was thinking yellow, since that's not taken? You really should use colors. I don't think it's worth the extra ugliness to scream in the no-color case. As such, the prompt is a fine bikeshedding target. I even introduced GIT_PS1_SEPARATOR, because some people were unhappy with me stripping one whitespace (yes, one). If we go down the configurability road, we'll either end up with a ton of environment variables, or be made to write a generalized custom formatter which splices together tons of arguments using color (super painful). While I do agree that it is a matter of taste, we have to make a few compromises for the sake of sanity. -- 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
Re: [RFC v2] reflog: show committer date in verbose mode
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 format-specifiers. Why not add to the list of pretty-format specifiers (like oneline, short, medium, full)? Also, this patch is extremely pervasive in that it teaches a poorly defined verbosity to a very low layer: revision.c/revision.h. -- 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
[PATCH] relnotes: fix spelling error in 1.8.4.txt
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 .emacs to catch this early. Documentation/RelNotes/1.8.4.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/RelNotes/1.8.4.txt b/Documentation/RelNotes/1.8.4.txt index 14835d1..0e08bf4 100644 --- a/Documentation/RelNotes/1.8.4.txt +++ b/Documentation/RelNotes/1.8.4.txt @@ -36,7 +36,7 @@ UI, Workflows Features did not update refs/remotes/origin/master; this was an early design decision to keep the update of remote tracking branches predictable, but in practice it turns out that people find it more - convenient to opportunisticly update them whenever we have a + convenient to opportunistically update them whenever we have a chance, and we have been updating them when we run git push which already breaks the original predictability anyway. -- 1.8.3.114.gcd03571 -- 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
Re: What's cooking in git.git (Jun 2013, #01; Sun, 2)
Duy Nguyen pclo...@gmail.com writes: On Mon, Jun 3, 2013 at 6:58 AM, Junio C Hamano gits...@pobox.com wrote: [Graduated to master] * tr/line-log (2013-04-22) 13 commits (merged to 'next' on 2013-04-22 at 8f2c1de) Should I resend nd/magic-pathspecs again now that all three topics that cause a lot of conflicts with it have graduated? Some conflicts (again) with pu but should be easy to resolve. The biggest one is jc/add-2.0-ignore-removal but that's basically a code deletion, I think you can handle it. Sounds good, thanks. I have a bit of backlog so I may not be able to get around to it for a few days, though. -- 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
Re: What's cooking in git.git (May 2013, #09; Wed, 29)
John Keeping j...@keeping.me.uk writes: I started looking at this over the weekend but didn't get time to get something ready to be submitted. I did find a couple of issues in cmd_foreach that make me think this topic should be dropped when next is rewound and held in pu waiting for a re-roll. Thanks for a heads-up. -- 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
Re: [PATCH v2 FIXUP 22/25] fixup! string_list_add_refs_by_glob(): add a comment about memory management
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Junio, would you mind squashing this patch onto mh/reflife 22/25?
Done. Thanks.
notes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/notes.c b/notes.c
index 602d956..b69c0b8 100644
--- a/notes.c
+++ b/notes.c
@@ -932,6 +932,7 @@ static int string_list_add_one_ref(const char *refname,
const unsigned char *sha
*/
void string_list_add_refs_by_glob(struct string_list *list, const char *glob)
{
+ assert(list-strdup_strings);
if (has_glob_specials(glob)) {
for_each_glob_ref(string_list_add_one_ref, glob, list);
} else {
--
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
Re: [PATCH v2 2/6] send-email: fix suppress-cc=self on cccmd
Michael S. Tsirkin m...@redhat.com writes:
When cccmd is used, old-style suppress-from filter
is applied by the newer suppress-cc=self isn't.
Fix this up.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
git-send-email.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index bd13cc8..a138615 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1462,7 +1462,7 @@ sub recipients_cmd {
$address =~ s/^\s*//g;
$address =~ s/\s*$//g;
$address = sanitize_address($address);
- next if ($address eq $sanitized_sender and $suppress_from);
+ next if ($address eq $sender and $suppress_cc{'self'});
If $suppress_from is defined, $suppress_cc{'self'} gets its value,
so the latter half of this change is very understandable.
The original comparison uses $address that is sanitized (whose
definition is roughly mangled/quoted with rfc2047 etc to fit on
To/Cc headers) against $sanitized_sender, which means for a
$sender = 'Michael S. Tsirkin m...@redhat.com';
we used
$sanitized_sender = 'Michael S. Tsirkin m...@redhat.com';
for comparison, but the new code does not quote the $recipient_name
part inside dq for the single dot after the middle name. Is this a
desirable change?
push @addresses, $address;
printf(($prefix) Adding %s: %s from: '%s'\n,
$what, $address, $cmd) unless $quiet;
--
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
Re: [PATCH v2 7/7] unpack-trees: free cache_entry array members for merges
Am 03.06.2013 02:04, schrieb Felipe Contreras: On Sun, Jun 2, 2013 at 6:47 PM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Am 03.06.2013 01:23, schrieb Felipe Contreras: I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I said we should do 'if (cd ce != o-df_conflict_entry)' instead of 'if (ce != o-df_conflict_entry)'. I did assume you meant the latter. There's no reason not to. Only the minor ones already mentioned: More text, Five characters. one more branch in object code, Which might actually be more optimal. The difference in absolute numbers will most certainly be within the noise for this one case. no benefit except for some hypothetical future case that's caught by the test suite anyway -- or by code review. That's not the benefit, the benefit is that the code is clearer. I don't see that, and I don't like adding a check that I don't expect to be ever needed. Users are safe because the test suite is going to catch a missing check. In general, I think those who introduce dependencies should add the necessary checks. They have to consider the invariants anyway, no matter how many checks you add beforehand for their convenience. I wonder if we already reached the point where we spent more time discussing this change than the time needed by the envisioned developer to find and fix the NULL check that suddenly became necessary. :) Maybe, but if what you want is to avoid the discussion, you could just add the extra five characters and be done with it. Or you could submit a patch on top that adds the check. I'd send it out if you'd supply a commit message. My review comment would be mostly harmless, but I don't like it very much because it's not needed now and probably won't ever. But I'm more interested in a different way forward: Would it make sense to push the allocations (and frees) into the merge functions? Currently they duplicate one of the cache entries. Would the merge functions become too ugly or too big if they'd have to build them themselves, avoiding duplication? Would it be significantly faster? René -- 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
Re: [PATCH v2 0/6] git send-email suppress-cc=self fixes
Michael S. Tsirkin m...@redhat.com writes: This includes bugfixes related to handling of --suppress-cc=self flag. Tests are also included. Thanks, will queue. -- 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
Re: [PATCH v2 1/6] t/send-email.sh: add test for suppress-cc=self
Michael S. Tsirkin m...@redhat.com writes:
This adds a basic test for --suppress-cc=self
option of git send-email.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
t/t9001-send-email.sh | 43 +++
1 file changed, 43 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index ebd5c5d..e1a7f3e 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -171,6 +171,49 @@ Result: OK
EOF
+test_suppress_self () {
+ test_commit $3
+ test_when_finished git reset --hard HEAD^
+
+ write_script cccmd-sed -EOF
+ sed -n -e s/^cccmd--//p \$1
+ EOF
+
+ git commit --amend --author=$1 $2 -F -
Ahh, this helper reads the log message from its standard input;
nice.
+ clean_fake_sendmail
+ git format-patch --stdout -1 suppress-self-$3.patch
+
+ git send-email --from=$1 $2 \
+ --to=nob...@example.com \
+ --cc-cmd=./cccmd-sed \
+ --suppress-cc=self \
+ --smtp-server=$(pwd)/fake.sendmail \
+ suppress-self-$3.patch
+
+ mv msgtxt1 msgtxt1-$3
+ sed -e '/^$/q' msgtxt1-$3 msghdr1-$3
+ expected-no-cc-$3
+
+ (grep '^Cc:' msghdr1-$3 actual-no-cc-$3;
+ test_cmp expected-no-cc-$3 actual-no-cc-$3)
+}
+
+test_suppress_self_unquoted () {
+ test_suppress_self $1 $2 unquoted-$3 -EOF
+ test suppress-cc.self unquoted-$3 with name $1 email $2
+
+ unquoted-$3
+
+ Cc: $1 $2
+ Signed-off-by: $1 $2
+ EOF
+}
+
+test_expect_success $PREREQ 'self name is suppressed'
+ test_suppress_self_unquoted 'A U Thor' 'aut...@redhat.com' \
+ 'self_name_suppressed'
+
+
test_expect_success $PREREQ 'Show all headers' '
git send-email \
--dry-run \
--
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
Re: Poor performance of git describe in big repos
Alex Bennée kernel-hac...@bennee.com writes: Why is git attempting to parse a commit not on the DAG for the branch I'm attempting to describe? I think that is because you need to parse the objects at the tip of refs to see if they are on the DAG in the first place. If there weren't any annotated tag, conceivably you could do without parsing these objects. You would: - First read the refs without parsing anything to learn the object name of the tips of refs; - Traverse the DAG, starting from the commit and notice when you see commits that are at the tips of refs you learned in the first step, arranging to stop when you found the closest tip. But with annotated tags (and git describe is designed to be primarily used with them; you would need --tags option to make it notice unannotated tags), the object name you see sitting at the tip will never appear during the DAG traversal. You will only see commits from the latter, so you would need to parse the tips to learn what commits they refer to. And of course, then parse only annotated tags, without parsing commits would not work, because you wouldn't know what the object is without looking at it ;-) -- 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
Re: [PATCH v2 4/6] send-email: make --suppress-cc=self sanitize input
On Mon, Jun 03, 2013 at 09:17:21AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
--suppress-cc=self fails to filter sender address in many cases where it
needs to be sanitized in some way, for example quoted:
A U. Thor aut...@example.com
To fix, make send-email sanitize both sender and the address it is
compared against.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
OK, so you are getting rid of distinctions between sanitized_sender
and sender, and $sender is now defined to be always sanitized
form.
That change makes things consistent with respect to the question I
had on [2/6].
I however wondered how this would affect those who have configured
sendemail.from with an already sanitized address. That is, you
may have used:
[sendemail]
from = Michael S. Tsirkin m...@redhat.com
with the older and current versions of Git. I _think_ the safetly
of this change relies on that it is a no-op to run sanitize_address
on an already sanitized address (i.e. feeding the above example
sendemail.from to sanitize_address gives back the same string),
which holds true for all practical purposes, but it is a bit subtle.
Yes, I think so too. So - what do you suggest?
Add a test?
Add a comment?
more?
git-send-email.perl | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index a138615..92df393 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -760,6 +760,8 @@ if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
}
+$sender = sanitize_address($sender);
+
my $prompting = 0;
if (!@initial_to !defined $to_cmd) {
my $to = ask(Who should the emails be sent to (if any)? ,
@@ -1113,10 +1115,9 @@ sub send_message {
if ($cc ne '') {
$ccline = \nCc: $cc;
}
- my $sanitized_sender = sanitize_address($sender);
make_message_id() unless defined($message_id);
- my $header = From: $sanitized_sender
+ my $header = From: $sender
To: $to${ccline}
Subject: $subject
Date: $date
@@ -1133,7 +1134,7 @@ X-Mailer: git-send-email $gitversion
}
my @sendmail_parameters = ('-i', @recipients);
- my $raw_from = $sanitized_sender;
+ my $raw_from = $sender;
if (defined $envelope_sender $envelope_sender ne auto) {
$raw_from = $envelope_sender;
}
@@ -1308,8 +1309,9 @@ foreach my $t (@files) {
}
elsif (/^From:\s+(.*)$/i) {
($author, $author_encoding) =
unquote_rfc2047($1);
+ my $sauthor = sanitize_address($author);
next if $suppress_cc{'author'};
- next if $suppress_cc{'self'} and $author eq
$sender;
+ next if $suppress_cc{'self'} and $sauthor eq
$sender;
printf((mbox) Adding cc: %s from line '%s'\n,
$1, $_) unless $quiet;
push @cc, $1;
@@ -1323,7 +1325,9 @@ foreach my $t (@files) {
}
elsif (/^Cc:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
- if (unquote_rfc2047($addr) eq $sender) {
+ my $qaddr = unquote_rfc2047($addr);
+ my $saddr = sanitize_address($qaddr);
+ if ($saddr eq $sender) {
next if ($suppress_cc{'self'});
} else {
next if ($suppress_cc{'cc'});
@@ -1370,7 +1374,8 @@ foreach my $t (@files) {
chomp;
my ($what, $c) = ($1, $2);
chomp $c;
- if ($c eq $sender) {
+ my $sc = sanitize_address($c);
+ if ($sc eq $sender) {
next if ($suppress_cc{'self'});
} else {
next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
@@ -1454,7 +1459,6 @@ foreach my $t (@files) {
sub recipients_cmd {
my ($prefix, $what, $cmd, $file) = @_;
- my $sanitized_sender = sanitize_address($sender);
my @addresses = ();
open my $fh, -|, $cmd \Q$file\E
or die ($prefix) Could not execute '$cmd';
--
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
Re: [PATCH v2 0/6] git send-email suppress-cc=self fixes
On Mon, Jun 03, 2013 at 09:18:56AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: This includes bugfixes related to handling of --suppress-cc=self flag. Tests are also included. Thanks, will queue. OK pls let me know if this means you intend to handle the rest of your comments yourself or if I need to fix anything. -- 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
Re: [PATCH v2 7/7] unpack-trees: free cache_entry array members for merges
On Mon, Jun 3, 2013 at 10:59 AM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Am 03.06.2013 02:04, schrieb Felipe Contreras: On Sun, Jun 2, 2013 at 6:47 PM, René Scharfe rene.scha...@lsrfire.ath.cx wrote: Am 03.06.2013 01:23, schrieb Felipe Contreras: I didn't say we should do 'if (ce) free(ce);' instead of 'free(ce);' I said we should do 'if (cd ce != o-df_conflict_entry)' instead of 'if (ce != o-df_conflict_entry)'. I did assume you meant the latter. There's no reason not to. Only the minor ones already mentioned: More text, Five characters. one more branch in object code, Which might actually be more optimal. The difference in absolute numbers will most certainly be within the noise for this one case. If you want to ignore the performance, you should ignore the branch as well. no benefit except for some hypothetical future case that's caught by the test suite anyway -- or by code review. That's not the benefit, the benefit is that the code is clearer. I don't see that, and I don't like adding a check that I don't expect to be ever needed. It's called self-documenting code; by adding a check for the NULL pointer, we are stating that ce can be NULL, if we don't do that, people reading that code would need to figure that out themselves. Or you could submit a patch on top that adds the check. I already sent a patch that has that check. http://article.gmane.org/gmane.comp.version-control.git/225972 -- Felipe Contreras -- 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
Re: [PATCH v2 4/6] send-email: make --suppress-cc=self sanitize input
Michael S. Tsirkin m...@redhat.com writes:
--suppress-cc=self fails to filter sender address in many cases where it
needs to be sanitized in some way, for example quoted:
A U. Thor aut...@example.com
To fix, make send-email sanitize both sender and the address it is
compared against.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
OK, so you are getting rid of distinctions between sanitized_sender
and sender, and $sender is now defined to be always sanitized
form.
That change makes things consistent with respect to the question I
had on [2/6].
I however wondered how this would affect those who have configured
sendemail.from with an already sanitized address. That is, you
may have used:
[sendemail]
from = Michael S. Tsirkin m...@redhat.com
with the older and current versions of Git. I _think_ the safetly
of this change relies on that it is a no-op to run sanitize_address
on an already sanitized address (i.e. feeding the above example
sendemail.from to sanitize_address gives back the same string),
which holds true for all practical purposes, but it is a bit subtle.
git-send-email.perl | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index a138615..92df393 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -760,6 +760,8 @@ if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
}
+$sender = sanitize_address($sender);
+
my $prompting = 0;
if (!@initial_to !defined $to_cmd) {
my $to = ask(Who should the emails be sent to (if any)? ,
@@ -1113,10 +1115,9 @@ sub send_message {
if ($cc ne '') {
$ccline = \nCc: $cc;
}
- my $sanitized_sender = sanitize_address($sender);
make_message_id() unless defined($message_id);
- my $header = From: $sanitized_sender
+ my $header = From: $sender
To: $to${ccline}
Subject: $subject
Date: $date
@@ -1133,7 +1134,7 @@ X-Mailer: git-send-email $gitversion
}
my @sendmail_parameters = ('-i', @recipients);
- my $raw_from = $sanitized_sender;
+ my $raw_from = $sender;
if (defined $envelope_sender $envelope_sender ne auto) {
$raw_from = $envelope_sender;
}
@@ -1308,8 +1309,9 @@ foreach my $t (@files) {
}
elsif (/^From:\s+(.*)$/i) {
($author, $author_encoding) =
unquote_rfc2047($1);
+ my $sauthor = sanitize_address($author);
next if $suppress_cc{'author'};
- next if $suppress_cc{'self'} and $author eq
$sender;
+ next if $suppress_cc{'self'} and $sauthor eq
$sender;
printf((mbox) Adding cc: %s from line '%s'\n,
$1, $_) unless $quiet;
push @cc, $1;
@@ -1323,7 +1325,9 @@ foreach my $t (@files) {
}
elsif (/^Cc:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
- if (unquote_rfc2047($addr) eq $sender) {
+ my $qaddr = unquote_rfc2047($addr);
+ my $saddr = sanitize_address($qaddr);
+ if ($saddr eq $sender) {
next if ($suppress_cc{'self'});
} else {
next if ($suppress_cc{'cc'});
@@ -1370,7 +1374,8 @@ foreach my $t (@files) {
chomp;
my ($what, $c) = ($1, $2);
chomp $c;
- if ($c eq $sender) {
+ my $sc = sanitize_address($c);
+ if ($sc eq $sender) {
next if ($suppress_cc{'self'});
} else {
next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
@@ -1454,7 +1459,6 @@ foreach my $t (@files) {
sub recipients_cmd {
my ($prefix, $what, $cmd, $file) = @_;
- my $sanitized_sender = sanitize_address($sender);
my @addresses = ();
open my $fh, -|, $cmd \Q$file\E
or die ($prefix) Could not execute '$cmd';
--
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
Re: [PATCH 1/4] read-cache: fix wrong 'the_index' usage
Felipe Contreras felipe.contre...@gmail.com writes:
We are dealing with the 'istate' index, not 'the_index'.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Good catch; will apply.
read-cache.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index 04ed561..5253ec5 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -626,7 +626,7 @@ int add_to_index(struct index_state *istate, const char
*path, struct stat *st,
if (*ptr == '/') {
struct cache_entry *foundce;
++ptr;
- foundce = index_name_exists(the_index,
ce-name, ptr - ce-name, ignore_case);
+ foundce = index_name_exists(istate, ce-name,
ptr - ce-name, ignore_case);
if (foundce) {
memcpy((void *)startPtr, foundce-name
+ (startPtr - ce-name), ptr - startPtr);
startPtr = ptr;
--
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
Re: [PATCH 3/4] unpack-trees: trivial cleanup
Felipe Contreras felipe.contre...@gmail.com writes:
dfc has not been initialized at this point.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Upon the first entry to this function, because dfc is
static struct cache_entry *dfc;
it is NULL. In that case, we allocate one instance. When the
function is called again, we can reuse the entry, because it merely
acts as a unique sentinel value.
And we do not free() it.
unpack-trees.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index ede4299..36f4ff7 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1040,8 +1040,7 @@ int unpack_trees(unsigned len, struct tree_desc *t,
struct unpack_trees_options
if (!o-skip_sparse_checkout)
mark_new_skip_worktree(o-el, o-src_index, 0,
CE_NEW_SKIP_WORKTREE);
- if (!dfc)
- dfc = xcalloc(1, cache_entry_size(0));
+ dfc = xcalloc(1, cache_entry_size(0));
o-df_conflict_entry = dfc;
if (len) {
--
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
Re: [PATCH v2 1/7] add simple tests of consistency across rebase types
On Tue, May 28, 2013 at 11:39 PM, Martin von Zweigbergk martinv...@gmail.com wrote: create mode 100755 t/t3420-rebase-topology-linear.sh Just FYI, there's another test case with the same number (t3420-rebase-autostash) in pu. I don't know how you normally handle such cases. -- 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
Re: preventing evil merges
Sandro Santilli s...@keybit.net writes: git merge anotherbranch git add something git commit --amend After the steps above the addition of something can't be found in the history anymore, but the file is there. This is a very common and sensible thing to do when dealing with semantic conflict. Imagine that you changed the name of a global variable in the code on your current branch since the anotherbranch you are pulling from forked from you. Then imagine further that the anotherbranch added one location that refers to that variable. Since they are not aware of the name change, they added the new reference with the old variable name. The part they added is a new code, so it is very likely that there is no textual conflict when you did git merge anotherbranch. But now the result is broken. And you fix that semantic conflict by editing the file they added the new reference to the variable under the old name and make it use the variable with the new name. You git add something and amend the merge. git show of the result will show you what happened, I think. -- 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
Re: git daemon --access-hook problem
On Fri, May 31, 2013 at 10:22 PM, Eugene Sajine eugu...@gmail.com wrote: and trying to perform some operations like fetch or push. It is cloned and fetches and pushes successfully. The problem is that the file test_hook_out.txt doesn't have anything in it after the execution, So the hook doesn't seem to work. What might be the issue here? I have no idea what the issue might be, but here's how I usually debug this kind of situations: - Exit with a non-zero value will make it an error, try exit 1 at the end of your script, you will know if it's executed or not - Your log file might not be located where you expect, you should use absolute path to dump text - Dump the cwd to know where it's executed from - The documentation says you can print one line before a failure, also try this to show the cwd Hope that helps, Antoine, -- 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
Re: [PATCH 1/6] prompt: don't scream continuation state
Thomas Rast tr...@inf.ethz.ch writes: Ramkumar Ramachandra artag...@gmail.com writes: Currently, when performing any operation that saves the state and expects the user the continue (like rebase, bisect, am), the prompt screams: artagnon|completion|REBASE-i 2/2:~/src/git$ Lowercase the words, so we get a more pleasant artagnon|completion|rebase-i 2/2:~/src/git$ So I'm not sure whether this falls under bikeshedding or actual features, but I like the screaming. Sounds like bikeshedding. My personal opinion is that detached in the middle of something is not a normal state, and it deserves to be in bold as a reminder. Let's leave it as-is. -- 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
Re: [PATCH 3/6] completion: add common options for blame
Thomas Rast tr...@inf.ethz.ch writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Add support for completing 'git blame'. List only the common short
options.
[...]
+_git_blame ()
+{
+__git_has_doubledash return
+
+case $cur in
+-*)
+__gitcomp -M -C -L -s -w
+esac
+__git_complete_revlist_file
+}
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, I do not think this is a good idea.
--
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
Re: crash on git diff-tree -Ganything tree for new files with textconv filter
On 2012-11-07 22:13, Jeff King wrote: On Wed, Nov 07, 2012 at 10:10:59PM +0100, Peter Oberndorfer wrote: For me the key to reproduce the problem was to have 2 commits. Adding the file in the root commit it did not work. [1] You probably would need to pass --root for it to do the diff of the initial commit. The patch below fixes it, but it's terribly inefficient (it just detects the situation and reallocates). It would be much better to disable the reuse_worktree_file mmap when we populate the filespec, but it is too late to pass an option; we may have already populated from an earlier diffcore stage. Hi, I tested your patch, and i can confirm it fixes the problem for me. (also on my real world test in msysgit) Thanks for the report. I'd still like to pursue using a regex library that does not require NUL-termination, but I've been distracted by other things. I'm going to hold back my copy-to-a-NUL-buffer patch for now and see if I can get to the regex thing this week. Hi, are there any news regarding this problem? The crash seems to still exist in the current version 1.8.3 and master. Thanks, Greetings Peter -- 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
Re: [PATCH 5/6] completion: clarify difftool completion
Ramkumar Ramachandra artag...@gmail.com writes: 'git difftool' is clearly a frontend to 'git diff' and is used in exactly the same way, but it uses a misleading completion function name __git_complete_file (aliased to to __git_complete_revlist_file). Change it to use __git_complete_revlist_file, just like 'git diff'. No functional changes. Makes sense. The completion helper for both revname and pathname should not be called __git_complete_file, and this is a step in the right direction. If we have a situation where we _know_ we only want to complete pathname and never revname, we may want to keep __git_complete_file function. For example, after seeing -- on the command line, we may want to use __git_complete_file (that does not look at revs, instead of __git_complete_revlist_file function. Will apply. Thanks. 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/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1305,7 +1305,7 @@ _git_difftool () return ;; esac - __git_complete_file + __git_complete_revlist_file } __git_fetch_options= -- 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
Re: [PATCH 6/6] completion: clarify ls-tree, archive, show completion
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, the 'git ls-tree', 'git archive', and 'git show' completions
use __git_complete_file (aliased to __git_complete_revlist_file).
In the case of 'git ls-tree' and 'git archive', they necessarily require
a tree-ish argument (and optionally a pathspec filter, or file
argument):
$ git ls-tree hot-branch git.c
$ git archive HEAD~4 git.c
So, __git_complete_file is a misleading name.
In the case of 'git show', it can take a pathspec and default the
revision to HEAD like:
$ git show git.c
(which is useful if git.c was modified in HEAD)
However, this usage is not idiomatic at all. The more common usage is
like:
$ git show HEAD~1
$ git show origin/pu:git.c
So, __git_complete_file is again a poor name.
Replace these three instances of __git_complete_file with
__git_complete_revlist_file, without making any functional changes.
Remove __git_complete_file, as it has no other callers.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
I think this is the same as 5/6 and better explained in a single
patch, as the rationale is the same: these commands can all take the
usual revs and then paths, so using misnamed complete_FILE helper is
wrong.
Mind if I squashed them together?
contrib/completion/git-completion.bash | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 8d70c30..84d1548 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -592,11 +592,6 @@ __git_complete_diff_index_file ()
esac
}
-__git_complete_file ()
-{
- __git_complete_revlist_file
-}
-
__git_complete_revlist ()
{
__git_complete_revlist_file
@@ -1007,7 +1002,7 @@ _git_archive ()
return
;;
esac
- __git_complete_file
+ __git_complete_revlist_file
}
_git_bisect ()
@@ -1476,7 +1471,7 @@ _git_ls_remote ()
_git_ls_tree ()
{
- __git_complete_file
+ __git_complete_revlist_file
}
# Options that go well for log, shortlog and gitk
@@ -2382,7 +2377,7 @@ _git_show ()
return
;;
esac
- __git_complete_file
+ __git_complete_revlist_file
}
_git_show_branch ()
--
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
Re: preventing evil merges
On Mon, Jun 3, 2013 at 7:20 PM, Junio C Hamano gits...@pobox.com wrote: Sandro Santilli s...@keybit.net writes: git merge anotherbranch git add something git commit --amend After the steps above the addition of something can't be found in the history anymore, but the file is there. This is a very common and sensible thing to do when dealing with semantic conflict. Imagine that you changed the name of a global variable in the code on your current branch since the anotherbranch you are pulling from forked from you. Then imagine further that the anotherbranch added one location that refers to that variable. Since they are not aware of the name change, they added the new reference with the old variable name. The part they added is a new code, so it is very likely that there is no textual conflict when you did git merge anotherbranch. But now the result is broken. And you fix that semantic conflict by editing the file they added the new reference to the variable under the old name and make it use the variable with the new name. You git add something and amend the merge. git show of the result will show you what happened, I think. Also, you need to use --cc option of log to see the change in history (in addition to -p): git log --cc -p -- 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
Re: [PATCH v2 7/7] unpack-trees: free cache_entry array members for merges
Felipe Contreras felipe.contre...@gmail.com writes: I don't see that, and I don't like adding a check that I don't expect to be ever needed. It's called self-documenting code; by adding a check for the NULL pointer, we are stating that ce can be NULL, if we don't do that, people reading that code would need to figure that out themselves. People following the codepath to unpack_nondirectories() already have seen enough to know what src[] means and very well know what NULL in it means. The only people possibly confused are those who do not know free(NULL) is safe, isn't it? Honestly speaking, I do not want such people to be touching this part of the system. -- 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
Re: [RFC v2] reflog: show committer date in verbose mode
Jiang Xin worldhello@gmail.com writes: 2013/6/3 Ramkumar Ramachandra artag...@gmail.com: 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 format-specifiers. Why not add to the list of pretty-format specifiers (like oneline, short, medium, full)? Also, this patch is extremely pervasive in that it teaches a poorly defined verbosity to a very low layer: revision.c/revision.h. I also feel bad when adding new flag verbose into rev_info. = =b CommitDate is more significant than AuthorDate for reflog. This is a curious statement, as I've seen it in a different context recently. Is it committer date that you really care about, or are you using it as a substitute for something else you care more about, namely, the time of the event the reflog entry was created (i.e. when you committed, when you resetted, when you branch -fed)? -- 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
Re: [PATCH 1/2] diffcore-pickaxe: make error messages more consistent
Ramkumar Ramachandra artag...@gmail.com writes:
Currently, diffcore-pickaxe reports two distinct errors for the same
user error:
$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference
$ git log -G'\1' # --pickaxe-regex is implied
fatal: invalid log-grep regex: Invalid back reference
Since the error has nothing to do with log-grep, change the -G and -S
error messages to say invalid regex.
I'll reword the above somewhat; as I repeatedly explained, -G does
*not* imply pickaxe-regex at all.
While -G was being developed, it was internally called log-grep (no
relation to git log --grep=pattern), and that seeped through to
the error message. Removing that is a good idea.
Thanks, will queue.
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..c97ac9b 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -122,7 +122,7 @@ static void diffcore_pickaxe_grep(struct diff_options *o)
char errbuf[1024];
regerror(err, regex, errbuf, 1024);
regfree(regex);
- die(invalid log-grep regex: %s, errbuf);
+ die(invalid regex: %s, errbuf);
}
pickaxe(diff_queued_diff, o, regex, NULL, diff_grep);
@@ -246,7 +246,7 @@ static void diffcore_pickaxe_count(struct diff_options *o)
char errbuf[1024];
regerror(err, regex, errbuf, 1024);
regfree(regex);
- die(invalid pickaxe regex: %s, errbuf);
+ die(invalid regex: %s, errbuf);
}
regexp = regex;
} else {
--
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
Re: [PATCH 2/2] diffcore-pickaxe doc: document -S and -G properly
Ramkumar Ramachandra artag...@gmail.com writes: The documentation of -S and -G is very sketchy. Completely rewrite the sections in Documentation/diff-options.txt and Documentation/gitdiffcore.txt. Will queue; 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
Re: [PATCH 6/6] completion: clarify ls-tree, archive, show completion
Ramkumar Ramachandra artag...@gmail.com writes: Currently, the 'git ls-tree', 'git archive', and 'git show' completions use __git_complete_file (aliased to __git_complete_revlist_file). In the case of 'git ls-tree' and 'git archive', they necessarily require a tree-ish argument (and optionally a pathspec filter, or file argument): $ git ls-tree hot-branch git.c $ git archive HEAD~4 git.c So, __git_complete_file is a misleading name. In the case of 'git show', it can take a pathspec and default the revision to HEAD like: $ git show git.c (which is useful if git.c was modified in HEAD) However, this usage is not idiomatic at all. More idiomatic is after seeing git show --stat doing git show dir/. But I do not think it really matters. Just like diff and difftool, show optionally takes revs and paths, and because the current completion code does not do anything fancy like we have seen enough revs and there will appear no revs hence we only complete paths from here on, complete_revlist_file is the right helper to use for all of them. -- 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
Re: git daemon --access-hook problem
- Your log file might not be located where you expect, you should use absolute path to dump text You were right! The problem was with the script itself - the log file not being specified with absolute path! Stupid me! ... - The documentation says you can print one line before a failure, also try this to show the cwd Would you be able to advise how this should be done? I don't get the error message (i mean the output of pwd) if i do this: echo `pwd` exit 1 What should it be? Thanks! Eugene Hope that helps, Antoine, -- 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
Re: [PATCH v2 4/6] send-email: make --suppress-cc=self sanitize input
Michael S. Tsirkin m...@redhat.com writes:
Yes, I think so too. So - what do you suggest?
Add a test?
Add a comment?
more?
Nothing major comes to my mind at this moment.
I guess it would be good to add a test or two to use A U. Thor
example with and without end-user added quotes, but that can be done
as a follow-up patch on top of this series (i.e. [PATCH 7/6]).
Thanks.
git-send-email.perl | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index a138615..92df393 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -760,6 +760,8 @@ if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
}
+$sender = sanitize_address($sender);
+
my $prompting = 0;
if (!@initial_to !defined $to_cmd) {
my $to = ask(Who should the emails be sent to (if any)? ,
@@ -1113,10 +1115,9 @@ sub send_message {
if ($cc ne '') {
$ccline = \nCc: $cc;
}
- my $sanitized_sender = sanitize_address($sender);
make_message_id() unless defined($message_id);
- my $header = From: $sanitized_sender
+ my $header = From: $sender
To: $to${ccline}
Subject: $subject
Date: $date
@@ -1133,7 +1134,7 @@ X-Mailer: git-send-email $gitversion
}
my @sendmail_parameters = ('-i', @recipients);
- my $raw_from = $sanitized_sender;
+ my $raw_from = $sender;
if (defined $envelope_sender $envelope_sender ne auto) {
$raw_from = $envelope_sender;
}
@@ -1308,8 +1309,9 @@ foreach my $t (@files) {
}
elsif (/^From:\s+(.*)$/i) {
($author, $author_encoding) =
unquote_rfc2047($1);
+ my $sauthor = sanitize_address($author);
next if $suppress_cc{'author'};
- next if $suppress_cc{'self'} and $author eq
$sender;
+ next if $suppress_cc{'self'} and $sauthor eq
$sender;
printf((mbox) Adding cc: %s from line '%s'\n,
$1, $_) unless $quiet;
push @cc, $1;
@@ -1323,7 +1325,9 @@ foreach my $t (@files) {
}
elsif (/^Cc:\s+(.*)$/i) {
foreach my $addr (parse_address_line($1)) {
- if (unquote_rfc2047($addr) eq $sender) {
+ my $qaddr = unquote_rfc2047($addr);
+ my $saddr = sanitize_address($qaddr);
+ if ($saddr eq $sender) {
next if ($suppress_cc{'self'});
} else {
next if ($suppress_cc{'cc'});
@@ -1370,7 +1374,8 @@ foreach my $t (@files) {
chomp;
my ($what, $c) = ($1, $2);
chomp $c;
- if ($c eq $sender) {
+ my $sc = sanitize_address($c);
+ if ($sc eq $sender) {
next if ($suppress_cc{'self'});
} else {
next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
@@ -1454,7 +1459,6 @@ foreach my $t (@files) {
sub recipients_cmd {
my ($prefix, $what, $cmd, $file) = @_;
- my $sanitized_sender = sanitize_address($sender);
my @addresses = ();
open my $fh, -|, $cmd \Q$file\E
or die ($prefix) Could not execute '$cmd';
--
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
Re: [PATCH v2 1/7] add simple tests of consistency across rebase types
Martin von Zweigbergk martinv...@gmail.com writes: On Tue, May 28, 2013 at 11:39 PM, Martin von Zweigbergk martinv...@gmail.com wrote: create mode 100755 t/t3420-rebase-topology-linear.sh Just FYI, there's another test case with the same number (t3420-rebase-autostash) in pu. I don't know how you normally handle such cases. Thanks for a heads-up. Usually, the series that appears later on the list yields and finds a unique number. -- 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
Re: [PATCH 3/6] completion: add common options for blame
On Mon, Jun 03, 2013 at 03:02:00PM +0530, Ramkumar Ramachandra wrote: 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 not have equivalent long-forms. But providing short options for completion is pointless. Those who know git blame's short options will just type them right away, because it requires less key presses than using completion, and those who don't know these options will only see -C, -M, etc. and won't have any clues what it stands for. Best, Gábor -- 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
Re: [PATCH v2 1/7] add simple tests of consistency across rebase types
On Mon, Jun 3, 2013 at 11:05 AM, Junio C Hamano gits...@pobox.com wrote: Martin von Zweigbergk martinv...@gmail.com writes: On Tue, May 28, 2013 at 11:39 PM, Martin von Zweigbergk martinv...@gmail.com wrote: create mode 100755 t/t3420-rebase-topology-linear.sh Just FYI, there's another test case with the same number (t3420-rebase-autostash) in pu. I don't know how you normally handle such cases. Thanks for a heads-up. Usually, the series that appears later on the list yields and finds a unique number. In this case, that's my series. Want a resend or do you want to do it yourself? I'm fine either way, whatever is easiest for you. -- 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
Re: What's cooking in git.git (Jun 2013, #01; Sun, 2)
Jiang Xin worldhello@gmail.com writes: I have updated the patch in the new reply for this thread, and it need some feedbacks: http://thread.gmane.org/gmane.comp.version-control.git/225139/focus=225934 Will re-queue and wait for some feedbacks then. 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
Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option
Felipe Contreras felipe.contre...@gmail.com writes:
Pretty much what it says on the tin.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-cherry-pick.txt | 3 +++
builtin/revert.c| 2 ++
sequencer.c | 6 ++
sequencer.h | 1 +
t/t3508-cherry-pick-many-commits.sh | 13 +
5 files changed, 25 insertions(+)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..fccd936 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -129,6 +129,9 @@ effect to your index in a row.
redundant commits are ignored. This option overrides that behavior and
creates an empty commit object. Implies `--allow-empty`.
+--skip-empty::
+ Instead of failing, skip commits that are or become empty.
Not quite sure. Is this instead of recording an empty commit,
(which may or may not fail depending on the allow-empty settings)?
If that is what this patch is meant to do, I think the change makes
sense.
--strategy=strategy::
Use the given merge strategy. Should only be used once.
See the MERGE STRATEGIES section in linkgit:git-merge[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 0401fdb..0e5ce71 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -118,6 +118,7 @@ static void parse_args(int argc, const char **argv,
struct replay_opts *opts)
OPT_END(),
OPT_END(),
OPT_END(),
+ OPT_END(),
};
if (opts-action == REPLAY_PICK) {
@@ -127,6 +128,7 @@ static void parse_args(int argc, const char **argv,
struct replay_opts *opts)
OPT_BOOLEAN(0, allow-empty, opts-allow_empty,
N_(preserve initially empty commits)),
OPT_BOOLEAN(0, allow-empty-message,
opts-allow_empty_message, N_(allow commits with empty messages)),
OPT_BOOLEAN(0, keep-redundant-commits,
opts-keep_redundant_commits, N_(keep redundant, empty commits)),
+ OPT_BOOLEAN(0, skip-empty, opts-skip_empty,
N_(skip empty commits)),
OPT_END(),
};
if (parse_options_concat(options, ARRAY_SIZE(options),
cp_extra))
diff --git a/sequencer.c b/sequencer.c
index f7be7d8..d3c7d72 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -627,6 +627,12 @@ static int do_pick_commit(struct commit *commit, struct
replay_opts *opts)
goto leave;
}
+ if (opts-skip_empty is_index_unchanged() == 1) {
+ warning(_(skipping %s... %s),
+ find_unique_abbrev(commit-object.sha1, DEFAULT_ABBREV),
+ msg.subject);
+ goto leave;
+ }
allow = allow_empty(opts, commit);
if (allow 0) {
res = allow;
diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..3b04844 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -34,6 +34,7 @@ struct replay_opts {
int allow_empty;
int allow_empty_message;
int keep_redundant_commits;
+ int skip_empty;
int mainline;
diff --git a/t/t3508-cherry-pick-many-commits.sh
b/t/t3508-cherry-pick-many-commits.sh
index 19c99d7..3dc19c6 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -187,4 +187,17 @@ test_expect_success 'cherry-pick --stdin works' '
check_head_differs_from fourth
'
+test_expect_success 'cherry-pick skip empty' '
+ git clean -fxd
+ git checkout -b empty fourth
+ git commit --allow-empty -m empty
+ test_commit ontop
+ git checkout -f master
+ git reset --hard fourth
+ git cherry-pick --skip-empty fourth..empty
+ echo ontop expected
+ git log --format=%s fourth..HEAD actual
+ test_cmp expected actual
+'
+
test_done
--
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
Re: [PATCH v2 4/8] cherry-pick: store rewritten commits
Felipe Contreras felipe.contre...@gmail.com writes:
+static void add_rewritten(unsigned char *from, unsigned char *to)
+{
+ struct rewritten_list_item *item;
+ if (rewritten.nr + 1 = rewritten.alloc) {
+ rewritten.alloc += 32;
+ rewritten.items = xrealloc(rewritten.items, rewritten.alloc *
sizeof(*rewritten.items));
+ }
Is there a compelling reason not to use ALLOC_GROW() here?
--
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
Re: [PATCH v2 5/8] sequencer: run post-rewrite hook
Felipe Contreras felipe.contre...@gmail.com writes:
As we should.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index c217716..3aa480e 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -127,6 +127,37 @@ static void add_rewritten(unsigned char *from, unsigned
char *to)
rewritten.nr++;
}
+static void run_rewrite_hook(void)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process proc;
+ const char *argv[3];
+ int code, i;
+
+ argv[0] = find_hook(post-rewrite);
+ if (!argv[0])
+ return;
+
+ argv[1] = rebase;
+ argv[2] = NULL;
When the end-user action is git cherry-pick A..B, shouldn't
the rewrite hook be called with cherry-pick not rebase as its
first argument?
More importantly, doesn't git revert A..B also trigger the
codepath for [4/8] and hence this function?
I think [3/8] --skip-empty makes sense also for revert, but I do not
think this one does as-is. As what [4/8] introduces is a record of
rewrite, the patch does not make sense either. These two steps
would want to limit themselves to cherry-pick only, no?
+ memset(proc, 0, sizeof(proc));
+ proc.argv = argv;
+ proc.in = -1;
+ proc.stdout_to_stderr = 1;
+
+ code = start_command(proc);
+ if (code)
+ return;
+ for (i = 0; i rewritten.nr; i++) {
+ struct rewritten_list_item *item = rewritten.items[i];
+ strbuf_addf(buf, %s %s\n, sha1_to_hex(item-from),
sha1_to_hex(item-to));
+ }
+ write_in_full(proc.in, buf.buf, buf.len);
+ close(proc.in);
+ finish_command(proc);
+}
+
static void remove_sequencer_state(void)
{
struct strbuf seq_dir = STRBUF_INIT;
@@ -1099,6 +1130,8 @@ static int pick_commits(struct commit_list *todo_list,
struct replay_opts *opts)
}
}
+ run_rewrite_hook();
+
/*
* Sequence of picks finished successfully; cleanup by
* removing the .git/sequencer directory
@@ -1136,14 +1169,24 @@ static int sequencer_continue(struct replay_opts
*opts)
}
if (index_differs_from(HEAD, 0))
return error_dirty_index(opts);
+ {
+ unsigned char to[20];
+ if (!read_ref(HEAD, to))
+ add_rewritten(todo_list-item-object.sha1, to);
+ }
todo_list = todo_list-next;
return pick_commits(todo_list, opts);
}
static int single_pick(struct commit *cmit, struct replay_opts *opts)
{
+ int ret;
setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
- return do_pick_commit(cmit, opts);
+ ret = do_pick_commit(cmit, opts);
+ if (ret)
+ return ret;
+ run_rewrite_hook();
+ return 0;
}
int sequencer_pick_revisions(struct replay_opts *opts)
--
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
Re: git daemon --access-hook problem
On Mon, Jun 3, 2013 at 8:02 PM, Eugene Sajine eugu...@gmail.com wrote: Would you be able to advise how this should be done? I don't get the error message (i mean the output of pwd) if i do this: echo `pwd` exit 1 What should it be? Actually, after digging into the code, it looks like you need to call git-daemon with --informative-errors if you want to allow custom errors. Maybe there is place for improvement in the documentation. Cheers, -- 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
Re: [PATCH v9 3/4] contrib: related: add option to parse from committish
Felipe Contreras felipe.contre...@gmail.com writes: For example master..feature-a. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/related/git-related | 38 -- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/contrib/related/git-related b/contrib/related/git-related index 3379982..20eb456 100755 --- a/contrib/related/git-related +++ b/contrib/related/git-related @@ -1,10 +1,12 @@ #!/usr/bin/env ruby # This script finds people that might be interested in a patch -# usage: git related files +# usage: git related files | rev-list options $since = '5-years-ago' $min_percent = 10 +$files = [] +$rev_args = [] class Commit @@ -102,10 +104,42 @@ class Commits end end + def from_rev_args(args) +source = nil +File.popen(%w[git rev-list --reverse] + args) do |p| + p.each do |e| +id = e.chomp +@main_commits[id] = true +File.popen(%w[git show -C --oneline] + [id]) do |p| Is there a solid design choice behind -C, or is it just what happens to have worked for you in practice? If the former, it may want to be explained somewhere (either in the log or in the code) so that later tweaks will not break it, especially given that the invocation of blame seems to use double-C's. + p.each do |e| +case e +when /^---\s+(\S+)/ + source = $1 != '/dev/null' ? $1[2..-1] : nil +when /^@@ -(\d+)(?:,(\d+))?/ + get_blame(source, $1, $2, id) if source +end + end +end + end +end + end + +end + +ARGV.each do |e| + if File.exists?(e) +$files e + else +$rev_args e + end end commits = Commits.new -commits.from_patches(ARGV) +if $files.empty? + commits.from_rev_args($rev_args) +else + commits.from_patches($files) +end commits.import count_per_person = Hash.new(0) -- 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
t4015 broken on pu
The new 4015 does not pass under Mac OS: a) The seq command, does not exits (we can use printf) b) One sed expression is not understood, sed exporst needed ;-) git diff diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh index b3c4fcc..f00d20b 100755 --- a/t/t4015-diff-whitespace.sh +++ b/t/t4015-diff-whitespace.sh @@ -143,18 +143,18 @@ git diff --ignore-space-at-eol out test_expect_success 'another test, with --ignore-space-at-eol' 'test_cmp expect out' test_expect_success 'ignore-blank-lines: only new lines' ' - seq 5 x + printf 1\n2\n3\n4\n5\n x git update-index x - seq 5 | sed /3/i x + printf 1\n2\n3\n4\n5\n | sed /3/i x git diff --ignore-blank-lines out printf expect test_cmp out expect ' test_expect_success 'ignore-blank-lines: only new lines with space' ' - seq 5 x + printf 1\n2\n3\n4\n5\n x git update-index x - seq 5 | sed /3/i \ x + printf 1\n2\n3\n4\n5\n | sed /3/i \ x git diff -w --ignore-blank-lines out printf expect test_cmp out expect @@ -162,7 +162,7 @@ test_expect_success 'ignore-blank-lines: only new lines with space' ' test_expect_success 'ignore-blank-lines: with changes' ' - seq 11 x + printf 1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n x git update-index x cat -\EOF x After that, TC 12 fails: ok 11 - another test, with --ignore-space-at-eol expecting success: printf 1\n2\n3\n4\n5\n x git update-index x printf 1\n2\n3\n4\n5\n | sed /3/i x git diff --ignore-blank-lines out printf expect test_cmp out expect sed: 1: /3/i \\: extra characters after \ at the end of i command not ok 12 - ignore-blank-lines: only new lines -- 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
Re: t4015 broken on pu
On Mon, Jun 3, 2013 at 9:01 PM, Torsten Bögershausen tbo...@web.de wrote: The new 4015 does not pass under Mac OS: a) The seq command, does not exits (we can use printf) I was planning to reroll with test_seq instead of seq, as advised by Johannes Sixt. b) One sed expression is not understood, sed exporst needed ;-) Thanks, I will fix sed also in next reroll ! -- 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
Re: [PATCH v2 7/8] revert/cherry-pick: add --quiet option
Makes sense. -- 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
Re: [PATCH 3/6] completion: add common options for blame
SZEDER Gábor sze...@ira.uka.de writes: But providing short options for completion is pointless. Those who know git blame's short options will just type them right away, because it requires less key presses than using completion, and those who don't know these options will only see -C, -M, etc. and won't have any clues what it stands for. It is not necessarily true that they won't have any clue; one could argue that -C -M etc can serve as reminder to people who once learned but forgot momentarily. My conclusion is the same, though; git blame -h is for those people. -- 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
Re: [PATCH v9 0/4] New git-related helper
Felipe Contreras felipe.contre...@gmail.com writes: I changed my mind, this is the same as v9 but minus some potentially controversial changes. Felipe Contreras (4): Add new git-related helper to contrib contrib: related: add support for multiple patches contrib: related: add option to parse from committish contrib: related: parse committish like format-patch contrib/related/git-related | 172 1 file changed, 172 insertions(+) create mode 100755 contrib/related/git-related Replaced what was parked on 'pu' with this. -- 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
Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option
Junio C Hamano gits...@pobox.com writes: Felipe Contreras felipe.contre...@gmail.com writes: Pretty much what it says on the tin. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-cherry-pick.txt | 3 +++ builtin/revert.c| 2 ++ sequencer.c | 6 ++ sequencer.h | 1 + t/t3508-cherry-pick-many-commits.sh | 13 + 5 files changed, 25 insertions(+) diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index c205d23..fccd936 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -129,6 +129,9 @@ effect to your index in a row. redundant commits are ignored. This option overrides that behavior and creates an empty commit object. Implies `--allow-empty`. +--skip-empty:: +Instead of failing, skip commits that are or become empty. Not quite sure. Is this instead of recording an empty commit, (which may or may not fail depending on the allow-empty settings)? If that is what this patch is meant to do, I think the change makes sense. Also what I noticed while looking at 4-5/8. Wouldn't revert --skip-empty A..B make sense as well? -- 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
Re: [PATCH 6/6] completion: clarify ls-tree, archive, show completion
On Sun, Jun 02, 2013 at 07:33:42PM +0530, Ramkumar Ramachandra wrote: Currently, the 'git ls-tree', 'git archive', and 'git show' completions use __git_complete_file (aliased to __git_complete_revlist_file). In the case of 'git ls-tree' and 'git archive', they necessarily require a tree-ish argument (and optionally a pathspec filter, or file argument): $ git ls-tree hot-branch git.c $ git archive HEAD~4 git.c So, __git_complete_file is a misleading name. In the case of 'git show', it can take a pathspec and default the revision to HEAD like: $ git show git.c (which is useful if git.c was modified in HEAD) However, this usage is not idiomatic at all. The more common usage is like: $ git show HEAD~1 $ git show origin/pu:git.c So, __git_complete_file is again a poor name. Replace these three instances of __git_complete_file with __git_complete_revlist_file, without making any functional changes. Remove __git_complete_file, as it has no other callers. 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. Arguably the name of __git_complete_file() could describe better what the function does, or what it did, i.e. it used to provide completion for the master:DocTAB notation. But that's only the name. Since both git ls-tree and git archive understand this notation, calling the helper for master:DocTAB in their completion functions is not misleading at all. Now, __git_complete_revlist_file() provides completion both for this master:DocTAB notation and for revision ranges, i.e. for master..nTAB and master...nTAB. However, since neither git ls-tree nor git archive accept revision ranges, calling __git_complete_revlist_file() in their completion function would be misleading. git show is special, as it understands both the master:DocTAB notation and revision ranges, and even the combination of the two, so calling __git_complete_revlist_file() there would indeed be better. Gábor -- 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
Re: [PATCH v2 2/6] send-email: fix suppress-cc=self on cccmd
On Mon, Jun 03, 2013 at 11:04:31AM -0700, Junio C Hamano wrote: Michael S. Tsirkin m...@redhat.com writes: What I tried to do here is split the changes to small chunks and I picked a chunk of a later patch in an earlier one by mistake. So this is fixed up by patch 4/6 in the series, which redefines sender to have the sanitized value, everywhere. I guess I'll have to repost moving this former chunk to patch 4. Yeah, that may be a good idea. Thanks. Or just smash 2+4 together ... Confused. You are doing this or want me ot? -- 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
Re: [PATCH 1/2] core: use env variable instead of config var to turn on logging pack access
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/sha1_file.c b/sha1_file.c
index 67e815b..7b47bdc 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -36,6 +36,8 @@ static inline uintmax_t sz_fmt(size_t s) { return s; }
const unsigned char null_sha1[20];
+static const char *log_pack_access = ;
+
/*
* This is meant to hold a *small* number of objects that you would
* want read_sha1_file() to be able to return, but yet you do not want
@@ -1956,6 +1958,14 @@ static void write_pack_access_log(struct packed_git
*p, off_t obj_offset)
{
static FILE *log_file;
+ if (!*log_pack_access) {
+ log_pack_access = getenv(GIT_TRACE_PACK_ACCESS);
+ if (!*log_pack_access)
+ log_pack_access = NULL;
+ if (!log_pack_access)
+ return;
+ }
Have you ever tested this?
Once log_pack_access goes to NULL (e.g. when it sees the empty
string it was initialized to), this new test will happily
dereference NULL.
--
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
Re: info/exclude not working
On Mon, Jun 03, 2013 at 01:04:39PM -0700, Devin Rhode wrote: MBP:dish devin$ cat ../.git/info/exclude # git ls-files --others --exclude-from=.git/info/exclude # Lines that start with '#' are comments. # For a project mostly in C, the following would be a good set of # exclude patterns (uncomment them if you want to use them): # *.[oa] # *~ models/CAFE.json dish/models/CAFE.json MBP:dish devin$ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: models/CAFE.json ***Shouldn't appear The exclude mechanism does not mean do not ever look at this file. It means when you are adding untracked files, do not include this one. Somebody has already added the file to the repository before your exclude was in place, so it is a tracked file. There is currently no official mechanism in git to do what you want (there are some hacks, but they include many pitfalls). -Peff -- 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
[PATCH v5 7/7] tests: move test for rebase messages from t3400 to t3406
t3406 is supposed to test messages from rebase operation, so let's move tests in t3400 that fit that description into 3406. Most of the functionality they tested, except for the messages, has now been subsumed by t3420. --- t/t3400-rebase.sh | 22 -- t/t3406-rebase-message.sh | 22 ++ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh index b436ef4..45a55e9 100755 --- a/t/t3400-rebase.sh +++ b/t/t3400-rebase.sh @@ -59,28 +59,6 @@ test_expect_success 'rebase against master' ' git rebase master ' -test_expect_success 'rebase against master twice' ' - git rebase master out - test_i18ngrep Current branch my-topic-branch is up to date out -' - -test_expect_success 'rebase against master twice with --force' ' - git rebase --force-rebase master out - test_i18ngrep Current branch my-topic-branch is up to date, rebase forced out -' - -test_expect_success 'rebase against master twice from another branch' ' - git checkout my-topic-branch^ - git rebase master my-topic-branch out - test_i18ngrep Current branch my-topic-branch is up to date out -' - -test_expect_success 'rebase fast-forward to master' ' - git checkout my-topic-branch^ - git rebase my-topic-branch out - test_i18ngrep Fast-forwarded HEAD to my-topic-branch out -' - test_expect_success 'the rebase operation should not have destroyed author information' ' ! (git log | grep Author: | grep ) ' diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh index fe8c27f..0392e36 100755 --- a/t/t3406-rebase-message.sh +++ b/t/t3406-rebase-message.sh @@ -30,6 +30,28 @@ test_expect_success 'rebase -m' ' test_cmp expect actual ' +test_expect_success 'rebase against master twice' ' + git rebase master out + test_i18ngrep Current branch topic is up to date out +' + +test_expect_success 'rebase against master twice with --force' ' + git rebase --force-rebase master out + test_i18ngrep Current branch topic is up to date, rebase forced out +' + +test_expect_success 'rebase against master twice from another branch' ' + git checkout topic^ + git rebase master topic out + test_i18ngrep Current branch topic is up to date out +' + +test_expect_success 'rebase fast-forward to master' ' + git checkout topic^ + git rebase topic out + test_i18ngrep Fast-forwarded HEAD to topic out +' + test_expect_success 'rebase --stat' ' git reset --hard start git rebase --stat master diffstat.txt -- 1.8.3.497.g83fddbe -- 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
[PATCH v5 0/7] Rebase topology test
The only change since v4 should be that t3420 was renamed t3421. Martin von Zweigbergk (7): add simple tests of consistency across rebase types add tests for rebasing with patch-equivalence present add tests for rebasing of empty commits add tests for rebasing root add tests for rebasing merged history t3406: modernize style tests: move test for rebase messages from t3400 to t3406 t/lib-rebase.sh | 32 t/t3400-rebase.sh | 53 +- t/t3401-rebase-partial.sh | 69 t/t3404-rebase-interactive.sh | 10 +- t/t3406-rebase-message.sh | 50 +++--- t/t3409-rebase-preserve-merges.sh | 53 -- t/t3421-rebase-topology-linear.sh | 350 ++ t/t3425-rebase-topology-merges.sh | 258 8 files changed, 672 insertions(+), 203 deletions(-) delete mode 100755 t/t3401-rebase-partial.sh create mode 100755 t/t3421-rebase-topology-linear.sh create mode 100755 t/t3425-rebase-topology-merges.sh -- 1.8.3.497.g83fddbe -- 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
[PATCH v5 2/7] add tests for rebasing with patch-equivalence present
---
t/lib-rebase.sh | 17
t/t3421-rebase-topology-linear.sh | 85 +++
2 files changed, 102 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 62b3887..16eeb1c 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -80,3 +80,20 @@ reset_rebase () {
git reset --hard
git clean -f
}
+
+cherry_pick () {
+ git cherry-pick -n $2
+ git commit -m $1
+ git tag $1
+}
+
+revert () {
+ git revert -n $2
+ git commit -m $1
+ git tag $1
+}
+
+make_empty () {
+ git commit --allow-empty -m $1
+ git tag $1
+}
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index c4b32db..75cc476 100755
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -75,4 +75,89 @@ test_run_rebase success -m
test_run_rebase success -i
test_run_rebase success -p
+# f
+# /
+# a---b---c---g---h
+# \
+# d---G---i
+#
+# uppercase = cherry-picked
+# h = reverted g
+#
+# Reverted patches are there for tests to be able to check if a commit
+# that introduced the same change as another commit is
+# dropped. Without reverted commits, we could get false positives
+# because applying the patch succeeds, but simply results in no
+# changes.
+test_expect_success 'setup of linear history for range selection tests' '
+ git checkout c
+ test_commit g
+ revert h g
+ git checkout d
+ cherry_pick G g
+ test_commit i
+ git checkout b
+ test_commit f
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* drops patches in upstream
+ reset_rebase
+ git rebase $* h i
+ test_cmp_rev h HEAD~2
+ test_linear_range 'd i' h..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* can drop last patch if in upstream
+ reset_rebase
+ git rebase $* h G
+ test_cmp_rev h HEAD^
+ test_linear_range 'd' h..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto drops patches in upstream
+ reset_rebase
+ git rebase $* --onto f h i
+ test_cmp_rev f HEAD~2
+ test_linear_range 'd i' f..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto does not drop patches in onto
+ reset_rebase
+ git rebase $* --onto h f i
+ test_cmp_rev h HEAD~3
+ test_linear_range 'd G i' h..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
test_done
--
1.8.3.497.g83fddbe
--
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
[PATCH v5 3/7] add tests for rebasing of empty commits
---
t/t3401-rebase-partial.sh | 24
t/t3421-rebase-topology-linear.sh | 58 +++
2 files changed, 58 insertions(+), 24 deletions(-)
diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh
index 58f4823..7ba1797 100755
--- a/t/t3401-rebase-partial.sh
+++ b/t/t3401-rebase-partial.sh
@@ -42,28 +42,4 @@ test_expect_success 'rebase --merge topic branch that was
partially merged upstr
test_path_is_missing .git/rebase-merge
'
-test_expect_success 'rebase ignores empty commit' '
- git reset --hard A
- git commit --allow-empty -m empty
- test_commit D
- git rebase C
- test $(git log --format=%s C..) = D
-'
-
-test_expect_success 'rebase --keep-empty' '
- git reset --hard D
- git rebase --keep-empty C
- test $(git log --format=%s C..) = D
-empty
-'
-
-test_expect_success 'rebase --keep-empty keeps empty even if already in
upstream' '
- git reset --hard A
- git commit --allow-empty -m also-empty
- git rebase --keep-empty D
- test $(git log --format=%s A..) = also-empty
-D
-empty
-'
-
test_done
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index 75cc476..81e3d59 100755
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -160,4 +160,62 @@ test_run_rebase success -m
test_run_rebase success -i
test_run_rebase success -p
+# a---b---c---j!
+# \
+# d---k!--l
+#
+# ! = empty
+test_expect_success 'setup of linear history for empty commit tests' '
+ git checkout c
+ make_empty j
+ git checkout d
+ make_empty k
+ test_commit l
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* drops empty commit
+ reset_rebase
+ git rebase $* c l
+ test_cmp_rev c HEAD~2
+ test_linear_range 'd l' c..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --keep-empty
+ reset_rebase
+ git rebase $* --keep-empty c l
+ test_cmp_rev c HEAD~3
+ test_linear_range 'd k l' c..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --keep-empty keeps empty even if already
in upstream
+ reset_rebase
+ git rebase $* --keep-empty j l
+ test_cmp_rev j HEAD~3
+ test_linear_range 'd k l' j..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase failure -i
+test_run_rebase failure -p
+
test_done
--
1.8.3.497.g83fddbe
--
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
[PATCH v5 6/7] t3406: modernize style
Update the following:
- Quote 'setup'
- Remove blank lines within test case body
- Use test_commit instead of custom quick_one
- Create branch topic from tag created by test_commit
---
t/t3406-rebase-message.sh | 30 +-
1 file changed, 9 insertions(+), 21 deletions(-)
diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh
index e6a9a0d..fe8c27f 100755
--- a/t/t3406-rebase-message.sh
+++ b/t/t3406-rebase-message.sh
@@ -4,27 +4,17 @@ test_description='messages from rebase operation'
. ./test-lib.sh
-quick_one () {
- echo $1 file$1
- git add file$1
- test_tick
- git commit -m $1
-}
+test_expect_success 'setup' '
+ test_commit O fileO
+ test_commit X fileX
+ test_commit A fileA
+ test_commit B fileB
+ test_commit Y fileY
-test_expect_success setup '
- quick_one O
- git branch topic
- quick_one X
- quick_one A
- quick_one B
- quick_one Y
-
- git checkout topic
- quick_one A
- quick_one B
- quick_one Z
+ git checkout -b topic O
+ git cherry-pick A B
+ test_commit Z fileZ
git tag start
-
'
cat expect \EOF
@@ -34,12 +24,10 @@ Committed: 0003 Z
EOF
test_expect_success 'rebase -m' '
-
git rebase -m master report
sed -n -e /^Already applied: /p \
-e /^Committed: /p report actual
test_cmp expect actual
-
'
test_expect_success 'rebase --stat' '
--
1.8.3.497.g83fddbe
--
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
[PATCH v5 4/7] add tests for rebasing root
---
t/t3421-rebase-topology-linear.sh | 129 ++
1 file changed, 129 insertions(+)
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
index 81e3d59..659a7b3 100755
--- a/t/t3421-rebase-topology-linear.sh
+++ b/t/t3421-rebase-topology-linear.sh
@@ -218,4 +218,133 @@ test_run_rebase failure -m
test_run_rebase failure -i
test_run_rebase failure -p
+# m
+# /
+# a---b---c---g
+#
+# x---y---B
+#
+# uppercase = cherry-picked
+# m = reverted b
+#
+# Reverted patches are there for tests to be able to check if a commit
+# that introduced the same change as another commit is
+# dropped. Without reverted commits, we could get false positives
+# because applying the patch succeeds, but simply results in no
+# changes.
+test_expect_success 'setup of linear history for test involving root' '
+ git checkout b
+ revert m b
+ git checkout --orphan disjoint
+ git rm -rf .
+ test_commit x
+ test_commit y
+ cherry_pick B b
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto --root
+ reset_rebase
+ git rebase $* --onto c --root y
+ test_cmp_rev c HEAD~2
+ test_linear_range 'x y' c..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* without --onto --root with disjoint
history
+ reset_rebase
+ git rebase $* c y
+ test_cmp_rev c HEAD~2
+ test_linear_range 'x y' c..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto --root drops patch in onto
+ reset_rebase
+ git rebase $* --onto m --root B
+ test_cmp_rev m HEAD~2
+ test_linear_range 'x y' m..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --onto --root with merge-base does not
go to root
+ reset_rebase
+ git rebase $* --onto m --root g
+ test_cmp_rev m HEAD~2
+ test_linear_range 'c g' m..
+
+}
+
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* without --onto --root with disjoint
history drops patch in onto
+ reset_rebase
+ git rebase $* m B
+ test_cmp_rev m HEAD~2
+ test_linear_range 'x y' m..
+
+}
+test_run_rebase success ''
+test_run_rebase failure -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* --root on linear history is a no-op
+ reset_rebase
+ git rebase $* --root c
+ test_cmp_rev c HEAD
+
+}
+test_run_rebase failure ''
+test_run_rebase failure -m
+test_run_rebase failure -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* -f --root on linear history causes
re-write
+ reset_rebase
+ git rebase $* -f --root c
+ ! test_cmp_rev a HEAD~2
+ test_linear_range 'a b c' HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
test_done
--
1.8.3.497.g83fddbe
--
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
Re: info/exclude not working
I wouldn't worry too much about this use case, we have a pretty lame workflow On Mon, Jun 3, 2013 at 1:32 PM, Jeff King p...@peff.net wrote: On Mon, Jun 03, 2013 at 01:04:39PM -0700, Devin Rhode wrote: MBP:dish devin$ cat ../.git/info/exclude # git ls-files --others --exclude-from=.git/info/exclude # Lines that start with '#' are comments. # For a project mostly in C, the following would be a good set of # exclude patterns (uncomment them if you want to use them): # *.[oa] # *~ models/CAFE.json dish/models/CAFE.json MBP:dish devin$ git status # On branch master # Changes not staged for commit: # (use git add file... to update what will be committed) # (use git checkout -- file... to discard changes in working directory) # # modified: models/CAFE.json ***Shouldn't appear The exclude mechanism does not mean do not ever look at this file. It means when you are adding untracked files, do not include this one. Somebody has already added the file to the repository before your exclude was in place, so it is a tracked file. There is currently no official mechanism in git to do what you want (there are some hacks, but they include many pitfalls). -Peff -- 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
Re: [PATCH 3/4] unpack-trees: trivial cleanup
On Mon, Jun 3, 2013 at 12:13 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: dfc has not been initialized at this point. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Upon the first entry to this function, because dfc is static struct cache_entry *dfc; Ah, I didn't notice it's static. Smells error-prone, but I guess it's OK for now. -- Felipe Contreras -- 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
[PATCH v5 1/7] add simple tests of consistency across rebase types
Helped-by: Johannes Sixt j...@kdbg.org
---
t/lib-rebase.sh | 15
t/t3421-rebase-topology-linear.sh | 78 +++
2 files changed, 93 insertions(+)
create mode 100755 t/t3421-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 6ccf797..62b3887 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -65,3 +65,18 @@ EOF
test_set_editor $(pwd)/fake-editor.sh
chmod a+x fake-editor.sh
}
+
+# checks that the revisions in $2 represent a linear range with the
+# subjects in $1
+test_linear_range () {
+ ! { git log --format=%p $2 | sane_grep ;}
+ expected=$1
+ set -- $(git log --reverse --format=%s $2)
+ test $expected = $*
+}
+
+reset_rebase () {
+ git rebase --abort # may fail; ignore exit code
+ git reset --hard
+ git clean -f
+}
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
new file mode 100755
index 000..c4b32db
--- /dev/null
+++ b/t/t3421-rebase-topology-linear.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+
+test_description='basic rebase topology tests'
+. ./test-lib.sh
+. $TEST_DIRECTORY/lib-rebase.sh
+
+# a---b---c
+# \
+# d---e
+test_expect_success 'setup' '
+ test_commit a
+ test_commit b
+ test_commit c
+ git checkout b
+ test_commit d
+ test_commit e
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result simple rebase $*
+ reset_rebase
+ git rebase $* c e
+ test_cmp_rev c HEAD~2
+ test_linear_range 'd e' c..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* is no-op if upstream is an ancestor
+ reset_rebase
+ git rebase $* b e
+ test_cmp_rev e HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* -f rewrites even if upstream is an
ancestor
+ reset_rebase
+ git rebase $* -f b e
+ ! test_cmp_rev e HEAD
+ test_cmp_rev b HEAD~2
+ test_linear_range 'd e' b..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* fast-forwards if an ancestor of
upstream
+ reset_rebase
+ git rebase $* e b
+ test_cmp_rev e HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_done
--
1.8.3.497.g83fddbe
--
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
[PATCH v5 5/7] add tests for rebasing merged history
--- t/t3400-rebase.sh | 31 + t/t3401-rebase-partial.sh | 45 --- t/t3404-rebase-interactive.sh | 10 +- t/t3409-rebase-preserve-merges.sh | 53 t/t3425-rebase-topology-merges.sh | 258 ++ 5 files changed, 260 insertions(+), 137 deletions(-) delete mode 100755 t/t3401-rebase-partial.sh create mode 100755 t/t3425-rebase-topology-merges.sh diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh index b58fa1a..b436ef4 100755 --- a/t/t3400-rebase.sh +++ b/t/t3400-rebase.sh @@ -40,13 +40,6 @@ test_expect_success 'prepare repository with topic branches' ' echo Side C git add C git commit -m Add C - git checkout -b nonlinear my-topic-branch - echo Edit B - git add B - git commit -m Modify B - git merge side - git checkout -b upstream-merged-nonlinear - git merge master git checkout -f my-topic-branch git tag topic ' @@ -106,31 +99,9 @@ test_expect_success 'rebase from ambiguous branch name' ' git rebase master ' -test_expect_success 'rebase after merge master' ' - git checkout --detach refs/tags/topic - git branch -D topic - git reset --hard topic - git merge master - git rebase master - ! (git show | grep ^Merge:) -' - -test_expect_success 'rebase of history with merges is linearized' ' - git checkout nonlinear - test 4 = $(git rev-list master.. | wc -l) - git rebase master - test 3 = $(git rev-list master.. | wc -l) -' - -test_expect_success 'rebase of history with merges after upstream merge is linearized' ' - git checkout upstream-merged-nonlinear - test 5 = $(git rev-list master.. | wc -l) - git rebase master - test 3 = $(git rev-list master.. | wc -l) -' - test_expect_success 'rebase a single mode change' ' git checkout master + git branch -D topic echo 1 X git add X test_tick diff --git a/t/t3401-rebase-partial.sh b/t/t3401-rebase-partial.sh deleted file mode 100755 index 7ba1797..000 --- a/t/t3401-rebase-partial.sh +++ /dev/null @@ -1,45 +0,0 @@ -#!/bin/sh -# -# Copyright (c) 2006 Yann Dirson, based on t3400 by Amos Waterland -# - -test_description='git rebase should detect patches integrated upstream - -This test cherry-picks one local change of two into master branch, and -checks that git rebase succeeds with only the second patch in the -local branch. -' -. ./test-lib.sh - -test_expect_success 'prepare repository with topic branch' ' - test_commit A - git checkout -b my-topic-branch - test_commit B - test_commit C - git checkout -f master - test_commit A2 A.t -' - -test_expect_success 'pick top patch from topic branch into master' ' - git cherry-pick C - git checkout -f my-topic-branch -' - -test_debug ' - git cherry master - git format-patch -k --stdout --full-index master /dev/null - gitk --all sleep 1 -' - -test_expect_success 'rebase topic branch against new master and check git am did not get halted' ' - git rebase master - test_path_is_missing .git/rebase-apply -' - -test_expect_success 'rebase --merge topic branch that was partially merged upstream' ' - git reset --hard C - git rebase --merge master - test_path_is_missing .git/rebase-merge -' - -test_done diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index a58406d..ffcaf02 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -477,19 +477,11 @@ test_expect_success 'interrupted squash works as expected (case 2)' ' test $one = $(git rev-parse HEAD~2) ' -test_expect_success 'ignore patch if in upstream' ' - HEAD=$(git rev-parse HEAD) - git checkout -b has-cherry-picked HEAD^ +test_expect_success '--continue tries to commit, even for edit' ' echo unrelated file7 git add file7 test_tick git commit -m unrelated change - git cherry-pick $HEAD - EXPECT_COUNT=1 git rebase -i $HEAD - test $HEAD = $(git rev-parse HEAD^) -' - -test_expect_success '--continue tries to commit, even for edit' ' parent=$(git rev-parse HEAD^) test_tick FAKE_LINES=edit 1 git rebase -i HEAD^ diff --git a/t/t3409-rebase-preserve-merges.sh b/t/t3409-rebase-preserve-merges.sh index 6de4e22..2e0c364 100755 --- a/t/t3409-rebase-preserve-merges.sh +++ b/t/t3409-rebase-preserve-merges.sh @@ -11,14 +11,6 @@ Run git rebase -p and check that merges are properly carried along GIT_AUTHOR_EMAIL=bogus_email_address export GIT_AUTHOR_EMAIL -# Clone 1 (trivial merge): -# -# A1--A2 -- origin/master -# \ \ -# B1--M -- topic -#\ -# B2 -- origin/topic -# # Clone 2 (conflicting merge): # # A1--A2--B3 -- origin/master @@ -36,16 +28,6 @@ export GIT_AUTHOR_EMAIL # \--A3
Re: [PATCH v2 7/7] unpack-trees: free cache_entry array members for merges
On Mon, Jun 3, 2013 at 12:40 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: I don't see that, and I don't like adding a check that I don't expect to be ever needed. It's called self-documenting code; by adding a check for the NULL pointer, we are stating that ce can be NULL, if we don't do that, people reading that code would need to figure that out themselves. People following the codepath to unpack_nondirectories() already have seen enough to know what src[] means and very well know what NULL in it means. The only people possibly confused are those who do not know free(NULL) is safe, isn't it? Wrong. I still do not know what src[] means, and I don't need to know, I can see from the code that the cached entries there leak. Honestly speaking, I do not want such people to be touching this part of the system. So we should make it more obfuscated? -- Felipe Contreras -- 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
Re: [PATCH v2 4/8] cherry-pick: store rewritten commits
On Mon, Jun 3, 2013 at 1:49 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
+static void add_rewritten(unsigned char *from, unsigned char *to)
+{
+ struct rewritten_list_item *item;
+ if (rewritten.nr + 1 = rewritten.alloc) {
+ rewritten.alloc += 32;
+ rewritten.items = xrealloc(rewritten.items, rewritten.alloc *
sizeof(*rewritten.items));
+ }
Is there a compelling reason not to use ALLOC_GROW() here?
Nope, I just copied the logic from another part of Git.
--
Felipe Contreras
--
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
Re: [PATCH v2 5/8] sequencer: run post-rewrite hook
On Mon, Jun 3, 2013 at 1:57 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
As we should.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
sequencer.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index c217716..3aa480e 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -127,6 +127,37 @@ static void add_rewritten(unsigned char *from, unsigned
char *to)
rewritten.nr++;
}
+static void run_rewrite_hook(void)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct child_process proc;
+ const char *argv[3];
+ int code, i;
+
+ argv[0] = find_hook(post-rewrite);
+ if (!argv[0])
+ return;
+
+ argv[1] = rebase;
+ argv[2] = NULL;
When the end-user action is git cherry-pick A..B, shouldn't
the rewrite hook be called with cherry-pick not rebase as its
first argument?
Indeed.
More importantly, doesn't git revert A..B also trigger the
codepath for [4/8] and hence this function?
True.
I think [3/8] --skip-empty makes sense also for revert, but I do not
think this one does as-is. As what [4/8] introduces is a record of
rewrite, the patch does not make sense either. These two steps
would want to limit themselves to cherry-pick only, no?
Probably.
--
Felipe Contreras
--
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
Re: [PATCH v9 3/4] contrib: related: add option to parse from committish
On Mon, Jun 3, 2013 at 2:05 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: For example master..feature-a. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- contrib/related/git-related | 38 -- 1 file changed, 36 insertions(+), 2 deletions(-) diff --git a/contrib/related/git-related b/contrib/related/git-related index 3379982..20eb456 100755 --- a/contrib/related/git-related +++ b/contrib/related/git-related @@ -1,10 +1,12 @@ #!/usr/bin/env ruby # This script finds people that might be interested in a patch -# usage: git related files +# usage: git related files | rev-list options $since = '5-years-ago' $min_percent = 10 +$files = [] +$rev_args = [] class Commit @@ -102,10 +104,42 @@ class Commits end end + def from_rev_args(args) +source = nil +File.popen(%w[git rev-list --reverse] + args) do |p| + p.each do |e| +id = e.chomp +@main_commits[id] = true +File.popen(%w[git show -C --oneline] + [id]) do |p| Is there a solid design choice behind -C, or is it just what happens to have worked for you in practice? If the former, it may want to be explained somewhere (either in the log or in the code) so that later tweaks will not break it, especially given that the invocation of blame seems to use double-C's. No reason in particular. -- Felipe Contreras -- 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
Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option
On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Pretty much what it says on the tin. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-cherry-pick.txt | 3 +++ builtin/revert.c| 2 ++ sequencer.c | 6 ++ sequencer.h | 1 + t/t3508-cherry-pick-many-commits.sh | 13 + 5 files changed, 25 insertions(+) diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index c205d23..fccd936 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -129,6 +129,9 @@ effect to your index in a row. redundant commits are ignored. This option overrides that behavior and creates an empty commit object. Implies `--allow-empty`. +--skip-empty:: + Instead of failing, skip commits that are or become empty. Not quite sure. Is this instead of recording an empty commit, (which may or may not fail depending on the allow-empty settings)? We are explaining --skip-empty, not --allow-empty. -- Felipe Contreras -- 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
Re: [PATCH 1/6] prompt: don't scream continuation state
On Mon, Jun 03, 2013 at 03:17:27PM +0530, Ramkumar Ramachandra wrote:
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 introduce a color in this series
because it would conflict with rr/zsh-color-prompt which is in pu: we
can introduce it after that graduates. I was thinking yellow, since
that's not taken?
You really should use colors. I don't think it's worth the extra
ugliness to scream in the no-color case.
As such, the prompt is a fine bikeshedding target. I even introduced
GIT_PS1_SEPARATOR, because some people were unhappy with me stripping
one whitespace (yes, one). If we go down the configurability road,
we'll either end up with a ton of environment variables, or be made to
write a generalized custom formatter which splices together tons of
arguments using color (super painful). While I do agree that it is a
matter of taste, we have to make a few compromises for the sake of
sanity.
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:
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index eaf5c36..1da3833 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -404,6 +404,8 @@ __git_ps1 ()
fi
gitstring=$(printf -- $printf_format $gitstring)
PS1=$ps1pc_start$gitstring$ps1pc_end
+ elif test $(type -t __git_ps1_printer) = function; then
+ __git_ps1_printer
else
# NO color option unless in PROMPT_COMMAND mode
printf -- $printf_format $c${b##refs/heads/}${f:+
$f}$r$p
and then you can define your own custom function if you like, which will
inherit all of the variables from __git_ps1. E.g.:
__git_ps1_printer() {
echo ${r,,}
}
yields a lower-case rebase-i. Of course there are many other variables
you want to put in your prompt, too. The only problem I see is that the
current set of variables is not suitable as a user-visible interface.
The names are not good (the branch should be $branch rather than $b,
the operation-in-progress should be $operation or similar rather than
$r, etc), and the formats are not as convenient ($r contains the
full |REBASE-i 6/10, whereas it should be broken down so the printing
function can easily use a case statement).
And of course the variables would need documentation.
-Peff
--
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
Re: What's cooking in git.git (May 2013, #09; Wed, 29)
Am 02.06.2013 20:50, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Am 30.05.2013 01:58, schrieb Junio C Hamano: * jl/submodule-mv (2013-04-23) 5 commits (merged to 'next' on 2013-04-23 at c04f574) + submodule.c: duplicate real_path's return value (merged to 'next' on 2013-04-19 at 45ae3c9) + rm: delete .gitmodules entry of submodules removed from the work tree + Teach mv to update the path entry in .gitmodules for moved submodules + Teach mv to move submodules using a gitfile + Teach mv to move submodules together with their work trees git mv A B when moving a submodule A does the right thing, inclusing relocating its working tree and adjusting the paths in the .gitmodules file. detailed discussion snipped So my gut feeling of the fix at this point in the evolution of the program may be to error out with a message like You have local changes to .gitmodules; please stash it before moving or removing. Yeah, me too thinks that this is a sane short term solution (even though a git submodule add currently happily stages any unstaged modifications to the .gitmodules file too, that should not stop us from doing better for rm and mv ;-). And I also agree that in the long run the the git-config aware merge driver together with the 3-way merge of a modified .gitmodules file you described is the best solution. But I'd really like to complete the recursive update before tackling that, so for now I just added these two to the to-do list on my GitHub wiki page. I'll resubmit this series with the strlen() fix and the erroring out in case of unstaged modifications of the .gitmodules file as soon as I find some time. -- 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
Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option
Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Jun 3, 2013 at 1:40 PM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: Pretty much what it says on the tin. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Documentation/git-cherry-pick.txt | 3 +++ builtin/revert.c| 2 ++ sequencer.c | 6 ++ sequencer.h | 1 + t/t3508-cherry-pick-many-commits.sh | 13 + 5 files changed, 25 insertions(+) diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt index c205d23..fccd936 100644 --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -129,6 +129,9 @@ effect to your index in a row. redundant commits are ignored. This option overrides that behavior and creates an empty commit object. Implies `--allow-empty`. +--skip-empty:: + Instead of failing, skip commits that are or become empty. Not quite sure. Is this instead of recording an empty commit, (which may or may not fail depending on the allow-empty settings)? We are explaining --skip-empty, not --allow-empty. Exactly. That is why I found the Instead of failing questionable. It is very easy to read the above as commits that are or become empty usually causes the command to fail, and this is a way to cause it not to fail.. It is true that cherry-pick A when A becomes empty, dies. But cherry-pick --allow-empty A when A becomes empty, does not fail, but still does create an empty commit. A large difference with --skip-empty, which applies to use scenario different from --allow-empty was meant to address, is that cherry-pick --skip-empty A when A becomes empty, does not fail and does not create an empty commit, either. I think just Skip commits that are or become empty without saying Instead of failing, is fine, too. -- 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
Re: What's cooking in git.git (May 2013, #09; Wed, 29)
Am 31.05.2013 21:40, schrieb John Keeping: On Thu, May 30, 2013 at 09:23:40PM +0200, Jens Lehmann wrote: Am 30.05.2013 01:58, schrieb Junio C Hamano: * jk/submodule-subdirectory-ok (2013-04-24) 3 commits (merged to 'next' on 2013-04-24 at 6306b29) + submodule: fix quoting in relative_path() (merged to 'next' on 2013-04-22 at f211e25) + submodule: drop the top-level requirement + rev-parse: add --prefix option Allow various subcommands of git submodule to be run not from the top of the working tree of the superproject. The summary and status commands are looking good in this version (they are now showing the submodule directory paths relative to the current directory). Apart from that my other remarks from gmane $221575 still seem to apply. And this series has only tests for status, summary and add (and that just with an absolute URL), I'd rather like to see a test for each submodule command (and a relative add to) to document the desired behavior. To summarize what I think are the outstanding issues from your email: * Should '$sm_path' be relative in submodule foreach? * submodule add with a relative path * submodule init initializes all submodules * Tests The current version does make '$sm_path' relative in submodule foreach, although it's hard to spot because we have to leave doing so until right before the eval. Yes. If I read the code correctly the submodule is cd'ed in before the foreach command is executed, so $sm_path should only be used for displaying info about where the command is executed anyway. Looks like your code is doing the right thing adjusting $sm_path to be relative to the directory the user is in. But a test showing that would really be nice ;-) I'm not sure what you mean about submodule add - the new version treats the path argument as relative (providing it is not an absolute path). The repository argument is not changed by running from a subdirectory but I think that's correct since it is documented as being relative to the superproject's origin repository. Sorry, I should have been more specific here. I saw that you did some changes to make submodule add do the right thing with relative paths, but the following change to t7406 does not work like I believe it should but instead makes the test fail: ---8- diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index a4ffea0..9766b9e 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa test_expect_success 'submodule add places git-dir in superprojects git-dir' ' (cd super mkdir deeper -git submodule add ../submodule deeper/submodule +(cd deeper + git submodule add ../../submodule submodule +) (cd deeper/submodule git log ../../expected ) ---8- submodule init is behaving in the same way as deinit - if you say submodule init . then it will only initialize submodules below the current directory. The difference is that deinit dies if it is not given any arguments whereas init will initialize everything from the top level down. I'm not sure whether to change this; given the direction git add -u is heading in for 2.0 I think the current behaviour is the most consistent with the rest of Git. I meant that both commands still print the submodule names from the top-level directory, not the one the user is in. -- 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
Setting of push.default or confusion about refspecs
I am setting up a git repository which I cloned using git svn. git ls-remote shows something like: ... refs/remotes/trunk refs/remotes/2.0.2a ... To get the subversion branch names to appear as a local branch, I: git remote add blah http://example.com/blah git fetch blah +refs/remotes/*:refs/heads/* I have made changes now that are okay to be in master in my local repository and I want to push them to the remote repository. The current branch is master. git push complains that push.default is not set. Now, I am confused by the documentation. push.default settings refer to either the upstream branch or a branch with the same name. What is the same name? Are these the same name: master refs/remotes/origin/master also, after the fetch above, are these the same name: refs/heads/something refs/remotes/something Regarding the upstream branch, I have in .git/config [remote origin] url = http://example.com/blah fetch = +refs/heads/*:refs/remotes/origin/* [branch master] remote = origin merge = refs/heads/master git config -l shows branch.master.remote=origin branch.master.merge=refs/heads/master When in branch master, is the upstream branch refs/heads/master? Then, I think I can get push to push to refs/remotes/origin/master by setting push.default to upstream, is that right? In case master is not the same name as refs/remotes/origin/master, can you give me an example of branches with the same name that push would push to when push.default is set to simple? Kendall -- 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
Re: crash on git diff-tree -Ganything tree for new files with textconv filter
On Mon, Jun 03, 2013 at 07:25:06PM +0200, Peter Oberndorfer wrote: Thanks for the report. I'd still like to pursue using a regex library that does not require NUL-termination, but I've been distracted by other things. I'm going to hold back my copy-to-a-NUL-buffer patch for now and see if I can get to the regex thing this week. are there any news regarding this problem? The crash seems to still exist in the current version 1.8.3 and master. Sorry, no, this got dropped due to lack of time. I _think_ it is as simple as just tweaking the Makefile to unconditionally build against the compat/ regex library, and then tweaking callsites as appropriate to use the GNU-specific interface that takes buf/len instead of a NUL-terminated string. But there may be some hidden complexities to it. -Peff -- 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
Re: What's cooking in git.git (May 2013, #09; Wed, 29)
On Mon, Jun 03, 2013 at 11:47:23PM +0200, Jens Lehmann wrote: Am 31.05.2013 21:40, schrieb John Keeping: The current version does make '$sm_path' relative in submodule foreach, although it's hard to spot because we have to leave doing so until right before the eval. Yes. If I read the code correctly the submodule is cd'ed in before the foreach command is executed, so $sm_path should only be used for displaying info about where the command is executed anyway. Looks like your code is doing the right thing adjusting $sm_path to be relative to the directory the user is in. But a test showing that would really be nice ;-) Agreed. I've also noticed that the legacy path variable hasn't been adjusted and the printing of the module paths does not make them relative. I'll fix them in the next version. I'm not sure what you mean about submodule add - the new version treats the path argument as relative (providing it is not an absolute path). The repository argument is not changed by running from a subdirectory but I think that's correct since it is documented as being relative to the superproject's origin repository. Sorry, I should have been more specific here. I saw that you did some changes to make submodule add do the right thing with relative paths, but the following change to t7406 does not work like I believe it should but instead makes the test fail: ---8- diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index a4ffea0..9766b9e 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa test_expect_success 'submodule add places git-dir in superprojects git-dir' ' (cd super mkdir deeper -git submodule add ../submodule deeper/submodule +(cd deeper + git submodule add ../../submodule submodule +) (cd deeper/submodule git log ../../expected ) ---8- Ah, ok. I think this case is problematic because the repository argument is either relative to remote.origin.url or to the top of the working tree if there is no origin remote. I wonder if we should just die when a relative path is given for the repository and we're not at the top of the working tree. submodule init is behaving in the same way as deinit - if you say submodule init . then it will only initialize submodules below the current directory. The difference is that deinit dies if it is not given any arguments whereas init will initialize everything from the top level down. I'm not sure whether to change this; given the direction git add -u is heading in for 2.0 I think the current behaviour is the most consistent with the rest of Git. I meant that both commands still print the submodule names from the top-level directory, not the one the user is in. Will fix. -- 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
Re: Git status reports untracked on tracked files
On Wed, May 29, 2013 at 11:40:56AM +0300, Andrey Kiyanovsky wrote: Git version 1.8.1.2. for Windows Git config: [core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true hideDotFiles = dotGitOnly compression = 1 In the past there have been some problems with status listings of untracked files when core.ignorecase is in use. I fixed some cases with a commit that went into v1.7.8, but some problems remained. Karsten Blees (cc'd) did some work that went into git v1.8.1.6, but I do not know off-hand if it would fix your case or not. Can you try with a more recent version of git? -Peff -- 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
Re: [PATCH v5 1/7] add simple tests of consistency across rebase types
Martin von Zweigbergk martinv...@gmail.com writes:
Helped-by: Johannes Sixt j...@kdbg.org
---
t/lib-rebase.sh | 15
t/t3421-rebase-topology-linear.sh | 78
+++
2 files changed, 93 insertions(+)
create mode 100755 t/t3421-rebase-topology-linear.sh
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index 6ccf797..62b3887 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -65,3 +65,18 @@ EOF
test_set_editor $(pwd)/fake-editor.sh
chmod a+x fake-editor.sh
}
+
+# checks that the revisions in $2 represent a linear range with the
+# subjects in $1
+test_linear_range () {
+ ! { git log --format=%p $2 | sane_grep ;}
An interesting way to spell:
test $(git rev-list --merges $2 | wc -l) = 0
I think I am fine with either, though.
+ expected=$1
+ set -- $(git log --reverse --format=%s $2)
+ test $expected = $*
OK.
+}
+
+reset_rebase () {
+ git rebase --abort # may fail; ignore exit code
test_might_fail to catch unusual exit codes?
+ git reset --hard
+ git clean -f
+}
diff --git a/t/t3421-rebase-topology-linear.sh
b/t/t3421-rebase-topology-linear.sh
new file mode 100755
index 000..c4b32db
--- /dev/null
+++ b/t/t3421-rebase-topology-linear.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+
+test_description='basic rebase topology tests'
+. ./test-lib.sh
+. $TEST_DIRECTORY/lib-rebase.sh
+
+# a---b---c
+# \
+# d---e
+test_expect_success 'setup' '
+ test_commit a
+ test_commit b
+ test_commit c
+ git checkout b
+ test_commit d
+ test_commit e
+'
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result simple rebase $*
+ reset_rebase
+ git rebase $* c e
+ test_cmp_rev c HEAD~2
+ test_linear_range 'd e' c..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* is no-op if upstream is an ancestor
+ reset_rebase
+ git rebase $* b e
+ test_cmp_rev e HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* -f rewrites even if upstream is an
ancestor
+ reset_rebase
+ git rebase $* -f b e
Asking to rebase the history leading to e from b on top of the merge
base (which happens to be b) may be no-op or force-create a new
history that is parallel. OK.
+ ! test_cmp_rev e HEAD
+ test_cmp_rev b HEAD~2
+ test_linear_range 'd e' b..
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase failure -p
+
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* fast-forwards if an ancestor of
upstream
The description is a non-sentence, and while I can tell what it
wants to say, I do not have a good suggestion for rephrasing this.
This is asking to rebase the history leading to b on top of e, but e
already includes everything in b, so it just turns into a no-op of
not moving from e. So it is not even a fast-forward.
+ reset_rebase
+ git rebase $* e b
+ test_cmp_rev e HEAD
+
+}
+test_run_rebase success ''
+test_run_rebase success -m
+test_run_rebase success -i
+test_run_rebase success -p
+
+test_done
--
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
Re: Is there an API to the .gitignore capability?
On Sun, Jun 2, 2013 at 9:40 PM, Peng Yu pengyu...@gmail.com wrote: Hi, .gitignore is a flexible way to customize what dir/file to search or not to search. So it is of general use and is more flexible than what is offered by find. I'm wondering if there is an API than I can use besides using it within git. Thanks. Git provides no C API, if that's what you mean. You can link with libgit.a, but there's no guarantee it won't break someday. At a higher API level such as shell scripting, still no, but I think you could modify git ls-files to support running 'ls-files -i' without a git repository (like git-grep --no-index). I think it'll work, mostly, but not entirely sure. -- Duy -- 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
Re: [PATCH] cherry-pick: don't barf when there's nothing to do
Felipe Contreras felipe.contre...@gmail.com writes: If the user set --ff, it's expected that if theres's nothing to do we fast-forward our current HEAD, which is a no-op. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- This is about git cherry-pick topic..master which is a misspelt form of git cherry-pick master..topic, or alternatively, a script calling git cherry-pick ..$branch that turns out to be giving an empty set, isn't it? I suspect that it is perfectly fine to turn this die() into a warning or an informational feedback (or be silent when --quiet is given) and make the command exit with success. If the user asked for a no-op, the result should be a no-op, but because a no-op is a strange thing to ask for, and is deserved to be warned about. But I do not see why we should behave differently between with and without --ff option. I also notice this funkiness with --ff: git.git/master$ git checkout master^ git.git/(ed73fe5...)$ git cherry-pick master^0 [detached HEAD 32af3ed] Update draft release notes to 1.8.4 1 file changed, 53 insertions(+) git.git/(32af3ed...)$ git checkout master^ git.git/(ed73fe5...)$ git cherry-pick --ff master^0 git.git/(b2edae0...)$ The last cherry-pick shows nothing. The user can notice that something useful has happened only because git-prompt script is in use (and he is experimenting on a detached HEAD), but otherwise there is no feedback. I think it should, unless given --quiet, say something like fast-forwarded to ... to avoid user confusion. sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index d8f9d30..b9d4b48 100644 --- a/sequencer.c +++ b/sequencer.c @@ -749,7 +749,7 @@ static void prepare_revs(struct replay_opts *opts) if (prepare_revision_walk(opts-revs)) die(_(revision walk setup failed)); - if (!opts-revs-commits) + if (!opts-revs-commits !opts-allow_ff) die(_(empty commit set passed)); } -- 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
Re: Setting of push.default or confusion about refspecs
On 06/03/2013 03:01 PM, Kendall Shaw wrote: ... Regarding the upstream branch, I have in .git/config [remote origin] url = http://example.com/blah fetch = +refs/heads/*:refs/remotes/origin/* [branch master] remote = origin merge = refs/heads/master git config -l shows branch.master.remote=origin branch.master.merge=refs/heads/master When in branch master, is the upstream branch refs/heads/master? Then, I think I can get push to push to refs/remotes/origin/master by setting push.default to upstream, is that right? I bit the wax tadpole and tried it. I think setting push.default set to upstream does what I thought. Kendall -- 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
Re: [git-users] Highlevel (but simple to implement) commands provided by default for git
On Thu, May 30, 2013 at 3:07 AM, Junio C Hamano gits...@pobox.com wrote: *1* blame is an oddball (and I suspect the recent log -Ln,m:path may share the same) in that it really wants a concret path, not a pathspec, so you cannot even say cd Documentation; git blame :/Makefile I think the right fix is to teach it that the argument it has been taking as a pathname is actually a pathspec, match the pathspec with appropriate place (either in the working tree, or in the commit we start digging from), and use the path that the pathspec matches to a single one (otherwise barf). You should have CCed me when it's about pathspec :) At least we can safely turn on :/ trick for git-blame and reject other features (like globbing) that blame can't handle. I'll look into how easy/hard to make git-blame support pathspec. -- Duy -- 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
Re: [PATCH 1/6] prompt: don't scream continuation state
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 the user need to re-implement this entire function (with so many variables) in her ~/.zshrc? Isn't it horribly painful for too little gain? -- 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
Re: [PATCH 1/6] prompt: don't scream continuation state
On Tue, Jun 04, 2013 at 09:14:23AM +0530, Ramkumar Ramachandra wrote:
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 the user
need to re-implement this entire function (with so many variables) in
her ~/.zshrc? Isn't it horribly painful for too little gain?
It is a lot of ugly code, but then, complexity and flexibility are a
tradeoff. You would not _have_ to use a custom function at all. But if
we make it an option, and leave the existing code as the default
function, then only those who want it have to use it.
Even better, we can hit a middle ground by abstracting away some of the
complexity. You could probably write colorize() function to handle
colorizing a particular string (and handle bash/zsh magic), and then
pull the whole which color is the branch function into a
colorize_branch(), and so forth.
I haven't looked that closely, so there may be hidden troubles awaiting,
but I don't see why you couldn't ultimately let the user write something
like:
__git_ps1_printer() {
echo ' ('
test $bare = t echo BARE:; # or bare: :)
color_branch $(short_ref $branch) $detached
test $wt_changes = t colorize red *
...
echo ')'
}
And if that is too much, you can abstract bits of it out. The point is
that if we can expose the lowest-level details, we can compose functions
around them at whatever level is appropriate, and callers can mix and
match for the balance of complexity and flexibility they want.
Perhaps it is overkill, but I also think it may make the code itself
more readable. For example, I put a ... above because the next line
would handle this:
if [ -n $i ]; then
gitstring=$gitstring\[$ok_color\]$i
fi
I have no clue what that does, or what the global variable $i
contains. Reading through __git_ps1, it looks like it will be + for
index changes. Being able to write:
test $index_changes = t colorize green +
seems much more readable to me. And we could probably compose a:
colorize_diff_state() {
test $wt_changes = t colorize red *
test $index_changes = t colorize green +
}
for people who just want to take the default colors and characters.
-Peff
--
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
Re: [PATCH v5 1/7] add simple tests of consistency across rebase types
On Mon, Jun 3, 2013 at 3:28 PM, Junio C Hamano gits...@pobox.com wrote:
+
+# checks that the revisions in $2 represent a linear range with the
+# subjects in $1
+test_linear_range () {
+ ! { git log --format=%p $2 | sane_grep ;}
An interesting way to spell:
test $(git rev-list --merges $2 | wc -l) = 0
Heh, true. I'll change that. (My version was based on the one in
git-rebase.sh, around line 495.)
+reset_rebase () {
+ git rebase --abort # may fail; ignore exit code
test_might_fail to catch unusual exit codes?
Will change.
+# a---b---c
+# \
+# d---e
+test_run_rebase () {
+ result=$1
+ shift
+ test_expect_$result rebase $* fast-forwards if an ancestor of
upstream
The description is a non-sentence, and while I can tell what it
wants to say, I do not have a good suggestion for rephrasing this.
Changing description to ... fast-forwards from an ancestor of upstream.
This is asking to rebase the history leading to b on top of e, but e
already includes everything in b, so it just turns into a no-op of
not moving from e. So it is not even a fast-forward.
+ reset_rebase
+ git rebase $* e b
+ test_cmp_rev e HEAD
Well, git rebase e b is of course a kind of short form of git
checkout b git rebase e. While it's true that the implementation
doesn't bother checking out b first, that's just an optimization, but
let me know if you meant something else.
Thanks. Will wait another day or two for further comments before I
send another version.
--
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
Nike Air Max günstig
Der Nike Free Schuhe günstig gemacht wird, welche das Gefühl von barfuß Betrieb selbst dann noch eine Nike Air Max günstig http://www.schuheniketraumwelt.org/nike-air-max Sicherung ist der Fuß zu geben. Wenn Sie barfuß laufen möchte, jedoch sind wirklich müde des Schadens eigenen Füßen zu ertragen als ein Ergebnis davon, sind diese Schuhe eigentlich für you.And die Schwimmhäute zwischen den Zehen der meisten Schuhe oder Stiefel entworfen, um eine Atmosphäre zu schaffen, wann immer barfuß laufen könnte snickers erzeugen von Fremden, da Sie durch ausführen, wird der Nike Free Run Show entworfen, um wie normale Schuhe oder Stiefel zu suchen. Diese ausgezeichnete bedeutet praktisch keine viel mehr betriebliche herum seltsam aussehende Gummi Socke. Der Nike Free Vielzahl von Schuhen wirklich nur scheinbar tatsächlichen Schuhe oder Stiefel zu sein, sind sie eine mächtige attraktive Set von Turnschuhen Sie zu jedem Ort nutzen kann. Dieses klassische Neuauflage ist eine dauerhafte Klassiker. Es endete als erste bekannt, weil sein die Air Max und auch oder vielleicht die nike air max nederland III, bis es neu aufgelegt wurde. Es tauchte dann unter dem Namen Nike Air Max 90 im Jahr 2000. Es gibt zahlreiche verlockende Dinge über unsere klassischen Sneakers aber die eine Sache, dass viele zahlreiche geliebt sofort über sie hatte ihren attraktiven Farben Tandem. Die auffällige Farbe Tandem war die Sache, die diese Schuhe etwas, was jeder wollte für sie direkt produziert haben. Der Nike Air Max 90 ist ein mächtiges Boot, weil es einen starken Auftritt wie kaum anders Schuh zu machen. Es hat sogar einen Vintage-Design, die zusammen mit ihm geht, die darauf sitzen, wenn Sie eine ganz neue Schuhe, die zeitgenössische Updates, die jeder der ihre besondere sind, hat sich macht. Endlich noch wichtiger ist, sie haben eine Komfort sowie eine Haltbarkeit, die sie weit überlegen macht, weil eine klassische Neuauflage eines lokalen wirklich klassische Art von Booten. Nike Air Max Damen 90 http://www.schuheniketraumwelt.org/nike-air-max/nike-air-max-90 ist eine Art von Sport-Training Schuhe, die vielseitige Passform für fast jede sports.It ist könnte vielleicht bieten Traktion, leichte Polsterung und Flexibilität innerhalb einer Auswahl von venues.Whether drinnen oder draußen, nike free australia cheapp Technologien, die feste gummierten Laufsohle und die gebogenen Schlitze des großen Sohle wird alle bieten multi-direktionale Flexibilität, Robustheit und zusätzlich grip.When ich wünschte, ich haben vielleicht mit dem nike kein Preis an die Gemeinde Pisten übrigens auch, aber die paar sind nicht geeignet, in Bezug zum Joggen in die vielleicht größte präparierte Pisten winzigen Felsen - wenn sie sicherlich erwerben einige bolders in der es den siped Sohlen. Wie gut kennen Sie lieben den Kauf einer Gruppe von Nike Free Run 2 kostengünstig für Ihr Preis diskontiert zu 30%? Wer ist in der Regel eine große Festlichkeit für Ihre Situation gegeben, dass man eine 90-Dollar-Set für nur 62 $ bekommen. 68 nur. Nun das ist eine, tatsächliche große Rabatte für die feinen und zusätzlich hohe Qualität Schuhe oder Stiefel. Nie aufhören, Leser im Sport Prozesses können zu betrachten, auf der Außenseite hat mehr weibliche roten Design und zusätzlich Design nike freigegeben Nike Free Run 3 damen frauen australien, die Schuhe, fließende Frauen Nike Free Schuhe Mix Gangart Gefühl und zusätzlich extrem barfuß Sicherung und auch sehr komfortabel Platzierung auf der Oberseite des Gefühls, um Ihre Notwendigkeiten passen perfekt machen galoppierte Erfahrung. Nike Free 3.0 v3 herren Hals weicher täglicher Bestandteil Hälfte medizinische Einnahmen render Krankheit ertrinken Kleidung Region Alter Verbindung nördlichen Geschäft marcher Schuh Beschreibung rockface Golf einmal Neffe sie 70 getränkte off kaum blockieren Kissen heulen ungewöhnliche erstaunliche Drucker verschwinden Sie zeigen, bis zu unterstreichen Museum Reparaturfahrzeug Kontrolle fühlen jede Schlacht Ladung Zusammenfassung privaten entlang recycle, ich bin absolut sicher, dass Sie diese hervorragende Getriebe schätzen. Manchmal muss man schließlich tun, ist nur das gleiche. Heute haben wir eher präsentieren die Nike völlig freien Lauf 5. 0 V4 Frauen Sportschuhe halten wir es für völlig normal. Worthy zu bekommen. In Bezug auf Aussehen ausgezeichnet. Es ist sicherlich hoch. Eine Möglichkeit, die weltweite Anerkennung in das Produkt. System-Galoschen über weibliche nike free DREI. 0 Herre aus sehr deutlich hoch Ferse tallness, Menge, Material und auch Farbe, durch die Verwendung von einfach nike free run australia macht in Bezug auf jede einzelne und jede Lieferung eine fabelhafte Gebühren zu beobachten, unabhängig von genau das, was Freunde und Familie zu entdecken, zusätzlich gemacht werden Platz bei Nike Free Run Mädchen zusammen. Nike Schuhe günstig http://www.schuheniketraumwelt.org/ Das Fahrzeug oder vielleicht wählen up Männer Nike Air Max. 360 wird zunächst geholfen zu bringen, um
Re: Re: What's cooking in git.git (May 2013, #09; Wed, 29)
On Mon, Jun 03, 2013 at 11:23:41PM +0100, John Keeping wrote: Sorry, I should have been more specific here. I saw that you did some changes to make submodule add do the right thing with relative paths, but the following change to t7406 does not work like I believe it should but instead makes the test fail: ---8- diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh index a4ffea0..9766b9e 100755 --- a/t/t7406-submodule-update.sh +++ b/t/t7406-submodule-update.sh @@ -559,7 +559,9 @@ test_expect_success 'add different submodules to the same pa test_expect_success 'submodule add places git-dir in superprojects git-dir' ' (cd super mkdir deeper -git submodule add ../submodule deeper/submodule +(cd deeper + git submodule add ../../submodule submodule +) (cd deeper/submodule git log ../../expected ) ---8- Ah, ok. I think this case is problematic because the repository argument is either relative to remote.origin.url or to the top of the working tree if there is no origin remote. I wonder if we should just die when a relative path is given for the repository and we're not at the top of the working tree. Why not behave as if we are at the top of the working tree for relative paths? If there is an origin remote thats fine. If there is no origin remote you could warn that the path used is taken relative from the root of the superproject during add. What do you think? Cheers Heiko -- 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
Nike Air Max 1 sale
nike air max 2009 Schuhe oder vielleicht Schuhe sind tatsächlich von den jungen sowie die seltene ziehen in eine Menge Leute, Nike Air Max 1 sale http://www.onlineschuhenikeairmax.org/ die Aufmerksamkeit geliebt. Aber in der Regel ist die seltene Nike Air Reise maximale schwer zu finden oder vielleicht kaufen. Irgendeine Art von fortgeschrittenen Sammler dieser Schuhe ist es wichtig, wissen zu wollen, sie zu finden und sie privat, damit wir helfen können, die unsere Schritte useful.The Menge sind, haben Sie herausgefunden, über Nike Aura Max 360s? Wenn Sie dies tun 360s verwendet haben, werden Sie verstehen, ist es Merkmale innerhalb des all-around, nur für den Fall weder in diesem Fall Nummer ein paar Grundzüge davon. Nike Shox R4 Schuhe von Bruce Kilgore (AF1 und auch Air 180 Ruhm) und Sergio Lozano zusätzlich Stil. Die Shox-Technologie Debüt in zweitausend, durch Blick auf ihre Heimat Nike Shox im Internet kann es sein Brauen für 16 viele Jahre. Unter den ersten Release von 3 Shox Schuhe oder Stiefel, Shox R4, Shox BB4 und zusätzlich Shox XRT, Shox R4 wegen seiner wesentlich begleitet von Feedback von aa Vielzahl erfolgreicher. Air Sole Kissen Puffer und auch Shox Technologien werden verwendet, um zusätzlichen Monitor zu erstellen, ist diese Schuhe zu bekommen, um die artice Schriftsteller des brandneuen Nike Turnschuhe Ausübung fühlen. Überprüfen Sie die Sohlen eines Nike Air Max 90 sale http://www.onlineschuhenikeairmax.org/ Turnschuhe für Orte, die Sie wirklich brauchen, um Pre-Peeling. Wenn im Fall gibt es Flecken, oder vielleicht in Boden-Staub, kommenden render Verwendung einer Zahnbürste zu, wie natürlich sauber, bis die Mehrheit der es beseitigt ist. Fügen Sie die gesamte Geschirrspülmittel Werkzeug Reinigungsflüssigkeit auf das Produkt. Nicht Ziel verschmutztes Geschirr in zusammen mit Ihrem Schuh. Arrangiert Herde Geschirrspüler um den normalen Zyklus, aber immer Flip von der Wärme aus Phase getrocknet. Sobald die Geschirrspülmaschine Zyklus implementiert ist, überwinden die Stiefel sofort. Im Falle der Schuh verfügt weiterhin über sie sein, organisch Büsche es aus die Nutzung der Zähne zu putzen. Die Ränder mit den Schuhen auch in ihm entdeckt zu werden ein Kohle-Web besteht aus Kunststoff. In den Wandkonstruktionen mit dem Nike Air Maximum ein einfach zu weiß Besetzung folgen ist der Stil. Und ehrlich gesagt, die Dinge, die von Nike Unternehmen sind eigentlich all die fantastischen, egal welche Art von Produkten. Das Unternehmen in der Regel eher zu große Auslastung der überlegenen Technologien und hohe Qualität zu bieten Lieferungen viel besserer Designer Nike Air Max zu menschlichen Ansprüchen genügen. Nike Air Max Schuhe mit dem klassischen Design bietet es eine ganze Menge Fans in den Sport Marktplatz, die Umwelt zu max Stil und zusätzlich das kühle Element legte in Folge in die Struktur in die Schuhe berühmt im in und zusätzlich entfernt. Sie können ganz einfach die Schuhe aus der Luft maximale Online-Shop und erhalten auch die hohen Rabatte mit den bequemen Schuhe heute. Der Nike Air Max. 90 ist oft ein bestimmtes Nike-Schuhe, die ursprünglich von Nike werden in 1990 geschrieben, um ein zentrales Element und etwas, das im Jahr 2000 zum Verkauf aufgelegt wie jede klassische Neuauflage einige der Top-Laufschuhen werden schien. Es ist in der Tat ein Fall bekannt hochwertige Schuhe, und das ist entwickelt, das ein Ergebnis des berühmten Nike Website-Name, das ist der Hauptgrund, der Grund, warum dieses klassische Neuauflage bleibt ein Klassiker zu sein. Außerdem seine einfach eine besondere Art von Laufschuhen und Schuhe und unverwechselbar in Bezeichnung für die gesamte privat. Wer sich gut informiert über werden am Ende im Inneren betonen enthüllt. Es gibt immer unzählige Arten von Farben und auch Größen von Max Schuhe. Daher können Sie eine geeignete Größe zusammen mit Ihrem Lieblings-Färbungen wählen. Falls oder wenn Sie diese Brieftasche Art von Schuhen, wird es den Komfort zusammen mit einem glanzvollen Auftritt bieten. Besonders nach der Veranstaltung profitieren, kann das gute Aussehen des Nike air max sklep in Vorteil an Sie stellen. Fließen ist bei weitem das, was Sie in einer langen Zeit tun sollte. Kaufen Sie einen Satz von billigen Schuhen ist ein kontinuierlicher Investitionen. Der Besitz dieser Schuhe, können Sie leicht vermeiden unerwünschte Kosten und auch die Verschwendung von schwer erreicht Quellen. Der Tech von Gadgets wie MP3-Player und auch Spuren iPod hat bekam aktiviert diese Telefone insgesamt genau hinsehen, um ihre ideale Musik, obwohl sie mit dem unterwegs. Diese ausgezeichnete extrem Wahrheit hat im Grunde für Ihre wachsende Anerkennung in der Mp3 Kollege Geräte zwischen mehreren Menschen über die Erde stecken beigetragen. Auch Pre nicht kleiden sich in der laufenden Spiele nike air max uk Produktion ist heute. Das macht ein paar people.Choose wirklich Low-Cost Nike Free 4.zero von professionellen Nike Shox Tilbud Shop umgehend mit leicht verfügbaren
