Hi Junio,
On Wed, 6 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > This is the second iteration of the long-awaited re-roll of the attempt to
> > avoid spawning merge-recursive from the builtin am and use merge_recursive()
> > directly instead.
>
> I wanted to queue this i
Hi Junio,
On Wed, 6 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > To understand why we're not done yet, the crucial point is *not* that the
> > return value encodes the insert position. The crucial point is that
> > despite asking for an index entry matching a specific nam
Hi Duy,
On Wed, 6 Jul 2016, Duy Nguyen wrote:
> On Tue, Jul 5, 2016 at 1:23 PM, Johannes Schindelin
> wrote:
> > The vast majority of error messages in Git's source code which report a
> > bug use the convention to prefix the message with "BUG:".
> >
> > As part of cleaning up merge-recursive to
Hi Junio,
On Wed, 6 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
> > almost 11 years already,...
> > ...Let's start changing that by using the variable name "her_tree" for an
> > equal number of year
Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
almost 11 years already, we demonstrated our disrespect to the pioneers
of software development like Ada Lovelace, Grace Hopper and Margaret
Hamilton, by pretending that each and every software developer is male
("his_tree").
Hi,
On Wed, 6 Jul 2016, Junio C Hamano wrote:
> David Turner writes:
>
> > Signed-off-by: David Turner
> > ---
> > .mailmap | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/.mailmap b/.mailmap
> > index e5b4126..edcae89 100644
> > --- a/.mailmap
> > +++ b/.mailmap
> > @@ -46,6 +
On Thu, Jul 07, 2016 at 01:47:19PM +0200, Johannes Schindelin wrote:
> Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
> almost 11 years already, we demonstrated our disrespect to the pioneers
> of software development like Ada Lovelace, Grace Hopper and Margaret
> Hamilton
W dniu 2016-07-07 o 14:49, Mike Hommey pisze:
> On Thu, Jul 07, 2016 at 01:47:19PM +0200, Johannes Schindelin wrote:
>> Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
>> almost 11 years already, we demonstrated our disrespect to the pioneers
>> of software development like
Hi Mike,
On Thu, 7 Jul 2016, Mike Hommey wrote:
> On Thu, Jul 07, 2016 at 01:47:19PM +0200, Johannes Schindelin wrote:
> > Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for
> > almost 11 years already, we demonstrated our disrespect to the pioneers
> > of software developme
Hi Kuba,
On Thu, 7 Jul 2016, Jakub Narębski wrote:
> Instead of nebulous "fairness" (i.e., be unfair in other direction),
> [...]
There is nothing nebulous about it.
Ciao,
Dscho
The vast majority of error messages in Git's source code which report a
bug use the convention to prefix the message with "BUG:".
As part of cleaning up merge-recursive to stop die()ing except in case of
detected bugs, let's just make the remainder of the bug reports consistent
with the de facto r
This is the second iteration of the long-awaited re-roll of the attempt to
avoid spawning merge-recursive from the builtin am and use merge_recursive()
directly instead.
The *real* reason for the reroll is that I need a libified recursive
merge to accelerate the interactive rebase by teaching the
Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14),
we already accumulate the output in a buffer. The idea was to avoid
interfering with the progress output that goes to stderr, which is
unbuffered, when we write to stdout, which is buffered.
We extend that buffering to allow
Signed-off-by: Johannes Schindelin
---
t/t5520-pull.sh | 30 ++
1 file changed, 30 insertions(+)
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 5d4880e..217b416 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -255,6 +255,36 @@ test_expect_success '--rebase
While working on the patch series that avoids die()ing in recursive
merges, the issue came up that bug reports (i.e. die("BUG: ...")
constructs) should never be translated, as the target audience is the
Git developer community, not necessarily the current user, and hence
a translated message would
It is technically allowed, as per C89, for functions' return type to
be complete structs (i.e. *not* just pointers to structs).
However, it was just an oversight of this developer when converting
Python code to C code in 6d297f8 (Status update on merge-recursive in
C, 2006-07-08) which introduced
The recursive merge machinery is supposed to be a library function, i.e.
it should return an error when it fails. Originally the functions were
part of the builtin "merge-recursive", though, where it was simpler to
call die() and be done with error handling.
The existing callers were already prepa
The data structure passed to the recursive merge machinery has a feature
where the caller can ask for the output to be buffered into a strbuf, by
setting the field 'buffer_output'.
Previously, we simply swallowed the buffered output when showing error
messages. With this patch, we show the output
It can be puzzling to see that was_tracked() asks to get an index entry
by name, but does not take a negative return value for an answer.
The reason we have to do this is that cache_name_pos() only looks for
entries in stage 0, even if nobody asked for any stage in particular.
Let's rewrite the l
There are a couple of places where return values indicating errors
are ignored. Let's teach them manners.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 469741d..3
Last October, we had to change this code to run `git merge-recursive`
in a child process: git-am wants to print some helpful advice when the
merge failed, but the code in question was not prepared to return, it
die()d instead.
We are finally at a point when the code *is* prepared to return errors,
We are about to libify the recursive merge machinery, where we only
die() in case of a bug or memory contention. To that end, we must heed
negative return values as indicating errors.
This requires our functions to be careful to pass through error
conditions in call chains, and for quite a few fun
It is possible that a tree cannot be written (think: disk full). We
will want to give the caller a chance to clean up instead of letting
the program die() in such a case.
Signed-off-by: Johannes Schindelin
---
merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --gi
Previously, callers of merge_trees() or merge_recursive() expected that
code to die() with an error message. This used to be okay because we
called those commands from scripts, and had a chance to print out a
message in case the command failed fatally (read: with exit code 128).
As scripting incur
In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we
changed the code such that it prints the output in one go, to avoid
interfering with the progress output.
Let's make sure that the same holds true when outputting the commit
title: previously, we used several printf() stateme
The recursive merge machinery accumulates its output in an output
buffer, to be flushed at the end of merge_recursive(). At this point,
we forgot to release the output buffer.
When calling merge_trees() (i.e. the non-recursive part of the recursive
merge) directly, the output buffer is never flush
Ever since 66a155b (Enable output buffering in merge-recursive.,
2007-01-14), we had a problem: When the merge failed in a fatal way, all
regular output was swallowed because we called die() and did not get a
chance to drain the output buffers.
To fix this, several modifications were necessary:
-
I am thinking about returning to doing the Git User's Survey, and
I'd like to ask for feedback.
Thanks to generocity of Survs.com, we have been gifted with premium
annual plan (previous surveys always generated quite a large number
of responses). This plan will last (at least; it was usually
auto
Hi Junio,
On Wed, 6 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Okay, so here is the deal: on the development machine where this was
> > developed, I do not have gpg installed. So please take this test case just
> > to make sure that things work as intended for the momen
Johannes Schindelin writes:
>> I doubt this kind fo distraction is desirable in the middle of a
>> seriously heavy series like this one. As a standalone clean-up to
>> turn these directly to "their" that everybody would agree on and can
>> be merged down quickly to 'master' that does not have to
This new test case ensures that we handle commit messages that start
with fixup! or squash! followed by more than one space. While we do
not generate such messages when committing with --fixup/--squash, it
is perfectly legal for users to hand-craft their own fixup messages,
and we heed Postel's law
When rearranging the edit script, we happily mistake the comment
character for a command, and the command for a SHA-1. As a consequence,
when we move fixup! and squash! commits, our logic to skip lines with
already handled SHA-1s mistakenly skips anything but the first
commented-out pick line, too.
For the upcoming rebase--helper work (which will accelerate the
interactive rebase noticably), it is important to verify that the
--gpg-sign option is handled properly.
Please note that this patch does this on the cheap, by verifying that
the expected option is printed in the message of the 'edit'
This is just another patch series in preparation for the rebase--helper.
Relative to v1 of this patch series,
- the grammo fix was backed out because it was picked up separately,
- two new tests were introduced, one demonstrating a bug, the other one
ensuring that the rebase--helper does not i
Hi Junio,
On Thu, 7 Jul 2016, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> I doubt this kind fo distraction is desirable in the middle of a
> >> seriously heavy series like this one. As a standalone clean-up to
> >> turn these directly to "their" that everybody would agree on and
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 7 Jul 2016, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> >> I doubt this kind fo distraction is desirable in the middle of a
>> >> seriously heavy series like this one. As a standalone clean-up to
>> >> turn these directly to
Jakub Narębski writes:
> Also, in all (?) other places we use "ours" and "theirs"; it looks like
> git-am was a strange exception with "ours" and "his" (also, it was/is
> inconsistent in using plural vs singular form). Though perhaps it was
> created before the terminology solidified...
I also
When I try to ```git clone --depth 1 --recursive
https://github.com/davidhalter/jedi-vim.git``` in 2.9.0, it fails with
the message: ```
Cloning into 'jedi-vim'...
remote: Counting objects: 37, done.
remote: Compressing objects: 100% (27/27), done.
remote: Total 37 (delta 1), reused 16 (delta 0), p
See the discussion and bug fix at
http://thread.gmane.org/gmane.comp.version-control.git/297687/focus=297719
This is a known regression in 2.9.0 and the fix is in the master branch already.
(I think Junio will also roll it into 2.9.1)
--
To unsubscribe from this list: send the line "unsubscribe gi
On 2016-07-06 16.57, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> At some point inside the merge, Git calls read-cache.c/ce_compare_data(),
>> to check if the path named "file" is clean.
>> According to the tree information, the path "file" has the sha1 99b633.
>> #Note:
>> #
On Thu, Jul 7, 2016 at 8:03 AM, Jakub Narębski wrote:
> I am thinking about returning to doing the Git User's Survey, and
> I'd like to ask for feedback.
Thanks for doing the survey!
>
> What I'd like to see is how people use Git, which features do they
> use and which tools (maybe there is some
On Wed, Jul 06, 2016 at 12:26:19PM -0700, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > @@ -426,6 +433,15 @@ int cache_tree_update(struct index_state *istate, int
> > flags)
> > i = update_one(it, cache, entries, "", 0, &skip, flags);
> > if (i < 0)
> > return i
Torsten Bögershausen writes:
> This is the callstack:
>
> merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1,
> const char *path, int stage, int refresh, int options)
> {
> struct cache_entry *ce;
> ce = make_cache_entry
> if (!ce)
>
% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at
'/home/erik/git/salt/archive-extracted-xz'
% test -d /home/erik/git/salt/archive-extracted-xz || echo "directory doesn't
exist"
directory doesn't exist
% git --version
git version 2.9.0
I know
Duy Nguyen writes:
> I'll deal with that separately. Let's focus on cache-tree only this
> time. So how about this on top?
I was hoping that you would limit the scope of the test to check if
write-tree does the right thing. i.e. not test "git commit", but
test "git write-tree".
--
To unsubscri
Tools interacting with Git repositories may need to know the complete
state of the working directory. For efficiency, it would be good to have
a single command to obtain this information.
We already have a `--porcelain` mode intended for tools' consumption,
and it only makes sense to enhance this
Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects)
if a repository has bitmap index, pack-objects can nicely speedup
"Counting objects" graph traversal phase. That however was done only for
case when resultant pack is sent to stdout, not written into a file.
We can teach pack-
Stefan Beller writes:
> The functions `mk_repo_pair` as well as `test_refs` are borrowed from
> t5543-atomic-push, with additional hooks installed.
>
> Signed-off-by: Stefan Beller
> ---
> t/t5544-push-options.sh | 101
>
> 1 file changed, 101 i
On Thu, Jul 7, 2016 at 12:51 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> The functions `mk_repo_pair` as well as `test_refs` are borrowed from
>> t5543-atomic-push, with additional hooks installed.
>>
>> Signed-off-by: Stefan Beller
>> ---
>> t/t5544-push-options.sh | 101
>> +++
write_file() either returns 0 or dies, so there is no point in checking
its return value. The callers of the wrappers write_state_text(),
write_state_count() and write_state_bool() consequently already ignore
their return values. Stop pretenting we care and make them void.
Signed-off-by: Rene Sc
Use the open(2) flag O_EXCL to ensure the file doesn't already exist
instead of (racily) calling stat(2) through file_exists(). While at it
switch to xopen() to reduce code duplication and get more consistent
error messages.
Signed-off-by: Rene Scharfe
---
notes-merge.c | 6 +-
1 file chang
Set the diff attribute for C source file to "cpp" in order to improve
git's ability to determine hunk headers. In particular it helps avoid
showing unindented labels in hunk headers. That in turn is useful for
git diff -W and git grep -W, which show whole functions now instead of
stopping at a la
Stefan Beller writes:
> As we first want to focus on getting simple strings to work
> reliably, we go with the last option for now.
OK.
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> index d82e912..c875cde 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation
On Thu, Jul 07, 2016 at 10:02:14PM +0200, René Scharfe wrote:
> write_file() either returns 0 or dies, so there is no point in checking
> its return value. The callers of the wrappers write_state_text(),
> write_state_count() and write_state_bool() consequently already ignore
> their return value
Stefan Beller writes:
> While documenting
> this, fix a nit in the `receive.advertiseAtomic` wording.
>
> receive.advertiseAtomic::
> By default, git-receive-pack will advertise the atomic push
> - capability to its clients. If you don't want to this capability
> + capability to
On Thu, Jul 07, 2016 at 10:08:30PM +0200, René Scharfe wrote:
> Use the open(2) flag O_EXCL to ensure the file doesn't already exist
> instead of (racily) calling stat(2) through file_exists(). While at it
> switch to xopen() to reduce code duplication and get more consistent
> error messages.
T
On Wed, Jul 06, 2016 at 02:39:26PM -0700, Junio C Hamano wrote:
> * nd/ita-cleanup (2016-07-01) 3 commits
> (merged to 'next' on 2016-07-06 at f15aeba)
> + grep: fix grepping for "intent to add" files
> + t7810-grep.sh: fix a whitespace inconsistency
> + t7810-grep.sh: fix duplicated test name
We unconditionally link with librt, when HAVE_CLOCK_GETTIME is defined.
But clock_gettime() has been available in most libc implementations for
some time now (e.g., for glibc since version 2.17) and no longer
requires linking with librt. Furthermore, commit a6c3c63 (configure.ac:
check for clock_ge
On Thu, Jul 07, 2016 at 10:09:17PM +0300, Kirill Smelkov wrote:
> Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects)
> if a repository has bitmap index, pack-objects can nicely speedup
> "Counting objects" graph traversal phase. That however was done only for
> case when resul
Stefan Beller writes:
> +-L::
> +--push-option::
> + Transmit the given string to the server, which passes them to
> + the pre-receive as well as the post-receive hook. Only C strings
> + containing no new lines are allowed.
This is to affect what happens at the remote end, so I woul
Jeff King writes:
> Why do we care that the file exists? Should we instead be using the
> lockfile code to get exclusive access to it? That would also switch us
> to doing the write-to-tempfile-and-rename dance, but that seems like it
> would be a good thing. If we hit a write() error in the code
Ronald Wampler writes:
> I am not sure if this the correction solution. Another option I
> considered was to wrap the EXTLIBS += -lrt is an ifndef NO_RT and only
> defining NO_RT for Mac OS X in config.mak.uname.
That alternative would make the resulting code noisier/uglier with
nested ifdef, I
Charles Bailey writes:
> I just wanted to clarify what was actually fixed. The actual bug that
> was reported and fixed was the fact that 'git grep' (without --cached)
> wasn't searching the contents of files in the working tree if the index
> entry had the "intent to add" bit set.
Ouch, you are
On Thu, Jul 07, 2016 at 02:21:28PM -0700, Junio C Hamano wrote:
> Charles Bailey writes:
>
> > I just wanted to clarify what was actually fixed. The actual bug that
> > was reported and fixed was the fact that 'git grep' (without --cached)
> > wasn't searching the contents of files in the working
On Thu, Jul 7, 2016 at 1:37 PM, Junio C Hamano wrote:
>
>> @@ -207,6 +214,8 @@ static void show_ref(const char *path, const unsigned
>> char *sha1)
>> "report-status delete-refs side-band-64k quiet");
>> if (advertise_atomic_push)
>>
On Thu, Jul 7, 2016 at 1:20 PM, Junio C Hamano wrote:
>
> What is suboptimal about the structure of the series is that we
> won't bisect down to any of the potential bugs in the above code
> even if we ever see any bug in the future.
> It also does not hint
> where push_options is expected to be r
On Thu, Jul 7, 2016 at 1:01 PM, Junio C Hamano wrote:
> On Thu, Jul 7, 2016 at 12:51 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> The functions `mk_repo_pair` as well as `test_refs` are borrowed from
>>> t5543-atomic-push, with additional hooks installed.
>>>
>>> Signed-off-by: Stef
Stefan Beller writes:
> But your first patch (2/4) would not yet advertise the capability?
> Or advertise and then just ignoring it?
As I wrote...
>> If I were doing this series, I
>> would probably have done 2/4 first without plumbing it through
>> (i.e. it is sent and accumulated in a string
On Thu, Jul 07, 2016 at 02:41:37PM -0700, Stefan Beller wrote:
> >> + /* NEEDSWORK: expose the limitations to be configurable. */
> >> + int max_options = 32;
> >> +
> >> + /*
> >> + * NEEDSWORK: expose the limitations to be configurable;
> >> + * Once the limit can be lifted
On Thu, Jul 7, 2016 at 2:56 PM, Jeff King wrote:
> On Thu, Jul 07, 2016 at 02:41:37PM -0700, Stefan Beller wrote:
>
>> >> + /* NEEDSWORK: expose the limitations to be configurable. */
>> >> + int max_options = 32;
>> >> +
>> >> + /*
>> >> + * NEEDSWORK: expose the limitations to b
Stefan Beller writes:
> No, there is no good objective reason. I added it just after the atomic
> flag as that is what I implemented.
>
> Is there a reason for a particular order of capabilities? I always considered
> it a set of strings, i.e. any order is valid and there is no preference in
> wh
On Thu, Jul 07, 2016 at 03:06:31PM -0700, Stefan Beller wrote:
> > The problem is for hosting sites which serve repositories via git-daemon
> > from untrusted users who have real shell accounts (e.g., you set up
> > git-daemon to run as the "daemon" user serving repositories out of
> > people's ho
Junio C Hamano writes:
> I am however not convinced passing the full SHA-1 is a good
> solution. The make_cache_entry() function may be creating a cache
> entry to stuff in a non-default index (i.e. not "the_index"), but
> its caller does not have a way to tell it which index the resulting
> cac
On Thu, Jul 7, 2016 at 11:44 AM, Erik Johnson wrote:
> % git branch -D archive-extracted-xz
> error: Cannot delete branch 'archive-extracted-xz' checked out at
> '/home/erik/git/salt/archive-extracted-xz'
> % test -d /home/erik/git/salt/archive-extracted-xz || echo "directory
> doesn't exist"
> di
On Thu, Jul 07, 2016 at 04:39:26PM -0700, Jacob Keller wrote:
On Thu, Jul 7, 2016 at 11:44 AM, Erik Johnson wrote:
% git branch -D archive-extracted-xz
error: Cannot delete branch 'archive-extracted-xz' checked out at
'/home/erik/git/salt/archive-extracted-xz'
% test -d /home/erik/git/salt/arch
The manpage for git gc says:
> git gc tries very hard to be safe about the garbage it collects. In
> particular, it will keep not only objects referenced by your current
> set of branches and tags, but also objects referenced by the index,
> remote-tracking branches, refs saved by git filter-branch
Josh Triplett writes:
> This could result in data loss, if a user expected that having an object
> referenced from those places would protect it from pruning.
Yeah, luckily, nobody expects such. I do not think any of our
document says nothing other than HEAD like CHERRY_PICK_HEAD is
reachabilit
Hi,
On Thu, 7 Jul 2016, Jeff Hostetler wrote:
> Tools interacting with Git repositories may need to know the complete
> state of the working directory. For efficiency, it would be good to have
> a single command to obtain this information.
>
> We already have a `--porcelain` mode intended for to
Hi René,
On Thu, 7 Jul 2016, René Scharfe wrote:
> write_file() either returns 0 or dies, so there is no point in checking
> its return value.
The question is whether it makes sense for write_file() to die(). It is a
library function and not every caller can be happy with that function to
exit t
Hi Peff,
On Thu, 7 Jul 2016, Jeff King wrote:
> We have two forms of write_file(): one that dies, and one
> that returns an error. However, the latter has only a single
> caller, which immediately dies anyway (after producing a
> message that is not really any more informative than
> write_file's
On Thu, Jul 07, 2016 at 09:34:02PM -0700, Junio C Hamano wrote:
> Josh Triplett writes:
> > This could result in data loss, if a user expected that having an object
> > referenced from those places would protect it from pruning.
>
> Yeah, luckily, nobody expects such. I do not think any of our
>
On Fri, Jul 08, 2016 at 08:37:35AM +0200, Johannes Schindelin wrote:
> > We have two forms of write_file(): one that dies, and one
> > that returns an error. However, the latter has only a single
> > caller, which immediately dies anyway (after producing a
> > message that is not really any more i
82 matches
Mail list logo