Phil Hord wrote:
> If I follow the latter advice about 'rm -rf', who will remember that
> 'rebase' had something stashed, and what will they do with it when
> they do?
>
> What if it is weeks or months later? I would be surprised to see
> long-forgotten wip show up in my workspace all of a sudden.
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> If it is 0 (which means that the rebase completely successfully), pop
>> the stash before exiting as usual.
>
> And you're going to pop the stash even if no stash were triggered when
> starting the rebase.
>
> Really, think about it again:
On Tue, Apr 16, 2013 at 5:20 AM, Ramkumar Ramachandra
wrote:
> Matthieu Moy wrote:
> No. Ultimately, the entry point of all these invocations is
> git-rebase.sh. The plan is to refactor calls from git-rebase.sh to
> git-rebase--*.sh scripts so that those scripts return control to
> git-rebase.sh
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> Yes, touching a simple "autostash" file at stash-time, and removing it
>> at pop-time will do. I don't see why it should be part of a
>> (potentially user-editable) todo-list, which serves an entirely
>> different purpose.
>
> You'll have
Ramkumar Ramachandra writes:
> Yes, touching a simple "autostash" file at stash-time, and removing it
> at pop-time will do. I don't see why it should be part of a
> (potentially user-editable) todo-list, which serves an entirely
> different purpose.
You'll have to apply the index state and the
Matthieu Moy wrote:
> And you're going to pop the stash even if no stash were triggered when
> starting the rebase.
>
> Really, think about it again: you're not going to guess whether you have
> to unstash without storing this information somewhere. You may argue
> about storing it outside the todo
Ramkumar Ramachandra writes:
> If it is 0 (which means that the rebase completely successfully), pop
> the stash before exiting as usual.
And you're going to pop the stash even if no stash were triggered when
starting the rebase.
Really, think about it again: you're not going to guess whether y
Matthieu Moy wrote:
> Because "git rebase" needs multiple runs in case of conflicts. You have
> to store the information somewhere in the filesystem, not in a variable.
> What you need to store is whether you need to unstash, and where you are
> in the process (in Junio's version, you may be doing
Ramkumar Ramachandra wrote:
> "If there were uncommitted worktree changes present when the merge
> started, git merge --abort will in some cases be unable to reconstruct
> these changes. It is therefore recommended to always commit or stash
> your changes before running git merge."
>
> Matthieu (a
Jonathan Nieder wrote:
> I wouldn't be surprised if there's still a documentation bug, though:
> a lack of clarity, a missing hint somewhere else, something else
> misleading. That seems especially likely when you say "I trusted the
> documentation on this one". Care to point to the appropriate s
Ramkumar Ramachandra wrote:
> Matthieu Moy wrote:
>> No, you don't. Just try if you're not convinced:
>
> Oh, I trusted the documentation on this one and never tried with a
> dirty worktree myself. Please fix the documentation, if you know how
> exactly to correct it.
The manual says:
"
Matthieu Moy wrote:
> Junio C Hamano writes:
>> Yes, that is why I said for pull-merge, --authsquash is neutral-to-better
>> and pull.autosquash is harmful.
>
> To speak from my experience: I find myself typing "git stash && git pull
> && git stash pop" relatively often.
To that end, maybe "git
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> If "rebase -m" were to be taught to do this, the natural way to do
>> so is to
>>
>> (1) Prepare the todo the usual way
>> (2) Do those two commits for index and working tree
>> (3) Append two insns (exec reset HEAD^ and exec reset --s
On Mon, Apr 15, 2013 at 11:38:20PM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
> > If "rebase -m" were to be taught to do this, the natural way to do
> > so is to
> >
> > (1) Prepare the todo the usual way
> > (2) Do those two commits for index and working tree
> > (3) Append t
Junio C Hamano wrote:
> If "rebase -m" were to be taught to do this, the natural way to do
> so is to
>
> (1) Prepare the todo the usual way
> (2) Do those two commits for index and working tree
> (3) Append two insns (exec reset HEAD^ and exec reset --soft
> HEAD^) at the end of the re
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> git-rebase --autostash
>>
>> git commit --allow-empty -m 'index part'
>> git commit --allow-empty -a -m 'working tree part'
>> git rebase --onto $UPSTREAM
>> git reset H
John Keeping wrote:
> Why restrict it to non-interactive? I'd find it useful when doing
> interactive rebases as well - consider the case when you simply want to
> re-order some commits.
Actually, I made a mistake: it should be doable for any specific
rebase (includes rebase--interactive, rebase-
On Mon, Apr 15, 2013 at 10:15:54PM +0530, Ramkumar Ramachandra wrote:
> Junio's criticism of pull.autostash hurting pull-merge people is
> cogent; my current plan is to ditch pull.autostash altogether, and
> implement rebase.autostash for the reduced case of a non-interactive
> rebase.
Why restric
Matthieu Moy wrote:
> No, they don't. Git forbids redefining commands with aliases. They may
> have an alias like "git pullauto" or so, but not "git pull".
Ofcourse, but you get the point. I use p for push, and pu for pull myself.
> There's not much we can do about it now, as Git cannot guess w
Matthieu Moy wrote:
> No, you don't. Just try if you're not convinced:
Oh, I trusted the documentation on this one and never tried with a
dirty worktree myself. Please fix the documentation, if you know how
exactly to correct it.
> No, I'm not proposing to do anything for merge. There's no reaso
Junio C Hamano wrote:
> git-rebase --autostash
>
> git commit --allow-empty -m 'index part'
> git commit --allow-empty -a -m 'working tree part'
> git rebase --onto $UPSTREAM
> git reset HEAD^
> git reset --soft
Junio C Hamano wrote:
> By tempting the user to use autostash first, you are forcing the
> user to say "reset --hard" (the first one), "ORIG_HEAD" (to start
> from the pre-pull state), "stash pop" (to recover the autostashed
> WIP), to a user who got conflict during "stash pop" after the pull
> int
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> Matthieu Moy wrote:
>>> AFAICT, "git merge --abort" is an alias for "git reset --merge"
>>
>> Yes, that is correct.
>>
>>> which
>>> was precisely designed to reset only modifications comming from a merge,
>>> and not the local changes tha
Ramkumar Ramachandra writes:
> Matthieu Moy wrote:
>> I disagree. A configuration option is something you set once, and then
>> forget about. A command, or a command-line option, is something you
>> explicitely add when you need it.
>
> You're making it out to be a much bigger difference than it
Ramkumar Ramachandra writes:
> Matthieu Moy wrote:
>> AFAICT, "git merge --abort" is an alias for "git reset --merge"
>
> Yes, that is correct.
>
>> which
>> was precisely designed to reset only modifications comming from a merge,
>> and not the local changes that were present before the merge wa
Matthieu Moy writes:
> I think you're taking it the wrong way. You seem to insist that
> autostash should be a pull feature. I think it should be a feature of
> merge and rebase, and the convenience script "git pull" should expose
> them to the user.
>
> I see no reason to prevent users running f
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> In the end, simple cases (the canonical example being Linus keeping
>> a local change to "Name = Unicycling Gorilla" in his Makefile while
>> running dozens of "git pull" every day) would not be helped with
>> this feature very much because
Ramkumar Ramachandra wrote:
> Okay, so you're proposing a uniform --autostash feature for both merge
> and rebase. Sorry, I didn't get it last time due to the typos in your
> email; yeah, this is worth investigating.
So, I thought about this and have concluded that pull is the Right
place for aut
Matthieu Moy wrote:
> I disagree. A configuration option is something you set once, and then
> forget about. A command, or a command-line option, is something you
> explicitely add when you need it.
You're making it out to be a much bigger difference than it actually
is. Users will simply alias p
Matthieu Moy wrote:
> AFAICT, "git merge --abort" is an alias for "git reset --merge"
Yes, that is correct.
> which
> was precisely designed to reset only modifications comming from a merge,
> and not the local changes that were present before the merge was
> started. The man pages are relatively
Ramkumar Ramachandra writes:
> First, this is not why Junio said pull.autostash is harmful: he had a
> completely different objection.
Yes. This is another objection.
> Second, this makes no sense. The user consciously made the decision
> to set pull.autostash to true
... possibly a long time
Ramkumar Ramachandra writes:
> In the pull-merge case, maybe: if your worktree isn't clean, you lose
> a lot of goodies like merge --abort anyway, and I hate that.
AFAICT, "git merge --abort" is an alias for "git reset --merge" which
was precisely designed to reset only modifications comming fro
Matthieu Moy wrote:
> I tend to agree that pull.autostash is harmful. At least in its current
> form, it is really too easy to overlook the "Please run 'git stash pop'
> after commiting the conflict resolution." message:
>
>
> $ git pull
>
> $ git status
>
> $ git commit
>
First, this is not w
Matthieu Moy wrote:
> Isn't this too pessimistic? If the local changes do not overlap (in
> terms of files) with the pulled changes, then autosquash is not needed.
>
> There should be a test for the case of non-overlapping changes.
In the pull-rebase case, no; it is not too pessimistic.
In the pu
Junio C Hamano wrote:
> In the end, simple cases (the canonical example being Linus keeping
> a local change to "Name = Unicycling Gorilla" in his Makefile while
> running dozens of "git pull" every day) would not be helped with
> this feature very much because there is rarely overlap, while in a
>
Junio C Hamano writes:
> Yes, that is why I said for pull-merge, --authsquash is neutral-to-better
> and pull.autosquash is harmful.
To speak from my experience: I find myself typing "git stash && git pull
&& git stash pop" relatively often. Typical use-case: I start working on
something, a coll
Matthieu Moy writes:
> Ramkumar Ramachandra writes:
>
>> +stash_required () {
>> +! (git diff-files --quiet --ignore-submodules &&
>> +git diff-index --quiet --cached HEAD --ignore-submodules)
>> +}
>
> Isn't this too pessimistic? If the local changes do not overlap (in
> terms of files)
Ramkumar Ramachandra writes:
> +stash_required () {
> + ! (git diff-files --quiet --ignore-submodules &&
> + git diff-index --quiet --cached HEAD --ignore-submodules)
> +}
Isn't this too pessimistic? If the local changes do not overlap (in
terms of files) with the pulled changes, then au
Ramkumar Ramachandra writes:
> Currently, executing a 'git pull' on a dirty worktree gives the
> following annoying message:
s/annoying//;
In general, avoid forcing your value judgement to readers when you
do not have to. Instead, you can just highlight the source of your
annoyance and let the
39 matches
Mail list logo
