Paul Tan writes:
>> + /* Does it have any Signed-off-by: in the text */
>> + for (cp = sb->buf;
>> +cp && *cp && (cp = strstr(cp, sign_off_header)) != NULL;
>> +cp = strchr(cp, '\n')) {
>> + if (sb->buf == cp || cp[-1] == '\n')
>> +
Levin Du writes:
> Since A & B share many common files, to save disk space, I'd like to merge
> them:
> (note: branch of A & B are independent, i.e. have no common ancestor.)
Not having any shared history is exactly the cause. If the
optimization were to exchange list of all the commits, blobs
Gábor Bernát writes:
> +if date '+%s' 2>/dev/null | grep -q '^[0-9][0-9]*$'
> +then
> + show_seconds=t
> +else
> + show_seconds=
> +fi
> +
> +case "$show_seconds" in
> +t)
> + start_timestamp=$(date +%s)
> + next_sample_at=0
> + ;;
> +'')
> + progress=""
> + ;;
> +esac
Karthik Nayak writes:
> diff --git a/Documentation/git-for-each-ref.txt
> b/Documentation/git-for-each-ref.txt
> index d039f40..c5154bb 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -128,13 +128,14 @@ color::
> are described in `color.bra
Nguyễn Thái Ngọc Duy writes:
> Noticed-by: Bjørnar Snoksrud
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/clone.c | 6 --
> t/t2025-worktree-add.sh | 5 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 578d
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
The cover letter talks about "local clone", and in this entire
series, I saw new tests only for the local case, but doesn't this
and the next change also affect the case where a Git daemon or a
upload-pack process is serv
Jens Lehmann writes:
> Am 07.09.2015 um 01:43 schrieb Eric Sunshine:
>
>> My concern in asking was that some future person might come up with
>> another scenario which also wants to use a "magic value" and would
>> have to invent / arrive at another "illegal" representation. Hence, an
>> explicit
Jeff King writes:
> Subject: [PATCH] git_connect: clarify conn->use_shell flag
>
> When executing user-specified programs, we generally always
> want to use a shell, for flexibility and consistency. One
> big exception is executing $GIT_SSH, which for historical
> reasons must not use a shell.
>
Eric Sunshine writes:
> On Mon, Sep 7, 2015 at 9:52 AM, Gábor Bernát wrote:
>...
>> # Rewrite the commits
>> +report_progress ()
>> +{
>> +if test -n "$progress"
>> +then
>
> Indent code within the function...
Also git_filter_branch__commit_count is now used only inside this
function, so it is
Jeff King writes:
> On Sat, Sep 05, 2015 at 09:56:27PM -0700, Junio C Hamano wrote:
>
>> +static void am_signoff(struct strbuf *sb)
>> +{
>> +char *cp;
>> +struct strbuf mine = STRBUF_INIT;
>> +
>> +/* Does it end with our own sign-of
Michael J Gruber writes:
> sigo venit, vidit, dixit 05.09.2015 14:22:
>> I've found really "little bug" with dots in the git output.
>>
>> $ git push
>> Everything up-to-date
>>
>> git pull
>> Already up-to-date.
>>
>> Could all phrases contain dots? :)
>>
>
> In this case, also both messages
Matthieu Moy writes:
>>> This line still looks overlong. Would it help to stop spelling this
>>> as a double "a = b = overlong expression" assignment?
>>>
>>
>> I'm not sure, I get what you mean.
>
> I guess
>
> format = xstrfmt("%%(align:15,left)%%(refname:short)%%(end)
> %%(contents:lines=%d)
Karthik Nayak writes:
>> I am flexible with the terminology, but the point is that I think
>> the quoting rules are better be specified _outside_ the description
>> of a particular atom, but as a general rule.
>
> I definitely agree, but like Matthieu said, corrently we have only
> one such atom
Jeff King writes:
> If you turn on reachability bitmaps, git _will_ do the thorough set
> difference, because it becomes much cheaper to do so. E.g., try:
>
> git repack -adb
>
> in repo A to build a single pack with bitmaps enabled. Then a subsequent
> push should send only a single object (
Ævar Arnfjörð Bjarmason writes:
> On Mon, Sep 7, 2015 at 5:36 PM, Olaf Hering wrote:
>> Am 07.09.2015 um 17:34 schrieb Ævar Arnfjörð Bjarmason:
>>> On Mon, Sep 7, 2015 at 5:07 PM, Olaf Hering wrote:
>>
https://github.com/libguestfs/libguestfs/commit/0306c98d319d189281af3c15101c8d343e400f13
Jeff King writes:
> On Mon, Sep 07, 2015 at 02:51:42PM -0300, Renato Botelho wrote:
>
>> Default variables used to build are set using = on Makefile, (e.g. CC,
>> INSTALL, CFLAGS, …). GNU make overwrite these values if it’s passed as
>> an argument (make CC=clang) and it works as expected.
>>
>>
Stefan Beller writes:
> On Thu, Sep 3, 2015 at 3:07 PM, Junio C Hamano wrote:
>>> +
>>> + cp.no_stdin = 1;
>>> + cp.no_stdout = 1;
>>> + cp.no_stderr = 1;
>>
>> Output from "git clone" is not shown, regardless of --qui
Buchacher, Dave Borowitz, David
Aguilar, David Turner, Elia Pinto, Eric Sunshine, Heiko
Voigt, Ilya Bobyr, Jacob Keller, Jeff King, Jiang Xin, Jim
Hill, Johannes Schindelin, Johannes Sixt, Junio C Hamano,
Karsten Blees, Karthik Nayak, Kevin Daudt, Matthieu Moy,
Michael Haggerty, Mike Hom
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> If read_pipe crashes then the caller can inspect the error and handle
> it appropriately.
>
> Signed-off-by: Lars Schneider
> ---
> git-p4.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-p4.py b/git-
Jeff King writes:
> The "simplest" way to do that is:
>
> rm .git/refs/heads/master
>
> but that is not guaranteed to work in future versions of git, and I
> wouldn't recommend it in general.
Yeah, "git checkout -b" has a stronger sibling "git checkout -B"
(i.e. I know that the named branch al
larsxschnei...@gmail.com writes:
> @@ -2226,17 +2355,16 @@ class P4Sync(Command, P4UserMap):
> text = regexp.sub(r'$\1$', text)
> contents = [ text ]
>
> -self.gitStream.write("M %s inline %s\n" % (git_mode, relPath))
> +if relPath == '.gitattributes':
>
Ehh, I was only kidding, though...
On Wed, Sep 9, 2015 at 10:37 AM, Karthik Nayak wrote:
> On Tue, Sep 8, 2015 at 11:50 PM, Junio C Hamano wrote:
>> Matthieu Moy writes:
>>
>>>>> This line still looks overlong. Would it help to stop spelling this
>>>>
Lars Schneider writes:
>> Also the exact format of these attributes entries looks like very
>> closely tied to GitHub LFS and not generic (for example, there is no
>> reason to expect that any large-file support would always use the
>> "filter" mechanism or the gitattributes mechanism for that
>>
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 first release candidate 2.6-rc1 has been tagged. Let's make
sure we catch any possible regressions from now on, without getting
distracted
ifference on Windows, in one case a `git
rebase --skip` took 1m40s without, and 5s with, this patch.
cf. https://github.com/git-for-windows/git/issues/365
Reported-and-suggested-by: Kim Gybels
Acked-by: Paul Tan
Signed-off-by: Johannes Schindelin
Signed-off-by: Junio C Hamano
---
git-am.sh |
Luke Diamand writes:
> def run(self, args):
> if len(args) == 0:
> self.master = currentGitBranch()
> -if len(self.master) == 0 or not gitBranchExists("refs/heads/%s"
> % self.master):
> -die("Detecting current git branch failed!")
> +
Jeff King writes:
> I did wonder if we needed to deal with any fallout from f4c3edc
> (vreportf: avoid intermediate buffer, 2015-08-11). That _is_ new in this
> release, so regressions are fair game during the -rc period.
Yeah, and the most obvious way to deal with it is just to revert,
but as y
Luke Diamand writes:
> On 9 September 2015 at 22:52, Junio C Hamano wrote:
>> Luke Diamand writes:
>>
>>> def run(self, args):
>>> if len(args) == 0:
>>> self.master = currentGitBranch()
>>> -if len(
ite a test for the same.
>
> Mentored-by: Christian Couder
> Mentored-by: Matthieu Moy
> Thanks-to: Junio C Hamano
> Signed-off-by: Karthik Nayak
> ---
> ref-filter.c | 23 +--
> t/t6302-for-each-ref-filter.sh | 4
> 2 files changed,
Karthik Nayak writes:
> Implement an `align` atom which left-, middle-, or right-aligns the
> content between %(align:...) and %(end).
Nicely done.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
Karthik Nayak writes:
> diff --git a/ref-filter.c b/ref-filter.c
> index 7d2732a..b098b16 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -56,6 +56,7 @@ static struct {
> { "color" },
> { "align" },
> { "end" },
> + { "contents:lines" },
Do we even need "contents:line
Matthieu Moy writes:
> OTOH, you are now accepting %(atom:) as a synonym to %(atom), and it's
> not clear whether this is a deliberate decition.
I would say so. When the caller wants to reject %(atom:), the
caller can tell it by checking val[0] == '\0' and reject that.
So it is better if you d
Karthik Nayak writes:
> The check was for checking if there is anything after the colon,
Why do you even care? If %(color) expects more specific
customization by adding colon followed by specific data after it,
i.e. %(color:something), %(color:) should clearly be that "%(color)"
thing with no c
Jacob Keller writes:
> Is there some other way? Would others be interested in such a feature?
Not me.
> I get very annoyed when I've written a nice long patch cover letter in
> vim before an email and then realize I should fix something else up,
> or accidentally cancel it because I didn't use
Karthik Nayak writes:
> It is one thing that the user can actually do the check themselves,
> but doesn't it make more sense that when we're using colon we expect a
> value after it, and something like %(color:) makes no sense when color
> specifically needs a value after the colon.
If you imagi
Karthik Nayak writes:
> -static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting)
> +static int list_tags(struct ref_filter *filter, struct ref_sorting *sorting,
> const char *format)
> {
> struct ref_array array;
> - char *format, *to_free = NULL;
> + char *to
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Karthik Nayak writes:
>>
>>> - } else if (starts_with(name, "color:")) {
>>> + } else if (match_atom_name(name, "color", &valp)) {
>>
>> Why use the
Martin Fick writes:
> As a Gerrit developer and user, I would like a way to
> see/review cover letters in Gerrit. We have had many
> internal proposals, most based on git notes, but we have
> also used the empty commit trick. It would be nice if there
> were some standard git way to do this
Jacob Keller writes:
> I hadn't thought of separating the cover letter from git-send-email.
> That would be suitable for me.
Yeah, I said this number of times over time, and I said it once
recently in another thread, but I think it was a mistake to allow
git-send-email to drive format-patch. It
Michael Rappazzo writes:
> Including functions to get the list of all worktrees, and to get
> a specific worktree (primary or linked).
Was this meant as a continuation of the sentence started on the
Subject line, or is s/Including/Include/ necessary?
> diff --git a/worktree.c b/worktree.c
> new
lenames longer than PATH_MAX
notes: use a strbuf in add_non_note
read_info_alternates: handle paths larger than PATH_MAX
show-branch: use a strbuf for reflog descriptions
Jim Hill (1):
strbuf_read(): skip unnecessary strbuf_grow() at eof
Johannes Sixt (1):
t2019: skip
Eric Wong writes:
> Michael J Gruber wrote:
>> Instead, make git svn uses the perl regex
>>
>> /^(.+?|\(no author\))\s*=\s*(.+?)\s*<(.*)>\s*$/
>>
>> for parsing the authors file so that the same (slightly more lenient)
>> regex is used in both cases.
>>
>> Reported-by: Till Schäfer
>> Signed
Max Kirillov writes:
> * There are more conflicts in pu with [1], not sure
> what should I do about it.
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/276628
I do not think conflicts got any worse than before. Between the
result of merging this round and the previous one to 'p
Michael Rappazzo writes:
> The code formerly in branch.c was largely the basis of the
> get_worktree_list implementation is now moved to worktree.c,
> and the find_shared_symref implementation has been refactored
> to use get_worktree_list
>
> Signed-off-by: Michael Rappazzo
> ---
> branch.
Junio C Hamano writes:
> Dave Borowitz writes:
>
>> I produced the patch with "git format-patch --subject-prefix='PATCH
>> v2' --cover-letter @{u}.." and mailed with "git send-email
>> --to=git@vger.kernel.org,gits...@pobox.com 0*.patch";
Jeff King writes:
> I'm not too familiar with the code, but this _seems_ to work for me:
>
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 21321be..2e03d47 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -1375,6 +1375,10 @@ static struct commit_list *first_scapegoat(struct
>
Ralf Thielow writes:
> The description of option "create-reflog" is "create_reflog", which
> is neither a good description, nor a sensible string to translate.
> Change it to a more meaningful message.
>
> Signed-off-by: Ralf Thielow
> ---
This definitely is an improvement. I will assume i18n
This "feels" correct ;-), but let me summon Duy who did the %><
padding at around a5752342 (pretty: support padding placeholders, %<
%> and %><, 2013-04-19) for an extra set of eyes.
Care to add a test or two while at it?
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git"
Eric Sunshine writes:
> In addition to a link to the previous round and an interdiff, it would
> be helpful to reviewers for you to annotate each patch (in the
> commentary are below the "---" line after your sign-off) with a
> description of the changes in that patch since the previous round in
Junio C Hamano writes:
> Jeff King writes:
>
>> I'm not too familiar with the code, but this _seems_ to work for me:
>>
>> diff --git a/builtin/blame.c b/builtin/blame.c
>> index 21321be..2e03d47 100644
>> --- a/builtin/blame.c
>> +++ b/builtin/
Eric Sunshine writes:
>> + qz_to_tab_space
> You don't seem to be taking advantage of qz_to_tab_space's
> transliteration of Q to tab and Z to space, so s/qz_to_tab_space/cat/
> would make the code clearer.
Don't cat into a pipe unless you are concatenating multiple files,
t
Michael Haggerty writes:
> 1. The server advertises the references that it has in the way that it
> is currently done.
> 2. The client advertises the objects that it has (or some subset of
> them; see below) via a Bloom filter.
> 3. The server sends the client the packfile that results from assum
Mike Rappazzo writes:
> On Fri, Sep 11, 2015 at 12:16 PM, Junio C Hamano wrote:
>> Michael Rappazzo writes:
>>
>>> The code formerly in branch.c was largely the basis of the
>>> get_worktree_list implementation is now moved to worktree.c,
>>> and the
Michael Rappazzo writes:
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 71bb770..a0c0fe8 100644
> --- a/builtin/worktree.c
> +++ b/builtin/worktree.c
> @@ -8,10 +8,13 @@
> #include "run-command.h"
> #include "sigchain.h"
> #include "refs.h"
> +#include "utf8.h"
> +#include "wor
Junio C Hamano writes:
> Ideally, I would think that you want that information when the
> series is fully cooked and gets merged to a more permanent place in
> the log message of the merge commit. At that point, where the
> series started may become more clear from the topology (
Jeff King writes:
> Yeah, I think what is happening in this first hunk:
> ...
> is doing the right thing. It did feel a little weird to me to be munging
> the global commit objects themselves, but I guess it is fairly normal
> for git code.
Yeah, the above may be brilliant, but ...
>> diff --gi
Shawn Pearce writes:
> The worst case is due to a bug in the negotiation. With nothing
> common, the client just goes on forever until it reaches roots
> (something is wrong with MAX_IN_VAIN). We saw 56,318 have lines ... a
> 2.6 MiB section. But smart HTTP gzips, so this may be only 1.3 MiB on
>
Stefan Beller writes:
> diff --git a/run-command.c b/run-command.c
> index 28e1d55..b8ff67b 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -852,3 +852,147 @@ int capture_command(struct child_process *cmd, struct
> strbuf *buf, size_t hint)
> close(cmd->out);
> return finish_
Duy Nguyen writes:
> On Mon, Sep 7, 2015 at 11:33 PM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>> ---
>>
>> The cover letter talks about "local clone", and in this entire
>>
On Sun, Sep 13, 2015 at 9:30 PM, Jeff King wrote:
>
> Ah, OK. Today I learned something. :)
>
> Jeffrey, can you produce a tested patch which works for you?
If I am not mistaken, I think I already have one on 'pu' (I think I did that
as an afternoon-tea time hack or something).
--
To unsubscribe
On Sun, Sep 13, 2015 at 3:07 AM, Jeff King wrote:
>> The thing is, traversing first-parent chain in reverse fundamentally
>> is undefined. You can fork multiple topics at the tip of 'master'
>> and each of the topics may be single strand of pearls, but which one
>> of the topics is the first-chil
On Sun, Sep 13, 2015 at 9:59 PM, Jeff King wrote:
>
> My follow-up question was going to be: is this something we should be
> setting in config.mak.uname for appropriate versions of Darwin? It
> wasn't clear to me from Eric's description if this is something that
> particular versions need, or jus
const char *bp = desc.buf;
$ git show -s 898eacd8
commit 898eacd8ada2d012f977948350ed60845e238037
Author: Junio C Hamano
Date: Thu Oct 6 23:12:09 2011 -0700
fmt-merge-msg: use branch.$name.description
This teaches "merge --log" and fmt-merge-msg to use branch descript
Nguyễn Thái Ngọc Duy writes:
> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
> index 473623d..889a72a 100644
> --- a/Documentation/gitignore.txt
> +++ b/Documentation/gitignore.txt
> @@ -82,12 +82,9 @@ PATTERN FORMAT
>
> - An optional prefix "`!`" which negates the p
Nguyễn Thái Ngọc Duy writes:
> While commit 9f673f9 (gc: config option for running --auto in
> background - 2014-02-08) helps reduce some complaints about 'gc
> --auto' hogging the terminal, it creates another set of problems.
>
> The latest in this set is, as the result of daemonizing, stderr i
Junio C Hamano writes:
> Thanks, will queue.
Ehh, I spoke a bit too early.
>> diff --git a/builtin/gc.c b/builtin/gc.c
>> index bcc75d9..2c3aaeb 100644
>> --- a/builtin/gc.c
>> +++ b/builtin/gc.c
>> @@ -43,9 +43,20 @@ static struct argv_array prune_worktrees
Mike Rappazzo writes:
> On Sat, Sep 12, 2015 at 10:39 PM, Eric Sunshine
> wrote:
>>> +struct worktree_list *get_worktree_list()
>>
>> Can we be more concise and call this get_worktrees()?
>
> I prefer 'get_worktree_list' because I also added the 'get_worktree'
> function, and I wanted to differ
Jeff King writes:
> I don't think you need exact timing information. This is no different
> than running the commands themselves, with stdout and stderr writing to
> a pty that your terminal emulator will then read() from. If the program
> produces intermingled stdout/stderr that clogs up the te
Max Kirillov writes:
> Functions which directly operate submodule's object database do not
> handle the case when the submodule is linked worktree (which are
> introduced in c7b3a3d2fe). Instead of fixing the path calculation use
> already existing strbuf_git_path_submodule() function without cha
Max Kirillov writes:
> On Thu, Sep 10, 2015 at 06:10:13PM -0700, Junio C Hamano wrote:
>> When I push the updated 'pu' out, could you please check
>
> I follow the pu merges. So far resolutions seem correct and
> all tests pass.
The primary thing I ask from "
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> diff to v6:
> * Always print the encoded path in verbose mode.
>
> v6 is already on next (a9e383). This patch must be applied on next.
> Is this the right way to handle this situation?
Yes, I thought that the reviewers found v6 was soli
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> If a path with non-ASCII characters is detected then print always the
> encoding and the encoded string in verbose mode.
Earlier if the user tells us that s/he knows what she is doing
by setting the configuration, we just followed the i
Paul Mackerras writes:
> On Wed, Sep 09, 2015 at 03:20:53PM +0200, Giuseppe Bilotta wrote:
>> This allows fast, keyboard-only usage of the menu (e.g. Alt+V, N to open a
>> new view).
>>
>> Signed-off-by: Giuseppe Bilotta
>
> Thanks, applied.
Thanks; will pull from you before tagging 2.6-rc2.
Karthik Nayak writes:
> + /*
> + * First we obtain all regular branch refs and if the HEAD is
> + * detached then we insert that ref to the end of the ref_fist
> + * so that it can be printed and removed first.
> + */
> for_each_rawref(append_ref, &cb);
> + if (d
Karthik Nayak writes:
> Remove the error reporting variable to make the code easier to port
> over to using ref-filter APIs. This variable is not required as in
> ref-filter we already check for possible errors and report them.
H. What do you exactly mean "possible errors" here?
Unlike gen
Stefan Beller writes:
> This replaces the last patch of the "Parallel git submodule fetching"
> series. Changes:
>
> * have correct return code in submodule fetching when one submodule fails
> * use poll instead of select now
> * broke down into more smaller functions instead of one giant.
> (I
Dan Kegel writes:
Yes, "diff -M -B" is known to be problematic, unfortunately. It
incorrectly creates an irreversible patch under certain conditions.
http://thread.gmane.org/gmane.linux.kernel/1879635
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
Yes, "diff -M -B" is known to be problematic, unfortunately. It
incorrectly creates an irreversible patch under certain conditions.
http://thread.gmane.org/gmane.linux.kernel/1879635
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kerne
ian
m. carlson, Charles Bailey, Christian Couder, Clemens Buchacher,
Dave Borowitz, David Aguilar, David Turner, Elia Pinto, Eric
Sunshine, Giuseppe Bilotta, Heiko Voigt, Ilya Bobyr, Jacob
Keller, Jeff King, Jiang Xin, Jim Hill, Johannes Schindelin,
Johannes Sixt, Junio C Hamano, Kar
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 tip of 'master' is slightly past 2.6-rc2; hopefully l10n team
can work on this without updates before the end of the cycle.
You can find th
h.
When we are done with rerere(), which can be directly called from
other programs like "git apply", "git commit" and "git merge", the
shared rerere_dir structures can be freed entirely, so they are not
reference-counted and they are not freed when we release rerere
the part that deals with garbage
collection of old rerere database entries, which probably needs more
work (and could use help, hints hints...).
Junio C Hamano (7):
rerere: split conflict ID further
rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id
rerere: handle leftover
the same conflict ID.
We still need to adjust garbage collection codepaths for this
change, but the basic "replay" functionality is functional with
this change.
Signed-off-by: Junio C Hamano
---
rerere.c | 94 +--
t/t4200
this step.
Signed-off-by: Junio C Hamano
---
rerere.c | 127 ---
rerere.h | 1 +
2 files changed, 106 insertions(+), 22 deletions(-)
diff --git a/rerere.c b/rerere.c
index c0482b8..f674461 100644
--- a/rerere.c
+++ b/rerere.c
@@ -30
resolution of this new conflict.
In later patches, we will further update this logic to be "do we
have pair that cleanly resolve the current
conflicts? If not, record a new preimage as a new variant", but
that does not happen at this stage yet.
Signed-off-by: Junio C Hamano
.
Signed-off-by: Junio C Hamano
---
t/t4200-rerere.sh | 74 +++
1 file changed, 74 insertions(+)
diff --git a/t/t4200-rerere.sh b/t/t4200-rerere.sh
index 52a8e09..8d52854 100755
--- a/t/t4200-rerere.sh
+++ b/t/t4200-rerere.sh
@@ -407,4 +407,78
This will help fixing bootstrap corner-case issues, e.g. having an
empty $GIT_DIR/rr-cache/$ID directory would fail to record a
preimage, in later changes in this series.
Signed-off-by: Junio C Hamano
---
rerere.c | 32 +---
1 file changed, 29 insertions(+), 3
se would have been a situation frustratingly hard to recover
from.
Signed-off-by: Junio C Hamano
---
rerere.c | 42 +-
t/t4200-rerere.sh | 18 +-
2 files changed, 42 insertions(+), 18 deletions(-)
diff --git a/rerere.c b/rerere.c
index fbd
Jeffrey Walton writes:
>> Oh, indeed. ac179b4d9. Looks good to me.
>>
>> My follow-up question was going to be: is this something we should be
>> setting in config.mak.uname for appropriate versions of Darwin? It
>> wasn't clear to me from Eric's description if this is something that
>> particula
Jeff King writes:
> It seems like nobody is actually that interested in what "blame
> --first-parent --reverse" does in the first place, though, and there's
> no reason for its complexity to hold up vanilla --first-parent. So what
> do you think of:
I like the part that explicitly disables the c
Matthieu Moy writes:
> Not just the return type (which is the error status), but also the type
> of the result argument indeed. It's not clear to me whether this is
> intentional (09f2825 (git-grep: don't use sscanf, 2007-03-12) introduced
> it, the commit message doesn't help). I first read strt
Eric Sunshine writes:
>> +static inline void strbuf_complete(struct strbuf *sb, char term)
>> +{
>> + if (sb->len && sb->buf[sb->len - 1] != term)
>> + strbuf_addch(sb, term);
>> +}
>
> Hmm, so this only adds 'term' if not already present *and* if 'sb' is
> not empty, which do
Jeff King writes:
>> Hmm, I haven't read any other patches yet (including those which use these
>> new '_to' functions), but I can't help feeling they should be named something
>> like 'sha1_to_hex_str()' and 'find_unique_abbrev_str()' instead. i.e. I
>> don't get
>> the '_to' thing - not that
Ramsay Jones writes:
> How about using strlcpy() instead? Thus:
>
> - strcpy(header.name, "pax_global_header");
> + strlcpy(header.name, "pax_global_header", sizeof(header.name));
>
> Ditto for other similar (strcpy->xsnprintf) hunks below.
Please do not advocate use of strlcpy(), which
"Robin H. Johnson" writes:
> Specifically, if the author is NOT the same as the committer, then
> display both in the header. Otherwise continue to display only the
> author.
I too found myself wanting to see both of the names sometimes, and
the "fuller" format was added explicitly for that purp
Jeff King writes:
> Obviously this is not intended for v2.6.0. But all of the spots touched
> here are relatively quiet right now, so I wanted to get it out onto the
> list. There are a few minor conflicts against "pu", but they're all
> just from touching nearby lines.
Thanks. Looks like a lo
Lars Schneider writes:
>>> +git-p4.largeFileSystem::
>>> + Specify the system that is used for large (binary) files. Please note
>>> + that large file systems do not support the 'git p4 submit' command.
>>
>> Why is that? Is it just that you haven't implemented support, or
>> is it fundament
Michael Haggerty writes:
> I'm not sure what behavior you want. At one point you say "puts the file
> to a final place if it is non-empty" but later you say "leave it if
> non-empty". Should the file be written directly, or should it be written
> to a lockfile and renamed into place only when com
"Philip Oakley" writes:
> Oops..
> ...
>> Shall I just rework/resend the V2 patch-up ($gmane/277829) that also
>> links to 'merge's' usage as a fresh patch (would be tonight UK)?
>
> I now see that the full V2 patch is already there at 4934a96.
OK. I was wondering what I missed. 4934a96^2 is a
Jeff King writes:
> On Wed, Sep 16, 2015 at 10:15:02AM +0200, Johannes Schindelin wrote:
>
>> Maybe we should stick to the established practice of the many, many
>> reentrant POSIX functions following the *_r() naming convention? I.e.
>> the reentrant version of localtime() is called localtime_r(
501 - 600 of 31372 matches
Mail list logo
