On Thu, 18 Jun 2015, Jeff King wrote:
On Thu, Jun 18, 2015 at 11:08:16AM -0700, Junio C Hamano wrote:
So as I said, I do not think it would hurt to have this as an
incremental improvement (albeit going in a possibly wrong
direction).
Of course, it is a separate question if this change makes
On Thu, Jun 18, 2015 at 01:06:54PM -0700, Junio C Hamano wrote:
Don't we load the config before parsing options here? In that case, we
can use our usual strategy to just set output_directory (which is
already a static global) from the config callback, and everything Just
Works.
We do
Kedves Email felhasználói;
Túllépte a határt 23432 tárolása a megadott e-mail fiókkal által beállított
Web Service / Administrator, és akkor sikerül a küldo
és a bejövo üzenetek, amíg meg újból érvényesíti az e-mail címre. A
szükséges eljárások
nyújtottak be az alábbiakban a nézetet,
Instead of specifying whether a message by the fsck machinery constitutes
an error or a warning, let's specify an identifier relating to the
concrete problem that was encountered. This is necessary for upcoming
support to be able to demote certain errors to warnings.
In the process, simplify the
These functions will be used in the next commits to allow the user to
ask fsck to handle specific problems differently, e.g. demoting certain
errors to warnings. The upcoming `fsck_set_msg_types()` function has to
handle partial strings because we would like to be able to parse, say,
Just like the diff machinery, we are about to introduce more settings,
therefore it makes sense to carry them around as a (pointer to a) struct
containing all of them.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
builtin/fsck.c | 20 +--
builtin/index-pack.c
On Thu, Jun 18, 2015 at 2:08 PM, Junio C Hamano gits...@pobox.com wrote:
Patrick Palka patr...@parcs.ath.cx writes:
I have this nagging feeling that it is just as likely that two
uneven hunks align at the top as they align at the bottom, so while
this might not hurt it may not be the right
Paul Tan pyoka...@gmail.com writes:
@@ -111,13 +122,69 @@ static void am_destroy(const struct am_state *state)
}
/**
+ * Splits out individual patches from `paths`, where each path is either a
mbox
+ * file or a Maildir. Return 0 on success, -1 on failure.
+ */
Splits and then
Hi,
AFAIK Git has two ways to clone a repository with respect to submodules:
(1) Plain clone of just the repository itself:
git clone git://github.com/foo/bar.git
(2) Recursive clone of the repository including all its submodules:
git clone --recursive git://github.com/foo/bar.git
I am working
Paul Tan pyoka...@gmail.com writes:
+static int is_email(const char *filename)
+{
+ struct strbuf sb = STRBUF_INIT;
+ FILE *fp = xfopen(filename, r);
+ int ret = 1;
+
+ while (!strbuf_getline(sb, fp, '\n')) {
+ const char *x;
+
+ strbuf_rtrim(sb);
Junio C Hamano wrote:
j...@joshtriplett.org writes:
Author and committer are used by many git tools; if they weren't part of
the object header, they'd need to be part of some pseudo-header with a
standardized format that git can parse.
Yes, the same goes to the address on Signed-off-by:
On Thu, Jun 18, 2015 at 12:52 AM, Theodore Ts'o wrote:
On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
By allowing multiple authors, you don't have to decide who's the
primary author, as in such situations usually there is no primary
at all. I sometimes deliberately override
Paul Tan pyoka...@gmail.com writes:
For the purpose of rewriting git-am.sh into a C builtin, implement a
skeletal builtin/am.c that redirects to $GIT_EXEC_PATH/git-am if the
environment variable _GIT_USE_BUILTIN_AM is not defined. Since in the
Makefile git-am.sh takes precedence over
On Thu, Jun 18, 2015 at 04:14:19PM -0400, Patrick Palka wrote:
in a test script becomes more clear. But some of the output is not so
great. For instance, the very commit under discussion has a
confusing and useless highlight. Or take a documentation patch like
5c31acfb, where I find the
Paul Tan pyoka...@gmail.com writes:
Implement applying the patch to the index using git-apply.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
builtin/am.c | 57 -
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git
On Thu, Jun 18, 2015 at 04:45:05PM -0400, Jeff King wrote:
Still, I think this is probably a minority case, and it may be
outweighed by the improvements. The real solution is to consider the
hunk as a whole and do an LCS diff on it, which would show that yes,
it's worth highlighting both of
Matthieu Moy matthieu@grenoble-inp.fr writes:
Cool. Then almost all the work is done to get an automated test. Next
step would be to add the tests itself in the code. I would do that by
adding a hidden --selfcheck option to git send-email that would compare
Mail::Address-parse($string);
Paul Tan pyoka...@gmail.com writes:
If a file is unchanged but stat-dirty, git-apply may erroneously fail to
apply patches, thinking that they conflict with a dirty working tree.
As such, since 2a6f08a (am: refresh the index at start and --resolved,
2011-08-15), git-am will refresh the index
On Thu, Jun 18, 2015 at 3:08 PM, Jeff King p...@peff.net wrote:
On Thu, Jun 18, 2015 at 12:28:58PM -0400, Patrick Palka wrote:
By the way, what would it take to get something like this script into
git proper? It is IMHO immensely useful even in its current form, yet
because it's not baked
Paul Tan pyoka...@gmail.com writes:
diff --git a/builtin/am.c b/builtin/am.c
index dbc8836..af68c51 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -6,6 +6,158 @@
#include cache.h
#include builtin.h
#include exec_cmd.h
+#include parse-options.h
+#include dir.h
+
+struct am_state {
Paul Tan pyoka...@gmail.com writes:
+ /* commit message and metadata */
+ struct strbuf author_name;
+ struct strbuf author_email;
+ struct strbuf author_date;
+ struct strbuf msg;
Same comment as dir in the earlier patch applies to these. If the
fields are read or
On Thu, Jun 18, 2015 at 5:23 PM, Jeff King p...@peff.net wrote:
On Thu, Jun 18, 2015 at 04:45:05PM -0400, Jeff King wrote:
Still, I think this is probably a minority case, and it may be
outweighed by the improvements. The real solution is to consider the
hunk as a whole and do an LCS diff on
Luke Diamand l...@diamand.org writes:
This is probably user error, but I'm not sure what I'm doing wrong.
I'm posting here in case anyone else gets the same thing
I'm using 2.4.4.598.gd7bed1d, i.e. 'next' as of today.
I've somehow ended up with history skipping back in time, but git not
Junio C Hamano gits...@pobox.com writes:
$ git checkout upstream/master -- subtree
$ git diff upstream/master -- subtree
-- still lots of deltas
Does this show _ONLY_ additions? Or does it include modifications
and removals?
The reason I ask this question is because of
On Thu, Jun 18, 2015 at 01:00:36PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I think this is a difference between git-diff's internal and external
diff modes which is working correctly, although possibly not desirably
in this case. The internal diff always uses
On 18 June 2015 at 23:28, Junio C Hamano gits...@pobox.com wrote:
Luke Diamand l...@diamand.org writes:
This is probably user error, but I'm not sure what I'm doing wrong.
I'm posting here in case anyone else gets the same thing
I'm using 2.4.4.598.gd7bed1d, i.e. 'next' as of today.
I've
Luke Diamand l...@diamand.org writes:
$ git checkout upstream/master -- subtree
$ git diff upstream/master -- subtree
-- still lots of deltas
Does this show _ONLY_ additions? Or does it include modifications
and removals?
There are indeed _ONLY_ additions.
John Keeping j...@keeping.me.uk writes:
I think the summary is that there are some scenarios where the external
diff tool should see the smudged version and others where the clean
version is more appropriate and Git should support both options. It
seems this is a property of the filter, so I
On 18 June 2015 at 23:53, Junio C Hamano gits...@pobox.com wrote:
Luke Diamand l...@diamand.org writes:
$ git checkout upstream/master -- subtree
$ git diff upstream/master -- subtree
-- still lots of deltas
Does this show _ONLY_ additions? Or does it include modifications
and removals?
John Keeping j...@keeping.me.uk writes:
I think this is a difference between git-diff's internal and external
diff modes which is working correctly, although possibly not desirably
in this case. The internal diff always uses clean files (so it runs the
working tree file through the clean
Jeff King p...@peff.net writes:
This change looks ugly and unnecessary. All the machinery after and
including the point set_outdir() is called, including reopen_stdout(),
work on output_directory variable and only that variable.
Wouldn't it work equally well to have
if
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
t/t5504-fetch-receive-strict.sh | 21 +
1 file changed, 21 insertions(+)
diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
index 69ee13c..3f7e96a 100755
---
This problem has been detected in the wild, and is the primary reason
to introduce an option to demote certain fsck errors to warnings. Let's
offer to ignore this particular problem specifically.
Technically, we could handle such repositories by setting
receive.fsck.msg-id to
When fsck_commit() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Note that some problems are too problematic to simply ignore. For
example, when the header
Some kinds of errors are intrinsically unrecoverable (e.g. errors while
uncompressing objects). It does not make sense to allow demoting them to
mere warnings.
Signed-off-by: Johannes Schindelin johannes.schinde...@gmx.de
---
fsck.c | 14 --
When fsck_tag() identifies a problem with the commit, it should try
to make it possible to continue checking the commit object, in case the
user wants to demote the detected errors to mere warnings.
Just like fsck_commit(), there are certain problems that could hide other
issues with the same tag
An fsck issue in a legacy repository might be so common that one would
like not to bother the user with mentioning it at all. With this change,
that is possible by setting the respective message type to ignore.
This change abuses the missingemail=warn test to verify that ignore
is also accepted
On Thu, Jun 18, 2015 at 04:13:23PM -0400, Jeff King wrote:
You would also need to remove the oh you gave me -o twice? check,
and change the semantics to later -o overrides an earlier one,
wouldn't you? Otherwise you would never be able to override what
you read from the config, I am
Jeff King p...@peff.net writes:
On Thu, Jun 18, 2015 at 04:45:05PM -0400, Jeff King wrote:
Still, I think this is probably a minority case, and it may be
outweighed by the improvements. The real solution is to consider the
hunk as a whole and do an LCS diff on it, which would show that yes,
Jeff King p...@peff.net writes:
Much worse, though, is that we also have to interact with --stdout. We
currently treat --stdout -o foo as an error; you need a separate
config_output_directory to continue to handle that (and allow --stdout
to override the config).
If I were designing from
This is probably user error, but I'm not sure what I'm doing wrong.
I'm posting here in case anyone else gets the same thing
I'm using 2.4.4.598.gd7bed1d, i.e. 'next' as of today.
I've somehow ended up with history skipping back in time, but git not
prepared to let let me fix it, or something.
Johannes Schindelin johannes.schinde...@gmx.de writes:
At the moment, the git-fsck's integrity checks are targeted toward the
end user, i.e. the error messages are really just messages, intended for
human consumption.
Under certain circumstances, some of those errors should be allowed to
be
The other thing about these files is that they were all deleted a few
weeks ago and have now come back.
On 18 June 2015 at 23:07, Luke Diamand l...@diamand.org wrote:
This is probably user error, but I'm not sure what I'm doing wrong.
I'm posting here in case anyone else gets the same thing
On Thu, 18 Jun 2015, Jeff King wrote:
On Thu, Jun 18, 2015 at 04:14:19PM -0400, Patrick Palka wrote:
in a test script becomes more clear. But some of the output is not so
great. For instance, the very commit under discussion has a
confusing and useless highlight. Or take a documentation patch
Hi Junio,
On 2015-06-19 00:11, Junio C Hamano wrote:
I haven't had a chance to go through the all the patches, but one
thing I noticed that did not appear in the interdiff is that some of
the message IDs are unclear. For example, there are BAD_something,
INVALID_something and
Junio C Hamano gits...@pobox.com writes:
I think restore also by definition has to go back to _some_
existing version, not a future yet-to-be-created one, so restore to
some previous state is superfluous;
That's why I found restore recorded state not too bad.
restore working tree files
Not
Am 17.06.2015 um 18:10 schrieb Robert Dailey:
I do the following:
$ git push origin :topic
If I stop halfway through typing 'topic' and hit TAB, auto-completion
does not work if I do not have a local branch by that name (sometimes
I delete my local branch first, then I push to delete it
On Wed, Jun 17, 2015 at 03:12:35PM -0400, Jeff King wrote:
On Wed, Jun 17, 2015 at 10:58:10AM -0700, Stefan Beller wrote:
Just make strbuf_slopbuf[] large enough to keep Coverity happy. If it's
happy, we'll have cleaner defect list
It's down 31 defects, roughly 10% of all things
On Thu, Jun 18, 2015 at 2:10 AM, Jeff King p...@peff.net wrote:
On Wed, Jun 17, 2015 at 05:04:04PM +0700, Duy Nguyen wrote:
I wonder if we could do it a bit differently. Instead of
GIT_TRACE_STDIN, I would add GIT_TRACE_HOOK that points to a script.
Whenever a command is run via run-command
The changes are described in CHANGES.
Contributions-by: Matthieu Moy matthieu@imag.fr
Contributions-by: Richard Hansen rhan...@rhansen.org
Contributions-by: Michael Haggerty mhag...@alum.mit.edu
Contributions-by: Elijah Newren new...@gmail.com
Contributions-by: Luke Mewburn l...@mewburn.net
On Tue, Jun 16, 2015 at 1:54 AM, Junio C Hamano gits...@pobox.com wrote:
Paul Tan pyoka...@gmail.com writes:
The scripted Porcelain is spawned after applying patches 1-3 from
here, when you do not have _GIT_USE_BUILTIN_AM exported. Haven't
RUN_SETUP code did its thing by that time?
Ah
On Wed, Jun 17, 2015 at 10:27:58PM -0400, Mike Rappazzo wrote:
On Wed, Jun 17, 2015 at 3:41 PM, Junio C Hamano gits...@pobox.com wrote:
Michael Rappazzo rappa...@gmail.com writes:
For some mergetools, the current invocation of git mergetool will
include an auto-merge flag. By default the
Implement the fetch + merge functionality of git-pull, by first running
git-fetch with the repo and refspecs provided on the command line, then
running git-merge on FETCH_HEAD to merge the fetched refs into the
current branch.
Helped-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Paul Tan
Certain git commands, such as git-pull, are simply wrappers around other
git commands like git-fetch, git-merge and git-rebase. As such, these
wrapper commands will typically need to pass through command-line
options of the commands they wrap.
Implement the parse_opt_passthru_argv() parse-options
When we have a null-terminated array, it would be useful to convert it
or append it to an argv_array for further manipulation.
Implement argv_array_pushv() which will push a null-terminated array of
strings on to an argv_array.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
Certain git commands, such as git-pull, are simply wrappers around other
git commands like git-fetch, git-merge and git-rebase. As such, these
wrapper commands will typically need to pass through command-line
options of the commands they wrap.
Implement the parse_opt_passthru() parse-options
This is a re-roll of [v3]. It squashes in Ramsay's patch fix some sparse
warnings, and fixes the use-before-free reported by Duy. Thanks a lot for
dealing with my mess :-).
Other than that, there are no other changes as I'm working on the git-am side
of things.
Previous versions:
[v1]
Commit a8c9bef (pull: improve advice for unconfigured error case,
2009-10-05) fully established the current advices given by git-pull for
the different cases where git-fetch will not have anything marked for
merge:
1. We fetched from a specific remote, and a refspec was given, but it
ended up
For the purpose of rewriting git-pull.sh into a C builtin, implement a
skeletal builtin/pull.c that redirects to $GIT_EXEC_PATH/git-pull.sh if
the environment variable _GIT_USE_BUILTIN_PULL is not defined. This
allows us to fall back on the functional git-pull.sh when running the
test suite for
Specify git-merge's options in the option list, and pass any specified
options to git-merge.
These options are:
* -n, --stat, --summary: since d8abe14 (merge, pull: introduce
'--(no-)stat' option, 2008-04-06)
* --log: since efb779f (merge, pull: add '--(no-)log' command line
option,
Since b10ac50 (Fix pulling into the same branch., 2005-08-25), git-pull,
upon detecting that git-fetch updated the current head, will
fast-forward the working tree to the updated head commit.
Re-implement this behavior.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
builtin/pull.c | 30
b4dc085 (pull: merge into unborn by fast-forwarding from empty
tree, 2013-06-20) established git-pull's current behavior of pulling
into an unborn branch by fast-forwarding the work tree from an empty
tree to the merge head, then setting HEAD to the merge head.
Re-implement this behavior by
Since eb2a8d9 (pull: handle git-fetch's options as well, 2015-06-02),
git-pull knows about and handles git-fetch's options, passing them to
git-fetch. Re-implement this behavior.
Since 29609e6 (pull: do nothing on --dry-run, 2010-05-25) git-pull
supported the --dry-run option, exiting after
7f87aff (Teach/Fix pull/fetch -q/-v options, 2008-11-15) taught git-pull
to accept the verbosity -v and -q options and pass them to git-fetch and
git-merge.
Re-implement support for the verbosity flags by adding it to the options
list and introducing argv_push_verbosity() to push the flags into
Since b814da8 (pull: add pull.ff configuration, 2014-01-15), git-pull.sh
would lookup the configuration value of pull.ff, and set the flag
--ff if its value is true, --no-ff if its value is false and
--ff-only if its value is only.
Re-implement this behavior.
Signed-off-by: Paul Tan
101 - 165 of 165 matches
Mail list logo
