Re: Bring together merge and rebase

On Dec 27, 2017, at 06:35, Carl Baldwin wrote: > > On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote: >> >> My experience, from seeing these much more complex use cases --- >> starting with something as simple as the Linux Kernel Stable Kernel >> Series, and

Re: Bring together merge and rebase

On Dec 24, 2017, at 01:01, Johannes Schindelin wrote: > > Hi Carl, > > On Sat, 23 Dec 2017, Carl Baldwin wrote: > >> I imagine that a "git commit --amend" would also insert a "replaces" >> reference to the original commit but I failed to mention that in my >> original post. > > And

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)

On Dec 11, 2017, at 01:17, Igor Djordjevic wrote: > On 10/12/2017 13:22, Phillip Wood wrote: >> I understood Alexei to mean that it was merging the f!A into A that >> caused conflicts due to the fact that f!A has conflicting context >> that was introduced in B. After all B' the rebased B is merge

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)

On Dec 10, 2017, at 14:22, Phillip Wood wrote: > > I've found conflicts arising from moving fixups can be quite common, so > these days I tend to edit the commit to be fixed up directly. I have a > script git-amend that does something like > > target=$(git rev-parse --verify "$1") &&

Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

On Dec 9, 2017, at 01:54, Igor Djordjevic wrote: > On 08/12/2017 17:24, Junio C Hamano wrote: >> I'd rather do a quick fix-up on top (which ensures that at least the >> fix-up works in the context of the tip), and then "rebase -i" to >> move it a more appropriate place in the history (during which

Re: Remove help advice text from git editors for interactive rebase and reword

On 23 July 2017 at 13:03, Kirill Likhodedov wrote: > Hello, > > is it possible to remove the helping text which appears at the bottom > of the Git interactive rebase editor (the one with the list of > instructions) I believe currently there is not way to do it. The interactive rebase is

Re: Suggestion for the "Did you mean this?" feature

On 18 December 2016 at 14:18, Kaartic Sivaraam wrote: > Hello all, > > I have found the "Did you mean this?" feature of git as a very good > feature. I thought it would be even better if it took a step toward by > asking for a prompt when there was only one alternative to the command > that was

Re: [git rebase -i] show time and author besides commit hash and message?

> It would help especially when the commit message was written badly. > > Or it might be possible to customize just like "git log --format"? It is possible to change the format globally via config option rebase.instructionFormat: $ git config rebase.instructionFormat "%an (%ad): %s" The

Re: Is the entire working copy “at one branch”?

Hi Stefan, Generally with git, your entire working copy will have the same revision (set to current branch, aka HEAD). The idea behind this is that your working copy of a repository should always be in consistent state. You can check out specific files or directories from another revision

Re: Expanding Includes in .gitignore

> I'm thinking something like ". path/to/include/file" in an ignore file, > and/or creating .gitignore.d and/or allowing $HOME/.config/git/ignore > and $GIT_DIR/info/exclude to be directories. Or some sane and consistent > mixture of these things. I think the rc.d-like approach with directories

Re: An anomaly, not a bug

> Actually, git reads > > # comment > > as 'ignore files with name "" (4 spaces)', and then a comment. > It does not ignore the leading whitespace. Even not as a comment, it treats it as literally a filename with a hash and that comment in it. However, one (usually) does not name their

Re: An anomaly, not a bug

> Note: the comments can be started away from the left margin, > as normal in all unix-linux configuration files we know of. > Git follows this behaviour fine. Actually, git reads # comment as 'ignore files with name "" (4 spaces)', and then a comment. It does not ignore the leading