On Thu, Jun 18, 2015 at 09:49:19PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... I think you could also argue that
> > because of whitespace-highlighting, colorized diffs are fundamentally
> > going to have colors intermingled with the content and should not be
> > parsed this way.
Alistair Lynn writes:
> $ git commit --allow-empty -m ‘test’
> $ git revert HEAD
>
> The latter fails silently, leaving HEAD pointing at the commit created
> by the first command.
I do not necessarily think it is a bug to ignore reverting a no-op.
"revert a no-op" should probably fail by default
Jeff King writes:
> ... I think you could also argue that
> because of whitespace-highlighting, colorized diffs are fundamentally
> going to have colors intermingled with the content and should not be
> parsed this way.
Painting of whitespace breakages is asymmetric [*1*]. If you change
somethi
On Thu, Jun 18, 2015 at 11:25:44PM +0200, Jakub Narębski wrote:
> Author and committer include datetime in the contents of the
> field, which is used by Git for heuristics limiting walk. Coauthor
> would have the same date as author, isn't it? If, after long
> and involved discussion, we didn't ad
On Thu, Jun 18, 2015 at 02:46:36PM -0700, Junio C Hamano wrote:
> > If I were designing from scratch, I would consider making "-o -" output
> > to stdout, and letting it override a previous "-o" (or vice versa). We
> > could still do that (and make "--stdout" an alias for that), but I don't
> > kn
On Thu, Jun 18, 2015 at 05:23:56PM -0400, Jeff King wrote:
> +# Return the individual diff-able items of the hunk, but with any
> +# diff or color prefix/suffix for each line split out (we assume that the
> +# prefix/suffix for each line will be the same).
> +sub split_hunk {
> + my ($prefix,
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 MISSING_som
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
On 18 June 2015 at 23:53, Junio C Hamano wrote:
> Luke Diamand 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
John Keeping 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 wonder if the
Luke Diamand 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.
http://thread.gmane.org/gmane.
On 18 June 2015 at 23:28, Junio C Hamano wrote:
> Luke Diamand 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
On Thu, Jun 18, 2015 at 01:00:36PM -0700, Junio C Hamano wrote:
> John Keeping 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 file
Junio C Hamano 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
http://thread.gmane.org/gm
Luke Diamand 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
> prepared to
On Thu, Jun 18, 2015 at 5:23 PM, Jeff King 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 it,
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 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
>
> I'm using 2.4.
Johannes Schindelin 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 turned into mere war
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.
$
Jeff King 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 scra
Jeff King 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,
>> i
Paul Tan 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 before applyi
Matthieu Moy 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); and split_addrs($string);
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: foote
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 o
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
Paul Tan writes:
> Implement applying the patch to the index using git-apply.
>
> Signed-off-by: Paul Tan
> ---
> builtin/am.c | 57 -
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/am.c b/builtin/am.c
> index d
Paul Tan 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 computed and the
Paul Tan 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);
Is
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 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 "Return"? Be
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 th
Paul Tan 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
On Thu, Jun 18, 2015 at 3:08 PM, Jeff King 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 into the
Paul Tan 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 builtin/am.c,
> $GIT_EX
On Thu, Jun 18, 2015 at 2:08 PM, Junio C Hamano wrote:
> Patrick Palka 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 approach for a better
>>> sol
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 th
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 t
Paul Tan writes:
> 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.
I d
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 already have support in `git receive-pack` to deal with some legacy
repositories which have non-fatal issues.
Let's make `git fsck` itself useful with such repositories, too, by
allowing users to ignore known issues, or at least demote those issues
to mere warnings.
Example: `git -c fsck.missi
The optional new config option `receive.fsck.skiplist` specifies the path
to a file listing the names, i.e. SHA-1s, one per line, of objects that
are to be ignored by `git receive-pack` when `receive.fsckObjects = true`.
This is extremely handy in case of legacy repositories where it would
cause m
Identical to support in `git receive-pack for the config option
`receive.fsck.skiplist`, we now support ignoring given objects in
`git fsck` via `fsck.skiplist` altogether.
This is extremely handy in case of legacy repositories where it would
cause more pain to change incorrect objects than to liv
Signed-off-by: Johannes Schindelin
---
Documentation/config.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 3e37b93..306ab7a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2205,6 +2205,20 @
The 'invalid tag name' and 'missing tagger entry' warnings can now be
upgraded to errors by specifying `invalidtagname` and
`missingtaggerentry` in the receive.fsck. config setting.
Incidentally, the missing tagger warning is now really shown as a warning
(as opposed to being reported with the "er
This option avoids unpacking each and all objects, and just verifies the
connectivity. In particular with large repositories, this speeds up the
operation, at the expense of missing corrupt blobs and ignoring
unreachable objects, if any.
Signed-off-by: Johannes Schindelin
---
Documentation/git-f
On 2015-06-18 21:45, Junio C Hamano wrote:
> This round looks good, except one trivial nit (below), which I'll
> locally squash-in a fix for.
Thanks,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
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
---
fsck.c | 14 --
t/t5504-fetch-receive-strict.sh | 11 +++
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 accep
Signed-off-by: Johannes Schindelin
---
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
--- a/t/t5504-fetch-receive-strict.sh
+++ b/t/t5504-fet
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
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. to missingcommitter=warn, but
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 lines
When fsck_ident() identifies a problem with the ident, it should still
advance the pointer to the next line so that fsck can continue in the
case of a mere warning.
Signed-off-by: Johannes Schindelin
---
fsck.c | 49 +++--
1 file changed, 27 insertions
For example, missing emails in commit and tag objects can be demoted to
mere warnings with
git config receive.fsck.missingemail=warn
The value is actually a comma-separated list.
In case that the same key is listed in multiple receive.fsck.
lines in the config, the latter configuration w
There are legacy repositories out there whose older commits and tags
have issues that prevent pushing them when 'receive.fsckObjects' is set.
One real-life example is a commit object that has been hand-crafted to
list two authors.
Often, it is not possible to fix those issues without disrupting th
Some legacy code has objects with non-fatal fsck issues; To enable the
user to ignore those issues, let's print out the ID (e.g. when
encountering "missingemail", the user might want to call `git config
--add receive.fsck.missingemail=warn`).
Signed-off-by: Johannes Schindelin
---
fsck.c
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 r
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,
'missingemail=
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
---
builtin/fsck.c | 20 +--
builtin/index-pack.c | 9 +--
builtin/unpac
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 turned into mere warnings, though, because the cost of fixing
Junio C Hamano writes:
> Jeff King 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
Jeff King 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 (!output_dir
John Keeping 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" filter before ap
On Thu, Jun 18, 2015 at 10:13:37AM -0700, Junio C Hamano wrote:
> > -static const char *set_outdir(const char *prefix, const char
> > *output_directory)
> > +static const char *set_outdir(const char *prefix, const char
> > *output_directory,
> > + const char *config_outpu
Thanks.
This round looks good, except one trivial nit (below), which I'll
locally squash-in a fix for.
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index fb1b571..6938e5e 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1052,7 +1052,
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, ell
On Thu, Jun 18, 2015 at 10:55 AM, SZEDER Gábor wrote:
>
> Quoting Robert Dailey :
>
>> On Thu, Jun 18, 2015 at 6:29 AM, SZEDER Gábor wrote:
>>>
>>> Quoting Robert Dailey
I do the following:
$ git push origin :topic
If I stop halfway through typing 'topic' and hit TA
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 into the application hardly anybody knows about
> it.
I think if
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 the output
> worse, by comparing
Patrick Palka 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 approach for a better
>> solution, in the sense that when somebody really wants to do a
>>
On Thu, Jun 18, 2015 at 4:25 AM, Paul Tan wrote:
> +/**
> + * Reads the contents of `file`. The third argument can be used to give a
> hint
I would avoid `third` here. (I needed to count twice to be sure which
argument you
were referring to, as I was confused.) Also how do you abstain from
givin
Remi Lespinet writes:
>> Remi Lespinet writes:
>>
>> > I've some more tests, maybe I should put them all in this post ?
>>
>> Yes, please post as much as you have. Ideally, this should be
>> automatically tested, but if you don't have time to write the automated
>> tests, at least having a tra
Hi folks,
can you someone look at it? Or were these troubles mentioned somewhere
earlier and I miss that?
On 2.6.2015 16:14, Petr Stodulka wrote:
request-pull prints incorrectly warn messages about not found commits
and man pages don't say
anything about todays changed behaviour. People are co
Alexander Kuleshov writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index fd2036c..8f6f7ed 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1247,6 +1247,10 @@ format.coverLetter::
> format-patch is invoked, but in addition can be set
Duy Nguyen writes:
> The last resort is simply filter out a whole class of warnings.
> Probably good enough if both patches look equally ugly.
>
> -- 8< --
> Subject: [PATCH] strbuf: kill strbuf_slopbuf, in favor of ""
>
> A lot of "out-of-bound access" warnings on scan.coverity.com is because
>
When rev-list's --cherry option does not detect that a patch has already
been applied upstream, an interactive rebase would offer to reapply it and
consequently stop at that patch with a failure, mentioning that the diff
is empty.
Traditionally, a `git rebase --continue` simply skips the commit in
When skipping commits whose changes were already applied via `git rebase
--continue`, we need to clean up said file explicitly.
The same is not true for `git rebase --skip` because that will execute
`git reset --hard` as part of the "skip" handling in git-rebase.sh, even
before git-rebase--interac
These patches fix a bug that bites me often enough when rebasing Git for
Windows.
The symptom is that .git/CHERRY_PICK_HEAD is left behind after skipping
an already-merged patch with `git rebase --continue` instead of `git
rebase --skip`. I always prefer the former invocation because the latter
wo
On Thu, Jun 18, 2015 at 11:50 AM, Junio C Hamano wrote:
> Patrick Palka writes:
>
>> Currently the diff-highlight script does not try to highlight hunks that
>> have different numbers of removed/added lines. But we can be a little
>> smarter than that, without introducing much magic and complexi
Hi Junio,
On 2015-06-18 18:00, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
+ git diff seq-onto &&
>>>
>>> I am puzzled with this "diff"; what is this about? Is it a remnant
>>> from an earlier debugging session, or is it making sure seq-onto is
>>> a valid tree-ish?
>>
>> The id
On Thu, Jun 18, 2015 at 05:39:18PM +0200, Florian Aspart wrote:
> 2015-06-18 16:28 GMT+02:00 John Keeping :
> > On Thu, Jun 18, 2015 at 04:17:52PM +0200, Florian Aspart wrote:
> >> 2015-06-18 16:11 GMT+02:00 John Keeping :
> >> > On Thu, Jun 18, 2015 at 03:51:25PM +0200, Florian Aspart wrote:
> >>
Johannes Schindelin writes:
>>> + git diff seq-onto &&
>>
>> I am puzzled with this "diff"; what is this about? Is it a remnant
>> from an earlier debugging session, or is it making sure seq-onto is
>> a valid tree-ish?
>
> The idea is to verify that we end up with the same tree even if we
>
Michael J Gruber writes:
> This type of request comes up often (for a reason). I'm wondering
> whether we could support it more systematically, either by exposing the
> steps above as a command, or by storing the unresolved merge somewhere
> (leveraging stash or rerere).
Perhaps 'tr/remerge-diff
Quoting Robert Dailey :
On Thu, Jun 18, 2015 at 6:29 AM, SZEDER Gábor wrote:
Quoting 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 del
Patrick Palka writes:
> Currently the diff-highlight script does not try to highlight hunks that
> have different numbers of removed/added lines. But we can be a little
> smarter than that, without introducing much magic and complexity.
>
> In the case of unevenly-sized hunks, we could still hig
2015-06-18 16:28 GMT+02:00 John Keeping :
> On Thu, Jun 18, 2015 at 04:17:52PM +0200, Florian Aspart wrote:
>> 2015-06-18 16:11 GMT+02:00 John Keeping :
>> > On Thu, Jun 18, 2015 at 03:51:25PM +0200, Florian Aspart wrote:
>> >> 2015-06-18 15:26 GMT+02:00 John Keeping :
>> >> > [Please don't top-pos
On Thu, Jun 18, 2015 at 6:29 AM, SZEDER Gábor wrote:
> Quoting 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 lo
Hello gitters
Steps to reproduce:
$ git commit --allow-empty -m ‘test’
$ git revert HEAD
The latter fails silently, leaving HEAD pointing at the commit created by the
first command.
A subsequent `git commit --allow-empty` has the revert message as the default
commit message when starting the
On Thu, Jun 18, 2015 at 4:43 AM David Aguilar wrote:
>
> On Wed, Jun 17, 2015 at 10:27:58PM -0400, Mike Rappazzo wrote:
> >
> > I feel that the auto-merge takes away the context of the changes.
> >
> > I use araxis merge as my mergetool of choice. I almost always immediately
> > undo the auto-mer
> Remi Lespinet writes:
>
> > I've some more tests, maybe I should put them all in this post ?
>
> Yes, please post as much as you have. Ideally, this should be
> automatically tested, but if you don't have time to write the automated
> tests, at least having a track of what you did on the list
On Thu, Jun 18, 2015 at 04:17:52PM +0200, Florian Aspart wrote:
> 2015-06-18 16:11 GMT+02:00 John Keeping :
> > On Thu, Jun 18, 2015 at 03:51:25PM +0200, Florian Aspart wrote:
> >> 2015-06-18 15:26 GMT+02:00 John Keeping :
> >> > [Please don't top-post on this list.]
> >> >
> >> > On Thu, Jun 18, 2
2015-06-18 16:11 GMT+02:00 John Keeping :
> On Thu, Jun 18, 2015 at 03:51:25PM +0200, Florian Aspart wrote:
>> 2015-06-18 15:26 GMT+02:00 John Keeping :
>> > [Please don't top-post on this list.]
>> >
>> > On Thu, Jun 18, 2015 at 03:15:38PM +0200, Florian Aspart wrote:
>> >> 2015-06-18 14:31 GMT+02
On Thu, Jun 18, 2015 at 03:51:25PM +0200, Florian Aspart wrote:
> 2015-06-18 15:26 GMT+02:00 John Keeping :
> > [Please don't top-post on this list.]
> >
> > On Thu, Jun 18, 2015 at 03:15:38PM +0200, Florian Aspart wrote:
> >> 2015-06-18 14:31 GMT+02:00 Michael J Gruber :
> >> > Florian Aspart veni
2015-06-18 15:26 GMT+02:00 John Keeping :
> [Please don't top-post on this list.]
>
> On Thu, Jun 18, 2015 at 03:15:38PM +0200, Florian Aspart wrote:
>> 2015-06-18 14:31 GMT+02:00 Michael J Gruber :
>> > Florian Aspart venit, vidit, dixit 16.06.2015 16:11:
>> >> Hi everyone,
>> >>
>> >> I created a
[Please don't top-post on this list.]
On Thu, Jun 18, 2015 at 03:15:38PM +0200, Florian Aspart wrote:
> 2015-06-18 14:31 GMT+02:00 Michael J Gruber :
> > Florian Aspart venit, vidit, dixit 16.06.2015 16:11:
> >> Hi everyone,
> >>
> >> I created a clean filter to apply on some files before commitin
Hi Michael,
yes in this case "difftool" compares an uncleaned working tree file
with a cleaned blob. I did not try the smudge filter to see if it
applied in difftool.
I think the problem comes from the way difftool is feeded, since I
also had this problem when setting an external tool for the dif
Hi Micha,
On 2015-06-18 14:26, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 16.06.2015 11:43:
>
>> To list all the merge commits in the current branch, I would use the
>> command-line:
>>
>> ```bash
>> git rev-list --author="My Colleague" --parents HEAD |
>> sed -n 's/ .* .*/
Florian Aspart venit, vidit, dixit 16.06.2015 16:11:
> Hi everyone,
>
> I created a clean filter to apply on some files before commiting them.
> The filter works correctly when I commit the file and is also applied
> when I usethe iff command line tool.
> However, when using difftool with meld, th
Johannes Schindelin venit, vidit, dixit 16.06.2015 11:43:
> Hi Eric,
>
> On 2015-06-16 03:17, Eric Raible wrote:
>> I'm running 1.9.5.msysgit.1, but this is a general git question...
>>
>> Upon returning from a vacation, I was looking at what people had been
>> up to, and discovered on merge in wh
1 - 100 of 168 matches
Mail list logo
