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 me
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 exist
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 tell
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 f
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
> > > > > full-bl
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
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
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, b
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 c
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
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 leanin
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
> > > --recreate-merg
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:
> >
>
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
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 _rebasing_
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 changes
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. Th
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.
>
> If
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 disc
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:
> >
>
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
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 di
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 comm
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 the
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 tha
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
> --preserve-merges.
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 c
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'
&g
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'
> # t
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 not
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 ha
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
> &
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 thin
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
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 comm
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 (https://github.com/git-for-wi
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
> >
> > [...]
> >
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 across
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/
>
> Signed-off-by: Phillip Wood
> ---
> Do
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 lines/
would make sense here,
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 is
> going to be reversed bef
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 recount fixes in [1]. The
> co
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
> >
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 t
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 b
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 proposal
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 any
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 branch
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'
> > - Remov
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 |
> > >|
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 witn
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]
> >
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 |
> > >|
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)
> > >| /
> > >
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 |
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)?
>
&g
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 |
> > >|
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'
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
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 |
> > >| /
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 |
>
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
> paren
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
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 perfor
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 "ref
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 is
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) modificatio
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 "from
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 commen
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 som
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" part...
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 the
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 && git
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
> Helped-by: Igor Djordjev
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
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
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 app
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 F
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
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` alon
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 pers
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 &&
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 o
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
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
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
> ""
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 i
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 a
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 the
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 c
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 taken
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 I
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
> > \|
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 c
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 Gi
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 want
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.
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)
>
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 to
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 i
1 - 100 of 138 matches
Mail list logo
