On Fri, Jan 25, 2013 at 07:36:18AM -0800, Junio C Hamano wrote:
> Jonathon Mah writes:
>
> > Just to note, the proposals so far don't prevent a "smart-ass"
> > function from freeing the buffer when it's called underneath the
> > use/release scope, as in:
> >
> > with_commit_buffer(commit); {
> >
When git-commit is asked to reuse a commit message via "-c",
we call read_commit_message, which looks up the commit and
hands back either the re-encoded result, or a copy of the
original. We make a copy in the latter case so that the
ownership semantics of the return value are clear (in either
case
The logmsg_reencode function will return the reencoded
commit buffer, or NULL if reencoding failed or no reencoding
was necessary. Since every caller then ends up checking for NULL
and just using the commit's original buffer, anyway, we can
be a bit more helpful and just return that buffer when we
Usually a commit that makes it to logmsg_reencode will have
been parsed, and the commit->buffer struct member will be
valid. However, some code paths will free commit buffers
after having used them (for example, the log traversal
machinery will do so to keep memory usage down).
Most of the time th
Am 2013-01-25 19:07, schrieb Junio C Hamano:
Carsten Fuchs writes:
[...]
$ git merge origin/master --ff-only
Updating f419d57..2da6052
error: The following untracked working tree files would be overwritten by merge:
obsolete/e107/Readme.txt
obsolete/e107/article.php
This will make it easier to use setup_tool in places where we expect
that the selected tool will not support the current mode.
Signed-off-by: John Keeping
---
On Fri, Jan 25, 2013 at 04:24:03PM -0800, Junio C Hamano wrote:
> Applying this one on top of 1/7 thru 5/7 and 7/7 seems to break
> t7610
On Fri, Jan 25, 2013 at 10:50:58PM -0800, David Aguilar wrote:
> Remove the exceptions for "vim" and "defaults" in the mergetool library
> so that every filename in mergetools/ matches 1:1 with the name of a
> valid built-in tool.
>
> Make common functions available in $MERGE_TOOLS_DIR/include/.
>
draf...@gmail.com wrote on Fri, 25 Jan 2013 12:44 -0800:
> Python 2.5 and older do not accept None as the first argument to
> translate() and complain with:
>
>TypeError: expected a character buffer object
>
> Satisfy this older python by calling maketrans() to generate an empty
> translation
draf...@gmail.com wrote on Fri, 25 Jan 2013 12:44 -0800:
> Python 2.4 lacks the following features:
>
>subprocess.check_call
>struct.pack_into
>
> Take a cue from 460d1026 and provide an implementation of the
> CalledProcessError exception. Then replace the calls to
> subproccess.check_c
This will make it easier to use setup_tool in places where we expect
that the selected tool will not support the current mode.
We need to introduce a new return code for setup_tool to differentiate
between the case of "the selected tool is invalid" and "the selected
tool is not a built-in" since w
On 01/25/2013 08:03 PM, Jonathan Nieder wrote:
diff --git a/abspath.c b/abspath.c
index 40cdc462..c7d5458e 100644
--- a/abspath.c
+++ b/abspath.c
@@ -216,7 +216,7 @@ const char *absolute_path(const char *path)
const char *prefix_filename(const char *pfx, int pfx_len, const char *arg)
{
On 26.01.13 02:03, Jonathan Nieder wrote:
> Throughout git, it is assumed that the WIN32 preprocessor symbol is
> defined on native Windows setups (mingw and msvc) and not on Cygwin.
> On Cygwin, most of the time git can pretend this is just another Unix
> machine, and Windows-specific magic is gen
Dear Git Hackers,
I have a feature request for `git add` auto completion:
`git add` auto completion suggests all files / directories, filtered by
nothing. I guess it would be
much nicer (as in increasing productivity) if it would only suggest unstaged
content, as reported by
`git status`, becau
Under Python 3 'hasher.update(...)' must take a byte string and not a
unicode string. Explicitly encode the argument to this method as UTF-8
bytes. This is safe since we are encoding a Python Unicode string to a
Unicode encoding.
This changes the directory used by git-remote-testpy for its git m
On Sat, Jan 26, 2013 at 4:45 AM, Pete Wyckoff wrote:
> draf...@gmail.com wrote on Fri, 25 Jan 2013 12:44 -0800:
>> Python 2.5 and older do not accept None as the first argument to
>> translate() and complain with:
>>
>>TypeError: expected a character buffer object
>>
>> Satisfy this older pyth
I am currently a student at Brigham Young University - Idaho and we are use
Pagoda Box and Git for our Mobile Apps class. However, the school's network
has blocked incoming trafic on port 22. I have been searching through all the
tutorials and documents provided by Pagoda Box and Git but have
On Sat, Jan 26, 2013 at 4:48 AM, Pete Wyckoff wrote:
> draf...@gmail.com wrote on Fri, 25 Jan 2013 12:44 -0800:
>> + sys.stdout.write(s);
> One stray semicolon.
Whoops. Thanks.
> In terms of maintenance, I'll not run tests with 2.4 or 2.5
> myself, but maybe you would be willing to check
From: Brandon Casey
Python 2.4 lacks the following features:
subprocess.check_call
struct.pack_into
Take a cue from 460d1026 and provide an implementation of the
CalledProcessError exception. Then replace the calls to
subproccess.check_call with calls to subprocess.call that check the re
From: Brandon Casey
Python 2.5 and older do not accept None as the first argument to
translate() and complain with:
TypeError: expected a character buffer object
As suggested by Pete Wyckoff, let's just replace the call to translate()
with a regex search which should be more clear and more p
On Sat, Jan 26, 2013 at 4:12 AM, John Keeping wrote:
> On Fri, Jan 25, 2013 at 10:50:58PM -0800, David Aguilar wrote:
>> Remove the exceptions for "vim" and "defaults" in the mergetool library
>> so that every filename in mergetools/ matches 1:1 with the name of a
>> valid built-in tool.
>>
>> Mak
On Sat, Jan 26, 2013 at 12:40:23PM -0800, David Aguilar wrote:
> On Sat, Jan 26, 2013 at 4:12 AM, John Keeping wrote:
> > On Fri, Jan 25, 2013 at 10:50:58PM -0800, David Aguilar wrote:
> >> diff --git a/Makefile b/Makefile
> >> index f69979e..3bc6eb5 100644
> >> --- a/Makefile
> >> +++ b/Makefile
Jeff King writes:
> Yeah, agreed. I started to fix this up with a use/unuse pattern and
> realized something: all of the call sites are calling logmsg_reencode
> anyway, because that is the next logical step in doing anything with the
> buffer that is not just parsing out the parent/timestamp/tre
Torsten Bögershausen writes:
> Do we really need "which" to detect if frotz is installed?
I think we all know the answer to that question is no, but why is
that a relevant question in the context of this discussion? One of
us may be very confused.
I thought the topic of this discussion was th
John Keeping writes:
> Junio, can you replace the queued 0846b0c (git-remote-testpy: hash bytes
> explicitly) with this?
>
> I hadn't realised that the "hex" encoding we chose before is a "bytes to
> bytes" encoding so it just fails with an error on Python 3 in the same
> way as the original code
On Sat, Jan 26, 2013 at 01:26:53PM -0800, Junio C Hamano wrote:
> This looks very good.
>
> I wonder if this lets us get rid of the hack in cmd_log_walk() that
> does this:
>
> while ((commit = get_revision(rev)) != NULL) {
> if (!log_tree_commit(rev, commit) &&
>
This is a repost from here:
http://thread.gmane.org/gmane.comp.version-control.git/211176
which got no response initially. Basically the issue is that read-only
repos (e.g., a CI server) whose workflow is something like:
git fetch $some_branch &&
git checkout -f $some_branch &&
make test
We generally try to run "gc --auto" after any commands that
might introduce a large number of new objects. An obvious
place to do so is after running "fetch", which may introduce
new loose objects or packs (depending on the size of the
fetch).
While an active developer repository will probably
eve
When we look up a sha1 object for reading, we first check
packfiles, and then loose objects. If we still haven't found
it, we re-scan the list of packfiles in `objects/pack`. This
final step ensures that we can co-exist with a simultaneous
repack process which creates a new pack and then prunes the
When this change was originally made (0846b0c - git-remote-testpy: hash bytes
explicitly , I didn't realised that the "hex" encoding we chose is a "bytes to
bytes" encoding so it just fails with an error on Python 3 in the same way as
the original code.
Since we want to convert a Unicode string to
From: John Keeping
This will make it easier to use setup_tool in places where we expect
that the selected tool will not support the current mode.
We need to introduce a new return code for setup_tool to differentiate
between the case of "the selected tool is invalid" and "the selected
tool is no
Remove the exceptions for "vim" and "defaults" in the mergetool library
so that every filename in mergetools/ matches 1:1 with the name of a
valid built-in tool.
Make common functions available in $MERGE_TOOLS_DIR/include/.
Signed-off-by: David Aguilar
---
This diffstat is much nicer now thanks
Remove the exceptions for "vim" and "defaults" in the mergetool library
so that every filename in mergetools/ matches 1:1 with the name of a
valid built-in tool.
Make common functions available in $MERGE_TOOLS_DIR/include/.
Signed-off-by: David Aguilar
---
v2 used "include" instead of "mergetool
Jeff King wrote:
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -959,6 +959,9 @@ int cmd_fetch(int argc, const char **argv, const char
> *prefix)
> struct string_list list = STRING_LIST_INIT_NODUP;
> struct remote *remote;
> int result = 0;
> + static const char *argv_
Yes, this really is four months later. Somehow I forgot all
about this series.
gits...@pobox.com wrote on Fri, 28 Sep 2012 12:11 -0700:
> Pete Wyckoff writes:
>
> > Use the standard client_view function from lib-git-p4.sh
> > instead of building one by hand. This requires a bit of
> > rework,
Junio and Hannes: thanks for the comments four months ago; I've
been slow getting back to this. I incorporated all your
suggestions.
Junio: this merges okay with Brandon's v2.4 support series.
This series fixes problems in git-p4, and its tests, so that
git-p4 works on the cygwin platform.
See
Commit fed2369 (git-p4: Search for parent commit on branch creation,
2012-01-25) uses temporary branches to help find the parent of a
new p4 branch. The temp branches are of the form "git-p4-tmp/%d"
for some p4 change number. Mistakenly, this string was made
using os.path.join() instead of just s
Found by "pyflakes" checker tool.
Modules shelve, getopt were unused.
Module os.path is exported by os.
Reformat one-per-line as is PEP008 suggested style.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/git-p4.py b/git
Depot paths must start with //. Exit with a better explanation
when a bad depot path is supplied.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 1 +
t/t9800-git-p4-basic.sh | 5 +
2 files changed, 6 insertions(+)
diff --git a/git-p4.py b/git-p4.py
index 47d092d..cbf8525 100755
Simplify the code a bit by using an existing function.
Signed-off-by: Pete Wyckoff
---
t/lib-git-p4.sh | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
index 7061dce..890ee60 100644
--- a/t/lib-git-p4.sh
+++ b/t/lib-git-p4.sh
@@ -7
The printf command re-interprets the format string as
long as there are arguments to consume. Use this to
simplify a for loop in the client_view() library function.
This requires a fix to one of the client_view callers.
An errant \n in the string was converted into a harmless
newline in the input
Use the standard client_view function from lib-git-p4.sh
instead of building one by hand. This requires a bit of
rework, using the current value of $P4CLIENT for the client
name. It also reorganizes the test to isolate changes to
$P4CLIENT and $cli in a subshell.
Signed-off-by: Pete Wyckoff
---
This will avoid having to do native path conversion for
windows. Also may be a bit cleaner always to know that p4d
has that working directory, instead of wherever the function
was called from.
Signed-off-by: Pete Wyckoff
---
t/lib-git-p4.sh | 7 +--
1 file changed, 5 insertions(+), 2 deleti
Native windows binaries do not understand posix-like
path mapping offered by cygwin. Convert paths to native
using "cygpath --windows" before presenting them to p4d.
This is done using the AltRoots mechanism of p4. Both the
posix and windows forms are put in the client specification,
allowing p4
Replacing \r\n with \n on windows was added in c1f9197 (Replace
\r\n with \n when importing from p4 on Windows, 2007-05-24), to
work around an oddity with "p4 print" on windows. Text files
are printed with "\r\r\n" endings, regardless of whether they
were created on unix or windows, and regardless
Files of type utf16 are handled with "p4 print" instead of the
normal "p4 -G print" interface due to how the latter does not
produce correct output. See 55aa571 (git-p4: handle utf16
filetype properly, 2011-09-17) for details.
On windows, though, "p4 print" can not be told which line
endings to u
P4 stores newlines in the depos as \n. By default, git does this
too, both on unix and windows. Test to make sure that this stays
true.
Both git and p4 have mechanisms to use \r\n in the working
directory. Exercise these.
Signed-off-by: Pete Wyckoff
---
t/t9802-git-p4-filetype.sh | 117 +
David Aguilar writes:
> @@ -44,19 +46,9 @@ valid_tool () {
> }
>
> setup_tool () {
> - case "$1" in
> - vim*|gvim*)
> - tool=vim
> - ;;
> - *)
> - tool="$1"
> - ;;
> - esac
This part was an eyesore every time I looked at mergeto
In all clients, even those created on windows, use unix line
endings. This makes it possible to verify file contents without
doing OS-specific comparisons in all the tests.
Tests in t9802-git-p4-filetype.sh are used to make sure that
the other LineEnd options continue to work.
Signed-off-by: Pet
This character is not valid in windows filenames, even though
it can appear in p4 depot paths. Avoid using it in tests on
windows, both mingw and cygwin.
Signed-off-by: Pete Wyckoff
---
t/t9809-git-p4-client-view.sh | 10 --
t/t9812-git-p4-wildcards.sh | 37 +++
There are some old versions of p4, compiled for cygwin, that
treat read-only files differently.
Normally, a file that is not open is read-only, meaning that
"test -w" on the file is false. This works on unix, and it works
on windows using the NT version of p4. The cygwin version
of p4, though, c
This test does a commit that is a pure mode change, submits
it to p4 but causes the submit to fail. It verifies that
the state in p4 as well as the client directory are both
unmodified after the failed submit.
On cygwin, "chmod +x" does nothing, so use the test_chmod
function to modify the index
On windows, p4 marks un-edited files as read-only. Not only are
they read-only, but also they cannot be deleted. Remove the
read-only attribute before deleting in both the copy and rename
cases.
This also happens in the RCS cleanup code, where a file is marked
to be deleted, but must first be ed
The extra quoting and double-% are unneeded, just to work
around the shell. Instead, avoid the shell indirection.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index a989704..c43d044 100755
--- a/git-p4.py
+
Invoke git rev-list directly, avoiding the shell, in
P4Submit and P4Sync. The overhead of starting extra
processes is significant in cygwin; this speeds things
up on that platform.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a
Signed-off-by: Pete Wyckoff
---
git-p4.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/git-p4.py b/git-p4.py
index c8ae83d..7efa9a8 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -571,7 +571,8 @@ def gitConfig(key, args = None): # set args to "--bool",
for instance
def gi
Signed-off-by: Pete Wyckoff
---
git-p4.py | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 7efa9a8..ff3e8c9 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -560,13 +560,16 @@ def gitBranchExists(branch):
return proc.wait() == 0;
_g
Make the intent of "--bool" more obvious by returning a direct True
or False value. Convert a couple non-bool users with obvious bool
intent.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 45 ++---
1 file changed, 26 insertions(+), 19 deletions(-)
diff --g
On Sat, Jan 26, 2013 at 7:15 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> @@ -44,19 +46,9 @@ valid_tool () {
>> }
>>
>> setup_tool () {
>> - case "$1" in
>> - vim*|gvim*)
>> - tool=vim
>> - ;;
>> - *)
>> - tool="$1"
>> - ;;
>
David Aguilar writes:
> I have a question. John mentioned that we can replace the use of
> "$(..)" with $(..) in shell.
I think it isn't so much about $(...) but more about quoting the RHS
of assignment.
Consider these:
var="$another_var"
var="$(command)"
var="$one_var$
On 01/26/2013 10:44 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> Junio, can you replace the queued 0846b0c (git-remote-testpy: hash bytes
>> explicitly) with this?
>>
>> I hadn't realised that the "hex" encoding we chose before is a "bytes to
>> bytes" encoding so it just fails with an e
John Keeping writes:
> I'm not sure creating an 'include' directory actually buys us much over
> declaring that 'vimdiff' is the real script and the others just source
> it.
Is 'include' really used for such a purpose? It only houses defaults.sh
as far as I can see.
As that defaults.sh file is
On Sat, Jan 26, 2013 at 8:57 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> I'm not sure creating an 'include' directory actually buys us much over
>> declaring that 'vimdiff' is the real script and the others just source
>> it.
>
> Is 'include' really used for such a purpose? It only hou
Michael Haggerty writes:
> This will still fail under Python 2.x if repo.path is a byte string that
> contains non-ASCII characters. And it will fail under Python 3.1 and
> later if repo.path contains characters using the surrogateescape
> encoding option [1],...
> Here you don't really need byt
On Sat, Jan 26, 2013 at 8:44 PM, Michael Haggerty wrote:
> So to handle all of the cases across Python versions as closely as
> possible to the old 2.x code, it might be necessary to make the code
> explicitly depend on the Python version number, like:
Does this all go away if we restrict ourselv
Jeff King writes:
> My HEAD has about 400/3000 non-unique commits, which matches your
> numbers percentage-wise. Dropping the lines above (and always freeing)
> takes my best-of-five for "git log -g" from 0.085s to 0.080s. Which is
> well within the noise. Doing "git log -g Makefile" ended up at
On Sat, Jan 26, 2013 at 9:07 PM, David Aguilar wrote:
> On Sat, Jan 26, 2013 at 8:57 PM, Junio C Hamano wrote:
>> John Keeping writes:
>>
>>> I'm not sure creating an 'include' directory actually buys us much over
>>> declaring that 'vimdiff' is the real script and the others just source
>>> it.
David Aguilar writes:
>> I think that's much better.
>
> Would you like me to put this together into a proper patch?
>
> You can also squash it in (along with a removal of the
> last line of the commit message) if you prefer.
I was lazy and didn't want to think about rewriting your log
message,
Jeff King writes:
> This is a repost from here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/211176
>
> which got no response initially. Basically the issue is that read-only
> repos (e.g., a CI server) whose workflow is something like:
>
> git fetch $some_branch &&
> git chec
On 26.01.13 22:43, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Do we really need "which" to detect if frotz is installed?
> I think we all know the answer to that question is no, but why is
> that a relevant question in the context of this discussion? One of
> us may be very confus
check-non-portable-shell.pl is using simple regular expressions to
find illegal shell syntax.
Improve the expressions and reduce the chance for false positves:
"sed -i" must be followed by 1..n whitespace and 1 non whitespace
"declare" must be followed by 1..n whitespace and 1 non whitespace
"ech
70 matches
Mail list logo