On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine 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
> branch and check it out i
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine 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 from checkout.
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine wrote:
> COMMANDS
>
> +add ::
> +
> +Check out `` into a separate working directory, ``, creating
> +`` if necessary. The new working directory is linked to the current
> +repository, sharing everything except working directory specific fil
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine wrote:
> Given "git checkout --to 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_
On Sat, Jul 4, 2015 at 7:17 AM, Eric Sunshine 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 administrative files (and
>
On Fri, Jul 3, 2015 at 8:17 PM, Eric Sunshine 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
> unconditional NEED_WO
On Fri, Jul 3, 2015 at 8:17 PM, Eric Sunshine wrote:
> Signed-off-by: Eric Sunshine
> ---
> +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 might typically use
> +linkgit:git-stash[
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 Fri, Jul 3, 2015 at 6:26 PM, Sitaram Chamarty 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 code, it probabl
On 07/03/2015 11:06 PM, Junio C Hamano wrote:
> Sitaram Chamarty writes:
>
>> On 06/25/2015 05:41 AM, Junio C Hamano wrote:
>>> Sitaram Chamarty 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 de
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 a
Matthieu Moy 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 that,
only faster.
--
To unsu
Matthieu Moy 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 this properly)
Yes,
As a convenience, when is omitted from "git worktree
" and neither -b nor -B used, automatically create a new branch
named after , as if "-b $(basename )" was specified. Thus,
"git worktree add ../hotfix" creates a new branch named "hotfix" and
associates it with new worktree "../hotfix".
Signed
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
---
Documentation/git-worktree.txt | 8 +++-
builtin/worktree.c | 6 +-
2
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 base
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 "
is dropped altogether since it becomes meaningless with re
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.
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
---
Documentation/git-worktree.
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 m
As a convenience, like "git branch" and "git checkout -b", make
"git worktree add -b " default to HEAD when
is omitted.
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.txt | 1 +
builtin/worktree.c | 6 --
t/t2025-worktree-add.sh| 7 +++
3 files changed
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
---
For br
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 th
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 mi
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
---
builtin/worktree.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/builtin/worktree.c b
Given "git checkout --to 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 the
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 a
The only references to 'new' were folded out by the last two patches.
Signed-off-by: Eric Sunshine
---
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
--- a/builtin/checkout.c
+++ b/
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*] co
This was missed when "git prune --worktrees" became "git worktree prune".
Signed-off-by: Eric Sunshine
---
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 72def5b..ce223e6 100
Signed-off-by: Eric Sunshine
---
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
+++ b/Documentation/git-wo
Relocate submodule warning to BUGS and enumerate missing commands.
Signed-off-by: Eric Sunshine
---
Documentation/git-worktree.txt | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index 3d28896
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 ste
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
---
Documentation/git-worktree.txt | 6 +++---
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 DES
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
---
When Junio queued v1[1] on '
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
---
Documentation/git-wo
On Fri, Jul 3, 2015 at 10:31 AM, Junio C Hamano wrote:
> John Keeping 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 some
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 extendin
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
On Fri, Jul 3, 2015 at 11:07 AM, Jeff King 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 out pack d
On Fri, Jul 03, 2015 at 10:49:40AM -0700, Junio C Hamano wrote:
> Lawrence Siebert 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
> > ---
>
> No way. Look at the things
On Fri, Jul 3, 2015 at 11:51 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy 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
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 mos
Matthieu Moy writes:
> Junio C Hamano 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 idea to make 'good/bad' more intel
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 w
Clemens Buchacher 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.
>
> Fix this by returning $
Lawrence Siebert 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
> ---
No way. Look at the things provided by list-objects.c API. They
are not about formatting outputs. printf()
Matthieu Moy writes:
> David Turner 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 mo
Jeff King 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* ma
Matthieu Moy 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 possible, while transforming
Sitaram Chamarty writes:
> On 06/25/2015 05:41 AM, Junio C Hamano wrote:
>> Sitaram Chamarty 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 expectation that --stdin would
John Keeping 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 | pas
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 enviornme
Nguyễn Thái Ngọc Duy 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 either ofs-delta
On Thu, Jul 2, 2015 at 11:16 AM, Paul Tan 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
> 67.3%[2].
>
> No
Am 3. Juli 2015 um 17:50 schrieb Ralf Thielow :
> 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
> ---
> #: dir.c:1945
> msgid "Untracked cache is disabled on this system."
> -msgstr ""
> +m
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
---
po/de.po | 186 ---
1 file changed, 95 insertions(+), 91 deletions(-)
diff --git a/po/
The only change is a bugfix: the SMTP mailer was not working with
Python 2.4.
Signed-off-by: Matthieu Moy
---
contrib/hooks/multimail/CHANGES | 5 +
contrib/hooks/multimail/README | 2 +-
contrib/hooks/multimail/README.Git | 4 ++--
contrib/hooks/multimail/git_mul
It is currently declared to return int, which could overflow for large
files.
Signed-off-by: Michael Haggerty
---
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 function for locally-generat
Matthieu Moy 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
$ ./bin-wrappers/git log --count
Lawrence Siebert 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 places, I'm just giving yo
Hi,
Please, don't top-post on this list. Quote the parts you're replying to
and reply below.
Lawrence Siebert 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 not, I'll use your namin
Lawrence Siebert 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 can read Documentatio
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
--use-bitmap-i
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
wrote:
> Lawrence Siebert writes:
>
>> +void get_commit_count(struct rev_info * revs) {
>
> Please,
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 sin
Lawrence Siebert 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.
> Signed-off-by: Lawrence S
Lawrence Siebert 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 when it
does not show
Lawrence Siebert 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 list: send the line "u
David Turner 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.
As long as it's an
71 matches
Mail list logo
