* 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
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-08 21:33 UTC (permalink / raw)
To: Peter Harris; +Cc: Peter Karlsson, git
In-Reply-To: <eaa105840801080507j1b748fy6fdff8b240cf8c33@mail.gmail.com>
On Tue, Jan 08, 2008 at 08:07:15AM -0500, Peter Harris wrote:
>
> Actually, Subversion does the Right Thing, and treats everything as a
> binary file until and unless you explicitly set the svn:eol-style
> property on each file that you want it to mangle.
Not exactly. Actually, Subversion detects binary or text file based
on heuristic. http://subversion.tigris.org/faq.html#binary-files
But the status of a file as binary or text has no effect whatsoever
on on CRLF conversation, which is controlled by another property.
By default, most of your text files will be detected as text (unless
you use non-ASCII character like Cyrillic), but they will not have
CRLF conversation. Now, you have to set svn:eol-style=native for
each new file, which of course can be done automatically based on
file extension, but that should be configured by each user in his
or her global config file. Obviously, it does not work well for
cross-platform projects, because many users forget to set
svn:eol-style=native for some extensions. Moreover, the issue tends
to repeat itself for every newly introduced file extension...
IMHO, having the binary or text status completely independent from
CRLF conversation is insanity...
Dmitry
^ permalink raw reply
* Re: git and unicode
From: Robin Rosenberg @ 2008-01-08 20:36 UTC (permalink / raw)
To: Gonzalo Garramuño; +Cc: git
In-Reply-To: <47835A02.80404@advancedsl.com.ar>
UTF-8: no
UTF-16: yes (actually "most likely" yes)
-- robin
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-08 21:15 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Steffen Prohaska, 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>
Dmitry Potapov <dpotapov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:
>>
>> I don't think a solution will be found by declaring one platform
>> native (UNIX) and all other platform non-native. The question to
>> answer is how to support cross-platform projects. A valid
>> solution should never corrupt data unless the user explicitly
>> told git to do so. I don't believe it is a valid solution to set
>> core.autocrlf=true on Windows and tell the users: "Well, in its
>> default settings, git sometimes corrupts your data on Windows.
>> Maybe you want to switch to Linux because this is the native
>> platform where data corruption will never happen."
>
> Maybe I am wrong but it seems to me that to guarantee that
> CRLF conversion is reversible (which means that you can
> always get exactly what you put into the repository), it is
> enough to check that the conversation is performed only if
> every LF is preceded by CR.
I've heard that before but I seem to recall convert.c already
doing something similar if I am not mistaken.
static int crlf_to_git(const char *path, const char *src, size_t len,
struct strbuf *buf, int action)
{
struct text_stat stats;
char *dst;
if ((action == CRLF_BINARY) || !auto_crlf || !len)
return 0;
gather_stats(src, len, &stats);
/* No CR? Nothing to convert, regardless. */
if (!stats.cr)
return 0;
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;
/*
* And add some heuristics for binary vs text, of course...
*/
if (is_binary(len, &stats))
return 0;
}
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?
^ permalink raw reply
* [PATCH] gitk: Update German translation
From: Christian Stimming @ 2008-01-08 20:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 4628 bytes --]
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
@Paul: Ignore my previous patch - this one is even more improved.
Just in case any mailer messes up whitespace or character
encodings, I've also attached that patch and the previous (Makefile)
one as a tarball.
po/de.po | 54 +++++++++++++++++++++++++++---------------------------
1 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/po/de.po b/po/de.po
index 19d048b..d7881dd 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1,14 +1,14 @@
# Translation of gitk to German.
-# Copyright (C) 2007 Paul Mackerras and Christian Stimming.
-# This file is distributed under the same license as the git package.
+# Copyright (C) 2007 Paul Mackerras.
+# This file is distributed under the same license as the gitk package.
# Christian Stimming <stimming@tuhh.de>, 2007
#
msgid ""
msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2007-11-07 12:27+0100\n"
-"PO-Revision-Date: 2007-11-07 12:36+0100\n"
+"POT-Creation-Date: 2007-12-21 12:04+0100\n"
+"PO-Revision-Date: 2008-01-08 21:48+0100\n"
"Last-Translator: Christian Stimming <stimming@tuhh.de>\n"
"Language-Team: German\n"
"MIME-Version: 1.0\n"
@@ -321,11 +321,11 @@ msgstr ""
#: gitk:2883
msgid "Local changes checked in to index but not committed"
-msgstr ""
+msgstr "Lokale Änderungen bereitgestellt, aber nicht eingetragen"
#: gitk:2913
msgid "Local uncommitted changes, not checked in to index"
-msgstr ""
+msgstr "Lokale Änderungen, nicht bereitgestellt"
#: gitk:4264
msgid "Searching"
@@ -496,7 +496,7 @@ msgstr "Zurücksetzen bestätigen"
#: gitk:6357
#, tcl-format
msgid "Reset branch %s to %s?"
-msgstr ""
+msgstr "Zweig »%s« auf »%s« zurücksetzen?"
#: gitk:6361
msgid "Reset type:"
@@ -504,7 +504,7 @@ msgstr "Art des Zurücksetzens:"
#: gitk:6365
msgid "Soft: Leave working tree and index untouched"
-msgstr "Weich: Arbeitskopie und Bereitstellung unverändert"
+msgstr "Harmlos: Arbeitskopie und Bereitstellung unverändert"
#: gitk:6368
msgid "Mixed: Leave working tree untouched, reset index"
@@ -526,11 +526,11 @@ msgstr "Zurücksetzen"
#: gitk:6444
msgid "Checking out"
-msgstr ""
+msgstr "Umstellen"
#: gitk:6474
msgid "Cannot delete the currently checked-out branch"
-msgstr ""
+msgstr "Der Zweig, auf den die Arbeitskopie momentan umgestellt ist, kann nicht gelöscht werden."
#: gitk:6480
#, tcl-format
@@ -580,28 +580,28 @@ msgstr "Gitk Einstellungen"
#: gitk:7960
msgid "Commit list display options"
-msgstr ""
+msgstr "Anzeige Versionsliste"
#: gitk:7964
msgid "Maximum graph width (lines)"
-msgstr ""
+msgstr "Maximale Graphenbreite (Zeilen)"
#: gitk:7968
#, tcl-format
msgid "Maximum graph width (% of pane)"
-msgstr ""
+msgstr "Maximale Graphenbreite (% des Fensters)"
#: gitk:7973
msgid "Show local changes"
-msgstr ""
+msgstr "Lokale Änderungen anzeigen"
#: gitk:7978
msgid "Diff display options"
-msgstr ""
+msgstr "Anzeige Vergleich"
#: gitk:7981
msgid "Tab spacing"
-msgstr ""
+msgstr "Tabulatorbreite"
#: gitk:7985
msgid "Display nearby tags"
@@ -609,11 +609,11 @@ msgstr ""
#: gitk:7990
msgid "Limit diffs to listed paths"
-msgstr ""
+msgstr "Vergleich nur für angezeigte Pfade"
#: gitk:7995
msgid "Colors: press to choose"
-msgstr ""
+msgstr "Farben: Klicken zum Wählen"
#: gitk:7999
msgid "Background"
@@ -625,15 +625,15 @@ msgstr "Hintergrund"
#: gitk:8007
msgid "Diff: old lines"
-msgstr ""
+msgstr "Vergleich: Alte Zeilen"
#: gitk:8012
msgid "Diff: new lines"
-msgstr ""
+msgstr "Vergleich: Neue Zeilen"
#: gitk:8017
msgid "Diff: hunk header"
-msgstr ""
+msgstr "Vergleich: Änderungstitel"
#: gitk:8023
msgid "Select bg"
@@ -641,24 +641,24 @@ msgstr "Hintergrundfarbe Auswählen"
#: gitk:8027
msgid "Fonts: press to choose"
-msgstr ""
+msgstr "Schriftart: Klicken zum Wählen"
#: gitk:8030
msgid "Main font"
-msgstr ""
+msgstr "Programmschriftart"
#: gitk:8031
msgid "Diff display font"
-msgstr ""
+msgstr "Vergleich"
#: gitk:8032
msgid "User interface font"
-msgstr ""
+msgstr "Beschriftungen"
#: gitk:8050
#, tcl-format
msgid "Gitk: choose color for %s"
-msgstr ""
+msgstr "Gitk: Farbe wählen für %s"
#: gitk:8431
msgid ""
@@ -668,7 +668,7 @@ msgstr ""
#: gitk:8516
msgid "Cannot find a git repository here."
-msgstr ""
+msgstr "Kein Git-Projektarchiv gefunden."
#: gitk:8520
#, tcl-format
--
1.5.3.4.206.g58ba4
[-- Attachment #2: gitk-Update-German-translation.tgz --]
[-- Type: application/x-tgz, Size: 2952 bytes --]
^ permalink raw reply related
* [PATCH] gitk: Update and fix Makefile
From: Christian Stimming @ 2008-01-08 20:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
This Makefile uses the template provided at git.git/gitk-git/Makefile
by Junio and adds the rules for the i18n files.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
This patch is against master of git.kernel.org.
@Paul: Ignore my previous patch - "make install" didn't
work there, but it does here.
Makefile | 63 +++++++++++++++++++++++++++++++++++++------------------------
1 files changed, 38 insertions(+), 25 deletions(-)
diff --git a/Makefile b/Makefile
index 38154b6..6158504 100644
--- a/Makefile
+++ b/Makefile
@@ -1,25 +1,52 @@
-# Set the installation directories; this section is needed only in
-# gitk.git but probably not in git.git.
-ifndef gitexecdir
- gitexecdir := $(shell git --exec-path)
-endif
-ifndef sharedir
- sharedir := $(dir $(gitexecdir))share
-endif
+# The default target of this Makefile is...
+all::
-# 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))
-## Beginning of po-file creation rules
+TCLTK_PATH ?= wish
+INSTALL ?= install
+RM ?= rm -f
+
+DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
+bindir_SQ = $(subst ','\'',$(bindir))
+TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+
+## po-file creation rules
XGETTEXT ?= xgettext
MSGFMT ?= msgfmt
PO_TEMPLATE = po/gitk.pot
ALL_POFILES = $(wildcard po/*.po)
ALL_MSGFILES = $(subst .po,.msg,$(ALL_POFILES))
-all:: $(ALL_MSGFILES)
+ifndef V
+ QUIET = @
+ QUIET_GEN = $(QUIET)echo ' ' GEN $@ &&
+endif
+
+all:: gitk-wish $(ALL_MSGFILES)
+
+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
+
+uninstall::
+ $(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
+ $(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+
+clean::
+ $(RM) gitk-wish po/*.msg
+
+gitk-wish: gitk
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
+ chmod +x $@+ && \
+ mv -f $@+ $@
$(PO_TEMPLATE): gitk
$(XGETTEXT) -kmc -LTcl -o $@ gitk
@@ -29,17 +56,3 @@ $(ALL_MSGFILES): %.msg : %.po
@echo Generating catalog $@
$(MSGFMT) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)
-clean::
- rm -f $(ALL_PROGRAMS) po/*.msg
-## End of po-file creation rules
-
-# Install rules for po-files
-install: all
- $(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(msgsdir_SQ)' $(INSTALL_D1)
- $(QUIET)$(foreach p,$(ALL_MSGFILES), $(INSTALL_R0)$p $(INSTALL_R1) '$(DESTDIR_SQ)$(msgsdir_SQ)' &&) true
-
-uninstall:
- $(QUIET)$(foreach p,$(ALL_MSGFILES), $(REMOVE_F0)'$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) $(REMOVE_F1) &&) true
- $(QUIET)$(REMOVE_D0)'$(DESTDIR_SQ)$(msgsdir_SQ)' $(REMOVE_D1)
- $(QUIET)$(REMOVE_D0)'$(DESTDIR_SQ)$(libdir_SQ)' $(REMOVE_D1)
- $(QUIET)$(REMOVE_D0)`dirname '$(DESTDIR_SQ)$(libdir_SQ)'` $(REMOVE_D1)
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-08 20:50 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, J. Bruce Fields, Johannes Schindelin,
Robin Rosenberg, Jeff King, Peter Karlsson, Git Mailing List,
msysGit
In-Reply-To: <02DC77F5-7465-418D-972E-0F76E56C3F75@zib.de>
On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:
>
> I don't think a solution will be found by declaring one platform
> native (UNIX) and all other platform non-native. The question to
> answer is how to support cross-platform projects. A valid
> solution should never corrupt data unless the user explicitly
> told git to do so. I don't believe it is a valid solution to set
> core.autocrlf=true on Windows and tell the users: "Well, in its
> default settings, git sometimes corrupts your data on Windows.
> Maybe you want to switch to Linux because this is the native
> platform where data corruption will never happen."
Maybe I am wrong but it seems to me that to guarantee that
CRLF conversion is reversible (which means that you can
always get exactly what you put into the repository), it is
enough to check that the conversation is performed only if
every LF is preceded by CR. If it is not so, error out and
tell the user that the file should be either marked as binary
or EOL in the text must be corrected.
So, even in those rare cases where the heuristic went wrong,
you will not lose your data. Most likely you will get the
above error, but even if a binary file is checked in as text,
it will affect only cross-platform projects, and it will be
easily to correct the situation later by marking this file
as binary and checking in again. So, it is a extermely rare
event, and no data is lost.
Perhaps, this option can be called core.autocrlf=safe
IMHO, a _text_ file is not just some octets, it consists of
lines. Even without CRLF conversation, Git is aware about
to do some basic operations like diff and merge. So, it is
natural to store lines in the repository in the same EOL
marker regardless on what platform the file is created. So,
having core.autocrlf=false on Windows is wrong. You may not
notice it until you do not move to another platform, but the
whole thing is already broken. It is not about one platform
being more native than other. It is like in the C standard,
LF is used to denote the end of line, because it is the only
sane choice to mark it.
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.
From: Nicolas Pitre @ 2008-01-08 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7v7iikrs86.fsf@gitster.siamese.dyndns.org>
On Tue, 8 Jan 2008, Junio C Hamano wrote:
> How about using a constant large enough slop? It is not like
> PREFIX and SUFFIX are different vastly between calls.
The size of the buffer is certainly bounded since the prefix length is
constant, the buffer size is constant, and both possible suffixes are
also constants.
Nicolas
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-08 20:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Steffen Prohaska, Johannes Schindelin,
Robin Rosenberg, Jeff King, Peter Karlsson, Git Mailing List,
msysGit
In-Reply-To: <7vir24rtfp.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Tue, 8 Jan 2008, Junio C Hamano wrote:
>
> I think the project can mark text files as text with attributes
> and if the port to the platform initialized core.autocrlf
> appropriately for the platform everything should work as you
> described.
Yes, I think core.autocrlf should default to "true" on Windows, since
that is what it's about. The alternative is to have "fail"/"warn", to just
make sure that nobody can do the wrong thing by mistake.
We could just do something like this, although that probably does mean
that the whole test-suite needs to be double-checked (ie now we really do
behave differently on windows outside of any config options!))
People who really dislike it can always do the
git config --global core.autocrlf false
thing.
(And no, I don't know if "#ifdef __WINDOWS__" is the right thing to do,
it's almost certainly not. This is just a draft.)
Linus
---
environment.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/environment.c b/environment.c
index 18a1c4e..5766bee 100644
--- a/environment.c
+++ b/environment.c
@@ -34,9 +34,23 @@ char *pager_program;
int pager_use_color = 1;
char *editor_program;
char *excludes_file;
-int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
unsigned whitespace_rule_cfg = WS_DEFAULT_RULE;
+/*
+ * Automatic CRLF conversion on files that look like
+ * text:
+ * 0: none (unix)
+ * 1: convert to LF on check-in and to CRLF on check-out
+ * -1: only on check-in (check-out with just LF)
+ */
+#ifdef __WINDOWS__
+ #define DEF_AUTOCRLF 1
+#else
+ #define DEF_AUTOCRLF 0
+#endif
+
+int auto_crlf = DEF_AUTOCRLF;
+
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
static const char *work_tree;
^ permalink raw reply related
* [STG PATCH] add a --index option to refresh which takes the contents of the index as the new commit
From: Peter Oberndorfer @ 2008-01-08 20:42 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List, Catalin Marinas
In-Reply-To: <20080107105612.GA20981@diana.vm.bytemark.co.uk>
This allows to stage only certain changes to a file by only adding
the desired parts to the index with git-gui, ugit, git add -i or another tool
that manipulates the index and then run stg refresh --index
it also allows removing a file from a patch by running git reset HEAD^ -- file_to_remove
followed by a stg refresh --index
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
---
On Montag 07 Januar 2008, Karl Hasselström wrote:
> On 2008-01-02 20:39:27 +0100, Peter Oberndorfer wrote:
>
> > On Sonntag 30 Dezember 2007, Peter Oberndorfer wrote:
> >
> > > Do you think this would be a useful/good idea? Or do we want a
> > > separate command for removing files from a patch anyway?
> >
> > The question is still open if this is useful for somebody else.
>
> I think it's a useful addition. Thanks!
Good since it was useful for me too even while writing this patch :-)
> So the use_index parameter to refresh_patch is actually not necessary?
> In that case I'd rather you didn't add it, since the functions in
> stgit/stack.py have quite enough parameters already.
>
In the beginning i was afraid it would be to obscure to call it this way
with all parameters set to some specific values.
But having more parameters does not make it better :-)
Done
> > diff --git a/t/t2700-refresh.sh b/t/t2700-refresh.sh
> > index 2e7901c..9eae85d 100755
> > --- a/t/t2700-refresh.sh
> > +++ b/t/t2700-refresh.sh
>
> Bonus points for adding a test case!
>
> I still haven't rebased my patch stack since Catalin accepted most of
> it just before Christmas. Once I've gotten around to that, I'll take
> your patch -- hopefully by then updated to not add the exra argument
> to refresh_patch(). :-)
>
Patch now comes with a Signed-off-by and a log message that explains
how this feature could be used.
It was tested with the testcase, used during development of this patch
and on another repo, but still take care when using it :-)
stgit/commands/refresh.py | 25 ++++++++++++++++---
t/t2700-refresh.sh | 57 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 77 insertions(+), 5 deletions(-)
diff --git a/stgit/commands/refresh.py b/stgit/commands/refresh.py
index 6e8ed0c..952b1b6 100644
--- a/stgit/commands/refresh.py
+++ b/stgit/commands/refresh.py
@@ -45,6 +45,9 @@ options = [make_option('-f', '--force',
make_option('--update',
help = 'only update the current patch files',
action = 'store_true'),
+ make_option('--index',
+ help = 'use the current contents of the index instead of looking at the working directory',
+ action = 'store_true'),
make_option('--undo',
help = 'revert the commit generated by the last refresh',
action = 'store_true'),
@@ -76,6 +79,14 @@ def func(parser, options, args):
if not patch:
raise CmdException, 'No patches applied'
+ if options.index:
+ if args or options.update:
+ raise CmdException, \
+ 'Only full refresh is available with the --index option'
+ if options.patch:
+ raise CmdException, \
+ '--patch is not compatible with the --index option'
+
if not options.force:
check_head_top_equal(crt_series)
@@ -85,9 +96,10 @@ def func(parser, options, args):
out.done()
return
- files = [path for (stat, path) in git.tree_status(files = args, verbose = True)]
+ if not options.index:
+ files = [path for (stat, path) in git.tree_status(files = args, verbose = True)]
- if files or not crt_series.head_top_equal():
+ if options.index or files or not crt_series.head_top_equal():
if options.patch:
applied = crt_series.get_applied()
between = applied[:applied.index(patch):-1]
@@ -105,8 +117,13 @@ def func(parser, options, args):
if autoresolved == 'yes':
resolved_all()
- crt_series.refresh_patch(files = files,
- backup = True, notes = options.annotate)
+
+ if options.index:
+ crt_series.refresh_patch(cache_update = False,
+ backup = True, notes = options.annotate)
+ else:
+ crt_series.refresh_patch(files = files,
+ backup = True, notes = options.annotate)
if crt_series.empty_patch(patch):
out.done('empty patch')
diff --git a/t/t2700-refresh.sh b/t/t2700-refresh.sh
index 2e7901c..9eae85d 100755
--- a/t/t2700-refresh.sh
+++ b/t/t2700-refresh.sh
@@ -6,8 +6,10 @@ test_description='Run "stg refresh"'
test_expect_success 'Initialize StGit stack' '
stg init &&
- echo expected.txt >> .git/info/exclude &&
+ echo expected*.txt >> .git/info/exclude &&
echo patches.txt >> .git/info/exclude &&
+ echo show.txt >> .git/info/exclude &&
+ echo diff.txt >> .git/info/exclude &&
stg new p0 -m "base" &&
for i in 1 2 3; do
echo base >> foo$i.txt &&
@@ -62,4 +64,57 @@ test_expect_success 'Refresh bottom patch' '
diff -u expected.txt patches.txt
'
+cat > expected.txt <<EOF
+p0
+p1
+p4
+EOF
+cat > expected2.txt <<EOF
+diff --git a/foo1.txt b/foo1.txt
+index 728535d..6f34984 100644
+--- a/foo1.txt
++++ b/foo1.txt
+@@ -1,3 +1,4 @@
+ base
+ foo 1
+ bar 1
++baz 1
+EOF
+cat > expected3.txt <<EOF
+diff --git a/foo1.txt b/foo1.txt
+index 6f34984..a80eb63 100644
+--- a/foo1.txt
++++ b/foo1.txt
+@@ -2,3 +2,4 @@ base
+ foo 1
+ bar 1
+ baz 1
++blah 1
+diff --git a/foo2.txt b/foo2.txt
+index 415c9f5..43168f2 100644
+--- a/foo2.txt
++++ b/foo2.txt
+@@ -1,3 +1,4 @@
+ base
+ foo 2
+ bar 2
++baz 2
+EOF
+test_expect_success 'Refresh --index' '
+ stg status &&
+ stg new p4 -m "refresh_index" &&
+ echo baz 1 >> foo1.txt &&
+ git add foo1.txt &&
+ echo blah 1 >> foo1.txt &&
+ echo baz 2 >> foo2.txt &&
+ stg refresh --index &&
+ stg patches foo1.txt > patches.txt &&
+ git diff HEAD^..HEAD > show.txt &&
+ stg diff > diff.txt &&
+ diff -u expected.txt patches.txt &&
+ diff -u expected2.txt show.txt &&
+ diff -u expected3.txt diff.txt &&
+ stg new p5 -m "cleanup again" &&
+ stg refresh
+'
test_done
--
1.5.4.rc2
^ permalink raw reply related
* [STG PATCH] change usage string of refresh to not refer to removed options
From: Peter Oberndorfer @ 2008-01-08 20:43 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
for changing the patch author, commiter and description
Signed-off-by: Peter Oberndorfer <kumbayo84@arcor.de>
---
I saw this while doing the refresh --index patch.
There was a discussion about bringing back refresh -e
If that also brings back this options, please do not apply the patch:-)
stgit/commands/refresh.py | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/stgit/commands/refresh.py b/stgit/commands/refresh.py
index 952b1b6..4695c62 100644
--- a/stgit/commands/refresh.py
+++ b/stgit/commands/refresh.py
@@ -31,11 +31,9 @@ usage = """%prog [options] [<files or dirs>]
Include the latest tree changes in the current patch. This command
generates a new GIT commit object with the patch details, the previous
-one no longer being visible. The patch attributes like author,
-committer and description can be changed with the command line
-options. The '--force' option is useful when a commit object was
-created with a different tool but the changes need to be included in
-the current patch."""
+one no longer being visible. The '--force' option is useful
+when a commit object was created with a different tool
+but the changes need to be included in the current patch."""
directory = DirectoryHasRepository()
options = [make_option('-f', '--force',
--
1.5.4.rc2
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-08 20:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysGit
In-Reply-To: <7v3at8rs4b.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Jan 8, 2008, at 9:15 PM, Junio C Hamano wrote:
>
> Steffen Prohaska <prohaska-wjoc1KHpMeg-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>
>> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:
>>>
>>> "J. Bruce Fields" <bfields-
>>> uC3wQj2KruNg9hUCZPvPmw-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>>>
>>>> My only suggestion is that we consider allowing the user that
>>>> "explicitly told git to do so" be the project maintainer. So if
>>>> you
>>>>
>>>> echo * autodetectcrlf >.gitattributes
>>>> git add .gitattributes
>>>> git commit
>>>>
>>>> then users that clone your repo will get that default without
>>>> having to
>>>> be told to do something magic on clone.
>>>>
>>>> (And ideally I'd've hoped you could do that using the existing crlf
>>>> attribute rather than having to invent something new, but maybe
>>>> that
>>>> doesn't work.)
>>>
>>> I think the project can mark text files as text with attributes
>>> and if the port to the platform initialized core.autocrlf
>>> appropriately for the platform everything should work as you
>>> described.
>>>
>>> At least that is how I read the description of `crlf` in
>>> gitattributes(5).
>>
>>
>> But we do not want to mark a file as text but tell git to run its
>> auto-detection and use the local default line endings.
>
> My reading of the description of `crlf` in gitattributes(5) is:
>
> `crlf`
> ^^^^^^
>
> This attribute controls the line-ending convention.
>
> Set::
>
> Setting the `crlf` attribute on a path is meant to mark
> the path as a "text" file. 'core.autocrlf' conversion
> takes place without guessing the content type by
> inspection.
>
>
> Notice "without guessing".
Exactly this is the problem. Some projects want guessing. A
project needs to have a way to explicitly tell git that is should
guess the file type and if it found "text", then it should use
the right line endings (that is the locally preferred endings).
If the project has control, the project maintainer is responsible
for making the right choice. That is either he enables automatic
detection of "text" files, or he can explicitly tell git about
the types without guessing.
A different project may not want to have guessing at all, but
leave all files as is. I believe this should be the default for
all projects that do not explicitly choose otherwise. I'm still
reluctant to enabling guessing as a system wide default. Someone
may just want to use git to manage a few binary files locally on
his machine. I'd be unhappy if "guessing" corrupted these files.
The project needs control if guessing is activated or not. Right
now we have no way for a project to tell git that it should
guess, even if the default for other projects is not to guess.
Steffen
^ permalink raw reply
* git-gui: Fix broken revert confirmation.
From: Christian Stimming @ 2008-01-08 20:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
I broke this extremely cool feature in 1ac17950,
but it is rather easy to fix this. Sorry for that.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
---
lib/index.tcl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/lib/index.tcl b/lib/index.tcl
index a0b22f2..30a244c 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -386,7 +386,9 @@ proc revert_helper {txt paths} {
set reply [tk_dialog \
.confirm_revert \
"[appname] ([reponame])" \
- [mc "Any unstaged changes will be permanently lost by the revert."] \
+ "$query
+
+[mc "Any unstaged changes will be permanently lost by the revert."]" \
question \
1 \
[mc "Do Nothing"] \
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-08 20:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysGit
In-Reply-To: <7vbq7wrsb6.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Jan 8, 2008, at 9:11 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska-wjoc1KHpMeg-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>
> By the way, is it your setting that mangles people's
> e-mail addresses? If it is, is it possible for you to
> configure it to stop doing that?
No. I have no idea where these mangled addresses come from.
I did never see such addresses before.
I thought I replaced all the mangled addresses in my last reply.
I this mail wrong, too?
Steffen
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-08 20:15 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Robin Rosenberg, Jeff King, Peter Karlsson,
Git Mailing List, msysGit
In-Reply-To: <B655B6FF-9377-434A-A979-2E758771B0FA-wjoc1KHpMeg@public.gmane.org>
Steffen Prohaska <prohaska-wjoc1KHpMeg-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
> On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:
>>
>> "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>>
>>> My only suggestion is that we consider allowing the user that
>>> "explicitly told git to do so" be the project maintainer. So if you
>>>
>>> echo * autodetectcrlf >.gitattributes
>>> git add .gitattributes
>>> git commit
>>>
>>> then users that clone your repo will get that default without
>>> having to
>>> be told to do something magic on clone.
>>>
>>> (And ideally I'd've hoped you could do that using the existing crlf
>>> attribute rather than having to invent something new, but maybe that
>>> doesn't work.)
>>
>> I think the project can mark text files as text with attributes
>> and if the port to the platform initialized core.autocrlf
>> appropriately for the platform everything should work as you
>> described.
>>
>> At least that is how I read the description of `crlf` in
>> gitattributes(5).
>
>
> But we do not want to mark a file as text but tell git to run its
> auto-detection and use the local default line endings.
My reading of the description of `crlf` in gitattributes(5) is:
`crlf`
^^^^^^
This attribute controls the line-ending convention.
Set::
Setting the `crlf` attribute on a path is meant to mark
the path as a "text" file. 'core.autocrlf' conversion
takes place without guessing the content type by
inspection.
Notice "without guessing".
^ permalink raw reply
* Re: [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.
From: Junio C Hamano @ 2008-01-08 20:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801081444360.3054@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 8 Jan 2008, Junio C Hamano wrote:
>
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>> > From: Johannes Sixt <johannes.sixt@telecom.at>
>> >
>> > How come we got along with this not very portable construct for so long?
>> > Probably because the array sizes were computed from the results of
>> > strlen() of string constants. Anyway, a follow-up patch will make the
>> > lengths really non-constant.
>> >
>> > Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
>> > ---
>> > sideband.c | 14 ++++++++++++--
>> > 1 files changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/sideband.c b/sideband.c
>> > index 756bbc2..513d7b3 100644
>> > --- a/sideband.c
>> > +++ b/sideband.c
>> > @@ -19,7 +19,10 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
>> > {
>> > unsigned pf = strlen(PREFIX);
>> > unsigned sf = strlen(SUFFIX);
>> > - char buf[pf + LARGE_PACKET_MAX + sf + 1];
>> > + char *buf, *save;
>> > +
>> > + save = xmalloc(sf);
>> > + buf = xmalloc(pf + LARGE_PACKET_MAX + sf + 1);
>>
>> I have to wonder if the malloc() overhead is small enough
>> compared to the network bandwidth to make a two malloc-free
>> pairs per packet a non-issue...
>
> Eeek. Overhead might be insignificant, but it still doesn't feel right.
>
> What about using alloca() instead? This is not like if we are doing
> funky things with the allocated memory anyway.
That's double Eek as I recall AIX is not dead.
How about using a constant large enough slop? It is not like
PREFIX and SUFFIX are different vastly between calls.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-08 20:11 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <02DC77F5-7465-418D-972E-0F76E56C3F75@zib.de>
Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
By the way, is it your setting that mangles people's
e-mail addresses? If it is, is it possible for you to
configure it to stop doing that?
> I don't think a solution will be found by declaring one platform
> native (UNIX) and all other platform non-native. The question to
> answer is how to support cross-platform projects. A valid
> solution should never corrupt data unless the user explicitly
> told git to do so.
I realize I might have misunderstood your intention.
I did not use the word "native" to mean "native vs second class
citizen". The "native" in my description should have said "a
platform whose native line ending convention happens to match
what the project chose to use as its canonical blob object
representation". And on such a platform, there is no need to
worry about accidental corruption because there is no autocrlf
involved. I could have said "lucky platform" instead of
"native".
I have been assuming that both of us are assuming LF line ending
is what a typical cross-platform project would pick as the
canonical blob object representation. If you are assuming CRLF
line ending as the canonical blob object representation for
projects originating from Windows, UNIX is not native (or
"lucky") in such a project. Of course, in such a project,
setting "core.autocrlf = true" is absolutely a wrong thing to do
on Windows. Perhaps you meant that, and I would agree with you.
In such a project, setting "core.autocrlf = reversed" (which
would convert work tree LF line endings to canonical CRLF when
creating a blob, but we currently do not support it) on UNIX
would become necessary, if you want the resulting mess to work
reasonably without configuration.
As long as "cross-platform" needs to support checkouts on
platforms with different conventions, and if you do not give
explicit marking about the binariness, platforms that are not
"lucky" needs to guess. The alternative is to check out
verbatim and effectively get it all wrong, from the platform
convention's point of view.
There is no avoiding that.
HOWEVER.
If you mean by "cross platform project" a project that picks LF
line ending as the canonical representation, then you cannot
deny the fact that Windows is not "lucky" and without explicit
marking about the binariness, it needs to guess. Again, the
alternative is to check out verbatim and get it all wrong.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-08 20:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <7vir24rtfp.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Jan 8, 2008, at 8:47 PM, Junio C Hamano wrote:
>
> "J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> writes:
>
>> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:
>>> ...
>>> I don't think a solution will be found by declaring one platform
>>> native (UNIX) and all other platform non-native. The question to
>>> answer is how to support cross-platform projects. A valid
>>> solution should never corrupt data unless the user explicitly
>>> told git to do so.
>>
>> My only suggestion is that we consider allowing the user that
>> "explicitly told git to do so" be the project maintainer. So if you
>>
>> echo * autodetectcrlf >.gitattributes
>> git add .gitattributes
>> git commit
>>
>> then users that clone your repo will get that default without
>> having to
>> be told to do something magic on clone.
>>
>> (And ideally I'd've hoped you could do that using the existing crlf
>> attribute rather than having to invent something new, but maybe that
>> doesn't work.)
>
> I think the project can mark text files as text with attributes
> and if the port to the platform initialized core.autocrlf
> appropriately for the platform everything should work as you
> described.
>
> At least that is how I read the description of `crlf` in
> gitattributes(5).
But we do not want to mark a file as text but tell git to run its
auto-detection and use the local default line endings. But for
different projects we do not even want to run the auto-detection,
but leave the files as is.
See my separate mail that I just sent before I read yours.
Steffen
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-08 19:59 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Junio C Hamano, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <20080108190952.GK22155@fieldses.org>
On Jan 8, 2008, at 8:09 PM, J. Bruce Fields wrote:
> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:
>>
>> On Jan 8, 2008, at 7:07 PM, Junio C Hamano wrote:
>>
>>>
>>>
>>> Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
>>>
>>>> msysgit installs plain git. core.autocrlf is unset. Whatever
>>>> plain
>>>> git's default is, this is msysgit's default, too.
>>>
>>> That sounds like a mistake if you are installing a port to a
>>> platform whose native line ending convention is different from
>>> where plain git natively runs on (i.e. UNIX).
>>
>> We failed to agree on a better default and as the lengthy
>> discussion documents, the best default isn't obvious.
>>
>> I don't think a solution will be found by declaring one platform
>> native (UNIX) and all other platform non-native. The question to
>> answer is how to support cross-platform projects. A valid
>> solution should never corrupt data unless the user explicitly
>> told git to do so.
>
> My only suggestion is that we consider allowing the user that
> "explicitly told git to do so" be the project maintainer. So if you
>
> echo * autodetectcrlf >.gitattributes
> git add .gitattributes
> git commit
>
> then users that clone your repo will get that default without
> having to
> be told to do something magic on clone.
>
> (And ideally I'd've hoped you could do that using the existing crlf
> attribute rather than having to invent something new, but maybe that
> doesn't work.)
I like this idea.
I think we need the following:
- if "autodetectcrlf" is set, git should guarantee that files in
the repository will always have LF-only. Otherwise the automatic
conversion can't work.
- git needs to support a way to select the preferred type of
line endings based on the OS. Unix users want to see LF,
while Windows users want to see CRLF for the same file.
And we could implement it as follows:
- We add a configuration variable that sets the preferred
autocrlf conversion, for example core.defaultautocrlf.
- We add a new string value "defaultauto" for crlf in .gitattributes.
crlf=defaultauto is similar to setting crlf to "Unspecified", but
also forces git to act as if core.autocrlf is set to
$(core.defaultautocrlf). That means if the content looks like text
it will be converted according to the local settings.
- On Unix, core.defaultautocrlf defaults to "input".
- On Windows, core.defaultautocrlf defaults to "crlf".
This added layer of indirection gives us what we need: The
file .gitattributes tells git to convert line endings; but the
details of the conversion depend on the environment (OS or
configuration).
Steffen
^ permalink raw reply
* Re: [PATCH 1/2] sideband.c: Use xmalloc() instead of variable-sized arrays.
From: Nicolas Pitre @ 2008-01-08 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7v4pdotdtl.fsf@gitster.siamese.dyndns.org>
On Tue, 8 Jan 2008, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
> > From: Johannes Sixt <johannes.sixt@telecom.at>
> >
> > How come we got along with this not very portable construct for so long?
> > Probably because the array sizes were computed from the results of
> > strlen() of string constants. Anyway, a follow-up patch will make the
> > lengths really non-constant.
> >
> > Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> > ---
> > sideband.c | 14 ++++++++++++--
> > 1 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/sideband.c b/sideband.c
> > index 756bbc2..513d7b3 100644
> > --- a/sideband.c
> > +++ b/sideband.c
> > @@ -19,7 +19,10 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
> > {
> > unsigned pf = strlen(PREFIX);
> > unsigned sf = strlen(SUFFIX);
> > - char buf[pf + LARGE_PACKET_MAX + sf + 1];
> > + char *buf, *save;
> > +
> > + save = xmalloc(sf);
> > + buf = xmalloc(pf + LARGE_PACKET_MAX + sf + 1);
>
> I have to wonder if the malloc() overhead is small enough
> compared to the network bandwidth to make a two malloc-free
> pairs per packet a non-issue...
Eeek. Overhead might be insignificant, but it still doesn't feel right.
What about using alloca() instead? This is not like if we are doing
funky things with the allocated memory anyway.
Nicolas
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-08 19:47 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Steffen Prohaska, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <20080108190952.GK22155@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:
>> ...
>> I don't think a solution will be found by declaring one platform
>> native (UNIX) and all other platform non-native. The question to
>> answer is how to support cross-platform projects. A valid
>> solution should never corrupt data unless the user explicitly
>> told git to do so.
>
> My only suggestion is that we consider allowing the user that
> "explicitly told git to do so" be the project maintainer. So if you
>
> echo * autodetectcrlf >.gitattributes
> git add .gitattributes
> git commit
>
> then users that clone your repo will get that default without having to
> be told to do something magic on clone.
>
> (And ideally I'd've hoped you could do that using the existing crlf
> attribute rather than having to invent something new, but maybe that
> doesn't work.)
I think the project can mark text files as text with attributes
and if the port to the platform initialized core.autocrlf
appropriately for the platform everything should work as you
described.
At least that is how I read the description of `crlf` in
gitattributes(5).
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: J. Bruce Fields @ 2008-01-08 19:09 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Junio C Hamano, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <02DC77F5-7465-418D-972E-0F76E56C3F75@zib.de>
On Tue, Jan 08, 2008 at 07:58:57PM +0100, Steffen Prohaska wrote:
>
> On Jan 8, 2008, at 7:07 PM, Junio C Hamano wrote:
>
>>
>>
>> Steffen Prohaska <prohaska-wjoc1KHpMeg@public.gmane.org> writes:
>>
>>> msysgit installs plain git. core.autocrlf is unset. Whatever plain
>>> git's default is, this is msysgit's default, too.
>>
>> That sounds like a mistake if you are installing a port to a
>> platform whose native line ending convention is different from
>> where plain git natively runs on (i.e. UNIX).
>
> We failed to agree on a better default and as the lengthy
> discussion documents, the best default isn't obvious.
>
> I don't think a solution will be found by declaring one platform
> native (UNIX) and all other platform non-native. The question to
> answer is how to support cross-platform projects. A valid
> solution should never corrupt data unless the user explicitly
> told git to do so.
My only suggestion is that we consider allowing the user that
"explicitly told git to do so" be the project maintainer. So if you
echo * autodetectcrlf >.gitattributes
git add .gitattributes
git commit
then users that clone your repo will get that default without having to
be told to do something magic on clone.
(And ideally I'd've hoped you could do that using the existing crlf
attribute rather than having to invent something new, but maybe that
doesn't work.)
--b.
> I don't believe it is a valid solution to set
> core.autocrlf=true on Windows and tell the users: "Well, in its
> default settings, git sometimes corrupts your data on Windows.
> Maybe you want to switch to Linux because this is the native
> platform where data corruption will never happen."
>
> I'd prefer the "warn/fail" proposal.
>
> Steffen
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Steffen Prohaska @ 2008-01-08 18:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: J. Bruce Fields, Johannes Schindelin, Robin Rosenberg, Jeff King,
Peter Karlsson, Git Mailing List, msysGit
In-Reply-To: <7vmyrgry20.fsf-jO8aZxhGsIagbBziECNbOZn29agUkmeCHZ5vskTnxNA@public.gmane.org>
On Jan 8, 2008, at 7:07 PM, Junio C Hamano wrote:
>
>
> Steffen Prohaska <prohaska-wjoc1KHpMeg-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org> writes:
>
>> msysgit installs plain git. core.autocrlf is unset. Whatever plain
>> git's default is, this is msysgit's default, too.
>
> That sounds like a mistake if you are installing a port to a
> platform whose native line ending convention is different from
> where plain git natively runs on (i.e. UNIX).
We failed to agree on a better default and as the lengthy
discussion documents, the best default isn't obvious.
I don't think a solution will be found by declaring one platform
native (UNIX) and all other platform non-native. The question to
answer is how to support cross-platform projects. A valid
solution should never corrupt data unless the user explicitly
told git to do so. I don't believe it is a valid solution to set
core.autocrlf=true on Windows and tell the users: "Well, in its
default settings, git sometimes corrupts your data on Windows.
Maybe you want to switch to Linux because this is the native
platform where data corruption will never happen."
I'd prefer the "warn/fail" proposal.
Steffen
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Pascal Obry @ 2008-01-08 18:25 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30801080858h5f109b47v87abc6b315fcfa08@mail.gmail.com>
Paolo,
I never tried msmtp. I'm using Cygwin ssmtp to send e-mail via Google
mail. Works fine. If it can be useful to others:
My /etc/ssmtp/ssmtp.conf:
root=<username>@gmail.com
mailhub=smtp.gmail.com:587
FromLineOverride=YES
hostname=<username>@gmail.com
rewriteDomain=
UseSTARTTLS=YES
AuthUser=<username>@gmail.com
AuthPass=<password>
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Jason Sewall @ 2008-01-08 18:16 UTC (permalink / raw)
To: Paolo Ciarrocchi, git
In-Reply-To: <4d8e3fd30801080858h5f109b47v87abc6b315fcfa08@mail.gmail.com>
I've had luck with msmtp: http://msmtp.sourceforge.net/; it's
basically a drop-in replacement for sendmail that supports the
authentication gmail requires.
A quick prayer to the Gods of Google portended this blog entry, which
spells out how to configure it for gmail pretty plainly:
http://typo.onxen.info/articles/2006/06/27/activemailer-sending-via-gmail
Then you just need to specify --smtp-serve /path/to/msmtp to
send-email and you're all set.
Jason
On Jan 8, 2008 11:58 AM, 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
>
^ 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