* Re: [PATCH] gitk: Update and fix Makefile
From: Paul Mackerras @ 2008-01-09 3:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Stimming, git
In-Reply-To: <7vk5mkq669.fsf@gitster.siamese.dyndns.org>
Junio C Hamano writes:
> I see somwhat funny spacing there. I'd suggest giving up
> aligning with spaces and consistently saying "var ?= val"
> instead.
I made those lines all have one space before and after the ?=, and
committed Christian's patches (plus one from Gerrit Pape), and pushed
it out. Please do a pull.
Paul.
^ permalink raw reply
* [PATCH] additional help when editing during interactive rebase
From: William Morgan @ 2008-01-09 3:29 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <7vsl17pv1c.fsf@gitster.siamese.dyndns.org>
Let the user know how to continue a rebase after amending a commit
during a git rebase --interactive session.
Signed-off-by: William Morgan <wmorgan@masanjin.net>
---
git-rebase--interactive.sh | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index acdcc54..ccef1ac 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -258,11 +258,10 @@ do_next () {
die_with_patch $sha1 "Could not apply $sha1... $rest"
make_patch $sha1
: > "$DOTEST"/amend
- warn
warn "You can amend the commit now, with"
- warn
warn " git commit --amend"
- warn
+ warn "Once amended, continue with"
+ warn " git rebase --continue"
exit 0
;;
squash|s)
--
1.5.4.rc2.69.g10f0
--
William <wmorgan-git@masanjin.net>
^ permalink raw reply related
* Sending a patch using git-send-email
From: Imran M Yousuf @ 2008-01-09 3:29 UTC (permalink / raw)
To: git
Hi All,
I am using
git-send-email --to imyousuf@gmail.com --cc
imran.yousuf@smartitengineering.com --from imyousuf@gmail.com
~/Desktop/0001-Signed-off-by-Imran-M-Yousuf-imran-smartitengineer.patch
to send a patch, now if I use --subject "test subject" --compose I get
2 emails one with subject "test subject" and body I gave in the
composer and another with patch subject and the patch as body. Is
there a way to combine them?
git-send-email --to imyousuf@gmail.com --subject "Simplified action
invocation in git submodule" --from imyousuf@gmail.com --compose
~/Desktop/0001-Signed-off-by-Imran-M-Yousuf-imran-smartitengineer.patch
was the command I was using for subject and compose.
I would be grateful if you would be kind enough to help me as I have
several patches pending to be sent for this.
Thank you & Best regards,
--
Imran M Yousuf
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Imran M Yousuf @ 2008-01-09 3:12 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30801080858h5f109b47v87abc6b315fcfa08@mail.gmail.com>
Hi Paolo,
I just setup GMail with git-send-email using
http://git.or.cz/gitwiki/GitTips#head-a015948617d9becbdc9836776f96ad244ba87cb8.
Just add port 587 below the host and it should work fine. In the
username it should some.user.name@gmail.com.
Best regards,
Imran
On Jan 8, 2008 10:58 PM, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> Hi all,
> as I previously wrote I would like to use git-send-email to send out a series
> of patches.
> While I was looking for documentation I saw the following statement in the
> git wiki:
>
> " Mailing off a set of patches to a mailing list can be quite neatly
> done by git-send-email.
> One of the problems you may encounter there is figuring out which machine
> is going to send your mail.
> I tried smtp.gmail.com, but that one requires tls and a password,
> and git-send-email could not handle that "
>
> From http://git.or.cz/gitwiki/GitTips.
>
> Is this statemant still correct ?
> Is msmtp the only solution for using git-send-mail with gmail? (tls +
> autentication).
>
> Thanks.
>
> regards,
> --
> Paolo
> http://paolo.ciarrocchi.googlepages.com/
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
^ permalink raw reply
* [ANNOUNCE] Push Me Pull You 0.1 - Preview Release
From: Mark Williamson @ 2008-01-09 2:28 UTC (permalink / raw)
To: git
Hi all,
For some time I have been working on a GUI for DVCS systems, which I have
named Push Me Pull You (PMPU). At its core is a GUI for viewing Incoming /
Outgoing changesets. It also includes support for initiating pulls / pushes,
doing clones, etc. Eventually I hope to provide access to much more
functionality.
My "native" DVCS is Mercurial and I'm rather new to git's way of doing things,
although it is similar in many respects. PMPU is intended to support
multiple DVCS systems; currently it supports hg, bzr and git. The level of
support and testing for these backends varies, however my eventual goal is to
have complete and robust support for all of them (and probably others).
This is just a quick heads-up that I've tagged a 0.1 release and that the code
may be worth looking at / playing with for some of you.
Please note that error handling is non-existant and that many usecases (e.g.
nested repositories) haven't been tested. The git backend is currently
fairly lightly tested. It seems to work OK for me, just please be CAUTIOUS
when playing with it.
The hg repository is here:
http://xenbits.xensource.com/maw/pmpu.hg
And the homepage (including a tarball of the release) is here:
http://www.cl.cam.ac.uk/~maw48/pmpu/
I would love to hear any feedback, suggestions, bug reports, etc. Please cc
any mailing list e-mails to me, as I am not subscribed. You're all welcome
to contact me directly if preferred.
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
^ permalink raw reply
* Re: [PATCH] additional help when editing during interactive rebase
From: Junio C Hamano @ 2008-01-09 2:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, William Morgan
In-Reply-To: <1199845915-sup-797@south>
William Morgan <wmorgan-git@masanjin.net> writes:
> I personally would have found this message useful the first time I used
> git rebase --interactive. YMMV.
Aside from this message being inappropriate as a proposed commit
log message, I think what the patch tries to achieve is a worthy
UI improvement.
I would have removed those empty lines around the instruction if
I were patching this, though. Losing 5 lines out of 25-line
terminal was marginally Ok. Losing 9 lines 4 lines too many and
is unacceptable.
Thoughts?
> Signed-off-by: William Morgan <wmorgan-git@masanjin.net>
> ---
> git-rebase--interactive.sh | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index acdcc54..d53d283 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -263,6 +263,10 @@ do_next () {
> warn
> warn " git commit --amend"
> warn
> + warn "Once amended, continue with"
> + warn
> + warn " git rebase --continue"
> + warn
> exit 0
> ;;
> squash|s)
> --
> 1.5.4.rc2.68.ge708a-dirty
>
>
> --
> William <wmorgan-git@masanjin.net>
^ permalink raw reply
* [PATCH] additional help when editing during interactive rebase
From: William Morgan @ 2008-01-09 2:32 UTC (permalink / raw)
To: git
I personally would have found this message useful the first time I used
git rebase --interactive. YMMV.
Signed-off-by: William Morgan <wmorgan-git@masanjin.net>
---
git-rebase--interactive.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index acdcc54..d53d283 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -263,6 +263,10 @@ do_next () {
warn
warn " git commit --amend"
warn
+ warn "Once amended, continue with"
+ warn
+ warn " git rebase --continue"
+ warn
exit 0
;;
squash|s)
--
1.5.4.rc2.68.ge708a-dirty
--
William <wmorgan-git@masanjin.net>
^ permalink raw reply related
* Re: [PATCH] git-submodule: New subcommand 'summary'
From: Imran M Yousuf @ 2008-01-09 2:25 UTC (permalink / raw)
To: Ping Yin; +Cc: git
In-Reply-To: <46dff0320801080420v6295939aw86a6cba3ceb8c076@mail.gmail.com>
Hi Ping,
Though I am not a expert on this myself but from my recent experience
from patches I would request you to have a look at
Documentation/Submitting patches.
http://repo.or.cz/w/git.git?a=blob;f=Documentation/SubmittingPatches;hb=HEAD
Best regards,
Imran
On Jan 8, 2008 6:20 PM, Ping Yin <pkufranky@gmail.com> wrote:
> Any comment to my patch?
>
> Following this i will give patches to introduce submodule summary
> function into git-commit
>
>
> On Jan 1, 2008 1:35 AM, Ping Yin <pkufranky@gmail.com> wrote:
> > The patch series ( 3 in total) teach git-submodule a new subcommand 'summary'.
> >
> > PATCH 1 introduces the code framework.
> >
> > PATCH 2 does the real work for summary.
> >
> > PATCH 3 teaches a new option '--summary-limit|-n'.
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe git" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
>
> --
> Ping Yin
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Mobile: +880-1711402557
^ permalink raw reply
* Re: [PATCH] Add [HOWTO] using merge subtree.
From: Junio C Hamano @ 2008-01-09 1:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Sean, git
In-Reply-To: <1199838182-15178-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
NAK. It may be well intentioned, but it lacks too much context
to be usable as a generic teaching material.
> +Abstract: In this article, Sean demonstrates how one can use the subtree merge
> + strategy.
> +Message-ID: <BAYC1-PASMTP12374B54BA370A1E1C6E78AE4E0@CEZ.ICE>
> +
> +How to use the subtree merge strategy
> +=====================================
Here, before diving to the actual command sequence, you need to
tell the reader what the objective of the whole exercise is.
What's /path/to/B and how its contents relate to the contents of
the current repository? How was that other repository prepared?
What's the ultimate goal, IOW, what overlayed tree layout are
you trying to create? Why do you want to have that overlayed
layout?
When you heard it on the mailing list you may have had enough
background material from the discussion thread. Your readers
won't have that.
> +----
> +$ git remote add -f B /path/to/B <1>
> +$ git merge -s ours --no-commit B/master <2>
> +$ git read-tree --prefix=B/ -u B/master <3>
> +$ git commit -m "Merge commit 'B/master'" <4>
> +----
> +<1> creates and fetches the remote.
> +<2> initiates a merge, but stops before committing it.
> +<3> reads B/master into the subdirectory "sub".
> +<4> all that remains is committing the completed merge.
> +
> +You only need this procedure for the first commit, after which `git merge -s
> +subtree B/master` is all you need.
Complaints for an overly long line aside, after that
description, having another code example block to illustrate the
exact command line would be more consistent with the above
display. Alternatively, make it <5> and annotate that entry
with "You only need the above four steps once, after that you
can keep doing 'git pull -s subtree B master'".
^ permalink raw reply
* Re: [EGIT PATCH] Showing abbreviated commit hash of the versions in Compare editor.
From: Roger C. Soares @ 2008-01-09 1:33 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
In-Reply-To: <200801082312.00329.robin.rosenberg.lists@dewire.com>
Robin Rosenberg escreveu:
> I'm implementing fetch (with some help from Shawn). Progress in
> place. I still need to update refs and get in consistent with native
> git behaviour.
>
> I'm also updating the javadocs.
Cool.
I use a lot the eclipse feature that highlights all occurences of a
variable or method but with all the warnings in the project it is
difficult to visually find these occurences. So I'm anxious to remove a
lot of warnings. Public methods without documentation are one of them.
Is it ok if I send you a patch removing all the warnings I know how but
the ones about public methods needing documentation as you're already
documenting them? I also want to remove the auto generated TODOs, as
they don't actually say what to do, like this one:
// TODO Auto-generated catch block
[]s,
Roger.
^ permalink raw reply
* Re: [EGIT PATCH] Showing commit info like the CVS plugin instead of tooltips.
From: Roger C. Soares @ 2008-01-09 1:17 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
In-Reply-To: <200801082320.52548.robin.rosenberg.lists@dewire.com>
Hi Robin,
> Looks nice. We probably want this into preferences and I'd still like the tooltop as an option. I.e. when you turn off
> the other panes the tooltip should come back. What I'd really want is the "Press F2"-version, like the javadoc
> tooltips, but that requires some more work (I guess, maybe only a little is needed).
>
Showing the tooltips when you press F2 makes more sense to me. What I'm
confortable to do now is to add another option in the history menu
(after show revision comment) to show the tooltips. I can send a new
patch with this.
For the search bar, I would like to make it visible by pressing ctrl-f
when the history panel has the focus. So if I learn how to do it I can
also do the F2 for the tooltips (low priority though).
>> + /* private */TextViewer revDetailTextViewer;
>> + /* private */TextViewer revCommentTextViewer;
>> + /* private */IAction toggleCommentWrapAction;
>> + /* private */IAction toggleRevDetailAction;
>> + /* private */IAction toggleRevCommentAction;
>>
>> - private Table table;
>> + /* private */Table table;
>>
>> - private List<IFileRevision> fileRevisions;
>> + /* private */List<IFileRevision> fileRevisions;
>>
>> - protected boolean hintShowDiffNow;
>> + /* private */boolean hintShowDiffNow;
>>
> Why? What's wrong plain private?
>
This is to improve performance and getting rid of the warning:
Read access to enclosing field GitHistoryPage.appliedPatches is emulated
by a synthetic accessor method. Increasing its visibility will improve
your performance
[]s,
Roger.
^ permalink raw reply
* Re: git svn fetch segfaults
From: Miklos Vajna @ 2008-01-09 0:33 UTC (permalink / raw)
To: Dennis Schridde; +Cc: git
In-Reply-To: <200801082325.45756.devurandom@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
On Tue, Jan 08, 2008 at 11:25:45PM +0100, Dennis Schridde <devurandom@gmx.net> wrote:
> mkdir org.gna.warzone2100.git
> cd org.gna.warzone2100.git
> git --bare init
> git --bare svn init --use-svnsync-props --stdlayout
> file:///var/svn/warzone2100/
> git --bare svn fetch
wget http://svn.kynes.de/warzone2100.bz2
svnadmin create warzone2100 && bzcat warzone2100.bz2 | svnadmin load warzone2100
the rest is the same i get a segfault at the very same place.
> If I do not specify --use-svnsync-prop to "git svn init", it gets past r13 in
> tags/1.10a.
same.
> I am using these versions:
> svn, version 1.4.6 (r28521)
> git version 1.5.4.rc2
$ svn --version
svn, version 1.4.5 (r25188)
$ git --version
git version 1.5.4.rc2.38.gd6da3
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-09 0:01 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Steffen Prohaska, Junio C Hamano, J. Bruce Fields,
Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysGit
In-Reply-To: <20080108225138.GA23240-EQL4cN526mwi5CQI31g/s0B+6BGkLq7r@public.gmane.org>
On Wed, 9 Jan 2008, Dmitry Potapov wrote:
>
> It seems the check for named LF should be:
> if (safecrlf && stats.lf == stats.crlf)
No. If there was a crlf, then we won't increment the lf count.
(Not that I tested it, but that's how it was supposed to work)
Linus
^ permalink raw reply
* [PATCH 2/2] core.whitespace cr-at-eol-is-ok
From: Junio C Hamano @ 2008-01-08 23:51 UTC (permalink / raw)
To: git
This allows a line to have a carriage return at the end when
checking and fixing trailing whitespaces.
I think the previous one to fix the message from --check is a
1.5.4 material, but this certainly is not. The naming of the
rule is iffy at best and the semantics when enabling all error
checks via attributes by setting whitespace attribute to true
should not include this option.
I haven't tested this very seriously other than adding just a
few tests to an existing test script.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-apply.c | 21 +++++++++++++++------
cache.h | 1 +
t/t4019-diff-wserror.sh | 40 ++++++++++++++++++++++++++++++++++++++++
ws.c | 15 +++++++++++++--
4 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index d57bb6e..dcd9f09 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1549,6 +1549,7 @@ static int apply_line(char *output, const char *patch, int plen,
*/
int i;
int add_nl_to_tail = 0;
+ int add_cr_to_tail = 0;
int fixed = 0;
int last_tab_in_indent = 0;
int last_space_in_indent = 0;
@@ -1564,14 +1565,20 @@ static int apply_line(char *output, const char *patch, int plen,
/*
* Strip trailing whitespace
*/
- if ((ws_rule & WS_TRAILING_SPACE) &&
- (1 < plen && isspace(patch[plen-1]))) {
- if (patch[plen] == '\n')
+ if ((ws_rule & WS_TRAILING_SPACE)) {
+ if (patch[plen] == '\n') {
add_nl_to_tail = 1;
- plen--;
- while (0 < plen && isspace(patch[plen]))
plen--;
- fixed = 1;
+ if (1 < plen && patch[plen - 1] == '\r') {
+ add_cr_to_tail = 1;
+ plen--;
+ }
+ }
+ if (isspace(patch[plen])) {
+ while (0 < plen && isspace(patch[plen]))
+ plen--;
+ fixed = 1;
+ }
}
/*
@@ -1633,6 +1640,8 @@ static int apply_line(char *output, const char *patch, int plen,
i = 1;
memcpy(output, patch + i, plen);
+ if (add_cr_to_tail)
+ output[plen++] = '\r';
if (add_nl_to_tail)
output[plen++] = '\n';
if (fixed)
diff --git a/cache.h b/cache.h
index 39331c2..3836176 100644
--- a/cache.h
+++ b/cache.h
@@ -651,6 +651,7 @@ void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, i
#define WS_TRAILING_SPACE 01
#define WS_SPACE_BEFORE_TAB 02
#define WS_INDENT_WITH_NON_TAB 04
+#define WS_CR_AT_EOL_IS_OK 010
#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
extern unsigned whitespace_rule_cfg;
extern unsigned whitespace_rule(const char *);
diff --git a/t/t4019-diff-wserror.sh b/t/t4019-diff-wserror.sh
index 67e080b..429d870 100755
--- a/t/t4019-diff-wserror.sh
+++ b/t/t4019-diff-wserror.sh
@@ -12,6 +12,7 @@ test_expect_success setup '
echo " Eight SP indent" >>F &&
echo " HT and SP indent" >>F &&
echo "With trailing SP " >>F &&
+ echo "Carriage ReturnQ" | tr Q "\015" >>F &&
echo "No problem" >>F
'
@@ -27,6 +28,7 @@ test_expect_success default '
grep Eight normal >/dev/null &&
grep HT error >/dev/null &&
grep With error >/dev/null &&
+ grep Return error >/dev/null &&
grep No normal >/dev/null
'
@@ -41,6 +43,7 @@ test_expect_success 'without -trail' '
grep Eight normal >/dev/null &&
grep HT error >/dev/null &&
grep With normal >/dev/null &&
+ grep Return normal >/dev/null &&
grep No normal >/dev/null
'
@@ -56,6 +59,7 @@ test_expect_success 'without -trail (attribute)' '
grep Eight normal >/dev/null &&
grep HT error >/dev/null &&
grep With normal >/dev/null &&
+ grep Return normal >/dev/null &&
grep No normal >/dev/null
'
@@ -70,6 +74,7 @@ test_expect_success 'without -space' '
grep Eight normal >/dev/null &&
grep HT normal >/dev/null &&
+ grep Return error >/dev/null &&
grep With error >/dev/null &&
grep No normal >/dev/null
@@ -85,6 +90,7 @@ test_expect_success 'without -space (attribute)' '
grep Eight normal >/dev/null &&
grep HT normal >/dev/null &&
+ grep Return error >/dev/null &&
grep With error >/dev/null &&
grep No normal >/dev/null
@@ -100,6 +106,7 @@ test_expect_success 'with indent-non-tab only' '
grep Eight error >/dev/null &&
grep HT normal >/dev/null &&
+ grep Return normal >/dev/null &&
grep With normal >/dev/null &&
grep No normal >/dev/null
@@ -115,9 +122,42 @@ test_expect_success 'with indent-non-tab only (attribute)' '
grep Eight error >/dev/null &&
grep HT normal >/dev/null &&
+ grep Return normal >/dev/null &&
grep With normal >/dev/null &&
grep No normal >/dev/null
'
+test_expect_success 'with cr-at-eol-is-ok' '
+
+ rm -f .gitattributes
+ git config core.whitespace cr-at-eol-is-ok
+ git diff --color >output
+ grep "$blue_grep" output >error
+ grep -v "$blue_grep" output >normal
+
+ grep Eight normal >/dev/null &&
+ grep HT error >/dev/null &&
+ grep With error >/dev/null &&
+ grep Return normal >/dev/null &&
+ grep No normal >/dev/null
+
+'
+
+test_expect_success 'with cr-at-eol-is-ok (attribute)' '
+
+ git config --unset core.whitespace
+ echo "F whitespace=trailing,cr-at-eol-is-ok" >.gitattributes
+ git diff --color >output
+ grep "$blue_grep" output >error
+ grep -v "$blue_grep" output >normal
+
+ grep Eight normal >/dev/null &&
+ grep HT error >/dev/null &&
+ grep With error >/dev/null &&
+ grep Return normal >/dev/null &&
+ grep No normal >/dev/null
+
+'
+
test_done
diff --git a/ws.c b/ws.c
index d09b9df..805be56 100644
--- a/ws.c
+++ b/ws.c
@@ -14,6 +14,7 @@ static struct whitespace_rule {
{ "trailing-space", WS_TRAILING_SPACE },
{ "space-before-tab", WS_SPACE_BEFORE_TAB },
{ "indent-with-non-tab", WS_INDENT_WITH_NON_TAB },
+ { "cr-at-eol-is-ok", WS_CR_AT_EOL_IS_OK },
};
unsigned parse_whitespace_rule(const char *string)
@@ -124,6 +125,7 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
int written = 0;
int trailing_whitespace = -1;
int trailing_newline = 0;
+ int trailing_carriage_return = 0;
int i;
/* Logic is simpler if we temporarily ignore the trailing newline. */
@@ -131,6 +133,11 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
trailing_newline = 1;
len--;
}
+ if ((ws_rule & WS_CR_AT_EOL_IS_OK) &&
+ len > 0 && line[len - 1] == '\r') {
+ trailing_carriage_return = 1;
+ len--;
+ }
/* Check for trailing whitespace. */
if (ws_rule & WS_TRAILING_SPACE) {
@@ -176,8 +183,10 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
}
if (stream) {
- /* Now the rest of the line starts at written.
- * The non-highlighted part ends at trailing_whitespace. */
+ /*
+ * Now the rest of the line starts at "written".
+ * The non-highlighted part ends at "trailing_whitespace".
+ */
if (trailing_whitespace == -1)
trailing_whitespace = len;
@@ -196,6 +205,8 @@ unsigned check_and_emit_line(const char *line, int len, unsigned ws_rule,
len - trailing_whitespace, 1, stream);
fputs(reset, stream);
}
+ if (trailing_carriage_return)
+ fputc('\r', stream);
if (trailing_newline)
fputc('\n', stream);
}
^ permalink raw reply related
* [PATCH 1/2] "git-apply --check" should not report "fixed"
From: Junio C Hamano @ 2008-01-08 23:46 UTC (permalink / raw)
To: git
When running "git apply --check" while --whitespace=fix is
enabled (either from the command line or via the configuration),
we reported that "N line(s) applied after _fixing_", but --check
by itself does not apply and this message was alarming.
We could even reword the message to say "N line(s) would have
been applied after fixing...", but this patch does not go that
far. Instead, we just make it use the "N lines add whitespace
errors" warning, which happens to be a good diagnostic message a
user would expect from the --check option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 5e3b4a1..d57bb6e 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2907,7 +2907,7 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
whitespace_error,
whitespace_error == 1 ? "" : "s",
whitespace_error == 1 ? "s" : "");
- if (applied_after_fixing_ws)
+ if (applied_after_fixing_ws && apply)
fprintf(stderr, "warning: %d line%s applied after"
" fixing whitespace errors.\n",
applied_after_fixing_ws,
^ permalink raw reply related
* Re: [PATCH] gitk: fix "Key bindings" message
From: Paul Mackerras @ 2008-01-08 23:36 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200801081437.46398.barra_cuda@katamail.com>
Michele Ballabio writes:
> -"] \
> +" $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T $M1T ] \
Ick. Are you sure you have the right number of instances of $M1T? :)
I'd prefer to use [string map].
Actually, for translation, it would probably be better to bust up that
help text into a series of shorter strings, maybe even one per line.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Update and fix Makefile
From: Junio C Hamano @ 2008-01-08 22:54 UTC (permalink / raw)
To: Christian Stimming; +Cc: Paul Mackerras, git
In-Reply-To: <200801082154.21282.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> writes:
> -# From here on, these are needed in git.git/gitk/Makefile.
> +prefix ?= $(HOME)
> +bindir ?= $(prefix)/bin
> +sharedir ?= $(prefix)/share
> gitk_libdir ?= $(sharedir)/gitk/lib
> msgsdir ?= $(gitk_libdir)/msgs
> msgsdir_SQ = $(subst ','\'',$(msgsdir))
I see somwhat funny spacing there. I'd suggest giving up
aligning with spaces and consistently saying "var ?= val"
instead.
I am reading the diff between the gitk-git/Makefile
before and after merging gitk with your patch and
the last three lines above are not context but additions
from my point of view.
> +install:: all
> + $(INSTALL) gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
> + $(INSTALL) -d '$(DESTDIR_SQ)$(msgsdir_SQ)'
> + $(foreach p,$(ALL_MSGFILES), $(INSTALL) $p '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
This is cute and correct (except I would have spelled "true" as
":" myself). I think we need to fix a few such constructs that
use ";" instead of "&&" in Makefile in git.git.
> +uninstall::
> + $(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
> + $(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
I have a mild dislike against uninstall target, but that's
Paul's call.
> +clean::
> + $(RM) gitk-wish po/*.msg
And this makes me wonder if the last token should be $(ALL_MSGFILES).
Other than that, Ack from me.
Thanks.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-08 22:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steffen Prohaska, Junio C Hamano, J. Bruce Fields,
Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysGit
In-Reply-To: <alpine.LFD.1.00.0801081325010.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
On Tue, Jan 08, 2008 at 01:31:57PM -0800, Linus Torvalds wrote:
>
> but we don't check that there are no "naked" LF characters.
But my idea was about checking for "naked" LF, because if there is at
least one naked LF, then you will get a _different_ file than you
put into the repository.
>
> So the only thing you'd need to add is to add a
>
> /* No naked LF's! */
> if (safecrlf && stats.lf)
It seems the check for named LF should be:
if (safecrlf && stats.lf == stats.crlf)
> return 0;
Unfortunately, you cannot return 0 here, because if there is
no CRLF, the opposite conversation cannot tell apart when all
CRLF were successfully converted to LF, and when there was no
conversation at all. So, the only thing to do here is to die()
saying this file should be either marked as binary or EOL in
the text must be corrected.
>
> to that sequence too, but the thing is, having mixed line-endings isn't
> actually all that unusual, so I think that kind of "autocrlf=safe" thing
> is actually almost useless - because when that thing triggers, you almost
> always *do* want to convert it to be just one way.
I agree that in most cases, you *do* want to covert, but the idea of the
"safe" mode is to protect you from the possibility (whatever small it
is) when you do not want to convert, because it is a _binary_ file, but
is_binary heuristic was wrong.
> I've seen it multiple times when people cooperate with windows files with
> unix tools, where unix editors often preserve old CRLF's, but write new
> lines with just LF.
>
> So "autocrlf=safe" would be trivial to add, but I suspect it would cause
> more confusion than it would fix.
The idea of "autocrlf=safe" is always to be on the safe side. Those who
prefer automatic correction of EOL can use "autocrlf=true". Besides,
checking EOL is somewhat similar checking whitespaces. Git allows you
either have --whitespace=error or --whitespace=strip, so it is reasonable
to have the same choice about EOL. I may choose either the "safe" mode,
which will only error out, or I can have the "true" mode, which corrects
EOLs on-fly.
Dmitry
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Peter Karlsson @ 2008-01-08 21:26 UTC (permalink / raw)
To: Git Mailing List
Cc: Robin Rosenberg, Johannes Schindelin, Jeff King, Steffen Prohaska,
Linus Torvalds
In-Reply-To: <alpine.LFD.1.00.0801071332530.3148@woody.linux-foundation.org>
Linus Torvalds:
> So defaulting to (or asking) "autocrlf" at install time is probably the
> safest thing, and then people can edit their global .gitconfig to turn it
> off.
Indeed. A checkbox in the Windows installer (like Cygwin has) would be nice.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* git svn fetch segfaults
From: Dennis Schridde @ 2008-01-08 22:25 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 915 bytes --]
Hello!
The following procedure results in a segfault:
mkdir org.gna.warzone2100.git
cd org.gna.warzone2100.git
git --bare init
git --bare svn init --use-svnsync-props --stdlayout
file:///var/svn/warzone2100/
git --bare svn fetch
A full log is attached.
If you want any more information, a dump of the SVN repository, etc, just tell
me.
The last part which seems to be interesting is this one:
Odd number of elements in anonymous hash at /usr/bin/git-svn line 1760.
r13 = 7f00bbc9c92e5601b158c2cbc572b8e7bdcebe59 (tags/1.10a)
Segmentation fault
If I do not specify --use-svnsync-prop to "git svn init", it gets past r13 in
tags/1.10a.
(Note that in the other mail, where I reported about the "Odd number of
elements" problem, I used "git svn clone" instead.)
I am using these versions:
svn, version 1.4.6 (r28521)
git version 1.5.4.rc2
--Dennis
(Please CC me if you answer, since I am not subscribed.)
[-- Attachment #2: svn_fetch_1.log.bz2 --]
[-- Type: application/x-bzip, Size: 10857 bytes --]
^ permalink raw reply
* Re: [EGIT PATCH] Showing commit info like the CVS plugin instead of tooltips.
From: Robin Rosenberg @ 2008-01-08 22:20 UTC (permalink / raw)
To: Roger C. Soares; +Cc: git, Shawn O. Pearce
In-Reply-To: <200801072320.26987.rogersoares@intelinet.com.br>
tisdagen den 8 januari 2008 skrev du:
> Tooltips for the info were annoying, especially on MacOS where the tooltip center is your pointer location.
> It is now possible to copy&paste data.
> Like the CVS plugin, there's a menu to show/hide views. Thought it doesn't save in the preferences store for now.
Looks nice. We probably want this into preferences and I'd still like the tooltop as an option. I.e. when you turn off
the other panes the tooltip should come back. What I'd really want is the "Press F2"-version, like the javadoc
tooltips, but that requires some more work (I guess, maybe only a little is needed).
> + /* private */TextViewer revDetailTextViewer;
> + /* private */TextViewer revCommentTextViewer;
> + /* private */IAction toggleCommentWrapAction;
> + /* private */IAction toggleRevDetailAction;
> + /* private */IAction toggleRevCommentAction;
>
> - private Table table;
> + /* private */Table table;
>
> - private List<IFileRevision> fileRevisions;
> + /* private */List<IFileRevision> fileRevisions;
>
> - protected boolean hintShowDiffNow;
> + /* private */boolean hintShowDiffNow;
Why? What's wrong plain private?
> \ No newline at end of file
There was trailing whitespace also, but I can fix such things easily. I'm erasing those on changed lines only, a
change at the time at the moment instead of big ws fixes. In eclipse 3.3 there is an option to fix trailing spaces
on save on changed lines only.
-- robin
^ permalink raw reply
* Re: [EGIT PATCH] Showing abbreviated commit hash of the versions in Compare editor.
From: Robin Rosenberg @ 2008-01-08 22:12 UTC (permalink / raw)
To: Roger C. Soares; +Cc: git, Shawn O. Pearce
In-Reply-To: <200801072315.30122.rogersoares@intelinet.com.br>
Thanks.
tisdagen den 8 januari 2008 skrev Roger C. Soares:
>
> Signed-off-by: Roger C. Soares <rogersoares@intelinet.com.br>
> ---
> Some more patches, please evaluate.
> Don't know what others are working on,
I'm implementing fetch (with some help from Shawn). Progress in
place. I still need to update refs and get in consistent with native
git behaviour.
I'm also updating the javadocs.
> but right now I'm missing a search functionality so
> this will probably be my next egit little feature.
Sounds good.
-- robin
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Sean @ 2008-01-08 22:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dmitry Potapov, Steffen Prohaska, Junio C Hamano, J. Bruce Fields,
Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysGit
In-Reply-To: <alpine.LFD.1.00.0801081325010.3148-5CScLwifNT1QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>
On Tue, 8 Jan 2008 13:31:57 -0800 (PST)
Linus Torvalds <torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> wrote:
> So the only thing you'd need to add is to add a
>
> /* No naked LF's! */
> if (safecrlf && stats.lf)
> return 0;
>
> to that sequence too, but the thing is, having mixed line-endings isn't
> actually all that unusual, so I think that kind of "autocrlf=safe" thing
> is actually almost useless - because when that thing triggers, you almost
> always *do* want to convert it to be just one way.
>
> I've seen it multiple times when people cooperate with windows files with
> unix tools, where unix editors often preserve old CRLF's, but write new
> lines with just LF.
>
> So "autocrlf=safe" would be trivial to add, but I suspect it would cause
> more confusion than it would fix.
But isn't the entire point of this exercise to ensure that you will never
be in the situation on Linux where you checkout files that have CRLF endings?
And conversely that on Windows you will never checkout files that have LF
endings? If so, you don't have to worry about your tools creating mixed
ending files.
The only time the above rules should be broken, is when the user explicitly
states that their tools will do-the-right-thing without such help.
Sean
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Robin Rosenberg @ 2008-01-08 21:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry Potapov, Steffen Prohaska, J. Bruce Fields,
Johannes Schindelin, Jeff King, Peter Karlsson, Git Mailing List,
msysGit
In-Reply-To: <7vy7b0qarq.fsf@gitster.siamese.dyndns.org>
tisdagen den 8 januari 2008 skrev Junio C Hamano:
> It counts CR and CRLF and converts only when there are the same
> number of them. You probably only need to make it also count
> LF?
Strictly speaking yes, but probably no anyway. Some tools on Windows
keep existing line endings for existing lines but add CRLF for new ones.
I can only think of one right now, but that's at least one.
-- robin
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-08 21:31 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Steffen Prohaska, Junio C Hamano, J. Bruce Fields,
Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysGit
In-Reply-To: <20080108205054.GN6951-EQL4cN526mwi5CQI31g/s0B+6BGkLq7r@public.gmane.org>
On Tue, 8 Jan 2008, Dmitry Potapov wrote:
>
> Perhaps, this option can be called core.autocrlf=safe
We already do half of that:
if (action == CRLF_GUESS) {
/*
* We're currently not going to even try to convert stuff
* that has bare CR characters. Does anybody do that crazy
* stuff?
*/
if (stats.cr != stats.crlf)
return 0;
but we don't check that there are no "naked" LF characters.
So the only thing you'd need to add is to add a
/* No naked LF's! */
if (safecrlf && stats.lf)
return 0;
to that sequence too, but the thing is, having mixed line-endings isn't
actually all that unusual, so I think that kind of "autocrlf=safe" thing
is actually almost useless - because when that thing triggers, you almost
always *do* want to convert it to be just one way.
I've seen it multiple times when people cooperate with windows files with
unix tools, where unix editors often preserve old CRLF's, but write new
lines with just LF.
So "autocrlf=safe" would be trivial to add, but I suspect it would cause
more confusion than it would fix.
Linus
^ 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