Ævar Arnfjörð Bjarmason, Wed, Dec 20, 2017 19:24:19 +0100:
> diff --git a/INSTALL b/INSTALL
> index ffb071e9f0..808e07b659 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -84,9 +84,24 @@ Issues of note:
>
> GIT_EXEC_PATH=`pwd`
> PATH=`pwd`:$PATH
> - GITPERLLIB=`pwd`/perl/blib/lib
> +
On Wed, Dec 20, 2017 at 8:40 AM, Cristian Achim wrote:
> All I will do is paste the stackoverflow question below. It covers the
> commands I made in chronological order and the way I would have
> expected git to behave differently.
>
> So I did
>
> git pull home_subfolder
>
This by itself should
On Tue, 19 Dec 2017, Junio C Hamano wrote:
> That (and existing) uses of printf() all feel a bit overkill ;-)
> Perhaps putchar() would suffice.
>
> I am not sure if the above wants to become something like
>
> for (i = 0; i < istate->cache_nr; i++) {
> putchar(istate->cache[
I was compiling origin/master today with the DEVELOPER compiler flags
today and was greeted by
t/helper/test-lazy-init-name-hash.c: In function ‘cmd_main’:
t/helper/test-lazy-init-name-hash.c:172:5: error: ‘nr_threads_used’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
On Wed, Dec 20, 2017 at 5:40 PM, Cristian Achim wrote:
> All I will do is paste the stackoverflow question below. It covers the
> commands I made in chronological order and the way I would have
> expected git to behave differently.
>
> So I did
>
> git pull home_subfolder
>
> while in usb_subfolde
v2:
* squashed the test patch and the bugfix, rewriting the commit message entirely.
This might not the way Jonathan imagined how I address the potential user
confusion[1], but I think it does the job.
[1]
https://public-inbox.org/git/2017122148.gj240...@aiede.mtv.corp.google.com/
v1:
T
Keep the local branch name as the upstream branch name to avoid confusion.
Signed-off-by: Stefan Beller
---
t/lib-submodule-update.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index 38dadd2c29..d7699046f6 100755
It turns out that this buggy test passed due to the buggy implementation,
which will soon be corrected. Let's fix the test first.
Signed-off-by: Stefan Beller
---
t/lib-submodule-update.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
When using hard reset or forced checkout with the option to recurse into
submodules, the submodules need to be reset, too.
It turns out that we need to omit the duplicate old argument to read-tree
in all forced cases to omit the 2 way merge and use the more assertive
behavior of reading the specif
The function same(a, b) is used to check if two entries a and b are the
same. As the index contains the staged files the same() function can be
used to check if files between a given revision and the index are the same.
In case of submodules, the gitlink entry is showing up as not modified
despit
On Wed, Dec 20, 2017 at 4:40 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Wed, Dec 20 2017, Eric Sunshine jotted:
>> On Wed, Dec 20, 2017 at 2:38 PM, Ævar Arnfjörð Bjarmason
>> wrote:
>>> +test_expect_success 'commit --fixup -m"something" -m"extra"' '
>>> + commit_for_rebase_autosquash_setup &&
On Wed, Dec 20 2017, Eric Sunshine jotted:
> On Wed, Dec 20, 2017 at 2:38 PM, Ævar Arnfjörð Bjarmason
> wrote:
>> Add support for supplying the -m option with --fixup. Doing so has
>> errored out ever since --fixup was introduced. Before this, the only
>> way to amend the fixup message while com
On Mon, 18 Dec 2017, Alex Vandiver wrote:
> dd9005a0a ("fsmonitor: delay updating state until after split index is
> merged", 2017-10-27) began deferring the setting of the
> CE_FSMONITOR_VALID flag until later, such that do_read_index() does
> not perform those steps. This means that t/helper/tes
On Tue, 19 Dec 2017, Junio C Hamano wrote:
> Alex Vandiver writes:
>
> > Subject: Re: [PATCH 2/6] fsmonitor: Add dir.h include, for
> > untracked_cache_invalidate_path
>
> Perhaps
>
> "Subject: fsmonitor.h: include dir.h"
Certainly more concise.
> But I am not sure if this is a right directi
Ævar Arnfjörð Bjarmason wrote:
> On Wed, Dec 20, 2017 at 6:41 PM, Todd Zullinger wrote:
>> /usr/share/perl5/vendor_perl/Git
>> /usr/share/perl5/vendor_perl/Git.pm
>> /usr/share/perl5/vendor_perl/Git/Error.pm
>> [...]
>> /usr/share/perl5/vendor_perl/build
>> /usr/share/perl5/vendor_perl/build/lib
>
On Wed, Dec 20, 2017 at 2:38 PM, Ævar Arnfjörð Bjarmason
wrote:
> Add support for supplying the -m option with --fixup. Doing so has
> errored out ever since --fixup was introduced. Before this, the only
> way to amend the fixup message while committing was to use --edit and
> amend it in the edit
On Wed, Dec 20, 2017 at 2:38 PM, Ævar Arnfjörð Bjarmason
wrote:
> Document that providing any of -c, -C, -F and --fixup along with -m
> will result in an error. Some variant of this has been errored about
> explicitly since 0c091296c0 ("git-commit: log parameter updates.",
> 2005-08-08), but the d
On 12/20/2017 11:33 AM, Jeff King wrote:
On Wed, Dec 20, 2017 at 02:42:42PM +, Jeff Hostetler wrote:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9593bfa..9ccdf2b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -3082,6 +3082,11 @@ status.s
Add support for supplying the -m option with --fixup. Doing so has
errored out ever since --fixup was introduced. Before this, the only
way to amend the fixup message while committing was to use --edit and
amend it in the editor.
The use-case for this feature is one of:
* Leaving a quick note to
Document that providing any of -c, -C, -F and --fixup along with -m
will result in an error. Some variant of this has been errored about
explicitly since 0c091296c0 ("git-commit: log parameter updates.",
2005-08-08), but the documentation was never updated to reflect this.
Signed-off-by: Ævar Arnf
On Wed, Dec 20, 2017 at 11:36 AM, Stefan Beller wrote:
> On Tue, Dec 19, 2017 at 4:01 PM, Jonathan Nieder wrote:
>> Stefan Beller wrote:
>>> On Tue, Dec 19, 2017 at 2:44 PM, Jonathan Nieder wrote:
>>
checkout -f
I think I would expect this not to touch a submodule that
On Tue, Dec 19, 2017 at 4:01 PM, Jonathan Nieder wrote:
> Stefan Beller wrote:
>> On Tue, Dec 19, 2017 at 2:44 PM, Jonathan Nieder wrote:
>
>>> checkout -f
>>> I think I would expect this not to touch a submodule that
>>> hasn't changed, since that would be consistent with its
>
I recently encountered that error when trying to do an interactive
rebase after using filter-branch to remove a file completely in a
repository. I bisected this issue which pointed at this patch. I'm not
sure how it is related as I'm not too familiar with the sequencer code.
I could help in case an
Replace the perl/Makefile.PL and the fallback perl/Makefile used under
NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily
inspired by how the i18n infrastructure's build process works[1].
The reason for having the Makefile.PL in the first place is that it
was initially[2] buildi
On Wednesday 20 December 2017 03:30 AM, Junio C Hamano wrote:
* pw/sequencer-in-process-commit (2017-12-13) 10 commits
(merged to 'next' on 2017-12-13 at ec4d2b9c84)
...
The sequencer infrastructure is shared across "git cherry-pick",
"git rebase -i", etc., and has always spawned "git c
On Wed, Dec 20, 2017 at 12:22 AM, Andreas Urke wrote:
> Thanks for looking into this.
>
> I was able to reproduce it from scratch, but I followed my earlier
> workflow where I first created the subrepos, and then later renamed
> it. At the time I was not able to find any command to rename without
Hi everyone,
The 34th edition of Git Rev News is now published:
https://git.github.io/rev_news/2017/12/20/edition-34/
Thanks a lot to all the contributors and helpers!
Enjoy,
Christian, Jakub and Markus.
Ævar Arnfjörð Bjarmason wrote:
> [Sorry for not CC-ing you on the last version. Forgot to update the
> giant send-email line I'm juggling for this series].
No worries. It is a rather large CC list at this point. :)
> This *.pmc thing is just me being overly clever. Here's a v5 that gets
> rid of
Hi Junio,
On Tue, 19 Dec 2017, Junio C Hamano wrote:
> Alex Vandiver writes:
>
> > These were mistakenly left in when the test was introduced, in
> > 1487372d3 ("fsmonitor: store fsmonitor bitmap before splitting index",
> > 2017-11-09)
> >
> > Signed-off-by: Alex Vandiver
> > ---
> > t/t7519
On Wed, Dec 20, 2017 at 02:42:41PM +, Jeff Hostetler wrote:
> From: Jeff Hostetler
>
> This patch series adds a "--no-ahead-behind" option to status
> to request that it avoid a possibly expensive ahead/behind
> computation for the current branch. Instead, it just prints a
> not up to date
All I will do is paste the stackoverflow question below. It covers the
commands I made in chronological order and the way I would have
expected git to behave differently.
So I did
git pull home_subfolder
while in usb_subfolder. Can't remember the immediate output, but it
included a part about tw
On Wed, Dec 20, 2017 at 11:14:07AM -0500, Jeff King wrote:
> On Wed, Dec 20, 2017 at 02:42:43PM +, Jeff Hostetler wrote:
>
> > Extend stat_tracking_info() to return 1 when the branch is
> > not up to date with its upstream branch and only return 0
> > when they are equal.
>
> This means that
On Wed, Dec 20, 2017 at 02:42:42PM +, Jeff Hostetler wrote:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 9593bfa..9ccdf2b 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -3082,6 +3082,11 @@ status.submoduleSummary::
> submodule
On Wed, Dec 20, 2017 at 02:42:45PM +, Jeff Hostetler wrote:
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index ea029ad..9a2f209 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -120,6 +120,9 @@ configuration variable document
On Wed, Dec 20, 2017 at 02:42:44PM +, Jeff Hostetler wrote:
> From: Jeff Hostetler
>
> Teach "git status --short --branch" to use "--no-ahead-behind"
> flag to skip computing ahead/behind counts for the branch and
> its upstream and just report '[different]'.
How come "--short" and "--long"
On Wed, Dec 20, 2017 at 02:42:43PM +, Jeff Hostetler wrote:
> Extend stat_tracking_info() to return 1 when the branch is
> not up to date with its upstream branch and only return 0
> when they are equal.
This means that callers all need to be updated, but there's no change
that the compiler c
On Wed, Dec 20, 2017 at 02:42:42PM +, Jeff Hostetler wrote:
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index 9f3a78a..6ce8cf8 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -111,6 +111,13 @@ configuration variable documen
From: Jeff Hostetler
Teach "git status --short --branch" to use "--no-ahead-behind"
flag to skip computing ahead/behind counts for the branch and
its upstream and just report '[different]'.
Signed-off-by: Jeff Hostetler
---
Documentation/git-status.txt | 3 +++
remote.c |
From: Jeff Hostetler
This patch series adds a "--no-ahead-behind" option to status
to request that it avoid a possibly expensive ahead/behind
computation for the current branch. Instead, it just prints a
not up to date message in place of the detailed counts.
This idea was previously discussed
From: Jeff Hostetler
Extend stat_tracking_info() to return 1 when the branch is
not up to date with its upstream branch and only return 0
when they are equal.
Signed-off-by: Jeff Hostetler
---
ref-filter.c | 4 ++--
remote.c | 6 --
wt-status.c | 2 +-
3 files changed, 7 insertions(+)
From: Jeff Hostetler
Teach long (normal) status format to respect the --no-ahead-behind
argument and skip the possibly expensive ahead/behind computation
when printing the branch tracking information.
When --no-ahead-behind is given or status.noaheadbehind is true,
status prints "Your branch is
From: Jeff Hostetler
Teach "status --porcelain=v2 --branch" to omit "# branch.ab x y"
when "--no-ahead-behind" argument is used.
This allows the user to omit the (possibly extremely expensive)
ahead/behind computation when not needed.
Signed-off-by: Jeff Hostetler
---
Documentation/config.txt
On Wed, Dec 20, 2017 at 05:14:02AM -0800, William Pursell wrote:
> Current documentation for branch, show-branch, and grep contain the following:
>
> --color[=]
>Show colored matches. The value must be always (the
> default), never, or auto.
>
> This is incorrect, as the default is "
Current documentation for branch, show-branch, and grep contain the following:
--color[=]
Show colored matches. The value must be always (the
default), never, or auto.
This is incorrect, as the default is "auto".
Signed-off-by: William Pursell
---
Documentation/git-branch.txt |
On Tue, Dec 19, 2017 at 10:33:55AM -0800, Junio C Hamano wrote:
> >> Why does prepare_revision_walk() clear the list of pending objects at
> >> all? Assuming the list is append-only then perhaps remembering the
> >> last handled index would suffice.
>
> For that matter, why does it copy, instead
On Tue, Dec 19, 2017 at 07:26:06PM +0100, René Scharfe wrote:
> > That's the same duality we have now with string_list.
>
> Hmm, I thought we *were* discussing string_list?
Right, I guess what I was wondering is if a wrapper over string_list
really ends up any better than having the dual-natured
On Wed, Dec 20, 2017 at 12:43:37PM +0100, Josef Wolf wrote:
> Thanks to you both for your patience with me. Sorry for the late reply, my day
> job was needing me ;-)
>
> On Fri, Dec 15, 2017 at 07:58:14PM +0100, Igor Djordjevic wrote:
> > On 15/12/2017 17:33, Junio C Hamano wrote:
> > >
> > >
On Fri, Dec 15, 2017 at 11:09:17AM -0800, Junio C Hamano wrote:
> Igor Djordjevic writes:
>
> > Junio, what about consecutive runs, while merge conflicts are still
> > unresolved?
>
> The impression I got was that the original running with svn does not
> deal with conflicting situation anyway,
Replace the perl/Makefile.PL and the fallback perl/Makefile used under
NO_PERL_MAKEMAKER=NoThanks with a much simpler implementation heavily
inspired by how the i18n infrastructure's build process works[1].
The reason for having the Makefile.PL in the first place is that it
was initially[2] buildi
Thanks to you both for your patience with me. Sorry for the late reply, my day
job was needing me ;-)
On Fri, Dec 15, 2017 at 07:58:14PM +0100, Igor Djordjevic wrote:
> On 15/12/2017 17:33, Junio C Hamano wrote:
> >
> > $ git fetch
> > $ git checkout -m -B FETCH_HEAD
For some reason,
Hi everybody,
we just stumbled over a situation in which a merge commits
staged changes into the merge commit. This happens when the
merged-in branch does have commits ('main') but has the same
tree ('--allow-empty') as the merge base:
git init
echo eins >a
git add a
git commit -m
On Wed, Dec 20, 2017 at 10:22:06AM +0800, Wei Shuyu wrote:
> On 2017-12-20 04:59, Jonathan Nieder wrote:
>
> > Thanks for writing this. Can you give an example of how I'd use it
> > (ideally in the form of a test in t/ so we avoid this functionality
> > regressing, but if that's not straightforw
On Wed, Dec 13, 2017 at 1:28 PM, Brandon Williams wrote:
> As promised here is an update to the documentation for the path generating
> functions.
Thanks for working on this. Aside from the review comments by
Junio[1], see a few more below. Although I had some familiarity with
the non-repo versio
Thanks for looking into this.
I was able to reproduce it from scratch, but I followed my earlier
workflow where I first created the subrepos, and then later renamed
it. At the time I was not able to find any command to rename without
changing the path (and I was not able find one now either, is th
54 matches
Mail list logo