Re: reftable [v4]: new ref storage format

Shawn Pearce writes: > On Wed, Aug 2, 2017 at 6:50 PM, Junio C Hamano wrote: > ... >>Would it benefit us if we define the sort order of bytes slightly >>different from the ASCII order, so that a slash '/' sorts between >>NUL '\000' and SOH

Re: reftable [v4]: new ref storage format

On Wed, Aug 2, 2017 at 6:50 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I like the general idea, what the file format can represent and how >> it does so, but I am a bit uneasy about how well this "stacked" part >> would work for desktop clients.

Re: reftable [v4]: new ref storage format

Junio C Hamano writes: > I like the general idea, what the file format can represent and how > it does so, but I am a bit uneasy about how well this "stacked" part > would work for desktop clients. Two more random things before I forget. * I understand that you would want

Re: [PATCH 4/4] revision: do not fallback to default when rev_input_given is set

On Wed, Aug 2, 2017 at 3:44 PM, Junio C Hamano wrote: > Jeff King writes: > >> If revs->def is set (as it is in "git log") and there are no >> pending objects after parsing the user's input, then we show >> whatever is in "def". But if the user _did_ ask for

Re: [PATCH 2/4] revision: add rev_input_given flag

On Wed, Aug 02, 2017 at 03:41:52PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > Normally a caller that invokes setup_revisions() has to > > check rev.pending to see if anything was actually queued for > > the traversal. But they can't tell the difference between > > two

Re: [PATCH 4/4] revision: do not fallback to default when rev_input_given is set

Jeff King writes: > If revs->def is set (as it is in "git log") and there are no > pending objects after parsing the user's input, then we show > whatever is in "def". But if the user _did_ ask for some > input that just happened to be empty (e.g., "--glob" that > does not match

Re: [PATCH 2/4] revision: add rev_input_given flag

Jeff King writes: > Normally a caller that invokes setup_revisions() has to > check rev.pending to see if anything was actually queued for > the traversal. But they can't tell the difference between > two cases: > > 1. The user gave us no tip from which to start a >

Re: [PATCH 0/4] handling empty inputs in the revision machinery

Jeff King writes: > I noticed that: > > git log --tags=does-not-exist > > will show all of HEAD, which is rather confusing. This fixes it, and > also hits several other cases that were marked as expect_failure for > rev-list. There is one case it doesn't handle: --stdin. It's

[PATCH DONOTAPPLY 5/4] revision: let --stdin set rev_input_given

On Wed, Aug 02, 2017 at 06:24:25PM -0400, Jeff King wrote: > I noticed that: > > git log --tags=does-not-exist > > will show all of HEAD, which is rather confusing. This fixes it, and > also hits several other cases that were marked as expect_failure for > rev-list. There is one case it

[PATCH 4/4] revision: do not fallback to default when rev_input_given is set

If revs->def is set (as it is in "git log") and there are no pending objects after parsing the user's input, then we show whatever is in "def". But if the user _did_ ask for some input that just happened to be empty (e.g., "--glob" that does not match anything), showing the default revision is

Re: [PATCH 6/6] cherry-pick/revert: reject --rerere-autoupdate when continuing

Junio C Hamano writes: > Phillip Wood writes: > >> From: Phillip Wood >> >> cherry-pick and revert should not accept --[no-]rerere-autoupdate once >> they have started. > > Hmph, why shouldn't they? In other words,

[PATCH 3/4] rev-list: don't show usage when we see empty ref patterns

If the user gives us no starting point for a traversal, we want to complain with our normal usage message. But if they tried to do so with "--all" or "--glob", but that happened not to match any refs, the usage message isn't helpful. We should just give them the empty output they asked for

[PATCH 2/4] revision: add rev_input_given flag

Normally a caller that invokes setup_revisions() has to check rev.pending to see if anything was actually queued for the traversal. But they can't tell the difference between two cases: 1. The user gave us no tip from which to start a traversal. 2. The user tried to give us tips via

[PATCH 1/4] t6018: flesh out empty input/output rev-list tests

In 751a2ac6e (rev-list --exclude: tests, 2013-11-01), we added a few tests for handling "empty" inputs with rev-list (i.e., where the user gave us some pattern but it turned out not to queue any objects for traversal), all of which were marked as failing. In preparation for working on this area

[PATCH 0/4] handling empty inputs in the revision machinery

I noticed that: git log --tags=does-not-exist will show all of HEAD, which is rather confusing. This fixes it, and also hits several other cases that were marked as expect_failure for rev-list. There is one case it doesn't handle: --stdin. It's not clear to me what the right behavior is there.

Re: Git log --tags isn't working as expected

On Wed, Aug 02, 2017 at 01:28:38PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > By the way, I noticed something funny that I forgot to mention: > > > > git log --tags=does-not-exist > > > > shows HEAD, because the logic to kick in the default only asks "were we > >

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

Junio C Hamano wrote: > Jonathan Nieder writes: >> Can you spell this out more? To be clear, are you speaking as a >> reviewer or as the project maintainer? In other words, if other >> reviewers are able to settle on a design that involves a relaxed >> guarantee for fsck in

Re: [PATCH 6/6] cherry-pick/revert: reject --rerere-autoupdate when continuing

Phillip Wood writes: > From: Phillip Wood > > cherry-pick and revert should not accept --[no-]rerere-autoupdate once > they have started. Hmph, why shouldn't they? In other words, shouldn't the usual "try to carry forward from the

Re: git svn fetch --localtime produces wrong commit times

Urs Thuermann writes: > I could find the bug grepping through /usr/lib/git-core/git-svn, maybe > it's in GIT::SVN::Fetcher or some other GIT::SVN module. Oops, that should be "could *not* find", of course. urs

Re: [PATCH v1 1/1] correct apply for files commited with CRLF

tbo...@web.de writes: > From: Torsten Bögershausen > > git apply does not find the source lines when files have CRLF in the index > and core.autocrlf is true: > These files should not get the CRLF converted to LF. Because cmd_apply() > does not load the index, this does not work,

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

Torsten Bögershausen writes: > My very first investigation shows that a patch like this could fix > the problem: > > diff --git a/apply.c b/apply.c > index f2d599141d..66b8387360 100644 > --- a/apply.c > +++ b/apply.c > @@ -2278,6 +2278,8 @@ static int read_old_data(struct stat

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

Jonathan Nieder writes: > Junio C Hamano wrote: >> Jonathan Tan writes: > >>> One possibility to conceptually have the same thing without the overhead >>> of the list is to put the obtained-from-elsewhere objects into its own >>> alternate object

[PATCH v1 1/1] correct apply for files commited with CRLF

From: Torsten Bögershausen git apply does not find the source lines when files have CRLF in the index and core.autocrlf is true: These files should not get the CRLF converted to LF. Because cmd_apply() does not load the index, this does not work, CRLF are converted into LF and

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

On Wed, Aug 2, 2017 at 11:11 AM, Jeremy Morton wrote: > Did this ever get anywhere? If not why not? It would be very useful to me > to be able to clone recursively by default, especially considering you can't > use 'alias' to override the existing 'clone' command. > Note

Re: Git log --tags isn't working as expected

Jeff King writes: > By the way, I noticed something funny that I forgot to mention: > > git log --tags=does-not-exist > > shows HEAD, because the logic to kick in the default only asks "were we > given any refs to start the traversal?". I think it probably should > consider a

Re: reftable [v4]: new ref storage format

On Wed, Aug 02, 2017 at 12:50:39PM -0700, Junio C Hamano wrote: > With the traditional "packed-refs plus loose" layout, no matter how > many times a handful of selected busy refs are updated during the > day, you'd need to open at most two files to find out the current > value of a single ref

Re: reftable [v4]: new ref storage format

> ### Ref block format > > A ref block is written as: > > 'r' > uint24( block_len ) > ref_record+ > uint32( restart_offset )+ > uint16( restart_count ) > padding? > So I learned that your current writer is a two block pass, i.e. the block is first written into memory and

Re: reftable [v4]: new ref storage format

Shawn Pearce writes: > ### Layout > > The `$GIT_DIR/refs` path is a file when reftable is configured, not a > directory. This prevents loose references from being stored. > > A collection of reftable files are stored in the `$GIT_DIR/reftable/` > directory: > >

[PATCH v4 10/10] grep: recurse in-process using 'struct repository'

Convert grep to use 'struct repository' which enables recursing into submodules to be handled in-process. Signed-off-by: Brandon Williams --- Documentation/git-grep.txt | 7 - builtin/grep.c | 396 ++--- cache.h

[PATCH v4 05/10] submodule: remove submodule.fetchjobs from submodule-config parsing

The '.gitmodules' file should only contain information pertinent to configuring individual submodules (name to path mapping, URL where to obtain the submodule, etc.) while other configuration like the number of jobs to use when fetching submodules should be a part of the repository's config.

[PATCH v4 09/10] submodule: merge repo_read_gitmodules and gitmodules_config

Since 69aba5329 (submodule: add repo_read_gitmodules) there have been two ways to load a repository's .gitmodules file: 'repo_read_gitmodules()' is used if you have a repository object you are working with or 'gitmodules_config()' if you are implicitly working with 'the_repository'. Merge the

[PATCH v4 06/10] submodule: remove fetch.recursesubmodules from submodule-config parsing

Remove the 'fetch.recursesubmodules' configuration option from the general submodule-config parsing and instead rely on using 'config_from_gitmodules()' in order to maintain backwards compatibility with this config being placed in the '.gitmodules' file. Signed-off-by: Brandon Williams

[PATCH v4 03/10] cache.h: add GITMODULES_FILE macro

Add a macro to be used when specifying the '.gitmodules' file and convert any existing hard coded '.gitmodules' file strings to use the new macro. Signed-off-by: Brandon Williams Signed-off-by: Stefan Beller --- cache.h| 1 + submodule.c| 20

[PATCH v4 08/10] submodule: check for unmerged .gitmodules outside of config parsing

Add 'is_gitmodules_unmerged()' function which can be used to determine in the '.gitmodules' file is unmerged based on the passed in index instead of relying on a global variable which is set during the submodule-config parsing. Signed-off-by: Brandon Williams --- submodule.c

[PATCH v4 01/10] repo_read_index: don't discard the index

Have 'repo_read_index()' behave more like the other read_index family of functions and don't discard the index if it has already been populated and instead rely on the quick return of read_index_from which has: /* istate->initialized covers both .git/index and .git/sharedindex.xxx */ if

[PATCH v4 07/10] submodule: check for unstaged .gitmodules outside of config parsing

Teach 'is_staging_gitmodules_ok()' to be able to determine in the '.gitmodules' file has unstaged changes based on the passed in index instead of relying on a global variable which is set during the submodule-config parsing. Signed-off-by: Brandon Williams --- builtin/mv.c |

[PATCH v4 00/10] Convert grep to recurse in-process

Changes in v4: * small typo fix in commit message. * convert all occurrences of '.gitmodules' to use the new macro. Brandon Williams (10): repo_read_index: don't discard the index repository: have the_repository use the_index cache.h: add GITMODULES_FILE macro config: add

[PATCH v4 04/10] config: add config_from_gitmodules

Add 'config_from_gitmodules()' function which can be used by 'fetch' and 'update_clone' in order to maintain backwards compatibility with configuration being stored in .gitmodules' since a future patch will remove reading these values in the submodule-config. This function should not be used

[PATCH v4 02/10] repository: have the_repository use the_index

Have the index state which is stored in 'the_repository' be a pointer to the in-core index 'the_index'. This makes it easier to begin transitioning more parts of the code base to operate on a 'struct repository'. Signed-off-by: Brandon Williams --- repository.c | 4 +++- 1

[PATCH v3 7/7] git.c: ignore pager.* when launching builtin as dashed external

When running, e.g., `git -c alias.bar=foo bar`, we expand the alias and execute `git-foo` as a dashed external. This is true even if git foo is a builtin. That is on purpose, and is motivated in a comment which was added in commit 441981bc ("git: simplify environment save/restore logic",

[PATCH v3 6/7] tag: change default of `pager.tag` to "on"

The previous patch taught `git tag` to only respect `pager.tag` in list-mode. That patch left the default value of `pager.tag` at "off". After that patch, it makes sense to let the default value be "on" instead, since it will help with listing many tags, but will not hurt users of `git tag -a` as

[PATCH v3 5/7] tag: respect `pager.tag` in list-mode only

Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. Someone who makes use of both `git tag -a` and `git tag -l` will probably not set `pager.tag`, so that `git tag -a` will actually work, at the cost of not

[PATCH v3 4/7] t7006: add tests for how git tag paginates

Using, e.g., `git -c pager.tag tag -a new-tag` results in errors such as "Vim: Warning: Output is not to a terminal" and a garbled terminal. Someone who makes use of both `git tag -a` and `git tag -l` will probably not set `pager.tag`, so that `git tag -a` will actually work, at the cost of not

[PATCH v3 3/7] git.c: provide setup_auto_pager()

The previous patch introduced a way for builtins to declare that they will take responsibility for handling the `pager.foo`-config item. (See the commit message of that patch for why that could be useful.) Provide setup_auto_pager(), which builtins can call in order to handle `pager.`, including

[PATCH v3 2/7] git.c: let builtins opt for handling `pager.foo` themselves

Before launching a builtin git foo and unless mechanisms with precedence are in use, we check for and handle the `pager.foo` config. This is done without considering exactly how git foo is being used, and indeed, git.c cannot (and should not) know what the arguments to git foo are supposed to

[PATCH v3 1/7] builtin.h: take over documentation from api-builtin.txt

Delete Documentation/technical/api-builtin.txt and move its content into builtin.h. Format it as a comment. Remove a '+' which was needed when the information was formatted for AsciiDoc. Similarly, change "::" to ":". Document SUPPORT_SUPER_PREFIX, thereby bringing the documentation up to date

[PATCH v3 0/7] tag: only respect `pager.tag` in list-mode

This is the third version of my attempt to make `pager tag` useful (v1 at [1], v2 at [2]). Thanks to Junio and Peff for comments on v2. I've squashed patches 01-03/10 and 07-08/10, respectively. The interdiff is below. I managed to clean up some tests thanks to a drive-by comment by Peff which

[PATCH] Add 'raw' blob_plain link in history overview

We often work with very large plain text files in our repositories and found it friendlier to the users if we can click directly to the raw version of such files. This patch adds a 'raw' blob_plain link in history overview. Signed-off-by: Job Snijders --- gitweb/gitweb.perl

Re: [RFC PATCH] clone: add clone.recursesubmodules config option

Did this ever get anywhere? If not why not? It would be very useful to me to be able to clone recursively by default, especially considering you can't use 'alias' to override the existing 'clone' command. -- Best regards, Jeremy Morton (Jez) On 06/06/2014 06:26, Heiko Voigt wrote: On Thu,

Re: [PATCH v3 07/10] submodule: check for unstaged .gitmodules outside of config parsing

On 08/02, Brandon Williams wrote: > On 07/31, Stefan Beller wrote: > > > > So this is where the check "pos < active_nr" is coming from, > > introduced in 5fee995244 (submodule.c: add .gitmodules staging > > helper functions, 2013-07-30) as well as d4e98b581b (Submodules: > > Don't parse

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

On Wed, Aug 2, 2017 at 9:28 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I think the exchange Stefan cited was an example that we want to >> have more of. The contributor is indicating that, even though the >> patch could be a drive-by patch by

Re: [PATCH] convert any hard coded .gitmodules file string to the MACRO

On 08/01, Junio C Hamano wrote: > Stefan Beller writes: > > >>> @@ -233,18 +233,18 @@ void gitmodules_config(void) > >>> strbuf_addstr(_path, "/.gitmodules"); > >> > >> > >> Did you mean to also change "/.gitmodules" ?? > > > > Goog point. We should pick

Re: [PATCH v3 07/10] submodule: check for unstaged .gitmodules outside of config parsing

On 07/31, Stefan Beller wrote: > On Tue, Jul 18, 2017 at 12:05 PM, Brandon Williams wrote: > > Teach 'is_staging_gitmodules_ok()' to be able to determine in the > > '.gitmodules' file has unstaged changes based on the passed in index > > instead of relying on a global varible

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

Hi, Junio C Hamano wrote: > Jonathan Tan writes: >> One possibility to conceptually have the same thing without the overhead >> of the list is to put the obtained-from-elsewhere objects into its own >> alternate object store, so that we can distinguish the two. > > Now

Re: Git log --tags isn't working as expected

On Wed, Aug 02, 2017 at 09:23:36AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > 3. Use --simplify-by-decoration to show a particular range of commits, > > but limit to ones that actually have a ref pointing at them. Like: > > > >git log ..HEAD

Re: [RFC] The correct and consistent alternative to quote a command ?

On Wed, Aug 2, 2017 at 5:22 AM, Kaartic Sivaraam wrote: > On Tue, 2017-08-01 at 10:38 -0700, Stefan Beller wrote: >> On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote: >> > I assume you mean the consistency in quoting i.e., you're expecting the >> > patch to

Re: reftable [v4]: new ref storage format

On Wed, Aug 02, 2017 at 08:17:29AM -0700, Shawn Pearce wrote: > > Just peeking at torvalds/linux, we have some objects with ~35K refs > > pointing to them (e.g., the v2.6.11 tag). > > Oy. I'll bet that every occurrence winds up in its own block due to > the layout of the namespace, and so the

Re: [PATCH] convert any hard coded .gitmodules file string to the MACRO

On 08/01, Junio C Hamano wrote: > Stefan Beller writes: > > >>> @@ -233,18 +233,18 @@ void gitmodules_config(void) > >>> strbuf_addstr(_path, "/.gitmodules"); > >> > >> > >> Did you mean to also change "/.gitmodules" ?? > > > > Goog point. We should pick

Re: reftable [v4]: new ref storage format

On Wed, Aug 02, 2017 at 08:20:44AM -0400, Dave Borowitz wrote: > >> OTOH a mythical protocol v2 might reduce the need to scan the > >> references for advertisement, so maybe this optimization will be more > >> helpful in the future? > > I haven't been following the status of the proposal, but I

Re: reftable [v4]: new ref storage format

Shawn Pearce writes: > On Wed, Aug 2, 2017 at 2:28 AM, Jeff King wrote: >> On Tue, Aug 01, 2017 at 07:38:37PM -0700, Shawn Pearce wrote: >> >>> > OBJS blocks can also be >>> > unbounded in size if very many references point at the same object, >>> > thought

Re: git send-email -v n fails

Olaf Hering writes: > I think send-email should understand all options of format-patch. I actually think it was a mistake to allow send-email drive format-patch ;-). > At least for '-v n' this fails, one has to type '--reroll-count n' as a > workaround with git version 2.13.3:

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

Junio C Hamano writes: > I think the exchange Stefan cited was an example that we want to > have more of. The contributor is indicating that, even though the > patch could be a drive-by patch by one-timer from whom we will never > hear again, it is not--the contributor is

Re: Git log --tags isn't working as expected

Jeff King writes: > 3. Use --simplify-by-decoration to show a particular range of commits, > but limit to ones that actually have a ref pointing at them. Like: > >git log ..HEAD --simplify-by-decoration Nit: dashed options come first and then revs and then

Re: [PATCH v2 0/5] Fsck for lazy objects, and (now) actual invocation of loader

Jonathan Tan writes: > One possibility to conceptually have the same thing without the overhead > of the list is to put the obtained-from-elsewhere objects into its own > alternate object store, so that we can distinguish the two. Now you are talking. Either a

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

Kaartic Sivaraam writes: > On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote: >> Actually I am slightly negative on this one, because of >> occurrences like [1]. >> >> Our SubmittingPatches is already considered *too long* for most people >> who just want to

git bisect "commits left" miscount

Hi, When bisecting given a set of paths, git counts the number of remaining commits improperly. Here's example output (based in the git.git repository): % git bisect start -- sha1_file.c % git bisect good v2.10.0 % git bisect bad v2.10.3 Bisecting: 1 revision left to test after

Re: core.autocrlf=true causes `git apply` to fail on patch generated with `git diff-index HEAD --patch`

On 08/01/2017 10:58 PM, Anthony Sottile wrote: Here's where I'm hitting the problem described: https://github.com/pre-commit/pre-commit/issues/570 Note that `git -c core.autocrlf=false` apply patch fixes this situation, but breaks others. [] I wasn't thinking of that - and thanks for the

Re: [RFC] The correct and consistent alternative to quote a command ?

Kaartic Sivaraam writes: > On Tue, 2017-08-01 at 10:38 -0700, Stefan Beller wrote: >> On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote: >> > I assume you mean the consistency in quoting i.e., you're expecting the >> > patch to use (") instead of (') for

Re: reftable [v4]: new ref storage format

On Wed, Aug 2, 2017 at 2:28 AM, Jeff King wrote: > On Tue, Aug 01, 2017 at 07:38:37PM -0700, Shawn Pearce wrote: > >> > OBJS blocks can also be >> > unbounded in size if very many references point at the same object, >> > thought that is perhaps only a theoretical problem. >> >>

git svn fetch --localtime produces wrong commit times

In converting a SVN repository to git, the commit timestamp is generated incorrectly. I use "git svn fetch --localtime" and the offset from UTC is always set to +0200 (probably because that is the current local offset here, i.e. Europe/Berlin) even for times when it should be +0100. For example,

git send-email -v n fails

I think send-email should understand all options of format-patch. At least for '-v n' this fails, one has to type '--reroll-count n' as a workaround with git version 2.13.3: + git send-email -v 2 --annotate --confirm=always --to-cmd=scripts/get_maintainer.pl 'HEAD^' fatal: ambiguous argument

Re: [PATCH 2/2] doc: add another way to identify if a patch has been merged

On Tue, 2017-08-01 at 10:46 -0700, Stefan Beller wrote: > Actually I am slightly negative on this one, because of > occurrences like [1]. > > Our SubmittingPatches is already considered *too long* for most people > who just want to drop a drive-by patch. > > Adding more knowledge (which btw is

Re: [RFC] The correct and consistent alternative to quote a command ?

On Tue, 2017-08-01 at 10:38 -0700, Stefan Beller wrote: > On Tue, Aug 1, 2017 at 8:59 AM, Kaartic Sivaraam wrote: > > I assume you mean the consistency in quoting i.e., you're expecting the > > patch to use (") instead of (') for quoting. Correct me, if I'm wrong. > > Actually I did not imply any

Re: reftable [v4]: new ref storage format

On Tue, Aug 1, 2017 at 10:38 PM, Shawn Pearce wrote: >> Peff and I discussed off-list whether the lookup-by-SHA-1 feature is >> so important in the first place. Currently, all references must be >> scanned for the advertisement anyway, > > Not really. You can hide refs and

[PATCH 1/6] am: remember --rerere-autoupdate setting

From: Phillip Wood Save the rerere-autoupdate setting so that it is remembered after stopping for the user to resolve conflicts. Signed-off-by: Phillip Wood --- There are no new tests, but this code is exercised by the new rebase tests

[PATCH 3/6] rebase -i: honor --rerere-autoupdate

From: Phillip Wood Interactive rebase was ignoring '--rerere-autoupdate'. Fix this by reading it appropriate file when restoring the sequencer state for an interactive rebase and passing '--rerere-autoupdate' to merge and cherry-pick when rebasing with

[PATCH 6/6] cherry-pick/revert: reject --rerere-autoupdate when continuing

From: Phillip Wood cherry-pick and revert should not accept --[no-]rerere-autoupdate once they have started. Signed-off-by: Phillip Wood --- This will break scripts that pass --[no-]rerere-autoupdate to 'git cherry-pick --continue'. I

[PATCH 4/6] t3504: use test_commit

From: Phillip Wood Using test_commit is simpler than chaining echo && git add && test_tick && commit. Also having tags makes it clearer which commit is being selecting by reset. Signed-off-by: Phillip Wood ---

[PATCH 5/6] cherry-pick/revert: remember --rerere-autoupdate

From: Phillip Wood When continuing after conflicts, cherry-pick forgot if the user had specified '--rerere-autoupdate'. Redo the cherry-pick rerere tests to check --rerere-autoupdate works as expected. Signed-off-by: Phillip Wood ---

[PATCH 0/6] am/cherry-pick/rebase/revert --rerere-autoupdate fixes

From: Phillip Wood With the exception of 'rebase -m' when continuing after stopping for the user to resolve conflicts, they all forget the setting of --rerere-autoupdate. Phillip Wood (6): am: remember --rerere-autoupdate setting rebase: honor --rerere-autoupdate

[PATCH 2/6] rebase: honor --rerere-autoupdate

From: Phillip Wood Rebase accepts '--rerere-autoupdate' as an option but only honors it if '-m' is also given. Fix it for a non-interactive rebase by passing on the option to 'git am' and 'git cherry-pick'. Rework the tests so that they can be used for each rebase

Re: reftable [v4]: new ref storage format

On Tue, Aug 01, 2017 at 07:38:37PM -0700, Shawn Pearce wrote: > > OBJS blocks can also be > > unbounded in size if very many references point at the same object, > > thought that is perhaps only a theoretical problem. > > Gah, I missed that in reftable. The block id pointer list could cause > a

Re: Git log --tags isn't working as expected

On Wed, Aug 02, 2017 at 08:41:41AM +0100, Richard Jones wrote: > I’m trying to locate a commit which takes place after another one, > matches a certain tag, and is by a specific user. I have the following > command: > > git log ..HEAD --decorate --author=“" --tags=“project-name” > > The tag

Git log --tags isn't working as expected

Hi, I’m trying to locate a commit which takes place after another one, matches a certain tag, and is by a specific user. I have the following command: git log ..HEAD --decorate --author=“" --tags=“project-name” The tag follows the format: project-name-version How ever this doesn’t seem to