2017-01-15 3:42 GMT+01:00 Junio C Hamano :
> Elia Pinto writes:
>
>> Ok. I agree. But is it strictly necessary to resend for this ?
>
> FWIW, the attacched is what I queued locally, after complaining
> "both have the same title? They need to be explained better."
>
> In any case, I sense that 2/
On 15/01/2017 03:39, Junio C Hamano wrote:
René Scharfe writes:
I am also more focused on keeping the codebase maintainable in good
health by making sure that we made an effort to find a solution that
is general-enough before solving a single specific problem you have
today. We may end up dec
http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833
Sometimes poople are forced to save stash for changed files. But there is no
such option (
While working on a repository, it's often helpful to stash the changes
of a single or multiple files, and leave others alone. Unfortunately
git currently offers no such option. git stash -p can be used to work
around this, but it's often impractical when there are a lot of changes
over multiple f
On 01/15, KES wrote:
> http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833
>
> Sometimes poople are forced to save stash for changed files. But there is no
> such option (
You may just be lucky. I've been wishin
On Fri, Jan 13, 2017 at 8:14 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> The following part of the description:
>>
>> git bisect (bad|new) []
>> git bisect (good|old) [...]
>>
>> may be a bit confusing, as a reader may wonder if instead it should be:
>>
>> git bisect (bad|good) []
>
Am 15.01.2017 um 03:39 schrieb Junio C Hamano:
> René Scharfe writes:
>
>>> I am also more focused on keeping the codebase maintainable in good
>>> health by making sure that we made an effort to find a solution that
>>> is general-enough before solving a single specific problem you have
>>> toda
Am 15.01.2017 um 11:06 schrieb Vegard Nossum:
On 15/01/2017 03:39, Junio C Hamano wrote:
René Scharfe writes:
How about extending the context upward only up to and excluding a line
that is either empty *or* a function line? That would limit the extra
context to a single function in the worst
request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete)
USAGE and LONG_USAGE anymore.
Signed-off-by: Wolfram Sang
---
git-request-pull.sh |3 ---
1 file changed, 3 deletions(-)
Index: git-2.11.0/git-request-pull.sh
=
Asking for opinions on lkml and git...
Getting enough quality assurance is likely one of the bigger upcoming tasks in
the near future. To improve the situation, praise the people already doing that
by adding their names to pull requests in the same manner that patch authors
are credited. Here is a
From: Lukas Puehringer
ref-filter functions are useful for printing git object information
using a format specifier. However, some other modules may not want to use
this functionality on a ref-array but only print a single item.
Expose a pretty_print_ref function to create, pretty print and free
From: Lukas Puehringer
Adding --format to git tag -v mutes the default output of the GPG
verification and instead prints the formatted tag object.
This allows callers to cross-check the tagname from refs/tags with
the tagname from the tag object header upon GPG verification.
The callback functio
From: Lukas Puehringer
Functions that print git object information may require that the
gpg-interface functions be silent. Add GPG_VERIFY_QUIET flag and prevent
print_signature_buffer from being called if flag is set.
Signed-off-by: Lukas Puehringer
---
gpg-interface.h | 1 +
tag.c |
From: Santiago Torres
Verify-tag now provides --format specifiers to inspect and ensure the
contents of the tag are proper. We add two tests to ensure this
functionality works as expected: the return value should indicate if
verification passed, and the format specifiers must be respected.
Signe
From: Santiago Torres
tag -v now supports --format specifiers to inspect the contents of a tag
upon verification. Add two tests to ensure this behavior is respected in
future changes.
Signed-off-by: Santiago Torres
---
t/t7004-tag.sh | 16
1 file changed, 16 insertions(+)
dif
From: Santiago Torres
This is the fifth iteration of [1][2][3][4], and as a result of the
discussion in [5]. The main goal of this patch series is to bring
--format to git tag verification so that upper-layer tools can inspect
the content of a tag and make decisions based on it.
In this re-woll
From: Lukas Puehringer
Calling functions for gpg_verify_tag() may desire to print relevant
information about the header for further verification. Add an optional
format argument to print any desired information after GPG verification.
Signed-off-by: Lukas Puehringer
---
builtin/tag.c|
From: Santiago Torres
Callers of verify-tag may want to cross-check the tagname from refs/tags
with the tagname from the tag object header upon GPG verification. This
is to avoid tag refs that point to an incorrect object.
Add a --format parameter to git verify-tag to print the formatted tag
obj
On 1/13/2017 12:30 PM, Stefan Beller wrote:
This question is about networking; the patch you originally replied to
was strictly about local operations in the filesystem, which is quite
a difference, so let's discuss it separately.
Yep ok look like you reclassified this and opened new topic which
Changes from v2:
* The orderfile feature doesn't set the WM_PATHNAME flag when it
calls wildmatch(), so document the pattern format accordingly.
Richard Hansen (2):
diff: document behavior of relative diff.orderFile
diff: document the format of the -O (diff.orderFile) file
Documentatio
Document that a relative pathname for diff.orderFile is interpreted as
relative to the top-level work directory.
Signed-off-by: Richard Hansen
---
Documentation/diff-config.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
ind
Signed-off-by: Richard Hansen
---
Documentation/diff-config.txt | 5 ++---
Documentation/diff-options.txt | 34 --
2 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/Documentation/diff-config.txt b/Documentation/diff-config.txt
index 875212045..9e411
René Scharfe writes:
> ... How bad would it be to only
> implement the first part (as in the patch I just sent) without adding
> new config settings or parameters?
That probably is a good place to stop ;-)
This one unfortunately clashes with jk/nofollow-attr-ignore where
Peff adds sanity to refuse following symbolic links when reading
.gitignore and .gitattributes; I'll eject jk/nofollow-attr-ignore
topic for now and see how well this topic fits together with the
remainder of the topics in flight.
T
Hi,
a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
"git stash pop", he got into a merge conflict. After he resolved the
conflict, he did not know what to do to get the repository into the
wanted state. In his case, it was only "git add "
followed by a "git reset" and a "git
Thomas Gummerer writes:
> While working on a repository, it's often helpful to stash the changes
> of a single or multiple files, and leave others alone. Unfortunately
> git currently offers no such option. git stash -p can be used to work
> around this, but it's often impractical when there ar
Wolfram Sang writes:
> request-pull uses OPTIONS_SPEC, so no need for (meanwhile incomplete)
> USAGE and LONG_USAGE anymore.
>
> Signed-off-by: Wolfram Sang
> ---
Makes sense. These are not used anywhere after we switched to use
parse-options.
Thanks.
>
> git-request-pull.sh |3 ---
> 1
Wolfram Sang writes:
> === new stuff starts here
>
> with much appreciated quality assurance from
>
> Andy Shevchenko (1):
> (Rev.) i2c: piix4: Avoid race conditions with IMC
>
> Benjamin Tissoires (1):
> (Test) i2c: do
Hi,
On 01/16/2017 01:21 AM, Junio C Hamano wrote:
> I haven't spent enough time to think if it even makes sense to
> "stash" partially, leaving the working tree still dirty. My initial
> reaction was "then stashing away the dirty WIP state to get a spiffy
> clean working environment becomes impos
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
Hi Junio,
On Sat, Jan 14, 2017 at 06:35:43PM -0800, Junio C Hamano wrote:
> David Aguilar writes:
>
> > On Fri, Jan 13, 2017 at 03:20:43AM -0800, David Aguilar wrote:
> >>
> >> Ping.. it would be nice to get this patch applied.
> >
> > Sorry for the noise, and thank you Paul for the fix.
> > Th
On Sun, Jan 15, 2017 at 3:56 PM, Stephan Beyer wrote:
> Hi,
>
> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
> "git stash pop", he got into a merge conflict. After he resolved the
> conflict, he did not know what to do to get the repository into the
> wanted state. In his
On Sun, Jan 15, 2017 at 4:35 PM, Junio C Hamano wrote:
> As to the implementation, I am wondering if we can make this somehow
> work well with the "trailers" code we already have, instead of
> inventing yet another parser of trailers.
>
> In its current shape, "interpret-trailers" focuses on "edit
On Sat, Jan 14, 2017 at 10:05 AM, Jeff King wrote:
> On Sat, Jan 14, 2017 at 06:57:13PM +0100, Johannes Schindelin wrote:
>
>> On Thu, 12 Jan 2017, Junio C Hamano wrote:
>>
>> > Johannes Schindelin writes:
>> >
>> > >
>> > > - if (!commit->parents) {
>> > > + if (!commit->parents)
>> > >
Hi all,
What is the difference between simple, fast forward, automatic and
trivial merge?
I am updating the translation and the only thing I am sure about is
that these four are not octopus merges,
Fast forward is when current state is ancestor of tip, automatic merge
is when the merge algorithm is
On Sun, Jan 15, 2017 at 8:41 PM, Alexander Shopov wrote:
> Hi all,
> What is the difference between simple, fast forward, automatic and
> trivial merge?
> I am updating the translation and the only thing I am sure about is
> that these four are not octopus merges,
> Fast forward is when current st
Am 16.01.2017 um 02:51 schrieb Junio C Hamano:
* jk/vreport-sanitize (2017-01-11) 2 commits
- vreport: sanitize ASCII control chars
- Revert "vreportf: avoid intermediate buffer"
An error message with an ASCII control character like '\r' in it
can alter the message to hide its early part, wh
Alexander Shopov writes:
> What is the difference between simple, fast forward, automatic and
> trivial merge?
"fast forward" and "trivial" (and "automatic" to some degree) are
technical terms with precise meaning. Other phrases that are
related to "merge" that are not in your list are "already
Paul Mackerras writes:
>> Paul, is it a good time to pull, or do you still have something not
>> published yet that should go together with what you have already
>> queued?
>
> I recently pushed out one more commit to update the Russian
> translation from Dimitriy Ryazantcev. The head is now 8fe
Johannes Sixt writes:
> Am 16.01.2017 um 02:51 schrieb Junio C Hamano:
>> * jk/vreport-sanitize (2017-01-11) 2 commits
>> - vreport: sanitize ASCII control chars
>> - Revert "vreportf: avoid intermediate buffer"
>>
>> An error message with an ASCII control character like '\r' in it
>> can alt
40 matches
Mail list logo
