Junio C Hamano wrote:
Only if I want to publish the result of the work forked from your
triangle as my triangle, but that is not the case. A fork to be
integrated by other is by definition more specialized than the
original, and I would publish my pushbranch subtopic as such, not
as
Hi,
So, this 'git checkout -' not working after a 'rebase -i' has annoyed
me to no end. This is the fix.
Unfortunately, some tests fail and I'm still tracking down what
exactly is going on.
Thanks.
Ramkumar Ramachandra (3):
t/checkout-last: checkout - doesn't work after rebase -i
checkout
The following command
$ git checkout -
does not work as expected after a 'git rebase -i'.
Add a failing test documenting this bug.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t2012-checkout-last.sh | 8
1 file changed, 8 insertions(+)
diff --git a/t/t2012-checkout
Invoking 'git rebase -i' writes the following line to the reflog at the
start of the operation:
rebase -i (start)
This is not very useful. Make it more informative like:
rebase -i (start): checkout master
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase
an interactive rebase.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/checkout.c | 11 ---
t/t2012-checkout-last.sh | 2 +-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f5b50e5..1e2af85 100644
--- a/builtin
Matthieu Moy wrote:
https://lkml.org/lkml/2012/4/12/434
https://lkml.org/lkml/2012/4/15/112
We don't want things taken out of context now, do we? Follow up this
thread [1], if you're interested in that discussion. I did clip out
the quotes you chose on purpose, in the interest of presenting
Junio C Hamano wrote:
I am curious what breaks, though.
t/status-help. Looks seriously unrelated, and I'm breaking my head
over it. Any clues?
--- expected2013-06-10 17:16:42.276356867 +
+++ actual 2013-06-10 17:16:42.279690201 +
@@ -1,4 +1,4 @@
-# HEAD detached at 000106f
+#
Jonathan Nieder wrote:
I don't think most bystanders would misunderstand if I let a certain
person alone instead of responding and saying You are being
unproductive. Please stop. But that certain person seems to
misunderstand, whether I say that or not. So when I lose patience I
say so,
Felipe Contreras wrote:
I think that's the only way forward, since the Git project doesn't
wish to be improved.
Perhaps it's time for me to create a pseudonym, and when you have to
do that to land clearly good patches, you know something is *REALLY*
wrong with the project.
I ask only for
A Large Angry SCM wrote:
It is absolutely imperative to keep all our contributors productive,
and maximize output.
Why?
A useful product with a maintainable code base are what seems to be more
important to a successful open source effort.
Doesn't a successful open source effort (with a
y...@ensimag.imag.fr wrote:
[...]
Good change.
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 9a07f15..958617a 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
I expected one test. Two, at most. This is a bit overzealous. I
don't mind leaving it as it is, but as a note
Junio C Hamano wrote:
The intent behind the document might be a noble one, but I am afraid
that the text is too broad and vague and does not address the real
issue to be of practical use.
Drafting something like this is shit work, which explains why nobody
has attempted it yet. I have no
Michael Haggerty wrote:
Thank you for drafting a proposed CommunityGuidelines document; I think
such a document would be helpful. But I don't like the overall flavor
of your proposal; frankly, it sounds to me more like
Felipe Contreras wrote:
I think there's an even more important number 0:
Always assume good faith. When discussing through digital mediums,
it's very easy to misconstrue the tone and intentions of other
parties, so it's better to err on the side of caution, and if one is
mistaken, assuming
Thomas Rast wrote:
It has become clear, also in discussion on IRC, that your preferred
approach is to fight the fires, attempting to extinguish flames as they
happen.
Incorrect. I am interested in minimizing occurrences, which is why I
started this thread: to calmly and rationally discuss how
This is an exercise. I can easily be more tactful (as evidenced by
other threads), but I'm choosing not to be. I want you to focus on
the argument, and not the tone.
Michael Haggerty wrote:
Ram, you are insulting Thomas the human being rather than addressing his
points. Please stop.
He
John Keeping wrote:
Ugh, why this roundabout-passive-past tone? Use imperative tone
like this:
...
vs.
We normally use the imperative in commit messages, perhaps like
this?
...
As my mother would say, politeness costs nothing ;-)
The review is being
Michael Haggerty wrote:
I stopped reading your email here. I've read enough tactless emails
over the last few days, but to be asked to read an email that was
*intentionally* written tactlessly is too detrimental to my quality of life.
I'm sorry, but the problem has no solution then.
The
John Keeping wrote:
On Wed, Jun 12, 2013 at 12:16:28AM +0530, Ramkumar Ramachandra wrote:
John Keeping wrote:
Ugh, why this roundabout-passive-past tone? Use imperative tone
like this:
...
vs.
We normally use the imperative in commit messages, perhaps like
Jeff King wrote:
And I think that is where the benevolent dictator role comes in. They
weigh not just the points made in the discussion (or a summary of it),
but also use their judgement on who is making comments (how many people,
the utility of their past comments) and other factors (other
Theodore Ts'o wrote:
But if people who *are* senior developers in the git community decide,
on their own, that someone isn't worth listening to, there's the
punishment has been inflicted, and this happens without banning
someone from posting or removing them from the mailing list.
Yes, I have
Junio C Hamano wrote:
$ git am ;# no input file
^C
$ git am --abort
Resolve operation not in progress, we are not resuming.
I tried it on git 1.8.3, and this only incidentally seems to half-work (?)
% git am
^C
% git am --abort
cat:
Junio C Hamano wrote:
These four are all valid ways to spell the rebase -i master step.
and I think it is sensible to expect
(1) they all behave the same way; or
Yes. My reasoning is very simple: a rebase is a rebase; it should not
write checkout: messages to the reflog. Therefore, the
Ramkumar Ramachandra wrote:
t/status-help. Looks seriously unrelated, and I'm breaking my head
over it. Any clues?
Damn it! A recent commit is responsible for this avalanche in test
breakages: b397ea (status: show more info than currently not on any
branch, 2013-03-13). It re-implements
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase--interactive.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f953d8d..0f04425 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
will be addressed in a
future patch.
When the defect is addressed, rebase will write the following line to
the reflog when started:
rebase: checkout master
This is much better than the confusing message it currently writes:
checkout: moving from master to 1462b67
Signed-off-by: Ramkumar
is not an easy task at all:
describe has no exposed API, and is polluted with die() statements.
Nevertheless, it can be a fruitful exercise for someone who is willing
to take on the challenge.
Thanks.
Ramkumar Ramachandra (6):
t/checkout-last: checkout - doesn't work after rebase
rebase
, and
another for an interactive rebase.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t2012-checkout-last.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index b44de9d..ae6d319 100755
--- a/t/t2012-checkout-last.sh
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 86a4f3f..07a6218 100644
--- a/contrib/completion/git
precludes the possibility of a stray $dotest directory
existing (when $dotest/{last,next} are not present).
Fix the bug by checking for a stray $dotest directory explicitly and
removing it on --abort.
Reported-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
SZEDER Gábor wrote:
Just curious: when do those files don't exist? When using an older
version of git with a newer prompt, obviously, but are there other
cases?
# On terminal one
$ git rebase --interactive master
# Ignore editor, and open terminal two
cat: .git/rebase-merge/msgnum: No
In the following case
$ git rebase master
Fast-forwarded autostash-fix to master.
The autostash is not applied automatically, because this codepath
forgets to call finish_rebase(). Fix this. Also add a test to guard
against regressions.
Signed-off-by: Ramkumar Ramachandra artag
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/git-rebase.sh b/git-rebase.sh
index d0c11a9..2122fe0 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -84,6 +84,8 @@ keep_empty=
test $(git config --bool
Hi,
I apologize for having missed these two trivial cases in the original
series.
Ramkumar Ramachandra (3):
rebase: guard against missing files in read_basic_state()
rebase: finish_rebase() in fast-forward rebase
rebase: finish_rebase() in noop rebase
git-rebase.sh | 4
In the following case
$ git rebase master
Current branch autostash-fix is up to date.
the autostash is not applied automatically, because this codepath
forgets to call finish_rebase(). Fix this. Also add a test to guard
against regressions.
Signed-off-by: Ramkumar Ramachandra artag
Junio C Hamano wrote:
But what does it have to do with rebase polluting the reflog?
See the series I just posted.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Junio C Hamano wrote:
Perhaps _that_ guarding condition is what needs
to be fixed, by reverting it back to just does $dotest exist?
Adding a single case workaround smells like a band-aid to me.
Like I pointed out earlier, the original codepath is not equipped to
handle this case. A normal
Junio C Hamano wrote:
Did you mean I'm still resisting, but after reading [...] I think
it makes sense? If so, please discard my question.
Sorry about the lack of clarity. I agreed with most of what you said,
and I outlined how we could possibly turn it into an implementation.
Still haven't
Junio C Hamano wrote:
[...]
Will fix those.
I suspect doing 6/6 before this patch may make more sense.
Yeah, I'd done it like that in the original (early preview thing).
Allow me to explain why I flipped the ordering.
The problem I am facing is that 6/6 causes very major breakages, and
5/6
Hi,
So this is a series to make git rebase [-i] :/quuxery possible. It is
an early preview, because I have not tested that :/quuxery works as
the onto, upstream, and branch.
Thanks.
Ramkumar Ramachandra (3):
t/rebase: add failing tests for a peculiar revision
sh-setup: add new
The failing tests in t/rebase and t/rebase-interactive pass as a result.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase.sh | 6 +++---
t/t3400-rebase.sh | 2 +-
t/t3404-rebase-interactive.sh | 2 +-
3 files changed, 5 insertions(+), 5 deletions
-by: Ramkumar Ramachandra artag...@gmail.com
---
git-sh-setup.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 2f78359..6ae19a6 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -313,3 +313,16
.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t3400-rebase.sh | 8
t/t3404-rebase-interactive.sh | 8
2 files changed, 16 insertions(+)
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b58fa1a..890f159 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400
Junio C Hamano wrote:
Why two?
What breaks checkout - is the initial HEAD detachment (which writes
that checkout: message), before anything else happens. None of
onto, upstream, and branch make any difference: I'm testing
exactly the code that I patched.
I have recently been told that I
Junio C Hamano wrote:
At this point, the utility of such a message is in question.
You can question, but I am not convinced the answer is an
unambiguous not useful
I am not arguing for an unambiguous not useful. I am arguing for a
practical compromise: this patch locks things up too tightly,
Junio C Hamano wrote:
Hmph, when did ORIG_HEAD set, and what commit does it point at?
By some unrelated previous operation (eg. pull, rebase, merge). The
point is that at any point in normal operation, ORIG_HEAD exists,
and usually points to @~N, for some N. If I rm .git/ORIG_HEAD by
hand, the
Junio C Hamano wrote:
What is wrong with git describe? Is this cheaper, or am I missing something?
I think what you are missing is that the detached from is not
about your current HEAD after you flipped it around with many resets
and commits. It is about what tag or what specific commit you
and remove it on --abort in the fresh-execution
codepath.
While at it, tell the user to run git am --abort to get rid of the
stray $dotest directory, if she attempts anything else.
Reported-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-am.sh | 14
[1/2] is now equipped to handle any am invocation in the presence of a
stray $dotest directory.
[2/2] is a while we're there.
Thanks.
Ramkumar Ramachandra (2):
am: handle stray $dotest directory
t/am: use test_path_is_missing() where appropriate
git-am.sh | 14 ++
t/t4150
Replace instances of ! test -d with test_path_is_missing.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t4150-am.sh | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 6c2cc3e..5edb79a 100755
, and switch to terminal 2
cat: .git/rebase-merge/msgnum: No such file or directory
cat: .git/rebase-merge/end: No such file or directory
$
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Better commit message.
contrib/completion/git-prompt.sh | 12 ++--
1 file changed, 6
It's trivial to support the feature :)
Ramkumar Ramachandra (2):
pull: respect rebase.autostash
pull: clarify the large { ... } form
git-pull.sh | 7 +--
t/t5520-pull.sh | 11 +++
2 files changed, 16 insertions(+), 2 deletions(-)
--
1.8.3.1.379.gb74074e.dirty
-by: Ramkumar Ramachandra artag...@gmail.com
---
git-pull.sh | 2 ++
t/t5520-pull.sh | 11 +++
2 files changed, 13 insertions(+)
diff --git a/git-pull.sh b/git-pull.sh
index 638aabb..fb01763 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,6 +44,7 @@ merge_args= edit=
curr_branch=$(git
Remove the large { ... } form, as the block can be confused with a
function block. Use a simple if-condition instead. No functional
changes.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-pull.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/git
the logic
surrounding autostash.
Thanks.
Ramkumar Ramachandra (5):
stash doc: add a warning about using create
stash doc: document short form -p in synopsis
stash: simplify option parser for create
stash: introduce 'git stash store'
rebase: use 'git stash store' to simplify logic
Add a note saying that the user probably wants save in the create
description. While at it, document that it can optionally take a
message in the synopsis.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-stash.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
rebase has no reason to know about the implementation of the stash. In
the case when applying the autostash results in conflicts, replace the
relevant code in finish_rebase () to simply call 'git stash store'.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase.sh | 6
in the
rebase.autostash feature using this new subcommand.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-stash.txt | 7 +++
git-stash.sh| 48 +++--
t/t3903-stash.sh| 19 ++
3 files changed, 68
The option parser for create unnecessarily checks $1 inside a case
statement that matches $1 in the first place.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-stash.sh | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index
Matthieu Moy wrote:
It would be nice to have an --autostash command-line option too,
I thought it would be a bit ugly, since it's already overloaded with
options to pass to merge.
and the
error message in require_clean_work_tree could suggest using it. That
would make the feature easily
Matthieu Moy wrote:
Use a newline, not a ';'.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
John Keeping wrote:
I don't think this is the correct behaviour. I can think of cases where
I would want to output multiple things into the same directory.
format.cleanOutputDirectory = true|false?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Since the early preview, I realized that peel_committish() is required
in exactly two places: the onto and upstream parsers facing
end-user data. Updated appropriately.
Thanks.
Ramkumar Ramachandra (3):
t/rebase: add failing tests for a peculiar revision
sh-setup: add new peel_committish
The revisions specified on the command-line as onto and upstream
arguments could be of the form :/quuxery; so, use peel_committish() to
resolve them. The failing tests in t/rebase and t/rebase-interactive
now pass.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase.sh
.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t3400-rebase.sh | 11 +++
t/t3404-rebase-interactive.sh | 11 +++
2 files changed, 22 insertions(+)
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b58fa1a..81ec517 100755
--- a/t/t3400-rebase.sh
-by: Ramkumar Ramachandra artag...@gmail.com
---
git-sh-setup.sh | 12
1 file changed, 12 insertions(+)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 2f78359..7a964ad 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -313,3 +313,15
Fredrik Gustafsson wrote:
However I think this patch can improve the workflow for experienced
developers. Can we tweak this in some way to get the best out of both
worlds?
The main problem is that output-directory can be an absolute path
(like ~, in the extreme case). I'm not sure how to
Phil Hord wrote:
nit: adds a period where there was not one previously.
Stripped periods in both, thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
SZEDER Gábor wrote:
_git_fp () { _git_format_patch ; }
Good stopgap, thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fredrik Gustafsson wrote:
git format-patch always creates a new directory like:
.git/outgoing/[patchname]FROM commit short sha1...TO commit short sha1
and possible runs a custom command afterwards. Like cd to the patch
directory, open the cover-letter in your editor etc.
git send-email
Junio C Hamano wrote:
The part you stripped from your quote looked like this:
Apologies for the lack of clarity.
You were at 1.8.2 but no longer are, so in the following sequence:
$ git checkout v1.8.2
$ git status
$ git reset --hard HEAD^
$ git status
the former would
Junio C Hamano wrote:
As I said (twice), you can argue that that particular piece of
information is not useful (at least to you), but why it is not
useful has to be justified, against the justification given by
b397ea4863a1 (status: show more info than currently not on any
branch, 2013-03-13)
Junio C Hamano wrote:
These two case arms are indented one level too deep (will locally
touch up).
Thanks. Can you tell me how to get shell-script-mode to indent the
case statement properly? (I used the default indentation)
--
To unsubscribe from this list: send the line unsubscribe git in
the
Junio C Hamano wrote:
$dotest, or \$dotest?
Works fine for me like this. Why do we escape the dollar in the other strings?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Junio C Hamano wrote:
git stash store [-m message] [-e error] commit
I am perplexed; that would not something I _would_ design or
suggest. The -e error looks especially odd, in that -e
usually refers to something the command evaluates (e.g. sed, perl),
but more importantly if the caller
Philip Oakley wrote:
Is there a proper name for this style of revision specification? I've been
letting this 'style' wash over me in the hope that I'd understand
eventually, but it hasn't.
See gitrevisions(7). None of them have any names.
Loking at git-rev-parse I now see that it might be
Junio C Hamano wrote:
If you first update git checkout so that it will pay attention to
a custom reflog-action exported by Porcelain scripts that may want
to internally use it to flip branches (and without a custom one, it
will still record checkout: moving from A to B), without exporting
Junio C Hamano wrote:
wt-status.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index bf84a86..403d48d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -1176,7 +1176,11 @@ void wt_status_print(struct wt_status *s)
Junio C Hamano wrote:
I am only saying that the last test the commit adds must be kept
unbroken. I am also saying that, even though that commit did not
add a test for detached from case, we should add something like
the attached to protect the behaviour. These two are sacred.
What happens
Junio C Hamano wrote:
Two possibilities:
(1) Assume that the other thread will produce a more reasonable
semantics when finished; perhaps the first line will go away
entirely, or maybe it would say something like # Rebasing;
head at $commit.
Your topic does not _care_
Junio C Hamano wrote:
The first line from status in the middle of
a rebase is secondary. End-user initiated checkout to detach is
the primary thing.
3. The problem is not unique to rebase at all; yet you have
special-cased it. If this isn't a band-aid, what is?
It is an illustration for
Junio C Hamano wrote:
I _think_ the new check you added may be too loose.
Yep, I totally forgot about the case when git-am.sh is called from an
existing script. In that case, it is upto the caller to handle
whatever stray directories; we have no business meddling with that.
A fix-up may look
Replace instances of ! test -d with test_path_is_missing.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t4150-am.sh | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 6c2cc3e..5edb79a 100755
The test in [1/2] was too loose in the previous iteration: guard it
with test -z $rebasing. Also fix a couple of minor problems pointed
out by Junio (extra indentation, $-unescaped).
Thanks.
Ramkumar Ramachandra (2):
am: handle stray $dotest directory
t/am: use test_path_is_missing() where
directory, if she attempts anything else.
Reported-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-am.sh | 17 +
t/t4150-am.sh | 6 ++
2 files changed, 23 insertions(+)
diff --git a/git-am.sh b/git-am.sh
index 1cf3d1d..91a2bcc
Add a note saying that the user probably wants save in the create
description. While at it, document that it can optionally take a
message in the synopsis.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-stash.txt | 4 +++-
1 file changed, 3 insertions(+), 1
'git stash save' can take -p, the short form of --patch, as an option.
Document this.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-stash.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git
in the
rebase.autostash feature using this new subcommand.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Documentation/git-stash.txt | 7 +++
git-stash.sh| 47 +++--
t/t3903-stash.sh| 19 ++
3 files changed, 67
The option parser for create unnecessarily checks $1 inside a case
statement that matches $1 in the first place.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-stash.sh | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index
The interface actually makes sense in this iteration, thanks to Junio.
Also fix minor nits pointed out by Phil Hord.
Thanks.
Ramkumar Ramachandra (5):
stash doc: add a warning about using create
stash doc: document short form -p in synopsis
stash: simplify option parser for create
stash
rebase has no reason to know about the implementation of the stash. In
the case when applying the autostash results in conflicts, replace the
relevant code in finish_rebase () to simply call 'git stash store'.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
git-rebase.sh | 7
Junio C Hamano wrote:
You can also specify the commit at the end of the history to be
rebased (very useful while trial runs to see where a series should
apply):
git rebase foo :/Add B
This is already handled properly because it first gets turned into
an object name $orig_head and then
To support mixed-case aliases like:
bM = branch -M
bD = branch -D
add an argument to git_config_with_options() to block the tolower()
calls on key characters.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
The static variable is somewhat disturbing, but it's the most obvious
-reflog to HEAD~3
There is no need to write the full SHA-1 to the user-visible reflog; use
find_unique_abbrev() to shorten the first line like:
f855138: checkout: moving from bdff0e3 to co-reflog
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
builtin/checkout.c | 2 +-
1 file changed
[1/2] is important. [2/2] is a minor prettification, that wouldn't
have been possible without [1/2].
Thanks.
Ramkumar Ramachandra (2):
sha1_name: stop hard-coding 40-character hex checks
checkout: do not write full sha1 to reflog
builtin/checkout.c | 2 +-
sha1_name.c| 6 +++---
2
it with a call to the more robust get_short_sha1().
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 90419ef..d862af3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -451,7
Ramkumar Ramachandra wrote:
[1/2] is important. [2/2] is a minor prettification, that wouldn't
have been possible without [1/2].
I forgot to mention: some tests fail, and I'm investigating. This is
an early preview.
--
To unsubscribe from this list: send the line unsubscribe git in
the body
Junio C Hamano wrote:
[...]
I have no desire to argue incessantly. I just want a solution to the problem!
A rerolled series that does:
- Tweak wt-status.c to take information not from reflog, when
detached during rebase (this may need to tweak existing tests,
as different rebase
Junio C Hamano wrote:
* rr/am-quit-empty-then-abort-fix (2013-06-14) 2 commits
- SQUASH???
- am: handle stray $dotest directory
Please pick up the latest iteration.
http://thread.gmane.org/gmane.comp.version-control.git/227946
* rr/triangle-push-fix (2013-06-09) 4 commits
-
Ramkumar Ramachandra wrote:
Can you tell me how to get shell-script-mode to indent the
case statement properly? (I used the default indentation)
Never mind; I figured it out:
(setq sh-indent-for-case-label 0)
(setq sh-indent-for-case-alt '+)
Maybe we should dump the relevant parts of my
401 - 500 of 1485 matches
Mail list logo
