This is for consistency with other porcelain commands such as 'log'.
Signed-off-by: Øystein Walle oys...@gmail.com
---
The rationale for this patch I hope is consicely explained in the commit
message. I was rather surprised it didn't use a pager as I've gotten used to it
for most commands.
I
On Wed, 12 Jun 2013 13:28:05 +, Felipe Contreras wrote:
...
And you are
doing that with the express purpose of annoying.
Where did 'assume good faith' go to today?
Andreas
--
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
On Thu, Jun 13, 2013 at 08:43:31AM +0200, Øystein Walle wrote:
This is for consistency with other porcelain commands such as 'log'.
I do not use show-branch myself, but being consistent with the other
porcelain commands makes sense to me.
I marked this as an RFC because of Jeff King's
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
Yes it does help ! Thanks a lot Peff for your very complete answer.
Cheers,
Laurent.
Le 12/06/2013 21:38, Jeff King a écrit :
I hope that helps. -Peff
--
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
This is for consistency with other porcelain commands such as 'log'.
Signed-off-by: Øystein Walle oys...@gmail.com
---
Hi, Jeff
Thanks for the (fast!) feedback and good to hear it won't cause any trouble.
I hadn't actually noticed this mechanism of setting up the pager before now but
I fully
Michael Haggerty mhag...@alum.mit.edu writes:
One race is still possible and undetected: another process could
change the file from a regular file into a symlink between the call to
lstat and the call to open(). The open() call would silently follow
the symlink and not know that something is
From: Johannes Sixt j...@kdbg.org
The bash on Windows rewrites paths that look like absolute POSIX paths
when they are a command-line argument of a regular Windows program, such
as git and the test helpers. As a consequence, the actual tests performed
are not what the tests scripts expect.
The
Dear list,
I am using Git bash from version 1.8.3.msysgit.0, on a Windows 7x64 PC.
I have an issue with executing git push if I have a post-receive
script configured.
The content of the script is not really important, as if I have a
script that contains only commented out lines (around 70 lines),
Øystein Walle oys...@gmail.com writes:
This is for consistency with other porcelain commands such as 'log'.
I don't think consistency with other porcelain is a sufficient argument.
Many commands purposely don't use the pager by default because they will
normally have a short output.
Users can
2013/6/13 Johannes Sixt j.s...@viscovery.net:
From: Johannes Sixt j...@kdbg.org
The bash on Windows rewrites paths that look like absolute POSIX paths
when they are a command-line argument of a regular Windows program, such
as git and the test helpers. As a consequence, the actual tests
From: Benoit Person benoit.per...@ensimag.fr
The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.
This serie is a second attempt to achieve it:
- It adds a new GitMediawiki.pm package to share code between
From: Benoit Person benoit.per...@ensimag.fr
This final commit adds the preview subcommand to git mw. It works as such:
1- Find the remote name of the current branch's upstream and check if it's a
mediawiki one.
1b- If it's not found or if it's not a mediawiki one. It will list all the
mediawiki
From: Benoit Person benoit.per...@ensimag.fr
This script will be used for all tools and command related to a mediawiki
remote. In this commit we introduce the tool, the way it parses argument
and subcommands and an example of subcommand: help. It also updates
the Makefile so that the new tool is
From: Benoit Person benoit.per...@ensimag.fr
The GitMediawiki.pm goal is to share code betwwen several scripts in
Git-Mediawiki (for now, git-mw.perl introduced in this patch serie and
git-remote-mediawiki.perl)
Signed-off-by: Benoit Person benoit.per...@ensimag.fr
Signed-off-by: Matthieu Moy
From: Benoit Person benoit.per...@ensimag.fr
Moving mediawiki_clean_filename, mediawiki_smudge_filename and mw_connect_maybe
Since we have a clean namespace in a perl module, we also rename them into more
concise ones (clean_filename, smudge_filename and connect_maybe). It also
delete the side
Hello,
On Mon, Jun 10, 2013 at 06:58:47PM +0530, Ramkumar Ramachandra wrote:
I've tried to write down a bare minimum, without restating the obvious.
[...]
I often come across so-called community guidelines in other
projects---some of which adhere to them quite strictly, and others simply
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 a
benoit.per...@ensimag.fr writes:
For now, this PATCH/RFC is based on the 'next' branch merged with the
bp/mediawiki-credential patch. For the final version, I will try
to rebase it on celestin's work with perlcritic.
Actually, it seems based on an old next branch. This hunk
---
From: Benoit Person benoit.per...@ensimag.fr
Updates the code to make it more easy to switch mediawiki version when
testing. Before that, the version number was partly hardcoded, partly
in a var.
Maybe I should add a warning that the installation procedure may not work
in the future ? It seems
benoit.per...@ensimag.fr writes:
Updates the code to make it more easy to switch mediawiki version when
testing. Before that, the version number was partly hardcoded, partly
in a var.
This is obviously good.
Maybe I should add a warning that the installation procedure may not work
in the
benoit.per...@ensimag.fr writes:
+install_pm:
+ cp $(GIT_MEDIAWIKI_PM) $(INSTLIBDIR)
Better use install, which is roughly like cp.
Also, this fails if the target dir does not exist, ie. if one did not
run make install at the toplevel Git. It's OK, but perhaps you should
add a comment in
benoit.per...@ensimag.fr writes:
From: Benoit Person benoit.per...@ensimag.fr
This final commit adds the preview subcommand to git mw. It works as such:
1- Find the remote name of the current branch's upstream and check if it's a
mediawiki one.
1b- If it's not found or if it's not a
Tamas Csabina tcsab...@gmail.com writes:
I am using Git bash from version 1.8.3.msysgit.0, on a Windows 7x64 PC.
I have an issue with executing git push if I have a post-receive
script configured.
The content of the script is not really important, as if I have a
script that contains only
Le 2013-06-13 07:52, Antoine Pelisse a écrit :
On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano gits...@pobox.com
wrote:
Antoine Pelisse apeli...@gmail.com writes:
Maybe we can display previous and next commits to provide some
context. Like we do for diff.
For example:
$ git status
# HEAD
benoit.per...@ensimag.fr writes:
From: Benoit Person benoit.per...@ensimag.fr
This script will be used for all tools and command related to a mediawiki
remote. In this commit we introduce the tool, the way it parses argument
and subcommands and an example of subcommand: help. It also updates
On Thu, Jun 13, 2013 at 1:45 AM, Andreas Krey a.k...@gmx.de wrote:
On Wed, 12 Jun 2013 13:28:05 +, Felipe Contreras wrote:
...
And you are
doing that with the express purpose of annoying.
Where did 'assume good faith' go to today?
Did you read the last part?
This does not mean that one
Interactive rebase should never write checkout: messages to the
reflog, since it is highly confusing to the end user, and breaks
grab_nth_branch_checkout(), as demonstrated by failing tests
in t/checkout-last. Set a sensible GIT_REFLOG_ACTION: checkout does not
respect GIT_REFLOG_ACTION yet, but
rebase should never write checkout: messages to the reflog, since it
is highly confusing to the end user, and breaks
grab_nth_branch_checkout(), as demonstrated by failing tests
in t/checkout-last. Set a sensible GIT_REFLOG_ACTION: checkout does not
respect GIT_REFLOG_ACTION yet, but this defect
Hi,
I'm happy to report that I have found a reasonable solution
to the problem: see [5/6].
The larger problem still persists: in my opinion, b397ea4 takes the
wrong approach to the problem it is attempting to solve; nobody cares
_how_ I got to a detached HEAD state; what is important is that I'm
The following command
$ git checkout -
does not work as expected after a rebase. Every kind of rebase must
behave in the exactly same way: for the purposes of checkout -, the
rebase event should be inconsequential.
Add two failing tests documenting this bug: one for a normal rebase, and
On Thu, Jun 13, 2013 at 5:19 AM, Thomas Adam tho...@xteddy.org wrote:
It's a point on which one is never going to win, because no matter what one
says, it'll just get twisted round in such a way that one then ends up
questioning their own words, and their own conduct, and that's bad, because
The files $g/rebase-{merge,apply}/{head-name,msgnum,end} are not
guaranteed to exist. When attempting to cat them, squelch the error
output to get rid of messages like these:
cat: .git/rebase-merge/msgnum: No such file or directory
cat: .git/rebase-merge/end: No such file or directory
Hi Thomas,
Thanks for the reply.
The script is a bash script, just to mention.
Meanwhile I`ve figured it out that the sluggish post-receive execution
was due to a (mis)-configuration in the samba share where the remote
repository is hosted. These are:
oplocks = No
level2 oplocks = No
Removing
The following bug has been observed since rr/rebase-autostash:
$ git am # no input file
^C
$ git am --abort
Resolve operation not in progress, we are not resuming.
This happens because the following test fails:
test -d $dotest test -f $dotest/last test -f $dotest/next
and am
Tamas Csabina tcsab...@gmail.com writes:
Meanwhile I`ve figured it out that the sluggish post-receive execution
was due to a (mis)-configuration in the samba share where the remote
repository is hosted. These are:
oplocks = No
level2 oplocks = No
[...]
Now, do I have to worry about allowing
Hi,
On Thu, Jun 13, 2013 at 07:16:49PM +0530, Ramkumar Ramachandra wrote:
The files $g/rebase-{merge,apply}/{head-name,msgnum,end} are not
guaranteed to exist. When attempting to cat them, squelch the error
output to get rid of messages like these:
cat: .git/rebase-merge/msgnum: No such
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
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
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
[...]
Okay, so what you're saying makes sense.
That is not a very useful style of quoting; what did you just agree to?
I think we should step back and clarify the to which repository the
push goes and what branch(es) in
Ramkumar Ramachandra artag...@gmail.com writes:
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
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
Ramkumar Ramachandra artag...@gmail.com writes:
The following bug has been observed since rr/rebase-autostash:
$ git am # no input file
^C
$ git am --abort
Resolve operation not in progress, we are not resuming.
This happens because the following test fails:
test -d $dotest
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Jun 12, 2013 at 3:02 PM, Junio C Hamano gits...@pobox.com wrote:
The proposed patch was rejected on the basis that it was organized
the code in a wrong way. And your patch shows how it should be
done.
In your opinion.
The fact
Øystein Walle oys...@gmail.com writes:
This is for consistency with other porcelain commands such as 'log'.
Signed-off-by: Øystein Walle oys...@gmail.com
---
The rationale for this patch I hope is consicely explained in the commit
message. I was rather surprised it didn't use a pager as
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 gits...@pobox.com writes:
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
[...]
Okay, so what you're saying makes sense.
That is not a very useful style of quoting; what did you just agree to?
Ahh.
I took your response as I'm still resisting [to
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
Ramkumar Ramachandra artag...@gmail.com writes:
The following command
$ git checkout -
does not work as expected after a rebase. Every kind of rebase must
behave in the exactly same way: for the purposes of checkout -, the
rebase event should be inconsequential.
Add two failing tests
Ramkumar Ramachandra artag...@gmail.com writes:
rebase should never write checkout: messages to the reflog, since it
is highly confusing to the end user, and breaks
grab_nth_branch_checkout(), as demonstrated by failing tests
in t/checkout-last.
breaks because the branch flipping rebase
The same comment as 2/6 applies to this one. What these two do
makes sense, but I think having 6/6 before them would make the
series easier to follow.
--
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
Ramkumar Ramachandra artag...@gmail.com writes:
The struct grab_1st_switch_cbdata has the field found, which is set in
grab_1st_switch() when a match is found. This information is redundant
and unused by any caller: the return value of the function serves to
communicate this information
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
Ramkumar Ramachandra artag...@gmail.com writes:
b397ea4 (status: show more info than currently not on any branch,
2013-03-13) made the output of 'git status' richer in the case of a
detached HEAD. Before this patch, with a detached HEAD:
$ git status
# Not currently on any branch.
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
On Thu, Jun 13, 2013 at 12:24 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Jun 12, 2013 at 3:02 PM, Junio C Hamano gits...@pobox.com wrote:
The proposed patch was rejected on the basis that it was organized
the code in a wrong way.
After commit 3fde386 (reset [--mixed]: use diff-based reset whether or
not pathspec was given), some code can't be reached, and other code can
be moved to the 'reset_type == MIXED' check.
Let's remove the check that can't be reached, and move the code is
specific to MIXED.
Signed-off-by: Felipe
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
The normal way to check whether a certain revision resolves to a valid
commit is:
$ git rev-parse --verify $REV^0
Unfortunately, this does not work when $REV is of the type :/quuxery.
Write a helper to work around this limitation.
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by:
The following commands fail, even if :/quuxery resolves to a perfectly
valid commit:
$ git rebase :/quuxery
$ git rebase -i :/quuxery
This is because rebase [-i] attempts to rev-parse ${REV}^0 to verify
that the given revision resolves to a commit. Add tests to document
these failures.
The compiler can short-circuit the evaluation of conditions strung
together with logical OR operators instead of computing the resulting
bitmask with binary ORs. More importantly, this patch makes the
intent of the changed code clearer, because the logical context (as
opposed to binary context)
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
Ramkumar Ramachandra artag...@gmail.com writes:
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
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,
On Thu, Jun 13, 2013 at 1:16 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, Jun 13, 2013 at 12:24 PM, Junio C Hamano gits...@pobox.com wrote:
But the thing is, that majority is what writes the majority of the
code and does the majority of the reviews, so as maintainer I *do*
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
Ramkumar Ramachandra artag...@gmail.com writes:
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
On Thu, Jun 13, 2013 at 2:19 PM, René Scharfe
rene.scha...@lsrfire.ath.cx wrote:
Deduplicate code by moving tree_desc initialtization into a helper
s/initialtization/initialization/
function, fill_tree_desc_strict. It is like fill_tree_descriptor,
except that it only accepts tree hashes and
Ramkumar Ramachandra artag...@gmail.com writes:
To be clear: the problem is not the feature, but rather in the
_implementation_ of the feature.
OK, but are we discussing the same feature (see below)?
You were at 1.8.2 but no longer are, so in the following sequence:
$ git checkout
On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
@@ -82,7 +82,7 @@ static int reset_index(const unsigned char *sha1, int
reset_type, int quiet)
if (unpack_trees(nr, desc, opts))
return -1;
- if (reset_type == MIXED ||
On Thu, Jun 13, 2013 at 4:13 PM, Martin von Zweigbergk
martinv...@gmail.com wrote:
On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
@@ -82,7 +82,7 @@ static int reset_index(const unsigned char *sha1, int
reset_type, int quiet)
if (unpack_trees(nr,
Martin von Zweigbergk martinv...@gmail.com writes:
...the line after this one reads
err = reset_index(sha1, MIXED, quiet);
? I don't know what the consequence of not calling prime_cache_tree()
would be, though.
It does not affect correctness, but makes the subsequent git
status, the
Ramkumar Ramachandra artag...@gmail.com writes:
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
This does not affect correctness; i.e. head_name=$(cat that-file)
will error out if the file is missing, right?
A more troublesome is that nobody seems to check the return value of
this
Ramkumar Ramachandra artag...@gmail.com writes:
But that is entirely an independent issue (I am going to agree with
you in the end).
Exactly. It might be nice to fix those two things (are there any
observed bugs?), but it is entirely orthogonal to our issue.
OK.
That is a correct
On 06/07/13 11:47, Junio C Hamano wrote:
Scott McPeak smcp...@coverity.com writes:
I suggest that this problem could easily have been avoided if git
stash refused to run with a pending merge (present MERGE_HEAD file),
since this is crucial repository state that it does not save. This
seems
On Thu, 13 Jun 2013, Jeff King wrote:
When we try to load an object from disk and fail, our
general strategy is to see if we can get it from somewhere
else (e.g., a loose object). That lets users fix corruption
problems by copying known-good versions of objects into the
object database.
The first iteration can be found here:
http://thread.gmane.org/gmane.comp.version-control.git/227572/
The errors in the first patch was a faulty test. I also applied Junios solution
in the
first patch, it was nicer.
Fredrik Gustafsson (2):
[submodule] handle multibyte characters in name
Many git submodule operations do not work on a submodule at a path whose
name is not in ASCII.
This is because git ls-files is used to find which paths are bound to
submodules to the current working tree, and the output is C-quoted by default
for non ASCII pathnames.
Tell git ls-files to not
This will prevent a fork and makes the code similair to the rest of the
file.
In the long term git-submodule.sh needs to use something else than sh to
handle newline in filenames (and therefore needs to use a language that
accepts \0 in strings). However I don't think that keeping that small
82 matches
Mail list logo
