[PATCH v2 0/2] branch --list: print useful info whilst interactive rebasing a detached HEAD

Ok, I seem to have forgotten the cover letter. So, here's one. The changes from v1 are as follows: * Changes to the commit message of 1/2 to fix some errors * Code changes to 1/2 to address the comments from v1 * Patch 2/2 is new. It's adds tests for the issue that 1/2 tries to fix. It's

[PATCH v2 1/2] branch --list: print useful info whilst interactive rebasing a detached HEAD

When rebasing interactively (rebase -i), "git branch --list" prints a line indicating the current branch being rebased. This works well when the interactive rebase is initiated when a local branch is checked out. This doesn't play well when the rebase is initiated on a detached HEAD. When "git

[PATCH v2 2/2] t3200: verify "branch --list" sanity when rebasing from detached HEAD

From: Eric Sunshine "git branch --list" shows an in-progress rebase as: * (no branch, rebasing ) master ... However, if the rebase is started from a detached HEAD, then there is no , and it would attempt to print a NULL pointer. The previous commit fixed this

[PATCH v6] ls-remote: create '--sort' option

Create a '--sort' option for ls-remote, based on the one from for-each-ref. This e.g. allows ref names to be sorted by version semantics, so that v1.2 is sorted before v1.10. Signed-off-by: Harald Nordgren --- Notes: Moving 'int i' declaration outside of 'for' loop

Re: [PATCH 7/7] diff.c: add --color-moved-ignore-space-delta option

On Mon, 2 Apr 2018 15:48:54 -0700 Stefan Beller wrote: > +struct ws_delta { > + int deltachars; > + char firstchar; > +}; I'll just make some overall design comments. Shouldn't this be a string of characters (or a char* and len) and whether it was added or removed?

Re: [PATCH 6/7] diff.c: decouple white space treatment for move detection from generic option

On Mon, 2 Apr 2018 15:48:53 -0700 Stefan Beller wrote: > In the original implementation of the move detection logic we assumed that > the choice for ignoring white space changes is the same for the move > detection as it is for the generic diff. It turns out this is wrong.

Re: [RFC PATCH 0/7] Moved code detection: ignore space on uniform indentation

On Mon, Apr 2, 2018 at 4:47 PM, Jonathan Tan wrote: > On Mon, 2 Apr 2018 15:48:47 -0700 > Stefan Beller wrote: > >> This is a re-attempt of [1], which allows the moved code detection to >> ignore blanks in various modes. >> >> patches 1-5 are

Re: [PATCH 5/7] diff.c: refactor internal representation for coloring moved code

On Mon, 2 Apr 2018 15:48:52 -0700 Stefan Beller wrote: > At the time the move coloring was implemented we thought an enum of modes > is the best to configure this feature. However as we want to tack on new > features, the enum would grow exponentially. > > Refactor the

Re: [RFC PATCH 0/7] Moved code detection: ignore space on uniform indentation

On Mon, 2 Apr 2018 15:48:47 -0700 Stefan Beller wrote: > This is a re-attempt of [1], which allows the moved code detection to > ignore blanks in various modes. > > patches 1-5 are refactoring, patch 6 adds all existing white space options > of regular diff to the move

RE: [ANNOUNCE] Git v2.17.0

On April 2, 2018 7:20 PM, Junio C Hamano wrote: > To: Stefan Beller > Cc: Randall S. Becker ; git > Subject: Re: [ANNOUNCE] Git v2.17.0 > > Stefan Beller writes: > > > Patch at > > https://public- >

[PATCH] send-email: fix docs regarding storing password with git credential

First of all, ‘git credential fill’ does not store credentials but is used to *read* them. The command which adds credentials to the helper’s store is ‘git credential approve’. Second of all, git-send-email will include port number in host parameter when getting the password so it has to be set

Re: [ANNOUNCE] Git v2.17.0

Stefan Beller writes: > Patch at > https://public-inbox.org/git/010f01d38a9e$a5c4f290$f14ed7b0$@nexbridge.com/ Thanks for a pointer. I think it was left behind and got forgotten while waiting for a reroll and tying the loose ends. I'll go offline for most of the rest of

Re: [PATCH v5] ls-remote: create '--sort' option

On Mon, Apr 2, 2018 at 6:53 PM, Eric Sunshine wrote: > On Mon, Apr 2, 2018 at 6:11 PM, Harald Nordgren > wrote: >> Create a '--sort' option for ls-remote, based on the one from >> for-each-ref. This e.g. allows ref names to be sorted by version

Re: [PATCH v5] ls-remote: create '--sort' option

On Mon, Apr 2, 2018 at 6:11 PM, Harald Nordgren wrote: > Create a '--sort' option for ls-remote, based on the one from > for-each-ref. This e.g. allows ref names to be sorted by version > semantics, so that v1.2 is sorted before v1.10. > > Signed-off-by: Harald Nordgren

[PATCH 1/7] xdiff/xdiff.h: remove unused flags

These flags were there since the beginning (3443546f6e (Use a *real* built-in diff generator, 2006-03-24), but were never used. Remove them. Signed-off-by: Stefan Beller --- xdiff/xdiff.h | 8 1 file changed, 8 deletions(-) diff --git a/xdiff/xdiff.h

[PATCH 7/7] diff.c: add --color-moved-ignore-space-delta option

This marks moved code still as blocks when their indentation level changes uniformly. Signed-off-by: Stefan Beller --- diff.c | 93 -- diff.h | 1 + t/t4015-diff-whitespace.sh | 191

[PATCH 2/7] xdiff/xdiffi.c: remove unneeded function declarations

There is no need to forward-declare these functions, as they are used after their implementation only. Signed-off-by: Stefan Beller --- xdiff/xdiffi.c | 17 - 1 file changed, 17 deletions(-) diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c index

[PATCH 6/7] diff.c: decouple white space treatment for move detection from generic option

In the original implementation of the move detection logic we assumed that the choice for ignoring white space changes is the same for the move detection as it is for the generic diff. It turns out this is wrong. There are a couple of things where the user wants to input their decision into the

[PATCH 5/7] diff.c: refactor internal representation for coloring moved code

At the time the move coloring was implemented we thought an enum of modes is the best to configure this feature. However as we want to tack on new features, the enum would grow exponentially. Refactor the code such that features are enabled via bits. Currently we can * activate the move

[PATCH 4/7] diff.c: adjust hash function signature to match hashmap expectation

This makes the follow up patch easier. Signed-off-by: Stefan Beller --- diff.c | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/diff.c b/diff.c index 52f6e02130..879b8a5d9d 100644 --- a/diff.c +++ b/diff.c @@ -707,11 +707,15 @@ struct

[RFC PATCH 0/7] Moved code detection: ignore space on uniform indentation

This is a re-attempt of [1], which allows the moved code detection to ignore blanks in various modes. patches 1-5 are refactoring, patch 6 adds all existing white space options of regular diff to the move detection. (I am unsure about this patch, as I presume we want to keep the option space at a

[PATCH 3/7] diff.c: do not pass diff options as keydata to hashmap

The diff options are passed to the compare function as 'hashmap_cmp_fn_data', which are given when the hashmaps are initialized. A later patch will make use of the keydata to signal different settings for comparision. Signed-off-by: Stefan Beller --- diff.c | 4 ++-- 1 file

[PATCH v5] ls-remote: create '--sort' option

Create a '--sort' option for ls-remote, based on the one from for-each-ref. This e.g. allows ref names to be sorted by version semantics, so that v1.2 is sorted before v1.10. Signed-off-by: Harald Nordgren --- Documentation/git-ls-remote.txt | 12 +++-

Re: [PATCH] send-email: report host and port separately when calling git credential

Michal Nazarewicz writes: > When git-send-email uses git-credential to get SMTP password, it will > communicate SMTP host and port (if both are provided) as a single entry > ‘host=:’. This trips the ‘git-credential-store’ helper > which expects those values as separate keys

Re: [PATCH v7 08/14] commit-graph: implement git commit-graph read

Derrick Stolee writes: > From: Derrick Stolee > ... > +static int graph_read(int argc, const char **argv) > +{ > + struct commit_graph *graph = 0; The previous round said NULL above, not 0, and NULL is the better way to spell it, I would think.

Re: [PATCH] ls-remote: create '--sort' option

On Mon, Apr 02, 2018 at 10:07:36PM +0200, Harald Nordgren wrote: > @@ -108,9 +115,25 @@ int cmd_ls_remote(int argc, const char **argv, const > char *prefix) > continue; > if (!tail_match(pattern, ref->name)) > continue; > + > +

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

On 04/02, Junio C Hamano wrote: > This is completely offtopic tangent, but I wonder how hidden-bool or > hidden options[] element in general interacts with the recent > addition of helping command line completion. Are we already doing > the right thing? I had a quick look at this, and it looks

Re: [PATCH] ls-remote: create '--sort' option

I shortened the commit message. Since we already have this feature for other sub-commands I guess I don't have to explain what version semantics are. Have to say I'm a bit confused about 'git send-mail'. This time I tried git send-email --subject-prefix="PATCH v4"

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

On 04/02, Junio C Hamano wrote: > Thomas Gummerer writes: > > > +test_expect_success 'reset --no-show-new-head-line suppresses "HEAD is now > > at" output' ' > > + git reset --hard --no-show-new-head-line HEAD >actual && > > + ! grep "HEAD is now at" > +' > > As

[PATCH v4] ls-remote: create '--sort' option

Create a '--sort' option for ls-remote, based on the one from for-each-ref. This e.g. allows ref names to be sorted by version semantics, so that v1.2 is sorted before v1.10. Signed-off-by: Harald Nordgren --- Documentation/git-ls-remote.txt | 12 +++-

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

On 04/02, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Introduce a new --show-new-head-line command line option, that > > determines whether the "HEAD is now at ..." message is printed or not. > > It is enabled by default to preserve the current behaviour. > > > >

Re: git stash push -u deletes untracked files

On 04/02, Hosam Aly Mahmoud wrote: > Hi, > > Using Git 2.16.3 on MacOS 10.13.3, running `git stash push > --include-untracked` deletes the untracked files specified in its > arguments and creates an empty stash commit. > > In the example below, I create a repository with a single file and a >

[PATCH v7 08/14] commit-graph: implement git commit-graph read

From: Derrick Stolee Teach git-commit-graph to read commit graph files and summarize their contents. Use the read subcommand to verify the contents of a commit graph file in the tests. Signed-off-by: Derrick Stolee ---

[PATCH v7 05/14] commit-graph: create git-commit-graph builtin

From: Derrick Stolee Teach git the 'commit-graph' builtin that will be used for writing and reading packed graph files. The current implementation is mostly empty, except for an '--object-dir' option. Signed-off-by: Derrick Stolee --- .gitignore

[PATCH v7 07/14] commit-graph: implement git-commit-graph write

From: Derrick Stolee Teach git-commit-graph to write graph files. Create new test script to verify this command succeeds without failure. Signed-off-by: Derrick Stolee --- Documentation/git-commit-graph.txt | 41 ++ builtin/commit-graph.c

[PATCH v7 12/14] commit-graph: read only from specific pack-indexes

From: Derrick Stolee Teach git-commit-graph to inspect the objects only in a certain list of pack-indexes within the given pack directory. This allows updating the commit graph iteratively. Signed-off-by: Derrick Stolee ---

[PATCH v7 14/14] commit-graph: implement "--additive" option

From: Derrick Stolee Teach git-commit-graph to add all commits from the existing commit-graph file to the file about to be written. This should be used when adding new commits without performing garbage collection. Signed-off-by: Derrick Stolee ---

[PATCH v7 09/14] commit-graph: add core.commitGraph setting

From: Derrick Stolee The commit graph feature is controlled by the new core.commitGraph config setting. This defaults to 0, so the feature is opt-in. The intention of core.commitGraph is that a user can always stop checking for or parsing commit graph files if

[PATCH v7 10/14] commit-graph: close under reachability

From: Derrick Stolee Teach write_commit_graph() to walk all parents from the commits discovered in packfiles. This prevents gaps given by loose objects or previously-missed packfiles. Also automatically add commits from the existing graph file, if it exists.

[PATCH v7 02/14] csum-file: refactor finalize_hashfile() method

From: Derrick Stolee If we want to use a hashfile on the temporary file for a lockfile, then we need finalize_hashfile() to fully write the trailing hash but also keep the file descriptor open. Do this by adding a new CSUM_HASH_IN_STREAM flag along with a functional

[PATCH v7 04/14] graph: add commit graph design document

From: Derrick Stolee Add Documentation/technical/commit-graph.txt with details of the planned commit graph feature, including future plans. Signed-off-by: Derrick Stolee --- Documentation/technical/commit-graph.txt | 163 +++ 1

[PATCH v7 03/14] commit-graph: add format document

From: Derrick Stolee Add document specifying the binary format for commit graphs. This format allows for: * New versions. * New hash functions and hash lengths. * Optional extensions. Basic header information is followed by a binary table of contents into "chunks" that

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

Thomas Gummerer writes: > +test_expect_success 'reset --no-show-new-head-line suppresses "HEAD is now > at" output' ' > + git reset --hard --no-show-new-head-line HEAD >actual && > + ! grep "HEAD is now at" +' As builtin/reset.c::print_new_head_line() does this:

[PATCH v7 13/14] commit-graph: build graph from starting commits

From: Derrick Stolee Teach git-commit-graph to read commits from stdin when the --stdin-commits flag is specified. Commits reachable from these commits are added to the graph. This is a much faster way to construct the graph than inspecting all packed objects, but is

[PATCH v7 11/14] commit: integrate commit graph with commit parsing

From: Derrick Stolee Teach Git to inspect a commit graph file to supply the contents of a struct commit when calling parse_commit_gently(). This implementation satisfies all post-conditions on the struct commit, including loading parents, the root tree, and the commit

[PATCH v7 01/14] csum-file: rename hashclose() to finalize_hashfile()

From: Derrick Stolee The hashclose() method behaves very differently depending on the flags parameter. In particular, the file descriptor is not always closed. Perform a simple rename of "hashclose()" to "finalize_hashfile()" in preparation for functional changes.

[PATCH v7 00/14] Serialized Git Commit Graph

This patch has only a few changes since v6: * Fixed whitespace issues using 'git rebase --whitespace=fix' * The --stdin-packs docs now refer to "pack-indexes" insead of "packs" * Modified description of --object-dir option to warn use is rare * Replaced '--additive' with '--append' * In

[PATCH v7 06/14] commit-graph: implement write_commit_graph()

From: Derrick Stolee Teach Git to write a commit graph file by checking all packed objects to see if they are commits, then store the file in the given object directory. Helped-by: Jeff King Signed-off-by: Derrick Stolee ---

Re: [PATCH v6 2/6] reset: introduce show-new-head-line option

Thomas Gummerer writes: > Introduce a new --show-new-head-line command line option, that > determines whether the "HEAD is now at ..." message is printed or not. > It is enabled by default to preserve the current behaviour. > > It will be used in a subsequent commit to

Re: [PATCH] ls-remote: create '--sort' option

Harald Nordgren writes: > Subject: Re: [PATCH] ls-remote: create '--sort' option It would be more helpful to mark as [PATCH v2] a rerolled patch like this. > Create a '--sort' option for ls-remote. This is useful e.g. for the Go > repository after the release of

RE: [ANNOUNCE] Git v2.17.0

On April 2, 2018 4:02 PM, Stefan Beller found my change: > On Mon, Apr 2, 2018 at 12:57 PM, Randall S. Becker > wrote: > > On April 2, 2018 3:34 PM, Junio C Hamano wrote: > >> The latest feature release Git v2.17.0 is now available at the usual > >> places. It is

[PATCH] ls-remote: create '--sort' option

Create a '--sort' option for ls-remote. This is useful e.g. for the Go repository after the release of version 1.10, where by default v1.10 is sorted before v1.2. See: $ git ls-remote -t https://go.googlesource.com/go ... 205f850ceacfc39d1e9d76a9569416284594ce8c

Re: [GSoC] [PATCH] travis-ci: added clang static analysis

On Sun, Apr 1, 2018, 8:10 PM Lars Schneider wrote: > > That's a good summary and I don't see a better solution. While (3) > sounds nice, I think (2) is the fastest/most pragmatic solution. > > We already use the Travis cache [1]. You could use that mechanism to > store

Re: [PATCH] ls-remote: create option to sort by versions

Thanks for all the discussion! I think I figured out a way to reuse more ref-filter.c machinery. I will submit another patchset shortly. On Mon, Apr 2, 2018 at 8:32 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> This is a sensible thing to

Re: [ANNOUNCE] Git v2.17.0

On Mon, Apr 2, 2018 at 12:57 PM, Randall S. Becker wrote: > On April 2, 2018 3:34 PM, Junio C Hamano wrote: >> The latest feature release Git v2.17.0 is now available at the usual places. >> It is >> comprised of 516 non-merge commits since v2.16.0, contributed by 71 >>

RE: [ANNOUNCE] Git v2.17.0

On April 2, 2018 3:34 PM, Junio C Hamano wrote: > The latest feature release Git v2.17.0 is now available at the usual places. > It is > comprised of 516 non-merge commits since v2.16.0, contributed by 71 > people, 20 of which are new faces. Just a heads up. I think this one might have gotten

Re: [PATCH] Support long format for log-based submodule diff

On Sun, Apr 1, 2018 at 6:07 PM, Robert Dailey wrote: > On Tue, Mar 27, 2018 at 5:17 PM, Stefan Beller wrote: >>> >> $ git diff --submodule=log --submodule-log-detail=(long|short) >>> >> >>> >> I'm not sure what makes sense here. I welcome

[ANNOUNCE] Git v2.17.0

The latest feature release Git v2.17.0 is now available at the usual places. It is comprised of 516 non-merge commits since v2.16.0, contributed by 71 people, 20 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public

Re: [PATCH] ls-remote: create option to sort by versions

Ævar Arnfjörð Bjarmason writes: > This is a sensible thing to want, but why not follow the UI we have for > this with git-tag? I.e. --sort= & -i (or --ignore-case)? Of course > ls-remote doesn't just show tags, so maybe we'd want --tag-sort= > and --ignore-tag-case or

Re: [PATCH v12 00/10] convert: add support for different encodings

> On 29 Mar 2018, at 20:37, Junio C Hamano wrote: > > lars.schnei...@autodesk.com writes: > >> From: Lars Schneider >> >> Patches 1-6,9 are preparation and helper functions. Patch 4 is new. >> Patch 7,8,10 are the actual change. >> >> This series

Re: [PATCH] graph.c: log.showRootMark to indicate root commits

Junio C Hamano writes: > Lyubomyr Shaydariv writes: > >> When log.showRootMark is set, root commits are marked with >> the at sign (@). >> >> When log.showRootMark is not set, root commits are marked with >> the asterisk sign (*). This is the default

Re: [PATCH] l10n: de.po: translate 132 new messages

Hi Ralf, thanks a lot for your translations! I've only found a small issue: #: git-add--interactive.perl:1405 -#, fuzzy, perl-format +#, perl-format msgid "Discard this hunk from worktree [y,n,q,a,d%s,?]? " -msgstr "diesen Patch-Block im Arbeitsverzeichnis verwerfen [y,n,q,a,d,/%s,?]? "

Re: [PATCH v4 00/13] Serialized Git Commit Graph

> Currently, the format includes 8 bytes to share between the generation > number and commit date. Due to alignment concerns, we will want to keep this > as 8 bytes or truncate it to 4-bytes. Either we would be wasting at least 3 > bytes or truncating dates too much (presenting the 2038 problem

Re: [PATCH] graph.c: log.showRootMark to indicate root commits

Lyubomyr Shaydariv writes: > When log.showRootMark is set, root commits are marked with > the at sign (@). > > When log.showRootMark is not set, root commits are marked with > the asterisk sign (*). This is the default behavior. > > Signed-off-by: Lyubomyr Shaydariv

Re: [PATCH v4 00/13] Serialized Git Commit Graph

On 4/2/2018 1:35 PM, Stefan Beller wrote: On Mon, Apr 2, 2018 at 8:02 AM, Derrick Stolee wrote: I would be happy to review any effort to extend the commit-graph format to include such indexes, as long as the performance benefits outweigh the complexity to create them. [2]

Re: [PATCH] ls-remote: create option to sort by versions

On Mon, Apr 02, 2018 at 06:26:49PM +0200, Harald Nordgren wrote: > It would be nice to have a uniform option like > '--sort=version:refname'. But spending a few hours to look over the > code, it seems that ls-remote.c would require a lot of rewrites if we > wanted to start using `ref_array` and

Re: [PATCH] ls-remote: create option to sort by versions

Both points make sense and it sounds like a very pragmatic approach. I'll look into it! On Mon, Apr 2, 2018 at 7:32 PM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Apr 02 2018, Harald Nordgren wrote: > >> In regards the the print statement, it was only moved down according >> to

Re: [PATCH v4 00/13] Serialized Git Commit Graph

On Mon, Apr 2, 2018 at 8:02 AM, Derrick Stolee wrote: >>> >>> I would be happy to review any effort to extend the commit-graph >>> format to include such indexes, as long as the performance benefits >>> outweigh the complexity to create them. >>> >>> [2] >>>

Re: [PATCH] ls-remote: create option to sort by versions

On Mon, Apr 02 2018, Harald Nordgren wrote: > In regards the the print statement, it was only moved down according > to the diff because I added more logic above. Basically there is 1) > the unrolling of the linked list to an array and 2) the printing > logic. I could move it and make the diff

Re: [GIT PULL] l10n updates for 2.17.0 round 1

Jiang Xin writes: > Would you please pull the following git l10n updates. > > The following changes since commit 0afbf6caa5b16dcfa3074982e5b48e27d452dbbb: Thanks, done.

Re: [PATCH] ls-remote: create option to sort by versions

Thanks for your comment Ævar! In regards the the print statement, it was only moved down according to the diff because I added more logic above. Basically there is 1) the unrolling of the linked list to an array and 2) the printing logic. I could move it and make the diff smaller, but that

git stash push -u deletes untracked files

Hi, Using Git 2.16.3 on MacOS 10.13.3, running `git stash push --include-untracked` deletes the untracked files specified in its arguments and creates an empty stash commit. In the example below, I create a repository with a single file and a single commit. Then I create two untracked files and

Re: [PATCH v4 00/13] Serialized Git Commit Graph

On 4/2/2018 10:46 AM, Jakub Narebski wrote: Derrick Stolee writes: [...] At one point, I was investigating these reachability indexes (I read "SCARAB: Scaling Reachability Computation on Large Graphs" by Jihn, Ruan, Dey, and Xu [2]) but find the question that these indexes

Re: [PATCH v4 00/13] Serialized Git Commit Graph

Derrick Stolee writes: > On 3/30/2018 7:10 AM, Jakub Narebski wrote: >> I hope that I am addressing the most recent version of this series. > > Hi Jakub. Thanks for the interest in this patch series. > > The most-recent version is v6 [1], but I will re-roll to v7 soon > (after

Re: [PATCH v4 01/13] commit-graph: add format document

Derrick Stolee writes: > On 3/30/2018 9:25 AM, Jakub Narebski wrote: >> Derrick Stolee writes: >> >>> +== graph-*.graph files have the following format: >> What is this '*' here? > > No longer necessary. It used to be a placeholder for a hash value, but > now

Re: [PATCH v4 01/13] commit-graph: add format document

On 3/30/2018 9:25 AM, Jakub Narebski wrote: Derrick Stolee writes: +== graph-*.graph files have the following format: What is this '*' here? No longer necessary. It used to be a placeholder for a hash value, but now the graph is stored in objects/info/commit-graph.

Re: [PATCH v4 00/13] Serialized Git Commit Graph

On 3/30/2018 7:10 AM, Jakub Narebski wrote: I hope that I am addressing the most recent version of this series. Hi Jakub. Thanks for the interest in this patch series. The most-recent version is v6 [1], but I will re-roll to v7 soon (after v2.17.0 is marked). [1]

Re: git log --oneline cannot display dates

On Mon, Apr 02, 2018 at 01:05:01PM +0100, David Hoyle wrote: > When using the git log command with the --oneline switch, you cannot > add the --date= switch to see the dates. Right. --date is just about selecting which date format to show, not whether to show one. The decision of what to show is

Re: From Katie

Hello, this is the second times am sending you this mail and you refused to reply to my email why? write to me on this email

Re: Possible bug in git log with date ranges

On Mon, Apr 02 2018, David Hoyle wrote: > Hi, > > Hopefully I've read the readme file correctly for submitting something > that might be a bug. > > I've recently migrated projects from an old version control system > (JEDI VCS) to Git (which I really like BTW). The way this was done was > by

git log --oneline cannot display dates

When using the git log command with the --oneline switch, you cannot add the --date= switch to see the dates. The only workaround is to create an alias and use the --pretty-format which doesn't provide the ability to colour the branch and tag information (as far as i can tell). regards David

Possible bug in git log with date ranges

Hi, Hopefully I've read the readme file correctly for submitting something that might be a bug. I've recently migrated projects from an old version control system (JEDI VCS) to Git (which I really like BTW). The way this was done was by extracting the files from the original database and saving

Re: [PATCH v3 0/3] add -p: select individual hunk lines

On Mon, Apr 02 2018, Phillip Wood wrote: > On 31/03/18 20:20, Ævar Arnfjörð Bjarmason wrote: >> >> On Fri, Mar 30 2018, Phillip Wood wrote: >> >>> On 29/03/18 19:32, Junio C Hamano wrote: Phillip Wood writes: > From: Phillip Wood

Re: [PATCH v3 0/3] add -p: select individual hunk lines

On 31/03/18 20:20, Ævar Arnfjörð Bjarmason wrote: > > On Fri, Mar 30 2018, Phillip Wood wrote: > >> On 29/03/18 19:32, Junio C Hamano wrote: >>> Phillip Wood writes: >>> From: Phillip Wood Since v2 I've updated the patches

Re: [RFC] git clone add option to track all remote branches

On Mon, Apr 02 2018, Yubin Ruan wrote: > I am writing to ask that whether or not you think will be appropriate to add > an option to "git clone" so that whenever a repo is cloned, branches are > created automatically to track corresponding remote branches. (or is there any > equivelant option?)

Re: Need help debugging issue in git

Am 02.04.2018 um 02:36 schrieb Robert Dailey: I'm struggling with a bug that I found introduced in git v2.13.2. The bug was not reproducible in v2.13.1. The issue is that using arguments like "@{-1}" to aliases causes those curly braces to be removed, so once the command is executed after alias

Re: [PATCH] ls-remote: create option to sort by versions

On Mon, Apr 02 2018, Harald Nordgren wrote: > Create the options '-V ' and '--version-sort' to sort > 'git ls-remote' output by version semantics. This is useful e.g. for > the Go repository after the release of version 1.10, where otherwise > v1.10 is sorted before v1.2. See: > > $ git

Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)

Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > [...] > In the parlance of your RFC v2, where you start with this history (which I > translated into the left-to-right notation that is used in pretty much all > of Git's own documentation about interactive