Paolo Bonzini writes:
> The purpose of this action is for scripts to be able to keep the
> user's Signed-off-by at the end. For example say I have a script
> that adds a Reviewed-by tag:
>
> #! /bin/sh
> them=$(git log -i -1 --pretty='format:%an <%ae>' --author="$*")
> trailer="Revie
On Fri, Oct 06, 2017 at 03:03:49PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I don't know if we wanted to capture any of the reasoning behind using
> > error() here or not. Frankly, I'm not sure how to argue for it
> > succinctly. :) I'm happy with letting it live on in the list arc
Jeff King writes:
> I don't know if we wanted to capture any of the reasoning behind using
> error() here or not. Frankly, I'm not sure how to argue for it
> succinctly. :) I'm happy with letting it live on in the list archive.
Are you talking about the "philosophical" thing?
Because we canno
Junio C Hamano writes:
> I think it is easier to reason about if this were not "else if", but
> just a simple "if".
And here are two small suggested changes to the code portion of your
patch.
- break if / else if cascade into two independent if / if
statements for clarity.
- give the "ign
Here is a suggested rewrite of t7519 (I used t7520 to avoid crashing
with another topic in flight).
- use unused/unallocated 7520 to avoid crashes with bp/fsmonitor
topic
- use setup inside test_expect_success
- use test_i18ngrep to avoid gettext-poison build gotchas
- look for specific
Junio C Hamano writes:
>> diff --git a/t/t7519-ignored-hook-warning.sh
>> b/t/t7519-ignored-hook-warning.sh
>> new file mode 100755
Another thing; t7519 is taken by another topic in flight. Let's use
t7520 instead.
Johannes Schindelin writes:
> Subject: Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote
> ref name
No verb? s/optionally/report/ perhaps?
> diff --git a/ref-filter.c b/ref-filter.c
> index 4819707d032..b4b2c9b2190 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -77,7
On Fri, Oct 06, 2017 at 01:26:48PM +0900, Junio C Hamano wrote:
> > We could probably be a bit more specific about the situation, since the
> > user will see this message with no context. Maybe something like:
> >
> > unable to stat just-written file %s
> >
> > or something. We should probably a
On Fri, Oct 06, 2017 at 08:01:48AM +0900, Junio C Hamano wrote:
> > But
> > I think we'd want to protect the read_blob_entry() call at the top of
> > the case with a check for dco->state == CE_RETRY.
>
> Yeah, I think that makes more sense.
>
> A patch may look like this on top of these two patc
Damien Marié writes:
> if (access(path.buf, X_OK) < 0) {
> + int err = errno;
OK, so we remember how/why we failed in err.
> #ifdef STRIP_EXTENSION
> strbuf_addstr(&path, STRIP_EXTENSION);
> if (access(path.buf, X_OK) >= 0)
>
On Fri, Oct 06, 2017 at 12:30:08AM -0400, Jeff King wrote:
> On Fri, Oct 06, 2017 at 01:19:21PM +0900, Junio C Hamano wrote:
>
> > > But note that the leak in (2) is actually older than that.
> > > The original unpack_sha1_file() directly returned the result
> > > of unpack_sha1_rest() to its cal
On Thu, Oct 05, 2017 at 07:35:30PM -0700, Jonathan Nieder wrote:
> > It also only tells half the story. You have to know not just what's in
> > $GIT_EDITOR, but you have to know the right way to evaluate it. There's
> > a git_editor helper in git-sh-setup, but other scripting languages are
> > on
On Fri, Oct 06, 2017 at 01:19:21PM +0900, Junio C Hamano wrote:
> > But note that the leak in (2) is actually older than that.
> > The original unpack_sha1_file() directly returned the result
> > of unpack_sha1_rest() to its caller, when it should have
> > been closing the zlib stream itself on er
Jeff King writes:
>> diff --git a/entry.c b/entry.c
>> index 5dab656364..2252d96756 100644
>> --- a/entry.c
>> +++ b/entry.c
>> @@ -355,7 +355,8 @@ static int write_entry(struct cache_entry *ce,
>> if (state->refresh_cache) {
>> assert(state->istate);
>> if (!fstat_
Jeff King writes:
> When a caller of sha1_object_info_extended() sets the
> "contentp" field in object_info, we call unpack_sha1_rest()
> but do not check whether it signaled an error.
>
> This causes two problems:
>
> 1. We pass back NULL to the caller via the contentp field,
> but the fu
Jonathan Nieder wrote:
Thanks for catching it. Do you use a broken link detection tool to
detect this kind of issue automatically?
Yeah, in the Fedora git builds we pass all the generated html files
through the linkchecker tool (http://wummel.github.io/linkchecker/).
We started using that
Jonathan Nieder writes:
> Aside: git-update-index(1) says
>
> Version 4 is relatively young (first released in 1.8.0 in
> October 2012).
>
> My first reaction is to wonder if it is time to introduce a config
> option to use index format version 4 by default, since after 5 years
> it i
Todd Zullinger wrote:
> In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/
> into header, 2017-09-26) the string-list API documentation was moved to
> string-list.h. The argv-array API documentation may follow a similar
> course in the future. Until then, prevent the broken
In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/
into header, 2017-09-26) the string-list API documentation was moved to
string-list.h. The argv-array API documentation may follow a similar
course in the future. Until then, prevent the broken link from making
it to the end
Alex Vandiver wrote:
> As part of gathering some automated performance statistics of git, it
> would be useful to be able to extract some vital properties of the
> index. While `git update-index` has ways to _set_ the index version,
> and enable/disable various extensions, AFAICT there is no meth
Alex Vandiver writes:
> On Fri, 6 Oct 2017, Junio C Hamano wrote:
>> > Do folks have feelings about surfacing this information, and where such
>> > logic should live?
>>
>> Probably one of the t/helper/test-dump-*.c programs, if we already
>> do not have one.
>
> The goal would be to be able to
Todd Zullinger writes:
> I noticed this broken link in the html documentation while building
> 2.15.0-rc0. I'm not sure whether it's better to point the link to the
> string-list.h file on Git Hub, remove the link, or drop the entire
> paragraph.
Probably removing the link is the right thing to
Jeff King wrote:
> On Thu, Oct 05, 2017 at 05:11:04AM -0400, rpj...@crashcourse.ca wrote:
>> - GIT_AUTHOR_IDENT
>> - GIT_COMMITTER_IDENT
>> - GIT_EDITOR
>> - GIT_PAGER
>>
>> first question -- what is it about precisely those four variables that makes
>> them "logical" variables in git parlance
René Scharfe writes:
> An error message is already shown by object_as_type(), which is called
> by the lookup functions. The walk callback functions are expected to
> handle NULL object pointers passed to them, but put_object_name() needs
> a valid object, so avoid calling it without one.
Thank
Martin Ågren writes:
> v2: Except for the slightly different documentation in cache.h, this is
> a squash of the last two patches of v1. I hope the commit message is
> better.
Yeah, it is long ;-) but readable.
Thanks.
Martin Ågren writes:
> diff --git a/read-cache.c b/read-cache.c
> index 65f4fe837..1c917eba9 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -2343,14 +2343,13 @@ static int do_write_locked_index(struct index_state
> *istate, struct lock_file *l
> int ret = do_write_index(istate, lock
Martin Ågren writes:
> `newfd` starts out negative. If we then take the lock, `newfd` will
> become non-negative. We later check for exactly that property before
> calling `write_locked_index()`. That is, we are simply using `newfd` as
> a boolean to keep track of whether we took the lock or not.
Martin Ågren writes:
> Bump `found` to the scope of the whole function and rearrange the "roll
> back or write?"-checks to a straightforward if-else on `found`. This
> also future-proves the code by making it obvious that we intend to take
> exactly one of these paths.
>
> Improved-by: Jeff King
Stefan Beller writes:
> On Thu, Oct 5, 2017 at 2:25 PM, Robert P. J. Day
> wrote:
>>
>> more pedantic nitpickery, but the git source/docs seems to bounce
>> all over the place as to which of those forms is the right one.
>> opinions?
>
> In the code we use all lowercase to compare (any input
On Fri, 6 Oct 2017, Junio C Hamano wrote:
> > Do folks have feelings about surfacing this information, and where such
> > logic should live?
>
> Probably one of the t/helper/test-dump-*.c programs, if we already
> do not have one.
The goal would be to be able to extract this information from
repo
Alex Vandiver writes:
> Do folks have feelings about surfacing this information, and where such
> logic should live?
Probably one of the t/helper/test-dump-*.c programs, if we already
do not have one.
Torsten Bögershausen writes:
> Before we put this into stone:
> Does it make sense to say "renormalize" instead of "rehash" ?
> (That term does exist already for merge.
> And rehash is more a technical term, rather then a user-point-of-view
> explanation)
I do not mind "renormalize" at all.
Heya,
As part of gathering some automated performance statistics of git, it
would be useful to be able to extract some vital properties of the
index. While `git update-index` has ways to _set_ the index version,
and enable/disable various extensions, AFAICT there is no method by
which one can ask
Jeff King writes:
> On Thu, Oct 05, 2017 at 08:19:13PM +0900, Junio C Hamano wrote:
>
>> This is unrelated to the main topic of this patch, but we see this
>> just before the precontext of this hunk:
>>
>> if (dco && dco->state != CE_NO_DELAY) {
>>
On Thu, Oct 5, 2017 at 2:23 PM, Thomas Braun
wrote:
> completion: Add forgotten describe options
When/Why was it forgotten? git-blame thinks it was me in b0176ce6b5
(builtin/describe: introduce --broken flag, 2017-03-21)
Which do you add? (dirty and broken)
I had these questions when reading th
On Thu, Oct 5, 2017 at 1:54 PM, wrote:
> From: Jameson Miller
>
> It is not clear what the correct behavior should be when you ask for
> specific ignored behavior without reporting untracked files. For now,
> report this as an unsupported combination of input arguments, so it
> can be modified i
Signed-off-by: Thomas Braun
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d934417475..0e16f017a4 100644
--- a/contrib/completion/git-completion.b
On Thu, Oct 5, 2017 at 1:54 PM, wrote:
> From: Jameson Miller
>
> Add tests for new ignored mode (matching) when showing all untracked
> files.
>
> Signed-off-by: Jameson Miller
> ---
> t/t7519-ignored-mode.sh | 132
>
> 1 file changed, 132 ins
On Thu, Oct 5, 2017 at 1:54 PM, wrote:
> From: Jameson Miller
>
> Signed-off-by: Jameson Miller
> ---
> Documentation/git-status.txt | 22 +-
> Documentation/technical/api-directory-listing.txt | 28
> +++
> 2 files changed, 45 insertio
Signed-off-by: Thomas Braun
---
contrib/completion/git-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index d934417475..0e16f017a4 100644
--- a/contrib/completion/git-completion.b
> builtin/add.c | 42 +-
> 1 file changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/add.c b/builtin/add.c
> index 5d5773d5cd..264f84dbe7 100644
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -26,6 +26,7 @@ static const char * const built
On Thu, Oct 5, 2017 at 2:25 PM, Robert P. J. Day wrote:
>
> more pedantic nitpickery, but the git source/docs seems to bounce
> all over the place as to which of those forms is the right one.
> opinions?
In the code we use all lowercase to compare (any input is converted to
lowercase);
in the d
more pedantic nitpickery, but the git source/docs seems to bounce
all over the place as to which of those forms is the right one.
opinions?
rday
--
Robert P. J. Day Ottawa, Ontario, CANAD
On 10/05/2017 05:16 PM, Jonathan Nieder wrote:
Hi,
jameson.mille...@gmail.com wrote:
This patch series is the second part of [1], which was split into 2
parts. The first part, added an optimization in the directory listing
logic to not scan the contents of ignored directories and was merged
Am 05.10.2017 um 21:33 schrieb Stefan Beller:
On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt wrote:
+git-post(1)
+===
+
+NAME
+
+git-post - Apply a commit on top of a branch that is not checked out
Contrasted to:
git-cherry-pick - Apply the changes introduced by some existing c
Hi,
jameson.mille...@gmail.com wrote:
> This patch series is the second part of [1], which was split into 2
> parts. The first part, added an optimization in the directory listing
> logic to not scan the contents of ignored directories and was merged
> to master with commit 5aaa7fd3. This patch s
In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/
into header, 2017-09-26) the string-list API documentation was moved
into string-list.h. Fix the link from the argv-array API documentation.
Signed-off-by: Todd Zullinger
---
Hi,
I noticed this broken link in the html doc
Hi Lars,
On Thu, 5 Oct 2017, Lars Schneider wrote:
> > On 05 Oct 2017, at 22:02, Johannes Schindelin
> > wrote:
> >
> > It is my pleasure to announce that Git for Windows 2.14.2(2) is available
> > from:
> >
> > https://git-for-windows.github.io/
> >
> > Changes since Git for Windows v2
From: Jameson Miller
Teach status command to handle matching ignored mode when showing
untracked files with the normal option.
Signed-off-by: Jameson Miller
---
dir.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index b9af87eca9..8636d
From: Jameson Miller
This patch series is the second part of [1], which was split into 2
parts. The first part, added an optimization in the directory listing
logic to not scan the contents of ignored directories and was merged
to master with commit 5aaa7fd3. This patch series includes the second
From: Jameson Miller
This change teaches the status command more options to control which
ignored files are reported independently of the which untracked files
are reported by allowing the `--ignored` option to take additional
arguments. Currently, the shown ignored files are linked to how
untra
From: Jameson Miller
Signed-off-by: Jameson Miller
---
Documentation/git-status.txt | 22 +-
Documentation/technical/api-directory-listing.txt | 28 +++
2 files changed, 45 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-sta
From: Jameson Miller
It is not clear what the correct behavior should be when you ask for
specific ignored behavior without reporting untracked files. For now,
report this as an unsupported combination of input arguments, so it
can be modified in the future without back compat concerns.
Signed-o
From: Jameson Miller
Add tests for new ignored mode (matching) when showing all untracked
files.
Signed-off-by: Jameson Miller
---
t/t7519-ignored-mode.sh | 132
1 file changed, 132 insertions(+)
create mode 100755 t/t7519-ignored-mode.sh
diff
From: Jameson Miller
Add tests for status handling of '--ignored=matching` and
`--untracked-files=normal`.
Signed-off-by: Jameson Miller
---
t/t7519-ignored-mode.sh | 63 +
1 file changed, 63 insertions(+)
diff --git a/t/t7519-ignored-mode.sh b/
When an hook is present but the file is not set as executable then git will
ignore the hook.
For now this is silent which can be confusing.
This commit adds this warning to improve the situation:
hint: The 'pre-commit' hook was ignored because it's not set as executable.
hint: You can disable
On Wed, Oct 4, 2017 at 6:40 AM, Junio C Hamano wrote:
> Damien writes:
>
>> ---
>
> Please explain why this change makes sense to those who find this
> commit in "git log" output six months down the line, without having
> read the original thread that motivated you to add this feature
> above thi
We have two users of `struct apply_state` and the related functionality
in apply.c. Each user sets up its `apply_state` by handing over a
pointer to its static `lock_file`. (Before 076aa2cbd (tempfile:
auto-allocate tempfiles on heap, 2017-09-05), we could never free
lockfiles, so making them stati
Similar to a previous patch, we do not need to use `newfd` to signal
that we have a lockfile to clean up. We can just unconditionally call
`rollback_lock_file`. If we do not hold the lock, it will be a no-op.
Where we check `newfd` to decide whether we need to take the lock, we
can instead use `is
The next patches will tweak the behavior of this function. Document it
in order to establish a basis for those patches.
Signed-off-by: Martin Ågren
---
v2: Tweaked to go better with the changed approach in the later patches.
cache.h | 16
1 file changed, 16 insertions(+)
diff
The function has always been documented as returning 0 or -1. It is in
fact `void`. Correct that. As part of the rearrangements we lose the
mention that `delete_tempfile()` might set `errno`. Because there is
no return value, the user can't really know whether it did anyway.
Signed-off-by: Martin
If the original version of `write_locked_index()` returned with an
error, it didn't roll back the lockfile unless the error occured at the
very end, during closing/committing. See commit 03b866477 (read-cache:
new API write_locked_index instead of write_index/write_cache,
2014-06-13).
In commit 9f
`update_index_if_able()` used to always commit the lock or roll it back.
Commit 03b866477 (read-cache: new API write_locked_index instead of
write_index/write_cache, 2014-06-13) stopped rolling it back in case a
write was not even attempted. This change in behavior is not motivated
in the commit me
`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`.
At most one is allowed. But it is also possible to use no flag, i.e.,
`0`. But when `write_locked_index()` calls `do_write_index()`, the
temporary file, a.k.a. the lockfile, will be closed. So passing `0` is
effectively the sam
On 3 October 2017 at 08:21, Junio C Hamano wrote:
> Martin Ågren writes:
>> On 2 October 2017 at 08:30, Junio C Hamano wrote:
>>
>> Thanks both of you for your comments. Based on them, I have made the
>> following notes:
>> ...
>> Especially 9-11 make me feel like wanting to re-roll this, for fu
There is no longer any need to allocate and leak a `struct lock_file`.
Initialize it on the stack instead.
Before this patch, we set `lock = NULL` to signal that we have already
rolled back, and that we should not do any more work. We need to take
another approach now that we cannot assign NULL. W
There is no longer any need to allocate and leak a `struct lock_file`.
The previous patch addressed an instance where we needed a minor tweak
alongside the trivial changes.
Deal with the remaining instances where we allocate and leak a struct
within a single function. Change them to have the `stru
After we have taken the lock using `LOCK_DIE_ON_ERROR`, we know that
`newfd` is non-negative. So when we check for exactly that property
before calling `write_locked_index()`, the outcome is guaranteed.
If we write and commit successfully, we set `newfd = -1`, so that we can
later avoid calling `r
`newfd` starts out negative. If we then take the lock, `newfd` will
become non-negative. We later check for exactly that property before
calling `write_locked_index()`. That is, we are simply using `newfd` as
a boolean to keep track of whether we took the lock or not. (We always
use `newfd` and `lo
Commit 83a3069a3 (lockfile: do not rollback lock on failed close,
2017-09-05) forgot to update the documentation by the function definition
to reflect that the lock is not rolled back in case closing fails.
Signed-off-by: Martin Ågren
Signed-off-by: Junio C Hamano
---
v2: Identical.
lockfile.h
> On 05 Oct 2017, at 22:02, Johannes Schindelin
> wrote:
>
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.14.2(2) is available
> from:
>
> https://git-for-windows.github.io/
>
> Changes since Git for Windows v2.14.2 (September 26th 2017)
>
> New Features
>
Because 'stash push' and 'stash save' are so closely related they share one
section in the man page. Currently 'stash save' comes first, as that
was the command that people were historically using. However this makes
the newer, more feature rich git stash push very easy to overlook.
Change the or
Dear Git users,
It is my pleasure to announce that Git for Windows 2.14.2(2) is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.14.2 (September 26th 2017)
New Features
* Comes with BusyBox v1.28.0pre.16467.b4c390e17.
* Comes with Git LFS v2.3.2.
On 10/04, Junio C Hamano wrote:
> I do not object with such a well designed deprecation plan for any
> other features, if there are other "favourite" ones people would
> want to deprecate and eventually remove, by the way.
Since you were asking :) With the introduction of 'git stash push',
my hop
René Scharfe wrote:
> Reported-by: Johannes Schindelin
> Reported-by: Stefan Beller
> Signed-off-by: Rene Scharfe
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
A quick "git shortlog -nse" run confirms that this works.
Reviewed-by: Jonathan Nieder
Thanks.
> diff --git a/.mailmap
lookup_blob() and lookup_tree() can return NULL if they find an object
of an unexpected type. Accessing the object member is undefined in that
case. Cast the result to a struct object pointer instead; we can do
that because object is the first member of all object types. This trick
is already us
Am 04.10.2017 um 06:00 schrieb Junio C Hamano:
> René Scharfe writes:
>> lookup_blob() and lookup_tree() can return NULL if they find an object
>> of an unexpected type. Error out of fsck_walk_tree() in that case, like
>> we do when encountering a bad file mode. An error message is already
>> sh
Reported-by: Johannes Schindelin
Reported-by: Stefan Beller
Signed-off-by: Rene Scharfe
---
.mailmap | 1 +
1 file changed, 1 insertion(+)
diff --git a/.mailmap b/.mailmap
index ab85e0d16d..224db83887 100644
--- a/.mailmap
+++ b/.mailmap
@@ -194,6 +194,7 @@ Philippe Bruhat
Ralf Thielow
Ra
On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt wrote:
> Add a new command that can be used to copy an arbitrary commit
> to a branch that is not checked out.
Cool. :)
>
> Signed-off-by: Johannes Sixt
> ---
> I have been using this command since years, but got around to
> write a man page and
Add a new command that can be used to copy an arbitrary commit
to a branch that is not checked out.
Signed-off-by: Johannes Sixt
---
I have been using this command since years, but got around to
write a man page and tests only now. I hope the man page makes
sense. I don't have the tool chain t
On Thu, Oct 05, 2017 at 07:25:52PM +0200, Andreas Krey wrote:
> I got something that looks like a regression somewhere since 2.11.
> This script
>
> set -xe
> rm -rf repo
> git init repo
> cd repo
> git commit -m nix --allow-empty
> git branch -m master/master
> git rev-parse HEAD
>
Hi everybody,
I got something that looks like a regression somewhere since 2.11.
This script
set -xe
rm -rf repo
git init repo
cd repo
git commit -m nix --allow-empty
git branch -m master/master
git rev-parse HEAD
git branch
git status
causes .git/HEAD to still contain 'ref: re
+ Rene
- kernel mailing list
On Thu, Oct 5, 2017 at 6:10 AM, Johannes Schindelin
wrote:
> Hi Junio,
>
> On Thu, 5 Oct 2017, Junio C Hamano wrote:
>
>> New contributors whose contributions weren't in v2.14.0 are as follows.
>> Welcome to the Git development community!
>>
>> Ann T Ropea, Daniel W
On 05/10/2017 16:21, ankostis wrote:
>
> But this seems to have stopped working; I clicked the link in the page below
> https://support.google.com/accounts/answer/6010255?hl=en
> and for my account it tells me "less secure apps" access is unavailable :-(
It says for me "This setting is not avai
UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE
- NO COLLATERAL
- MINIMUM DOCUMENTATION
- BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS
CONTACT US TODAY VIA EMAIL: financeloa...@hotmail.com
On 5 October 2017 at 15:43, Paolo Bonzini wrote:
>
> On 05/10/2017 12:52, Lars Schneider wrote:
> > Hi,
> >
> > I used to use the Google SMTP server to send my patches to the list with
> > the following config:
> >
> > [sendemail]
> > smtpencryption = tls
> > smtpserver = smtp.
Hi all,
I noticed a possible inconsistency in the documentation for
.gitignore; the pertinent bit is:
If the pattern does not contain a slash /, Git treats it as a
shell glob pattern
and checks for a match against the pathname relative to the location of the
.gitignore file
...
On 05/10/2017 12:52, Lars Schneider wrote:
> Hi,
>
> I used to use the Google SMTP server to send my patches to the list with
> the following config:
>
> [sendemail]
> smtpencryption = tls
> smtpserver = smtp.gmail.com
> smtpuser = larsxschnei...@gmail.com
> s
The check_all argument is pointless, because the function degenerates
to !same_trailer when check_all==0 (if same_trailer fails, it always
ends up returning 1). Remove it, switching the check_all==0 caller
to use same_trailer directly.
Signed-off-by: Paolo Bonzini
---
trailer.c | 15 ++-
In some cases, people apply patches to a queue branch immediately
with "git am -3 -s", and later collect Reviewed-by or Acked-by
trailers as they come in from the mailing list.
In this case, "where=after" does not have the desired behavior,
because it will add the trailer in an unorthodox position
Create a new function apply_arg that takes care of computing the new
trailer's "neighbor", checking for duplicates through a pluggable
callback, and adding the new argument according to "trailer.where".
Rename after_or_end, and don't use it in apply_arg. It's a coincidence
that the conditions for
All callees of process_trailers_lists are calling free_arg_item.
Just do it in process_trailers_lists itself.
Signed-off-by: Paolo Bonzini
---
trailer.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/trailer.c b/trailer.c
index 3ba157ed0..4ba28ae33 100644
--- a/trai
The purpose of this action is for scripts to be able to keep the
user's Signed-off-by at the end. For example say I have a script
that adds a Reviewed-by tag:
#! /bin/sh
them=$(git log -i -1 --pretty='format:%an <%ae>' --author="$*")
trailer="Reviewed-by: $them"
git log -1 --prett
Hi Junio,
On Thu, 5 Oct 2017, Junio C Hamano wrote:
> New contributors whose contributions weren't in v2.14.0 are as follows.
> Welcome to the Git development community!
>
> Ann T Ropea, Daniel Watkins, Dimitrios Christidis, Eric Rannaud,
> Evan Zacks, Hielke Christian Braun, Ian Campbell, I
On 10/5/2017 6:00 AM, Jeff King wrote:
On Thu, Oct 05, 2017 at 06:48:10PM +0900, Junio C Hamano wrote:
Jeff King writes:
This is weirdly specific. Can we accomplish the same thing with existing
tools?
E.g., could:
git cat-file --batch-all-objects --batch-check='%(objectname)' |
shu
Hi Junio,
On Wed, 4 Oct 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > This patch offers the new suffix :remote for the upstream and for the
> > push atoms, allowing to show exactly that.
>
> Has the design changed since this description and examples were
> written?
Obviously
From: J Wyman
There are times when scripts want to know not only the name of the
push branch on the remote, but also the name of the branch as known
by the remote repository.
An example of this is when a tool wants to push to the very same branch
from which it would pull automatically, i.e. the
This not only prevents regressions, but also serves as documentation
what this new feature is expected to do.
Signed-off-by: Johannes Schindelin
---
t/t6300-for-each-ref.sh | 32
1 file changed, 32 insertions(+)
diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for
There are times when e.g. scripts want to know not only the name of the
upstream branch on the remote repository, but also the name of the
remote.
This patch offers the new suffix :remotename for the upstream and for
the push atoms, allowing to show exactly that. Example:
$ cat .git/confi
This introduces support for
git for-each-ref \
--format="%(merge:remotename),%(merge:remoteref)"
git for-each-ref \
--format="%(push:remotename),%(push:remoteref)"
to figure out the remote nickname as well as the name of the corresponding
branch on
1 - 100 of 131 matches
Mail list logo
