On Sun, Mar 17, 2019 at 5:50 AM Nguyễn Thái Ngọc Duy wrote:
>
> "git checkout" doing too many things is a source of confusion for many
> users (and it even bites old timers sometimes). To remedy that, the
> command will be split into two new ones: switch and restore. The good
> old "git checkout"
On Mon, Mar 18, 2019 at 4:38 AM Nguyễn Thái Ngọc Duy wrote:
>
> Phillip found out that 'git checkout -f ' does not restore
> conflict/unmerged files correctly. All tracked files should be taken
> from and all non-zero stages removed. Most of this is true,
> except that the final file could be in
On Sun, Mar 17, 2019 at 4:02 PM Todd Zullinger wrote:
>
> d76ce4f734 ("log,diff-tree: add --combined-all-paths option",
> 2019-02-07) added tests for files containing tabs.
>
> When the tests are run with bash, the lack of quoting during the file
> setup causes 'ambiguous redirect' errors.
>
> Sig
On Wed, Mar 13, 2019 at 1:58 PM Jeff King wrote:
>
> I took an informal poll at the last contributor summit in Brussels, but
> that obviously has some bias. So I'll ask here: do you have a location
> preference for a Git Merge conference (and associated contributor
> summit) next March?
>
> We're
On Thu, Mar 14, 2019 at 12:23 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> I think sometimes a 3-way merge creates marker conflicts in file, and
> >> this does not look easy to reverse when switching back. If it's true
> >> and we can det
On Thu, Mar 14, 2019 at 2:18 AM Duy Nguyen wrote:
>
> On Tue, Mar 12, 2019 at 01:28:35PM -0400, Eric Sunshine wrote:
> > > > Again, not much of a datapoint, but I do use --orphan periodically.
> > > > The idea of "fixing" the behavior so that --orphan starts with a clean
> > > > slate is certainly
On Wed, Mar 13, 2019 at 8:29 PM Duy Nguyen wrote:
>
> On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> wrote:
> > > +-m::
> > > +--merge::
> > > + If you have local modifications to one or more files that are
> > > + different between the current branch and the branch to which
> > > +
On Wed, Mar 13, 2019 at 4:05 AM Duy Nguyen wrote:
>
> On Tue, Mar 12, 2019 at 12:54 AM Elijah Newren wrote:
> > > +--progress::
> > > +--no-progress::
> > > + Progress status is reported on the standard error stream
> > > + by default
On Tue, Mar 12, 2019 at 12:32 PM Sergio Durigan Junior
wrote:
>
> On Tuesday, March 12 2019, Elijah Newren wrote:
>
> > On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
> > wrote:
> >> On Tuesday, March 12 2019, Duy Nguyen wrote:
> >>
> >>
On Tue, Mar 12, 2019 at 9:48 AM Sergio Durigan Junior
wrote:
> On Tuesday, March 12 2019, Duy Nguyen wrote:
>
> > On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
> > wrote:
> >> This works without problems most of the time (well, usually there are
> >> conflicts and all, but that's a burden
On Tue, Mar 12, 2019 at 11:21 AM Robert P. J. Day wrote:
>
> On Tue, 12 Mar 2019, Kevin Daudt wrote:
>
> ... snip ...
>
> > The only reason why `:q!` works just for comitting is because there
> > is no default message, so the final message ends up empty.
> >
> > When you do things like git revert
On Tue, Mar 12, 2019 at 4:58 AM Duy Nguyen wrote:
> On Tue, Mar 12, 2019 at 12:25 AM Elijah Newren wrote:
> > On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
> > > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > > wrote:
> > > > On 08/03
On Tue, Mar 12, 2019 at 8:37 AM Eric Sunshine wrote:
>
> On Tue, Mar 12, 2019 at 8:19 AM Duy Nguyen wrote:
> > On Tue, Mar 12, 2019 at 3:51 AM Phillip Wood
> > wrote:
> > > I tend to agree with this but that's probably because I don't really use
> > > checkout -B. I'm not sure if it's widely us
On Tue, Mar 12, 2019 at 4:06 AM Phillip Wood wrote:
>
> Hi Elijah
>
> On 11/03/2019 17:54, Elijah Newren wrote:
> > A few other comments that I thought of while responding elsewhere in
> > the thread that didn't make sense to include elsewhere...
> >
> > O
On Mon, Mar 11, 2019 at 1:51 PM Phillip Wood wrote:
> On 11/03/2019 17:24, Elijah Newren wrote:
> > On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
> >> On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> >> wrote:
> >>> On 08/03/2019 09:57, Nguyễn Thái Ngọc
Hi Norbert,
On Fri, Mar 8, 2019 at 9:38 AM Norbert Nemec
wrote:
>
> Thanks, Elijah, I had indeed missed that block about the ^0 handling.
>
> I still don't get why this awkward workaround is required. Why isn't that
> lookup done by default? Performance can't be the reason, since the same
> loo
On Sun, Mar 10, 2019 at 5:29 PM Jacob Keller wrote:
>
> On March 8, 2019 1:57:41 AM PST, "Nguyễn Thái Ngọc Duy"
> wrote:
> >+::
> >+ Name for the new branch.
> >+
> >+::
> >+ The name of a commit at which to switch to before creating a
> >+ new branch or detach from.
>
> The word
// CC'ing Thomas since this touches on a thread elsewhere about the glossary
On Mon, Mar 11, 2019 at 8:40 AM Duy Nguyen wrote:
>
> On Mon, Mar 11, 2019 at 10:22 PM Duy Nguyen wrote:
> >
> > On Sun, Mar 10, 2019 at 2:17 AM Elijah Newren wrote:
> > >
> > &
A few other comments that I thought of while responding elsewhere in
the thread that didn't make sense to include elsewhere...
On Fri, Mar 8, 2019 at 2:00 AM Nguyễn Thái Ngọc Duy wrote:
>
> "git checkout" doing too many things is a source of confusion for many
> users (and it even bites old timer
On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
>
> On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> wrote:
> >
> > Hi Duy
> >
> > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > "git checkout" doing too many things is a source of confusion for many
> > > users (and it even bites old time
On Sun, Mar 10, 2019 at 4:19 AM Duy Nguyen wrote:
>
> On Fri, Mar 8, 2019 at 5:17 PM Nguyễn Thái Ngọc Duy wrote:
> > - --index has a different meaning in git-apply. I don't have a good
> > suggestion except "yeah we have two different worlds now, the old
> > and the new one"
>
> I will rename
Hi,
On Mon, Mar 11, 2019 at 2:37 AM Denton Liu wrote:
>
> Hello all,
>
> I was in the process of deprecating `git diff ..` as
> discussed here[1]. However, I ran into a weird case that I'm not sure
> how to deal with.
>
> In t3430-rebase-merges.sh:382, we have the following test case which
> invo
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> The new command "git restore" (together with "git switch") are added
> to avoid the confusion of one-command-do-all "git checkout" for new
> users. They are also helpful to avoid ambiguation context.
s/ambiguation/ambiguous/ or s/ambi
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> Completion for restore is straightforward. We could still do better
> though by give the list of just tracked files instead of all present
> ones. But let's leave it for later.
s/give/giving/
I'm slightly worried that due to using --
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> git-restore is different from git-checkout that it only restores the
> worktree by default, not both worktree and index. add--interactive
> needs some update to support this mode.
Nice! That removes my frowny face from a few patches
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> "git restore --index" does not make much sense since we're told to
> restore the index from the (by default) index. Set default source to
> HEAD in this case. This is basically the same as "git reset -- ".
Can I suggest a slight rewor
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> 'git checkout ' updates both index and
> worktree. But updating the index when you want to restore worktree
> files is non-intuitive. The index contains the data ready for the next
> commit, and there's no indication that the user wil
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> Overlay mode is considered confusing when the command is about
> restoring files on worktree. Disable it by default. The user can still
> turn it on, or use 'git checkout' which still has overlay mode on by
> default.
>
> While at ther
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> "git restore" without arguments does not make much sense when
> it's about restoring files (what files now?). We could default to
> either
>
> git restore .
>
> or
>
> git restore :/
>
> Neither is intuitive. Make the user alwa
On Sat, Mar 9, 2019 at 4:16 AM Duy Nguyen wrote:
> On Sat, Mar 9, 2019 at 1:01 AM Elijah Newren wrote:
> > > +-q::
> > > +--quiet::
> > > + Quiet, suppress feedback messages.
> > > +
> > > +--progress::
> > > +--no-progress::
> &
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
>
> This is another departure from 'git checkout' syntax, which uses -- to
> separate ref and pathspec. The observation is restore (or "git
> checkout ,, ") is most often used to restore some files from
> the index. If this is correct, we
Hi,
On Sat, Mar 9, 2019 at 9:29 AM Thomas Gummerer wrote:
>
> On 03/07, Duy Nguyen wrote:
> > On Thu, Mar 7, 2019 at 7:34 PM Philip Oakley wrote:
> > >
> > > On 06/03/2019 09:44, Duy Nguyen wrote:
> > > > On Wed, Mar 6, 2019 at 8:34 AM Junio C Hamano wrote:
> > > >> * tg/checkout-no-overlay (20
Thanks for working on this; overall looks really good. I've got a few
comments here and there on the wording and combinations of options...
On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
> +SYNOPSIS
It might be worth adding some words somewhere to differentiate between
`reset` and `
Hi,
On Wed, Feb 20, 2019 at 2:58 PM Elijah Newren wrote:
>
> I found a few issues with parsing in fast-import (dating back to
> I've cc'ed the relevant folks, and have a few patches that fix the
> issue and I think make the parser more robust against future issues in
&
Hi Norbert,
On Fri, Mar 8, 2019 at 2:51 AM Norbert Nemec
wrote:
>
> Hi there,
>
> I've struggled for quite some time to sort out documented, intended and
> actual behavior of git fast-import. Unless I'm completely mistaken, it seems
> to be a straightforward bug, but if that is the case, I am r
On Tue, Mar 5, 2019 at 8:43 PM Junio C Hamano wrote:
> Elijah Newren writes:
>
> > Note that there is also a third possibility here:
> >
> > C) There are different answers depending on the context and content
> > that cannot be determined by git,
On Sat, Mar 2, 2019 at 5:33 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Whatever we choose for the default could be tweaked by some new option
> > (e.g. make it less noisy or don't mark such paths as conflicted if the
> > user has explicitly stated
Hi Junio,
On Thu, Feb 28, 2019 at 6:52 PM Junio C Hamano wrote:
>
> As you know that I've always been skeptical to this rename-directory
> business, this probably won't come as a surprise, but I seriously
> think directory renames should be made opt-in, and as a separate
> option, making the opti
On Wed, Feb 27, 2019 at 8:40 AM Jeff King wrote:
>
> On Wed, Feb 27, 2019 at 08:02:35AM -0800, Elijah Newren wrote:
>
> > > > I have found what I suspect to be a bug, or at least not desirable
> > > > behavior in my case. In one branch, I have moved all files
Hi,
On Wed, Feb 27, 2019 at 6:30 AM Phillip Wood wrote:
>
> Hi Linus
>
> On 27/02/2019 12:47, Linus Nilsson wrote:
> > Hi
> >
> > I have found what I suspect to be a bug, or at least not desirable behavior
> > in my case. In one branch, I have moved all files in a directory to another
> > direc
ast-forward cases as well
and suggest using --no-ff with --no-commit if the point is to ensure
that the merge stops before completing.
Reported-by: Ulrich Windl
Signed-off-by: Elijah Newren
---
Changes since v2:
- Small wording change suggested by Junio (s/do not need to/do not/)
Documentati
Hi Phillip,
On Wed, Feb 20, 2019 at 3:00 AM Phillip Wood wrote:
> On 22/01/2019 20:39, Junio C Hamano wrote:
> > Elijah Newren writes:
> >
> >> Also, I have a fuzzy memory of discussing a very similar case with
> >> some rebase-oriented option and its
Signed-off-by: Elijah Newren
---
Documentation/git-fast-import.txt | 7 +-
t/t9300-fast-import.sh| 37 +++
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
index
a case (it would be
trivial to use cat-blob before the filemodify instead), but since there
is evidence this was used, for backwards compatibility let's support
that case too.
Signed-off-by: Elijah Newren
---
Documentation/git-fast-import.txt | 7 ---
fast-import.c |
e cc'ed the relevant folks, and have a few patches that fix the
issue and I think make the parser more robust against future issues in
a way that I think is safe enough for backward compatibility, but
"backward compatible enough" might concern some folks; if so, please
take a look at pa
The docs claimed `ls` commands could appear almost anywhere, but the
code told a different story. Modify the docs to match the code.
Signed-off-by: Elijah Newren
---
Documentation/git-fast-import.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-fast
her, trying to allow this command anywhere caused parsing
bugs. Fix the parsing problems by only allowing get-mark commands to
appear when other commands have completed.
Signed-off-by: Elijah Newren
---
Documentation/git-fast-import.txt | 4
fast-import.c | 8 ++
s added, it was stuck
near the top of the list, with no rationale for that particular
location. Move it down to later to appease my Tourette's-like internal
twitching that its former location was causing.
Signed-off-by: Elijah Newren
---
fast-import.c | 4 ++--
1 file changed, 2 insertions(+)
On Tue, Feb 19, 2019 at 2:36 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> As long as worktree-only mode does not lose track of a
> >> previously-untracked path in the index (perhaps use the i-t-a bit),
> >> I do not have a strong objection agains
On Tue, Feb 19, 2019 at 11:32 AM Junio C Hamano wrote:
> Elijah Newren writes:
>
> > +With --no-commit perform the merge and stop just before creating
> > +a merge commit, to give the user a chance to inspect and further
> > +tweak the merge result before committing.
&g
On Tue, Feb 19, 2019 at 11:07 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Overall this looks good, but there's just one part that confuses me.
> > Here you seem to suggest that if you pass --source but neither --index
> > or --worktree that both th
On Tue, Feb 19, 2019 at 11:03 AM Junio C Hamano wrote:
> * --no-index --worktree ...
>
>Update only the working tree files without touching the index
>(new feature that cannot be done with the current Git, although
>"cat-file -p >path" may be close enough at times), from the index
I
On Tue, Feb 19, 2019 at 11:10 AM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > I am getting the impression that to save typing, you would want to
> > make "--index --worktree" the default (i.e. among the above, only
> > --no-index and --no-worktree need to be spelled explicitly), but
> >
ast-forward cases as well
and suggest using --no-ff with --no-commit if the point is to ensure
that the merge stops before completing.
Reported-by: Ulrich Windl
Signed-off-by: Elijah Newren
---
Changes since v1:
- Tweaked commit message
Documentation/merge-options.txt | 12 +--
Hi Duy,
On Mon, Feb 18, 2019 at 8:21 PM Duy Nguyen wrote:
>
> On Sat, Feb 2, 2019 at 12:57 AM Junio C Hamano wrote:
> >
> > Duy Nguyen writes:
> >
> > > Of course we could just do --index and --worktree, each option
> > > restores the respective part. Then it's combinable (and extensible in
> >
Hi Ulrich,
Sorry for the late reply...
On Tue, Jan 22, 2019 at 11:04 PM Ulrich Windl
wrote:
> >>> Elijah Newren schrieb am 22.01.2019 um 22:29 in
> Nachricht
> > On Tue, Jan 22, 2019 at 1:05 PM Ulrich Windl
> > wrote:
> >>
> >> Using git versio
On Fri, Feb 15, 2019 at 10:52 AM Denton Liu wrote:
>
> On Thu, Feb 14, 2019 at 02:10:53PM -0800, Junio C Hamano wrote:
> > Elijah Newren writes:
> >
> > > The only thing I seem to be able to retain is the following: "git
> > > diff D..E is totally usel
Hi Viresh,
On Thu, Feb 14, 2019 at 10:40 PM Viresh Kumar wrote:
>
> On 14-02-19, 13:23, Elijah Newren wrote:
> > I think you're getting tripped up by double-dot vs triple-dot with
> > diff being different than log:
> >
> > `git diff D..E` means the same thi
Hi,
On Thu, Feb 14, 2019 at 11:35 AM Viresh Kumar wrote:
>
> Hello,
>
> I am not sure if it is a bug or not, but the output I got wasn't what
> I was looking for. And so looking for some help. I was looking to send
> pull request [1] to PM maintainer and was generating the request
> against his t
Signed-off-by: Elijah Newren
---
Documentation/git-rebase.txt | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index daa16403ec..619303adbc 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -554,8 +554,6
* --exec
> * --keep-empty
> - * --autosquash
> * --edit-todo
> * --root when used in combination with --onto
>
> --
> 2.20.1
Oops; thanks for catching my mistake.
Reviewed-by: Elijah Newren
On Sun, Feb 10, 2019 at 9:51 PM Оля Тележная wrote:
>
> > It would be nice to have a few more project ideas.
>
> I am not sure I have additional ideas for 3-month project for the intern, but
>
> > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible
> > projects:
> >
> > - Unify r
On Sat, Feb 9, 2019 at 3:23 AM Nguyễn Thái Ngọc Duy wrote:
>
> Since commit 7db118303a (unpack_trees: fix breakage when o->src_index !=
> o->dst_index - 2018-04-23) and changes in merge code to use separate
> index_state for source and destination, when doing a merge with split
> index activated,
Hi Dscho,
On Fri, Feb 8, 2019 at 12:13 PM Johannes Schindelin
wrote:
>
> Hi Ævar,
>
> On Fri, 8 Feb 2019, Ævar Arnfjörð Bjarmason wrote:
>
> > [...]
> >
> > But perhaps there's ways we can in advance deal with a potential
> > future breaking API change. E.g. some Pythonic way of versioning th
Hi Ævar,
On Fri, Feb 8, 2019 at 10:53 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Jan 31 2019, Elijah Newren wrote:
>
> > What's the future? (Core command of git.git? place it in contrib? keep it
> > in a separate repo?) I'm hoping to discuss that at the co
On Thu, Feb 7, 2019 at 8:00 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > +For `-c` and `--cc`, only the destination or final path is shown even
> > +if the file was renamed on any side of history. With
> > +`--combined-all-paths`, the name of the p
On Thu, Feb 7, 2019 at 8:14 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > + for (i = 0; i < num_parent; i++) {
> > + switch (elem->parent[i].status) {
> > + case DIFF_STATUS_COPIED:
> > +
Hi,
On Thu, Jan 31, 2019 at 12:57 AM Elijah Newren wrote:
> git-filter-repo[1], a filter-branch-like tool for rewriting repository
> history, is ready for more widespread testing and feedback. The rough
Someone at the Contributor Summit (Michael Haggerty perhaps?) asked me
about perfo
y.c fuey.c phooey.c
Further, in patch format, this changes the from/to headers so that
instead of just having one "from" header, we get one for each parent.
For example, instead of having
--- a/phooey.c
+++ b/phooey.c
we would see
--- a/fooey.c
--- a/fuey.c
+++ b/phooey.c
Signed-o
com/
* Micro fixes:
* Renamed --combined-all-names to --combined-all-paths
* Fixed formatting error (missed '+') in diff-generate-patch.txt
* Marked tests which used tabs in filenames with FUNNYNAMES prereq
* Added tests that didn't depend on FUNNYNAMES
Elijah Newren (2):
This also adds "rename from " and "copy from "
extended headers when renames or copies are involved.
Signed-off-by: Elijah Newren
---
Documentation/diff-generate-patch.txt | 7 +++
combine-diff.c| 15 +++
2 files changed, 18 insert
On Thu, Feb 7, 2019 at 2:28 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > diff --git a/Documentation/diff-generate-patch.txt
> > b/Documentation/diff-generate-patch.txt
> > index 231105cff4..69cb3b0349 100644
> > --- a/Documentation/diff-generate-
On Thu, Feb 7, 2019 at 3:31 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Now, the question: In addition to the two "from" headers, how many
> > "to" headers do we emit? In particular, do we emit both a "copied to
> > F" and a
On Thu, Feb 7, 2019 at 12:25 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > I think "copy from" and "rename from" should be relatively
> > straightforward. However, in a combined diff, we could have both a
> > modified status, a re
On Tue, Feb 5, 2019 at 12:39 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> >> > Further, in patch format, this changes the from/to headers so that
> >> > instead of just having one "from" header, we get one for each parent.
> >> &g
Hi Dscho,
On Tue, Feb 5, 2019 at 1:48 AM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Mon, 4 Feb 2019, Elijah Newren wrote:
>
> > The combined diff format for merges will only list one filename, even if
> > rename or copy detection is active. For example, with r
On Mon, Feb 4, 2019 at 1:20 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> There is one place that says combined-all-paths, and everywhere else
> it says combined-all-names. The former is probably techincally more
> correct, I think ;-)
Looks like I had a mixture o
y.c fuey.c phooey.c
Further, in patch format, this changes the from/to headers so that
instead of just having one "from" header, we get one for each parent.
For example, instead of having
--- a/phooey.c
+++ b/phooey.c
we would see
--- a/fooey.c
--- a/fuey.c
+++ b/phooey.c
Signed-o
Hi Jakub,
On Sat, Feb 2, 2019 at 4:39 AM Jakub Narebski wrote:
> I have noticed a little 'recording' indicator; would recorded session
> (video or audio only) be made available at some point in time? Did
> anyone take minutes, or take notes (for example of the Summit agenda
> created at the star
Hi Dscho,
On Thu, Jan 31, 2019 at 10:04 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> as discussed at the Contributors' Summit, I ran p3400 as-is (i.e. with the
> --am backend) and then with --keep-empty to force the interactive backend
> to be used. Here are the best of 10, on my relatively p
Hi Roberto,
First of all, thanks for the feedback, and for the awesome work on BFG
repo filter!
On Fri, Feb 1, 2019 at 12:36 AM Roberto Tyley wrote:
>
> On Thu, 31 Jan 2019 at 22:37, Elijah Newren wrote:
> > On Thu, Jan 31, 2019 at 8:09 PM Junio C Hamano wrote:
> > >
On Thu, Jan 31, 2019 at 9:57 AM Elijah Newren wrote:
>
> Hi everyone,
>
> git-filter-repo[1], a filter-branch-like tool for rewriting repository
> history, is ready for more widespread testing and feedback.
...
> What's the future? (Core command of git.git? place it in c
On Thu, Jan 31, 2019 at 8:09 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > git-filter-repo[1], a filter-branch-like tool for rewriting repository
> > history, is ready for more widespread testing and feedback. The rough
> > edges I previously mentioned
Hi everyone,
git-filter-repo[1], a filter-branch-like tool for rewriting repository
history, is ready for more widespread testing and feedback. The rough
edges I previously mentioned have been fixed, and it has several useful
features already, though more development work is ongoing (docs are a
b
giving us the following form:
if incompatible_opts:
if interactive:
show_error_about_interactive_and_am_incompatibilities
if rebase-merge:
show_error_about_merge_and_am_incompatibilities
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
git-legacy-rebase.sh | 20
now REBASE-i.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
.gitignore| 1 -
Documentation/git-rebase.txt | 17 +--
Makefile | 1 -
builtin/rebase.c | 15 ++-
git-legacy-rebase.sh | 43
inery even though we have
no empty commits). A subsequent commit will remove the inconsistency in
--skip handling.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
t/t5407-post-rewrite-hook.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/
turning on topological sorting is actually a
performance improvement: by way of comparison, turning on --topo-order
made fast-export faster (see
https://public-inbox.org/git/20090211135640.ga19...@coredump.intra.peff.net/).
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
git-
presence of a
"verbose" file in the state_dir, while the other was signalled by the
contents of a "quiet" file was just weirdly inconsistent. (This
inconsistency pre-dated the rewrite into C.) Make them consistent by
having them both key off the presence of the file.
Acked-by
treat it as an empty commit trivially squashed into
its parent.
This brings the rebase--am and rebase--merge backends in sync with the
behavior of the interactive rebase backend.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
builtin/am.c | 9 +
git-r
y thoroughly in the rebase
man page (in the "Incompatible Options" section, with multiple links
throughout the document), and since I expect this list to change over
time, just simplify the error message.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
builtin/rebase.c
f.bet/)
Elijah Newren (8):
rebase: make builtin and legacy script error messages the same
rebase: fix incompatible options error message
t5407: add a test demonstrating how interactive handles --skip
differently
am, rebase--merge: do not overlook --skip'ed commits with post-rew
t;error:" prefix from the builtin
version of rebase, and change the prefix from "error:" to "fatal:" in
the legacy script to match.
Acked-by: Johannes Schindelin
Signed-off-by: Elijah Newren
---
builtin/rebase.c | 10 +-
git-legacy-rebase.sh | 12 ++-
y.c fuey.c phooey.c
Further, in patch format, this changes the from/to headers so that
instead of just having one "from" header, we get one for each parent.
For example, instead of having
--- a/phooey.c
+++ b/phooey.c
we would see
--- a/fooey.c
--- a/fuey.c
+++ b/phooey.c
Signed-o
On Fri, Jan 25, 2019 at 2:21 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Also, my first version of the patch actually showed all names, on all
> > lines, but I found the heavy repetition really annoying, and not in
> > keeping with how non-merge commits
On Fri, Jan 25, 2019 at 11:51 AM Eric Sunshine wrote:
>
> On Fri, Jan 25, 2019 at 12:52 PM Elijah Newren wrote:
> > On Fri, Jan 25, 2019 at 9:41 AM Derrick Stolee wrote:
> > > On 1/25/2019 11:54 AM, Elijah Newren wrote:
> > > > + printf "0f9645804ebb
On Fri, Jan 25, 2019 at 11:29 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > The raw diff format for merges with -c or --cc will only list one
> > filename, even if rename detection is active and a rename was detected
> > for the given path. Examples:
>
On Fri, Jan 25, 2019 at 9:41 AM Derrick Stolee wrote:
>
> On 1/25/2019 11:54 AM, Elijah Newren wrote:
> > +test_expect_success '--combined-with-paths works with -z as well' '
> > + printf "0f9645804ebb04cc3eef91f799eb7fb
ned-off-by: Elijah Newren
---
Differences since v1: added a testcase, with and without -z
Documentation/diff-format.txt | 23 +---
Documentation/git-diff-tree.txt| 9 +--
Documentation/rev-list-options.txt | 5
combine-diff.c
Hi,
On Fri, Jan 25, 2019 at 6:45 AM Derrick Stolee wrote:
>
> On 1/24/2019 11:46 AM, Elijah Newren wrote:
> > As an alternative, I considered perhaps trying to sell it as a bugfix
> > (how often do people use -M, -c, and --raw together and have renames
> > in merge comm
501 - 600 of 1788 matches
Mail list logo
