Receiving objects: 100% (1003/1003), 1.15 MiB | 0 bytes/s, done.
Receiving objects: 100% (1861/1861), 11.74 MiB | 4.58 MiB/s, done.
Receiving objects: 100% (474/474), 160.72 KiB | 0 bytes/s, done.
Receiving objects: 100% (7190/7190), 26.02 MiB | 6.53 MiB/s, done.
If the connection is too fast to c
Hi,
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 version: 2.13.0
1. Valid branch name
2. fatal: '@{-1}' is not a valid
Hello all,
I don't know if this is a desired feature, but I noticed that, one some
versions of gpg, gpg tests are skipped when I run a test suite multiple
times.
Cheers!
-Santiago.
On Fri, Jul 07, 2017 at 06:01:59PM -0400, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> When running gpg-re
From: Santiago Torres
When running gpg-relevant tests, a gpg-daemon is ran for a
trash_directory-specific GNUPGHOME. This daemon creates a unix socket on
the target host, and it will be used on subsequent runs of the same test
script. Add a call to kill the agent and flush the sockets of the
rel
On Fri, Jul 7, 2017 at 11:22 PM, Junio C Hamano wrote:
> Luc Van Oostenryck writes:
>
>> At least here, the scenario I gave allow to fully reproduce the problem.
>>
>> Would you like any other information?
>
> Not really. Here is what I locally ran and its output
>
> -- >8 -- cut here -- >8 --
>
Luc Van Oostenryck writes:
> At least here, the scenario I gave allow to fully reproduce the problem.
>
> Would you like any other information?
Not really. Here is what I locally ran and its output
-- >8 -- cut here -- >8 --
#!/bin/sh
mkdir -p /var/tmp/x/lvo && cd /var/tmp/x/lvo || exit
rm
On Wed, Jul 05, 2017 at 11:38:51AM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> >> @@ -636,7 +636,7 @@ static int get_sha1_basic(const char *str, int len,
> >> unsigned char *sha1,
> >> int detached;
> >>
> >> if (interpret_nth_prior_checkout(str, len,
Hi git-folk!
long time no see! I'm trying to do one of those "actually, please
don't" things that turn out to be needed in the field.
I need to open our next "for release" development branch from our
master, but without a couple of disruptive feature branches, which
have been merged into master a
Hello, My name is Gloria C. Mackenzie, i have a Monetary Donation to make for
the less privilege, yourself and your organization, am writing you with a
friend's email, please contact me on mackenzie...@rogers.com
Thanks. All made sense to me after reading them twice.
Dan Fabulich writes:
> Prior to this commit, git-checkout would only switch branches; you
> could use git-checkout-index to copy files from the index to the
> working tree. But in this commit, git-checkout not only subsumes
> the functionality of git-checkout-index but also learns the
> ability t
> -Original Message-
> From: Junio C Hamano [mailto:jch2...@gmail.com] On Behalf Of Junio C
> Hamano
> Sent: Friday, July 7, 2017 2:35 PM
> To: Ben Peart
> Cc: git@vger.kernel.org; benpe...@microsoft.com; pclo...@gmail.com;
> johannes.schinde...@gmx.de; David Turner ;
> p...@peff.net; chri
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
You can find the changes described
On 7/7/2017 2:35 PM, Junio C Hamano wrote:
Ben Peart writes:
On 6/14/2017 2:36 PM, Junio C Hamano wrote:
Ben Peart writes:
Having said all that, I think you are using this ONLY on windows;
perhaps it is better to drop #ifdef GIT_WINDOWS_NATIVE from all of
the above and arrange Makefile t
On 6/27/2017 12:20 PM, Christian Couder wrote:
On Sat, Jun 10, 2017 at 3:40 PM, Ben Peart wrote:
+# fsmonitor works correctly with or without the untracked cache
+# but if it is available, we'll turn it on to ensure we test that
+# codepath as well.
+
+test_lazy_prereq UNTRACKED_CACHE '
+
Ben Peart writes:
> On 6/14/2017 2:36 PM, Junio C Hamano wrote:
>> Ben Peart writes:
>>
Having said all that, I think you are using this ONLY on windows;
perhaps it is better to drop #ifdef GIT_WINDOWS_NATIVE from all of
the above and arrange Makefile to build test-drop-cache only
Kaartic Sivaraam writes:
> The pre-commit-msg hook sample has an example that comments
> the "Conflicts:" part of the merge commmit. It isn't relevant
> anymore as it's done by default since 261f315b ("merge & sequencer:
> turn "Conflicts:" hint into a comment", 2014-08-28).
>
> Add an alternativ
On 6/14/2017 2:36 PM, Junio C Hamano wrote:
Ben Peart writes:
Having said all that, I think you are using this ONLY on windows;
perhaps it is better to drop #ifdef GIT_WINDOWS_NATIVE from all of
the above and arrange Makefile to build test-drop-cache only on that
platform, or something?
I
Dan Fabulich writes:
> I was looking back through git's history, trying to figure out why
> git-checkout has so many features. I was struck by this commit by
> Junio in 2005.
>
> https://github.com/git/git/commit/4aaa702794447d9b281dd22fe532fd61e02434e1
>
>> git-checkout: revert specific paths to
On Fri, Jul 07, 2017 at 08:53:39AM -0700, Junio C Hamano wrote:
> Luc Van Oostenryck writes:
>
> > $ git reset --hard
> > patching file afile.c
>
> Is that a message from something? It does not sound like something
> "git reset --hard" would say.
Indeed, sorry. This is the result of a
Jeff King writes:
> When we're doing a reflog walk (instead of walking the
> actual parent pointers), we may see commits multiple times.
> For this reason, we hold on to the commit buffer for each
> commit rather than freeing it after we've showed the commit.
>
> We should do the same for the par
--
„It takes love over gold” — Dire Straits
> On 7 Jul 2017, at 17:43, Junio C Hamano wrote:
>
> Beat Bolli writes:
>
>> Now that the Unicode 10 has been announced[0], update the character
>> width tables to the new version.
Typo! Could you drop the first "the" from the message?
Thanks,
B
Ben Peart writes:
> For more API/state design purity, I wonder if there should be an
> object_store structure that is passed to each of the object store APIs
> instead of passing the repository object. The repository object could
> then contain an instance of the object_store structure.
>
> That
Johannes Schindelin writes:
> Yes, there are grep versions that behave differently... how did you guess?
>
> I am in the middle of an extended investigation trying to assess how
> feasible it would be to use a native Win32 port of BusyBox (started by
> long-time Git contributor Nguyễn Thái Ngọc D
The sample hook to prepare the commit message before
a commit allows users to opt-in to add the signature
to the commit message. The signature is added at a place
that isn't consistent with the "-s" option of "git commit".
Further, it could go out of view in certain cases.
Add the signature in a w
The pre-commit-msg hook sample has an example that comments
the "Conflicts:" part of the merge commmit. It isn't relevant
anymore as it's done by default since 261f315b ("merge & sequencer:
turn "Conflicts:" hint into a comment", 2014-08-28).
Add an alternative example that replaces it. This ensur
Signed-off-by: Kaartic Sivaraam
---
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 8d1cac062..aff6bf7aa 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -984,7 +984,7 @@ static int rest_is_empty(struct strbuf *
Jeff King writes:
> Prior to this commit, we show both entries with
> identical reflog messages. After this commit, we show
> only the "comes back" entry. See the update in t3200
> which demonstrates this.
>
> Arguably either is fine, as the whole double-entry
> thin
Jeff King writes:
> +test_expect_failure 'walking multiple reflogs shows all' '
> + # We expect to see all entries for all reflogs, but interleaved by
> + # date, with order no the command line breaking ties. We
s/order no/order on/
--
Kyle
Luc Van Oostenryck writes:
> $ git reset --hard
> patching file afile.c
Is that a message from something? It does not sound like something
"git reset --hard" would say.
> $ git co
> fatal: Not tracking: ambiguous information for ref
> refs/remotes//
>
> What can be am
Beat Bolli writes:
> Now that the Unicode 10 has been announced[0], update the character
> width tables to the new version.
>
> [0]
> http://blog.unicode.org/2017/06/announcing-unicode-standard-version-100.html
>
> Signed-off-by: Beat Bolli
> ---
Thanks, again, for keeping an eye on the progre
On Fri, 2017-07-07 at 08:05 -0700, Junio C Hamano wrote:
> That is because I wear multiple hats, because I try to help in
> different ways, and because open source is not a battle to see whose
> idea is more right, but is a cooperative process to find a better
> solution together.
>
Thanks for hel
Ævar Arnfjörð Bjarmason writes:
> Which is why I think we should take Francesco's patch (with fixes from
> feedback), instead of Junio's.
The patch in this discussion is not meant as a replacement for the
one from Francesco. It was meant as a companion patch.
As I view the form of the option
Kaartic Sivaraam writes:
> That said, in case my interpretation that "'prepare-commit-msg' hook is
> not to be shipped due to it's uselessness" is correct, the reply of
> this mail as a whole seems to contradict it.
That is because I wear multiple hats, because I try to help in
different ways, a
On 7/6/2017 10:33 PM, Junio C Hamano wrote:
Stefan Beller writes:
Subject: Re: [RFC/WIP PATCH] object store classification
I thought you are writing different object-store backends and
classifying them into many categories (e.g. local, networked,
telepathic, etc.)
It is a logical next ste
Hi,
Lately I've been caught several time with a problem which,
to me, is a bug. It can easily be reproduced, so I think
It's very possible it has already been reported.
The problem arise when trying to checkout a branch while having
some uncommited changes. The scenario is the following:
Now that the Unicode 10 has been announced[0], update the character
width tables to the new version.
[0] http://blog.unicode.org/2017/06/announcing-unicode-standard-version-100.html
Signed-off-by: Beat Bolli
---
unicode_width.h | 42 +-
1 file changed, 29
On Wed, 2017-07-05 at 12:50 -0700, Junio C Hamano wrote:
> Three things that caught my eyes:
>
> - Between "git commit --cleanup=strip" and "git commit --
> cleanup=verbatim",
> lines that make up this initial instruction section are different.
>
> - "git grep 'Please enter the '" finds that
Hi Michael,
On Thu, 6 Jul 2017, Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 05.07.2017 18:26:
> > Johannes Schindelin writes:
> >
> >> It seems to be a little-known feature of `grep` (and it certainly came
> >> as a surprise to this here developer who believed to know the Unix
On Fri, Jul 07 2017, Stefan Haller jotted:
> Junio C Hamano wrote:
>
>> It turns out that some people use third-party tools that fetch from
>> remote and update the remote-tracking branches behind users' back,
>> defeating the safety relying on the stability of the remote-tracking
>> branches.
>
On Fri, Jul 07, 2017 at 11:24:15AM +0200, Stefan Haller wrote:
> > Let's disable the form that relies on the stability of remote-tracking
> > branches by default, and allow users who _know_ their remote-tracking
> > branches are stable to enable it with a configuration variable.
>
> I'm wondering
On Thu, Jul 06 2017, Junio C. Hamano jotted:
> "git push --force-with-lease=:" makes sure that
> there is no unexpected changes to the branch at the remote while you
> prepare a rewrite based on the old state of the branch. This
> feature came with an experimental option that allows : part
> to
Junio C Hamano wrote:
> It turns out that some people use third-party tools that fetch from
> remote and update the remote-tracking branches behind users' back,
> defeating the safety relying on the stability of the remote-tracking
> branches.
Third-party tools are not the only problem. They may
On Fri, Jul 07, 2017 at 05:14:07AM -0400, Jeff King wrote:
> @@ -3132,7 +3132,10 @@ static struct commit *get_revision_1(struct rev_info
> *revs)
> if (revs->max_age != -1 &&
> (commit->date < revs->max_age))
> continue
On Fri, Jul 07, 2017 at 05:06:10AM -0400, Jeff King wrote:
> +test_expect_failure 'walking multiple reflogs shows all' '
> + # We expect to see all entries for all reflogs, but interleaved by
> + # date, with order no the command line breaking ties. We
> + # can use "sort" on the separ
When doing a reflog walk, we use the commit's date to
do any date limiting. In earlier versions of Git, this could
lead to nonsense results, since a skipped commit would
truncate the traversal. So a sequence like:
git commit ...
git checkout week-old-branch
git checkout -
git log -g --sinc
The reflog-walk system works by putting a ref's tip into the
pending queue, and then "traversing" the reflog by
pretending that the parent of each commit is the previous
reflog entry.
This causes a number of user-visible oddities, as documented
in t1414 (and the commit message which introduced it)
The get_revision_1() function tries to avoid entering its
main loop at all when there are no commits to look at. But
it's perfectly safe to call pop_commit() on an empty list
(in which case it will return NULL). Switching to an early
return from the loop lets us skip repeating the loop
condition be
When git-rev-list sees no pending commits, it shows a usage
message. This works even when reflog-walking is requested,
because the reflog-walk code currently puts the reflog tips
into the pending queue.
In preparation for refactoring the reflog-walk code, let's
explicitly check whether we have any
When we're doing a reflog walk (instead of walking the
actual parent pointers), we may see commits multiple times.
For this reason, we hold on to the commit buffer for each
commit rather than freeing it after we've showed the commit.
We should do the same for the parent list. Right now this is
jus
The reflog-walk code doesn't work with limit_list(). That
function traverses down the real history graph, not the fake
reflog history that get_revision() returns. So it's not
going to actually examine all of the commits we're going to
show, because we'd add them to the pending list only during
the
Since its inception, the general strategy of the reflog-walk
code has been to start with the tip commit for the ref, and
as we traverse replace each commit's parent pointers with
fake parents pointing to the previous reflog entry.
This lets us traverse the reflog as if it were a real
history, but
On Fri, Jul 07, 2017 at 04:36:36AM -0400, Jeff King wrote:
> Here's an updated version of the bug-fix patch, along with the fix for
> the problem that Eric noticed, and some other problems I noticed while
> fixing that one. So I've split these immediate fixes for maint off into
> their own series.
When we encounter an error adding reflogs for a walk, we try
to free any logs we have read. But we didn't free all
fields, meaning that we could in theory leak all of the
"items" array (which would consitute the bulk of the
allocated memory).
This patch adds a helper which frees all of the entries
The add_reflog_for_walk() function keeps a cache mapping
refnames to their reflog contents. We use a cached reflog
entry if available, and otherwise allocate and store a new
one.
Since 5026b47175 (add_reflog_for_walk: avoid memory leak,
2017-05-04), when we hit an error parsing a date-based
reflog
As part of the add_reflog_to_walk() function, we keep a
string_list mapping refnames to their reflog contents. This
serves as a cache so that accessing the same reflog twice
requires only a single copy of the log in memory.
The string_list is initialized via xcalloc, meaning its
strdup_strings fie
Since 39ee4c6c2f (branch: record creation of renamed branch
in HEAD's log, 2017-02-20), a rename on the currently
checked out branch will create two entries in the HEAD
reflog: one where the branch goes away (switching to the
null oid), and one where it comes back (switching away from
the null oid)
On Wed, Jul 05, 2017 at 03:55:08AM -0400, Jeff King wrote:
> The first patch is my original small fix with an extra test. I think
> that would be appropriate for 'maint'. Its behavior still has some
> quirks, but it avoids the confusion that you experienced and has a low
> risk of breaking anythin
58 matches
Mail list logo
