Michael Haggerty :
> I think that here a reference to the file t/README would help (and
> perhaps make part of your text redundant).
Thank you, done.
--
http://www.catb.org/~esr/";>Eric S. Raymond
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a m
On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond wrote:
> git presently contains one Python extension command, Pete Wycoff's p4
> importer. If my git-weave code is merged it will acquire another.
> I think we can expect more submissions of Python extensions in the
> future, for two good reasons:
On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond wrote:
> Nguyen Thai Ngoc Duy :
>> These may apply to other languages as well. Where do we draw a line?
>
> I'm in favor of the general policy of avoiding scripting languages
> other than the top three most widely deployed. At the moment that
> mea
Am 25.11.2012 03:44, schrieb Eric S. Raymond:
> That, among other things, means up-to-date versions of Python are
> ubiquitous unless we're looking at Windows - in which case Perl and
> shell actually become much bigger portability problems.
You seem to ignore that more than a quater of users are
Junio C Hamano writes:
> Enrico Scholz writes:
>
>> when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
>> git, the command fails with
>>
>> | ... is not a git working tree
>>
>> This is caused by creating submodules with '--separate-git-dir' but
>> still checking for a work
Felipe Contreras :
> If your friends jump off a bridge, would you? Yes, using python has
> served them well, but as opposed to what? Other scripting languages? I
> don't think so.
The competition that Python won was *precisely* against other scripting
languages, notably shell and Perl. Both used
Felipe Contreras :
> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond wrote:
> > Nguyen Thai Ngoc Duy :
> >> These may apply to other languages as well. Where do we draw a line?
> >
> > I'm in favor of the general policy of avoiding scripting languages
> > other than the top three most widely depl
On 2012-11-22, Angelo Borsotti wrote:
> Hi
>
> I have attached an external disc, which appears on Windows as drive f:
> in Windows Explorer.
> Right-clicking on it displays a context menu showing (among other
> items) Git Init Here, Git Gui and
> Git Bash. The first two work properly on that drive
Johannes Sixt :
> Am 25.11.2012 03:44, schrieb Eric S. Raymond:
> > That, among other things, means up-to-date versions of Python are
> > ubiquitous unless we're looking at Windows - in which case Perl and
> > shell actually become much bigger portability problems.
>
> You seem to ignore that more
On 25 November 2012 03:15, Nguyen Thai Ngoc Duy wrote:
> CCing msysgit. I vaguely remember they had problems with building
> Python on Windows. I don't know if it's still an issue.
>
> On Sun, Nov 25, 2012 at 9:44 AM, Eric S. Raymond wrote:
>> git presently contains one Python extension command,
Pat Thoyts :
> Git for Windows simply ships everything we need to run git - so if a
> desirable module requires a version of python, we will add that
> version plus any required modules into the installer. We already have
> a patch to provide python in the msysgit tree - it would just require
> pol
Document that 'git svn' will import SVN tags as branches.
Signed-off-by: Sebastian Leske
---
Documentation/git-svn.txt |6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 92780ef..6212b24 100644
--- a/Documentation/git-svn.txt
Describe what the option --follow-parent does, and what happens if it is
set or unset.
Signed-off-by: Sebastian Leske
---
Documentation/git-svn.txt | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index
git svn will sometimes create branches with an at-sign in the name
(branchname@revision). These branches confuse many users and it is a FAQ
why they are created. Document when git svn will create them.
Signed-off-by: Sebastian Leske
---
I found various important features of git-svn that are not
Document that when using git svn, one should usually either use the
directory structure options to import branches as branches, or only
import one subdirectory. The default behaviour of cloning all branches
and tags as subdirectories in the working copy is usually not what the
user wants.
Signed-o
On 11/25/2012 09:53 AM, Felipe Contreras wrote:
> On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond wrote:
>> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
>> 2008) and be pretty much guaranteed it will be anywhere we want to
>> deploy except Windows. Windows will remain a
Michael Haggerty :
> There is, of course, the awkward issue of how/when to transition to
> Python 3.x, which is *not* backwards compatible with Python 2.x. I
> expect that when the time comes there will be volunteers (myself
> included) willing to help adapt Python scripts to the new version, but
There were two functions doing almost the same XML quoting of
character entities, so implement a library function
strbuf_addstr_xml_quoted() and use that in both places.
Along the way, do a lot of simplification within imap-send.c, which
was doing a lot of its own string management instead of usin
Substantially the same code is present in http-push.c and imap-send.c,
so make a library function out of it.
Signed-off-by: Michael Haggerty
---
strbuf.c | 26 ++
strbuf.h | 6 ++
2 files changed, 32 insertions(+)
diff --git a/strbuf.c b/strbuf.c
index 05d0693..9a37
Signed-off-by: Michael Haggerty
---
http-push.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/http-push.c b/http-push.c
index 8701c12..9923441 100644
--- a/http-push.c
+++ b/http-push.c
@@ -172,28 +172,7 @@ enum dav_header_flag {
static char *xml_en
Through the rest of the file, the data member of struct msg_data is
kept NUL-terminated, and that fact is relied upon in a couple of
places. Change lf_to_crlf() to preserve this invariant.
In fact, there are no execution paths in which lf_to_crlf() is called
and then its data member is required t
all_msgs is only used as a glorified string, therefore there is no
reason to declare it as a struct msg_data.
Signed-off-by: Michael Haggerty
---
imap-send.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index c818b0c..50e2
Previously, read_message() didn't distinguish between an error and eof
when reading its input. This could have resulted in incorrect
behavior if there was an error: (1) reporting "nothing to send" if no
bytes were read or (2) sending an incomplete message if some bytes
were read before the error.
struct msg_data stored (char *, len) of the data to be included in a
message, kept the character data NUL-terminated, etc., much like a
strbuf would do. So change it to use a struct strbuf. This makes the
code clearer and reduces copying a little bit.
A side effect of this change is that the mem
Use the new function to quote characters as they are being added to
buf, rather than quoting them in *p and then copying them into buf.
This increases code sharing, and changes the algorithm from O(N^2) to
O(N) in the number of characters in a line.
Signed-off-by: Michael Haggerty
---
imap-send.
On Sun, Nov 25, 2012 at 10:53 AM, Eric S. Raymond wrote:
> Felipe Contreras :
>> If your friends jump off a bridge, would you? Yes, using python has
>> served them well, but as opposed to what? Other scripting languages? I
>> don't think so.
>
> The competition that Python won was *precisely* agai
On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty wrote:
> On the contrary, there is *constant* traffic on the mailing list about
> incompatibilities between different shell implementations (sh, dash,
> bash, etc), not to mention those in other utilities (sed, grep, etc)
> that one is forced to wo
On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty wrote:
> On 11/25/2012 09:53 AM, Felipe Contreras wrote:
>> On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond wrote:
>>> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
>>> 2008) and be pretty much guaranteed it will be anyw
On Sun, Nov 25, 2012 at 10:54 AM, Eric S. Raymond wrote:
> Felipe Contreras :
>> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond wrote:
>> > Nguyen Thai Ngoc Duy :
>> >> These may apply to other languages as well. Where do we draw a line?
>> >
>> > I'm in favor of the general policy of avoiding
On Sun, 25 Nov 2012, Eric S. Raymond wrote:
Michael Haggerty :
There is, of course, the awkward issue of how/when to transition to
Python 3.x, which is *not* backwards compatible with Python 2.x. I
expect that when the time comes there will be volunteers (myself
included) willing to help adapt
Hi David. One minor but important correction ...
On 11/25/2012 12:51 PM, David Lang wrote:
>
> You may think that C and Bash are poor choices, but that is what the
> community is familar with.
>
Actually, it is C and POSIX shell -- not merely bash. Indeed, the shell
code in Git is expected to wo
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
---
This will also break all translation files, should I also send a patch
to update them ?
Cheers,
Antoine Pelisse
builtin/remote.c |2 +-
1 file changed, 1 insertion(+), 1
On Sun, Nov 25, 2012 at 11:33 AM, Eric S. Raymond wrote:
> Pat Thoyts :
>> Git for Windows simply ships everything we need to run git - so if a
>> desirable module requires a version of python, we will add that
>> version plus any required modules into the installer. We already have
>> a patch to
Hi,
On Sun, Nov 25, 2012 at 7:26 AM, Junio C Hamano wrote:
>
> Thanks, but I prefer not to take patches to gitk-git/ directly;
> could you prepare a patch against Paul's tree at
>
>
> git://ozlabs.org/~paulus/gitk
>
> and send it in that direction (paulus@) instead?
No problem. Will do that.
Hi,
I’m asking here informally first, because my information relates
to a quite old version (the one from lenny-backports). A tl;dr
is at the end.
On a multi-core machine, the garbage collection of git, as well
as pack compression on the server side when someone clones a
repository remotely, the
Hi,
thank you Duy for thinking of Cc:ing the msysGit mailing list. We indeed
do not have a working Python in Git for Windows yet (mainly because I did
not review kusma's patch yet thanks to a non-fun-at-all side track).
On Sun, 25 Nov 2012, Eric S. Raymond wrote:
> Nguyen Thai Ngoc Duy :
> > The
Felipe Contreras :
> Seems sensible, but I don't know what "rejection" would actually mean.
Why is this mysterious? We reject a patch when we don't choose to merge it.
> My "extensions" are on the way to the contrib area. Is the contrib
> area supposed to have different rules? I don't know.
I d
Felipe Contreras :
> Of course, but there are experts in C and shell around, not so many
> python experts. So if somebody sneaks in a python program that makes
> use of features specific to python 2.7, I doubt anybody would notice.
I would.
> And if they did, I doubt that would be reason enough f
David Lang :
> You may think that C and Bash are poor choices, but that is what the
> community is familar with.
I don't think C is a "poor" choice. bash, on the other hand...so
many dependencies on tool quirks!
> You are far from the first person to say that git should be
> re-written (or at le
Felipe Contreras :
> Not according to ohloh:
>
> 1) shell 33%
> 2) tcl 9%
> 3) perl 9.7%
>
> 4) python 1.8%
Look in the Makefile - all that tcl code is buried in gitk. We're
very, very lucky the author did such a good job, because it's a
potentially serious headache; who can maintain it?
--
Right clicking on a tag pops up a menu, which allows
tag to be renamed or deleted.
Signed-off-by: Leon KUKOVEC
---
gitk-git/gitk | 154 +
1 file changed, 154 insertions(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..38cc233
On Sun, Nov 25, 2012 at 6:50 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> Not according to ohloh:
>>
>> 1) shell 33%
>> 2) tcl 9%
>> 3) perl 9.7%
>>
>> 4) python 1.8%
>
> Look in the Makefile - all that tcl code is buried in gitk. We're
> very, very lucky the author did such a good job, bec
On Sun, Nov 25, 2012 at 6:36 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> Of course, but there are experts in C and shell around, not so many
>> python experts. So if somebody sneaks in a python program that makes
>> use of features specific to python 2.7, I doubt anybody would notice.
>
> I
This contains no policy changes or proposals, it simply attempts
to document the interfaces and conventions already in place.
---
Documentation/technical/api-command.txt | 81 +++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/technical/api-command
On Sat, Nov 24, 2012 at 09:44:51PM -0500, Eric S. Raymond wrote:
>
> We're behind the best-practices curve here. The major Linux
> distributions, which have to deal with almost the same set of
> tradeoffs we do, went to Python for pretty much all glue and
> administration scripts outside /etc a d
On Sun, Nov 25, 2012 at 6:32 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> Seems sensible, but I don't know what "rejection" would actually mean.
>
> Why is this mysterious? We reject a patch when we don't choose to merge it.
Why would you reject it? If, according to you, it's very simple t
Felipe Contreras :
> And gitk is an integral part of git. But if you have different
> numbers, what are they?
I looked at the Makefile. I saw that there are shell variables that collect
C commands, shell command, Perl commands, and Python commands. There are no
collections of other commands. Th
Felipe Contreras :
> And are you going to be around to spot them? It seems my patches for
> git-remote-hg slipped by your watch, because it seems they use stuff
> specific to python 2.7.
The dev group hasn't decided (in whatever way it decides these
things) to require 2.6 yet. When and if it does
Felipe Contreras :
> > I'd be happy to help you out by auditing them for version dependencies.
>
> Be my guest:
> http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/remote-helpers;h=adfdcc164e634c74024c8f69bb0cdb9f3b4a9f18;hb=7b4a70c62f3a83fbd8b44bf712141754a5f64205
>
> Some patches might be m
Krzysztof Mazur :
> What about embedded systems? git is also useful there. C and shell is
> everywhere, python is not.
Supposing this is true (and I question it with regard to shell) if you
tell me how you live without gitk and the Perl pieces I'll play that
right back at you as your answer.
--
From: Brandon Casey
I hate to have the battle of the patches, but I kinda prefer the
append_signoff code in sequencer.c over the code in log-tree.c as a
foundation to build on.
So, this series is similar to Duy's "unification" series, but it goes in the
opposite direction and builds on top of se
Commit c1e01b0c generalized the detection of the last paragraph
signed-off-by footer and used rfc2822 as a guideline. Support for rfc2822
style continuation lines was also implemented, but not correctly, so it has
never detected a line beginning with space or tab as a continuation of the
previous
The part of test_commit() may not be appropriate for a tag name.
So let's allow test_commit to accept a fourth argument to specify the tag
name.
Signed-off-by: Brandon Casey
---
t/test-lib-functions.sh | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/t/test-lib-funct
Add some tests to ensure that 'cherry-pick -s' operates in the following
manner:
* Inserts a blank line before appending a s-o-b to a commit message that
does not contain a s-o-b footer
* Does not mistake first line "subject: description" as a s-o-b footer
* Does not mistake single
When 'cherry-pick -s' is used to append a signed-off-by line to a cherry
picked commit, it does not currently detect the "(cherry picked from..."
that may have been appended by a previous 'cherry-pick -x' as part of the
s-o-b footer and it will insert a blank line before appending a new s-o-b.
Let
Start treating the "(cherry picked from" line added by cherry-pick -x
the same way that the s-o-b lines are treated. Namely, separate them
from the main commit message body with an empty line.
Introduce tests to test this functionality.
Signed-off-by: Brandon Casey
---
sequencer.c
Teach append_signoff how to detect a duplicate s-o-b in the commit footer.
This is in preparation to unify the append_signoff implementations in
log-tree.c and sequencer.c.
Fixes test in t3511.
Signed-off-by: Brandon Casey
---
builtin/commit.c | 2 +-
sequencer.c | 43
Teach append_signoff to detect whether a blank line exists at the position
that the signed-off-by line will be added, and avoid adding an additional
one if one already exists. This is necessary to allow format-patch to add a
s-o-b to a patch with no commit message without adding an extra newline.
From: Nguyễn Thái Ngọc Duy
[bc: fix test 90 "signoff: some random signoff-alike" and mark as failing.
Correct behavior should insert a blank line after message body and
signed-off-by ]
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Brandon Casey
---
t/t4014-format-patch.sh | 146
From: Nguyễn Thái Ngọc Duy
S-o-b in the middle of a sentence, at the beginning of the sentence
but it is just because of text wrapping, or a full paragraph of valid
S-o-b in the middle of the message. All these are not S-o-b, but
detected as is. Fix them.
[bc: add two additional tests to demonst
From: Nguyễn Thái Ngọc Duy
This is a preparation step for merging with append_signoff from
sequencer.c
Signed-off-by: Nguyễn Thái Ngọc Duy
Signed-off-by: Brandon Casey
---
builtin/log.c | 13 +
log-tree.c| 21 +
revision.h| 2 +-
3 files changed, 15 in
There are two implementations of append_signoff in log-tree.c and
sequencer.c, which do more or less the same thing. Unify on top of the
sequencer.c implementation.
Add a test in t4014 to demonstrate support for non-s-o-b elements in the
commit footer provided by sequence.c:append_sob. Mark test
"Eric S. Raymond" writes:
> While the weave operation can build a commit graph with any structure
> desired, an important restriction of the inverse (unraveling)
> operation is that it operates on *master branches only*. The unravel
> operation discards non-master-branch content, emitting a warni
Antoine Pelisse writes:
> Subject: Re: [PATCH] diff: Fixes shortstat number of files
Please replace "Fixes" with "Fix at least (because our log messages
are written as if a patch is giving an order to the codebase, iow,
in imperative mood), but we would prefer to see a concrete
description on wh
Antoine Pelisse writes:
> fast-export can fail because of some pruned-reference when importing a
> mark file.
>
> The problem happens in the following scenario:
>
> $ git fast-export --export-marks=MARKS master
> (rewrite master)
> $ git prune
> $ git fast-export --import-marks=MA
Felipe Contreras writes:
> On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras
> wrote:
>> This is a re-roll of the previous series to add support to fetch and push
>> special modes, and refactor some related code.
>
> It seems this one got forgotten, I only see v2 in pu.
Oops; I think that was f
e...@thyrsus.com (Eric S. Raymond) writes:
> ---
Sign off?
> Documentation/CommandIntegration | 69
> ++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/CommandIntegration
>
> diff --git a/Documentation/CommandIntegration
> b/Docume
Junio C Hamano :
> "Eric S. Raymond" writes:
>
> > While the weave operation can build a commit graph with any structure
> > desired, an important restriction of the inverse (unraveling)
> > operation is that it operates on *master branches only*. The unravel
> > operation discards non-master-bra
Sven Strickroth writes:
> Am 11.11.2012 17:40 schrieb Sven Strickroth:
>> Am 06.10.2012 20:28 schrieb Junio C Hamano:
>>> It is either that it was simply forgotten, or after I wrote the part
>>> you quoted early in January there were discussions later that showed
>>> the patch was not desirable f
The latest maintenance release Git v1.8.0.1 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
4e7492f7558f3ba2a450c43efa7de3b0b1adc6c1 git-1.8.0.1.tar.gz
6c0e64d53a8543447f595e3bac4966ba9
Hi all
This is my first post to this list, so thank you for all your work.
After suggesting using zip files to move our projects around, I was
told that you can not zip a git repo without loosing all the history.
This didn't make sense to me, but two people told me the same thing,
so I wasn't sur
On 26 November 2012 15:55, Carl Smith wrote:
> Hi all
>
> This is my first post to this list, so thank you for all your work.
>
> After suggesting using zip files to move our projects around, I was
> told that you can not zip a git repo without loosing all the history.
> This didn't make sense to
On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond wrote:
> Krzysztof Mazur :
>> What about embedded systems? git is also useful there. C and shell is
>> everywhere, python is not.
>
> Supposing this is true (and I question it with regard to shell) if you
> tell me how you live without gitk and the
Junio C Hamano :
> As the first sentence in this paragraph does not make it clear
> enough that you are defining a new term "git execution directory",
> "execution directory" here may be misleading and can easily be
> mistaken as if we look something in the directory where the user
> runs "git" in.
Necklaces has become utilized by means of human beings intended for many
years, in addition to recommended different things to help families in
addition to countries. In the course of heritage humankind include desired
objects having which often to help accentuate independently, from time to
time i
Felipe Contreras writes:
> On Wed, Nov 21, 2012 at 8:48 PM, Jeff King wrote:
> ...
> I would like to understand that that even means. What behavior is
> currently broken?
I do not know if this is the same as what Peff was referring to, but
I found this message in the discussion thread during my
This document contains no new policies or proposals; it attempts
to document established practices and interface requirements.
Signed-off-by: Eric S. Raymond
---
Documentation/technical/api-command.txt | 91 +++
1 file changed, 91 insertions(+)
create mode 100644 D
Add config pack.graphcompression similar to pack.compression.
Applies to non-blob objects and if unspecified falls back to pack.compression.
We may identify objects compressed with level 0 by their leading bytes.
Use this to force recompression when the source and target levels mismatch.
Limit its
Swarovski may be the brand for that selection of precision-cut lead-crystal
cup as well as associated items made by Swarovski AG associated with
Wattens, Luxembourg. These types of stunning drops had been very first
produced within 1892 as well as changed Victorian jewelry style. These days,
these
There are various types of crystalfigurines as well as each individual
gathers all of them with regard to their own factors. They may be big
collectible figurines which are the discussion item on their own, as well as
little sensitive types which are available in models. If you're considering
accum
On Mon, Nov 26, 2012 at 8:45 AM, Brandon Casey wrote:
> From: Brandon Casey
>
> I hate to have the battle of the patches, but I kinda prefer the
> append_signoff code in sequencer.c over the code in log-tree.c as a
> foundation to build on.
>
> So, this series is similar to Duy's "unification" se
81 matches
Mail list logo
