On Mon, Jun 12, 2017 at 11:16:27PM -0700, Brandon Williams wrote:
> > > *puzzled* Why wasn't this needed before, then? The rest of the patch
> > > should result in no functional change, but this part seems different.
> >
> > Now I'm puzzled, too. The original that got filled in lazily by the
> >
> On 12 Jun 2017, at 19:11, Junio C Hamano wrote:
>
> Sergey Yurzin writes:
>
>> Subject: Re: [PATCH] Fix KeyError "fileSize" in verbose mode
>
> ...
>
>> git-p4.py | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/git-p4.py b/git-p4.py
>> index 8d151da91b969
> On 12 Jun 2017, at 17:52, Junio C Hamano wrote:
>
> "Philip Oakley" writes:
>
>> From: "Lars Schneider"
>>> Many open source projects use github.com for their contribution process.
>>> Although we mirror the Git core repository to github.com [1] we do not
>>> use any other github.com servic
> On 10 Jun 2017, at 14:48, Philip Oakley wrote:
>
> From: "Lars Schneider"
>> Many open source projects use github.com for their contribution process.
>> Although we mirror the Git core repository to github.com [1] we do not
>> use any other github.com service. This is unknown/unexpected to a
> On 10 Jun 2017, at 09:35, Jeff King wrote:
>
> On Fri, Jun 09, 2017 at 10:03:57AM -0700, Jonathan Nieder wrote:
>
>> Would putting a PULL_REQUEST_TEMPLATE and CONTRIBUTING in the
>> top-level directory work? If I'm reading
>> https://help.github.com/articles/setting-guidelines-for-repository
> On 10 Jun 2017, at 03:51, Junio C Hamano wrote:
>
> Jonathan Nieder writes:
>
>> Lars Schneider wrote:
>>
>>> Many open source projects use github.com for their contribution process.
>>> Although we mirror the Git core repository to github.com [1] we do not
>>> use any other github.com serv
Many open source projects use github.com for their contribution process.
Although we mirror the Git core repository to github.com [1] we do not
use any other github.com service. This is unknown/unexpected to a
number of (potential) contributors and consequently they create Pull
Requests against our
On Tue, Jun 13, 2017 at 10:18:07AM +0200, Lars Schneider wrote:
> changes since v1:
> * mention submitGit
> * link to mailing list address instead of mailing list archive
You might want to link to https://git-scm.com/community/, which has a
section on the mailing list at the top. It gives the lis
On Fri, Jun 09, 2017 at 07:19:35PM -0400, Jeff King wrote:
> Should "git add" check whether there's a matching .gitmodules entry for
> the path and issue a warning otherwise?
Here's my attempt at that.
[1/2]: add: warn when adding an embedded repository
[2/2]: t: move "git add submodule" int
Some submodule tests do some setup outside of a test_expect
block. This is bad because we won't actually check the
outcome of those commands. But it's doubly so because "git
add submodule" now produces a warning to stderr, which is
not suppressed by the test scripts in non-verbose mode.
This patch
It's an easy mistake to add a repository inside another
repository, like:
git clone $url
git add .
The resulting entry is a gitlink, but there's no matching
.gitmodules entry. Trying to use "submodule init" (or clone
with --recursive) doesn't do anything useful. Prior to
v2.13, such an entry
I hope you are doing well and this email meet you in good health condition. My
name is Wesley.I`m from the US but currently in Syria for peace keeping
mission. I want to get to know you better, if I may be so bold. I consider
myself an easy-going man, and I am currently looking for a relationsh
On Tue, Jun 13, 2017 at 12:31 AM, René Scharfe wrote:
> Am 12.06.2017 um 21:02 schrieb Ævar Arnfjörð Bjarmason:
>>
>> I only ever use the time offset info to quickly make a mental note of
>> "oh +0200, this guy's in Europe", or "oh -0400 America East". Having
>> any info at all for %Z would allow
> On Tue, 13 Jun 2017, René Scharfe wrote:
> Am 12.06.2017 um 21:02 schrieb Ævar Arnfjörð Bjarmason:
>> Which gives me a pretty good idea of where the people who are making
>> my colleges / collaborators who are making commits all over the world
>> are located, for the purposes of reinforcing
Add a test for the case when only one parameter is passed to '-m'
(move/rename) option.
For example - if 'git branch -m bbb' is run while checked out on aaa
branch, it should rename the currently checked out branch to bbb.
There was no test for this particular case with only one parameter
for -m o
Hi Junio,
On Sat, 10 Jun 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > We are about to change the way aliases are expanded, to use the early
> > config machinery.
> >
> > This machinery reports errors in a slightly different manner than the
> > cached config machinery.
> >
> >
Hi Peff,
On Sat, 10 Jun 2017, Jeff King wrote:
> On Thu, Jun 08, 2017 at 09:53:35PM +0200, Johannes Schindelin wrote:
>
> > When get_value() parses a key/value pair, it is possible that the line
> > number is decreased (because the \n has been consumed already) before the
> > key/value pair is p
Hi Peff,
On Sat, 10 Jun 2017, Jeff King wrote:
> On Thu, Jun 08, 2017 at 09:53:50PM +0200, Johannes Schindelin wrote:
>
> > -char *alias_lookup(const char *alias)
> > [...]
> > {
> > - char *v = NULL;
> > - struct strbuf key = STRBUF_INIT;
> > - strbuf_addf(&key, "alias.%s", alias);
> > -
Hi Peff,
On Sat, 10 Jun 2017, Jeff King wrote:
> On Thu, Jun 08, 2017 at 09:53:53PM +0200, Johannes Schindelin wrote:
>
> > @@ -245,36 +201,37 @@ static int handle_options(const char ***argv, int
> > *argc, int *envchanged)
> >
> > static int handle_alias(int *argcp, const char ***argv)
> >
On Tue, Jun 13, 2017 at 01:02:49PM +0200, Johannes Schindelin wrote:
> > +test_expect_success 'invalid path' '
> > + echo "[bool]var" >invalid &&
> > + test_must_fail git config -f invalid --path bool.var 2>actual &&
> > + test_i18ngrep "line 1" actual
> > +'
> > +
> > test_expect_success '
On Tue, Jun 13, 2017 at 01:21:28PM +0200, Johannes Schindelin wrote:
> > Two optional cleanups here:
> >
> > 1. We don't need to call config_key_is_valid when using a callback. We
> > only needed that to prevent the configset machinery from issuing a
> > warning. It does save us readi
On Tue, Jun 13, 2017 at 01:25:53PM +0200, Johannes Schindelin wrote:
> > But couldn't we just unconditionally do:
> >
> > setup_git_directory_gently();
>
> But of course we can do that! Why on earth did I not think of that...
>
> Will change the code accordingly.
Thanks. I was really worried
The `git stash push` command recently gained the ability to get a
pathspec as its argument to only stash matching files. Calling this
command from a subdirectory does not work, though, as one of the first
things we do is changing to the top level directory without keeping
track of the prefix from w
Hi Peff,
On Tue, 13 Jun 2017, Johannes Schindelin wrote:
> On Sat, 10 Jun 2017, Jeff King wrote:
>
> > On Thu, Jun 08, 2017 at 09:53:50PM +0200, Johannes Schindelin wrote:
> >
> > > -char *alias_lookup(const char *alias)
> > > [...]
> > > {
> > > - char *v = NULL;
> > > - struct strbuf key = S
On Tue, Jun 13, 2017 at 01:42:02PM +0200, Johannes Schindelin wrote:
> > As you probably guessed, I had tried that first and then figured that if
> > I needed to keep the config_key_is_valid() test anyway, I could just as
> > well keep the strbuf around for later use.
> >
> > Will change the code
When expanding an alias in a subdirectory, we setup the git_dir
(gently), read the config, and then restore the "env" (e.g. the current
working directory) so that the command specified by the alias can run
correctly.
What we failed to reset was the git_dir, meaning that in the most common
case, it
When discovering a .git/ directory, we take pains to ensure that its
repository format version matches Git's expectations, and we return NULL
otherwise.
However, we still appended the invalid path to the strbuf passed as
argument.
Let's just reset the strbuf to the state before we appended the .g
Git has this feature which suggests similar commands (including aliases)
in case the user specified an unknown command.
This feature currently relies on a side effect of the way we expand
aliases right now: when a command is not a builtin, we use the regular
config machinery (meaning: discovering
When expanding aliases, the git_dir is set during the alias expansion
(by virtue of running setup_git_directory_gently()).
This git_dir may be relative to the current working directory, and
indeed often is simply ".git/".
When the alias expands to a shell command, we restore the original
working
Instead of discovering the .git/ directory, read the config and then
trying to painstakingly reset all the global state if we did not find a
matching alias, let's use the early config machinery instead.
It may look like unnecessary work to discover the .git/ directory in the
early config machinery
When get_value() parses a key/value pair, it is possible that the line
number is decreased (because the \n has been consumed already) before the
key/value pair is passed to the callback function, to allow for the
correct line to be attributed in case of an error.
However, when git_parse_source() a
We are about to change the way aliases are expanded, to use the early
config machinery.
This machinery reports errors in a slightly different manner than the
cached config machinery.
Let's not get hung up by the precise wording of the message mentioning
the line number. It is really sufficient to
Hi,
On 13/06/17 02:42 AM, Konstantin Khomoutov wrote:
> On Mon, Jun 12, 2017 at 11:42:44PM -0400, liam Beguin wrote:
>
> [...]
>>> Conceptually, the contents of the stash are *not* commits, even
>>> though the implementation happens to use a commit to represent each
>>> stash entry. Perhaps "ha
Johannes Schindelin writes:
> Sadly, I do not think so. It is just different, not better. Maybe less
> redundant... See for yourself:
Yup, I noticed and was referring to this "less redundant" as an
improvement, actually.
> The real fix would indeed be (as mentioned by Brandon elsewhere) to unif
liam Beguin writes:
>> The fact a stash entry is a merge commit of two synthetic commits is an
>> implementation detail. It can be very useful at times for power users,
>> but regular Git users need not be concerned with this.
>>
>> Another fact worth reiterating that what the UI displays to th
Torsten Bögershausen writes:
> That's better ... here is my attempt to improve
That reads well. Thanks.
>
> doc: do not use `rm .git/index` when normalizing line endings
>
> When illustrating how to normalize the line endings, the
> documentation in gitattributes tells the user to `rm
Attension my friend,
Your silent is not helping us on this, please let me know your
response concerning my first letter to you.
Lawson.
Dear Git users,
It is my pleasure to announce that Git for Windows 2.13.1 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.13.0 (May 10th 2017)
New Features
* Comes with Git v2.13.1.
* Comes with Git Credential Manager v1.10.0.
* Comes with O
On 2017-06-12 06:58 PM, Jacob Keller wrote:
Hi,
There's no actual code yet, (forgive me), but I've been thinking back
to a while ago about attempting to find a way to share things like
refs/notes, and similar refs which are usually not shared across a
remote.
By default, those refs are not prop
On 06/13, Jeff King wrote:
> On Mon, Jun 12, 2017 at 11:16:27PM -0700, Brandon Williams wrote:
>
> > > > *puzzled* Why wasn't this needed before, then? The rest of the patch
> > > > should result in no functional change, but this part seems different.
> > >
> > > Now I'm puzzled, too. The origin
On 06/13, Jeff King wrote:
> On Mon, Jun 12, 2017 at 10:52:43PM -0700, Brandon Williams wrote:
>
> > > >> curious: Why get_git_common_dir() instead of get_git_dir()?
> > > >
> > > > Needs to be commondir since the config is stored in the common git
> > > > directory and not a per worktree git dire
Stefan Beller writes:
> When using git-blame lots of lines contain redundant information, for
> example in hunks that consist of multiple lines, the metadata (commit name,
> author, timezone) are repeated. A reader may not be interested in those,
> so darken them. The darkening is not just based
Patrick Steinhardt writes:
> The `git stash push` command recently gained the ability to get a
> pathspec as its argument to only stash matching files. Calling this
> command from a subdirectory does not work, though, as one of the first
> things we do is changing to the top level directory witho
On 2017-06-13 10:41 AM, Marc Branchaud wrote:
So I like your refs/tracking proposal, and hope that it aims for
mirroring a remote's refs, to eventually replace refs/remotes entirely.
To be extra-clear:
I think a refs/tracking hierarchy that starts with notes and maybe some
other bits is a g
Factor out the logic which creates section headers in the config file,
e.g. the 'branch.foo' key will be turned into '[branch "foo"]'.
This introduces no function changes, but is needed for a later change
which adds support for copying branch sections in the config file.
Signed-off-by: Sahil Dua
From: Ævar Arnfjörð Bjarmason
Add a test for how 'git branch -m' handles the renaming of multiple
config sections existing for one branch.
The config format we use is hybrid machine/human editable, and we do
our best to preserve the likes of comments and formatting when editing
the file with git
Add the ability to --copy a branch and its reflog and configuration,
this uses the same underlying machinery as the --move (-m) option
except the reflog and configuration is copied instead of being moved.
This is useful for e.g. copying a topic branch to a new version,
e.g. work to work-2 after su
Johannes Schindelin writes:
> Instead of discovering the .git/ directory, read the config and then
> trying to painstakingly reset all the global state if we did not find a
> matching alias, let's use the early config machinery instead.
s/read/&ing/, I think. My reading hiccupped while trying t
On Tue, Jun 13, 2017 at 8:25 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> When using git-blame lots of lines contain redundant information, for
>> example in hunks that consist of multiple lines, the metadata (commit name,
>> author, timezone) are repeated. A reader may not be intereste
Jeff King writes:
> On Tue, Jun 13, 2017 at 01:42:02PM +0200, Johannes Schindelin wrote:
>
>> > As you probably guessed, I had tried that first and then figured that if
>> > I needed to keep the config_key_is_valid() test anyway, I could just as
>> > well keep the strbuf around for later use.
>>
Stefan Beller writes:
> * As you have an individual color setup, maybe you can fix this
> for you by setting the appropriate slots to your perception of
> dimmed?
I do not think it is possible with only {new,old}{,alternative} 4
colors.
Consider this diff:
context
-B
Sahil Dua writes:
> Add the ability to --copy a branch and its reflog and configuration,
> this uses the same underlying machinery as the --move (-m) option
> except the reflog and configuration is copied instead of being moved.
>
> This is useful for e.g. copying a topic branch to a new version,
Sahil Dua writes:
> Factor out the logic which creates section headers in the config file,
> e.g. the 'branch.foo' key will be turned into '[branch "foo"]'.
>
> This introduces no function changes, but is needed for a later change
> which adds support for copying branch sections in the config fil
Jeff King wrote:
> On Mon, Jun 12, 2017 at 06:38:17PM -0700, Jonathan Nieder wrote:
>> Brandon Williams wrote:
>>> On 06/12, Jonathan Nieder wrote:
Alternatively, could this patch rename git_config_with_options? That
way any other patch in flight that calls git_config_with_options would
On Tue, Jun 13, 2017 at 2:24 AM, Jeff King wrote:
> It's an easy mistake to add a repository inside another
> repository, like:
>
> git clone $url
> git add .
>
> The resulting entry is a gitlink, but there's no matching
> .gitmodules entry. Trying to use "submodule init" (or clone
> with --re
On Tue, Jun 13, 2017 at 6:17 PM, Sahil Dua wrote:
> Factor out the logic which creates section headers in the config file,
> e.g. the 'branch.foo' key will be turned into '[branch "foo"]'.
+CC Junio: This is to be applied, Sahil is using submitgit which
apparently doesn't CC you by default (I don
Sahil Dua writes:
> + cat >expect <<-\EOF &&
> + branch.dest.key1=value1
> + some.gar.b=age
> + branch.dest.key2=value2
> + EOF
> + cat >config.branch <<\EOF &&
> +;; Comment for source
> +[branch "source"]
> + ;; Comment for the source value
> + key1 = value1
> +
On Tue, Jun 13, 2017 at 10:00 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> * As you have an individual color setup, maybe you can fix this
>> for you by setting the appropriate slots to your perception of
>> dimmed?
>
> I do not think it is possible with only {new,old}{,alternative}
On Tue, Jun 13, 2017 at 2:24 AM, Jeff King wrote:
> Some submodule tests do some setup outside of a test_expect
> block. This is bad because we won't actually check the
> outcome of those commands. But it's doubly so because "git
> add submodule" now produces a warning to stderr, which is
> not su
On 06/13, Stefan Beller wrote:
> On Tue, Jun 13, 2017 at 2:24 AM, Jeff King wrote:
>
> > There is a config knob that can disable the (long) hint. But
> > I intentionally omitted a config knob to disable the warning
> > entirely. Whether the warning is sensible or not is
> > generally about contex
Jeff King writes:
> I also waffled on whether we should ask the submodule code
> whether it knows about a particular path. Technically:
>
> git config submodule.foo.path foo
> git config submodule.foo.url git://...
> git add foo
>
> is legal, but would still warn with this patch.
Did you
Stefan Beller writes:
> Here is what currently happens:
>
>>
>> context
>> -B dim oldMoved
>> -B dim oldMoved
>> -B highlight oldMovedAlternative
>> -A highlight oldMovedAlternative
>> -A
Viresh Kumar writes:
>> Going back to the core part of your change, i.e.
>>
>> -foreach my $entry (qw (cccmd cc author self sob body bodycc)) {
>> +foreach my $entry (qw (tocmd cccmd cc author self sob body bodycc)) {
>>
>> to think about it a bit more, I notice that all the existing on
On Tue, Jun 13, 2017 at 10:19 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Here is what currently happens:
>>
>>>
>>> context
>>> -B dim oldMoved
>>> -B dim oldMoved
>>> -B highlight oldMovedAlternative
>>>
Junio C Hamano writes:
> Sahil Dua writes:
>
>> Add the ability to --copy a branch and its reflog and configuration,
>> this uses the same underlying machinery as the --move (-m) option
>> except the reflog and configuration is copied instead of being moved.
>>
>> This is useful for e.g. copying
On Tue, Jun 13, 2017 at 7:10 PM, Junio C Hamano wrote:
> Sahil Dua writes:
>
>> + cat >expect <<-\EOF &&
>> + branch.dest.key1=value1
>> + some.gar.b=age
>> + branch.dest.key2=value2
>> + EOF
>> + cat >config.branch <<\EOF &&
>> +;; Comment for source
>> +[branch "source"]
Stefan Beller writes:
> But you do not want to (yet)? The goal is not to tell you where the bounds
> are, but the goal is to point out that extra care is required for review of
> these particular 3 lines.
And when you _can_ help users in that "extra care" by pointing out
where the boundary is, w
Ævar Arnfjörð Bjarmason writes:
> On Tue, Jun 13, 2017 at 7:10 PM, Junio C Hamano wrote:
>> Indenting using <<- would make it easier to read. I.e.
>>
>> cat >config.branch <<-\EOF &&
>> ;; Comment for ...
>> [branch "source"]
>> ;; Comment for ...
>>
On Tue, Jun 13, 2017 at 10:33 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> But you do not want to (yet)? The goal is not to tell you where the bounds
>> are, but the goal is to point out that extra care is required for review of
>> these particular 3 lines.
>
> And when you _can_ help u
Stefan Beller writes:
> On Tue, Jun 13, 2017 at 10:33 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> But you do not want to (yet)? The goal is not to tell you where the bounds
>>> are, but the goal is to point out that extra care is required for review of
>>> these particular 3 lines
On Tue, Jun 13 2017, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> On Tue, Jun 13, 2017 at 7:10 PM, Junio C Hamano wrote:
>>> Indenting using <<- would make it easier to read. I.e.
>>>
>>> cat >config.branch <<-\EOF &&
>>> ;; Comment for ...
>>> [branch
Hi,
Ævar Arnfjörð Bjarmason wrote:
> So the reason we have this for -m is:
>
> commit 3f59481e33
> Author: Jonathan Nieder
> Date: Fri Nov 25 20:30:02 2011 -0600
>
> branch: allow a no-op "branch -M HEAD"
>
> Overwriting the current branch with a different commit is forbid
On Tue, Jun 13, 2017 at 10:48 AM, Junio C Hamano wrote:
>
> I never said "start and end" (you did). I just wanted the boundary
> of A and B and C clear, so I'd be perfectly happy with:
>
> context
> +A dim
> +A dim
> +A highlight #1
> +C
On Tue, Jun 13 2017, Jonathan Nieder jotted:
> Hi,
>
> Ævar Arnfjörð Bjarmason wrote:
>
>> So the reason we have this for -m is:
>>
>> commit 3f59481e33
>> Author: Jonathan Nieder
>> Date: Fri Nov 25 20:30:02 2011 -0600
>>
>> branch: allow a no-op "branch -M HEAD"
>>
>> Ov
Stefan Beller writes:
> On Tue, Jun 13, 2017 at 10:33 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> But you do not want to (yet)? The goal is not to tell you where the bounds
>>> are, but the goal is to point out that extra care is required for review of
>>> these particular 3 lines
Ævar Arnfjörð Bjarmason wrote:
> On Tue, Jun 13 2017, Jonathan Nieder jotted:
> > Ævar Arnfjörð Bjarmason wrote:
>>> My understanding of that last part is that Jonathan/someone (see
>>> reported-by in that patch) had some script which was renaming
>>> branches, and it was easier for whatever reaso
Am 13.06.2017 um 00:49 schrieb Junio C Hamano:
Michael Giuffrida writes:
For the abbreviated commit hash placeholder ('h'), pretty.c uses
add_again() to cache the result of the expansion, and then uses that
result in future expansions. This causes problems when the expansion
includes whitespac
On 06/13, Johannes Schindelin wrote:
> Instead of discovering the .git/ directory, read the config and then
> trying to painstakingly reset all the global state if we did not find a
> matching alias, let's use the early config machinery instead.
>
> It may look like unnecessary work to discover th
René Scharfe writes:
> Indeed, a very nice bug report!
>
>> I think the call to format_commit_one() needs to be taught to pass
>> 'magic' through, and then add_again() mechanism needs to be told not
>> to cache when magic is in effect, or something like that.
>>
>> Perhaps something along this li
Stefan Beller writes:
> @@ -149,15 +119,17 @@ deinit [-f|--force] (--all|[--] ...)::
> tree. Further calls to `git submodule update`, `git submodule foreach`
> and `git submodule sync` will skip any unregistered submodules until
> they are initialized again, so use this command
Joel Teichroeb writes:
> Ensure the command gives the correct return code
OK. When you know what the correct return code is, we'd prefer to
see it spelled out, i.e.
Ensure that the command succeeds.
Or did you mean that the command outputs nothing?
The test itself looks obviously correct
Joel Teichroeb writes:
> If the return value of merge recurisve is not checked, the stash could end
> up being dropped even though it was not applied properly
s/recurisve/recursive/
> Signed-off-by: Joel Teichroeb
> ---
> t/t3903-stash.sh | 14 ++
> 1 file changed, 14 insertions(+
Joel Teichroeb writes:
> Signed-off-by: Joel Teichroeb
> ---
> t/t3903-stash.sh | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
> index 5399fb05ca..ce4c8fe3d6 100755
> --- a/t/t3903-stash.sh
> +++ b/t/t3903-stash.sh
> @@ -822,6 +822,18
Joel Teichroeb writes:
> If the merge does not have anything to do, it does not unlock the index,
> causing any further index operations to fail. Thus, always unlock the index
> regardless of outcome.
>
> Signed-off-by: Joel Teichroeb
> ---
This one makes sense.
So far, nobody who calls this
On Tue, Jun 13, 2017 at 12:45 PM, Junio C Hamano wrote:
> Joel Teichroeb writes:
>
>> Signed-off-by: Joel Teichroeb
>> ---
>> t/t3903-stash.sh | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
>> index 5399fb05ca..ce4c8fe3d6 100755
>>
On Tue, Jun 13, 2017 at 12:40 PM, Junio C Hamano wrote:
> Joel Teichroeb writes:
>
>> If the return value of merge recurisve is not checked, the stash could end
>> up being dropped even though it was not applied properly
>
> s/recurisve/recursive/
>
>> Signed-off-by: Joel Teichroeb
>> ---
>> t/
Am 13.06.2017 um 20:29 schrieb Junio C Hamano:
René Scharfe writes:
Indeed, a very nice bug report!
I think the call to format_commit_one() needs to be taught to pass
'magic' through, and then add_again() mechanism needs to be told not
to cache when magic is in effect, or something like that
Joel Teichroeb writes:
>>> +test_expect_success 'create in a detached state' '
>>> + test_when_finished "git checkout master" &&
>>> + git checkout HEAD~1 &&
>>> + >foo &&
>>> + git add foo &&
>>> + STASH_ID=$(git stash create) &&
>>> + HEAD_ID=$(git rev-parse --short HEAD
Currently 'discover_git_directory' only looks at the gitdir to determine
if a git directory was discovered. This causes a problem in the event
that the gitdir which was discovered was in fact a per-worktree git
directory and not the common git directory. This is because the
repository config, whi
Changes in v2:
* Fix a small nit in builtin/config.c that Jonathan pointed out.
* Added two patches which ensure that the repository wide config is properly
read by providing 'commondir' as a field in the 'config_options' struct.
Brandon Williams (6):
config: create config.h
config: remov
Move all config related declarations from cache.h to a new config.h
header file. This makes cache.h smaller and allows for the opportunity
in a following patch to only include config.h when needed.
Signed-off-by: Brandon Williams
---
cache.h | 190 +-
Since there is no implementation of the function 'git_config_iter' lets
stop exporting it and remove the prototype from config.h.
Signed-off-by: Brandon Williams
---
config.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/config.h b/config.h
index f7f8b66c5..c70599bd5 100644
--- a/config.h
+
Worktrees present an interesting problem when it comes to the config.
Historically we could assume that the per-repository config lives at
'gitdir/config', but since worktrees were introduced this isn't the case
anymore. There is currently no way to specify per-worktree
configuration, and as such
Stop including config.h by default in cache.h. Instead only include
config.h in those files which require use of the config system.
Signed-off-by: Brandon Williams
---
advice.c | 1 +
alias.c | 1 +
apply.c | 1 +
archive
Commit 2185fde56 (config: handle conditional include when $GIT_DIR is
not set up) added a 'git_dir' field to the config_options struct. Let's
use this option field explicitly all the time instead of occasionally
falling back to calling 'git_pathdup("config")' to get the path to the
local repositor
Peff suggested putting in a new field in struct object_info for the
object contents; I tried it and it seems to work out quite well.
Patch 1 is unmodified from the previous version. Patches 2-3 have been
rewritten, and patch 4 is similar except that the missing-lookup change
is made to sha1_object
In sha1_file.c, there are a few functions that provide information on an
object regardless of its storage (cached, loose, or packed). Looking
through all non-static functions in sha1_file.c that take in an unsigned
char * pointer, the relevant ones are:
- sha1_object_info_extended
- sha1_object_i
In commit 46f0344 ("sha1_file: support reading from a loose object of
unknown type", 2015-05-06), "struct object_info" gained a "typename"
field that could represent a type name from a loose object file, whether
valid or invalid, as opposed to the existing "typep" which could only
represent valid t
In a subsequent patch, packed_object_info() will be modified to use the
delta base cache, so move the relevant code to before
packed_object_info().
Signed-off-by: Jonathan Tan
---
sha1_file.c | 226 +++-
1 file changed, 116 insertions(+), 1
Currently, Git does not support repos with very large numbers of blobs
or repos that wish to minimize manipulation of certain blobs (for
example, because they are very large) very well, even if the user
operates mostly on part of the repo, because Git is designed on the
assumption that every blob r
1 - 100 of 147 matches
Mail list logo
