* Re: [REROLL PATCH 6/8] Support remote helpers implementing smart transports
From: Junio C Hamano @ 2009-12-08 23:38 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-7-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
> ---
> Documentation/git-remote-helpers.txt | 25 +++++++-
> transport-helper.c | 126 ++++++++++++++++++++++++++++++++--
> 2 files changed, 144 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index 20a05fe..b957813 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -93,6 +93,20 @@ Supported if the helper has the "push" capability.
> +
> Supported if the helper has the "import" capability.
>
> +'connect' <service>::
> + Connects to given service. Stdin and stdout of helper are
A minor point, but in prose, unless it explains how to use "stdin" and
"stdout" as a variable, keyword, etc. in code, I'd prefer to see these
spelled out, like so:
The standard input and output of helpers are connected to ...
> @@ -34,12 +36,12 @@ static void sendline(struct helper_data *helper, struct strbuf *buffer)
> die_errno("Full write to remote helper failed");
> }
>
> -static int recvline(struct helper_data *helper, struct strbuf *buffer)
> +static int _recvline(FILE *helper, struct strbuf *buffer)
> {
Not a good naming for two reasons.
- Somebody new to the code wouldn't be able to tell which of recvline()
and _recvline() take helper_data and FILE easily.
- A function name that starts with an underscore, even if it is file
scoped static, is something we tend to avoid. This applies to
_process_connect() in the earlier patch as well.
recvline_fh() vs revline() might be better as most of the interaction in
this layer are done on helper_data, which makes the name recvline() pair
nicely with sendline that also takes helper_data; and the oddball one that
is _not_ an implementation detail (i.e. you have calls outside recvline()
implementation that call _recvline()) hints that it takes filehandle
instead.
^ permalink raw reply
* Re: [REROLL PATCH 7/8] Support remote archive from external protocol helpers
From: Junio C Hamano @ 2009-12-08 23:39 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1260278177-9029-8-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> Helpers which support connect also should support remote archive
> snapshot (or at least there's only one way to attempt it). So support
> remote snapshotting for protocol helpers.
Sorry, but I cannot parse this "should", and cannot understand how the
first sentence leads to the conclusion ("So") that we must have this
patch.
"They should support it when able, because doing so gives them _this nice
property_ (that is unspecified)"???
Or "They must support it because we are changing the code not to work
without"???
Or "Because the transport layer has been restructured cleanly enough to
allow passing general payload, there is no reason not to do this change to
pass 'archive' output in addition to the 'git smart fetch/push protocol'
payload, and this allows the archive command to take advantage of the
helper based transports"???
^ permalink raw reply
* Re: PATCH/RFC] gitweb.js: Workaround for IE8 bug
From: Stephen Boyd @ 2009-12-09 0:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200912082332.29925.jnareb@gmail.com>
On Tue, 2009-12-08 at 23:32 +0100, Jakub Narebski wrote:
> Dnia wtorek 8. grudnia 2009 22:56, Stephen Boyd napisał:
> > Yes, there is no longer an error but IE8 still locks up and takes about
> > 30 seconds. It doesn't seem to be any more responsive. Isn't putting the
> > error in a try-catch just papering over the issue?
>
> Does increasing interval in setInterval call at the end of startBlame
> finction in gitweb.js from 1000 (1 second) to e.g. 2000 (2 seconds)
> help there?
>
I tried numbers from 100 to 10000 and didn't see a difference. Files
with only a few hundred lines or less don't lock up though. I've been
using builtin-apply.c for testing.
^ permalink raw reply
* Truth about manhood quality
From: Joachim Norman @ 2009-10-09 23:47 UTC (permalink / raw)
To: git
Always be ready http://oul.owiccypsu.com/
^ permalink raw reply
* Re: help: bisect single file from repos
From: SZEDER Gábor @ 2009-12-09 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder, Michael J Gruber, wharms
In-Reply-To: <7vein5e2lc.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Dec 08, 2009 at 10:35:11AM -0800, Junio C Hamano wrote:
> But I wonder if there is
> something we _could_ have done better in the documentation area to avoid
> this from the beginning, iow, make it easier to "learn how things work
> before using"? I think there is a lesson to be learned by us in here, and
> I'd like to hear comments and improvement suggestions, especially from
> "usability" and "friendly to new people" advocates.
when a git command accepts a commit as command line option, the
documentation usually refers to the "Specifying revisions" section of
'git rev-parse's docs for "a more complete list of ways to spell
commits"[1]. Even the docs of porcelain commands and the user manual
do that. But 'git rev-parse' is plumbing, and we actively advertise
that avarage users don't really need to know about plumbing at all.
While new to git I repeatedly encountered this reference to 'git
rev-parse' all over the porcelain manpages, and it was a real burden
for me back then. I was like "but I don't want to know about all the
glory details, just give me a short summary".
I think the user should not refer to plumbing manpages to be able to
use porcelain commands. Therefore, the manpage of every command
accepting a commit option need to have a section about specifying
these commits. This section doesn't need to be as detailed as 'git
rev-parse'; perhaps we don't need to discuss the ^{} notation there.
Also, the precedence in case of an ambiguous symbolic ref name should
be described without reference to the internal $GIT_DIR/refs/
directory structure.
Furthermore, some manpages use the term "<commit>", while others
"<committish>" or "<rev>". The same term should be used everywhere.
Best,
Gábor
[1] - 'git cherry-pick' doc says the following:
<commit>
Commit to cherry-pick. For a more complete list of ways to spell
commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
What? "A _more_ complete list"!? Well, it's not very hard to be more
complete than this, there is not a single way described here (;
^ permalink raw reply
* Re: [PATCH v2 1/3] refactor ref status logic for pushing
From: Tay Ray Chuan @ 2009-12-09 3:40 UTC (permalink / raw)
To: Daniel Barkalow
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Clemens Buchacher,
Jeff King, Junio C Hamano
In-Reply-To: <alpine.LNX.2.00.0912081158040.14365@iabervon.org>
Hi,
On Wed, Dec 9, 2009 at 1:17 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 8 Dec 2009, Tay Ray Chuan wrote:
>
>> Move the logic that detects up-to-date and non-fast-forward refs to a
>> new function in remote.[ch], set_ref_status_for_push().
>
> Is there some reason to not have set_ref_status_for_push() be static in
> transport.c now? (Sorry for not suggesting this before.)
it can't be static, because builtin-send-pack.c::main() needs it too.
> Other than that, it looks good to me.
Thanks.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Nanako Shiraishi @ 2009-12-09 3:55 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jeff King, Junio C Hamano, Nanako Shiraishi, Johannes Schindelin,
Matthieu Moy, Michael J Gruber, Michael Haggerty, git
In-Reply-To: <fabb9a1e0912080551s32295cfahf05bdc715360360@mail.gmail.com>
Quoting Sverre Rabbelier <srabbelier@gmail.com>
> Heya,
>
> On Tue, Dec 8, 2009 at 10:35, Jeff King <peff@peff.net> wrote:
>> $ bash
>> $ echo "!fixup commit"
>> bash: !fixup: event not found
>> $ echo "fixup! commit"
>> fixup! commit
>
> Speaking of which, must we use that annoying bang? I hate how bash
> gets in my way when I try to write a commit message with a a bang in
> it, I'd much rather use a different character that is not in risk of
> being mistreated by my shell. (Although it seems that bash does do TRT
> in the 'fixup!' case.)
>
> --
> Cheers,
>
> Sverre Rabbelier
There was a strong objection (I think from Johanes) against not
using 'unusual' letters during the initial round back in June
2009. Even when explicitly giving '--auto-squash' from the
command line, there can be commits with confusing titles
like "fixup the ancient bug in cat-file" in addition to
the ones you wanted to mark with the "fixup!" marker.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Weird message when pulling git version 1.6.6.rc1.39.g9a42
From: Nanako Shiraishi @ 2009-12-09 3:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Alejandro Riveira, git, Horst H. von Brand, Nanako Shiraishi
In-Reply-To: <7vmy1t6nye.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Alejandro Riveira <ariveira@gmail.com> writes:
>
>> $ git pull
>> remote: Counting objects: 9, done.
>> remote: Compressing objects: 100% (5/5), done.
>> remote: Total 5 (delta 4), reused 0 (delta 0)
>> Unpacking objects: 100% (5/5), done.
>> From git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
>> 6035ccd..a252e74 master -> origin/master
>> Updating 6035ccd..a252e74
>> Fast-forward (no commit created; -m option ignored) # what is this ??
>> net/sctp/sysctl.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> Thanks for reporting.
>
> Warning about a message that the end user didn't give the command is
> clearly wrong. I guess we would want to revert c0ecb07 (git-pull.sh: Fix
> call to git-merge for new command format, 2009-12-01), and b81e00a
> (git-merge: a deprecation notice of the ancient command line syntax,
> 2009-11-30).
>
> Reverting them will still keep 76bf488 (Do not misidentify "git merge foo
> HEAD" as an old-style invocation, 2009-12-02) that resulted in the change
> we are reverting here, so we are still ahead ;-)
>
> http://thread.gmane.org/gmane.comp.version-control.git/134103/focus=134145
Sorry for causing too much trouble. I feel bad.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Aaron Cohen @ 2009-12-09 4:41 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Sverre Rabbelier, Jeff King, Junio C Hamano, Johannes Schindelin,
Matthieu Moy, Michael J Gruber, Michael Haggerty, git
In-Reply-To: <20091209125555.6117@nanako3.lavabit.com>
On Tue, Dec 8, 2009 at 10:55 PM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Sverre Rabbelier <srabbelier@gmail.com>
>
>> Heya,
>>
>> On Tue, Dec 8, 2009 at 10:35, Jeff King <peff@peff.net> wrote:
>>> $ bash
>>> $ echo "!fixup commit"
>>> bash: !fixup: event not found
>>> $ echo "fixup! commit"
>>> fixup! commit
>>
>> Speaking of which, must we use that annoying bang? I hate how bash
>> gets in my way when I try to write a commit message with a a bang in
>> it, I'd much rather use a different character that is not in risk of
>> being mistreated by my shell. (Although it seems that bash does do TRT
>> in the 'fixup!' case.)
>>
>> --
>> Cheers,
>>
>> Sverre Rabbelier
>
> There was a strong objection (I think from Johanes) against not
> using 'unusual' letters during the initial round back in June
> 2009. Even when explicitly giving '--auto-squash' from the
> command line, there can be commits with confusing titles
> like "fixup the ancient bug in cat-file" in addition to
> the ones you wanted to mark with the "fixup!" marker.
>
> --
I'm sorry to pipe in with my perhaps half-baked idea from lurkerdom,
but would autosquash make more sense designed as a hook rather than as
a special case behavior of git-rebase?
I think this feature could be implemented by having git-rebase call a
hook if supplied the --autosquash command. The hook script would be
supplied with the id of the blobs being fixed up on standard input,
and it could do whatever it wanted internally (including looking for
magic !commands in the commit messages of the blobs).
The result of the script should be the list of blobs to be commited as
a result of the script's munging, on standard output.
^ permalink raw reply
* Re: [PATCH 2/2] git-svn: Move setting of svn.authorsfile in clone to between init and fetch
From: Eric Wong @ 2009-12-09 4:44 UTC (permalink / raw)
To: Junio C Hamano, Alex Vandiver; +Cc: git
In-Reply-To: <1260305651-11111-2-git-send-email-alex@chmrr.net>
Alex Vandiver <alex@chmrr.net> wrote:
> If a clone errors out because of a missing author, or user interrupt,
> this allows `git svn fetch` to resume seamlessly, rather than forcing
> the user to re-provide the path to the authors file.
Thanks Alex,
I shortened the subject on this one, acked the series and pushed to
git://git.bogomips.org/git-svn
Alex Vandiver (2):
git-svn: Set svn.authorsfile to an absolute path when cloning
git-svn: set svn.authorsfile earlier when cloning
--
Eric Wong
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Miles Bader @ 2009-12-09 4:51 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Björn Steinbrink, git, Junio C Hamano
In-Reply-To: <20091208164449.GA32204@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which
> can't easily be achieved with existing commands, especially if you add
> "-i".
It also allows making use of rebase's rather extensive machinery for
dealing with conflicts (e.g., rebase --continue / --skip / --abort).
But it would make more sense to have it in cherry-pick...
(cherry-pick --continue / --skip / --abort...)
-Miles
--
Consult, v.i. To seek another's disapproval of a course already decided on.
^ permalink raw reply
* error: git-svn died of signal 13
From: Jonathan Nieder @ 2009-12-09 5:36 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Hi,
Just wanted to pass on a few reports about git-svn dying with SIGPIPE
when trying to fetch large repositories. It seems to fetch a few
revisions, then die; the repositories can eventually be fetched
successfully by restarting 'git svn fetch' again and again.
Some bug reporters have been very patient, but I don’t really know
where to look or ask in solving this. Attempts at tracing so far have
given either too little or too much information to make any sense.
The problem goes back at least to v1.5.6.5.
At the end of the git-svn process’s life, the last few function calls
are these:
- SVN::Ra::Reporter::finish_report and related functions
- _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
- SVN::Ra::Callbacks::open_tmp_file, called from
SVN::_Ra::svn_ra_do_update, called from
Git::SVN::Ra::do_update, called from
Git::SVN::Ra::gs_do_update
- Git::SVN::_set_repos_root
- starting a 'git update-index -z --index-info' to feed commands to
Maybe /tmp is filling up? It is hard to know, since the SIGPIPE stops
everything and we do not get any nice, simple error message describing
what read or write would have received EPIPE.
See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
<http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
Any insights?
Jonathan
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Christian Couder @ 2009-12-09 5:30 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Stephan Beyer, Christian Couder, Daniel Barkalow,
Git List, Johannes Schindelin
In-Reply-To: <fabb9a1e0912081229l7990a148j9cd2daa338662dd@mail.gmail.com>
Hi,
On mardi 08 décembre 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Tue, Dec 8, 2009 at 21:22, Junio C Hamano <gitster@pobox.com> wrote:
> > But I think it is a reasonable thing to _implement_ the feature to
> > range-pick commits reusing the sequencing logic already in "rebase" and
> > "rebase -i". That essentially is what we wanted to do with "git
> > sequencer" that would be a sequencing logic backend shared among
> > rebase, cherry-pick, and perhaps am.
>
> Speaking of which, what's the status of git sequencer? I seem to
> remember some activity recently to slowly rewrite git rebase in c, but
> I haven't seen anything since then. Is it still moving forward? Is
> anyone interested in doing so? Just curious...
Last June and July, I sent some patch series to port "rebase -i" to C using
code from the sequencer project. My goal was to save some interesting code
from the sequencer GSoC 2008 project and at the same time to move
forward "rebase -i" code toward a sequencer.
But Dscho and Junio didn't like the fact that the code from the sequencer I
added was duplicating existing code and was not properly refactored, though
it also added things that would be needed later for the sequencer. My plan
was to refactor later, once I had a sequencer, but Junio and Dscho did not
like that plan. They said it would be a too big maintenance burden.
So I agreed to not duplicate any existing code and to properly refactor
everything. And I have been trying to take interesting and useful code from
the sequencer project and to integrate it into existing commands. And this
is why I sent yesterday the 4th version of my '"git reset --merge" related
improvements' patch series.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Junio C Hamano @ 2009-12-09 5:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, git
In-Reply-To: <4B1E798C.5050204@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>> Michael J Gruber wrote:
>>
>>> +decrypt_color () {
>>> + sed \
>>> + -e 's/.\[1m/<WHITE>/g' \
>>> + -e 's/.\[31m/<RED>/g' \
>>> + -e 's/.\[32m/<GREEN>/g' \
>>> + -e 's/.\[34m/<BLUE>/g' \
>>> + -e 's/.\[m/<RESET>/g'
>>> +}
>>
>> Shouldn't this be better in test-lib.sh, or some common lib
>> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>> in naming here)?
>
> Well, so far it's used in two places (and somewhat differently). I would
> say test-libification starts at 3 :)
That is a pretty lame excuse and is a bad way to keep things maintainable.
Having two copies now means that you will *double* the chance for the next
person to copy and paste one of the existing copies that are found in the
non-library-ish part of the test script set to create the third duplicate,
without even realizing that there already are two copies that should have
been consolidated in the first place. The worst part is that once that
duplication is pointed out, s/he will use the existing two copies as an
excuse for copy and paste.
Please don't.
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Junio C Hamano @ 2009-12-09 5:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, git
In-Reply-To: <7vzl5sww3w.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>>> Michael J Gruber wrote:
>>>
>>>> +decrypt_color () {
>>>> + sed \
>>>> + -e 's/.\[1m/<WHITE>/g' \
>>>> + -e 's/.\[31m/<RED>/g' \
>>>> + -e 's/.\[32m/<GREEN>/g' \
>>>> + -e 's/.\[34m/<BLUE>/g' \
>>>> + -e 's/.\[m/<RESET>/g'
>>>> +}
>>>
>>> Shouldn't this be better in test-lib.sh, or some common lib
>>> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>>> in naming here)?
>>
>> Well, so far it's used in two places (and somewhat differently). I would
>> say test-libification starts at 3 :)
> ...
> Please don't.
I'll squash this in to fix it up.
I don't know where 36->BROWN mistake came from when color.h has a
series of #define that can be used to make the decoding script
mechanically, though ;-)
t/t4034-diff-words.sh | 23 ++++---------
t/t7508-status.sh | 83 ++++++++++++++++++++++---------------------------
t/test-lib.sh | 11 ++++++
3 files changed, 55 insertions(+), 62 deletions(-)
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 4508eff..ea895b0 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -11,18 +11,9 @@ test_expect_success setup '
'
-decrypt_color () {
- sed \
- -e 's/.\[1m/<WHITE>/g' \
- -e 's/.\[31m/<RED>/g' \
- -e 's/.\[32m/<GREEN>/g' \
- -e 's/.\[36m/<BROWN>/g' \
- -e 's/.\[m/<RESET>/g'
-}
-
word_diff () {
test_must_fail git diff --no-index "$@" pre post > output &&
- decrypt_color < output > output.decrypted &&
+ test_decode_color <output >output.decrypted &&
test_cmp expect output.decrypted
}
@@ -47,7 +38,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
<RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
<RESET>
a = b + c<RESET>
@@ -68,7 +59,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
h(4),<GREEN>hh<RESET>[44]
<RESET>
a = b + c<RESET>
@@ -104,7 +95,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
h(4)<GREEN>,hh[44]<RESET>
<RESET>
a = b + c<RESET>
@@ -146,7 +137,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
h(4),<GREEN>hh[44<RESET>]
<RESET>
a = b + c<RESET>
@@ -168,7 +159,7 @@ cat > expect <<\EOF
<WHITE>index c29453b..be22f37 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1 +1 @@<RESET>
+<CYAN>@@ -1 +1 @@<RESET>
aaa (aaa) <GREEN>aaa<RESET>
EOF
@@ -187,7 +178,7 @@ cat > expect <<\EOF
<WHITE>index 289cb9d..2d06f37 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1 +1 @@<RESET>
+<CYAN>@@ -1 +1 @@<RESET>
(<RED>:<RESET>
EOF
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 50554a0..cf67fe3 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -8,45 +8,36 @@ test_description='git status'
. ./test-lib.sh
test_expect_success 'setup' '
- : > tracked &&
- : > modified &&
+ : >tracked &&
+ : >modified &&
mkdir dir1 &&
- : > dir1/tracked &&
- : > dir1/modified &&
+ : >dir1/tracked &&
+ : >dir1/modified &&
mkdir dir2 &&
- : > dir1/tracked &&
- : > dir1/modified &&
+ : >dir1/tracked &&
+ : >dir1/modified &&
git add . &&
git status >output &&
test_tick &&
git commit -m initial &&
- : > untracked &&
- : > dir1/untracked &&
- : > dir2/untracked &&
- echo 1 > dir1/modified &&
- echo 2 > dir2/modified &&
- echo 3 > dir2/added &&
+ : >untracked &&
+ : >dir1/untracked &&
+ : >dir2/untracked &&
+ echo 1 >dir1/modified &&
+ echo 2 >dir2/modified &&
+ echo 3 >dir2/added &&
git add dir2/added
'
-decrypt_color () {
- sed \
- -e 's/.\[1m/<WHITE>/g' \
- -e 's/.\[31m/<RED>/g' \
- -e 's/.\[32m/<GREEN>/g' \
- -e 's/.\[34m/<BLUE>/g' \
- -e 's/.\[m/<RESET>/g'
-}
-
test_expect_success 'status (1)' '
grep "use \"git rm --cached <file>\.\.\.\" to unstage" output
'
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -72,12 +63,12 @@ EOF
test_expect_success 'status (2)' '
- git status > output &&
+ git status >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -90,7 +81,7 @@ EOF
test_expect_success 'status -s (2)' '
- git status -s > output &&
+ git status -s >output &&
test_cmp expect output
'
@@ -112,8 +103,8 @@ cat >expect <<EOF
EOF
test_expect_success 'status -uno' '
mkdir dir3 &&
- : > dir3/untracked1 &&
- : > dir3/untracked2 &&
+ : >dir3/untracked1 &&
+ : >dir3/untracked2 &&
git status -uno >output &&
test_cmp expect output
'
@@ -258,7 +249,7 @@ test_expect_success 'status -s (status.showUntrackedFiles all)' '
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -284,12 +275,12 @@ EOF
test_expect_success 'status with relative paths' '
- (cd dir1 && git status) > output &&
+ (cd dir1 && git status) >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M modified
A ../dir2/added
?? untracked
@@ -301,12 +292,12 @@ A ../dir2/added
EOF
test_expect_success 'status -s with relative paths' '
- (cd dir1 && git status -s) > output &&
+ (cd dir1 && git status -s) >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -319,7 +310,7 @@ EOF
test_expect_success 'status --porcelain ignores relative paths setting' '
- (cd dir1 && git status --porcelain) > output &&
+ (cd dir1 && git status --porcelain) >output &&
test_cmp expect output
'
@@ -330,7 +321,7 @@ test_expect_success 'setup unique colors' '
'
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -357,7 +348,7 @@ EOF
test_expect_success 'status with color.ui' '
git config color.ui always &&
- git status | decrypt_color > output &&
+ git status | test_decode_color >output &&
test_cmp expect output
'
@@ -366,12 +357,12 @@ test_expect_success 'status with color.status' '
git config --unset color.ui &&
git config color.status always &&
- git status | decrypt_color > output &&
+ git status | test_decode_color >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
<RED>M<RESET> dir1/modified
<GREEN>A<RESET> dir2/added
<BLUE>??<RESET> dir1/untracked
@@ -386,7 +377,7 @@ test_expect_success 'status -s with color.ui' '
git config --unset color.status &&
git config color.ui always &&
- git status -s | decrypt_color > output &&
+ git status -s | test_decode_color >output &&
test_cmp expect output
'
@@ -395,12 +386,12 @@ test_expect_success 'status -s with color.status' '
git config --unset color.ui &&
git config color.status always &&
- git status -s | decrypt_color > output &&
+ git status -s | test_decode_color >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -415,7 +406,7 @@ test_expect_success 'status --porcelain ignores color.ui' '
git config --unset color.status &&
git config color.ui always &&
- git status --porcelain | decrypt_color > output &&
+ git status --porcelain | test_decode_color >output &&
test_cmp expect output
'
@@ -424,7 +415,7 @@ test_expect_success 'status --porcelain ignores color.status' '
git config --unset color.ui &&
git config color.status always &&
- git status --porcelain | decrypt_color > output &&
+ git status --porcelain | test_decode_color >output &&
test_cmp expect output
'
@@ -433,7 +424,7 @@ test_expect_success 'status --porcelain ignores color.status' '
git config --unset color.status
git config --unset color.ui
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -461,12 +452,12 @@ EOF
test_expect_success 'status without relative paths' '
git config status.relativePaths false
- (cd dir1 && git status) > output &&
+ (cd dir1 && git status) >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -479,7 +470,7 @@ EOF
test_expect_success 'status -s without relative paths' '
- (cd dir1 && git status -s) > output &&
+ (cd dir1 && git status -s) >output &&
test_cmp expect output
'
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5fdc5d9..d63ad2d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -208,6 +208,17 @@ test_set_editor () {
export VISUAL
}
+test_decode_color () {
+ sed -e 's/.\[1m/<WHITE>/g' \
+ -e 's/.\[31m/<RED>/g' \
+ -e 's/.\[32m/<GREEN>/g' \
+ -e 's/.\[33m/<YELLOW>/g' \
+ -e 's/.\[34m/<BLUE>/g' \
+ -e 's/.\[35m/<MAGENTA>/g' \
+ -e 's/.\[36m/<CYAN>/g' \
+ -e 's/.\[m/<RESET>/g'
+}
+
test_tick () {
if test -z "${test_tick+set}"
then
^ permalink raw reply related
* Re: error: git-svn died of signal 13
From: Eric Wong @ 2009-12-09 5:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091209053602.GA2739@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Just wanted to pass on a few reports about git-svn dying with SIGPIPE
> when trying to fetch large repositories. It seems to fetch a few
> revisions, then die; the repositories can eventually be fetched
> successfully by restarting 'git svn fetch' again and again.
>
> Some bug reporters have been very patient, but I don’t really know
> where to look or ask in solving this. Attempts at tracing so far have
> given either too little or too much information to make any sense.
>
> The problem goes back at least to v1.5.6.5.
Hi Jonathan,
Thanks for taking the time to look into this. This has been a
problem for a long time and very difficult to track down.
One factor is that git svn continues happily afterwards so it's hard to
reproduce and there's less incentive to look for a fix.
> At the end of the git-svn process’s life, the last few function calls
> are these:
>
> - SVN::Ra::Reporter::finish_report and related functions
> - _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
> - SVN::Ra::Callbacks::open_tmp_file, called from
> SVN::_Ra::svn_ra_do_update, called from
> Git::SVN::Ra::do_update, called from
> Git::SVN::Ra::gs_do_update
> - Git::SVN::_set_repos_root
> - starting a 'git update-index -z --index-info' to feed commands to
>
> Maybe /tmp is filling up? It is hard to know, since the SIGPIPE stops
> everything and we do not get any nice, simple error message describing
> what read or write would have received EPIPE.
>
> See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
> <http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
>
> Any insights?
Can somebody get an strace or core dump for the "git update-index"
call? Or even an strace -f of the entire git svn invocation as well...
--
Eric Wong
^ permalink raw reply
* Re: Weird message when pulling git version 1.6.6.rc1.39.g9a42
From: Junio C Hamano @ 2009-12-09 6:00 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Alejandro Riveira, git, Horst H. von Brand
In-Reply-To: <20091209125556.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Reverting them will still keep 76bf488 (Do not misidentify "git merge foo
>> HEAD" as an old-style invocation, 2009-12-02) that resulted in the change
>> we are reverting here, so we are still ahead ;-)
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/134103/focus=134145
>
> Sorry for causing too much trouble. I feel bad.
Oh, please don't be. You reported a real problem, and we do not shoot the
messengers.
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Junio C Hamano @ 2009-12-09 6:16 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, Matthieu Moy, Michael J Gruber,
Michael Haggerty, git
In-Reply-To: <7viqchhl7h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> @@ -519,6 +521,43 @@ get_saved_options () {
>> test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
>> }
>>
>> +# Rearrange the todo list that has both "pick sha1 msg" and
>> +# "pick sha1 !fixup/!squash msg" appears in it so that the latter
>> +# comes immediately after the former, and change "pick" to
>> +# "fixup"/"squash".
>> +rearrange_squash () {
>> + sed -n -e 's/^pick \([0-9a-f]*\) !\(squash\) /\1 \2 /p' \
>> + -e 's/^pick \([0-9a-f]*\) !\(fixup\) /\1 \2 /p' \
>> + "$1" >"$1.sq"
>> + test -s "$1.sq" || return
>> +
>> + sed -e '/^pick [0-9a-f]* !squash /d' \
>> + -e '/^pick [0-9a-f]* !fixup /d' \
>> + "$1" |
>> + (
>> + used=
>> + while read pick sha1 message
>> + do
>> + ...
>> + done >"$1.rearranged"
>> + )
>> + cat "$1.rearranged" >"$1"
>> + rm -f "$1.sq"
>> +}
>
> The logic to move the lines seem to have been improved since the last
> round, which is good. I've amended this to remove "$1.rearranged" as well.
Actually I think the logic in the version from the June is more correct;
doesn't this version drop commits that are marked as "squash! <message>"
but with a misspelled <message> part? I think your old version, when it
didn't find a matching one in early part, left such an unmatched "fixup"
in place.
Here is a fix-up patch I think should be squashed in. I added a test to
make sure that a mismatching "squash!" is kept in place. Please double
check for sanity.
Thanks.
git-rebase--interactive.sh | 38 ++++++++++++++++----------------------
t/t3415-rebase-autosquash.sh | 15 +++++++++++++++
2 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c68cc5b..935e9e1 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -531,29 +531,23 @@ rearrange_squash () {
"$1" >"$1.sq"
test -s "$1.sq" || return
- sed -e '/^pick [0-9a-f]* squash! /d' \
- -e '/^pick [0-9a-f]* fixup! /d' \
- "$1" |
- (
- used=
- while read pick sha1 message
+ used=
+ while read pick sha1 message
+ do
+ case " $used" in
+ *" $sha1 "*) continue ;;
+ esac
+ echo "$pick $sha1 $message"
+ while read squash action msg
do
- echo "$pick $sha1 $message"
- while read squash action msg
- do
- case " $used" in
- *" $squash "*)
- continue ;;
- esac
- case "$message" in
- "$msg"*)
- echo "$action $squash $action! $msg"
- used="$used$squash "
- ;;
- esac
- done <"$1.sq"
- done >"$1.rearranged"
- )
+ case "$message" in
+ "$msg"*)
+ echo "$action $squash $action! $msg"
+ used="$used$squash "
+ ;;
+ esac
+ done <"$1.sq"
+ done >"$1.rearranged" <"$1"
cat "$1.rearranged" >"$1"
rm -f "$1.sq" "$1.rearranged"
}
diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh
index f7a0f7a..b63f4e2 100755
--- a/t/t3415-rebase-autosquash.sh
+++ b/t/t3415-rebase-autosquash.sh
@@ -55,4 +55,19 @@ test_expect_success 'auto squash' '
test 2 = $(git cat-file commit HEAD^ | grep first | wc -l)
'
+test_expect_success 'misspelled auto squash' '
+ git reset --hard base &&
+ echo 1 >file1 &&
+ git add -u &&
+ test_tick &&
+ git commit -m "squash! forst"
+ git tag final-missquash &&
+ test_tick &&
+ git rebase --autosquash -i HEAD^^^ &&
+ git log --oneline >actual &&
+ test 4 = $(wc -l <actual) &&
+ git diff --exit-code final-missquash &&
+ test 0 = $(git rev-list final-missquash...HEAD | wc -l)
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH RFC] rebase: add --revisions flag
From: Christian Couder @ 2009-12-09 6:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Stephan Beyer, Christian Couder, Daniel Barkalow,
Git List, Johannes Schindelin
In-Reply-To: <200912090630.28506.chriscool@tuxfamily.org>
On mercredi 09 décembre 2009, Christian Couder wrote:
> Hi,
>
> On mardi 08 décembre 2009, Sverre Rabbelier wrote:
> > Heya,
> >
> > On Tue, Dec 8, 2009 at 21:22, Junio C Hamano <gitster@pobox.com> wrote:
> > > But I think it is a reasonable thing to _implement_ the feature to
> > > range-pick commits reusing the sequencing logic already in "rebase"
> > > and "rebase -i". That essentially is what we wanted to do with "git
> > > sequencer" that would be a sequencing logic backend shared among
> > > rebase, cherry-pick, and perhaps am.
> >
> > Speaking of which, what's the status of git sequencer? I seem to
> > remember some activity recently to slowly rewrite git rebase in c, but
> > I haven't seen anything since then. Is it still moving forward? Is
> > anyone interested in doing so? Just curious...
>
> Last June and July, I sent some patch series to port "rebase -i" to C
> using code from the sequencer project. My goal was to save some
> interesting code from the sequencer GSoC 2008 project and at the same
> time to move forward "rebase -i" code toward a sequencer.
>
> But Dscho and Junio didn't like the fact that the code from the sequencer
> I added was duplicating existing code and was not properly refactored,
> though it also added things that would be needed later for the sequencer.
> My plan was to refactor later, once I had a sequencer, but Junio and
> Dscho did not like that plan. They said it would be a too big maintenance
> burden.
>
> So I agreed to not duplicate any existing code and to properly refactor
> everything. And I have been trying to take interesting and useful code
> from the sequencer project and to integrate it into existing commands.
> And this is why I sent yesterday the 4th version of my '"git reset
> --merge" related improvements' patch series.
After that I plan to work on cherry-pick and that could be useful to
implement something like "git cherry-pick A..B".
See patch 11/15 from Stephan Beyer in my last "port rebase -i to C" series:
http://thread.gmane.org/gmane.comp.version-control.git/127256/focus=127259
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH v2 1/3] refactor ref status logic for pushing
From: Daniel Barkalow @ 2009-12-09 7:13 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Clemens Buchacher,
Jeff King, Junio C Hamano
In-Reply-To: <be6fef0d0912081940p63628d5eoab93a1a1f2676baa@mail.gmail.com>
On Wed, 9 Dec 2009, Tay Ray Chuan wrote:
> Hi,
>
> On Wed, Dec 9, 2009 at 1:17 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > On Tue, 8 Dec 2009, Tay Ray Chuan wrote:
> >
> >> Move the logic that detects up-to-date and non-fast-forward refs to a
> >> new function in remote.[ch], set_ref_status_for_push().
> >
> > Is there some reason to not have set_ref_status_for_push() be static in
> > transport.c now? (Sorry for not suggesting this before.)
>
> it can't be static, because builtin-send-pack.c::main() needs it too.
Oh, right, fair enough.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: error: git-svn died of signal 13
From: Jonathan Nieder @ 2009-12-09 7:53 UTC (permalink / raw)
To: Frederik Hohlfeld, Adam Borowski, David Förster; +Cc: Eric Wong, git
In-Reply-To: <20091209055824.GA22941@dcvr.yhbt.net>
CCing those who reported the problem. There is some debugging advice below,
for anyone who wants to take a further stab at tracking this down.
Eric Wong wrote:
> Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Just wanted to pass on a few reports about git-svn dying with SIGPIPE
>> when trying to fetch large repositories. It seems to fetch a few
>> revisions, then die; the repositories can eventually be fetched
>> successfully by restarting 'git svn fetch' again and again.
>>
>> Some bug reporters have been very patient, but I don’t really know
>> where to look or ask in solving this. Attempts at tracing so far have
>> given either too little or too much information to make any sense.
>>
>> The problem goes back at least to v1.5.6.5.
>
> Hi Jonathan,
>
> Thanks for taking the time to look into this. This has been a
> problem for a long time and very difficult to track down.
>
> One factor is that git svn continues happily afterwards so it's hard to
> reproduce and there's less incentive to look for a fix.
>
>> At the end of the git-svn process’s life, the last few function calls
>> are these:
>>
>> - SVN::Ra::Reporter::finish_report and related functions
>> - _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
>> - SVN::Ra::Callbacks::open_tmp_file, called from
>> SVN::_Ra::svn_ra_do_update, called from
>> Git::SVN::Ra::do_update, called from
>> Git::SVN::Ra::gs_do_update
>> - Git::SVN::_set_repos_root
>> - starting a 'git update-index -z --index-info' to feed commands to
>>
>> Maybe /tmp is filling up? It is hard to know, since the SIGPIPE stops
>> everything and we do not get any nice, simple error message describing
>> what read or write would have received EPIPE.
>>
>> See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
>> <http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
>>
>> Any insights?
>
> Can somebody get an strace or core dump for the "git update-index"
> call? Or even an strace -f of the entire git svn invocation as well...
^ permalink raw reply
* Re: help: bisect single file from repos
From: Nanako Shiraishi @ 2009-12-09 8:27 UTC (permalink / raw)
To: szeder; +Cc: Junio C Hamano, git, Christian Couder, Michael J Gruber, wharms
In-Reply-To: <20091209012855.GA3208@neumann>
Quoting SZEDER Gábor <szeder@ira.uka.de>
> [1] - 'git cherry-pick' doc says the following:
>
> <commit>
> Commit to cherry-pick. For a more complete list of ways to spell
> commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
>
> What? "A _more_ complete list"!? Well, it's not very hard to be more
> complete than this, there is not a single way described here (;
I agree that "more" shouldn't be in that sentence, and I understand your hesitation to read plumbing manual pages, but I don't think it is a sane solution to the issue to repeat how to name a commit in manual pages for every single command to bloat the two line description you quoted into a half-page paragraph. Even within that two lines, the real information that should be in the manual for cherry-pick is only three words "Commit to cherry-pick" and the rest is to help people who don't know.
Maybe it is a better idea to rewrite this to "See 'basic concepts' manual for how to specify a commit", and create a new 'basic concepts' manual that describes these things the readers must know to effectively use the main part of the manual. And make sure that we try very hard to keep the 'basic concepts' manual short, by eg. making a goal to keep it less than N printed pages.
To decide the value of 'N', somebody needs to first think and list the topics that need to be covered by 'basic concepts'. Something like this?
* What are committed states, the state in the index and the state in the working tree.
* How to name a commit.
* How to name a range of commit (move part from the rev-parse manual).
* How to specify options, revisions and files on command line (move part from the gitcli manual).
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* rerere failed to parse conflict hunks
From: Uwe Kleine-König @ 2009-12-09 8:46 UTC (permalink / raw)
To: git
Hello,
I just tried to merge linux-next
(5c1af82119f11c5b322156b09d38cc37318849c4) into my private tree
(based on 2b876f95d03e226394b5d360c86127cbefaf614b) and this
happened:
...
Removing sound/soc/au1x/sample-ac97.c
Recorded preimage for 'arch/Kconfig'
Recorded preimage for 'arch/arm/mach-s3c2440/mach-anubis.c'
Recorded preimage for 'arch/arm/plat-mxc/Makefile'
error: Could not parse conflict hunks in arch/arm/plat-s3c/dev-hsmmc2.c
Recorded preimage for 'arch/arm/plat-s3c/include/plat/sdhci.h'
Recorded preimage for 'arch/arm/plat-samsung/Kconfig'
Recorded preimage for 'arch/x86/include/asm/x86_init.h'
Recorded preimage for 'arch/x86/kernel/x86_init.c'
Recorded preimage for 'drivers/net/wireless/ray_cs.c'
Recorded preimage for 'kernel/Makefile'
Recorded preimage for 'kernel/power/hibernate.c'
Recorded preimage for 'net/sctp/sysctl.c'
Automatic merge failed; fix conflicts and then commit the result.
If you are interested, I can provide you the two trees above. When
reproducing the line "error: ..." came later, but is still present.
I guess this should be reproduceable with
git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git checkout 2b876f95d03e226394b5d360c86127cbefaf614b
git merge 5c1af82119f11c5b322156b09d38cc37318849c4
I havn't tried though.
The only non-trivial conflict is:
#include <plat/sdhci.h>
#include <plat/devs.h>
<<<<<<< HEAD
=======
<<<<<<< HEAD
#include <plat/cpu.h>
=======
>>>>>>> next-s5pc1xx
>>>>>>> next/master
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Peter Krefting @ 2009-12-09 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
In-Reply-To: <7vfx7lcj18.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Many people wanted to have "pick many commits onto the current HEAD" and I
> think it would be a natural, uncontroversial and welcome addition to allow
> "git cherry-pick A..B".
Or even "git cherry-pick branch", as I naïvely tried doing before I
understood what it did. This is definitely a feature that would help me.
The question of where it goes is actually a bit difficult, it is the same
mode of operation as "git rebase", only the other way around. It is the same
as "git cherry-pick", but called multiple times. And it is the same as "git
merge --squash", but without squashing the commits into one.
So does this new mode go into rebase, cherry-pick or merge, or into all
three? No matter which, proper documentation is needed.
Maybe this could also be used to implement a "git merge --squash A..B", a.k.a
a "partial merge". (And if it could be implemented to allow a "git merge A..B"
and later do a "git merge B" to merge the rest of the side-branch, that
would be interesting).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [REROLL PATCH 3/8] Pass unknown protocols to external protocol handlers
From: Bert Wesarg @ 2009-12-09 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, git
In-Reply-To: <7vskbl59ai.fsf@alter.siamese.dyndns.org>
On Wed, Dec 9, 2009 at 00:35, Junio C Hamano <gitster@pobox.com> wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>> + } else if (!is_url(url)
>> + || !prefixcmp(url, "file://")
>> + || !prefixcmp(url, "git://")
>> + || !prefixcmp(url, "ssh://")
>> + || !prefixcmp(url, "git+ssh://")
>> + || !prefixcmp(url, "ssh+git://")) {
>> + /* These are builtin smart transports. */
>
> Hmm, what is !is_url(url) at the beginning for, if this lists "builtin"
> smart transports?
I think/hope this should catch theses use cases:
? [user@]host.xz:/path/to/repo.git/
? [user@]host.xz:~user/path/to/repo.git/
? [user@]host.xz:path/to/repo.git
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox