[RFE] Allow for "interactive"-like actions in non-interactive rebase

2019-05-03 Thread Konstantin Kharlamov
Interactive rebase (i.e. for example "git rebase -i HEAD~10") is used most often to apply an action to a single commit, e.g. "rename", "edit", "fixup", etc… As result, people keep coming up with custom scripts and aliases for every distinct action. Instead, it would be nice to have native su

Re: [RFE] Allow for "interactive"-like actions in non-interactive rebase

2019-05-06 Thread Konstantin Kharlamov
On Пн, May 6, 2019 at 18:25, Eric Sunshine wrote: On Mon, May 6, 2019 at 4:30 PM Emily Shaffer wrote: On Fri, May 03, 2019 at 06:04:15PM +0300, Konstantin Kharlamov wrote: > Interactive rebase (i.e. for example "git rebase -i HEAD~10") is used most > often to appl

Any way to make git-log to enumerate commits?

2018-12-05 Thread Konstantin Kharlamov
It would be great if git-log has a formatting option to insert an index of the current commit since HEAD. It would allow after quitting the git-log to immediately fire up "git rebase -i HEAD~index" instead of "git rebase -i go-copy-paste-this-long-number-id".

Re: [PATCH] worktree add: sanitize worktree names

2019-02-21 Thread Konstantin Kharlamov
On Чт, Feb 21, 2019 at 2:00 PM, =?UTF-8?b?Tmd1eeG7hW4gVGjDoWkgTmfhu41j?= Duy wrote: Worktree names are based on $(basename $GIT_WORK_TREE). They aren't significant until 3a3b9d8cde (refs: new ref types to make per-worktree refs visible to all worktrees - 2018-10-21), where worktree name coul

Re: [PATCH] worktree add: sanitize worktree names

2019-02-21 Thread Konstantin Kharlamov
On Чт, Feb 21, 2019 at 2:38 PM, Duy Nguyen wrote: On Thu, Feb 21, 2019 at 6:28 PM Konstantin Kharlamov wrote: On Чт, Feb 21, 2019 at 2:00 PM, =?UTF-8?b?Tmd1eeG7hW4gVGjDoWkgTmfhu41j?= Duy wrote: > Worktree names are based on $(basename $GIT_WORK_TREE). They aren't >

Do not raise conflict when a code in a patch was already added

2018-08-20 Thread Konstantin Kharlamov
So, steps-to-reproduce below rather full of trivia like setting up a repo, but the TL;DR is: Upon using `git rebase -i HEAD~1` and then `git add -p` to add part of a "hunk" as one commit, and then using `git rebase --continue` so the other part of hunk would be left in top commit; git raises a co

Re: Do not raise conflict when a code in a patch was already added

2018-08-21 Thread Konstantin Kharlamov
On 20.08.2018 22:22, Johannes Sixt wrote: Am 20.08.2018 um 19:40 schrieb Phillip Wood: On 20/08/2018 11:22, Konstantin Kharlamov wrote: It's spectacular, that content of one of inserted conflict markers is empty, so all you have to do is to remove the markers, and use `git add` on the