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

Hi Konstantin, On 21/08/2018 11:37, Konstantin Kharlamov wrote: > > > There's another possibility (and I think it is what happens > > actually in Konstantin's case): When one side added lines 1 2 and the > > other side added 1 2 3, then the actual conflict is > > << 1 2 == 1 2 3 >>, but our

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Stefan, On 08/05/2018 00:24, Stefan Beller wrote: > > > List, rename, delete -- all these seem more as basic CRUD operations, > > where comparison is a more complex one. And not to get me wrong - I > > could see "branch diff" being part of "branch", but not really when > > "diff" already

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Dscho, On 07/05/2018 03:34, Johannes Schindelin wrote: > > > > I think Todd's idea to shift it from a full-blown builtin to a cmdmode > > > of `branch` makes tons of sense. > > > > I don`t know, I still find it a bit strange that in order to "diff > > something", you go to "something" and

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

On 07/05/2018 09:48, Jeff King wrote: > > > > Let's, please, not fall into the trap of polluting git-branch with > > > utterly unrelated functionality, as has happened a few times with > > > other Git commands. Let's especially not do so merely for the sake of > > > tab-completion. git-branch is

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Dscho, On 06/05/2018 14:10, Johannes Schindelin wrote: > > > > > > This builtin does not do a whole lot so far, apart from showing a > > > > > usage that is oddly similar to that of `git tbdiff`. And for a > > > > > good reason: the next commits will turn `branch-diff` into a > > > > >

Re: [PATCH v2 05/18] branch-diff: also show the diff between patches

Hi Johannes, On 04/05/2018 17:34, Johannes Schindelin wrote: > Just like tbdiff, we now show the diff between matching patches. This is > a "diff of two diffs", so it can be a bit daunting to read for the > beginner. > > And just like tbdiff, we now also accept the `--no-patches` option > (which

Re: [PATCH v2 02/18] Add a new builtin: branch-diff

Hi Dscho, On 05/05/2018 23:57, Johannes Schindelin wrote: > > > > This builtin does not do a whole lot so far, apart from showing a > > > usage that is oddly similar to that of `git tbdiff`. And for a > > > good reason: the next commits will turn `branch-diff` into a > > > full-blown replacement

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

Hi Sergey, On 19/03/2018 06:44, Sergey Organov wrote: > > > > > > > Second side note: if we can fast-forward, currently we prefer > > > > > > that, and I think we should keep that behavior with -R, too. > > > > > > > > > > I agree. > > > > > > > > I'm admittedly somewhat lost in the discussion,

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

Hi Sergey, On 16/03/2018 08:31, Sergey Organov wrote: > > > > As I said, putting myself on the user side, I'd prefer entirely > > > separate first step of the algorithm, exactly as written, with > > > its own conflict resolution, all running entirely the same way as > > > it does with non-merge

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

On 15/03/2018 00:11, Igor Djordjevic wrote: > > > > > Second side note: if we can fast-forward, currently we prefer > > > > that, and I think we should keep that behavior with -R, too. > > > > > > I agree. > > > > I'm admittedly some

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

Hi Sergey, On 15/03/2018 08:52, Sergey Organov wrote: > > > > 2. The U1' == U2' consistency check in RFC that I still think is worth > > > to be implemented. > > > > At the moment, I think we`d appreciate test cases where it actually > > proves useful, as the general consensus seems to be

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

Hi Sergey, On 15/03/2018 07:00, Sergey Organov wrote: > > > > Thinking about it I've got an idea that what we actually need is > > > --no-flatten flag that, when used alone, will just tell "git rebase" to > > > stop flattening history, and which will be implicitly imposed by > > >

Re: [bug] git stash push {dir-pathspec} wipes untracked files

On 15/03/2018 17:52, Junio C Hamano wrote: > > > Hi, I ran into what I believe is a bug today. I’m using primarily Git > > for Windows 2.16.2 and also reproduced the behavior on Git for Windows > > 2.15.1 and Git 2.14.1 on Ubuntu: > > > > Given any repository with at least one subdirectory: > >

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

Hi Sergey, On 14/03/2018 08:21, Sergey Organov wrote: > > There are still 2 issues about the implementation that need to be > discussed though: > > 1. Still inverted order of the second merge compared to RFC. > > It'd be simple to "fix" again, except I'm not sure it'd be better, and > as there

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

On 14/03/2018 15:24, Sergey Organov wrote: > > > > Second side note: if we can fast-forward, currently we prefer that, and I > > > think we should keep that behavior with -R, too. > > > > I agree. > > I'm admittedly somewhat lost in the discussion, but are you talking > fast-forward on

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

Hi Sergey, On 13/03/2018 17:10, Sergey Organov wrote: > > > Hi Sergey, I've been following this discussion from the sidelines, > > though I haven't had time to study all the posts in this thread in > > detail. I wonder if it would be helpful to think of rebasing a merge as > > merging the

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Dscho, On 12/03/2018 11:20, Johannes Schindelin wrote: > > > > [...] and cannot introduce ambiguities when rebasing the > > > changes introduced by M (i.e. the "amendmendts" we talked about). > > > > Hmm, not following here, which ambiguities are we talking about? > > U1' vs U2' of course.

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

Hi Dscho, On 12/03/2018 11:46, Johannes Schindelin wrote: > > > Sometimes one just needs to read the manual, and I don`t really think > > this is a ton complicated, but just something we didn`t really have > > before (real merge rebasing), so it requires a moment to grasp the > > concept. > >

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

On 12/03/2018 13:56, Sergey Organov wrote: > > > > I agree with both of you that `pick ` is inflexible > > > (not to say just plain wrong), but I never thought about it like that. > > > > > > If we are to extract further mentioned explicit old:new merge > > > parameter mapping to a separate

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

Hi Dscho, On 12/03/2018 11:37, Johannes Schindelin wrote: > > > If we are to extract further mentioned explicit old:new merge > > parameter mapping to a separate discussion point, what we`re > > eventually left with is just replacing this: > > > > merge -R -C > > > > ... with this: > > >

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Dscho, On 11/03/2018 23:04, Igor Djordjevic wrote: > > I`m yet to read (and reason about) your whole (very informative) > reply, but I just wanted to address this part first, as it might be a > clear end-game situation already, due to a mutual agreement, all the > re

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Dscho, I`m yet to read (and reason about) your whole (very informative) reply, but I just wanted to address this part first, as it might be a clear end-game situation already, due to a mutual agreement, all the rest being purely academic, interesting, but not any more (that) important to

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Dscho, On 11/03/2018 16:47, Johannes Schindelin wrote: > > > > > Phillip's method is essentially merging the new tips into the original > > > > merge, pretending that the new tips were not rebased but merged into > > > > upstream. > > > > > > [...] > > > > > > Here`s a starting point, two

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

Hi Dscho, On 11/03/2018 13:11, Johannes Schindelin wrote: > > > > I did wonder about using 'pick ' for rebasing merges > > > and keeping 'merge ...' for recreating them but I'm not sure if that > > > is a good idea. It has the advantage that the user cannot specify the > > > wrong parents for

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

Hi Dscho, On 11/03/2018 13:08, Johannes Schindelin wrote: > > > Hmm, funny enough, `pick ` was something I though about > > originally, too, feeling that it might make more sense in terms on > > what`s really going on, but I guess I wanted it incorporated into > > `--recreate-merges` too much

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

Hi Dscho, On 11/03/2018 13:00, Johannes Schindelin wrote: > > > I actually like `pick` for _rebasing_ merge commits, as `pick` is > > already used for rebasing non-merge commits, too, so it feels natural. > > Phillip is right, though: this would repeat the design mistake of >

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On 08/03/2018 20:58, Igor Djordjevic wrote: > > > Phillip's method is essentially merging the new tips into the original > > merge, pretending that the new tips were not rebased but merged into > > upstream. > > [...] > > Here`s a starting point, two commit

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On 08/03/2018 21:27, Igor Djordjevic wrote: > > > git merge-recursive U1' -- M U2' > > tree="$(git write-tree)" > > # in case of original merge being octopus, we would continue like: > > # git merge-recursive $tree -- M U3' > > # t

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

On 08/03/2018 20:58, Igor Djordjevic wrote: > > git merge-recursive U1' -- M U2' > tree="$(git write-tree)" > # in case of original merge being octopus, we would continue like: > # git merge-recursive $tree -- M U3' > # tree="$(git

Re: [RFC v2] Rebasing merges: a jorney to the ultimate solution (Road Clear)

Hi Johannes, On 07/03/2018 15:08, Johannes Schindelin wrote: > > > > Didn't we settle on Phillip's "perform successive three-way merges > > > between the original merge commit and the new tips with the old tips > > > as base" strategy? > > > > It seems you did, dunno exactly why. > > That is

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

On 06/03/2018 12:45, Sergey Organov wrote: > > > > The only thing I wonder of here is how would we check if the > > > "rebased" merge M' was "clean", or should we stop for user amendment? > > > With that other approach Sergey described, we have U1'==U2' to test with. > > > > I think (though I

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

On 08/03/2018 16:16, Igor Djordjevic wrote: > > > Unless we reimplement the octopus merge (which works quite a bit > > differently from the "rebase merge commit" strategy, even if it is > > incremental, too), which has its own challenges: if there are merge > &

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

On 08/03/2018 13:16, Phillip Wood wrote: > > > Side note: I wonder whether we really need to perform the additional check > > that ensures that the refers to the rewritten version of the > > original merge commit's parent. > > > > [...] > > Oops that was referring to the first side note. I

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

Hi Phillip and Johannes, On 08/03/2018 12:20, Phillip Wood wrote: > > I did wonder about using 'pick ' for rebasing merges and > keeping 'merge ...' for recreating them but I'm not sure if that is a > good idea. It has the advantage that the user cannot specify the wrong > parents for the merge

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

Hi Dscho, On 07/03/2018 08:26, Johannes Schindelin wrote: > > > So, it could be something like: > > > > merge -C deadbee 123abc:cafecafe 234bcd:bedbedbed > > I like where this is heading, too, but I do not think that we can do this > on a per-MERGE_HEAD basis. The vast majority of merge

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

Hi Johannes, On 05/03/2018 18:29, Johannes Schindelin wrote: > > > By the way, is there documentation for `git merge-recursive` > > anywhere, besides the code itself...? :$ > > I am not aware of any. The commit message adding the command is not very > illuminating

Re: [PATCH v2 1/3] add -p: select individual hunk lines

On 06/03/2018 21:29, Igor Djordjevic wrote: > > > diff --git a/git-add--interactive.perl b/git-add--interactive.perl > > index f83e7450ad..a273b41e95 100755 > > --- a/git-add--interactive.perl > > +++ b/git-add--interactive.perl > > > > [...] > >

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

Hi Junio, On 06/03/2018 22:03, Junio C Hamano wrote: > > > A small nitpick - I see you use phrasing like "select lines", where > > the other commands usually talk about "staging", instead, so "stage > > lines" might be more aligned with the existing text. > > Isn't this machinery shared

Re: [PATCH v2 2/3] add -p: allow line selection to be inverted

On 06/03/2018 11:17, Phillip Wood wrote: > From: Phillip Wood > > If the list of lines to be selected begins with '^' select all the > lines except the ones listed. s/to be selected begins with '^' select all/to be staged begins with '^' stage all/ > >

Re: [PATCH v2 3/3] add -p: optimize line selection for short hunks

On 06/03/2018 11:17, Phillip Wood wrote: > From: Phillip Wood > > If there are fewer than ten changes in a hunk then make spaces > optional when selecting individual lines. This means that for short Not sure if using s/selecting individual lines/staging individual

Re: [PATCH v2 1/3] add -p: select individual hunk lines

On 06/03/2018 11:17, Phillip Wood wrote: > From: Phillip Wood > > When I end up editing hunks it is almost always because I want to > stage a subset of the lines in the hunk. Doing this by editing the > hunk is inconvenient and error prone (especially so if the patch

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

Hi Phillip, On 06/03/2018 11:17, Phillip Wood wrote: > > From: Phillip Wood > > I've added some documentation to git-add.txt for the new selection > mode and cleaned up some style issues, otherwise these are unchanged > since v1. These patches build on top of the

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

On 06/03/2018 19:12, Johannes Schindelin wrote: > > > > And I guess being consistent is pretty important, too - if you add new > > > content during merge rebase, it should always show up in the merge, > > > period. > > > > Yes, that should make it easy for the user to know what to expect from >

Re: [PATCH v5 00/12] rebase -i: offer to recreate merge commits

Hi Johannes, On 26/02/2018 22:29, Johannes Schindelin wrote: > > Once upon a time, I dreamt of an interactive rebase that would not > flatten branch structure, but instead recreate the commit topology > faithfully. > > My original attempt was --preserve-merges, but that design was so > limited

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

On 02/03/2018 19:14, Igor Djordjevic wrote: > > > > It is interesting to think what it means to faithfully rebase a '-s > > > ours' merge. In your example the rebase does not introduce any new > > > changes into branch B that it doesn't introduce to branch A. Had it

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

Hi Phillip, On 02/03/2018 12:31, Phillip Wood wrote: > > > Thinking about it overnight, I now suspect that original proposal had a > > mistake in the final merge step. I think that what you did is a way to > > fix it, and I want to try to figure what exactly was wrong in the > > original

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

Hi Phillip, > On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote: > > > > > It is interesting to think what it means to faithfully rebase a '-s > > > ours' merge. > > > > I should have explained that I mean is a faithful rebase one that > > adheres to the semantics of '-s ours' (i.e. ignores

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

Hi Phillip, On 02/03/2018 17:00, Jacob Keller wrote: > > > It is interesting to think what it means to faithfully rebase a '-s > > ours' merge. In your example the rebase does not introduce any new > > changes into branch B that it doesn't introduce to branch A. Had it > > added a fixup to

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

Hi Sergey, On 02/03/2018 06:40, Sergey Organov wrote: > > > So... In comparison to original merge commit M, rebased merge commit > > M' is expected to: > > > > - Add X9, from updated "master" > > - Have A1 changed to A12, due to A12 commit amendment > > - Keep A2, rebased as A2' > > -

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

Hi Sergey, On 01/03/2018 06:39, Sergey Organov wrote: > > > > (3) ---X1---o---o---o---o---o---X2 > > >|\ |\ > > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' > > >| \ | > > >| M | > > >|

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

On 28/02/2018 21:25, Igor Djordjevic wrote: > > But U1' and U2' are really to be expected to stay the same in > non-interactive rebase case only... Just to rephrase to "could be expected" here, meaning still not necessarily in this case, either - I`ve just witnessed non

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

Hi Sergey, On 28/02/2018 07:14, Sergey Organov wrote: > > > > Would additional step as suggested in [1] (using R1 and R2 to "catch" > > > interactive rebase additions/amendments/drops, on top of U1' and > > > U2'), make more sense (or provide an additional clue, at least)? > > > > > > [1] >

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

Hi Sergey, On 28/02/2018 06:19, Sergey Organov wrote: > > > > (3) ---X1---o---o---o---o---o---X2 > > >|\ |\ > > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' > > >| \ | > > >| M | > > >|

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

Hi Sergey, On 28/02/2018 06:44, Sergey Organov wrote: > > > > Here`s our starting position: > > > > > > (0) ---X1---o---o---o---o---o---X2 (master) > > >|\ > > >| A1---A2---A3 > > >| \ > > >| M (topic) > > >| / > > >

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

Hi Sergey, On 28/02/2018 06:21, Sergey Organov wrote: > > > > > > (3) ---X1---o---o---o---o---o---X2 > > > > >|\ |\ > > > > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' > > > > >| \ | > > > > >| M |

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

On 28/02/2018 03:12, Igor Djordjevic wrote: > > Would additional step as suggested in [1] (using R1 and R2 to "catch" > interactive rebase additions/amendments/drops, on top of U1' and > U2'), make more sense (or provide an additional clue, at least)? > > [1] &g

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

Hi Junio, On 28/02/2018 01:10, Junio C Hamano wrote: > > > > (3) ---X1---o---o---o---o---o---X2 > > >|\ |\ > > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' > > >| \ | > > >| M | > > >|

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

Hi Johannes, On 28/02/2018 00:27, Johannes Schindelin wrote: > > thank you for making this a lot more understandable to this thick > developer. Hehe, no problem, it primarily served fighting my own thickness ;) > > Finally, we drop temporary commits, and record rebased commits A3' > > and B3'

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

On 28/02/2018 02:33, Igor Djordjevic wrote: > > This seems to be working inside my (too trivial?) test case, for > interactive adding, dropping, and amending of rebased commits, > resulting "rebased" merge containing all the added/modified/dropped > changes, plus the

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

On 28/02/2018 01:36, Jacob Keller wrote: > > > > (3) ---X1---o---o---o---o---o---X2 > > >|\ |\ > > >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' > > >| \ | > > >| M | > > >| /

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

On 27/02/2018 20:59, Igor Djordjevic wrote: > > (3) ---X1---o---o---o---o---o---X2 >|\ |\ >| A1---A2---A3---U1 | A1'--A2'--A3'--U1' >| \ | >| M | >| /

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

On 27/02/2018 19:55, Igor Djordjevic wrote: > > It would be more along the lines of "(1) rebase old merge commit parents, > (2) generate separate diff between old merge commit and each of its > parents, (3) apply each diff to their corresponding newly rebased >

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

Hi Dscho, On 27/02/2018 17:21, Johannes Schindelin wrote: > > Do you have any way to describe the idea in a simple, 3-5 lines long > paragraph? > > So far, I just know that it is some sort of confusing criss-cross > cherry-picking and merging and stuff, but nothing in those steps > shouts out

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

Hi Sergey, On 16/02/2018 14:08, Sergey Organov wrote: > > By accepting the challenges raised in recent discussion of advanced > support for history rebasing and editing in Git, I hopefully figured out > a clean and elegant method of rebasing merges that I think is "The Right > Way (TM)" to

Re: [PATCH v2 10/14] commit-graph: add core.commitgraph setting

Hi Derrick, On 30/01/2018 22:39, Derrick Stolee wrote: > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 0e25b2c92b..5b63559a2b 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -898,6 +898,9 @@ core.notesRef:: > This setting defaults to

Re: git stash ; git stash pop unstages all staged changes

Hi Marten, On 30/01/2018 11:05, Martin Häcker wrote: > > I just lost quite some work, because `git stash; git stash pop` > doesn’t seem to understand the concept of the index correctly. I`m afraid it actually seems you`re not fully understanding how `git stash pop` works - but the good news

Re: [BUG] git pull with pull.rebase and rebase.autoStash is not working anymore in 2.16

Hi Dimitriy, On 24/01/2018 13:19, Dimitriy wrote: > > Looks like regression in 2.16. > Worked fine before update. > Seems like git stash is not always working. > Any ideas? Could this be the same one as reported as Git for Windows issue #1437[1] ("`git status` reports (non-existent)

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

p.s. An extra note for the casual reader, just in case: On 28/12/2017 01:50, Igor Djordjevic wrote: > > ... it totally slipped me that documentation is/was pretty strict > about being HEAD path (exclusively), where I was still > expecting it to show renamed working tree

Re: [PATCH v3 0/6] Renames in git-status "changed not staged" section

Hi Duy, On 27/12/2017 11:18, Nguyễn Thái Ngọc Duy wrote: > > v3 more or less goes back to v1 after my discussion with Igor about > porcelain formats. So 7/7 is not needed anymore. 4/7 becomes 5/6. The > meat is still in 6/6, now with some more updates in git-status.txt and > to address the

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

On 27/12/2017 02:06, Duy Nguyen wrote: > > > ... > > > >The pathname. In a renamed/copied entry, this > > is the path in the index and in the working tree. > > Gaah.. as you may see in the other mail when I quoted this > (incorrectly). I must have modified this file at

Re: [PATCH v2 7/7] wt-status.c: avoid double renames in short/porcelain format

On 27/12/2017 01:49, Duy Nguyen wrote: > > > I lost you a bit here, partially because of what seems to be an > > incomplete setup script, partially because of this last sentence, as > > Git v2.15.1 doesn`t seem to be showing this, so not sure about "like > > we have been showing until now"

Re: Bring together merge and rebase

Very interesting topic, just this one part I wanted to comment on: On 26/12/2017 02:28, Jacob Keller wrote: > > What about some way to take the reflog and turn it into a commit-based > linkage and export that? Rather than tying it into the individual > commit history, keep track of it outside

Re: [PATCH v2 7/7] wt-status.c: avoid double renames in short/porcelain format

Hi Duy, On 26/12/2017 10:10, Nguyễn Thái Ngọc Duy wrote: > > The presence of worktree rename leads to an interesting situation, > what if the same index entry is renamed twice, compared to HEAD and to > worktree? We can have that with this setup > > echo first > first && git add first &&

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

PS. The reader may notice that this patch adds a new xstrdup() but not > a free(). Yes we leak memory (the same for head_path). But wt_status > so far has been short lived, this leak should not matter in > practice. > > Noticed-by: Alex Vandiver <ale...@dropbox.com> > Helped-by: Igor

Re: [PATCH] status: handle worktree renames

On 25/12/2017 20:45, Igor Djordjevic wrote: > > I guess an additional test for this would be good, too. ... aaand here it is. Again based on your test, but please double check, I`m not sure if it`s ok to compare file modes like that, expecting them to be the same (hashes should be f

Re: [PATCH] status: handle worktree renames

On 25/12/2017 19:26, Igor Djordjevic wrote: > > But I`ve noticed that "--porcelain=v2" output might still be buggy - > this is what having both files staged shows: > > $ git status --porcelain=v2 > 2 R. N... 100644 100644 100644 12f00e90b6ef

Re: [PATCH] status: handle worktree renames

Hi Duy, On 25/12/2017 11:37, Nguyễn Thái Ngọc Duy wrote: > Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist > in index" - 2016-10-24) there are never "new files" in the index, which > essentially disables rename detection because we only detect renames > when a new file

Re: Need help migrating workflow from svn to git.

Hi Josef, On 20/12/2017 12:43, Josef Wolf wrote: > >> $ git add -u >> $ git reset > > This would be added after the "git checkout -m -B master FETCH_HEAD" > command? Yes, so it would be something like this: git fetch origin master && #1 git checkout -m -B master

Re: [PATCH v2 1/5] core.aheadbehind: add new config setting

Hi Jeff, On 21/12/2017 20:09, Jeff Hostetler wrote: > > diff --git a/Documentation/config.txt b/Documentation/config.txt > index 9593bfa..c78d6be 100644 > --- a/Documentation/config.txt > +++ b/Documentation/config.txt > @@ -895,6 +895,14 @@ core.abbrev:: > abbreviated object names to stay

Re: feature-request: git "cp" like there is git mv.

Hi Simon, On 12/12/2017 11:53, Simon Doodkin wrote: > > please develop a new feature, git "cp" like there is git mv > tomovefile1 tofile2 (to save space). > > there is a solution in https://stackoverflow.com/a/44036771/466363 > however, it is not single easy command. While having `git cp`

Re: Need help migrating workflow from svn to git.

On 15/12/2017 20:09, Junio C Hamano wrote: > > > Junio, what about consecutive runs, while merge conflicts are still > > unresolved? > > The impression I got was that the original running with svn does not > deal with conflicting situation anyway, so I did not think about it > at all, and I

Re: Need help migrating workflow from svn to git.

onflicts were still in, but it might be worth it in this specific case, conflicting parts still easily visible between conflict markers. Regards, Buga [1] On 15/12/2017 19:24, Igor Djordjevic wrote: > > git checkout -b temp && #1 > git fetch &&

Re: Need help migrating workflow from svn to git.

Hi Josef, Thank you for your patient answers. From what you said here and in that other reply[1], it looks like you know what you`re doing, you`re aware of circumstances, and you still prefer doing it that way. So, here it goes... :) On 15/12/2017 13:47, Josef Wolf wrote: > > > I`m thinking

Re: Need help migrating workflow from svn to git.

On 14/12/2017 23:27, Igor Djordjevic wrote: > > As you basically have a flow where two users (you and cron job) can > edit same files at the same time, desired outcome might be a bit > ambiguous, especially when scheduled execution of those files is > added to the mix. This sa

Re: Need help migrating workflow from svn to git.

Hi Josef, I`m not a Git expert, and I know less of Subversion, but following your explanation, I might try to help, at least until more experienced people join. On 14/12/2017 14:09, Josef Wolf wrote: > > Every machine has a working copy of the repository in a specific > directory. A cron job

Re: Apparent bug in 'git stash push ' loses untracked files

Hi Thomas, On 14/12/2017 00:14, Thomas Gummerer wrote: > > > For what it`s worth, using `git stash save ` instead seems > > to (still) work as expected... > > I think that depends on what you expect ;) 'git stash save ' > will create a stash of the whole working directory with the message >

Re: Apparent bug in 'git stash push ' loses untracked files

Hi Reid, On 13/12/2017 18:32, Reid Price wrote: > > When running 'git stash push ' if there are both tracked and > untracked files in this subdirectory, the tracked files are stashed > but the untracked files are discarded. I can reproduce this as well (git version 2.15.1.windows.2). For what

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

Hi Philip, On 10/12/2017 13:22, Phillip Wood wrote: > > Sorry I should have been clearer. The point I was somewhat obliquely > making was that 'rebase --onto' succeeds where 'rebase --autosquash' > fails not because it is smarter but because it is doing something > different. Specifically it

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

Hi Philip, On 09/12/2017 20:01, Phillip Wood wrote: > > > But thanks for clarifying, anyway, it does feel like `git rebase > > -i --autosquash` could be smarter in this regards, if `git rebase > > --onto` does it better...? > > Creating the fixup directly on A rather than on top of B avoids

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

Hi Alexei, On 09/12/2017 03:18, Alexei Lozovsky wrote: > > > Chris reported in this very topic[1] that sometimes, due to > > conflicts with later commits, "checkout > commit > [checkout >] > > rebase --onto" is "much easier to do", where "commit --fixup > > > rebase -i" "breaks" (does not apply

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

On 08/12/2017 17:24, Junio C Hamano wrote: > > > To get back on track, and regarding what`s already been said, > > would having something like this(1) feel useful? > > > > (1) git commit --onto > > Are you asking me if _I_ find it useful? It is not a very useful > question to ask, as I've

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

On 06/12/2017 19:34, Johannes Sixt wrote: > > I am sorry for not responding in detail. I think we've reached a > mutual understanding of our workflows. No problem, thanks for your time so far. There might be one more thing I should address, possibly left unclear from my previous message, but

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

Hi Hannes, On 01/12/2017 18:23, Johannes Sixt wrote: > > > To work with `--onto-parent` and be able to commit on top of any of > > the topic branches, you would need a situation like this instead: > > > > (1) ...C <- topic C > > | > > ...A | <- topic A > > \|

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

Hi Chris, On 30/11/2017 23:40, Chris Nerwert wrote: > > I'm actually doing the described workflow quite often with git rebase > when working on a topic. Given the following structure: > > ---o (master) > \ >o---A---B---C (topic) > > When I want to make changes to

Re: [ANNOUNCE] Git for Windows 2.15.1

Hi Johannes, On 29/11/2017 14:57, Johannes Schindelin wrote: > > * It is now possible to configure nano or Notepad++ as Git's > default editor instead of vim. This seems as a really nice option, as it could\should greatly help Windows people in lowering friction in first encounter with

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

Hi Hannes, On 29/11/2017 20:11, Johannes Sixt wrote: > > Ok, then please explain, how this process should work in my workflow > and with the `commit --onto-parent` feature that you have in mind. I > have an integration branch (which is a throw-away type, so you can > mangle it in any way you

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

Hi Johannes, On 27/11/2017 22:54, Johannes Sixt wrote: > > I my opinion, putting the focus on integration merge commits and the > desire to automate the re-merge step brings in a LOT of complexity in > the implementation for a very specific use-case that does not > necessarily help other cases.

[SCRIPT/RFC 1/3] setup.sh

On 26/11/2017 23:35, Igor Djordjevic wrote: > > This is what we end up with once "master" and topic branches are > merged in merge commit M1 inside temporary "test" branch for further > integration testing: > > (2)o---o---A (topicA) >

[SCRIPT/RFC 2/3] git-merge-one-file--cached

Original "git-merge-one-file" script is slightly tweaked here into "git-merge-one-file--cached"[*1*] to allow (still trivial) _index-only_ three-way file merge, not touching files inside working tree. Proof of concept, not thoroughly tested, original content left in, commented out. Feel free

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

Hi to all, Here`s my humble attempt on (once more) scratching a use case which seems to be desired occasionally through the years, obviously not enough to be actually implemented yet, but might be worth some more attention... :) For the reference, some past mentions of (more or less) similar

  1   2   >