Hi Junio,
On Fri, 8 Jul 2016, Junio C Hamano wrote:
> * js/am-call-theirs-theirs-in-fallback-3way (2016-07-08) 1 commit
> - am: counteract gender bias
>
> One part of "git am" had an oddball helper function that called
> stuff from outside "his" as opposed to calling what we have "ours",
> w
Hi Duy,
On Sun, 10 Jul 2016, Duy Nguyen wrote:
> We will be able to see refs from all worktrees if we choose to.
What I tried to say is: even if we make it technically feasible to have
per-worktree refs or reflogs, the downsides are too prohibitive. We should
simply not introduce support for tha
We already have "--date=raw", which is a Unix epoch
timestamp plus a contextual timezone (either the author's or
the local). But one may not care about the timezone and just
want the epoch timestamp by itself. It's not hard to parse
the two apart, but if you are using a pretty-print format,
you may
The "raw" format shows a Unix epoch timestamp, but with a
timezone tacked on. The timestamp is not _in_ that zone, but
it is extra information about the time (by default, the zone
the author was in).
The documentation claims that "raw-local" does not work. It
does, but the end result is rather sub
We document that asking for HEAD@{now} will switch the
output to show HEAD@{timestamp}, but not that specifying
`--date` has a similar effect, or that it can be overridden
with HEAD@{0}. Let's do so.
These rules come from 794151e (reflog-walk: always make
HEAD@{0} show indexed selectors, 2012-05-0
The "reflog selector" format changes based on a series of
heuristics, and that applies equally to both stock "log -g"
output, as well as "--format=%gd". The documentation for
"%gd" doesn't cover this. Let's mention the multiple formats
and refer the user back to the "-g" section for the complete
ru
When "log -g" shows "HEAD@{1}", "HEAD@{2}", etc, calling
that "commit@{Nth}" is not really accurate. The "HEAD" part
is really the refname. By saying "commit", a reader may
misunderstand that to mean something related to the specific
commit we are showing, not the ref whose reflog we are
traversing
On Sun, Jul 10, 2016 at 10:26:22AM -0400, Theodore Ts'o wrote:
> On Sun, Jul 10, 2016 at 02:16:45AM -0400, Jeff King wrote:
> > I wonder if a better approach would be:
> >
> > 1. In the short term, add specific designators for the fields you'd
> > want. One for HEAD@{n} that is unaffected
On Sun, Jul 10, 2016 at 06:05:31PM +0200, Duy Nguyen wrote:
> On Sun, Jul 10, 2016 at 4:26 PM, Theodore Ts'o wrote:
> > One other long-term thought. Maybe past a certain point, we should
> > just make it easy to get the data from git-log into a perl or pythons
> > script, where it becomes possibl
Junio C Hamano wrote:
> Ronald Wampler writes:
>
> > I am not sure if this the correction solution. Another option I
> > considered was to wrap the EXTLIBS += -lrt is an ifndef NO_RT and only
> > defining NO_RT for Mac OS X in config.mak.uname.
>
> That alternative would make the resulting code
On Sun, Jul 10, 2016 at 2:29 PM, Linus Torvalds
wrote:
> On Sun, Jul 10, 2016 at 2:21 PM, Linus Torvalds
> wrote:
>>
>> I'm not sure why it doesn't happen in current git master, because that
>> function is the same, and the logic around expand_tabs_in_log looks
>> similar too.
>
> Ahh. Commit 43e
On Sun, Jul 10, 2016 at 2:21 PM, Linus Torvalds
wrote:
>
> I'm not sure why it doesn't happen in current git master, because that
> function is the same, and the logic around expand_tabs_in_log looks
> similar too.
Ahh. Commit 43ec55091553 ("bisect: always call setup_revisions after
init_revision
On Sun, Jul 10, 2016 at 2:05 PM, Linus Torvalds
wrote:
>
> I'm getting "extra" being -1 in strbuf_grow(). Let me dog deeper.
"dog deeper"? My typing skills are deteriorating.
Anyway, I dug deeper, and the reason is that "tabwidth" is -1, and then
pretty.c:1669: strbuf_add_tabexpand():
From: "Junio C Hamano" : Saturday, July 02, 2016 12:01
AM
Junio C Hamano writes:
On Fri, Jul 1, 2016 at 3:08 PM, Philip Oakley
wrote:
~~~
To exclude commits reachable from a commit, a prefix '{caret}'
notation is used. E.g. '{caret}r1 r2' means commits reacha
On Sun, Jul 10, 2016 at 2:01 PM, Linus Torvalds
wrote:
>
> I'll try to figure out why git-2.9.0 fails.
I'm getting "extra" being -1 in strbuf_grow(). Let me dog deeper.
Linus
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.k
On Sun, Jul 10, 2016 at 11:41 AM, Andreas Schwab wrote:
>
> I've seen that too, but only at the end of bisection, when it tries to
> display the bad commit.
That's apparently what the kernel bug reporter sees too now.
However, I cannot reproduce the problem with the particular kernel
bisect that
Linus Torvalds writes:
> We have an odd bug report in the kernel, where somebody had trouble
> bisecting all the way due to
>
> "git is failing with "you are trying to use to much memory"(?!)"
>
> which can't be an exact error message quote, but the closest I can
> find smells like the "unsign
On Sun, Jul 10, 2016 at 10:06 AM, Shawn Pearce wrote:
> On Fri, Jul 8, 2016 at 5:31 PM, Stefan Beller wrote:
>> +
>> + /* NEEDSWORK: expose the limitations to be configurable. */
>> + int max_options = 32;
>> +
>> + /*
>> +* NEEDSWORK: expose the limitations to be config
On Fri, Jul 8, 2016 at 5:31 PM, Stefan Beller wrote:
> +
> + /* NEEDSWORK: expose the limitations to be configurable. */
> + int max_options = 32;
> +
> + /*
> +* NEEDSWORK: expose the limitations to be configurable;
> +* Once the limit can be lifted, include a wa
On Sun, Jul 10, 2016 at 4:26 PM, Theodore Ts'o wrote:
> One other long-term thought. Maybe past a certain point, we should
> just make it easy to get the data from git-log into a perl or pythons
> script, where it becomes possible to do conditionals, more flexible
> padding rules, etc. So some k
We have an odd bug report in the kernel, where somebody had trouble
bisecting all the way due to
"git is failing with "you are trying to use to much memory"(?!)"
which can't be an exact error message quote, but the closest I can
find smells like the "unsigned_add_overflows()" check in the strb
larsxschnei...@gmail.com wrote:
> (2) Joey's topic, which is the base for my patch, looks stalled for more than
> 2 weeks:
> http://thread.gmane.org/gmane.comp.version-control.git/297994/focus=298006
> I would be happy to address Junio's comments and post a reroll. However,
> I don't want to interf
On Fri, Jun 3, 2016 at 11:03 PM, Michael Haggerty wrote:
> Since the that ref-iterator [1] changes seem to have gotten a positive
> reception, let's try to keep up the momentum. I hope I'm not
> overloading the review pipeline...
>
> I think all of the groundwork is in place now to virtualize the
On Sun, Jul 10, 2016 at 4:16 PM, Johannes Schindelin
wrote:
>> No, the point is, refs subsystem needs to know which refs is per-repo,
>> which is per-worktree. So far the rules are "everything under refs,
>> except a few known exceptions, is per-repo" and "everything directly
>> under $GIT_DIR is
On Sun, Jul 10, 2016 at 02:16:45AM -0400, Jeff King wrote:
> I wonder if a better approach would be:
>
> 1. In the short term, add specific designators for the fields you'd
> want. One for HEAD@{n} that is unaffected by date, as %gd is (or
> even one for the branch-name and one for "n"
Hi Duy,
On Sun, 10 Jul 2016, Duy Nguyen wrote:
> On Sun, Jul 10, 2016 at 12:59 PM, Johannes Schindelin
> wrote:
> >> >> Now, how about special-casing *just* these legacy files in gc: HEAD,
> >> >> FETCH_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD? Any new transient refs
> >> >> should
> >> >> live in
Peter writes:
> Ah, ok, I see now. But are there any other situations where the "-f"
> switch is not needed?
When the file is unmodified and matches the index.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now f
Ah, ok, I see now. But are there any other situations where the "-f"
switch is not needed?
Peter
On 10 July 2016 at 12:57, Andreas Schwab wrote:
> Peter writes:
>
>> So if I do:
>>
>> touch abc
>> git add abc
>>
>>
>> And after that I do:
>>
>> git rm abc
> error: the following file has changes
From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter process for every
single file that is affected by the filter. If you have *a lot* of files to
filter then the startup time of the external filter process becomes a problem
as discussed here:
http://thread.gmane.org/gmane
On Sun, Jul 10, 2016 at 12:59 PM, Johannes Schindelin
wrote:
>> >> Now, how about special-casing *just* these legacy files in gc: HEAD,
>> >> FETCH_HEAD, MERGE_HEAD and CHERRY_PICK_HEAD? Any new transient refs should
>> >> live in the refs/ namespace, which is already handled.
>> >
>> > That seems
Hi Duy,
On Sat, 9 Jul 2016, Duy Nguyen wrote:
> On Sat, Jul 9, 2016 at 4:09 PM, Josh Triplett wrote:
> > On Sat, Jul 09, 2016 at 09:35:24AM +0200, Johannes Schindelin wrote:
> >> On Fri, 8 Jul 2016, Junio C Hamano wrote:
> >> > Josh Triplett writes:
> >> >
> >> > > That sounds reasonable. And
Peter writes:
> So if I do:
>
> touch abc
> git add abc
>
>
> And after that I do:
>
> git rm abc
error: the following file has changes staged in the index:
abc
(use --cached to keep the file, or -f to force removal)
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 5
Hi Peff,
On Sat, 9 Jul 2016, Johannes Schindelin wrote:
> On Fri, 8 Jul 2016, Jeff King wrote:
>
> > I think we can clean that up, though. I'll hopefully have a series in a
> > few minutes.
>
> You caught me at busy times... I'll review it tomorrow, promise!
And so I did. Looks good to me, I w
For blobs, we want to make sure the on-disk data is not corrupted
(i.e. can be inflated and produce the expected SHA-1). Blob content is
opaque, there's nothing else inside to check for.
For really large blobs, we may want to avoid unpacking the entire blob
in memory, just to check whether it prod
A typical diff will not show what's going on and you need to see full
functions. The core code is like this, at the end of of write_one()
e->idx.offset = *offset;
size = write_object(f, e, *offset);
if (!size) {
e->idx.offset = recursing;
ret
On Tue, Jul 5, 2016 at 7:05 PM, Nguyễn Thái Ngọc Duy wrote:
> Most of the rest seems harmless, except for the local variable "size"
> in builtin/pack-objects.c:write_one(). I might send 6/5 for that one.
This truncated "size" produces incorrect .idx file and makes everybody
else fail to read the
--
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://vger.kernel.org/majordomo-info.html
So if I do:
touch abc
git add abc
And after that I do:
git rm abc
Can you agree that there is an asymmetry of two commands vs. one? Git
add only touches the files in .git/ and git rm ALSO affects the
working tree...
Is "git rm" or "git rm --cache" used more often in practice?
Peter
On 7 J
At least for me, this improves the readability of xread and
xwrite; hopefully allowing missing "continue" statements to
be spotted more easily.
Signed-off-by: Eric Wong
Signed-off-by: Jeff King
---
Jeff King wrote:
> On Sun, Jul 10, 2016 at 03:47:36AM +, Eric Wong wrote:
> > Yes, I'm
Hi,
On Sun, 19 Jun 2016, Junio C Hamano wrote:
> Lars Schneider writes:
>
> > Hi Junio,
> >
> > is there any chance to pick this up? It would enable the web server
> > tests on Travis CI.
>
> There always are chances unless a patch was rejected with some
> reason, like "no, I do not like it" ;
Hi Ted,
On Sat, 9 Jul 2016, Theodore Ts'o wrote:
> + # is arugably better, but it is a GNU extension. Since this isn't
s/arugably/arguably/
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
41 matches
Mail list logo
