Users may set test_cmp to a comparison tool of their liking. The intent is
that the tool performs comparison of line-oriented texts. However, t5300
uses it also to compare binary data. Change those tests to use 'cmp'.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/t5300-pack-object.sh | 10
a diff tool that undoes the converted CRLF. To avoid that
sub-processes are spawned (which is very slow on Windows), the tool is
implemented as a shell function. Diff is invoked as usual only when a
difference is detected by the shell code.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/test-lib
Am 10/24/2013 22:04, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
That said, I don't think that --change-id option that the user must not
forget to use is any better than a hook that the user must not forget to
install.
That is why I said this in my first response
Am 10/25/2013 0:21, schrieb Junio C Hamano:
+test_expect_success 'using reflog to find the fork point' '
+ git reset --hard
+ git checkout -b base $E
+
+ for count in 1 2 3 4 5
+ do
+ git commit --allow-empty -m Base commit #$count
+ git rev-parse
Am 10/25/2013 10:09, schrieb John Keeping:
On Fri, Oct 25, 2013 at 09:12:10AM +0200, Johannes Sixt wrote:
You could put the loops into a function from which you 'return', but that
is obscure in this case. The first iteration was better, IMO.
Wouldn't it be simpler to just return from
Am 10/24/2013 7:25, schrieb Duy Nguyen:
On Thu, Oct 24, 2013 at 11:11 AM, Nasser Grainawi nas...@codeaurora.org
wrote:
It is not clear to me how you envision to make it work.
I don't have the source code.
Now you do:
Am 21.10.2013 03:31, schrieb Duy Nguyen:
On Mon, Oct 21, 2013 at 12:57 AM, Antoine Pelisse apeli...@gmail.com wrote:
My main motive was to not *stop* the process when a long path is met.
Because somebody created a repository on Linux with a long file-name
doesn't mean you should not be able to
Am 10/16/2013 1:57, schrieb Jonathan Nieder:
Junio C Hamano wrote:
You just made these two that the user clearly meant to express two
different things indistinguishable.
opt.sh -S
opt.sh -S ''
[...]
And that is exactly why gitcli.txt tells users to use the 'sticked'
form, and
Am 10.10.2013 17:52, schrieb Sebastian Schuberth:
Hi again,
the problem can also be reproduced in an easier way, independently of
mingwGitDevEnv and using the mingw_path function instead of
relative_path. If I install msysGit 1.8.4 from [1] and run
test-path-utils I get this on Windows
Am 10.10.2013 21:47, schrieb Sebastian Schuberth:
So the obvious thing would be to replace /a/b/ with
/foo/bar/ in the tests, but that just masks the problem, or?
The strange behavior is not a problem in Git, it is a problem of MSYS.
Using /foo/bar instead of /a/b in Git's test suite is a
Am 10/9/2013 12:32, schrieb Paolo Giarrusso:
On Wed, Oct 9, 2013 at 12:20 PM, Tay Ray Chuan rcta...@gmail.com wrote:
On Wed, Oct 9, 2013 at 11:57 AM, Paolo G. Giarrusso
p.giarru...@gmail.com wrote:
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index
Am 9/27/2013 14:10, schrieb Ramkumar Ramachandra:
+ else if (!strcmp(formatp, track)
+ !prefixcmp(name, upstream)) {
+ char buf[40];
+
+ if (!upstream_present)
+
Am 21.09.2013 13:47, schrieb Felipe Contreras:
diff --git a/Makefile b/Makefile
index 3588ca1..18081bf 100644
--- a/Makefile
+++ b/Makefile
@@ -1010,7 +1010,7 @@ ifndef sysconfdir
ifeq ($(prefix),/usr)
sysconfdir = /etc
else
-sysconfdir = etc
+sysconfdir = $(prefix)/etc
Not good:
From: Johannes Sixt j...@kdbg.org
Provide PRId64 alongside PRIuMAX.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
I thought I had compiled 'next' on Windows recently...
This is an emergency fix for a compile error in 'master'.
compat/mingw.h | 1 +
1 file changed, 1 insertion(+)
diff
Am 19.09.2013 15:39, schrieb Ralf Baechle:
The original patch that introduced the symlink with the \n is kernel
commit 3b29aa5ba204c62b3ec8f9f5b1ebd6e5d74f75d3 and is archived in
patchwork at http://patchwork.linux-mips.org/patch/5745/ The patch
file contains a \n at the end - but one would
Am 17.09.2013 10:24, schrieb Jiang Xin:
I have checked the behavior of UNC path on Windows (msysGit):
* I can cd to a UNC path:
cd //server1/share1/path
* can cd to other share:
cd ../../share2/path
* and can cd to other server's share:
cd ../../../server2/share/path
Am 9/12/2013 1:32, schrieb Junio C Hamano:
* jc/ref-excludes (2013-09-03) 2 commits
- document --exclude option
- revision: introduce --exclude=glob to tame wildcards
People often wished a way to tell git log --branches (and git
log --remotes --not --branches) to exclude some local
Am 12.09.2013 16:13, schrieb Torsten Bögershausen:
On 2013-09-12 11.12, Jiang Xin wrote:
+static int have_same_root(const char *path1, const char *path2)
+{
+int is_abs1, is_abs2;
+
+is_abs1 = is_absolute_path(path1);
+is_abs2 = is_absolute_path(path2);
+return (is_abs1
Am 12.09.2013 11:12, schrieb Jiang Xin:
Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
It will make git_dir shorter only if git_dir is inside work_tree,
and this will increase performance. But my last refactor effort on
relative_path function (commit
Am 12.09.2013 21:24, schrieb John Keeping:
This allows us to correctly removing trailing backslashes on Windows
when checking for submodules.
Signed-off-by: John Keeping j...@keeping.me.uk
---
pathspec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/pathspec.c
Am 9/12/2013 17:24, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
Am 9/12/2013 1:32, schrieb Junio C Hamano:
* jc/ref-excludes (2013-09-03) 2 commits
Thanks for a dose of sanity. I didn't look at rev-parse. I vaguely
recall somebody offered follow-ups (was it you
Am 10.09.2013 21:13, schrieb John Keeping:
When using tab-completion, a directory path will often end with a
trailing slash which currently confuses git rm when dealing with
submodules. Now that we have parse_pathspec we can easily handle this
by simply adding the
Am 10.09.2013 15:14, schrieb Tvangeste:
After bisecting this problem I ended up with the mentioned commit
that completely breaks git-svn for me on Windows (mingw/msys version).
==
# git svn rebase
warning: unable to access '': Invalid argument
warning: unable to access '': Invalid
Am 11.09.2013 05:19, schrieb Jiang Xin:
I tested 'relative_path' function using 'test-path-utils', and got the
following result:
$ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
../../../C:/a/b
$ ./test-path-utils relative_path '/a/b' 'x/y'
../..//a/b
$
Am 9/5/2013 23:43, schrieb Eyal Zinder:
I'm trying to setup a distributed development repository with a central
repository acting as the production copy. I'm doing so on a Windows
file share with no SSH / HTTP accessibility. Basically each developer
will have their own copy of the project,
Am 9/2/2013 10:54, schrieb Joergen Edelbo:
Changes done:
Remove selection of branches to push - push always HEAD.
This can be justified by the fact that this far the most
common thing to do.
What are your plans to support a topic-based workflow? Far the most
common thing to happen is that
Am 9/5/2013 11:18, schrieb Jørgen Edelbo:
Forgetting to push something that you have just
completed is very far from what I am used to.
Forgetting to push is just one of many reasons why a branch that is not
equal to HEAD is not yet pushed... The new restriction is just too tight.
-- Hannes
From: Johannes Sixt j...@kdbg.org
Back in 21e9757e (Hack git-add--interactive to make it work with
ActiveState Perl, 2007-08-01), the invocation of external commands was
changed to use qx{} on Windows. The rationale was that the command
interpreter on Windows is not a POSIX shell, but rather
Am 03.09.2013 18:03, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
So I like the relative simplicity of this approach. Here is a bit of
documentation.
Oh, thanks for helping. An example or two may also help, and using
your original I have branches and wip/ situation would
Am 8/31/2013 21:27, schrieb Felipe Contreras:
On Fri, Aug 30, 2013 at 2:56 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 8/30/2013 8:32, schrieb Junio C Hamano:
If you have a history where
- branches master and maint point at commit A;
- branch next points at commit B
Am 8/31/2013 23:26, schrieb Felipe Contreras:
+--except::
+ Skip the following object names. For example:
+ '--branches --except master' will show all the branches, except master.
+ This differs from --not in that --except will still show the object, if
+ they are referenced
Am 9/1/2013 4:08, schrieb Nguyễn Thái Ngọc Duy:
git-add--interactive.perl rejects arguments with colons in 21e9757
(Hack git-add--interactive to make it work with ActiveState Perl -
2007-08-01). Pathspec magic starts with a colon, so it won't work if
these pathspecs are passed to
Am 9/2/2013 11:30, schrieb Duy Nguyen:
On Mon, Sep 02, 2013 at 08:42:18AM +0200, Johannes Sixt wrote:
Am 9/1/2013 4:08, schrieb Nguyễn Thái Ngọc Duy:
git-add--interactive.perl rejects arguments with colons in 21e9757
(Hack git-add--interactive to make it work with ActiveState Perl -
2007-08
---
Subject: [PATCH] document --exclude option
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Documentation/rev-list-options.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 5bdfb42..650c252
Am 8/30/2013 8:32, schrieb Junio C Hamano:
If you have a history where
- branches master and maint point at commit A;
- branch next points at commit B that is a descendant of A; and
- there are tags X and Y pointing at commits that are ahead of B
or behind A
i.e.
Am 8/30/2013 9:32, schrieb Felipe Contreras:
On Fri, Aug 30, 2013 at 2:26 AM, Junio C Hamano gits...@pobox.com wrote:
On Aug 30, 2013 12:19 AM, Felipe Contreras felipe.contre...@gmail.com
Would the same argument apply to
next ^maint --except maint
where next gets in the queue, maint in
With nd/magic-pathspec I get the following failure on Windows in
t2016-checkout-patch.sh:
expecting success:
set_state dir/foo work head
# the third n is to get out in case it mistakenly does not apply
(echo y; echo n; echo n) | (cd dir git checkout -p foo)
Am 8/27/2013 23:48, schrieb Jeff King:
The counterarguments I can see are:
1. Who cares? If you want to know whether pack-objects will choke on
your huge config value, then run pack-objects.
2. Such a check would involve knowing which type we use internally to
look at
Am 8/28/2013 10:32, schrieb Matthieu Moy:
Historically, git status needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when git status is ran from the
command-line, and this may distract users
Am 26.08.2013 21:56, schrieb Jeff King:
Also, prevent the delimiter being added twice, as happens now in these
examples:
git grep -l foo HEAD:
HEAD::some/path/to/foo.txt
^
Which one of these two does it print then?
HEAD:/some/path/to/foo.txt
HEAD:some/path/to/foo.txt
Am 25.08.2013 15:06, schrieb Christian Couder:
@@ -100,6 +101,15 @@ static int replace_object(const char *object_ref, const
char *replace_ref,
if (check_refname_format(ref, 0))
die('%s' is not a valid ref name., ref);
+ obj_type = sha1_object_info(object, NULL);
+
Am 25.08.2013 15:06, schrieb Christian Couder:
+test_expect_success 'replaced and replacement objects must be of the same
type' '
+ test_must_fail git replace mytag $HASH1 2err
+ grep Object ref '\''mytag'\'' is of type '\''tag'\'' err
Uh, this hurts in the eye! Please write this
Am 25.08.2013 21:44, schrieb Christian Couder:
What about:
die(Objects must be of the same type.\n
'%s' points to a replaced object of type '%s'\n
while '%s' points to a replacement object of type '%s'.,
Much better!
-- Hannes
--
To
Am 23.08.2013 01:14, schrieb Jeff King:
+++ b/t/t5308-pack-detect-duplicates.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+test_description='handling of duplicate objects in incoming packfiles'
+. ./test-lib.sh
+. ../lib-pack.sh
This should be
. $TEST_DIRECTORY/lib-pack.sh
to support running tests with
Am 22.08.2013 00:15, schrieb Stefan Beller:
On 08/21/2013 10:56 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
+static int delta_base_offset = 1;
+char *packdir;
Does this have to be global?
As the path is pretty obvious (get_object_directory() + /pack),
we
Am 21.08.2013 10:49, schrieb Matthieu Moy:
Stefan Beller stefanbel...@googlemail.com writes:
+ for_each_string_list_item(item, names) {
+ for (ext = 0; ext 2; ext++) {
+ char *fname, *fname_old;
+ fname = mkpathdup(%s/%s%s,
Am 21.08.2013 15:07, schrieb Matthieu Moy:
Stefan Beller stefanbel...@googlemail.com writes:
But as these follow up changes heavily rely on the very first patch
I will first try to get that right, meaning accepted into pu.
Then I can send patches with these proposals such as making more
Am 21.08.2013 00:36, schrieb Stefan Beller:
I think I got all the suggestions except the
use of git_path/mkpathdup.
I replaced mkpathdup by mkpath where possible,
but it's still not perfect.
I'll wait for the dokumentation patch of Jonathan,
before changing all these occurences forth and back
I didn't look at functions above cmd_repack.
Am 20.08.2013 01:23, schrieb Stefan Beller:
+int cmd_repack(int argc, const char **argv, const char *prefix) {
+
+ int pack_everything = 0;
+ int pack_everything_but_loose = 0;
+ int delete_redundant = 0;
+ char
Am 20.08.2013 17:00, schrieb Junio C Hamano:
I wonder if there are more like this broken caller or xread and/or
xwrite.
Looking at the grep -C1 output, there are no others.
The only one that looked suspicious was xread in remote-curl.c, but it is
fine (it just eats all data from the input).
Am 20.08.2013 17:16, schrieb Antoine Pelisse:
I was actually wondering when it's better to use xread() over
read_in_full() ? Considering that we don't know if xread() will read
the whole buffer or not, would it not be better to always use
read_in_full() ?
Of course, you know whether the whole
Am 20.08.2013 17:08, schrieb Stefan Beller:
On 08/20/2013 03:31 PM, Johannes Sixt wrote:
You cannot run_command() and then later read its output! You must split
it into start_command(), read stdout, finish_command().
Thanks for this hint. Could that explain rare non-deterministic failures
Am 20.08.2013 20:52, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
I wonder if there are more like this broken caller or xread and/or
xwrite.
Here is a result of a quick audit (of 1.8.0.x codebase).
As xwrite() will not be splitting a single-byte request, the patch
to
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
+test_expect_success EXPENSIVE 'filter large file' '
+ git config filter.largefile.smudge cat
+ git config filter.largefile.clean cat
+ for i in $(test_seq 1 2048); do printf %1048576d 1; done 2GB
Shouldn't you count to 2049
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
Note that 'git add' exits with 0 even if it prints filtering errors to
stderr. The test, therefore, checks stderr. 'git add' should probably
be changed (sometime in another commit) to exit with nonzero if
filtering fails. The test could then be
Am 19.08.2013 10:25, schrieb Stefan Beller:
On 08/19/2013 10:20 AM, Johannes Sixt wrote:
Am 19.08.2013 08:38, schrieb Steffen Prohaska:
+test_expect_success EXPENSIVE 'filter large file' '
+git config filter.largefile.smudge cat
+git config filter.largefile.clean cat
+for i
Am 16.08.2013 00:36, schrieb Junio C Hamano:
Due to unfortunate regressions, two topics had to be reverted:
* An attempted fix to git stash save, to detect that going back
to the state of the HEAD needs to lose killed files, and/or
untracked files in a killed directory, to prevent the
Am 17.08.2013 14:40, schrieb Steffen Prohaska:
Previously, filtering more than 2GB through an external filter (see
test) failed on Mac OS X 10.8.4 (12E55) with:
error: read from external filter cat failed
error: cannot feed the input to external filter cat
error: cat died of
Am 16.08.2013 12:36, schrieb SZEDER Gábor:
+repo_with_newline='repo
+with
+newline'
+
+test_expect_success 'prompt - with newline in path' '
This test must be skipped when the filesystem does not support LF in file
names. Cf. the FUNNYNAMES prerequisite in t3600-rm.sh.
+ printf
Am 14.08.2013 20:05, schrieb Junio C Hamano:
Stefano Lattarini stefano.lattar...@gmail.com writes:
My problems is that some new automagical interpretation of the bare
@' character (introduced after 1.8.3) has destroyed my use case:
...
I don't want to ask you to revert this new behaviour, but
Am 8/8/2013 23:11, schrieb Phil Hord:
On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson ag4ve...@gmail.com wrote:
On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 8/7/2013 8:24, schrieb shawn wilson: ... create a repo for one of
these scripts and I'd like to keep
Am 8/9/2013 8:33, schrieb shawn wilson:
On Fri, Aug 9, 2013 at 2:25 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 8/8/2013 23:11, schrieb Phil Hord:
On Wed, Aug 7, 2013 at 5:07 PM, shawn wilson ag4ve...@gmail.com wrote:
On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt j.s...@viscovery.net
Am 8/9/2013 12:03, schrieb shawn wilson:
The question still stands though - why is that unassociated commit left there?
Because your command did not remove it. filter-branch does not know that
it is unassociated when you ask it to follow all commits beginning at
HEAD. But when you say 'HEAD --
Am 8/7/2013 8:24, schrieb shawn wilson: ... create a repo for one of
these scripts and I'd like to keep the commit history.
Ok, so:
% find -type f ! -iname webban.pl | while read f; do git
filter-branch -f --index-filter git rm --cached --ignore-unmatch $f
HEAD ; done
Which basically did
Am 8/5/2013 16:23, schrieb Duy Nguyen:
close() is added in commit_lock_file(), before rename(), by 4723ee9
(Close files opened by lock_file() before unlinking. - 2007-11-13),
which is needed by Windows. But doesn't that create a gap between
close() and rename() on other platforms where another
Am 03.08.2013 08:21, schrieb Nguyễn Thái Ngọc Duy:
I changed mingw.h to add a stub uname() because I don't think MinGW
port has that function, but that's totally untested.
Thanks, but we don't have kill(pid, 0), either :-(
-- Hannes
--
To unsubscribe from this list: send the line
Am 03.08.2013 12:01, schrieb Duy Nguyen:
On Sat, Aug 03, 2013 at 11:49:02AM +0200, Johannes Sixt wrote:
Am 03.08.2013 08:21, schrieb Nguyễn Thái Ngọc Duy:
I changed mingw.h to add a stub uname() because I don't think MinGW
port has that function, but that's totally untested.
Thanks, but we
Am 7/25/2013 10:03, schrieb Eric Sunshine:
The tests in this series identify real bugs in dealing with empty
ranges, which the subsequent patches fix. The test are possible
because one can specify an empty range via blame/log -L, however, I
now realize that the ability for -L to create empty
Am 7/19/2013 11:21, schrieb Allan Acheampong:
Something like 'git clone theRepo -createLocalBranchesForAllBranches'
Perhaps:
$ git clone theRepo
$ git fetch origin refs/heads/*:refs/heads/*
(untested). There may be ways to write the same shorter, but I've lost
track of what is and what is not
Am 7/15/2013 19:48, schrieb Greg Troxel:
Clearly there is the possibility of creating a corrupt repository when
receiving objects and updating refs, if a crash or power failure causes
data not to get written to disk but that data is pointed to. Journaling
mitigates this, but I'd argue that
I question the value of this warning. Initialization with '=
{0}' is a well-established idiom, and sparse should know about
it.
Thanks everyone for your feedback. But I really wanted to call only the
warning in the case of the '= {0}' idiom into question, not about 0 vs.
NULL in general.
--
Am 15.07.2013 05:50, schrieb Junio C Hamano:
... or also with your --lockref is default
$ git push origin +master
... rejected due to stale expectation
$ git fetch
You just have updated the lockref base, so if you did, without doing
anything else,
$
Am 14.07.2013 22:59, schrieb Johannes Sixt:
... I wonder how Junio's last
example with push.default=simple can work today:
$ git pull --rebase # not a merge
$ git push
because it is not a fast-forward.
*blush* I was mostly asleep and and totally off the rails when I wrote
Am 7/15/2013 19:31, schrieb Ramsay Jones:
Sparse issues three Using plain integer as NULL pointer warnings.
Each warning relates to the use of an '{0}' initialiser expression
in the declaration of an 'struct object_info'.
I question the value of this warning. Initialization with '= {0}' is a
Am 14.07.2013 21:17, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
I actually think that by implying allow-no-ff in --lockref, you are
hurting users who have configured a push refspec without a + prefix:
They suddenly do not get the push denied when it is not a fast-forward
Am 14.07.2013 22:34, schrieb Jonathan Nieder:
Johannes Sixt wrote:
Sorry, IMO, this goes into a totally wrong direction, in particular, I
think that this is going to close to door to make --lockref the default
some day in a way that helps everyone.
Would a '*' that acts like --lockref
Am 12.07.2013 23:19, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
We have three independent options that the user can choose in any
combination:
o --force given or not;
o --lockref semantics enabled or not;
o refspec with or without +;
and these two orthogonal
Am 13.07.2013 22:08, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
If --lockref automatically implies --allow-no-ff (the design in
the reposted patch), you cannot express that combination. But once
you use --lockref in such a situation , for the push to succeed,
you know
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
configuration that says something like:
[remote ko]
url
Am 12.07.2013 19:40, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Am 12.07.2013 00:14, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Again: Why not just define +refspec as the way to achieve this check?
What justification do we have to break existing people's
Am 10.07.2013 01:08, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
I _think_ I am OK if we introduced --allow-no-ff that means the
current --force (i.e. rewinding is OK), that does not defeat the
--lockref safety. That is the intended application (you know that
push does
Am 09.07.2013 21:53, schrieb Junio C Hamano:
+--lockref::
+--lockref=refname::
+--lockref=refname:expect::
...
+This is meant to make `--force` safer to use.
This is a contradiction. --force means I mean it, dude, and not I
mean it sometimes. It would make sense if this sentence were This is
Am 09.07.2013 22:37, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
Am 09.07.2013 21:53, schrieb Junio C Hamano:
+--lockref::
+--lockref=refname::
+--lockref=refname:expect::
...
+This is meant to make `--force` safer to use.
This is a contradiction. --force means I mean
Am 7/3/2013 21:53, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
I don't think that is necessary. We already have *two* options to
force-push a ref: the + in front of refspec, and --force.
They mean exactly the same thing; the only difference being that +
prefix
this patch. (There are trivial conflicts when 5/5 is applied on
top.) Notice the comment I added in test case 'left alignment formatting
with ltrunc'.
Signed-off-by: Johannes Sixt j...@kdbg.org
To be squashed into v8 4/5:
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index
Am 7/2/2013 0:50, schrieb Alexey Shumkin:
On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
Am 6/26/2013 12:19, schrieb Alexey Shumkin:
test_expect_success 'setup complex body' '
git config i18n.commitencoding iso8859-1
echo change2 foo git commit -a -F commit-msg
Am 5/24/2013 1:23, schrieb Alois Mahdal:
...query for when the file was really added,
which I was trying to achieve with
$ git -1 --reverse --follow several_times_renamed_file
Assuming you meant 'git log -1 ...' or similar. It won't do what you think
it would do because:
* -1 is a
Am 6/26/2013 12:19, schrieb Alexey Shumkin:
One can set an alias
$ git config alias.lg log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)%an%Creset'
--abbrev-commit --date=local
to see the log as a pretty tree (like *gitk* but in
Am 27.06.2013 14:47, schrieb Sebastian Schuberth:
diff --git a/git-archimport.perl b/git-archimport.perl
index 9cb123a..ed2c741 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
...
@@ -477,8 +477,8 @@ sub process_patchset_fast {
unlink @$del;
while (@$del) {
Am 25.06.2013 00:10, schrieb Junio C Hamano:
Mark Levedahl mleved...@gmail.com writes:
On 06/22/2013 03:38 PM, Ramsay Jones wrote:
Also, apart from running the git test-suite, I have the Win32
l/stat functions disabled on all of my repos. In particular, I have
core.filemode set to true. (At
Am 24.06.2013 17:21, schrieb Jiang Xin:
Add new subcommand mingw_path in test-path-utils, so that we can get
the expected absolute paths on Windows. For example:
COMMAND LINELinux Windows
== = ===
Am 22.06.2013 00:32, schrieb Junio C Hamano:
Ramkumar Ramachandra artag...@gmail.com writes:
Replace the 'git config' calls in tests with test_config for greater
robustness.
That may be a good thing in principle, but I _think_
mk_empty testrepo
(
cd
Am 6/20/2013 9:56, schrieb Peter Krefting:
Junio C Hamano:
But my understanding is that the reordering using printf() is the
mechanism we suggest l10n folks to use when the order of parameters
given to printf does not match the preferred word order in the message
in their language.
It's
Am 6/20/2013 20:11, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
But you can't have this string:
Splitting a commit while rebasing branch '%2$s' on '%3$s'.
neither in the template nor in the translation, because the numbers must
begin at 1 (and must be used without
Am 6/19/2013 8:09, schrieb Ramkumar Ramachandra:
Johannes Sixt wrote:
I haven't followed the topic closely, but I wonder why there are so many
explicit assignments to GIT_REFLOG_ACTION. Is calling set_reflog_action
(defined in git-sh-setup) the wrong thing to do?
Does this answer your
Am 6/19/2013 10:04, schrieb Ramkumar Ramachandra:
+test_expect_failure 'checkout - works after a rebase -i A B' '
+ git branch foodle master~1
+ git checkout master
+ git checkout other
+ git rebase master foodle
git rebase -i master foodle
+ git checkout -
Am 6/17/2013 11:18, schrieb Thomas Rast:
+match_pattern_list () {
+ arg=$1
+ shift
+ test -z $* return 1
+ for pat
+ do
+ case $arg in
+ $pat)
+ return 0
+ esac
+ done
+ return 1
+}
Watch this
From: Johannes Sixt j...@kdbg.org
The recently introduced tests used uppercase letters to denote
cherry-picks of commits having the corresponding lowercase letter names.
The helper functions also set up tags with the names of the commits.
But this constellation fails on case-insensitive file
Am 6/18/2013 20:55, schrieb Ramkumar Ramachandra:
Now that the checkout invoked internally from rebase knows to honor
GIT_REFLOG_ACTION, we can start to use it to write a better reflog
message when rebase anotherbranch, rebase --onto branch,
etc. internally checks out the new fork point. We
Am 6/18/2013 17:53, schrieb Martin von Zweigbergk:
On Tue, Jun 18, 2013 at 12:28 AM, Johannes Sixt j.s...@viscovery.net wrote:
Knowing that the tests would take their time to complete on Windows,
I'm curious just how slow it is. Are we talking minutes?
D:\Src\mingw-git\tbash -c time make
801 - 900 of 1147 matches
Mail list logo
