[PATCH 5/5] date: add "unix" format

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

[PATCH 4/5] date: document and test "raw-local" mode

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

[PATCH 2/5] doc/rev-list-options: explain "-g" output formats

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,

[PATCH 3/5] doc/pretty-formats: describe index/time formats for %gd

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

[PATCH 1/5] doc/rev-list-options: clarify "commit@{Nth}" for "-g" option

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

Re: [PATCH] pretty: add format specifiers: %gr, %gt, %gI, gi

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

Re: [PATCH] pretty: add format specifiers: %gr, %gt, %gI, gi

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

[PATCH] config.mak.uname: define NEEDS_LIBRT under Linux, for now

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

Re: Odd git overrflow bug?

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

Re: Odd git overrflow bug?

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

Re: Odd git overrflow bug?

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:

Re: [PATCH v2 4/4] doc: clarify that `^r1` will exclude `r1` itself

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}'

Re: Odd git overrflow bug?

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

Re: Odd git overrflow bug?

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

Re: Odd git overrflow bug?

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

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

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; >> + >> + /* >> +*

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

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

Re: [PATCH] pretty: add format specifiers: %gr, %gt, %gI, gi

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,

Odd git overrflow bug?

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

Re: [RFC] Long running Git clean/smudge filter

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

Re: [PATCH 00/38] Virtualization of the refs API

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

Re: gc and repack ignore .git/*HEAD when checking reachability

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

Re: [PATCH] pretty: add format specifiers: %gr, %gt, %gI, gi

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

Re: gc and repack ignore .git/*HEAD when checking reachability

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 >

Re: Fwd: git rm

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

Re: Fwd: git rm

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

[RFC] Long running Git clean/smudge filter

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:

Re: gc and repack ignore .git/*HEAD when checking reachability

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

Re: gc and repack ignore .git/*HEAD when checking reachability

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

Re: Fwd: git rm

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

Re: [PATCH] am: ignore return value of write_file()

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

[PATCH 7/5] fsck: use streaming interface for large blobs in pack

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

[PATCH 6/5] pack-objects: do not truncate result in-pack object size on 32-bit systems

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;

Re: [PATCH 0/5] Number truncation with 4+ GB files on 32-bit systems

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

Re: Did you get my last request?

-- 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

Re: Fwd: git rm

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

[PATCH 3/2] hoist out handle_nonblock function for xread and xwrite

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

Re: [PATCH v1] travis-ci: enable web server tests t55xx on Linux

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,

Re: [PATCH] guilt: fix portability problem with using find -perm +111

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

Re: [PATCH] pretty: add format specifiers: %gr, %gt, %gI, gi

On Sun, Jul 10, 2016 at 01:54:02AM -0400, Theodore Ts'o wrote: > Add new format specifiers which allow the printing of reflog > timestamp. This allows us to know when operations which change HEAD > take place (e.g., guilt pop -a, which does the equivalent of a "git > reset --hard commit"), since