Re: Reset by checkout?

2014-05-31 Thread Andreas Schwab
Atsushi Nakagawa at...@chejz.com writes: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful.

Re: [ANNOUNCE] Git v2.0.0

2014-05-31 Thread David Kastrup
Felipe Contreras felipe.contre...@gmail.com writes: Jeff King wrote: On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote: This is the last mail I sent to you, because you ignore them anyway, and remove them from the mailing list. [...] [2], a mail you conveniently removed

Re: [PATCH v2 2/2] connect.c: replace signal() with sigaction()

2014-05-31 Thread Chris Packham
On 31/05/14 08:58, Jeremiah Mahler wrote: From signal(2) man page: The behavior of signal() varies across UNIX versions, and has also var‐ ied historically across different versions of Linux. Avoid its use: use sigaction(2) instead. Replaced signal() with sigaction() in

Re: [PATCH] check_refname_component: Optimize

2014-05-31 Thread Michael Haggerty
On 05/30/2014 07:29 PM, Jeff King wrote: On Fri, May 30, 2014 at 11:47:33AM +0200, Michael Haggerty wrote: [...] If we want to be robust to future changes to refname rules, we could add a header flag like # pack-refs with: peeled fully-peeled check-level=1.0 [...] Yeah, I thought about

RE: Reset by checkout?

2014-05-31 Thread Felipe Contreras
Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not careful. Or, I could use

Re: [PATCH] check_refname_component: Optimize

2014-05-31 Thread Duy Nguyen
On Fri, May 30, 2014 at 7:07 AM, Jeff King p...@peff.net wrote: But then we're just trusting that the trust me flag on disk is correct. Why not just trust that packed-refs is correct in the first place? I missed one thing in the first reply: because packed-refs is a plain text file, the user

Re: Reset by checkout?

2014-05-31 Thread Kevin Bracey
On 31/05/2014 08:46, Atsushi Nakagawa wrote: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative.q I'm 100% in agreement. Reset current branch to X is an extremely common operation, and I use this

Re: [PATCH v2 2/2] connect.c: replace signal() with sigaction()

2014-05-31 Thread Jeremiah Mahler
Chris, On Sat, May 31, 2014 at 10:39:39PM +1200, Chris Packham wrote: On 31/05/14 08:58, Jeremiah Mahler wrote: From signal(2) man page: ... - signal(SIGCHLD, SIG_DFL); + memset(sa, 0, sizeof(sa)); + sa.sa_handler = SIG_DFL; + sigaction(SIGCHLD, sa, 0); I think this got

Re: git-multimail: migration: Config is not iterable

2014-05-31 Thread Michael Haggerty
On 05/29/2014 04:22 PM, Azat Khuzhin wrote: Using the latest version of git-multimail there is an issue with migration: $ ~azat/git-multimail/git-multimail/migrate-mailhook-config --overwrite Traceback (most recent call last): File

[PATCH] Improve function dir.c:trim_trailing_spaces()

2014-05-31 Thread Pasha Bolokhov
Discard the unnecessary 'nr_spaces' variable, remove 'strlen()' and improve the 'if' structure. Switch to pointers instead of integers Slightly more rare occurrences of 'text \' with a backslash in between spaces are handled correctly. Namely, the code in 8ba87adad6 does not reset

Re: git-multimail: migration: Config is not iterable

2014-05-31 Thread Azat Khuzhin
On Sat, May 31, 2014 at 04:59:45PM +0200, Michael Haggerty wrote: On 05/29/2014 04:22 PM, Azat Khuzhin wrote: Using the latest version of git-multimail there is an issue with migration: $ ~azat/git-multimail/git-multimail/migrate-mailhook-config --overwrite Traceback (most recent call

[PATCH] Makefile: don't hardcode HEAD in dist target

2014-05-31 Thread Dennis Kaarsemaker
Instead of calling git-archive HEAD^{tree}, use $(GIT_VERSION)^{tree}. This makes sure the archive name and contents are consistent, if HEAD has moved, but GIT-VERSION-FILE hasn't been regenerated yet. Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net --- I have a somewhat odd setup in

RE: Reset by checkout?

2014-05-31 Thread Felipe Contreras
Felipe Contreras wrote: Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk blowing away dirty files if I'm not

[PATCH nd/split-index] fixup! read-cache: new API write_locked_index instead of write_index/write_cache

2014-05-31 Thread Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- I intended it resend the series after the comments I received, but it looks like Junio has picked up all comments except this one, so here's the fix. sequencer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: Reset by checkout?

2014-05-31 Thread Atsushi Nakagawa
Andreas Schwab sch...@linux-m68k.org wrote: Atsushi Nakagawa at...@chejz.com writes: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard origin/master' and risk

Re: Reset by checkout?

2014-05-31 Thread Atsushi Nakagawa
Kevin Bracey ke...@bracey.fi wrote: On 31/05/2014 08:46, Atsushi Nakagawa wrote: `git checkout -B current-branch-name tree-ish` This is such an useful notion that I can fathom why there isn't a better, first-tier, alternative.q ... I guess in theory using checkout allows fancier

Re: Reset by checkout?

2014-05-31 Thread Atsushi Nakagawa
Felipe Contreras felipe.contre...@gmail.com wrote: Felipe Contreras wrote: Atsushi Nakagawa wrote: Ok, the typical use case is: I'm on 'master' and I make a few test commits. Afterwards, I want to discard the commits and move back to 'origin/master'. I could type 'reset --hard

[PATCH v4 1/2] refs.c: optimize check_refname_component()

2014-05-31 Thread David Turner
In a repository with many refs, check_refname_component can be a major contributor to the runtime of some git commands. One such command is git rev-parse HEAD Timings for one particular repo, with about 60k refs, almost all packed, are: Old: 35 ms New: 29 ms Many other commands which read refs

[PATCH v4 2/2] refs.c: SSE4.2 optimizations for check_refname_component

2014-05-31 Thread David Turner
Optimize check_refname_component using SSE4.2, where available. git rev-parse HEAD is a good test-case for this, since it does almost nothing except parse refs. For one particular repo with about 60k refs, almost all packed, the timings are: Look up table: 29 ms SSE4.2:25 ms This is