It is currently declared to return int, which could overflow for large
files.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
This patch is against maint, but it also rebases against master
without conflict.
I couldn't find any way to exploit this bug. Most callers only use
this
The only change is a bugfix: the SMTP mailer was not working with
Python 2.4.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
contrib/hooks/multimail/CHANGES | 5 +
contrib/hooks/multimail/README | 2 +-
contrib/hooks/multimail/README.Git | 4 ++--
On Fri, Jul 3, 2015 at 11:51 PM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Once we know the number of objects in the input pack, we allocate an
array of nr_objects of struct delta_entry. On x86-64, this struct is
32 bytes long. The union
On Fri, Jul 3, 2015 at 11:07 AM, Jeff King p...@peff.net wrote:
I wondered briefly whether this impacted the keepalives we added to
`upload-pack` in 05e9515; those are implemented as 0-byte data packets,
which we send during the potentially long counting/delta-compression
phase before we send
Clemens Buchacher clemens.buchac...@intel.com writes:
Since e481af06 (rebase: Handle cases where format-patch fails) we
notice if format-patch fails and return immediately from
git-rebase--am. We save the return value with ret=$?, but then we
return $?, which is usually zero in this case.
Sitaram Chamarty sitar...@gmail.com writes:
On 06/25/2015 05:41 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
This *is* documented, but I'm curious why this distinction is made.
I think it is from mere laziness, and also in a smaller degree
coming from an
Matthieu Moy matthieu@grenoble-inp.fr writes:
David Turner dtur...@twopensource.com writes:
Twitter's history is almost completely linear, so it's useful for us.
Since it looks like the patch won't be useful outside of our context,
I'll just rewrite it to check the pathspec count, and
On Fri, Jul 03, 2015 at 10:49:40AM -0700, Junio C Hamano wrote:
Lawrence Siebert lawrencesieb...@gmail.com writes:
Moving commit counting from rev-list into list-object which is a step
toward letting git log do counting as well.
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
Jeff King p...@peff.net writes:
On Wed, Jul 01, 2015 at 01:39:49PM -0700, Junio C Hamano wrote:
There is a slight complication on sending an empty line without any
termination, though ;-) The reader that calls packet_read() cannot
tell such a payload from a flush packet, I think.
*That*
On Fri, Jul 03, 2015 at 11:43:33AM -0700, Shawn Pearce wrote:
For (2), hopefully we can implement it in the same way, and rely on
empty sideband-0 packets. I haven't tested it in practice, though (I
have some very rough patches for (1) already).
sideband-0 is not going to work for JGit
Am 3. Juli 2015 um 17:50 schrieb Ralf Thielow ralf.thie...@gmail.com:
Translate 65 new messages came from git.pot update
in 64f23b0 (l10n: git.pot: v2.5.0 round 1 (65 new,
15 removed)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
#: dir.c:1945
msgid Untracked cache is disabled
Matthieu Moy matthieu@grenoble-inp.fr writes:
I would agree with more strict is it was about rejecting the input (to
catch errors), but here we're still accepting it without complaining
Yes, by more strict, I meant that I would prefer to keep things we
do not understand as intact as
On Fri, Jul 03, 2015 at 10:18:45AM -0700, Junio C Hamano wrote:
Since 2e6c01e2, we export GIT_PAGER_IN_USE so that a process that
I imagine you mean 2e6c012e here.
becomes the upstream of the spawned pager can still tell that we
have spawned the pager and decide to do colored output even
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Once we know the number of objects in the input pack, we allocate an
array of nr_objects of struct delta_entry. On x86-64, this struct is
32 bytes long. The union delta_base, which is part of struct
delta_entry, provides enough space to store
Lawrence Siebert lawrencesieb...@gmail.com writes:
Moving commit counting from rev-list into list-object which is a step
toward letting git log do counting as well.
Signed-off-by: Lawrence Siebert lawrencesieb...@gmail.com
---
No way. Look at the things provided by list-objects.c API.
On Fri, Jul 03, 2015 at 10:45:59AM -0700, Junio C Hamano wrote:
Usually flush packets are , and an empty data packet
is 0004. Or are you talking about some kind of flush inside the
pkt-data stream?
Neither. At the wire level there is a difference, but the callers
of most often used
Dear Winner,
Your email address attached to ticket number 7-27-31-37-43 WON One Million
British Pound in the BINGO LOTTO INTERNATIONAL. Email to (bingo...@aim.com) for
claim.
Congratulations once again.
Yours Faithfully,
Mr. David
--
To unsubscribe from this list: send the line unsubscribe
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
Given git checkout --to path HEAD~1, the new worktree's HEAD should
begin life at the current branch's HEAD~1, however, it actually ends up
at HEAD~2. The happens because:
1. git-checkout resolves HEAD~1
2.
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
COMMANDS
+add path branch::
+
+Check out `branch` into a separate working directory, `path`, creating
+`path` if necessary. The new working directory is linked to the current
+repository, sharing
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add -b/-B options to create a new
Translate 65 new messages came from git.pot update
in 64f23b0 (l10n: git.pot: v2.5.0 round 1 (65 new,
15 removed)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 186 ---
1 file changed, 95 insertions(+), 91
On Thu, Jul 2, 2015 at 11:16 AM, Paul Tan pyoka...@gmail.com wrote:
Increase test coverage of git-am.sh to help prevent regressions that could
arise
from the rewrite of git-am.sh to C. This patch series, along with
pt/am-foreign, improved test coverage as measured by kcov from 56.5%[1] to
Since 2e6c01e2, we export GIT_PAGER_IN_USE so that a process that
becomes the upstream of the spawned pager can still tell that we
have spawned the pager and decide to do colored output even when
its output no longer goes to a terminal (i.e. isatty(1)).
But we forgot to clear it from the
John Keeping j...@keeping.me.uk writes:
On Tue, Jun 30, 2015 at 02:10:49PM +0200, Johannes Schindelin wrote:
On 2015-06-29 18:46, Lawrence Siebert wrote:
I appreciate your help. Okay, That all makes sense.
I would note that something like:
git shortlog -s $FILENAME: | cut -f 1 |
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
* ad/bisect-terms (2015-06-29) 10 commits
...
The bottom part has been quite well cooked. Perhaps split it into
two topisc and merge the earlier ones to 'next' before the rest
settles. Michael's
On Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty sitar...@gmail.com wrote:
Jokes apart, I'm not sure the chances of *both* those things happening
-- an accidental hash-like string in the text *and* it matching an
existing hash -- are high enough to bother. If it can be done without
too much
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
Now that git worktree add has achieved user-facing feature-parity with
git checkout --to, retire the latter.
Move the actual linked worktree creation functionality,
prepare_linked_checkout() and its helpers, verbatim
On Fri, Jul 3, 2015 at 8:17 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
+EXAMPLES
+
+You are middle of a refactoring session and your boss comes in and demands
s/middle/in the /
+that you fix something immediately. You
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
+git-worktree could provide more automation for tasks currently
+performed manually or via other commands, such as:
+
+- `add` to create a new linked worktree
+- `remove` to remove a linked worktree and its
On Fri, Jul 3, 2015 at 8:17 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
In order to allow linked worktree creation via git checkout -b from a
s/-b/--to/
bare repository, 3473ad0 (checkout: don't require a work tree when
checking out into a new one, 2014-11-30) dropped git-checkout's
The plan is to relocate git checkout --to functionality to git
worktree add. As a first step, introduce a bare-bones git-worktree
add command along with documentation. At this stage, git worktree
add merely invokes git checkout --to behind the scenes, but an
upcoming patch will move the actual
The only references to 'new' were folded out by the last two patches.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
builtin/checkout.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 0cb81ee..0dcdde2 100644
---
As a safeguard, checking out a branch already checked out by a different
worktree is disallowed. This behavior can be overridden with
--ignore-other-worktrees, however, this option is neither obvious nor
particularly discoverable. As a common safeguard override, --force is
more likely to come to
A subsequent patch will also need to compute the basename of the new
worktree, so factor out this logic into a new function.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
builtin/worktree.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff
Now that git worktree add has achieved user-facing feature-parity with
git checkout --to, retire the latter.
Move the actual linked worktree creation functionality,
prepare_linked_checkout() and its helpers, verbatim from checkout.c to
worktree.c.
This effectively reverts changes to checkout.c
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add a --detach option to detach HEAD
in the new worktree.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
As a convenience, when branch is omitted from git worktree path
branch and neither -b nor -B used, automatically create a new branch
named after path, as if -b $(basename path) was specified. Thus,
git worktree add ../hotfix creates a new branch named hotfix and
associates it with new worktree
By default, git worktree add refuses to create a new worktree when
the requested branch is already checked out elsewhere. Add a --force
option to override this safeguard.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-worktree.txt | 8 +++-
builtin/worktree.c
In order to allow linked worktree creation via git checkout -b from a
bare repository, 3473ad0 (checkout: don't require a work tree when
checking out into a new one, 2014-11-30) dropped git-checkout's
unconditional NEED_WORK_TREE requirement and instead performed worktree
setup conditionally based
With the introduction of git worktree add, git checkout --to is
slated for removal. Therefore, retrofit linked worktree creation tests
to use git worktree add instead.
(The test to check exclusivity of checkout --to and checkout paths
is dropped altogether since it becomes meaningless with
git-worktree options affect some worktree commands but not others, but
this is not necessarily obvious from the option descriptions. Make this
clear by indicating explicitly which commands are affected by which
options.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Due to the (current) absence of a git worktree lock command, locking
a worktree's administrative files to prevent automatic pruning is a
manual task, necessarily requiring low-level understanding of linked
worktree functionality. However, this level of detail does not belong
in the high-level
Now that the git-worktree command exists, its documentation page is the
natural place for the linked worktree description to reside. Relocate
the MULTIPLE WORKING TREES description verbatim from git-checkout.txt
to git-worktree.txt.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
When
The DESCRIPTION section should provide a high-level overview of linked
worktree functionality to bring users up to speed quickly, without
overloading them with low-level details, so relocate the technical
information to a new DETAILS section.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
Given git checkout --to path HEAD~1, the new worktree's HEAD should
begin life at the current branch's HEAD~1, however, it actually ends up
at HEAD~2. The happens because:
1. git-checkout resolves HEAD~1
2. to satisfy is_git_directory, prepare_linked_worktree() creates a
HEAD in
prepare_linked_checkout() respects git-checkout's --quiet flag, however,
the plan is to relocate git checkout --to functionality to git
worktree add, and git-worktree does not (yet) have a --quiet flag.
Consequently, make prepare_linked_checkout() unconditionally verbose to
ease eventual code
One of git-worktree's roles is to populate the new worktree, much like
git-checkout, and thus, for convenience, ought to support several of the
same shortcuts. Toward this goal, add -b/-B options to create a new
branch and check it out in the new worktree.
Signed-off-by: Eric Sunshine
The plan is to relocate git checkout --to functionality to git
worktree add, however, worktree.c won't have access to the 'struct
checkout_opts' passed to prepare_linked_worktree(), which it consults
for the pathname of the new worktree and the argv[] of the command it
should run to populate the
This is v2 of the series to replace git checkout --to with git
worktree add. It's built atop Duy's df0b6cf (worktree: new place for
git prune --worktrees, 2015-06-29) which introduces the git-worktree
command and replaces git prune --worktrees with git worktree prune.
Although v1[*1*] consisted
This was missed when git prune --worktrees became git worktree prune.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-checkout.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-worktree.txt | 22 ++
1 file changed, 22 insertions(+)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 410f0b4..028bbd9 100644
--- a/Documentation/git-worktree.txt
Relocate submodule warning to BUGS and enumerate missing commands.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-worktree.txt | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-worktree.txt
The plan is to relocate git checkout --to functionality to git
worktree add, however, this check expects a 'struct branch_info' which
git-worktree won't have at hand. It will, however, have access to its
own command-line from which it can pick up the branch name. Therefore,
as a preparatory step,
On Fri, Jul 3, 2015 at 10:31 AM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
On Tue, Jun 30, 2015 at 02:10:49PM +0200, Johannes Schindelin wrote:
On 2015-06-29 18:46, Lawrence Siebert wrote:
I appreciate your help. Okay, That all makes sense.
I would
Matthieu Moy matthieu@grenoble-inp.fr writes:
If implementing a proper count is too hard, one option is to forbid
--count -S and --count -G to avoid confusion.
Let's not go there. Letting people to use --oneline | wc -l is
far better unless we can get --count that behaves the same as
On 07/03/2015 11:06 PM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
On 06/25/2015 05:41 AM, Junio C Hamano wrote:
Sitaram Chamarty sitar...@gmail.com writes:
This *is* documented, but I'm curious why this distinction is made.
I think it is from mere laziness, and
Matthieu Moy matthieu@grenoble-inp.fr writes:
Also, some revision-limiting options can reduce the count like
git log --grep whatever
and you should check that you actually count the right number here.
(I don't know this part of the code enough, but I'm not sure you
actually deal with
When c6458e60 (index-pack: kill union delta_base to save memory,
2015-04-18) attempted to reduce the memory footprint of index-pack,
one of the key thing it did was to keep track of ref-deltas and
ofs-deltas separately.
In fix_unresolved_deltas(), however it forgot that it now wants to
look only
Sorry for not replying earlier, and thanks for taking the time to
investigate this!
It's a pretty subtle corner case: I think a test case would be useful.
I'm going to try to put something together, unless you beat me to it!
(I think t9811-git-p4-label-import.sh is the one that needs
David Turner dtur...@twopensource.com writes:
Twitter's history is almost completely linear, so it's useful for us.
Since it looks like the patch won't be useful outside of our context,
I'll just rewrite it to check the pathspec count, and not upstream it
until follow becomes more general.
Lawrence Siebert lawrencesieb...@gmail.com writes:
+static void show_object(struct object *obj,
+ const struct name_path *path, const char *component,
+ void *cb_data)
+{
+ return;
+}
It seems streange to me to have a function named show_object
Lawrence Siebert lawrencesieb...@gmail.com writes:
added test comparing output between git log --count HEAD and
git rev-list --count HEAD
Unless there is a very long list of tests, I'd rather see this squashed
with PATCH 2/4. As a reviewer I prefer having code and tests in the same
place.
Mattieu,
Understood. I don't suppose there is any commonly code formatting tool
to automate formatting in the git style, is there?
Thanks,
Lawrence
On Fri, Jul 3, 2015 at 12:24 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Lawrence Siebert lawrencesieb...@gmail.com writes:
+void
Lawrence Siebert lawrencesieb...@gmail.com writes:
+void get_commit_count(struct rev_info * revs) {
Please, write struct rev_info *revs (stick * to revs).
+void get_commit_count(struct rev_info * revs);
Likewise.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this
traverse_commit_list requires a function to be passed to it. That
said, after further review it can probably pass NULL and have it work
fine. If not, I'll use your naming convention.
`git rev-list --count` (or actually `git rev-list --count HEAD`, which
this borrows the code from, produces a
Matthieu,
Ok, I'll fix that. I think I can also add tests, I can look at the
tests for rev-list --count, with the understanding that I saw somebody
else had made changes for the --use-bitmap-index option, and I am
basing off of master for this, and thus don't feel comfortable with
Lawrence Siebert lawrencesieb...@gmail.com writes:
Mattieu,
Understood. I don't suppose there is any commonly code formatting tool
to automate formatting in the git style, is there?
IIRC, someone posted a configuration file for clang-format that
essentially matches the Git coding style.
You
Hi,
Please, don't top-post on this list. Quote the parts you're replying to
and reply below.
Lawrence Siebert lawrencesieb...@gmail.com writes:
traverse_commit_list requires a function to be passed to it. That
said, after further review it can probably pass NULL and have it work
fine. If
Lawrence Siebert lawrencesieb...@gmail.com writes:
Ok, I'll fix that.
(Note: this is a typical example of why we don't top-post here. I made
several remarks and I can't know what that refers to)
(Meta-note: don't take the note as agressive, I know that top-posting is
the norm in many other
Matthieu Moy matthieu@grenoble-inp.fr writes:
Also, some revision-limiting options can reduce the count like
git log --grep whatever
OK, --grep seems to work, but -S and -G do not:
$ ./bin-wrappers/git log -Sfoo --count
40012
$ ./bin-wrappers/git log -Sfoo --oneline | wc -l
925
$
70 matches
Mail list logo
