On 29 June 2016 at 08:49, Andy Falanga (afalanga) wrote:
> Is there some sort of strange file caching that happening when
> make starts that, although the local db is updated, I don't get what I'm
> after?
I don't have time to look at your git issue, but I write this quick
note just in case it
On 21 February 2016 at 13:12, Moritz Neeb wrote:
>
> On 02/20/2016 11:58 PM, Seb wrote:
>>
>> I've recently learnt how to consolidate and clean up the master branch's
>> commit history. I've squashed/fixuped many commits thinking these would
>> propagate to the children branches with whom it shar
On 24 February 2016 at 10:05, Seb wrote:
> On Tue, 23 Feb 2016 23:57:06 +0100,
> Moritz Neeb wrote:
>
> [...]
>
>>> OK, I've followed this advice and looked at the dependency graphs in
>>> gitk before and after rebasing, I've managed to obtain what I was
>>> after. The repository now has two bra
On Sat, 22 Dec 2018 at 10:04, Brian Johnson wrote:
>
> Is it possible (or could a flag be added) to have show-branch only
> show the branch hierarchy at the top and not print out the commit
> list?
Does
git show-branch --list
do what you want?
On Thu, 7 Mar 2019 at 09:00, Mike Hommey wrote:
> On Wed, Mar 06, 2019 at 03:14:11PM +0100, Johannes Schindelin wrote:
> >
> > just wanted to express my gratitude for your idea to introduce the `break`
> > command in `git rebase -i`'s todo list. I use it *all* the time now.
>
> +1. Before that, I
that the latest git version is from february, but I can
try anyway :)
Cheers,
David
On Tue, 3 Sep 2019 at 04:11, Bert Wesarg wrote:
> On Mon, Sep 2, 2019 at 6:25 PM Birger Skogeng Pedersen
> wrote:
> > On Sat, Aug 31, 2019 at 12:51 PM Birger Skogeng Pedersen
> > wrote:
> > > In my pursuit to fully utilize git-gui with only using a keyboard, I
> > > suggest that there is a ho
On Tue, 3 Sep 2019 at 22:45, Pratyush Yadav wrote:
>
> Can you try doing a Shift+Tab? For me on Linux, if I hit Shift+Tab, it
> immediately takes me to the "Amend last commit" option. Then I can press
> space to select it and Tab again to get back to the commit message.
Hi Pratyush Yadav,
Yes, w
On Sat, 14 Sep 2019 at 08:07, Marc Branchaud wrote:
> On 2019-09-13 10:32 a.m., Pratyush Yadav wrote:
> > On 13/09/19 12:24PM, Allan Ford wrote:
> >> Not a bug, but a suggestion consideration for “Git Gui”
> >> Can a double click on the file name in the “unstaged” area move the
> >> item to “sta
On Sat, 14 Sep 2019 at 06:51, Bert Wesarg wrote:
> On Fri, Sep 13, 2019 at 4:32 PM Pratyush Yadav wrote:
> > On 13/09/19 12:24PM, Allan Ford wrote:
>
> I miss a general problem description: Whats wrong with the
> single-click on the icon to begin with?
No problem here, but see my other message f
On Sun, 15 Sep 2019 at 05:08, Pratyush Yadav wrote:
> On 15/09/19 02:07AM, David wrote:
> > On Sat, 14 Sep 2019 at 06:51, Bert Wesarg
> > wrote:
> > > I consider adding a second way as not not acceptable. I also consider
> > > double-click on a file in a
On Sun, 15 Sep 2019 at 07:24, Pratyush Yadav wrote:
> On 15/09/19 01:57AM, David wrote:
> > I can't say it strongly enough. Please do not change stage/unstage
> > to require double-click. This would be most unwelcome here, unless it
> > comes with a configuration
On 6 June 2017 at 11:52, Junio C Hamano wrote:
> Samuel Lijin writes:
>
>> For what it's worth, I've never quite understood the "Initial commit"
>> message, because the repository is in a state where there are no
>> commits yet, not when HEAD is pointing to a root commit.
>
> In the context of "s
On 27 June 2013 18:55, Yann Dirson wrote:
> I just ran into a funny edge-case when doing a long rebase: one of
> the rewritten commits got a sha1 starting with one of the abbreviated
> sha1's of a commit still to be applied.
>
> As a result, the rebase stopped with a funny-looking "short SHA1 ...
On 27 June 2013 21:04, Matthieu Moy wrote:
> David writes:
>
>> I'm not sure that rebase could predict the new hashes without actually
>> creating
>> the prior commits? So maybe the "short" SHA1 is "too short"?
>
> It's OK to show the
On 10 August 2013 05:22, Diogo de Campos wrote:
> Had some problems rebasing a large repository, fatal error because a
> short SHA-1 ref was ambiguous.
This recent disussion might also interest you:
http://thread.gmane.org/gmane.comp.version-control.git/229091
--
To unsubscribe from this list: se
My branches are very long so for years I have been doing a lot of scrolling
when using gitk. I have just now discovered how to see a simplified history.
For this example history where commits were added in alphabetical order:
A--B--C--D--H
\
E--F--G--I
\
CORRECTION:
So I hope to see:
* 00a27e0 J
| * 160d232 I
|/
* b981ea0 F
| * daa5b69 H
|/
* 546ae44 B
* 734db0c A
On 28/12/2012, David wrote:
> My branches are very long so for years I have been doing a lot of scrolling
> when using gitk. I have ju
ls that I should be using
instead of continuing to use the scripts that I threw together several
years ago?
David Lang
--
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/majordomo-info.html
e. what they should
be), it's instead an archived 'what is', the result of changes from all
the tools.
The systems are all built with a standard image, but the automation tools
I do have tend to push identical files out to many of the systems (or
files identical except for a couple
(SHA1 and SHA3) and they both
agree that the file has not been tampered with, you should still be in
good shape just using the SHA1 as a reference.
David Lang
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
Mor
al files out to many of the systems (or files
identical except for a couple of lines)
David,
Is there any particular reason you aren't using etckeeper?
not really, I've thought of that as a tool for managing a single system.
Some of the data in configs is sensitive (and much of it
the data from all the branches at the same time.
I guess I could do something with branches on one repository, with a
different worktree for each system, but that seems a bit fragile (one
command with the wrong environment variables and it coudl really tangle
things up)
David Lang
--
To unsub
tween pseudorefs and real refs can correctly
handle notes merges.
This will also enable us to prevent pseudorefs from being updated by
the ref update machinery e.g. git update-ref.
Signed-off-by: David Turner
---
Documentation/git-notes.txt | 12 ++---
builtin/notes.c
Add glossary entries for both concepts.
Pseudorefs and per-worktree refs do not yet have special handling,
because the files refs backend already handles them correctly. Later,
we will make the LMDB backend call out to the files backend to handle
per-worktree refs.
Signed-off-by: David Turner
This version fixes documentation issues found by Eric Sunshine.
It also adds a new patch so as not to create static functions that
aren't immediately used; Eric also noticed that issue.
I refactored the functions to classify a ref into a single public
ref_type function. This makes it easy for ba
Pseudorefs should not be updated through the ref transaction
API, because alternate ref backends still need to store pseudorefs
in GIT_DIR (instead of wherever they store refs). Instead,
change update_ref and delete_ref to call pseudoref-specific
functions.
Signed-off-by: David Turner
Instead of manually writing a pseudoref (in one case) and shelling out
to git update-ref (in another), use the update_ref function. This
is much simpler.
Signed-off-by: David Turner
---
bisect.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff
Now update_ref (via write_pseudoref) does almost exactly what
write_cherry_pick_head did, so we can remove write_cherry_pick_head
and just use update_ref.
Signed-off-by: David Turner
---
sequencer.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a
Add a function ref_type, which categorizes refs as per-worktree,
pseudoref, or normal ref.
Later, we will use this in refs.c to treat pseudorefs specially.
Alternate ref backends may use it to treat both pseudorefs and
per-worktree refs differently.
Signed-off-by: David Turner
---
refs.c | 29
On Tue, 2015-07-28 at 11:18 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Instead of manually writing a pseudoref (in one case) and shelling out
> > to git update-ref (in another), use the update_ref function. This
> > is much simpler.
> >
&
On Tue, 2015-07-28 at 12:01 -0700, Junio C Hamano wrote:
> On top of what work is this series expected to be applied?
I think I started from 'next' as of a few days ago:
commit df7aaa5e3454bbcbb1f142dd6b95b214d0b8efad
Author: Zoë Blade
Date: Tue Jul 21 14:22:46 2015 +0100
userdiff: add s
On Tue, 2015-07-28 at 12:00 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > All-caps files like NOTES_MERGE_REF are pseudorefs, and thus are
> > per-worktree. We don't want multiple notes merges happening at once
> > (in different worktrees), so we want
When we unpack trees into an existing index, we discard the old index
and replace it with the new, merged index. Ensure that this index has
its cache-tree populated. This will make subsequent git status and
commit commands faster.
Signed-off-by: David Turner
Signed-off-by: Brian Degenhardt
On Tue, 2015-07-28 at 12:50 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > When we unpack trees into an existing index, we discard the old index
> > and replace it with the new, merged index. Ensure that this index has
> > its cache-tree populated. This
On Tue, 2015-07-28 at 13:04 -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > David Turner writes:
> >
> >> The work done to produce the cache-tree is work that the commit would
> >> otherwise have to do. So we're spending extra time in o
On Tue, 2015-07-28 at 13:47 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > When we unpack trees into an existing index, we discard the old index
> > and replace it with the new, merged index. Ensure that this index has
> > its cache-tree populated. This
ref to examine; previously, it just looked at HEAD.
Reported-by: Junio C Hamano
Signed-off-by: David Turner
---
branch.c | 15 +
branch.h | 2 +-
builtin/checkout.c | 2 +-
builtin/notes.c | 2 ++
bui
Sorry, this one is on top of next.
On Tue, 2015-07-28 at 17:23 -0400, David Turner wrote:
> Prevent merges to the same notes branch from different worktrees.
> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using the same
> code we use to check that two HEADs in different worktr
This version removes the old patch 2/6, which changed notes to use
normal refs instead of pseudorefs. We don't actually want to forbid
per-worktree notes merge; instead, we want to either ensure that they
don't conflict, or use a completely different merge mechanism. So we
omit this patch.
In ad
Add a function ref_type, which categorizes refs as per-worktree,
pseudoref, or normal ref.
Later, we will use this in refs.c to treat pseudorefs specially.
Alternate ref backends may use it to treat both pseudorefs and
per-worktree refs differently.
Signed-off-by: David Turner
---
refs.c | 26
Add glossary entries for both concepts.
Pseudorefs and per-worktree refs do not yet have special handling,
because the files refs backend already handles them correctly. Later,
we will make the LMDB backend call out to the files backend to handle
per-worktree refs.
Signed-off-by: David Turner
Instead of manually writing a pseudoref (in one case) and shelling out
to git update-ref (in another), use the update_ref function. This
is much simpler.
Signed-off-by: David Turner
---
bisect.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff
Pseudorefs should not be updated through the ref transaction
API, because alternate ref backends still need to store pseudorefs
in GIT_DIR (instead of wherever they store refs). Instead,
change update_ref and delete_ref to call pseudoref-specific
functions.
Signed-off-by: David Turner
Now update_ref (via write_pseudoref) does almost exactly what
write_cherry_pick_head did, so we can remove write_cherry_pick_head
and just use update_ref.
Signed-off-by: David Turner
---
sequencer.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a
I'm looking at dir.c, and there's a bit I'm confused about:
prep_exclude() says:
/*
* .. and .gitignore does not exist before
* (i.e. null exclude_sha1 and skip_worktree is
* not set). Then we can skip loading .
On Thu, 2015-07-30 at 21:09 +0700, Duy Nguyen wrote:
> On Thu, Jul 30, 2015 at 9:32 AM, David Turner
> wrote:
> > I'm looking at dir.c, and there's a bit I'm confused about:
> >
> > prep_exclude() says:
> > /*
> >
On Thu, 2015-07-30 at 19:30 -0400, David Turner wrote:
> On Thu, 2015-07-30 at 21:09 +0700, Duy Nguyen wrote:
> > On Thu, Jul 30, 2015 at 9:32 AM, David Turner
> > wrote:
> > > I'm looking at dir.c, and there's a bit I'm confused
Pseudorefs should not be updated through the ref transaction
API, because alternate ref backends still need to store pseudorefs
in GIT_DIR (instead of wherever they store refs). Instead,
change update_ref and delete_ref to call pseudoref-specific
functions.
Signed-off-by: David Turner
Add a function ref_type, which categorizes refs as per-worktree,
pseudoref, or normal ref.
Later, we will use this in refs.c to treat pseudorefs specially.
Alternate ref backends may use it to treat both pseudorefs and
per-worktree refs differently.
Signed-off-by: David Turner
---
refs.c | 26
Add glossary entries for both concepts.
Pseudorefs and per-worktree refs do not yet have special handling,
because the files refs backend already handles them correctly. Later,
we will make the LMDB backend call out to the files backend to handle
per-worktree refs.
Signed-off-by: David Turner
Instead of manually writing a pseudoref (in one case) and shelling out
to git update-ref (in another), use the update_ref function. This
is much simpler.
Signed-off-by: David Turner
---
bisect.c | 37 -
1 file changed, 8 insertions(+), 29 deletions(-)
diff
Now update_ref (via write_pseudoref) does almost exactly what
write_cherry_pick_head did, so we can remove write_cherry_pick_head
and just use update_ref.
Signed-off-by: David Turner
---
sequencer.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a
Remove a check that would disable the untracked cache for sparse
checkouts. Add tests that ensure that the untracked cache works with
sparse checkouts -- specifically considering the case that a file
foo/bar is checked out, but foo/.gitignore is not.
Signed-off-by: David Turner
---
dir.c
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
die_if_shared_symref. This prevents simultaneous merges to the same
notes branch from different worktrees.
Signed-off-by: David Turner
---
This version addresses Eric Sunshine's critiques of v1. It breaks out
the symref-che
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
die_if_shared_symref. This prevents simultaneous merges to the same
notes branch from different worktrees.
Signed-off-by: David Turner
---
builtin/notes.c | 2 ++
t/t3320-notes-merge-worktrees.sh | 71
Add a new function, die_if_shared_symref, which works like
die_if_checked_out, but for all references. Refactor
die_if_checked_out to work in terms of die_if_shared_symref.
Soon, we will use die_if_shared_symref to protect notes merges in
worktrees.
Signed-off-by: David Turner
---
Oops
On Fri, 2015-07-31 at 15:35 -0400, Eric Sunshine wrote:
> On Fri, Jul 31, 2015 at 3:01 PM, David Turner
> wrote:
> > Add a new function, die_if_shared_symref, which works like
> > die_if_checked_out, but for all references. Refactor
> > die_if_checked
On Fri, 2015-07-31 at 11:46 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
> > die_if_shared_symref. This prevents simultaneous merges to the same
> > notes branch from different worktrees.
>
On Fri, 2015-07-31 at 17:36 -0400, Eric Sunshine wrote:
> On Fri, Jul 31, 2015 at 5:15 PM, David Turner
> wrote:
> > On Fri, 2015-07-31 at 15:35 -0400, Eric Sunshine wrote:
> >> On Fri, Jul 31, 2015 at 3:01 PM, David Turner
> >> wrote:
> >> > Add a
Add a new function, find_shared_symref, which contains the heart of
die_if_checked_out, but works for all symrefs. Refactor
die_if_checked_out to use the same infrastructure as
find_shared_symref.
Soon, we will use find_shared_symref to protect notes merges in
worktrees.
Signed-off-by: David
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes branch from different worktrees.
Signed-off-by: David Turner
---
builtin/notes.c | 5 +++
t/t3320-notes-merge
Using the new worktree-refs/ refs, make bisection per-worktree.
git show-ref presently only handles refs under refs/, so we change
git bisect to use git rev-parse instead.
Signed-off-by: David Turner
---
Documentation/git-bisect.txt | 4 ++--
Documentation/rev-list-options.txt | 14
This is RFC because I'm not sure why show-ref only works on refs/ (and
whether it should learn to look in worktree-refs/). I'm also not sure
whether there are other changes I should make to refs.c to handle
per-worktree refs; I basically did the simplest thing I could think of
to start with.
--
T
ated docs learn that
worktree-refs/ is per-worktree.
The ref-packing functions learn that refs beginning with
worktree-refs/ should not be packed (since packed-refs is common
rather than per-worktree).
Signed-off-by: David Turner
---
Documentation/glossary-content.txt | 3 ++-
refs.c
On Sat, 2015-08-01 at 06:04 +0200, Christian Couder wrote:
>
> Le 1 août 2015 09:01, "David Turner" a
> écrit :
> >
> > This is RFC because I'm not sure why show-ref only works on refs/
> (and
> > whether it should learn to look in worktree-refs/
the global ref namespace
like that.
> I wish we could just make refs/bisect/* (or whatever the current bisect
> code uses) automatically per worktree. I know David dismissed it saying
> that the current code is not set up to allow it easily, but is it
> really a fundamental
> limitati
On Sat, 2015-08-01 at 15:51 +0200, Johan Herland wrote:
> On Sat, Aug 1, 2015 at 12:11 AM, David Turner
> wrote:
> > Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
> > find_shared_symref and die if we find one. This prevents simultaneous
> > merges to th
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes branch from different worktrees.
Signed-off-by: David Turner
---
builtin/notes.c | 6
t/t3320-notes-merge
-off-by: David Turner
---
This reroll fixes issues reported by Eric Sunshine: leaks
and Johan Herland: prepositions and broken &&
---
branch.c | 45 ++---
branch.h | 8
2 files changed, 42 insertions(+), 11 deletions(-)
diff --git a/br
On Sat, 2015-08-01 at 08:51 +0200, Michael Haggerty wrote:
> On 08/01/2015 07:12 AM, Junio C Hamano wrote:
> > On Fri, Jul 31, 2015 at 8:59 PM, Michael Haggerty
> > wrote:
> >>
> >> It seems to me that adding a new top-level "worktree-refs" directory is
> >> pretty traumatic. Lots of people and t
On Mon, 2015-08-03 at 20:55 +0700, Duy Nguyen wrote:
> On Fri, Jul 31, 2015 at 1:06 PM, David Turner
> wrote:
> > Add a function ref_type, which categorizes refs as per-worktree,
> > pseudoref, or normal ref.
>
> For per-worktree refs, you probably should follow c
kup_untracked_recursive, helps untracked_cache_invalidate_path to
perform this operation.
Signed-off-by: David Turner
---
This patch applies on top of dt/untracked-sparse, presently in `pu` at
d2cd01bd. I think only the test part depends on that patch.
Duy, let me know if you think this is t
On Tue, 2015-08-04 at 06:09 +0700, Duy Nguyen wrote:
> On Tue, Aug 4, 2015 at 2:49 AM, David Turner wrote:
> > Simply treating refs/worktree as per-worktree, while the rest of refs/
> > is not, would be a few dozen lines of code. The full remapping approach
> > is likely t
On Wed, 2015-08-05 at 15:55 -0700, Junio C Hamano wrote:
> * dt/untracked-subdir (2015-08-05) 2 commits
> - DONTMERGE: Waiting for an Ack from Duy
> - untracked-cache: fix subdirectory handling
> (this branch uses dt/untracked-sparse.)
>
> This seems to break some tests.
All tests pass for me
kup_untracked_recursive, helps untracked_cache_invalidate_path to
perform this operation.
Signed-off-by: David Turner
---
This version removes debugging cruft. Oops!
---
dir.c | 50 ---
dir.h | 1 +
t/t7063-
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes branch from different worktrees.
Signed-off-by: David Turner
---
This reroll addresses Eric Sunshine's comments on v5.
---
bu
Sorry, that should have included the first patch as well. Will re-send
as .v7
On Mon, 2015-08-10 at 13:43 -0400, David Turner wrote:
> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
> find_shared_symref and die if we find one. This prevents simultaneous
> merges to the s
-off-by: David Turner
---
Please disregard v6.
This version addresses Eric Sunshine's comments on v5. It fixes an error
message and cleans up the code.
---
branch.c | 46 ++
branch.h | 8
2 files changed, 42 insertions(+), 12 dele
Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using
find_shared_symref and die if we find one. This prevents simultaneous
merges to the same notes branch from different worktrees.
Signed-off-by: David Turner
---
builtin/notes.c | 6
t/t3320-notes-merge
On Mon, 2015-08-10 at 18:30 -0400, Eric Sunshine wrote:
> On Mon, Aug 10, 2015 at 1:52 PM, David Turner
> wrote:
> > worktrees: add find_shared_symref
>
> s/worktrees/branch/ perhaps?
Do you mean "this is in branch.c, so should be labeled with branch"?
Because
On Mon, 2015-08-10 at 16:53 -0400, Michael Rappazzo wrote:
> + while ((d = readdir(dir)) != NULL) {
I think it would be useful to break this loop out into a
for_each_worktree function.
While looking into per-worktree ref stuff, I have just noticed that git
prune will delete ob
Using the new refs/worktree/ refs, make bisection per-worktree.
Signed-off-by: David Turner
---
Documentation/git-bisect.txt | 4 ++--
Documentation/rev-list-options.txt | 14 +++---
bisect.c | 2 +-
builtin/rev-parse.c| 6
that refs beginning with
refs/worktree/ should not be packed (since packed-refs is common
rather than per-worktree).
Signed-off-by: David Turner
---
This implements the very simple solution of making refs/worktree/
per-worktree, as we discussed on the PATCH/RFC first version of this
patch.
Note
On Mon, 2015-08-03 at 20:55 +0700, Duy Nguyen wrote:
> On Fri, Jul 31, 2015 at 1:06 PM, David Turner
> wrote:
> > Add a function ref_type, which categorizes refs as per-worktree,
> > pseudoref, or normal ref.
>
> For per-worktree refs, you probably should follow c
es. If you prefer, I can resend the whole
series, but I thought this might be easier.
From 6c86c38f533c6b35db3a557270aab95b342875c9 Mon Sep 17 00:00:00 2001
From: David Turner
Date: Wed, 15 Jul 2015 18:05:28 -0400
Subject: [PATCH 3/5] pseudorefs: create and use pseudoref update and delete
functions
On Tue, 2015-08-11 at 14:10 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > We need a place to stick refs for bisects in progress that is not
> > shared between worktrees. So we use the refs/worktree/ hierarchy.
>
> This is by itself OK, but to help existing
On Tue, 2015-08-11 at 14:10 -0700, Junio C Hamano wrote:
> David Turner writes:
P.S. I noticed an issue with patch 2/2; I had reverted a now-unnecessary
hack, but accidentally reverted the whole file. So I'll need to re-roll
anyway.
--
To unsubscribe from this list: send the line &quo
On Tue, 2015-08-11 at 15:47 -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > David Turner writes:
> >
> >> On Fri, 2015-07-31 at 16:40 -0700, Stefan Beller wrote:
> >>> I am sorry for being late to the review, I looked into coverity today a
Instead of a linear search over common_list to check whether
a path is common, use a trie. The trie search operates on
path prefixes, and handles excludes.
Signed-off-by: David Turner
---
Probably overkill, but maybe we could later use it for making exclude
or sparse-checkout matching faster
that per-worktree refs should not be
packed (since packed-refs is common rather than per-worktree).
Signed-off-by: David Turner
---
Documentation/glossary-content.txt | 5 +++--
path.c | 1 +
refs.c | 32
Instead of common_list having formatting like ! and /, use a struct to
hold common_list data in a structured form.
We don't use 'exclude' yet; instead, we keep the old codepath that
handles info/sparse-checkout and logs/HEAD. Later, we will use exclude.
Signed-off-by: David Tur
Using the new refs/worktree/ refs, make bisection per-worktree.
Signed-off-by: David Turner
---
Documentation/git-bisect.txt | 4 ++--
Documentation/rev-list-options.txt | 14 +++---
bisect.c | 2 +-
builtin/rev-parse.c| 6 --
git
On Thu, 2015-08-13 at 13:15 -0400, Eric Sunshine wrote:
> On Wed, Aug 12, 2015 at 5:57 PM, David Turner
> wrote:
> > diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
> > index 93605f4..28e6dff 100755
> > --- a/t/t0060-path-utils.sh
> &g
On Thu, 2015-08-13 at 14:32 -0400, Michael Rappazzo wrote:
> for_each_worktree iterates through each worktree and invokes a callback
> function. The main worktree (if not bare) is always encountered first,
> followed by worktrees created by `git worktree add`.
Thanks! This will be super-useful!
On Thu, 2015-08-13 at 14:32 -0400, Michael Rappazzo wrote:
> 'git worktree list' uses the for_each_worktree function to iterate,
> and outputs in the format: ' ()'
I'm not sure I'm going to have time to review the whole thing, but I
think we ought to have tests with both bare and non-bare main re
On Thu, 2015-08-13 at 22:16 +0200, Michael Haggerty wrote:
> On 08/13/2015 07:41 PM, David Turner wrote:
> > On Thu, 2015-08-13 at 13:15 -0400, Eric Sunshine wrote:
> >> On Wed, Aug 12, 2015 at 5:57 PM, David Turner
> >> wrote:
> >>> diff --git a/t/t006
On Fri, 2015-08-14 at 10:04 -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > Let's take a step back.
> >
> > We have always had a ton of code that uses `git_path()` and friends to
> > convert abstract things into filesystem paths. Let's take the
> > reference-handling code as an exam
On Fri, 2015-08-14 at 13:27 -0700, Junio C Hamano wrote:
> David Turner writes:
>
> > Random side note: the present workspace path name component is not
> > acceptable for this if alternate ref backends use a single db for
> > storage across all workspaces. That'
: failed to push some refs to
'ssh://remotehost.com/home/user/git/my_repo/'
$ git --version
git version 2.2.0
$ ssh remotehost.com "git --version"
git version 1.7.10.1
Thank you very much,
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
1 - 100 of 2998 matches
Mail list logo