On Fri, Jul 14, 2017 at 08:27:53AM +0200, Christian Couder wrote:
> The whole thing seems really complex to me though. And this makes me
> think that people might want to specify different GIT-BUILD-OPTIONS
> and config.mak files to be used when running perf tests, so that the
> results from perf
It was possible before v2.13.3 to invoke:
git config alias.CamelCased
git CamelCased
This regressed (due to a stupid mistake of mine that was not caught in
patch review, sadly) in v2.13.3.
And this patch series fixes it again, introducing a regression test to
ensure that it does
It is totally legitimate to add CamelCased aliases, but due to the way
config keys are compared, the case does not matter.
Except that now it does: the alias name is expected to be all
lower-case. This is a regression introduced by a9bcf6586d1 (alias: use
the early config machinery to expand alias
It is totally legitimate to add CamelCased aliases, but due to the way
config keys are compared, the case does not matter.
Therefore, we must compare the alias name insensitively to the config
keys.
This fixes a regression introduced by a9bcf6586d1 (alias: use
the early config machinery to expand
On 14/07/17 06:49, Lutz Roeder wrote:
Using precomposeunicode still reproduces the issue:
Repro steps:
1. Download https://www.dropbox.com/s/0q5pbpqpckwzj7b/gitstatusrepro.zip?dl=0
2. unzip gitstatusrepro.zip && cd gitstatusrepro
3. git reset --hard
4. git -c core.precomposeunicode=true statu
Schönen Tag,
Brauchen Sie eine finanzielle Unterstützung? Brauchen Sie einen legitimen
Kredit für Zinsen? Brauchen Sie ein Business-Darlehen? Brauchen Sie ein
Darlehen, um ein Haus zu kaufen, Auto, zahlen Sie Ihre Rechnungen und Schulden?
Brauchen Sie Geld, um Probleme zu lösen? Wenn so freund
On Fri, Jul 14, 2017 at 10:39:24AM +0200, Johannes Schindelin wrote:
> It was possible before v2.13.3 to invoke:
>
> git config alias.CamelCased
> git CamelCased
>
> This regressed (due to a stupid mistake of mine that was not caught in
> patch review, sadly) in v2.13.3.
Interestin
For what it's worth, the file looks normal in Gentoo GNU/Linux (name
appears "ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).
On Fri, Jul 14, 2017 at 4:41 AM, Torsten Bögershausen wrote:
>
>
> On 14/07/17 06:49, Lutz Roeder wrote:
>>
>> Using precomposeunicode still reproduces the iss
On Thu, Jul 13, 2017 at 12:27:41PM -0700, Junio C Hamano wrote:
> > I agree it's a bit gross. Possibly:
> >
> > git log --format='%C(auto)%d %s'
> >
> > would be easier for the test to parse (I'm pretty sure that didn't exist
> > back when this test was written).
>
> Yeah, that may make the tes
On Thu, Jul 13, 2017 at 02:53:17PM -0700, Junio C Hamano wrote:
> >> Unfortunately, https://travis-ci.org/git/git/builds/ shows that it
> >> does not care if it spawned a job to build the tip of 'maint' and
> >> another for 'v2.13.3' that point at the same thing.
> >
> > That is indeed suprising a
(Please no top-posting)
On 14/07/17 11:45, Elliot Chandler wrote:
For what it's worth, the file looks normal in Gentoo GNU/Linux (name appears
"ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).
Thanks for testing -
Normal and Normal ;-)
For me the 6th code point does look strange
The
This patch series enables git to request missing objects when they are
not found in the object store. This is a fault-in model where the
"read-object" sub-process will fetch the missing object and store it in
the object store as a loose, alternate, or pack file. On success, git
will retry the opera
This patch series enables git to request missing objects when they are
not found in the object store. This is a fault-in model where the
"read-object" sub-process will fetch the missing object and store it in
the object store as a loose, alternate, or pack file. On success, git
will retry the opera
On Fri, Jul 14, 2017 at 02:35:52PM +0200, Torsten Bögershausen wrote:
> (Please no top-posting)
> On 14/07/17 11:45, Elliot Chandler wrote:
> > For what it's worth, the file looks normal in Gentoo GNU/Linux (name
> > appears "ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).
> >
> Thanks
On Jul 14 2017, Torsten Bögershausen wrote:
> (Please no top-posting)
> On 14/07/17 11:45, Elliot Chandler wrote:
>> For what it's worth, the file looks normal in Gentoo GNU/Linux (name
>> appears "ḋἲ╓εﮯ𒑏○╓Ӳ" and it seems to work like any other directory).
>>
> Thanks for testing -
> Normal and N
On Thu, 2017-07-13 at 10:58 -0700, Junio C Hamano wrote:
> I think many people know about and do use the "delete all lines"
> (i.e. ":1,$d" in vi, or \M-< \C-SPC \M-> \C-w in Emacs) to abort out
> of a commit or a merge. I just do not think it is likely for them
> to leave Sign-off lines and remov
Hello,
Originally, when I first had Git Bash everything was working
perfectly. Randomly one day, my bash commands were not working. I
uninstalled Git Bash an reinstalled it. I have been trying for 3 weeks
to get it to work again. I am working on Windows 10. I have tried
editing the PATH variables
Hi, Junio. Thanks for replying.
> I postponed it when I saw it the first time to see if anybody
> comments on it, and then it turns out nobody was interested, and it
> remained uninteresting to the list to this day.
>
True, that's what I was afraid of, but I wanted to give it some closure.
>
On Thu, Jul 13, 2017 at 8:11 PM, Shawn Pearce wrote:
> In another (Gerrit Code Review), we disable reflogs for
> the insane refs/changes/ namespace, as nearly every reference is
> created once, and never modified.
Apologies for the tangent, but this is not true in the most recent
Gerrit implement
Hi Kavita,
On Fri, 14 Jul 2017, Kavita Desai wrote:
> Originally, when I first had Git Bash everything was working
> perfectly. Randomly one day, my bash commands were not working.
There are a gazillion ways how commands can "not work". You *need* to be
more specific here. In the least, a precis
Sorry for not being specific. What I meant by not working was that the
bash commands are not found.
Here is an example
$ ls
bash: ls: command not found
Kavita
On Fri, Jul 14, 2017 at 9:28 AM, Johannes Schindelin
wrote:
> Hi Kavita,
>
> On Fri, 14 Jul 2017, Kavita Desai wrote:
>
>> Originally, w
Hi all,
just to let you know that repository-local aliases stopped working in
v2.13.3. This is due to my "aliases via early config" work that made it
into a maintenance release...
The bug is fixed in master already, and I cherry-picked Brandon's config-h
series that contains the fix into Git for
On Fri, 2017-07-14 at 09:34 -0500, Kavita Desai wrote:
> Sorry for not being specific. What I meant by not working was that the
> bash commands are not found.
> Here is an example
>
> $ ls
> bash: ls: command not found
The most obvious issue is your PATH is wrong.
What does "echo $PATH" show?
W
This patch series reimplements the expensive pre- and post-processing of
the todo script in C.
And it concludes the work I did to accelerate rebase -i so far.
I am still unwilling to replace a compile-time safe way to pass the
options to the revision machinery by the alternative (which I am still
The first step of an interactive rebase is to generate the so-called "todo
script", to be stored in the state directory as "git-rebase-todo" and to
be edited by the user.
Originally, we adjusted the output of `git log ` using a simple
sed script. Over the course of the years, the code became more
To avoid problems with short SHA-1s that become non-unique during the
rebase, we rewrite the todo script with short/long SHA-1s before and
after letting the user edit the script. Since SHA-1s are not intuitive
for humans, rebase -i also provides the onelines (commit message
subjects) in the script,
The commands used to be indented, and it is nice to look at, but when we
transform the SHA-1s, the indentation is removed. So let's do away with it.
For the moment, at least: when we will use the upcoming rebase--helper
to transform the SHA-1s, we *will* keep the indentation and can
reintroduce it
An upcoming patch will move the todo list generation into the
rebase--helper. An early version of that patch regressed on an empty
rebase.instructionFormat value (the shell version could not discern
between an empty one and a non-existing one, but the C version used the
empty one as if that was int
This is crucial to improve performance on Windows, as the speed is now
mostly dominated by the SHA-1 transformation (because it spawns a new
rev-parse process for *every* line, and spawning processes is pretty
slow from Git for Windows' MSYS2 Bash).
Signed-off-by: Johannes Schindelin
---
builtin
These tests were a bit anal about the *exact* warning/error message
printed by git rebase. But those messages are intended for the *end
user*, therefore it does not make sense to test so rigidly for the
*exact* wording.
In the following, we will reimplement the missing commits check in
the sequenc
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Signed-off-by: Johannes Schindelin
---
builtin/rebase--helper.c | 7 +-
git-rebase--intera
The `git commit --fixup` command unwraps wrapped onelines when
constructing the commit message, without wrapping the result.
We need to make sure that `git rebase --autosquash` keeps handling such
cases correctly, in particular since we are about to move the autosquash
handling into the rebase--he
In particular on Windows, where shell scripts are even more expensive
than on MacOSX or Linux, it makes sense to move a loop that forks
Git at least once for every line in the todo list into a builtin.
Note: The original code did not try to skip unnecessary picks of root
commits but punts instead
This operation has quadratic complexity, which is especially painful
on Windows, where shell scripts are *already* slow (mainly due to the
overhead of the POSIX emulation layer).
Let's reimplement this with linear complexity (using a hash map to
match the commits' subject lines) for the common cas
Jeff King writes:
> Right, I think the right solution is some amount of peeling. Recognizing
> that the commit sha1 is the same, or better yet, not bothering to retest
> trees which have already been tested.
Yup, I also have a hack to avoid testing a version that is only
different in insignifica
Here are the results.
What does "echo $PATH" show?
/c/Users/Kavita/
What does "type -a ls" show?
ls is aliased to `ls -F --color=auto --show-control-chars'
On Fri, Jul 14, 2017 at 9:37 AM, Paul Smith wrote:
> On Fri, 2017-07-14 at 09:34 -0500, Kavita Desai wrote:
>> Sorry for not being specif
Jeff King writes:
> On Fri, Jul 14, 2017 at 10:39:24AM +0200, Johannes Schindelin wrote:
>
>> It was possible before v2.13.3 to invoke:
>>
>> git config alias.CamelCased
>> git CamelCased
>>
>> This regressed (due to a stupid mistake of mine that was not caught in
>> patch review, sa
On Fri, 2017-07-14 at 09:59 -0500, Kavita Desai wrote:
> What does "echo $PATH" show?
> /c/Users/Kavita/
Well, there you go. That's clearly wrong.
You absolutely have to have /bin and /usr/bin on your PATH, _at least_
if you want to be able to run standard UNIX tools. And most likely
you'll hav
On Fri, Jul 14, 2017 at 3:26 PM, Ben Peart wrote:
> diff --git a/contrib/long-running-read-object/example.pl
> b/contrib/long-running-read-object/example.pl
> new file mode 100755
> index 00..b8f37f836a
> --- /dev/null
> +++ b/contrib/long-running-read-object/example.pl
[...]
> +sub pa
Johannes Schindelin writes:
> The bug is fixed in master already, and I cherry-picked Brandon's config-h
> series that contains the fix into Git for Windows' master branch.
As you can see in Documentation/RelNotes/2.14.0.txt, I actually have
been debating myself if that series should be merged d
Santiago Torres writes:
>> Combined with the unknown-ness of the root cause of the issue, I can
>> only say that the patch may be raising an issue worth addressing,
>> but it is too sketchy to tell if it is a right solution or what the
>> exact problem being solved is.
>
> I'll dig into this. Thi
On Fri, Jul 14, 2017 at 08:14:18AM -0700, Junio C Hamano wrote:
> >> It was possible before v2.13.3 to invoke:
> >>
> >>git config alias.CamelCased
> >>git CamelCased
> >>
> >> This regressed (due to a stupid mistake of mine that was not caught in
> >> patch review, sadly) in v2.13.3.
>
On Fri, Jul 14, 2017 at 7:27 AM, Dave Borowitz wrote:
> On Thu, Jul 13, 2017 at 8:11 PM, Shawn Pearce wrote:
>> In another (Gerrit Code Review), we disable reflogs for
>> the insane refs/changes/ namespace, as nearly every reference is
>> created once, and never modified.
>
> Apologies for the ta
On Fri, Jul 14, 2017 at 07:54:16AM -0700, Junio C Hamano wrote:
> > The "git test" script[1] uses this strategy with git-notes as the
> > storage, and I've found it quite useful. I don't think we can rely on
> > git-notes, but I think Travis gives us some storage options. Even just a
> > best-effo
Junio C Hamano writes:
> Oh, absolutely.
>
> Here is another possible test balloon, that may actually be useful
> as an example. I think there is a topic in flight that touches this
> array, unfortunately, so I probably would find another one that is
> more stable for a real follow-up patch to t
Signed-off-by: Ralf Thielow
---
po/de.po | 123 +--
1 file changed, 64 insertions(+), 59 deletions(-)
diff --git a/po/de.po b/po/de.po
index b9e076f93..f4cb9bf2d 100644
--- a/po/de.po
+++ b/po/de.po
@@ -176,26 +176,26 @@ msgid "git appl
Jeff King writes:
> I think there are basically two mental models that are reasonable:
>
> 1. Uppercase in key names is treated the same as lowercase. Therefore
> we must allow "alias.Foo" to match "git foo", but "git Foo" can
> never have a match (in the current schema).
>
> 2. Key
On Fri, Jul 14, 2017 at 9:11 AM, Junio C Hamano wrote:
> - I prefer to keep decl-after-statement out of our codebase. I
>view it as a big plus in code-readability to be able to see a
>complete list of variables that will be used in a block upfront
>before starting to read the code t
FWIW, I don't like 2, I don't like the irregularity in the invocation:
$ git branch
* master
$ git BRANCH
git: 'BRANCH' is not a git command. See 'git --help'.
$ git config alias.br 'branch -v'
$ git br
* master 51c785c initial
$ git BR
* master 51c785c initial
There is also thi
On Fri, Jul 14, 2017 at 7:44 AM, Johannes Schindelin
wrote:
> This patch series reimplements the expensive pre- and post-processing of
> the todo script in C.
>
> And it concludes the work I did to accelerate rebase -i so far.
>
> I am still unwilling to replace a compile-time safe way to pass the
On Fri, Jul 14, 2017 at 09:11:33AM -0700, Junio C Hamano wrote:
> As to other things that we currently not allow in our codebase that
> newer compilers can grok, here is what *I* think. It is *not* meant
> to be an exhaustive "what's new in C99 that is not in C89? what is
> the final verdict on e
On Fri, Jul 14, 2017 at 05:26:00PM +, astian wrote:
> FWIW, I don't like 2, I don't like the irregularity in the invocation:
Without quoting, it took me a second to figure out what you meant. But I
think "2" here is the "mental model 2" I mentioned in my earlier email.
> $ git branch
> *
On Thu, 2017-07-13 at 12:23 -0700, Junio C Hamano wrote:
> All good points; if it bothers you that "commit" and "merge" define
> "emptyness" of the buffer differently too much, I think you could
> persuade me to unify them to "the buffer _must_ contain no bytes",
> i.e. not special-casing sign-off
On Sat, Jul 08, 2017 at 03:17:32AM +0200, Marko Kungla wrote:
> As contrived e.g: if I have in my "workspace" sub directories mostly
> git repositories, but some not and if I exec,
> "for d in */ ; do (cd $d && git check-ref-format --branch @{-1});
> done" then I get 3 possible responses.
>
> git
On Fri, Jul 14, 2017 at 02:03:13PM -0400, Jeff King wrote:
> So I think the patch below is probably the right direction.
And here it is with a real commit message, if this is what we want to
do.
I do feel like "check-ref-format --branch" is a misfeature. The
operation seems to fit better with "r
Jeff King writes:
>> +static int clean_use_color = -1;
>> +static char clean_colors[][COLOR_MAXLEN] = {
>> +[CLEAN_COLOR_RESET] = GIT_COLOR_RESET,
>> +[CLEAN_COLOR_PLAIN] = GIT_COLOR_NORMAL,
>> +[CLEAN_COLOR_PROMPT] = GIT_COLOR_BOLD_BLUE,
>> +[CLEAN_COLOR_HEADER] = GIT_COLOR_BOLD,
Junio C Hamano writes:
> Do we need to have a check to detect a buggy compiler that takes the
> syntax but produces an incorrectly initialized array? I could add a
> test to ensure that HEADER comes out BOLD, etc. (or we may already
> have such a test) and then reorder these lines in this patch,
On Fri, Jul 14 2017, Junio C. Hamano jotted:
> Junio C Hamano writes:
>
> - This may be showing I am not just old fashioned but also am
>ignorant, but I do not see much point in using the following in
>our codebase (iow, I am not aware of places in the existing code
>that they can b
On 07/13, brian m. carlson wrote:
> This is the ninth in a series of series to convert Git to use struct
> object_id. This series converts the remaining callers of get_sha1 and
> friends to take and use struct object_id, and in doing so, renames them
> to get_oid and friends.
>
> This patch shoul
On 7/13/2017 3:39 PM, Jonathan Tan wrote:
On Wed, 12 Jul 2017 13:29:11 -0400
Jeff Hostetler wrote:
My primary concern is scale and managing the list of objects over time.
My fear is that this list will be quite large. If we only want to omit
the very large blobs, then maybe not. But if we
On Thu, Jul 13, 2017 at 05:11:52PM -0700, Shawn Pearce wrote:
> Yes, I was hoping for reader atomicity. But I may OK foregoing that if
> the transaction either all goes through, or all fails. A partially
> stuck transaction because the process died in the middle of the commit
> step creates a mess
On Thu, Jul 13, 2017 at 05:27:44PM -0700, Shawn Pearce wrote:
> > We _could_ consider gzipping individual blocks of
> > a reftable (or any structure that allows you to search to a
> > constant-sized block and do a linear search from there). But given that
> > they're in the same ballpark, I'm happ
Hi,
On Fri, 14 Jul 2017, Paul Smith wrote:
> On Fri, 2017-07-14 at 09:59 -0500, Kavita Desai wrote:
> > What does "echo $PATH" show?
> > /c/Users/Kavita/
>
> Well, there you go. That's clearly wrong.
>
> You absolutely have to have /bin and /usr/bin on your PATH,
As Kavita talks about Git Bas
Hi Stefan,
On Fri, 14 Jul 2017, Stefan Beller wrote:
> On Fri, Jul 14, 2017 at 7:44 AM, Johannes Schindelin
> wrote:
>
> > -static int subject2item_cmp(const struct subject2item_entry *a,
> > - const struct subject2item_entry *b, const void *key)
> > +static int subject2item_cmp(const vo
On Fri, 2017-07-14 at 22:33 +0200, Johannes Schindelin wrote:
> > You absolutely have to have /bin and /usr/bin on your PATH,
>
> As Kavita talks about Git Bash, it is probably Git for Windows, for
> which /bin should not be in the PATH but /mingw64/bin or /mingw32/bin
> (depending on the architec
Jeff Hostetler wrote:
> On 7/13/2017 3:39 PM, Jonathan Tan wrote:
>> I know that discussion has shifted to the possibility of not having this
>> list at all, and not sending size information together with the fetch,
>> but going back to this...maybe omitting trees *is* the solution to both
>> the
Hi Paul,
On Fri, 14 Jul 2017, Paul Smith wrote:
> On Fri, 2017-07-14 at 22:33 +0200, Johannes Schindelin wrote:
> > > You absolutely have to have /bin and /usr/bin on your PATH,
> >
> > As Kavita talks about Git Bash, it is probably Git for Windows, for
> > which /bin should not be in the PATH b
Ævar Arnfjörð Bjarmason writes:
> On Fri, Jul 14 2017, Junio C. Hamano jotted:
>
>> Junio C Hamano writes:
>>
>> - This may be showing I am not just old fashioned but also am
>>ignorant, but I do not see much point in using the following in
>>our codebase (iow, I am not aware of places
Convert grep to use 'struct repository' which enables recursing into
submodules to be handled in-process.
Signed-off-by: Brandon Williams
---
Documentation/git-grep.txt | 7 -
builtin/grep.c | 396 ++---
cache.h| 1 -
gi
Have the index state which is stored in 'the_repository' be a pointer to
the in-core index 'the_index'. This makes it easier to begin
transitioning more parts of the code base to operate on a 'struct
repository'.
Signed-off-by: Brandon Williams
---
repository.c | 4 +++-
1 file changed, 3 inser
Have 'repo_read_index()' behave more like the other read_index family of
functions and don't discard the index if it has already been populated
and instead rely on the quick return of read_index_from which has:
/* istate->initialized covers both .git/index and .git/sharedindex.xxx */
if (istat
Changes in v2:
* small style nits fixed.
* Comment describing function contract for repo_read_index
* NEEDSWORK comment in grep to describe the issue with adding the submodule's
object store as an alternate.
* the_repository->index = &the_index was removed from setup.c and instead this
is done
On Fri, Jul 14, 2017 at 09:11:33AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Oh, absolutely.
> >
> > Here is another possible test balloon, that may actually be useful
> > as an example. I think there is a topic in flight that touches this
> > array, unfortunately, so I probabl
On Fri, Jul 14, 2017 at 7:44 AM, Johannes Schindelin
wrote:
> The first step of an interactive rebase is to generate the so-called "todo
> script", to be stored in the state directory as "git-rebase-todo" and to
> be edited by the user.
>
> Originally, we adjusted the output of `git log ` using a
On Thu, Jul 13 2017, Junio C. Hamano jotted:
Proposed improvements for the release notes (is this a good way to
propose RelNotes changes?)
> An early preview release Git v2.14.0-rc0 is now available for
> testing at the usual places. It is comprised of 675 non-merge
> commits since v2.13.0, con
Jeff King writes:
>> There is also this:
>>
>> $ git branch
>> * master
>> $ git BRANCH
>> git: 'BRANCH' is not a git command. See 'git --help'.
>> $ git config alias.branch 'branch -v'
>> $ git branch
>> * master
>> $ git BRANCH
>> * master 51c785c initial
>
> That is an inter
On Sat, Jul 15, 2017 at 1:17 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Jul 13 2017, Junio C. Hamano jotted:
>> * "git send-email" learned to overcome some SMTP server limitation
>>that does not allow many pieces of e-mails to be sent over a single
>>session.
>
> Makes it sound like
Hi,
Git v2.14.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 30+ updated messages need to be translated since last
update:
l10n: git.pot: v2.14.0 round 1 (34 new, 23 removed)
Generate po/git.pot from v2.14.0-rc0 for git v2.14.0 l10n round 1.
78 matches
Mail list logo
