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
On Thu, Jul 10, 2014 at 12:35 PM, Fabian Ruch 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 majord...@vger.kernel
uring "reword",
> 2011-11-30); it seems that the primary point of the change was to
> make sure it exits and the warning message may not have been well
> thought out, but before discarding the result of somebody else's
> work, it may not be a bad idea to ask just in case
On Mon, Mar 17, 2014 at 7:04 PM, Junio C Hamano 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 tested it during
On Fri, Mar 14, 2014 at 4:57 PM, Jagan Teki wrote:
> Mr.J> git cherry-pick -X subtree=foo
> cc70089614de16b46c08f32ea61c972fea2132ce
> 14e9c9b20e3bf914f6a38ec720896b3d67f94c90
> error: could not apply cc70089... A
> hint: after resolving the conflicts, mark the corrected paths
> hi
On Fri, Mar 14, 2014 at 4:55 PM, Junio C Hamano 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 next tim
On Fri, Mar 14, 2014 at 4:01 PM, Jagan Teki wrote:
> On Sat, Mar 15, 2014 at 12:48 AM, Andrew Wong wrote:
>> On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki wrote:
>>> Suppose developer send 10 patches on branch1 where are changes in terms
>>> of _/ then I need to app
On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki wrote:
> Suppose developer send 10 patches on branch1 where are changes in terms
> of _/ 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
> tree which is quite question
On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud 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 changing "git r
Print message during "git merge" and "git status".
Add a new "mergeHints" advice to silence these messages.
Signed-off-by: Andrew Wong
---
Documentation/config.txt | 3 +++
advice.c | 2 ++
advice.h | 1 +
builtin/merge.c
we want to
make "git reset" 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
---
builtin/reset.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/builtin/reset.c b/builtin/reset.c
index
x27;ll change this into an error to prevent 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" durin
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
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, Mar 5, 2014 at 1:29 PM, Junio C Hamano 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 codepa
On Wed, Feb 26, 2014 at 3:38 PM, Jonathan Nieder 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)
On Wed, Feb 26, 2014 at 3:57 PM, Matthieu Moy
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 should be a warning te
On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder 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 whatever reason
On Wed, Feb 26, 2014 at 3:38 PM, Jonathan Nieder wrote:
> Seems reasonable, but I worry about the command growing too noisy.
>
> Could this be guarded by an advice. setting? (See advice.*
> in git-config(1) for what I mean.)
Ah, good idea. This seems to belong to advice.resolveConflict. I'll
add
On Wed, Feb 26, 2014 at 3:37 PM, Junio C Hamano 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 THE merge".
On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy
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 merge and discard the
would want most of the time, and not "git reset --mixed". I haven't updated the
"git reset" docs yet, I'll 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
Signed-off-by: Andrew Wong
---
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 *s
nges. This makes
"git reset" a little more user-friendly during a merge.
Signed-off-by: Andrew Wong
---
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/
Signed-off-by: Andrew Wong
---
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 @@ static int
cords 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
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 b
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 -
t/t9161-git-svn-
tly setting use_color to 0, we can ensure the diff output has no
color codes in it.
Signed-off-by: Andrew Wong
---
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,
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 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 add" to add my c
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/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.
On 3/11/13, Max Horn 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 fine, I
On 3/11/13, Max Horn 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 the same issu
On 3/11/13, Max Horn 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
> exactl
On 3/10/13, Max Horn 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 sho
The previous code allowed the ")" to be optional.
Signed-off-by: Andrew Wong
---
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 *prefi
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
---
setu
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
On 03/09/13 06:26, Max Horn wrote:
> It tends to fail in separate places, but eventually "stabilizes". E.g. I just
> did a couple test rebases, and it failed twice in commit 14, then the third
> time in commit 15 (which underlines once more that the failures are
> inappropriate).
>
> The fourth
On 3/8/13, Max Horn 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 using at the same
On 3/8/13, Max Horn 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 --index .git/r
On 3/8/13, Max Horn 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" errors out
On 03/07/13 20:51, Junio C Hamano wrote:
> But it is equally broken to behave as if there is nothing wrong in
> the incomplete magic ":(top" that is not closed, isn't it?
Ah, yea, I did notice that, but then I saw a few lines below:
if (*copyfrom == ')')
copyfrom++;
which is exp
On 3/7/13, Junio C Hamano 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 generates this erro
On 3/7/13, Junio C Hamano 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 because the nextat
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
---
setup.c | 6 --
1 fi
Signed-off-by: Andrew Wong
---
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/githooks.txt
@@ -365,7 +365,7
On Tue, Oct 16, 2012 at 3:41 PM, Uri Moszkowicz 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 wrote:
>> Yea, it's a difficult problem to diagnose. It'd be really helpf
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 blanks
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
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
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 &q
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 us
rrange
the 'write_basic_state' and 'move_to_original_branch' to make the logic
flow a bit better and easier to read.
Signed-off-by: Andrew Wong
---
git-rebase--am.sh | 51 +--
1 file changed, 45 insertions(+), 6 deletions(-)
e
'write_basic_state' and 'move_to_original_branch' to make the logic flow 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(+)
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
>
27;format-patch' 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 failur
, or
in repos with larger files and perhaps binary files.
Andrew Wong (1):
rebase: Handle cases where format-patch fails
git-rebase--am.sh | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
--
1.8.0.rc0.19.ga19ab82.dirty
--
To unsubscribe from this list
On 10/07/12 20:39, Thiago Farina wrote:
> When trying to build from source but it's failing:
>
> $ sudo make prefix=/usr/local all
> LINK git-credential-store
> gcc: @CHARSET_LIB@: No such file or directory
> make: *** [git-credential-store] Error 1
Did you run the "configure" script?
In the so
Could we look into getting these two patches into git/git-gui?
On 10/02/12 12:25, 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 to detect the
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 bindshiftfunctionke
and 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
---
git-rebase--am.sh | 37 +++--
1 file changed, 35 insert
an intermediate file to store the output of 'format-patch'.
But the intermediate file could get 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
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 ignor
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 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 the
On 10/04/2012 12:35 AM, John Whitney wrote:
I just ran into a problem that I'm pretty sure is a bug in git. Just
read and run this (fairly trivial) shell script to replicate.
I tried your steps on a Mac, but I wasn't able to produce the issue.
Perhaps I don't have the right CRLF configs to trigg
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 yo
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 (current
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
---
git-gui.sh | 9 +++--
1 fi
additional branch that
checks the file name without using the prefix.
Signed-off-by: Andrew Wong
---
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 +3003,1
path along with a rev argument, but I
don't have time to look it right now. I'll try 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
Signed-off-by: Andrew Wong
---
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 . updatecommits
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
---
gitk | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 379582a..f8f89a5 100755
--- a/gitk
+++ b/gitk
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 same workaround was used for Shift-F4 in:
cea07cf8dc9b3677e0c50433c0d72bce83adbdc7
Signed-off-by: Andrew Wong
---
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/gitk-git/gitk
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 (
The same workaround was used for Shift-F4 in:
cea07cf8dc9b3677e0c50433c0d72bce83adbdc7
Signed-off-by: Andrew Wong
---
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/gitk-git/gitk
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
On 09/18/12 00:58, Martin von Zweigbergk wrote:
> On Mon, Sep 17, 2012 at 6:28 PM, Andrew Wong wrote:
>> + test M = $(git cat-file commit HEAD^ | sed -ne \$p) &&
>> + test L = $(git cat-file commit HEAD | sed -ne \$p)
> I couldn't find "$" (m
This allows users to edit the todo file while they're stopped in the
middle of an interactive rebase. When this action is executed, all
comments from the original todo file are stripped, and new help messages
are appended to the end.
Signed-off-by: Andrew Wong
---
Documentation/git-rebas
Signed-off-by: Andrew Wong
---
t/t3404-rebase-interactive.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 7304b66..6eafb63 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
Signed-off-by: Andrew Wong
---
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--interactive.sh
+++ b/git-rebase
message
included
git-rebase [-i] --continue | --abort | --skip
Remove the "[-i]" from this line.
Signed-off-by: Martin von Zweigbergk
Signed-off-by: Andrew Wong
---
git-rebase.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase.sh b/git-rebas
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
Signed-off-by: Andrew Wong
---
t/t3404-rebase-interactive.sh | 18 ++
1 file changed, 18 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 7304b66..6eafb63 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
This allows users to edit the todo file while they're stopped in the
middle of an interactive rebase. When this action is executed, all
comments from the original todo file are stripped, and new help messages
are appended to the end.
Signed-off-by: Andrew Wong
---
Documentation/git-rebas
Signed-off-by: Andrew Wong
---
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--interactive.sh
+++ b/git-rebase
On 09/16/12 02:54, Junio C Hamano wrote:
> In any case, what information are you discarding and then replacing
> with the standard boilerplate?
It's to strip out the comment that says:
# However, if you remove everything, the rebase will be aborted.
As there's no way reliable way to know wher
Signed-off-by: Andrew Wong
---
t/t3404-rebase-interactive.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 7304b66..a194c97 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
This allows users to edit the todo file while they're stopped in the
middle of an interactive rebase. When this action is executed, all
comments from the original todo file are stripped, and new help messages
are appended to the end.
Signed-off-by: Andrew Wong
---
Documentation/git-rebas
Signed-off-by: Andrew Wong
---
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--interactive.sh
+++ b/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: Ref
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
On Mon, Sep 10, 2012 at 3:57 PM, Junio C Hamano 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?
Yes, it's not
On Mon, Sep 10, 2012 at 2:28 PM, Johannes Sixt 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 do for
1 - 100 of 104 matches
Mail list logo
