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 have asked us to
Matthieu Moy matthieu@grenoble-inp.fr 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
Junio C Hamano gits...@pobox.com writes:
Johan Herland jo...@herland.net 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.
Junio C Hamano gits...@pobox.com 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
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr 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
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
---
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
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:
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:
$ git
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
Matthieu Moy matthieu@grenoble-inp.fr 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),
Ramkumar Ramachandra artag...@gmail.com 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
Yann Droneaud ydrone...@opteya.com writes:
Hi,
Le 21.06.2013 23:57, Junio C Hamano a écrit :
Junio C Hamano gits...@pobox.com 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
Fredrik Gustafsson iv...@iveqy.com 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
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
Ramkumar Ramachandra artag...@gmail.com 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 staTAB
stagestash
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:
$ git
Ramkumar Ramachandra artag...@gmail.com 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
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 what
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 its
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
# pushing
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
== = ===
Jiang Xin worldhello@gmail.com 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;
}
Jiang Xin worldhello@gmail.com 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
Jiang Xin worldhello@gmail.com 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
Jiang Xin worldhello@gmail.com 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
Jiang Xin worldhello@gmail.com 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
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).
Right,
SZEDER Gábor sze...@ira.uka.de 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
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,
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 expanded
Junio C Hamano gits...@pobox.com 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
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 gits...@pobox.com 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]
On Mon, Jun 24, 2013 at 09:24:29AM -0700, Junio C Hamano wrote:
Fraser Tweedale fr...@frase.id.au 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
Ramkumar Ramachandra artag...@gmail.com 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
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
Fraser Tweedale fr...@frase.id.au 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.
Fredrik Gustafsson iv...@iveqy.com 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
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 separate
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 iv...@iveqy.com
---
git-submodule.sh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
From: Jeff King p...@peff.net
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.
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.
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
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
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
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
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
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|
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
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
+++
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
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
упражняясь всего-навсего 10-15 минуток в период, Вы вернете себе 100-процентное
зрение http://goo.gl/xi1Di?/RIo
2013/6/25 Johannes Sixt j...@kdbg.org:
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
+ ;;
+ *)
+
2013/6/25 Junio C Hamano gits...@pobox.com:
Jiang Xin worldhello@gmail.com 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
Vicent Marti tan...@gmail.com 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
2013/6/23 SZEDER Gábor sze...@ira.uka.de:
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
2013/6/24 SZEDER Gábor sze...@ira.uka.de:
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
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 script:
Jiang Xin worldhello@gmail.com writes:
In order to test NULL pointer in t/t0060, I have to write
normalize_argv_string
to convert null to NULL
Yes, null and empty I already understand.
Add prefix _ to workaround the absolute path rewritten issue in
msysGit is interesting, but
Summoning area experts ;-)
Thanks.
Fredrik Gustafsson iv...@iveqy.com 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 iv...@iveqy.com
---
On Mon, Jun 24, 2013 at 5:23 PM, Vicent Marti tan...@gmail.com 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(+)
101 - 167 of 167 matches
Mail list logo
