* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jay Soffian @ 2009-01-26 15:29 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126111605.GB19993@coredump.intra.peff.net>
On Mon, Jan 26, 2009 at 6:16 AM, Jeff King <peff@peff.net> wrote:
> I don't want to break existing setups, either. But at some point you
> have to say "this is porcelain, so don't rely on there not being any
> user-triggered effects in its behavior". If porcelain is cast in stone,
> then what is the point in differentiating plumbing from porcelain?
>
> And when the line is blurred (as I think it is in several places)
Aside, AIX has commands that are run both directly or via smit (a
curses-based interface). When smit calls the commands, it passes a
switch to let said commands know that they are being run from smit.
e.g.:
-J
This flag is used when the installp command is executed from the
System Management Interface Tool (SMIT) menus.
Perhaps adding such a concept to those git commands which can be used
in both porcelain and plumbing contexts would be useful for git.
j.
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Jakub Narebski @ 2009-01-26 15:31 UTC (permalink / raw)
To: Peter Krefting; +Cc: Dill, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0901261426350.7798@ds9.cixit.se>
On Mon, 26 Jan 2009, Peter Krefting wrote:
> Jakub Narebski wrote:
>
> > With GUI translations we just use gettext conventions. I don't know
> > any such convention for docs:
>
> There is a lot of documentation being translated using PO files. po4a -
> http://po4a.alioth.debian.org/ - is a nice starting point for that.
I'm not sure if XLIFF wouldn't be better format to use to translate
_documents_. Gettext was meant to translate, I think, not very long
messages in programs.
Also I am not sure how much support this idea has. True, in last Git
User's Survey[1] 63% to 76% wanted (parts of) Documentation... but that
was out of 325 people who answered this question, with 3236 responses
to survey in total, so numbers are more like 6% - 8%.
[1] http://git.or.cz/gitwiki/GitSurvey2008
[2] http://translate.sourceforge.net/wiki/
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Allow format-patch to create patches for merges
From: Johannes Schindelin @ 2009-01-26 15:36 UTC (permalink / raw)
To: Nathan W. Panike; +Cc: git, gitster, aspotashev
In-Reply-To: <1232978650-7008-1-git-send-email-nathan.panike@gmail.com>
Hi,
On Mon, 26 Jan 2009, Nathan W. Panike wrote:
> The behavior for git format-patch is to ignore merge commits, producing
> an empty patch. The code does not allow the user to change this
> behavior. This patch changes that behavior by allowing the user to
> specify -c or -m at the command line to produce a patch for a merge
> commit.
Your patch is almost perfect, except that you
- lack an explanation when this makes sense (format-patch is commonly used
for mail-based patch queues, and only -m 1 would make sense there, and
only if you run format-patch with --first-parent),
- did not add your Sign-off :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/3] Make has_commit non-static
From: Johannes Schindelin @ 2009-01-26 15:38 UTC (permalink / raw)
To: Jake Goulding; +Cc: git, gitster
In-Reply-To: <1232979205-17161-2-git-send-email-goulding@vivisimo.com>
Hi,
On Mon, 26 Jan 2009, Jake Goulding wrote:
> Moving has_commit from branch to a common location in preparation for
> using it in tag. Renaming it to commit_has_any_in_commit_list to be more
> unique.
I feel like bike-shedding for a change, and I'd also like to prove that
not all Germans like long names:
is_ancestor_of_any()
Hmm?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Hannu Koivisto @ 2009-01-26 16:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Charles Bailey, git, Theodore Tso
In-Reply-To: <7v1vuuvt11.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Charles Bailey <charles@hashpling.org> writes:
>
>> Previously, git mergetool used cat-file which does not perform git to
>> worktree conversion. This changes mergetool to use git checkout-index
>> instead which means that the temporary files used for mergetool use the
>> correct line endings for the platform.
>>
>> Signed-off-by: Charles Bailey <charles@hashpling.org>
>
> Sounds like the right thing to do and from a cursory review it looks Ok to
> me.
>
> But I do not use mergetool myself, so an Ack from Ted and a Thanks from
> whoever reported the breakage would be encouraging ;-).
I apologize for not being able to test this earlier and I'm
certainly thankful for the patch, although admittedly I reported
the issue mainly to help improve git, not because mergetool is part
of my normal use of git (that may change when I find time to study it
and see if I can easily add ediff support to it in addition to
emerge).
Now that I tried the patch, I observed that while the stage2 and
stage3 temporary files have CRLF line endings, the merge result
buffer/file has LF line endings. I'm again using Cygwin git,
mergetool -t emerge and native Windows Emacs. So when I quit the
mergetool, I get
...
Hit return to start merge resolution tool (emerge):
warning: LF will be replaced by CRLF in kala.txt
warning: LF will be replaced by CRLF in kala.txt
and indeed hexdump proves that the file in my worktree now has LF
line endings even though it had CRLF line endings before invoking
mergetool.
I wonder why I didn't notice this the first time. I can certainly
reproduce it now without Charles' patch as well so I suppose this
is a separate issue and the patch does what it is supposed to do.
--
Hannu
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Marc Branchaud @ 2009-01-26 16:21 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Stephan Beyer, git, Stephen Haberman, spearce,
Thomas Rast, Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242156320.14855@racer>
I'm sorry, but I just don't understand the purpose of 'was E' (or
whatever syntax) in the merge command. Why is there a need to refer to
E at all? The only reason I can think of is to replicate E's commit
message. Am I missing something?
Come to think of it, what if the user wants to edit a merge commit's
message? Should there be an 'editmerge' command?
M.
Johannes Schindelin wrote:
>
>> - Why do you need "merge D' was E"? Shouldn't "pick E" be able to
>> notice that E is a merge and decompose it into "merge D' was E"
>> internally?
>>
>> This one I am somewhat complaining, unless your answer is "because
>> this way the user could drop some parents from the merge in the
>> editor".
>
> Not only that; the user could use this to fix mismerges, i.e. by replacing
> a SHA-1 with the SHA-1 (or indeed, a short name, unless it is "was") of
> the branch that she _actually_ wanted to merge with.
>
>> And if your answer is that, then my next question will be "if that is
>> the case, can the user be expected to easily find out which commit
>> each parent SHA-1 refers to, without having more hint on the 'merge'
>> insn line?"
>
> Nope.
>
> In most cases, however, that should be plenty enough:
>
> merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
>
> The user does not have to guess much what 9383af1 might refer to.
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Mike Hommey @ 2009-01-26 16:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Peter Krefting, Dill, Git Mailing List
In-Reply-To: <200901261631.18157.jnareb@gmail.com>
On Mon, Jan 26, 2009 at 04:31:17PM +0100, Jakub Narebski wrote:
> On Mon, 26 Jan 2009, Peter Krefting wrote:
> > Jakub Narebski wrote:
> >
> > > With GUI translations we just use gettext conventions. I don't know
> > > any such convention for docs:
> >
> > There is a lot of documentation being translated using PO files. po4a -
> > http://po4a.alioth.debian.org/ - is a nice starting point for that.
>
> I'm not sure if XLIFF wouldn't be better format to use to translate
> _documents_. Gettext was meant to translate, I think, not very long
> messages in programs.
>
> Also I am not sure how much support this idea has. True, in last Git
> User's Survey[1] 63% to 76% wanted (parts of) Documentation... but that
> was out of 325 people who answered this question, with 3236 responses
> to survey in total, so numbers are more like 6% - 8%.
On the other hand, the people who would really need the translations
didn't answer the survey at all, since they couldn't read it.
Mike
^ permalink raw reply
* [PATCH] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 16:26 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
As discussed in
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
the Mac OS X C standard library is always thread safe and always
includes the pthread library. So explicitly using -pthread causes an
'unrecognized option' compiler warning.
This patch clears PTHREAD_LIBS by default. However, if
FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
before.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
Makefile | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..30764af 100644
--- a/Makefile
+++ b/Makefile
@@ -70,6 +70,15 @@ all::
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -817,6 +826,9 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+ ifndef FORCE_DARWIN_PTHREAD_LIBS
+ PTHREAD_LIBS =
+ endif
endif
ifndef CC_LD_DYNPATH
--
1.6.1.213.g28da8
^ permalink raw reply related
* Re: [PATCH] Allow format-patch to create patches for merges
From: Nathan W. Panike @ 2009-01-26 16:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302>
On Mon, Jan 26, 2009 at 9:36 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 26 Jan 2009, Nathan W. Panike wrote:
>
>> The behavior for git format-patch is to ignore merge commits, producing
>> an empty patch. The code does not allow the user to change this
>> behavior. This patch changes that behavior by allowing the user to
>> specify -c or -m at the command line to produce a patch for a merge
>> commit.
>
> Your patch is almost perfect, except that you
>
> - lack an explanation when this makes sense (format-patch is commonly used
> for mail-based patch queues, and only -m 1 would make sense there, and
> only if you run format-patch with --first-parent),
>
I think I have an unusual workflow where my patch makes sense,
although it probably does not for the vast majority of git users. I
regularly use 3 machines: S, L, and H. I keep my work synchronized by
using git. Normally, I fetch from S to L or to H, depending on which
machine I am working on at the moment. I also push from L or H to S.
I sporadically lose connectivity to S, so I have a hook in the repo on
S to send a backup email to me on mail server M, which has a more
reliable connection. This email also serves as a reminder when I
have moved from one machine to another with a degree of latency; and I
can use the mail queue on M to recreate most of my state, if I cannot
fetch from S. In this workflow, I would really like git to create a
patch, even in the merge case, and I think I want to see that it was a
merge.
What I do not want to see is an empty patch when a non-trivial change
has occurred, which is the way it works now.
Also, I think I must be issuing the wrong command, as when I do
git format-patch --first-parent --stdout -1 $merge_commit
there is no data, with or without my patch.
> - did not add your Sign-off :-)
Oops. Thanks for the catch.
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Hosting from Windows XP.
From: Tim Visher @ 2009-01-26 16:27 UTC (permalink / raw)
To: git
Hello Everyone,
I'm trying to get git set up for my company. We're stuck using
Windows for the foreseeable future so for now I have to host the
central integration repository out of a Windows box. I figured the
easiest way to do this, short of installing cygwin, would be to do a
simple msysgit install and then run git daemon with the relevant repo
copied over onto the server. Then devs could track that repo.
However, it appears that msysgit does not install git daemon.
I may totally be missing something here, but I don't know what. Short
of the question is, how do I host a repo out of Windows?
Thanks in advance!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Charles Bailey @ 2009-01-26 16:31 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: Junio C Hamano, git, Theodore Tso
In-Reply-To: <83skn6doxm.fsf@kalahari.s2.org>
On Mon, Jan 26, 2009 at 06:15:01PM +0200, Hannu Koivisto wrote:
>
> Now that I tried the patch, I observed that while the stage2 and
> stage3 temporary files have CRLF line endings, the merge result
> buffer/file has LF line endings. I'm again using Cygwin git,
> mergetool -t emerge and native Windows Emacs. So when I quit the
> mergetool, I get
>
> ...
> Hit return to start merge resolution tool (emerge):
> warning: LF will be replaced by CRLF in kala.txt
> warning: LF will be replaced by CRLF in kala.txt
>
> and indeed hexdump proves that the file in my worktree now has LF
> line endings even though it had CRLF line endings before invoking
> mergetool.
>
> I wonder why I didn't notice this the first time. I can certainly
> reproduce it now without Charles' patch as well so I suppose this
> is a separate issue and the patch does what it is supposed to do.
mergetool doesn't touch the destination file, it just asks the merge
tool to overwrite it.
I suspect that the LF endings in the file is due to the fact that in
builtin-merge-file.c, the file is opened (fopen) in binary mode
("wb"), but xdl_merge terminates all lines with a raw '\n'.
The obvious fix would be to change fopen in builtin-file-merge.c to
use "w" instead, but this doesn't work in a number of scenarios. In
particular, it is wrong for repositories on windows with core.autocrlf
set to false, and would not fix non-windows repositories with
core.autocrlf set to true.
Currently, I've no idea as to what the solution should be.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Shawn O. Pearce @ 2009-01-26 16:31 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
Tim Visher <tim.visher@gmail.com> wrote:
> I'm trying to get git set up for my company. We're stuck using
> Windows for the foreseeable future so for now I have to host the
> central integration repository out of a Windows box. I figured the
> easiest way to do this, short of installing cygwin, would be to do a
> simple msysgit install and then run git daemon with the relevant repo
> copied over onto the server. Then devs could track that repo.
> However, it appears that msysgit does not install git daemon.
git-daemon isn't ported yet, due to its heavy reliance on POSIX
behavior during fork+exec.
> I may totally be missing something here, but I don't know what. Short
> of the question is, how do I host a repo out of Windows?
I think your options are limited to:
- Use Cygwin
- Use a virtual machine running Linux with git inside it
- Use JGit and its daemon
--
Shawn.
^ permalink raw reply
* [PATCH (update)] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Ted Pavlic @ 2009-01-26 16:33 UTC (permalink / raw)
To: gitster; +Cc: git, Ted Pavlic
In-Reply-To: <1232987160-5635-1-git-send-email-ted@tedpavlic.com>
As discussed in
http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
the Mac OS X C standard library is always thread safe and always
includes the pthread library. So explicitly using -pthread causes an
'unrecognized option' compiler warning.
This patch clears PTHREAD_LIBS by default. However, if
FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
before.
Signed-off-by: Ted Pavlic <ted@tedpavlic.com>
---
This update adds the documentation comment in the Makefile to
configure.ac as well.
Makefile | 11 +++++++++++
configure.ac | 8 ++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b4d9cb4..86f0a66 100644
--- a/Makefile
+++ b/Makefile
@@ -70,6 +70,14 @@ all::
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -817,6 +825,9 @@ ifeq ($(uname_S),Darwin)
BASIC_LDFLAGS += -L/opt/local/lib
endif
endif
+ ifndef FORCE_DARWIN_PTHREAD_LIBS
+ PTHREAD_LIBS =
+ endif
endif
ifndef CC_LD_DYNPATH
diff --git a/configure.ac b/configure.ac
index 082a03d..a53d97c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -578,6 +578,14 @@ GIT_PARSE_WITH(expat))
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
+# Define FORCE_DARWIN_PTHREAD_LIBS if you are building on Darwin/Mac OS
+# X and want PTHREAD_LIBS to be set. On Mac OS X, all components of the
+# C standard library that are defined to be thread safe by the POSIX
+# standard already include the pthread library. Hence, the -pthread
+# option is redundant and will generate an 'unrecognized option'
+# warning. So PTHREAD_LIBS will be cleared unless
+# FORCE_DARWIN_PTHREAD_LIBS is set.
+#
# Define NO_MMAP if you want to avoid mmap.
#
# Define NO_ICONV if your libc does not properly support iconv.
--
1.6.1.213.g28da8
^ permalink raw reply related
* [PATCH v2] Allow format-patch to create patches for merges
From: Nathan W. Panike @ 2009-01-26 16:43 UTC (permalink / raw)
To: git; +Cc: Nathan W. Panike
In-Reply-To: <d77df1110901260827j2200fe41oe1b84c387d88aba () mail ! gmail ! com>
The behavior for git format-patch is to ignore merge commits, producing an
empty patch. The code does not allow the user to change this behavior. This
patch changes that behavior by allowing the user to specify -c or -m at the
command line to produce a patch for a merge commit.
Signed-off-by: Nathan W. Panike <nathan.panike@gmail.com>
---
Add Sign off.
This seems to solve my problem, but maybe my workflow is sufficiently different
that it is a problem no one else has. Maybe someone can point me in a direction
that solves problems more users have.
Thanks,
Nathan Panike
builtin-log.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 2ae39af..ea4729d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -994,10 +994,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
continue;
}
- /* ignore merges */
- if (commit->parents && commit->parents->next)
- continue;
-
if (ignore_if_in_upstream &&
has_commit_patch_id(commit, &ids))
continue;
--
1.6.1.1.GIT
^ permalink raw reply related
* Re: Hosting from Windows XP.
From: Johannes Schindelin @ 2009-01-26 16:45 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
Hi,
On Mon, 26 Jan 2009, Tim Visher wrote:
> I may totally be missing something here, but I don't know what. Short
> of the question is, how do I host a repo out of Windows?
Use a net share. Use the native permission system to restrict/open up the
repository for certain people to read from/write to.
Ciao,
Dscho
^ permalink raw reply
* Re: Heads up: major rebase -i -p rework coming up
From: Marc Branchaud @ 2009-01-26 16:10 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Stephen Haberman, spearce, Thomas Rast,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0901242056070.14855@racer>
Johannes Schindelin wrote:
>
> - $sha1'
>
> for merge and goto, if a $sha1 ends in a single quote, the
> rewritten commit is substituted (if there is one)
I find this notation fairly unintuitive. I'm more inclined to let users
specify their own names for important parts of the rebase.
I guess that's what Junio's 'mark' command is for, but not having seen a
proper explanation of 'mark', I suggest instead a more inline method: an
'as' keyword. Any command in a todo script can be followed (on the same
line, before the SHA1 value) with 'as <name>' allowing <name> to appear
later in the script to refer to the result of the earlier command.
So the script in the example becomes
pick as start A
pick C
pick as bottom D
goto start
pick B
merge bottom was E
I find that much easier to understand. Especially when real SHA1 values
are floating around everywhere, I think this notation will help users
get things right.
This approach also allows a commit name "A" to consistently refer to the
original commit, which I think also makes things easier for users.
M.
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Jakub Narebski @ 2009-01-26 17:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Tim Visher, git
In-Reply-To: <20090126163124.GA31810@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Tim Visher <tim.visher@gmail.com> wrote:
> > I'm trying to get git set up for my company. We're stuck using
> > Windows for the foreseeable future so for now I have to host the
> > central integration repository out of a Windows box. I figured the
> > easiest way to do this, short of installing cygwin, would be to do a
> > simple msysgit install and then run git daemon with the relevant repo
> > copied over onto the server. Then devs could track that repo.
> > However, it appears that msysgit does not install git daemon.
>
> git-daemon isn't ported yet, due to its heavy reliance on POSIX
> behavior during fork+exec.
You can use instead "dumb" HTTP protocol, or network filesystem
(network share). Or SSH.
Note that for push you don't [usually] use git-daemon: you can use
SSH, filesystem (network share), HTTPS with WebDAV.
> > I may totally be missing something here, but I don't know what. Short
> > of the question is, how do I host a repo out of Windows?
>
> I think your options are limited to:
[...]
> - Use JGit and its daemon
>From what I remember currently JGit daemon generates suboptimal
packfiles, as it does not support delta compression yet...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Shawn O. Pearce @ 2009-01-26 17:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tim Visher, git
In-Reply-To: <m3bptux984.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > - Use JGit and its daemon
>
> From what I remember currently JGit daemon generates suboptimal
> packfiles, as it does not support delta compression yet...
Yes.
It does however support delta-reuse, and it only supports the
index-pack variant during receive-pack. So it saves and reuses
any deltas created by C git. Which makes it almost tolerable to
work with as a bit server.
--
Shawn.
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Tay Ray Chuan @ 2009-01-26 17:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tim Visher, git
In-Reply-To: <alpine.DEB.1.00.0901261744240.25749@intel-tinevez-2-302>
Hi,
On Tue, Jan 27, 2009 at 12:45 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Use a net share. Use the native permission system to restrict/open up the
> repository for certain people to read from/write to.
hmm, does this entail git daemon usage too?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Peter Simons @ 2009-01-26 17:46 UTC (permalink / raw)
To: git
In-Reply-To: <808woyz2k7.fsf@tiny.isode.net>
Bruce Stephens <bruce.stephens@isode.com> writes:
>> Other modes, such as message-mode, do support that kind of thing
>> correctly, so apparently it is possible to configure what the
>> editor considers as a paragraph. Is there some Emacs wizard out
>> there who'd be kind enough to improve git-mode accordingly?
>
> I suspect this doesn't directly relate to git-mode. What mode
> does emacs say you're in at this point? I'm guessing the buffer
> name is COMMIT_EDITMSG and the mode is fundamental-mode?
The buffer is in "log-edit" mode.
> In that case you could stick this in your .emacs if you wanted to
> use message-mode:
>
> (setq auto-mode-alist (cons '("COMMIT_EDITMSG" . message-mode) auto-mode-alist))
Unfortunately, it's not that easy. I'm not an Emacs expert, but I'd
assume that switching into a different mode would change the meaning
of C-c C-c.
Peter
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Tay Ray Chuan @ 2009-01-26 17:46 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0901260827ge5e4b29w871b345da2373f6b@mail.gmail.com>
Hi,
On Tue, Jan 27, 2009 at 12:27 AM, Tim Visher <tim.visher@gmail.com> wrote:
> Hello Everyone,
>
> I'm trying to get git set up for my company. We're stuck using
> Windows for the foreseeable future so for now I have to host the
> central integration repository out of a Windows box. I figured the
> easiest way to do this, short of installing cygwin, would be to do a
> simple msysgit install and then run git daemon with the relevant repo
> copied over onto the server. Then devs could track that repo.
> However, it appears that msysgit does not install git daemon.
you might want to look at using pushing over DAV: say, have all your
employees pulling from a DAV-enabled server.
The DAV protocol itself is platform-agnostic, so your server could be
Windows or Linux or whatever. Since DAV deals with file I/O, you might
want to look at your security options, though I think basic access
authentication would be enough if your server is only accessible
within your company's LAN.
By pushing over DAV, you can avoid running a git daemon. Looking at
how you would do this on Windows, i don't think it's advisable to do
so.
To do this, first, you would need to have cygwin, then you have to run
"cygrunsrv -I", which will install your git daemon as a Windows
service.
AFAIK, cygrunsrv pipes stuff to git-daemon. I don't know how good this
option is, reliablity or performance-wise.
I've tried this out (somewhat limitedly) using git built on cygwin,
with an Apache server, though currently you would have problems if
your Apache was running on a Windows box (my patch to fix this is on
its way).
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: Hosting from Windows XP.
From: Shawn O. Pearce @ 2009-01-26 17:46 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Johannes Schindelin, Tim Visher, git
In-Reply-To: <be6fef0d0901260944l7e128588xc560810515e5f941@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Tue, Jan 27, 2009 at 12:45 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Use a net share. Use the native permission system to restrict/open up the
> > repository for certain people to read from/write to.
>
> hmm, does this entail git daemon usage too?
No, developers would be accessing the repository directly over SMB.
Its slower than if you used git daemon. Access over SMB is
tolerable, especially if your network is fast, but there's still a
lot more data transfer then if the native git protocol could be used.
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #06; Sat, 24)
From: Junio C Hamano @ 2009-01-26 17:47 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Steffen Prohaska
In-Reply-To: <497D6BA7.4070409@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> * sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits
>> - Windows: Revert to default paths and convert them by
>> RUNTIME_PREFIX
>> - Compute prefix at runtime if RUNTIME_PREFIX is set
>> - Modify setup_path() to only add git_exec_path() to PATH
>> - Add calls to git_extract_argv0_path() in programs that call
>> git_config_*
>> - git_extract_argv0_path(): Move check for valid argv0 from caller
>> to callee
>> - Refactor git_set_argv0_path() to git_extract_argv0_path()
>> - Move computation of absolute paths from Makefile to runtime (in
>> preparation for RUNTIME_PREFIX)
>>
>> We should move this to 'next' soon with J6t's blessing.
>
> I've been using this series for a few days now without problems:
>
> Acked-by: Johannes Sixt <j6t@kdbg.org>
Thanks. I take that as not just "have been using this and no breakage
observed" but also "of course the patches themselves make sense to me".
^ permalink raw reply
* Re: [PATCH (update)] make: By default, remove -pthread on Darwin (it is included by cstdlib).
From: Junio C Hamano @ 2009-01-26 17:47 UTC (permalink / raw)
To: Ted Pavlic; +Cc: gitster, git
In-Reply-To: <1232987609-6229-1-git-send-email-ted@tedpavlic.com>
Ted Pavlic <ted@tedpavlic.com> writes:
> As discussed in
>
> http://lists.apple.com/archives/Unix-porting/2005/Mar/msg00019.html
>
> the Mac OS X C standard library is always thread safe and always
> includes the pthread library. So explicitly using -pthread causes an
> 'unrecognized option' compiler warning.
>
> This patch clears PTHREAD_LIBS by default. However, if
> FORCE_DARWIN_PTHREAD_LIBS is defined, then PTHREAD_LIBS will be set as
> before.
Why is this even configurable? You explained pretty clearly that:
- With -pthread, you get an nasty warning;
- By default, we now do not use -pthread;
- By adding FORCE_DARWIN_PTHREAD_LIBS, you can still compile with
-pthread.
But the above leaves the reader wondering in what situation it may be
useful to use FORCE_* and for what purpose other than to get the nasty
warning back (which probably is not most users want to).
^ permalink raw reply
* Re: [PATCH] Allow format-patch to create patches for merges
From: Junio C Hamano @ 2009-01-26 18:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nathan W. Panike, git, aspotashev
In-Reply-To: <alpine.DEB.1.00.0901261604420.25749@intel-tinevez-2-302>
[-- Attachment #1: Type: text/plain, Size: 2771 bytes --]
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> - lack an explanation when this makes sense (format-patch is commonly used
> for mail-based patch queues, and only -m 1 would make sense there, and
> only if you run format-patch with --first-parent),
You do not necessarily want --first-parent.
Suppose you have this topology
B---D---E
/ /
M---A---C
where M is 'master', and E is 'mine'.
The format-patch command ignores merges by default because you can get
diff for A-M, B-A, C-A, E-D and serialize the resulting history without
it, and this is often sufficient. When D merges with a conflict, or D is
an evil merge, however, you will not be able to reproduce how D looked
like on the receiving end. Your --first-parent would instead format the
log message for A B D E with patch text of A-M, B-A, D-B and E-D.
But as a recipient of such a patch series, I'd much prefer to see the
patch text and the log message of B and C themselves. I'd either apply
them on top of A serially, or apply them on top of A to recreate the
forked history the sender had and merge, to arrive at the state the sender
had at D either way, resolving a potential conflict (either when applying
C on top of B, or when merging between B and C), and apply E on top.
Getting a first parent diff that says "I merged random stuff here at D and
here is the difference D-B", is much less useful and throws us back to
dark ages of CVS/SVN merges, especially because C could be a long
multi-patch sequence.
I am not happy about Nathan's output. I think "-m" output is a wrong
thing to use in that it just lets D-B and D-C patches in the same output
file, without marking that it is something you should not be applying as
part of the series blindly. The patch is "If you reproduced my B and C
with the patches so far, here is a hint to help you recreate the merged
state D", and care must be taken to make sure both the tool and the user
notice the situation. "git am", after you have applied B and then C, will
notice that the patches for D does not apply anyway, but the message
should tell the recipient that it is _expected_ not to apply to avoid
confusion. One possible solution might be to always show --cc patch in
such a case, which (1) won't apply with patch nor git-am, and (2) will be
clear it is not a patch by having more than two @@ signs on each hunk
header.
If you really want to generate a patch for a merge commit (e.g. D in the
above picture), what you may want is "here is a fix-up you need to apply
on top of the result of naturally merging B and C to arrive at D". It
could be empty if the merge is conflict-free and there is no evil amend.
Here is a food-for-thought sample history for interested parties to
experiment on.
[-- Attachment #2: a bundle out of a sample repo --]
[-- Type: application/octet-stream, Size: 2036 bytes --]
^ 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