On Sat, Sep 29, 2018 at 10:27:15PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > And I think this has to be stderr. We're polluting the output of the
> > aliased command with our extra message, so we have two choices:
> >
> > 1. Pollute stderr, and risk copious stdout (or a pager) scr
On Sat, Sep 29, 2018 at 3:11 PM Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
> @@ -72,6 +72,11 @@ Options for `expire`
> +--single-worktree::
> + By default when `--all` is specified, reflo
Jeff King writes:
> And I think this has to be stderr. We're polluting the output of the
> aliased command with our extra message, so we have two choices:
>
> 1. Pollute stderr, and risk copious stdout (or a pager) scrolling it
> off the screen.
>
> 2. Pollute stdout, at which point our
On Sat, Sep 29, 2018 at 3:11 PM Nguyễn Thái Ngọc Duy wrote:
> Make use of the new ref aliases to pass refs from another worktree
> around and access them from the current ref store instead. This does
> not change any functionality, but when a problem arises, we would like
> the reported messages t
On Sat, Sep 29, 2018 at 12:06:38PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Wow, what's old is new again. Here's more or less the same patch from
> > 2012:
> >
> > https://public-inbox.org/git/20120407033417.ga13...@sigill.intra.peff.net/
> >
> > Unfortunately, some people seem t
On Sat, Sep 29, 2018 at 3:10 PM Nguyễn Thái Ngọc Duy wrote:
> The main worktree has to be treated specially because well.. it's
Nit: s/well../well.../
> special from the beginning. So HEAD from the main worktree is
> acccessible via the name "main-worktree/HEAD" instead of
> "worktrees/main/HEAD
On Sat, Sep 29, 2018 at 11:31:08AM -0700, Junio C Hamano wrote:
> > The only funny thing is that you have to "dereference" the iterator like
> > this:
> >
> > struct list_head *pos;
> > struct actual_thing *item;
> > ...
> > item = list_entry(pos, struct actual_thing, list_member);
> >
> >
On Sat, Sep 29, 2018 at 2:55 PM Stephen P. Smith wrote:
> Status variables were initialized in the collect phase and some
> variables were later freed in the print functions.
>
> A "struct wt_status" used to be sufficient for the output phase to
> work. It was designed to be filled in the collect
On Fri, Sep 28, 2018 at 9:55 AM Taylor Blau wrote:
> On Thu, Sep 27, 2018 at 09:49:36PM -0700, Stephen P. Smith wrote:
> > When updating the collect and print functions, it was found that
> > status variables were initialized in the collect phase and some
> > variables were later freed in the prin
On Sat, Sep 29, 2018 at 11:30 AM Nguyễn Thái Ngọc Duy wrote:
> A new repo extension is added, worktreeConfig. When it is present:
> [...]
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -2,8 +2,9 @@ CONFIGURATION FILE
> The Git
On Sat, Sep 29, 2018 at 10:39:54AM -0700, Junio C Hamano wrote:
> Suppose "git foo" is aliased to a command "git bar".
>
> The best case is when "git bar -h" knows that it is asked to give us
> a short usage. We get "foo is aliased to bar" followed by the short
> usage for "bar" and everything i
On Sat, Sep 29, 2018 at 11:30 AM Nguyễn Thái Ngọc Duy wrote:
> In many config-related tests it's common to check if a config variable
> has expected value and we want to print the differences when the test
> fails. Doing it the normal way is three lines of shell code. Let's add
> a function do to
Jeff King writes:
> So yet another alternative here is to just define a single hashmap that
> stores void pointers. That also throws away some type safety, but is
> maybe conceptually simpler. I dunno.
I was tempted to try that route, which would essentially give us "if
you are abusing string-li
Stefan Xenos writes:
> What is the evolve command?
> ...
> - Systems like gerrit would no longer need to rely on "change-id" tags
> in commit comments to associate commits with the change that they
> edit, since git itself would have that information.
> ...
> Is anyone else interested in this? Pl
Hello, List!
I'm interested in porting something like Mercurial's evolve command to
Git. I'll be following up with a formal proposal shortly, but before I
do I thought I'd introduce myself to the list and find out if anyone
else is interested in this topic.
What is the evolve command?
Imagine yo
Jonathan Tan writes:
> This was prompted by a user at $DAY_JOB who had a partial clone
> excluding trees, and had a workflow that only required tree objects (and
> not blobs).
>
> This will hopefully make partial clones excluding trees (with the
> "tree:0" filter) a bit better, in that if an oper
Re: Junio C Hamano 2018-09-29
> I also expect folks who are used to "git grep --re" to summon
> the only option of the command that begins with that prefix to start
> complaining that they now have to type "--recurs" instead.
Fwiw I was just asking about -r. There doesn't have to be a
correspondi
Reported-by: Jeff King
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-reflog.txt | 7 ++-
builtin/reflog.c | 22 +++---
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 47
When multiple worktrees are used, we need rules to determine if
something belongs to one worktree or all of them. Instead of keeping
adding rules when new stuff comes (*), have a generic rule:
- Inside $GIT_DIR, which is per-worktree by default, add
$GIT_DIR/common which is always shared. New fe
fsck is a repo-wide operation and should check all references no
matter which worktree they are associated to.
Reported-by: Jeff King
Helped-by: Elijah Newren
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fsck.c | 55 ++---
t/t1450-fsck.sh | 35 ++
From: Elijah Newren
This will make it easier to check the HEAD of other worktrees from fsck.
Signed-off-by: Elijah Newren
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fsck.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/builtin/fsck.c b/b
Make use of the new ref aliases to pass refs from another worktree
around and access them from the current ref store instead. This does
not change any functionality, but when a problem arises, we would like
the reported messages to mention full ref aliases, like this:
fatal: bad object worktre
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index a7a75b4cc0..9f7268d5fe 100644
--- a/refs.c
+++ b/refs.c
@@ -646,7 +646,7 @@ enum ref_type ref_type(const char *refname)
return REF_TYPE_PER_WORK
v2 changes
- more documentation
- main/ prefix is renamed to main-worktree/ to reduce ambiguation
chances and make it clearer
- refs/local is renamed to refs/worktree
- bug fix in is_main_pseudoref_syntax() and
is_other_pseudoref_syntax()
Interdiff
diff --git a/Documentation/git-worktree.txt
One of the problems with multiple worktree is accessing per-worktree
refs of one worktree from another worktree. This was sort of solved by
multiple ref store, where the code can open the ref store of another
worktree and has access to the ref space of that worktree.
The problem with this is repor
This function is a callback of for_each_reflog() which will pass a ref
name as the first argument, not a path (to a reflog file).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
revision.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index e18bd530e4
Jeff King writes:
> Wow, what's old is new again. Here's more or less the same patch from
> 2012:
>
> https://public-inbox.org/git/20120407033417.ga13...@sigill.intra.peff.net/
>
> Unfortunately, some people seem to rely on this multi-helper behavior. I
> recommend reading the whole thread, as
Junio suggested a cleanup patch, jc/wt-status-state-cleanup, which is
the basis for this patch.
This patch uses ss/wt-status-committable.
Updated commit comment and removed one extra blank line insertion.
Stephen P. Smith (1):
roll wt_status_state into wt_status and populate in the collect phas
Status variables were initialized in the collect phase and some
variables were later freed in the print functions.
A "struct wt_status" used to be sufficient for the output phase to
work. It was designed to be filled in the collect phase and consumed
in the output phase, but over time some fields
On Sun, Sep 23, 2018 at 04:41:32AM -0400, Eric Sunshine wrote:
> > + grep "main/HEAD: detached HEAD points" out
>
> This message doesn't get localized, so no need for
> test_i18ngrep(). Okay.
Don't remind me. I started to mark all strings in fsck for translation
and faced the reality that I
Ramsay Jones writes:
> You probably already know, but I had to add this on top of the 'pu'
> branch to get a clean compile tonight (your 'jc/war-on-string-list'
> branch).
It was not just about squelching a warning but simply broken code
that deserved to be warned/errored. I think what we have
Jeff King writes:
> On Wed, Sep 26, 2018 at 03:59:08PM -0700, Stefan Beller wrote:
>
>> > +struct refname_hash_entry {
>> > + struct hashmap_entry ent; /* must be the first member */
>>
>> $ git grep "struct hashmap_entry" reveals that we have another
>> convention that we follow but not d
On Tue, Sep 25, 2018 at 11:16 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > The main worktree has to be treated specially because well.. it's
> > special from the beginning. So HEAD from the main worktree is
> > acccessible via the name "main/HEAD" (we can't use
> > "worktrees/
Duy Nguyen writes:
> On Wed, Sep 26, 2018 at 03:54:38PM -0400, Ben Peart wrote:
>> +
>> +#define EOIE_SIZE (4 + GIT_SHA1_RAWSZ) /* <4-byte offset> + <20-byte hash>
>> */
>> +#define EOIE_SIZE_WITH_HEADER (4 + 4 + EOIE_SIZE) /* <4-byte signature> +
>> <4-byte length> + EOIE_SIZE */
>
> If you ma
Jeff King writes:
> Right, I'm proposing only to add the extra message and then continue as
> usual.
>
> It is a little funny, I guess, if you have a script which doesn't
> respond to "-h", because you'd get our "foo is aliased to git-bar"
> message to stderr, followed by who-knows-what. But as l
Ævar Arnfjörð Bjarmason writes:
> This --recursive (-r) option does nothing, and is purely here to
> appease people who have "grep -r ..." burned into their muscle memory.
>
> Requested-by: Christoph Berg
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
I personally am not all that sympathetic
I have a repo, but it appears to be specific to staging area state.
It only segfaults when I have a certain file deleted.
Where do you want me to upload it?
On Sat, Sep 29, 2018 at 8:34 AM Duy Nguyen wrote:
>
> On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
> wrote:
> > > #1 refs_resol
On Sat, Sep 29, 2018 at 5:25 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sat, Sep 29 2018, Duy Nguyen wrote:
>
> > On Sat, Sep 29, 2018 at 4:58 PM Ævar Arnfjörð Bjarmason
> > wrote:
> >>
> >> This --recursive (-r) option does nothing, and is purely here to
> >> appease people who have "grep -r ...
On Sat, Sep 29, 2018 at 5:31 PM Ævar Arnfjörð Bjarmason
wrote:
> > #1 refs_resolve_ref_unsafe (refs=0x0,
> > refname=refname@entry=0x55e863062253 "HEAD",
> > resolve_flags=resolve_flags@entry=1, oid=oid@entry=0x7ffdc834b1c0,
> > flags=flags@entry=0x7ffdc834b1bc) at refs.c:1493
refs is NULL. It l
A new repo extension is added, worktreeConfig. When it is present:
- Repository config reading by default includes $GIT_DIR/config _and_
$GIT_DIR/config.worktree. "config" file remains shared in multiple
worktree setup.
- The special treatment for core.bare and core.worktree, to stay
e
In many config-related tests it's common to check if a config variable
has expected value and we want to print the differences when the test
fails. Doing it the normal way is three lines of shell code. Let's add
a function do to all this (and a little more).
This function has uses outside t1300 as
Besides various doc/test changes. v2 has two code changes
- "git config --worktree" on a multiple worktree setup _without_ the
new extension will now barf. The user is supposed to RTFM and enable
the extension manually.
- I failed to update setup code to pick up config from per-worktree
fil
On Sat, Sep 29 2018, Raymond Jennings wrote:
> [New LWP 19644]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `git submodule--helper status'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0
On Sat, Sep 29 2018, Duy Nguyen wrote:
> On Sat, Sep 29, 2018 at 4:58 PM Ævar Arnfjörð Bjarmason
> wrote:
>>
>> This --recursive (-r) option does nothing, and is purely here to
>> appease people who have "grep -r ..." burned into their muscle memory.
>
> GNU grep -r recurses infinitely but Git
[New LWP 19644]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `git submodule--helper status'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 refs_read_raw_ref (type=, referent=,
oid=, refname=, ref_st
On Fri, Sep 28 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Sep 27 2018, Jonathan Nieder wrote:
>
>>> That said, that seems to me like a lot of work to avoid adding some
>>> patches to "next" that belong in "next" anyway. I understand why the
>>> Git for Windows main
On Sat, Sep 29, 2018 at 4:58 PM Ævar Arnfjörð Bjarmason
wrote:
>
> This --recursive (-r) option does nothing, and is purely here to
> appease people who have "grep -r ..." burned into their muscle memory.
GNU grep -r recurses infinitely but Git grep also has --max-depth. How
do these interact? My
This --recursive (-r) option does nothing, and is purely here to
appease people who have "grep -r ..." burned into their muscle memory.
Requested-by: Christoph Berg
Signed-off-by: Ævar Arnfjörð Bjarmason
---
On Sat, Sep 29, 2018 at 4:10 PM Christoph Berg wrote:
>
> I often use "grep -r $patter
I often use "grep -r $pattern" to recursively grep a source tree. If
that takes too long, I hit ^C and tag "git" in front of the command
line and re-run it. git then complains "error: unknown switch `r'"
because "git grep" is naturally recursive.
Could we have "git grep -r" accept the argument for
On Mon, Sep 24, 2018 at 4:21 PM Taylor Blau wrote:
> > @@ -602,6 +605,7 @@ int cmd_config(int argc, const char **argv, const char
> > *prefix)
> >PARSE_OPT_STOP_AT_NON_OPTION);
> >
> > if (use_global_config + use_system_config + use_local_config +
> > + u
On Fri, Sep 28, 2018 at 09:57:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Another way to look at it, which is closer to what I was thinking about,
> is to just view GFW as some alternate universe "next" branch (which by
> my count is ~2-3k commits ahead of master[1]).
> 1. $ git log --max-parents
On Sat, Sep 29, 2018 at 11:14:29AM +0200, SZEDER Gábor wrote:
> > > Note that comparing the cached data in copied and original entries in
> >
> > s/cached data/cached stat data/ ? I was confused for a bit.
>
> No, it's indeed cached data, but now that you mention it, the subject
> line does need
On Sat, Sep 29, 2018 at 07:36:08AM +0200, Duy Nguyen wrote:
> On Fri, Sep 28, 2018 at 06:24:58PM +0200, SZEDER Gábor wrote:
> > When unpack_trees() constructs a new index, it copies cache entries
> > from the original index [1]. prepare_to_write_split_index() has to
> > deal with this, and it has
On Fri, Sep 28, 2018 at 10:18:05AM +0200, Rasmus Villemoes wrote:
> > it, and then it is up to the alias to handle "-h" sensibly.
>
> I'd be nervous about doing this, though, especially if we introduce this
> without a new opt-in config option (which seems to be the direction the
> discussion
On Fri, Sep 28, 2018 at 12:37:16PM -0400, Kyle Hubert wrote:
> When calling the Git Credential Helper that is set in the git config,
> the get command can return a credential. Git immediately turns around
> and calls the store command, even though that credential was just
> retrieved by the Helper
On Fri, Sep 28, 2018 at 05:43:59PM +0200, Martin Ågren wrote:
> Instead of running `test "foo" = "$(bar)"`, we prefix the whole thing
> with `echo`. Comparing to nearby tests makes it clear that this is just
> debug leftover. This line has actually been modified four times since it
> was introduce
On Sat, Sep 29, 2018 at 07:21:36AM +0200, Duy Nguyen wrote:
> On Fri, Sep 28, 2018 at 06:24:59PM +0200, SZEDER Gábor wrote:
> > diff --git a/t/t1701-racy-split-index.sh b/t/t1701-racy-split-index.sh
> > index fbb77046da..5dc221ef38 100755
> > --- a/t/t1701-racy-split-index.sh
> > +++ b/t/t1701-racy
On Fri, Sep 28, 2018 at 11:29:32AM -0700, Daniel Lo wrote:
> I was reviewing the tformat parameters on:
> https://git-scm.com/docs/git-log (middle of the page).
>
> Specifically: %<|(): make the next placeholder take at least until
> Nth columns, padding spaces on the right if necessary
>
> I fo
On Fri, Sep 28, 2018 at 09:50:14AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: CodingGuidelines: document the API in *.h files
>
> It makes it harder to let the API description and the reality drift
> apart if the doc is kept close to the implementation or the header
> of the API. We have
On Fri, Sep 28, 2018 at 10:14:12AM -0700, Stefan Beller wrote:
> > I think other high-level concepts that are _not_ APIs (e.g., file
> > formats, protocol, etc) could go into technical/.
>
> That is what I meant with high level concepts. Anything that talks
> about or implies the existence of a f
On Fri, Sep 28, 2018 at 01:11:26PM -0700, Junio C Hamano wrote:
> > I am mildly against giving names to obvious ones.
>
> Just to make sure nobody listening from sidelines do not
> misunderstand, ones like getwholeline_fd() that takes more than one
> parameter with the same time is a prime exampl
On Fri, Sep 28, 2018 at 03:05:57PM -0700, Taylor Blau wrote:
> > > For example, to advertise only tags, a caller using
> > > 'core.alternateRefsCommand' would have to do:
> > >
> > > $ git config core.alternateRefsCommand ' \
> > > git -C "$1" for-each-ref refs/tags --format="%(objectname)
On Fri, Sep 28, 2018 at 03:04:10PM -0700, Taylor Blau wrote:
> > Well, you also need to pass the path so it knows which repo to look at.
> > Which I think is the primary reason we do it, but behaving differently
> > for each alternate is another option.
>
> Yeah. I think that the clearer argument
63 matches
Mail list logo
