On Tue, Jan 15, 2013 at 11:38:32AM +0700, Duy Nguyen wrote:
> dirlen is not expected to include the trailing slash, but
> find_basename() does that. It messes up with the path filters for
> push/pop in the next code. This brings grep performance closely back
> to before for me. Ross, can you check
- Ursprungligt meddelande -
> Robin Rosenberg writes:
>
> > Semantically they're somewhat different. My flags are for ignoring
> > a value when it's not used as indicated by the value zero, while
> > trustctime is for ignoring untrustworthy, non-zero, values.
>
> Yeah, I realized that
Am 1/15/2013 1:11, schrieb Junio C Hamano:
> I'd say a simplistic "ignore if zero is stored" or even "ignore this
> as one of the systems that shares this file writes crap in it" may
> be sufficient, and if this is a jGit specific issue, it might even
> make sense to introduce a single configuratio
Chris Rorvick writes:
[jc: please elide parts you are not responding to, leaving enough
lines to understand the context]
>> +def command(self):
>> +"Emit the command implied by all previous options."
>> +return self.cvsps + "--fast-export " + self.opts
>
> "--fast-export" str
Junio C Hamano writes:
> Jardel Weyrich writes:
>
>> If you allow me, I'd like you to forget about the concepts for a minute, and
>> focus on the user experience.
>> Imagine a simple hypothetical scenario in which the user wants to push to 2
>> distinct repositories. He already has cloned the
Jardel Weyrich writes:
> If you allow me, I'd like you to forget about the concepts for a minute, and
> focus on the user experience.
> Imagine a simple hypothetical scenario in which the user wants to push to 2
> distinct repositories. He already has cloned the repo from the 1st
> repository,
On Sun, Jan 13, 2013 at 7:40 PM, Junio C Hamano wrote:
> The new cvsps 3.x series lacks support of some options cvsps 2.x
> series had and used by cvsimport-2; add a replacement program from
> the author of cvsps 3.x and allow users to choose it by setting the
> GIT_CVSPS_VERSION environment varia
Throughout most of parse_args(), the variable 'i' remains at 0. Many
references are still made to the variable even when it could only have
the value 0. This made at least me, who has relatively little
experience with C programming styles, think that parts of the function
was meant to be part of a
On Mon, Jan 14, 2013 at 9:02 PM, Junio C Hamano wrote:
> I converted one of Chris's follow-up test tweaks to this to
> illustrate how it can be done without breaking tests for the
> original cvsimport, but didn't do all of them. Chris, is this a
> foundation we can work together on top?
Sure, lo
Use a single condition to guard the call to die_if_unmerged_cache for
both --soft and --keep. This avoids the small distraction of the
precondition check from the logic following it.
Also change an instance of
if (e)
err = err || f();
to the almost as short, but clearer
if (e && !err)
The final part of cmd_reset() essentially looks like:
if (pathspec) {
...
read_from_tree(...);
} else {
...
reset_index(...);
update_index_refresh(...);
...
}
where read_from_tree() internally also calls
update_index_refresh(). Move the call to update_index_refresh()
Changes since v1:
- Spelling fixes.
- Explained how "git reset -- $pathspec" in bare repo is broken.
- Provided motivation for replacement of switch by if-else
- Fixed argv/argc handling by removing use of argc.
- Replaced "don't refresh index on --quiet" patch by one that just
inlines
"git reset --keep" calls reset_index_file() twice, first doing a
two-way merge to the target revision, updating the index and worktree,
and then resetting the index. After each call, we write the index
file.
In the unlikely event that the second call to reset_index_file()
fails, the index will hav
By extracting the code for updating the HEAD and ORIG_HEAD symbolic
references to a separate function, we declutter cmd_reset() a bit and
we make it clear that e.g. the four variables {,sha1_}{,old_}orig are
only used by this code.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 39 ++
Now that there is only one caller left to the single-line method
update_index_refresh(), inline it.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index c316d9b..520c1a5
The switch statement towards the end of reset.c is missing case arms
for KEEP and MERGE for no obvious reason, and soon the only non-empty
case arm will be the one for HARD. So let's proactively replace it by
if-else, which will let us move one if statement out without leaving
funny-looking left-ov
Declutter cmd_reset() a bit by moving out the argument parsing to its
own function.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 70 +++--
1 file changed, 38 insertions(+), 32 deletions(-)
diff --git a/builtin/reset.c b/builtin/r
If writing or committing the new index file fails, we print "Could not
write new index file." followed by "Could not reset index file to
revision $rev.". The first message seems to imply the second, so print
only the first message.
Signed-off-by: Martin von Zweigbergk
---
builtin/reset.c | 8 +++
When doing a mixed reset without paths, the index is locked, read,
reset, and written back as part of the actual reset operation (in
reset_index()). Then, when showing the list of worktree modifications,
we lock the index again, refresh it, and write it.
Change this so we only write the index once
By not returning from inside the "if (pathspec)" block, we can let the
pathspec-aware and pathspec-less code share a bit more, making it
easier to make future changes that should affect both cases. This also
highlights the similarity between read_from_tree() and reset_index().
Signed-off-by: Marti
In preparation for the/a following patch, move the locking, writing
and committing of the index file out of update_index_refresh(). The
code duplication caused will soon be taken care of. What remains of
update_index_refresh() is just one line, but it is still called from
two places, so let's leave
Thanks to b65982b (Optimize "diff-index --cached" using cache-tree,
2009-05-20), resetting with paths is much faster than resetting
without paths. Some timings for the linux-2.6 repo to illustrate this
(best of five, warm cache):
reset reset .
real0m0.219s0m0.080s
user0m0
Some users seem to think, knowingly or not, that being on an unborn
branch is like having a commit with an empty tree checked out, but
when run on an unborn branch, "git reset" currently fails with:
fatal: Failed to resolve 'HEAD' as a valid ref.
Instead of making users figure out that they sho
Resetting with paths does not update HEAD and there is nothing else
that a commit should be needed for. Relax the argument parsing so only
a tree is required.
The sha1 is only passed to read_from_tree(), which already only
requires a tree.
The "rev" variable we pass to run_add_interactive() will
Since 34110cd (Make 'unpack_trees()' have a separate source and
destination index, 2008-03-06), the index no longer gets clobbered by
do_diff_cache() and we can remove the code for discarding and
re-reading it.
There are two paths to update_index_refresh() from cmd_reset(), but on
both paths, eith
"git reset $pathspec" currently exits with a non-zero exit code if the
worktree is dirty after resetting, which is inconsistent with reset
without pathspec, and it makes it harder to know whether the command
really failed. Change it to exit with code 0 regardless of whether the
worktree is dirty so
We use the path arguments in two places in reset.c: in
interactive_reset() and read_from_tree(). Both of these call
get_pathspec(), so we pass the (prefix, argv) pair to both
functions. Move the call to get_pathspec() out of these methods, for
two reasons: 1) One argument is simpler than two. 2) It
Running e.g. "git reset ." in a bare repo results in an index file
being created from the HEAD commit. The differences compared to the
index are then printed as usual, but since there is no worktree, it
will appear as if all files are deleted. For example, in a bare clone
of git.git:
Unstaged ch
On 14/01/2013, at 17:09, Junio C Hamano wrote:
> Michael J Gruber writes:
>
>> It seems to me that everything works as designed, and that the man page
>> talk about "push URLs" can be read in two ways,...
>
> Hmph, but I had an impression that Jardel's original report was that
> one of the --a
On Tue, Jan 15, 2013 at 9:46 AM, Duy Nguyen wrote:
> I don't have time to look into details now, but by enabling
> DEBUG_ATTR, it looks like this commit makes it push and pop patterns a
> lot more than without the commit.
I think the culprit is at this chunk:
static void prepare_attr_stack(cons
Junio C Hamano writes:
> At least the attached patch is necessary.
Sorry, but the last hunk (see below) is not. It breaks the hook.
> In the longer term, we may want to discuss what should happen when
> the hook exited without even reading what we fed. My gut feeling is
> that we can still tr
Junio C Hamano writes:
> [New Topics]
>
> * jc/cvsimport-upgrade (2013-01-14) 8 commits
> - t9600: adjust for new cvsimport
> - t9600: further prepare for sharing
> - cvsimport-3: add a sample test
> - cvsimport: make tests reusable for cvsimport-3
> - cvsimport: start adding cvsps 3.x suppo
Commit 82dce99 (attr: more matching optimizations from .gitignore -
2012-10-15) changed match_attr structure but it did not update
DEBUG_ATTR-specific code. This fixes it.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
attr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/attr.c b/
Ross Lagerwall writes:
> I have noticed a performance regression in git grep between v1.8.1 and
> v1.8.1.1:
>
> On the kernel tree:
> For git 1.8.1:
> $ time git grep foodsgsg
>
> real 0m0.158s
> user 0m0.290s
> sys0m0.207s
>
> For git 1.8.1.1:
> $ time /tmp/g/bin/git grep foodsgsg
>
> re
On Tue, Jan 15, 2013 at 5:38 AM, Ross Lagerwall wrote:
> Hi,
>
> I have noticed a performance regression in git grep between v1.8.1 and
> v1.8.1.1:
>
> On the kernel tree:
> For git 1.8.1:
> $ time git grep foodsgsg
>
> real 0m0.158s
> user 0m0.290s
> sys0m0.207s
>
> For git 1.8.1.1:
> $ t
Johannes Schindelin writes:
> On Mon, 14 Jan 2013, Junio C Hamano wrote:
>
>> It appears that memcmp() uses the usual "one word at a time"
>> comparison and triggers valgrind in a callback of bsearch() used in
>> the refname search. I can easily trigger problems in any script
>> with test_commit
Happy ending!
Turns out i have actually made a backup 3 days ago.
My other work was on a branch + in a stash. Commits done on a branch
were already present in a backup.
I was able to get the stash working by copying corrupted .pack files
from the backup, luckily all the new work wasn't packed yet
It finds its upstream and applies the commit properly, but
the sync step will fail unless it is told which branch to
work on.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 5 +
git-p4.py | 6 +-
t/t9806-git-p4-options.sh | 25 +
3 f
Tests assume that this is set to something valid. Make sure
that the 'clone --use-client-spec' does not leak its changes
out into the rest of the tests.
Signed-off-by: Pete Wyckoff
---
t/t9806-git-p4-options.sh | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/t/t9806-g
It is legal to sync a branch with a different name than
refs/remotes/p4/master, and to do so even when master does
not exist.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 5 +
git-p4.py | 14 +++---
t/t9806-git-p4-options.sh | 8
3 files chan
If --branch was used to build a repository with no
refs/remotes/p4/master, future syncs will not know
which branch to sync. Notice this situation and
print a helpful error message.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 29 +++--
t/t9806-git-p4-optio
This was set in a couple of places, both of which were very
far away from its use. Move it a bit closer to importChanges(),
and add some comments.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/git-p4.py b/git-p4.py
ind
For a clone or sync, --branch says where the newly imported
branch should go, or which existing branch to sync up. It
takes an argument, which is currently either something that
starts with "refs/", or if not, "refs/heads/p4" is prepended.
Putting it in heads seems like a bad default; these shoul
Make sure that the example on how to use git-p4.branchList
works if typed directly. In particular, it does not make sense
to set a config variable until the git repository has been
initialized.
Reported-by: Olivier Delalleau
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 4 +++-
1
When using the --branch argument to "git p4 clone", one
might specify a destination for p4 changes different from
the default refs/remotes/p4/master. Both cases should
create a master branch and checkout files.
Signed-off-by: Pete Wyckoff
---
Documentation/git-p4.txt | 3 +--
git-p4.py
Make sure that the standard branches are created as expected.
Signed-off-by: Pete Wyckoff
---
t/t9800-git-p4-basic.sh | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh
index 8c59796..166e752 100755
--- a/t/t9800-git-p4-
There is code to create a symbolic reference from p4/HEAD to
p4/master. This allows saying "git show p4" as a shortcut
to "git show p4/master", for example.
But this reference was only created on the second "git p4 sync"
(or first sync after a clone). Make it work on the initial
clone or sync.
It is four lines of code used in only one place. Simplify by
including it where it is used.
Signed-off-by: Pete Wyckoff
---
git-p4.py | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 03680b0..8814049 100755
--- a/git-p4.py
+++ b/git-
Signed-off-by: Pete Wyckoff
---
git-p4.py | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 68f7458..03680b0 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -553,27 +553,36 @@ def gitConfigList(key):
_gitConfig[key] = re
Signed-off-by: Pete Wyckoff
---
git-p4.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 69f1452..68f7458 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -2754,23 +2754,23 @@ class P4Sync(Command, P4UserMap):
self.changeRange = "
Add failing tests to document behavior when there are multiple p4
branches, as created using the --branch option. In particular:
Using clone --branch populates the specified branch correctly, but
dies with an error when trying to checkout master.
Calling sync without a master branch dies with an
There are multiple oddities in how git-p4 treats multiple
p4 branches, as created with "clone" or "sync" and the
'--branch' argument. Olivier reported some of these recently
in http://thread.gmane.org/gmane.comp.version-control.git/212613
There are two observable behavior changes, but they
are in
> Is this "the user edits in eclipse and then runs 'git status' from
> the
> terminal" problem?
Yes. Of course not just status, but any command that validates
the index. On Unix this is usually bearable, though slow, but on
Windows I often see git status take minutes (yes large files...).
-- rob
Aaron Schrab writes:
> t/t5571-pre-push-hook.sh | 129
> +
> diff --git a/t/t5571-pre-push-hook.sh b/t/t5571-pre-push-hook.sh
> new file mode 100755
> index 000..d68fed7
> --- /dev/null
> +++ b/t/t5571-pre-push-hook.sh
> @@ -0,0 +1,129 @@
> +#!/b
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Aaron Schrab writes:
>>
>>> Main changes since the initial version:
>>>
>>> * The first patch converts the existing hook callers to use the new
>>>find_hook() function.
>>> * Information about what is to be pushed is now sent over a pip
Robin Rosenberg writes:
> Semantically they're somewhat different. My flags are for ignoring
> a value when it's not used as indicated by the value zero, while
> trustctime is for ignoring untrustworthy, non-zero, values.
Yeah, I realized that after writing that message.
> Another thing that I
Hi Junio,
On Mon, 14 Jan 2013, Junio C Hamano wrote:
> It appears that memcmp() uses the usual "one word at a time"
> comparison and triggers valgrind in a callback of bsearch() used in
> the refname search. I can easily trigger problems in any script
> with test_commit (e.g. "sh t0101-at-syntax
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Any stat checking by git will then need to check content,
which may be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if th
From: "George Karpenkov"
Sent: Monday, January 14, 2013 10:57 PM
Thanks everyone!
Progress so far:
After executing reverse sed command:
find .git -name '*.*' -exec sed -i 's//\t/g' {} \;
Have you counted how many substitutions there are in the pack file(s).
It may be sufficiently small
- Ursprungligt meddelande -
> Robin Rosenberg writes:
>
> > diff --git a/read-cache.c b/read-cache.c
> > index fda78bc..f7fe15d 100644
> > --- a/read-cache.c
> > +++ b/read-cache.c
> > @@ -197,8 +197,9 @@ static int ce_match_stat_basic(struct
> > cache_entry *ce, struct stat *st)
> >
It appears that memcmp() uses the usual "one word at a time"
comparison and triggers valgrind in a callback of bsearch() used in
the refname search. I can easily trigger problems in any script
with test_commit (e.g. "sh t0101-at-syntax.sh --valgrind -i -v")
without this suppression.
Signed-off-by
Thanks everyone!
Progress so far:
After executing reverse sed command:
find .git -name '*.*' -exec sed -i 's//\t/g' {} \;
And trying to switch the branch I get:
> git checkout X
error: failed to read object 51a980792f26875d00acb79a19f043420f542cfa
at offset 41433013 from
.git/objects/pack/
Junio C Hamano writes:
> Aaron Schrab writes:
>
>> Main changes since the initial version:
>>
>> * The first patch converts the existing hook callers to use the new
>>find_hook() function.
>> * Information about what is to be pushed is now sent over a pipe rather
>>than passed as comma
Hi,
I have noticed a performance regression in git grep between v1.8.1 and
v1.8.1.1:
On the kernel tree:
For git 1.8.1:
$ time git grep foodsgsg
real 0m0.158s
user 0m0.290s
sys0m0.207s
For git 1.8.1.1:
$ time /tmp/g/bin/git grep foodsgsg
real 0m0.501s
user 0m0.707s
sys0m0.493s
This fixes "hg" patch format support for locales other than C and en_*.
Before the change, git-am was making "Date:" line from hg changeset
metadata according to the current locale, and this line was rejected
later with "invalid date format" diagnostics because localized date
strings are not suppor
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
As usual, this cycle is expected to last for 8 to 10 weeks, with a
preview -rc0 sometime in the middle of next month.
You can find the changes
Robin Rosenberg writes:
> @@ -566,6 +566,31 @@ static int git_default_core_config(const char *var,
> const char *value)
> trust_ctime = git_config_bool(var, value);
> return 0;
> }
> + if (!strcmp(var, "core.ignorezerostat")) {
> + char *copy, *t
Robin Rosenberg writes:
> diff --git a/read-cache.c b/read-cache.c
> index fda78bc..f7fe15d 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -197,8 +197,9 @@ static int ce_match_stat_basic(struct cache_entry *ce,
> struct stat *st)
> }
> if (ce->ce_mtime.sec != (unsigned int)st-
"Dmitry V. Levin" writes:
> This fixes "hg" patch format support for locales other than C and en_*,
> see https://bugzilla.altlinux.org/show_bug.cgi?id=28248
>
> Signed-off-by: Dmitry V. Levin
> ---
Thanks.
The reference URL is not very friendly, and you should be able to
state it here on a si
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Any stat checking by git will then need to check content,
which may be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if th
This fixes "hg" patch format support for locales other than C and en_*,
see https://bugzilla.altlinux.org/show_bug.cgi?id=28248
Signed-off-by: Dmitry V. Levin
---
git-am.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-am.sh b/git-am.sh
index c682d34..64b88e4 100755
---
Michal Privoznik writes:
> +--diff-algorithm={patience|minimal|histogram|myers}::
> + Choose a diff algorithm. The variants are as follows:
> ++
> +--
> +`myers`;;
> + The basic greedy diff algorithm.
> +`minimal`;;
> + Spend extra time to make sure the smallest possible diff is
> +
Michal Privoznik writes:
> +static long parse_algorithm_value(const char *value)
> +{
> + if (!value || !strcasecmp(value, "myers"))
> + return 0;
[diff]
algorithm
should probably error out. Also it is rather unusual to parse the
keyword values case insensitively.
> +
On Mon, Jan 14, 2013 at 3:03 AM, Piotr Krukowiecki
wrote:
> Just wondering, is the result different than something like
>
> git checkout commit_to_reparent
> cp -r * ../snapshot/
> git reset --hard new_parent
> rm -r *
> cp -r ../snapshot/* .
> git add -A
>
> (assumes 1 parent, does not cope with
Piotr Krukowiecki writes:
> Just wondering, is the result different than something like
>
> git checkout commit_to_reparent
> cp -r * ../snapshot/
> git reset --hard new_parent
> rm -r *
> cp -r ../snapshot/* .
> git add -A
I think you are looking for "git reset --soft new_parent", which keeps
b
It's been a while I was trying to get this in. Recently, I realized how
important this is.
Please keep me CC'ed as I am not subscribed to the list.
diff to v1:
-Junio's suggestions worked in
Michal Privoznik (3):
git-completion.bash: Autocomplete --minimal and --histogram for
git-diff
co
Since command line options have higher priority than config file
variables and taking previous commit into account, we need a way
how to specify myers algorithm on command line. However,
inventing `--myers` is not the right answer. We need far more
general option, and that is `--diff-algorithm`.
S
Some users or projects prefer different algorithms over others, e.g.
patience over myers or similar. However, specifying appropriate
argument every time diff is to be used is impractical. Moreover,
creating an alias doesn't play nicely with other tools based on diff
(git-show for instance). Hence,
Even though --patience was already there, we missed --minimal and
--histogram for some reason.
Signed-off-by: Michal Privoznik
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completi
Frederik Beaujean
writes:
> On 13-01-11 01:47 AM, Samuel Wales wrote:
>> I have more on this, but if possible it would be best to make ediff do
>> that natively. I don't know if that's possible.
> Thanks for your prompt replies. The reason I looked for this feature
> is that it is available in t
The latest maintenance release Git v1.8.1.1 is now available at
the usual places. This contains many bugfixes that have been
cooking on the 'master' branch since v1.8.1 was released.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksum
On Mon, Jan 14, 2013 at 11:28 AM, Ramsay Jones
wrote:
>
> In particular, sparse issues an "symbol not declared. Should it be
> static?" warning for the 'parse_args' function. Since this function
> does not require greater than file visibility, we suppress this
> warning by simply adding the static
In particular, sparse issues an "symbol not declared. Should it be
static?" warning for the 'parse_args' function. Since this function
does not require greater than file visibility, we suppress this
warning by simply adding the static modifier to it's decalaration.
Signed-off-by: Ramsay Jones
--
Junio C Hamano writes:
> Everybody seems to be getting an impression that .idx is the only
> thing that got corrupt. Where does that come from?
It's the only thing that appear in the error message. This does not
imply that it is the only corrupt thing, but gives a little hope that it
may still
Junio C Hamano writes:
> Michal Privoznik writes:
> ...
>> diff --git a/merge-recursive.c b/merge-recursive.c
>> index d882060..53d8feb 100644
>> --- a/merge-recursive.c
>> +++ b/merge-recursive.c
>> @@ -2068,6 +2068,12 @@ int parse_merge_opt(struct merge_options *o, const
>> char *s)
>>
Michael J Gruber writes:
> It seems to me that everything works as designed, and that the man page
> talk about "push URLs" can be read in two ways,...
Hmph, but I had an impression that Jardel's original report was that
one of the --add --pushurl was not adding but was replacing. If
that was a
Johannes Sixt writes:
> Am 1/14/2013 12:40, schrieb George Karpenkov:
>> I've managed to corrupt my very valuable repository with a recursive
>> sed which went wrong.
>> I wanted to convert all tabs to spaces with the following command:
>>
>> find ./ -name '*.*' -exec sed -i 's/\t//g' {} \;
Michael Haggerty writes:
> On 01/14/2013 07:57 AM, Jonathan Nieder wrote:
>> Michael Haggerty wrote:
>>
>>> imap-send.c | 286
>>> +---
>>> 1 file changed, 39 insertions(+), 247 deletions(-)
>>
>> See my replies for comments on patches 1
Michal Privoznik writes:
> Since command line options have higher priority than config file
> variables and taking previous commit into account, we need a way
> how to specify myers algorithm on command line.
Yes. We cannot stop at [2/3] without this patch.
> However,
> inventing `--myers` is
Michal Privoznik writes:
> Some users or projects prefer different algorithms over others, e.g.
> patience over myers or similar. However, specifying appropriate
> argument every time diff is to be used is impractical. Moreover,
> creating an alias doesn't play nicely with other tools based on di
Max Horn writes:
> From: Felipe Contreras
>
> Mercurial might convert the URL to something more appropriate, like an
> absolute path.
"What it is converted *TO*" is fairly clear with ", like an ...",
but from the first reading it was unclear to me "what it is
converted *FROM*" and "*WHEN* the c
Earlier, dc87183 (use GIT_CONFIG only in "git config", not other
programs, 2008-06-30) made sure that the environment variable is
never used outside "git config", but "git clone", after creating a
directory for the new repository and until the init_db() function
populates its .git/ directory, expor
Jeff King writes:
> The config callback functions get keys of the general form:
>
> section.subsection.key
>
> (where the subsection may be contain arbitrary data, or may
> be missing). For matching keys without subsections, it is
> simple enough to call "strcmp". Matching keys with
> subsectio
On Mon, Jan 14, 2013 at 09:06:10AM -0800, Jeff King wrote:
> struct config_key k;
> parse_config_key(&k, var);
> if (strcmp(k.section, "filter") || k.subsection))
> return 0;
>
> would be a better start (or having git_config do the first two lines
> itself before triggering the ca
On 14.01.13 00:24, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> The test "merge (case change)" passes on a case ignoring file system
>>
>> Use test_expect_success to remove the "known breakage vanished"
>>
>> Signed-off-by: Torsten Bögershausen
>> ---
>
> Interesting. When did thi
Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Phil Hord writes:
>>
>>> Subject: [PATCH] rebase --preserve-merges keeps empty merge commits
>> I would rephrase it as
>>
>> rebase --preserve-merges: keep empty merge commits
>>
>> we usually give orders in commit messages, not state facts (it
Aaron Schrab writes:
> Main changes since the initial version:
>
> * The first patch converts the existing hook callers to use the new
>find_hook() function.
> * Information about what is to be pushed is now sent over a pipe rather
>than passed as command-line parameters.
>
> Aaron Schr
Aaron Schrab writes:
> Create a sample of a script for a pre-push hook. The main purpose is to
> illustrate how a script may parse the information which is supplied to
> such a hook. The script may also be useful to some people as-is for
> avoiding to push commits which are marked as a work in
Aaron Schrab writes:
> Add support for a pre-push hook which can be used to determine if the
> set of refs to be pushed is suitable for the target repository. The
> hook is run with two arguments specifying the name and location of the
> destination repository.
>
> Information about what is to b
I went through your initial thread about blame-tree,
and it is really very very (+very) close to answer my question.
Thanks for writing it,
if it comes one day to git, I will use it.
As for:
'I guess people's eyes and brains are trained by the old school "file
boundaries matter" way of thinking'
1 - 100 of 132 matches
Mail list logo
