When git status recurses a directory that isn't readable (but
executable), it should print out a warning/error. Currently, if there
are untracked files in these directories, git wouldn't be able to
discover them. Ideally, git status should return a non-zero exit
code as well.
The problem seems to
(Andrew Wong Cc'ed).
but then the generic message is not of much help either. Since this
lack of information affects the built-in git commands for commit,
merge and cherry-pick first, the solution would be to keep track of
the failed hooks in their output so that the user knows which of her
On Thu, Jul 10, 2014 at 12:35 PM, Fabian Ruch baf...@gmail.com wrote:
That is still taken care of by exit_with_patch here.
Oh, that's right. Ok, go ahead and remove the third warning then. Thanks!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Mon, Mar 17, 2014 at 7:04 PM, Junio C Hamano gits...@pobox.com wrote:
Has this series been tested with existing test suite? I tentatively
queued it to 'pu' but then had to revert because many tests started
failing, causing me to redo the today's integration cycle for 'pu'
once again.
I
On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud marcn...@xiplink.com wrote:
I know this approach was suggested earlier, but given these dangers it seems
silly to give this big warning on a plain git reset but still go ahead and
do the things the warning talks about.
Is there any issue with
On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Suppose developer send 10 patches on branch1 where are changes in terms
of dir_version/ then I need to apply on my local repo branch1, till now
is fine then I need to apply same 10 patches on to my branch2 where source
On Fri, Mar 14, 2014 at 4:01 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
On Sat, Mar 15, 2014 at 12:48 AM, Andrew Wong andrew.k...@gmail.com wrote:
On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Suppose developer send 10 patches on branch1 where are changes
On Fri, Mar 14, 2014 at 4:55 PM, Junio C Hamano gits...@pobox.com wrote:
For the users that really did mean --merge, the warning is silly.
It's basically saying We know that you're about to mess up your work
tree, but we let you mess up anyway. Learn the correct way so that you
don't mess up
On Fri, Mar 14, 2014 at 4:57 PM, Jagan Teki jagannadh.t...@gmail.com wrote:
Mr.J git cherry-pick -X subtree=foo
cc70089614de16b46c08f32ea61c972fea2132ce
14e9c9b20e3bf914f6a38ec720896b3d67f94c90
error: could not apply cc70089... A
hint: after resolving the conflicts, mark the
This is mainly changing messages that say:
run git foo --bar
to
use git foo --bar to baz
Although the commands and flags are usually self-explanatory, this is
more consistent with other status messages, and gives some sort of
explanation to the user.
Signed-off-by: Andrew Wong andrew.k
Print message during git merge and git status.
Add a new mergeHints advice to silence these messages.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
Documentation/config.txt | 3 +++
advice.c | 2 ++
advice.h | 1 +
builtin/merge.c | 6 ++
wt
error out when used in the middle of a merge. For now,
we simply print out a warning to the user.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
builtin/reset.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/builtin/reset.c b/builtin/reset.c
index 4fd1c6c..04e8103
work tree from becoming a
mess.
Andrew Wong (3):
wt-status: Make status messages more consistent with others
merge: Advise user to use git merge --abort to abort merges
reset: Print a warning when user uses git reset during a merge
Documentation/config.txt | 3 +++
advice.c
On 02/26/14 15:53, Junio C Hamano wrote:
- start warning against reset (no mode specifier) and reset --mixed
when the index is unmerged *and* MERGE_HEAD exists; and then
Why do we also want to check if index is unmerged? This situation can
happen regardless of having conflicts or not
On Wed, Feb 26, 2014 at 3:38 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Andrew Wong wrote:
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -909,7 +909,8 @@ static int suggest_conflicts(int renormalizing)
fclose(fp);
rerere(allow_rerere_auto);
printf(_(Automatic merge
On Wed, Mar 5, 2014 at 1:29 PM, Junio C Hamano gits...@pobox.com wrote:
If the user said git merge while another git merge is still
outstanding, we would want to say You have not concluded your
previous merge and die, and you presumably want to add the same
how to abort message there. Such a
more user-friendly during a merge.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
builtin/reset.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 6004803..740263d 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -318,7
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
builtin/merge.c | 3 ++-
wt-status.c | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index e576a7f..07af427 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -909,7 +909,8
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 4e55810..6e1ad7d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -899,7 +899,7 @@ static void show_merge_in_progress(struct wt_status
update it if we decide to use this new behavior.
Comments?
Andrew Wong (3):
wt-status: Make conflict hint message more consistent with other hints
merge: Add hints to tell users about git merge --abort
reset: Change the default behavior to use --merge during a merge
builtin/merge.c | 3
On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
But this breaks backward compatibility.
I sometimes run git reset during a merge to only reset the index and
then examine the changes introduced by the merge. With your changes,
someone doing so would abort the
On Wed, Feb 26, 2014 at 3:37 PM, Junio C Hamano gits...@pobox.com wrote:
I see that you are trying to match the phrasing used in the other
side of this if/else (which is outside the context of the posted
patch). Over there we say ... to conclude merge while the new
text says ... to conclude
On Wed, Feb 26, 2014 at 3:38 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Seems reasonable, but I worry about the command growing too noisy.
Could this be guarded by an advice.something setting? (See advice.*
in git-config(1) for what I mean.)
Ah, good idea. This seems to belong to
On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder jrnie...@gmail.com wrote:
I really don't like the idea of making git reset modal, though. I'd
rather that reset --mixed print some advice about how to recover from
the mistake, which would also have the advantage of allowing scripts
that for
On Wed, Feb 26, 2014 at 3:57 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
If you were to design git reset's interface from scratch, your
proposal would make sense. But we're talking about a change, and you
can't expect that users never use the current behavior. At the very
least, there
Detect a cherry-pick merge if there's only one parent and the git-svn-id
metadata exists. Then, get the parent's mergeinfo and merge this commit's
mergeinfo.
---
git-svn.perl | 52 +--
t/t9161-git-svn-mergeinfo-push.sh | 30
Instead of always storing mergeinfo at the root, give an option to store the
merge info in a subdirectory. The subdirectory must exist before we try to set
its property.
---
git-svn.perl | 21 +++--
perl/Git/SVN/Editor.pm| 5 -
that information in
svn:mergeinfo. These patches will enable git-svn to do the same.
Andrew Wong (3):
git-svn: Generate mergeinfo for every commit
git-svn: Support cherry-pick merges
git-svn: Add config to control the path of mergeinfo
git-svn.perl | 79
The previous behavior would only generate mergeinfo once using the first
commit, and use that mergeinfo for all remaining commits. The new behavior will
generate it once for every commit.
---
git-svn.perl | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl
can ensure the diff output has no
color codes in it.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
builtin/add.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/builtin/add.c b/builtin/add.c
index f45d9d4..8266a9c 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -343,6 +343,7 @@ static
Sorry for the late reply. I was able to reproduce the problem that you
were describing a while ago. And your patch indeed fixes it. It's a much
more elegant way of dealing with the absolute vs relative path problem
that I was trying to fix.
Thanks!
As for Pat, I'm not sure wha'ts going on with
On 3/19/13, Ramkumar Ramachandra artag...@gmail.com wrote:
I know that this is expected behavior, but is there an easy way to get
rid of this inconsistency?
You can actually rely on rebase to run the appropriate command. In
the first edit commit (the_
no conflict one), I usually run only git
On 3/10/13, Max Horn m...@quendi.de wrote:
I did run
touch lib/*.* src/*.* git update-index --refresh git diff-files
a couple dozen times (the problematic files where in src/ and lib), but
nothing happened. I just re-checked, and the rebase still fails in the same
why...
Perhaps I
On 3/11/13, Max Horn m...@quendi.de wrote:
So I tried this:
git rebase branches/stable-4.6 # ... which leads to the error
git ls-files -m
but got nothing. Perhaps you had something else in mind, though, but I am
not quite sure what... sorry for being dense, but if you let me know what
On 3/11/13, Max Horn m...@quendi.de wrote:
PS: Just as a side note, I should mention that I have done tons of rebases
on various repositories on this very machine: same hard drive, same file
system; the git version of course has changed over time, but as I already
described, I can reproduce
On 3/11/13, Max Horn m...@quendi.de wrote:
Looking at the git config man page to check what each of my config settings
does, I discovered trustctime. And adding
trustctime = false
to .git/config made the rebase work, every single time. Huh.
Adding this to the fact that a clone works
On 03/11/13 20:29, Max Horn wrote:
sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist
- this exits revisiond, and prevents launchd from respawning it. After that,
the problem is gone, on several attempts. And once I reactivate revisions,
the problem reoccurs.
So
On 03/11/13 21:01, Jeff King wrote:
From git help config:
core.trustctime
If false, the ctime differences between the index and the working
tree are ignored; useful when the inode change time is regularly
modified by something outside Git (file system crawlers and some
On 03/09/13 13:32, Andrew Wong wrote:
Yea, that's really suspicious. This could mean there's an issue with
when git is checking the index. Try running these a couple times in a
clean work tree:
$ git update-index --refresh
$ git diff-files
In a clean work tree, these commands should
The previous code was assuming length ends at either ) or ,, and was
not handling the case where strcspn returns length due to end of string.
So specifying :(top as pathspec will cause the loop to go pass the end
of string.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
setup.c | 6
The previous code allowed the ) to be optional.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
setup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/setup.c b/setup.c
index f4c4e73..5ed2b93 100644
--- a/setup.c
+++ b/setup.c
@@ -225,8 +225,9 @@ static const char
On 3/8/13, Max Horn m...@quendi.de wrote:
All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
journaling, not case sensitive (the default)) might be at fault. Still, this
is quite puzzling and annoying, and so I still wonder if anybody has any
insights on this.
When rebase
On 3/8/13, Max Horn m...@quendi.de wrote:
I tried this a dozen times, but 'git apply' failed to fail even once. No
surprise there, given that the patch that throws off rebase every time is
clean and simple. I am flabbergasted :-(
Hm, what if you add in the --index flag? i.e.
git apply
On 3/8/13, Max Horn m...@quendi.de wrote:
Same result, it works fine.
Just shooting in the dark here... I wonder if there's some background
process running in OS X that's messing with the files/directories
while rebase is working... backup, virus scan, etc? Or maybe some
programs that you're
The previous code was assuming length ends at either `)` or `,`, and was
not handling the case where strcspn returns length due to end of string.
So specifying :(top as pathspec will cause the loop to go pass the end
of string.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
setup.c | 6
On 3/7/13, Junio C Hamano gits...@pobox.com wrote:
The parser that goes past the end of the string may be a bug worth
fixing, but is this patch sufficient to diagnose such an input as an
error?
Yea, the patch should fix the passing end of string too. The parser
was going past end of string
On 3/7/13, Junio C Hamano gits...@pobox.com wrote:
This did not error out for me, though.
$ cd t git ls-files :(top
No error message at all? Hm, maybe in your case, the byte after the
end of string happens to be '\0' and the loop ended by chance?
git doesn't crash for me, but it
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
Documentation/githooks.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 8181e4e..eab9b35 100644
--- a/Documentation/githooks.txt
+++ b/Documentation
On Tue, Oct 16, 2012 at 3:41 PM, Uri Moszkowicz u...@4refs.com wrote:
I can do that if it still fails tomorrow. How do I build a debug version of
git?
On Tue, Oct 16, 2012 at 2:35 PM, Andrew Wong andrew.k...@gmail.com wrote:
Yea, it's a difficult problem to diagnose. It'd be really helpful
On 10/15/2012 11:53 AM, Uri Moszkowicz wrote:
I'm trying to convert a CVS repository to Git using cvs2git. I was able to
generate the dump file without problem but am unable to get Git to
fast-import it. The dump file is 328GB and I ran git fast-import on a
machine with 512GB of RAM.
Just taking
On 10/15/2012 05:28 PM, Uri Moszkowicz wrote:
Thanks for the reply. Yes I am using a 64-bit build of Git. The report
is too large to attach to email so I've uploaded it here (~6MB tar.xz
file):
http://www.tempfiles.net/download/201210/267447/fast_import_crash18192.html
Hm, there are some
Can I get some feedback on these two patches? It'd be great to have them
merged into git-gui. Thanks.
On 10/02/2012 12:25 PM, Andrew Wong wrote:
I ran into a file name parsing issue in git-gui. If I'm in a subfolder and try
to pass a full path to git-gui blame, then git-gui will fail
Can I get some feedback on these two patches? It'd be great to have them
merged into gitk. Thanks.
On 10/02/2012 11:04 AM, Andrew Wong wrote:
Refactored the code for binding modified function keys as Junio suggested.
Andrew Wong (2):
gitk: Refactor code for binding modified function keys
On 10/11/12 16:54, Thiago Farina wrote:
Just setting CC to gcc works for me. But still, I'd like to be able to
build with clang (may be as you noted is just something with the + in
my PATH).
Oh, I just realized you were using sudo. The PATH environment was
probably not inherited when you use
a bit
better and easier to read.
Andrew Wong (1):
rebase: Handle cases where format-patch fails
git-rebase--am.sh | 51 +--
1 file changed, 45 insertions(+), 6 deletions(-)
--
1.8.0.rc0.19.gc58a63a.dirty
--
To unsubscribe from this list: send
flow a bit better and easier to read.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--am.sh | 51 +--
1 file changed, 45 insertions(+), 6 deletions(-)
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index 392ebc9..85b594e 100644
' and 'am' by using an
intermediate file. This gurantees that we can invoke 'am' with the
complete input, or not invoking 'am' at all if 'format-patch' failed.
Also print messages to help user with how to recover from such failures.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase
On 10/08/12 17:36, Thiago Farina wrote:
OK, after running ./configure I tried the make command again.
CC credential-store.o
/bin/sh: clang: not found
make: *** [credential-store.o] Error 127
$ which clang
/home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang
$ clang
Could we look into getting this patch into git/gitk?
On 10/02/12 11:04, Andrew Wong wrote:
Refactored the code for binding modified function keys as Junio suggested.
Andrew Wong (2):
gitk: Refactor code for binding modified function keys
gitk: Use bindshiftfunctionkey to bind Shift-F5
very big, so it didn't seem like a good
idea.
Andrew Wong (1):
rebase: Handle cases where format-patch fails
git-rebase--am.sh | 37 +++--
1 file changed, 35 insertions(+), 2 deletions(-)
--
1.8.0.rc0.18.gf84667d
--
To unsubscribe from this list: send the line
in the pipeline is
available, we rely on || to detect whether 'format-patch' has failed.
Also print messages to help user with how to recover from such failures.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--am.sh | 37 +++--
1 file changed, 35
On 10/03/2012 06:35 PM, Alexander Kostikov wrote:
That allows you can go back to the pre-rebase state by
rebase --abort.
rebase --abort command were not available. I guess rebase file was not created.
I meant rebase --abort would be available *if* the error was caught by
rebase. But in your
On 10/04/2012 12:16 PM, John Whitney wrote:
This problem occurs on Mac, Windows, and Linux, and
with multiple versions of git. Note that in my script a CR
is appended to test.txt. On the Mac, you can generate this
in Terminal by pressing Ctrl-V Ctrl-M. Or, alternatively,
just download and run
On 10/04/2012 05:09 PM, Alexander Kostikov wrote:
Full script is uploaded to
https://dl.dropbox.com/u/10828740/rebase.log Here is the last page:
Judging from that log, I'm pretty sure rebase is failing at
format-patch. I was able to reproduce the issue you're having:
rebase finished and
On 10/04/2012 05:20 PM, Marco Craveiro wrote:
Similar but not quite; the idea is that you know that there is some
code (I'm just talking about files here, so lets ignore hunks for the
moment) which is normally checked in but for a period of time you want
it ignored. So you don't want it git
On 10/03/2012 03:47 PM, Alexander Kostikov wrote:
Expected behaviour:
- restore branch to pre-rebase location on out of memory exception
- not to fall with out of memory in the first place. But for our
repository that could be fixed only after either:
--- a) msysgit would have x64 binary
Refactored the code for binding modified function keys as Junio suggested.
Andrew Wong (2):
gitk: Refactor code for binding modified function keys
gitk: Use bindshiftfunctionkey to bind Shift-F5
gitk | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
--
1.7.12.1.382.gb0576a6
The function includes a workaround for systems where F* keys are mapped
to XF86_Switch_VT_* when modifiers are used.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
gitk | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 379582a..f8f89a5 100755
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index f8f89a5..d53fdb2 100755
--- a/gitk
+++ b/gitk
@@ -2501,7 +2501,7 @@ proc makewindow {} {
bindkey ? {dofind -1 1}
bindkey f nextfile
bind
to get to that issue another
time.
Andrew Wong (2):
git-gui: Detect full path when parsing arguments
git-gui: Don't prepend the prefix if value looks like a full path
git-gui.sh | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
--
1.7.12.1.382.gb0576a6
that
checks the file name without using the prefix.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-gui.sh | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/git-gui.sh b/git-gui.sh
index 5d035d5..5d7894b 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -3003,10
When argument parsing fails to detect a file name, git-gui will try to
use the previously detected head as the file name. We should avoid
prepending the prefix if head looks like a full path.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-gui.sh | 9 +++--
1 file changed, 7
I was running into the same issue too. It turns out that on some machines
Shift-F5 is mapped to Shift-XF86_Switch_VT_5. My patch includes a workaround.
The same workaround was used for Shift-F4.
Andrew Wong (1):
gitk: Add workaround for system where Shift-F5 mapped to
Shift-XF86_Switch_VT_5
The same workaround was used for Shift-F4 in:
cea07cf8dc9b3677e0c50433c0d72bce83adbdc7
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
gitk-git/gitk | 1 +
1 file changed, 1 insertion(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..698b84a 100755
--- a/gitk-git/gitk
+++ b
Sorry, my previous git send-email screwed up. Resending the email again.
I was running into the same issue too. It turns out that on some machines
Shift-F5 is mapped to Shift-XF86_Switch_VT_5. My patch includes a workaround.
The same workaround was used for Shift-F4.
Andrew Wong (1):
gitk: Add
The same workaround was used for Shift-F4 in:
cea07cf8dc9b3677e0c50433c0d72bce83adbdc7
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
gitk-git/gitk | 1 +
1 file changed, 1 insertion(+)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..698b84a 100755
--- a/gitk-git/gitk
+++ b
Made the fixes as suggested by Martin.
Martin: Good points. Thanks!
Andrew Wong (3):
rebase -i: Refactor help messages for todo file
rebase -i: Teach --edit-todo action
rebase -i: Add tests for --edit-todo
Martin von Zweigbergk (1):
rebase usage: subcommands can not be combined with -i
-02-28), the usage message
included
git-rebase [-i] --continue | --abort | --skip
Remove the [-i] from this line.
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--interactive.sh | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a09e842..4d57e50 100644
--- a/git-rebase
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--interactive.sh | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index a09e842..4d57e50 100644
--- a/git-rebase
The flag will allow the user to edit the todo file while they're in the middle
of an interactive rebase. It simply invoke the editor and do nothing else.
More discussions here:
http://thread.gmane.org/gmane.comp.version-control.git/205133/focus=205182
Andrew Wong (3):
rebase -i: Refactor
On 09/13/2012 09:33 AM, Peter Krefting wrote:
But this could potentially be dangerous because if rebase fires up
a editor for any other reason (e.g. having a reword or squash in
your recipe), then the commit message will be messed up. So you need
to make sure your recipe won't trigger any
On 09/11/2012 02:32 AM, Peter Krefting wrote:
Now, to my question. Is there an easy way to run interactive rebase on
the upstream branch with this recipe? The best we have come up with so
far is
git checkout master # the upstream branch
git rebase -i HEAD~
and then just append everything
have ever ran into this situation, and would this be
a useful feature to have in interactive rebase? Comments?
This patch doesn't have any documentations yet. I'll add some documentations in
another patch if we decide to include this.
Andrew Wong (1):
rebase -i: Teach --edit action
git-rebase
This allows users to edit the todo list while they're in the middle of
an interactive rebase.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
git-rebase--interactive.sh | 6 ++
git-rebase.sh | 14 ++
2 files changed, 20 insertions(+)
diff --git a/git-rebase
On Mon, Sep 10, 2012 at 12:25 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Indent with space. Please, use tabs (same below).
Ah, thanks. Good catch.
Just edit may be a bit misleading, as we already have the edit
action inside the todolist. I'd call this --edit-list to avoid
On Mon, Sep 10, 2012 at 2:46 PM, Jeff King p...@peff.net wrote:
On Mon, Sep 10, 2012 at 08:36:43PM +0200, Johannes Sixt wrote:
[1] It does preclude using --edit to make a note about a later commit
while you are in the middle of resolving a conflict or something.
You'd have to do it
On Mon, Sep 10, 2012 at 2:28 PM, Johannes Sixt j...@kdbg.org wrote:
Did you think about what can go wrong? For example, starting with this
todo sheet:
exec false
pick 1234567
Ah, that's definitely a problem.
I was going to say we probably just to check the done file, same as
the one we
On Mon, Sep 10, 2012 at 3:57 PM, Junio C Hamano gits...@pobox.com wrote:
Hrm... They see the contents of the todo file immediately after
they say rebase --edit-todo and the sole reason they said that
command is because they wanted to edit the todo file. Is it likely
they need a reminder?
89 matches
Mail list logo
