On Mon, Jun 24, 2013 at 5:23 PM, Vicent Marti wrote:
> This is the technical documentation and design rationale for the new
> Bitmap v2 on-disk format.
> ---
> Documentation/technical/bitmap-format.txt | 235
> +
> 1 file changed, 235 insertions(+)
> create mode 100
Summoning area experts ;-)
Thanks.
Fredrik Gustafsson writes:
> Used only when a clone is initialized. This is useful when the submodule(s)
> are huge and you're not really interested in anything but the latest commit.
>
> Signed-off-by: Fredrik Gustafsson
> ---
> git-submodule.sh | 13 ++
Jiang Xin writes:
> In order to test NULL pointer in t/t0060, I have to write
> normalize_argv_string
> to convert "" to NULL
Yes, null and empty I already understand.
> Add prefix _ to workaround the absolute path rewritten issue in
> msysGit is interesting, but these test cases have alre
Here's a slightly simpler test case for adding a symbolic link. This
test exploits the fact that on my system, /bin/awk is a symbolic link
to "gawk". As you can see, the behavior of Git differs if the link's
path is given to "git add" as an absolute path or a relative path.
Here is the test scri
2013/6/24 SZEDER Gábor :
> This patch series will conflict with Eduardo's work on refactoring the
> colorizing function, and the conflict is not trivial. Although there
> are still some open questions left with that series (using tput, zsh
> tests), those won't affect the conflicts between the two
2013/6/23 SZEDER Gábor :
> I'm wary of relying on tput's availability. It's part of ncurses,
> which is an essential package in many (most? all?) linux distros, but
> I don't know how it is with other supported platforms. So I think
> we'd have to stick to the hard-coded escape sequences as a fal
Vicent Marti writes:
> The library is re-licensed under the GPLv2 with the permission of Daniel
> Lemire, the original author. The source code for the C version can
> be found on GitHub:
>
> https://github.com/vmg/libewok
>
> The original Java implementation can also be found on GitHub:
>
>
2013/6/25 Junio C Hamano :
> Jiang Xin writes:
>
>> diff --git a/test-path-utils.c b/test-path-utils.c
>> index 0092cb..dcc530 100644
>> --- a/test-path-utils.c
>> +++ b/test-path-utils.c
>> @@ -28,6 +28,19 @@ static int normalize_ceiling_entry(struct
>> string_list_item *item, void *unused)
>>
2013/6/25 Johannes Sixt :
> Thanks for working on this. Did you have an opportunity to test on Windows?
Yes, I write this commit on Windows, and have tested it in msysGit.
>> +mingw_path() {
>> + case $2 in
>> + NO_MINGW)
>> + echo "$1"
>> + ;;
>> + *)
>> +
упражняясь всего-навсего 10-15 минуток в период, Вы вернете себе 100-процентное
зрение http://goo.gl/xi1Di?/RIo
The POSIX standard doesn't currently define a `nothll`/`htonll`
function pair to perform network-to-host and host-to-network
swaps of 64-bit data. These 64-bit swaps are necessary for the on-disk
storage of EWAH bitmaps if they are not in native byte order.
---
git-compat-util.h | 28 +++
Since `pack-objects` will write a `.bitmap` file next to the `.pack` and
`.idx` files, this commit teaches `git-repack` to consider the new
bitmap indexes (if they exist) when performing repack operations.
This implies moving old bitmap indexes out of the way if we are
repacking a repository that
This commit enables users of `struct rev_info` to peform custom limiting
during a revision walk (i.e. `get_revision`).
If the field `include_check` has been set to a callback, this callback
will be issued once for each commit before it is added to the "pending"
list of the revwalk. If the include
EWAH is a word-aligned compressed variant of a bitset (i.e. a data
structure that acts as a 0-indexed boolean array for many entries).
It uses a 64-bit run-length encoding (RLE) compression scheme,
trading some compression for better processing speed.
The goal of this word-aligned implementation
The bitmap reachability index used to speed up the counting objects
phase during `pack-objects` can also be used to optimize a normal
rev-list if the only thing required are the SHA1s of the objects during
the list.
Calling `git rev-list --use-bitmaps [committish]` is the equivalent
of `git rev-li
The hash function used by `builtin/pack-objects.c` to efficiently find
delta bases when packing can be of interest for other parts of Git that
also have to deal with delta bases.
---
builtin/pack-objects.c | 24 ++--
cache.h|2 ++
sha1_file.c|
Looking up the offset in the packfile for a given SHA1 involves the
following:
- Finding the position in the index for the given SHA1
- Accessing the offset cache in the index for the found position
There are cases however where we'd like to find the position of a SHA1
in the inde
A bitmap index is used, if available, to speed up the Counting Objects
phase during `pack-objects`.
The bitmap index is a `.bitmap` file that can be found inside
`$GIT_DIR/objects/pack/`, next to its corresponding packfile, and
contains precalculated reachability information for selected commits.
The `pack-objects` builtin is capable of writing out bitmap indexes
(.bitmap) next to the their corresponding packfile, as part of the
process of actually generating the packfile.
This is a very efficient operation because all the required data for
writing the bitmap index (commit traversal list,
A new helper function allows to efficiently query the size and real type
of an object in a packfile based on its position on the packfile index.
This is particularly useful when trying to parse all the information of
an index in memory.
---
cache.h |1 +
sha1_file.c |6 ++
2 files
The `git_open_noatime` helper can be of general interest for other
consumers of git's different on-disk formats.
---
cache.h |1 +
sha1_file.c |4 +---
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/cache.h b/cache.h
index 95ef14d..bbe5e2a 100644
--- a/cache.h
+++ b/cac
This is the technical documentation and design rationale for the new
Bitmap v2 on-disk format.
---
Documentation/technical/bitmap-format.txt | 235 +
1 file changed, 235 insertions(+)
create mode 100644 Documentation/technical/bitmap-format.txt
diff --git a/Documenta
If bitmap indexes are available, the process of counting reachable
commits with `git rev-list --count` can be greatly sped up. Instead of
having to use callbacks that yield each object in the revision list, we
can build the reachable bitmap for the list and then use an efficient
popcount to find th
This commit extends more the functionality of `pack-objects` by allowing
it to write out a `.bitmap` index next to any written packs, together
with the `.idx` index that currently gets written.
If bitmaps are enabled for a given repository (either by calling
`pack-objects` with the `--use-bitmaps`
Hello friends and enemies from the lovevely Git Mailing list.
I bring to you a patch series that implement a quite interesting performance
optimization: the removal of the "Counting Objects" phase during `pack-objects`
by using a pre-computed bitmap to find the reachable objects in the packfile.
From: Jeff King
We free the tree buffer during traversal to save memory.
However, we do not reset the "parsed" flag, which leaves a
landmine for the next person to use the tree. When they call
parse_tree it will do nothing, and they will segfault when
they try to access the buffer.
This hasn't m
Used only when a clone is initialized. This is useful when the submodule(s)
are huge and you're not really interested in anything but the latest commit.
Signed-off-by: Fredrik Gustafsson
---
git-submodule.sh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/git-s
On Mon, Jun 24, 2013 at 03:35:19PM -0700, Junio C Hamano wrote:
> > I don't understand this. How is git:// insecure?
>
> If your DNS is poisoned, or your router is compromised to allow your
> traffic diverted, you may be fetching from somewhere you did not
> intend to. As I explained in a separat
Fredrik Gustafsson writes:
> On Tue, Jun 25, 2013 at 07:57:35AM +1000, Fraser Tweedale wrote:
>> The git transport is insecure and should be used with caution on
>> unsecured networks.
>
> I don't understand this. How is git:// insecure?
>
> It's protocol with no authentication, because it's a
Fraser Tweedale writes:
> Junio, do you prefer the following more generic wording? If so I
> will re-roll the patch (also note s/protocol/transport/ which is
> more appropriate, I think).
>
> The git transport is insecure and should be used with caution on
> unsecured networks.
Generic but I
On Tue, Jun 25, 2013 at 07:57:35AM +1000, Fraser Tweedale wrote:
> The git transport is insecure and should be used with caution on
> unsecured networks.
I don't understand this. How is git:// insecure?
It's protocol with no authentication, because it's a protocol used for
public sharing.
The
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> If we want to continue that tried-and-proven approach as a
>> short-term fix, a patch may look like this.
>
> I don't like this special-casing for show_branch at all.
The patch does not special-case show_branch at all, in that I would
expec
On Mon, Jun 24, 2013 at 09:24:29AM -0700, Junio C Hamano wrote:
> Fraser Tweedale writes:
>
> > The fact that the git transport has no end-to-end security is easily
> > overlooked. Add a brief security notice to the "GIT URLS" section
> > of the documentation stating that the git transport shoul
Junio C Hamano writes:
> Care to turn it into an appliable patch with tests?
In the meantime, here is a quick-and-dirty one. I am not proud of
it; it was just something to keep in 'pu' let it gets lost.
A better replacement is very much welcomed.
-- >8 --
Subject: [PATCH] diff: demote core.sa
I'm trying to create a tarball from a git tag and I can't get the
syntax right. The documentation is not very clear.
Can someone help me?
== details
git v1.8.1.4
The upstream git repo is at: https://github.com/dkovar/analyzeMFT
Here's a few attempts using git as the protocol:
> git archive -
Junio C Hamano writes:
> We use "unspecified" value to initialize the main variables
> (status_format global and s->show_branch), and also prepare
> "from-config" counterpart variables. After we read both, we figure
> out which one should be used, while resetting the main variables to
> their de
On Tue, Jun 25, 2013 at 12:54:17AM +0530, Ramkumar Ramachandra wrote:
> Jeff King wrote:
> > Leaving aside the transport API for a minute, you are always going to
> > have this lack-of-information versus time problem. A refspec like ":"
> > says nothing particularly useful, but it can only be expa
Junio C Hamano wrote:
> If we want to continue that tried-and-proven approach as a
> short-term fix, a patch may look like this.
I don't like this special-casing for show_branch at all. What is the
problem with skipping branch configuration altogether and going
straight to diff-ui configuration,
SZEDER Gábor writes:
> Hi,
>
> displaying the git-specific bash prompt on Windows/MinGW takes quite
> long, long enough to be noticeable. This is mainly caused by the
> numerous fork()s and exec()s to create subshells and run git or other
> commands, which are rather expensive on Windows.
>
> Th
Jeff King wrote:
> Leaving aside the transport API for a minute, you are always going to
> have this lack-of-information versus time problem. A refspec like ":"
> says nothing particularly useful, but it can only be expanded once
> contact is made with the other side (which is what takes time).
Ri
Jiang Xin writes:
> Before introducing interactive git-clean, refactor git-clean operations
> into two phases:
>
> * hold cleaning items in del_list,
> * and remove them in a separate loop at the end.
>
> We will introduce interactive git-clean between the two phases. The
> interactive git-clea
Jiang Xin writes:
> -static void write_name(const char* name, size_t len)
> +static void write_name(const char *name)
> {
> - write_name_quoted_relative(name, len, prefix, prefix_len, stdout,
> - line_terminator);
> +
> + /* turn off prefix, if run with "--full-name"
Jiang Xin writes:
> After substitute path_relative() in quote.c with relative_path() from
> path.c, parameters (such as len and prefix_len) are obsolete in function
> quote_path_relative(). Remove unused parameters and change the order of
> parameters for quote_path_relative() function.
> ...
> d
Jiang Xin writes:
> Since there is an enhanced version of relative_path() in path.c,
> remove duplicate counterpart path_relative() in quote.c.
There is no nice comparison chart before and after like you had in
patch 02/16?
> void write_name_quoted_relative(const char *name, size_t len,
>
Jiang Xin writes:
> diff --git a/test-path-utils.c b/test-path-utils.c
> index 0092cb..dcc530 100644
> --- a/test-path-utils.c
> +++ b/test-path-utils.c
> @@ -28,6 +28,19 @@ static int normalize_ceiling_entry(struct string_list_item
> *item, void *unused)
> return 1;
> }
>
> +static voi
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
> == = ===
>
On Tue, Jun 25, 2013 at 12:12:16AM +0530, Ramkumar Ramachandra wrote:
> > 1. It does not tell very much about how the refspecs are expanded or
> > what is going to happen. "git push --dry-run" gives a much more
> > complete view of what will be pushed.
>
> Yes.
>
> $ git push
> #
Ramkumar Ramachandra wrote:
> 11920d2 (Add a built-in alias for 'stage' to the 'add' command,
> 2008-12-01) added a the 'git stage' command which simply calls
> cmd_add(). Since then, no references to it have been made anywhere on
> the internet; there is no evidence that anyone even knows about i
Jeff King wrote:
> If your intent is to let people stop disastrous pushes before they
> complete, I think there are two failings:
>
> 1. It does not tell very much about how the refspecs are expanded or
> what is going to happen. "git push --dry-run" gives a much more
> complete view of
Ramkumar Ramachandra writes:
> 11920d2 (Add a built-in alias for 'stage' to the 'add' command,
> 2008-12-01) added a the 'git stage' command which simply calls
> cmd_add(). Since then, no references to it have been made anywhere on
> the internet; there is no evidence that anyone even knows abou
On Mon, Jun 24, 2013 at 11:11:02PM +0530, Ramkumar Ramachandra wrote:
> There are many configuration variables that determine exactly what a
> push does. Give the user early feedback so that she has a chance to
> abort if she doesn't mean to push those refspecs to that destination
> like:
>
>
Ramkumar Ramachandra writes:
> 11920d2 (Add a built-in alias for 'stage' to the 'add' command,
> 2008-12-01) added a the 'git stage' command which simply calls
> cmd_add(). Since then, no references to it have been made anywhere on
> the internet;
$ git sta
stagestashstatus
So the co
Junio C Hamano wrote:
> With remote.pushdefault, I think the ship has long sailed.
What's wrong with the "early feedback" approach I suggested?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vge
Fredrik Gustafsson writes:
> On Mon, Jun 24, 2013 at 11:11:02PM +0530, Ramkumar Ramachandra wrote:
>> There are many configuration variables that determine exactly what a
>> push does. Give the user early feedback so that she has a chance to
>> abort if she doesn't mean to push those refspecs to
Yann Droneaud writes:
> Hi,
>
> Le 21.06.2013 23:57, Junio C Hamano a écrit :
>> Junio C Hamano writes:
>>
>>> The helper may want to learn a way to be told to demote that error
>>> to a warning.
>>
>> Perhaps something like this?
>>
>
> Thanks for the patch.
Care to turn it into an appliable p
Ramkumar Ramachandra writes:
> I'm not saying that we need to differentiate between configuration
> variables and CLI options; what I _am_ saying is that we need to think
> twice about moving a CLI option to a configuration variable, precisely
> because we do not differentiate between the two cas
Matthieu Moy writes:
>> "First read config, override with command line" is what we always
>> do. One recent workaround with selective exception I can think of
>> offhand is in diff config parser 6c374008 (diff_opt: track whether
>> flags have been set explicitly, 2013-05-10), but I am fairly sur
11920d2 (Add a built-in alias for 'stage' to the 'add' command,
2008-12-01) added a the 'git stage' command which simply calls
cmd_add(). Since then, no references to it have been made anywhere on
the internet; there is no evidence that anyone even knows about its
existence. It is a long-lost for
On Mon, Jun 24, 2013 at 11:11:02PM +0530, Ramkumar Ramachandra wrote:
> There are many configuration variables that determine exactly what a
> push does. Give the user early feedback so that she has a chance to
> abort if she doesn't mean to push those refspecs to that destination
> like:
>
> $
There are many configuration variables that determine exactly what a
push does. Give the user early feedback so that she has a chance to
abort if she doesn't mean to push those refspecs to that destination
like:
$ git push
# pushing refspecs 'master next' to ram (^C to abort)
Signed-off-by:
Ramkumar Ramachandra wrote:
> + __git_complete_index_file
Um, that should be __git_complete_index_file "--cached", I think.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/m
Signed-off-by: Ramkumar Ramachandra
---
contrib/completion/git-completion.bash | 26 ++
1 file changed, 26 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 6c3bafe..912fb98 100644
--- a/contrib/completion/gi
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> benoit.per...@ensimag.fr writes:
>>>
diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..a2f0aa1
--- /dev/null
+++ b/contrib/mw-to-g
Junio C Hamano writes:
> That means after we add more and more other options like --branch
> that enrich the output in several years, scripts that want to use
> the enriched data need to pass tons of options to get what they
> want, which is not very nice,
Right, but accepting status.branch woul
Junio C Hamano writes:
> Johan Herland writes:
>
>>> + git --git-dir="${3:-repo1}" log -1 --format='%h %s' "$2" >actual &&
>>
>> Isn't ${3:-repo1} a bashism?
>
> I do not think so. But now I looked at it again, I think I would
> use ${3-repo1} form in this case myself. No caller passes
Matthieu Moy writes:
> Scripts that want the branch information can use --branch.
> Scripts that do not have absolutely nothing to gain in getting this
> extra output (only extra parser complexity).
OK, I could buy that.
I personally have always _assumed_ that the way the "--porcelain"
output w
Junio C Hamano wrote:
> If you do not set anywhere (like branch.master.pushremote or
> remote.pushdefault) to push to "ram", and if you did not say "git
> push ram" but just said "git push", we will not push to "ram"
> (otherwise it is broken). So if the push is going to "ram", the
> user must hav
Le 2013-06-24 18:56, Matthieu Moy a écrit :
Junio C Hamano writes:
Matthieu Moy writes:
benoit.per...@ensimag.fr writes:
diff --git a/contrib/mw-to-git/git-mw.perl
b/contrib/mw-to-git/git-mw.perl
new file mode 100644
index 000..a2f0aa1
--- /dev/null
+++ b/contrib/mw-to-git/git-mw.per
Le 24.06.2013 18:37, Yann Droneaud a écrit :
I'm still trying to use .gitattributes "text" flag with CRLF line
ending files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
On Mon, Jun 24, 2013 at 06:56:17PM +0200, Matthieu Moy wrote:
> > Good eyes. But if we encourage people to run non-*.perl version,
> > perhaps we should drop the executable bit from the source, no?
>
> But by default, I'd say consistency is most important so if other *.perl
> are executable, we
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> benoit.per...@ensimag.fr writes:
>>
>>> diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
>>> new file mode 100644
>>> index 000..a2f0aa1
>>> --- /dev/null
>>> +++ b/contrib/mw-to-git/git-mw.perl
>>
>> *.perl scripts
Yann Droneaud writes:
> - Why git diff does not always report the CRLF/LF mismatch ?
Most likely because you are telling safecrlf not to error out but
just warn, and then you are not fixing the cause of the warning? So
diff would say "Ok, you must know what you are doing, so I trust
what is in
Junio C Hamano wrote:
> In any case, I am still not convinced yet that status.short is a
> real problem if --porcelain readers trip with "## branchname"
> output. Isn't it that the readers are broken and need fixing?
If you're going to read the configuration and then scramble to reset
it in wt_po
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> If the user said "git push" without an explicit request to push to
>> "ram", and if branch.master.pushremote was not set to "ram", and
>> still the command "git push" pushed the branch to "ram", then I
>> would understand what you are worrie
Junio C Hamano writes:
> Matthieu Moy writes:
>
>>> Basically, having the CLI parser and the config parser flip two
>>> different sets of variables, so we can discriminate who set what.
>>> What annoys me is that this is the first instance of such a
>>> requirement.
>>
>> I don't think it's the
__git_ps1() is usually added to the prompt inside a command
substitution, imposing the overhead of fork()ing a subshell. Using
__git_ps1() for $PROMPT_COMMAND is slightly faster, because it avoids
that command substitution.
Mention this in the comments about setting up the git prompt.
The whole
When the environment variable $GIT_PS1_SHOWSTASHSTATE is set
__git_ps1() checks the presence of stashes by running 'git rev-parse
--verify refs/stash'. This command not only checks that the
'refs/stash' ref exists but also, well, verifies that it's a valid
ref.
However, we don't need to be that t
Before setting $PS1, __git_ps1() uses a command substitution to
redirect the output from a printf into a variable. Spare the overhead
of fork()ing a subshell by using 'printf -v ' to directly assign
the output to that variable.
zsh's printf doesn't support the '-v ' option, so stick with the
comm
When enabled, the bash prompt can indicate the presence of untracked
files with a '%' sign. __git_ps1() checks for untracked files by running the
'$(git ls-files --others --exclude-standard)' command substitution,
and displays the indicator when there is no output.
Avoid this command substitution
When the dirty work tree and index status indicator is enabled,
__git_ps1() checks for changes in the index by running 'git diff-index
--cached --quiet HEAD --' and looking at its exit code. However, that
makes sense only when HEAD points to a valid commit: on an unborn
branch the failure of said
There are a couple of '$(git rev-parse --)' command substitutions
in __git_ps1() and three of them are executed in the main code path:
- the first to get the path to the .git directory ('--git-dir'),
- the second to check whether we're inside the .git directory
('--is-inside-git-dir'),
- and
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() now runs the '$(git rev-parse
--short HEAD)' command substitution to get the abbreviated detached
HEAD commit object name. This imposes the overhead of fork()ing a
subshell and fork()+exec()i
__git_ps1() runs the '$(git symbolic-ref HEAD)' command substitution
to find out whether we are on a branch and to find out the name of
that branch. This imposes the overhead of fork()ing a subshell and
fork()+exec()ing a git process.
Since HEAD is in most cases a single-line file and the symboli
During an ongoing interactive rebase __git_ps1() finds out the name of
the rebased branch, the total number of patches and the number of the
current patch by executing a '$(cat .git/rebase-merge/)' command
substitution for each. That is not quite the most efficient way to
read single line single w
... to gain one level of indentation for the bulk of the function.
(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)
Signed-off-by: SZEDER Gábor
---
contrib/completion/git-prompt.sh | 201 ---
1 file changed, 101 insertions(+), 100
__git_ps1() finds out the path to the repository by using the
__gitdir() helper function. __gitdir() is basically just a wrapper
around 'git rev-parse --git-dir', extended with support for
recognizing a remote repository given as argument, to use the path
given on the command line, and with a few
Le 24.06.2013 18:37, Yann Droneaud a écrit :
I'm still trying to use .gitattributes "text" flag with CRLF line
ending files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
Signed-off-by: SZEDER Gábor
---
t/t9903-bash-prompt.sh | 9 +
1 file changed, 9 insertions(+)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index df36239a..416e6219 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@@ -40,6 +40,15 @@ test_expect_success 'pro
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() runs 'cut -c1-7 .git/HEAD' to
show the 7 hexdigits abbreviated commit object name in the prompt.
Obviously, this neither respects core.abbrev nor produces a unique
object name.
Fix this by us
Helped-by: Jeff King
Signed-off-by: SZEDER Gábor
---
t/t9903-bash-prompt.sh | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh
index 7c7f8b97..442b9a20 100755
--- a/t/t9903-bash-prompt.sh
+++ b/t/t9903-bash-prompt.sh
@
Currently __gitdir() is duplicated in the git completion and prompt
scripts, while its tests are in the prompt test suite. This patch
series is about to change __git_ps1() in a way that it won't need
__gitdir() anymore and __gitdir() will be removed from the prompt
script.
So move all __gitdir()
Use '>file' instead of '> file', in accordance with the coding
guidelines.
Signed-off-by: SZEDER Gábor
---
t/t9903-bash-prompt.sh | 232 -
1 file changed, 116 insertions(+), 116 deletions(-)
diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-promp
Hi,
displaying the git-specific bash prompt on Windows/MinGW takes quite
long, long enough to be noticeable. This is mainly caused by the
numerous fork()s and exec()s to create subshells and run git or other
commands, which are rather expensive on Windows.
This patch series eliminates many comma
Matthieu Moy writes:
> benoit.per...@ensimag.fr writes:
>
>> diff --git a/contrib/mw-to-git/git-mw.perl b/contrib/mw-to-git/git-mw.perl
>> new file mode 100644
>> index 000..a2f0aa1
>> --- /dev/null
>> +++ b/contrib/mw-to-git/git-mw.perl
>
> *.perl scripts are usually executable in Git's tree
Hi,
I'm still trying to use .gitattributes "text" flag with CRLF line ending
files
under Linux.
I'm surprised about the interaction between the index and the working
directory,
more specificaly about the interaction between git diff and git status:
$ git init
Initialized empty Git repos
Matthieu Moy writes:
>> Basically, having the CLI parser and the config parser flip two
>> different sets of variables, so we can discriminate who set what.
>> What annoys me is that this is the first instance of such a
>> requirement.
>
> I don't think it's the first instance, but I can't rememb
Fraser Tweedale wrote:
> The default similarity index of 50% is documented in gitdiffcore(7)
> but it is worth also mentioning it in the description of the
> -M/--find-renames option.
Looks good from a quick look at diffcore.h:
#define DEFAULT_RENAME_SCORE 3 /* rename/copy similarity minimum
Fraser Tweedale writes:
> The fact that the git transport has no end-to-end security is easily
> overlooked. Add a brief security notice to the "GIT URLS" section
> of the documentation stating that the git transport should be used
> with caution on unsecured networks.
>
> Signed-off-by: Fraser
On Sat, Jun 22, 2013 at 01:32:38PM -0300, Eduardo D'Avila wrote:
> These tests where important to make sure that I wouldn't break anything during
> the refactorization. Having them pass before *and* after refactorization
> guarantees that nothing was broken (except for some subtle case that might
Junio C Hamano wrote:
> If the user said "git push" without an explicit request to push to
> "ram", and if branch.master.pushremote was not set to "ram", and
> still the command "git push" pushed the branch to "ram", then I
> would understand what you are worried about, but otherwise I do not
> see
1 - 100 of 164 matches
Mail list logo
