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 commen
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. Therefor
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 a
This is for consistency with other porcelain commands such as 'log'.
Signed-off-by: Øystein Walle
---
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 agree. Here's an up
Michael Haggerty 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 wrong. I don't
From: Johannes Sixt
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 tests that need
Junio C Hamano wrote:
> If you recall the earlier discussion on "@{publish} which is
> different from @{upstream}", one idea to allow mapping on the push
> end was to introduce "push.default = single" that would act as
> "upstream" when in "branch I fetch and integrate with is the same
> branch at
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 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 already set "pag
2013/6/13 Johannes Sixt :
> From: Johannes Sixt
>
> 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
From: Benoit Person
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 the new tool
and
`gi
From: Benoit Person
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 remotes configured and as
From: Benoit Person
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 installed properly.
Si
From: Benoit Person
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
Signed-off-by: Matthieu Moy
---
contrib/mw-to-git/GitMediawiki.pm | 24 +
From: Benoit Person
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 effects of mw_connect_maybe
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
doc
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
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
--- a/contr
From: Benoit Person
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 to work for the range 1.1
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
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 comme
benoit.per...@ensimag.fr writes:
> From: Benoit Person
>
> 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 lis
Tamas Csabina 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 commented out lin
Le 2013-06-13 07:52, Antoine Pelisse a écrit :
On Thu, Jun 13, 2013 at 12:19 AM, Junio C Hamano
wrote:
Antoine Pelisse writes:
Maybe we can display previous and next commits to provide some
context. Like we do for diff.
For example:
$ git status
# HEAD detached from ecb9f3e
# Already applie
benoit.per...@ensimag.fr writes:
> From: Benoit Person
>
> 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
On Thu, Jun 13, 2013 at 1:45 AM, Andreas Krey 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 shou
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, bu
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Several other commands
including merge, reset, and commit respect it.
Fix the failing tests in t/checkout-last by making checkout respect it
too. You can now expect
$ git checkout
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.
After the patch:
$ git checkout v1.8.2
# HEAD is no
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 anyway. Remove the field.
Signed-off-by: Ramkumar Rama
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 defec
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
anoth
On Thu, Jun 13, 2013 at 5:19 AM, Thomas Adam 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
> there never wa
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
Signed
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 th
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
Tamas Csabina 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 oplocks on t
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 s
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:
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
---
git-rebase.
Signed-off-by: Ramkumar Ramachandra
---
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 rebase.autosquash)" = "true" &&
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
---
git-reb
Ramkumar Ramachandra 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 that chose
Ramkumar Ramachandra 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 not on any
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 http://vger.kernel.org/majordomo-info.
Ramkumar Ramachandra 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" && test
Felipe Contreras writes:
> On Wed, Jun 12, 2013 at 3:02 PM, Junio C Hamano 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 that nobody outside of 'git' wil
Øystein Walle writes:
> This is for consistency with other porcelain commands such as 'log'.
>
> Signed-off-by: Øystein Walle
> ---
> 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
> fo
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 "nor
Junio C Hamano writes:
> Ramkumar Ramachandra 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 what was quoted
before
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'
Ramkumar Ramachandra 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 documentin
Ramkumar Ramachandra 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 internally
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 htt
Ramkumar Ramachandra 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 anyway. Remove 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
Ramkumar Ramachandra 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.
>
> After the p
Junio C Hamano wrote:
> [...]
I'd just like to point out quickly that I first attempted to write 6/6
without this patch. It is absolutely impossible, because the
"detached HEAD from/to" messages no longer make any sense when
checkout starts respecting GIT_REFLOG_ACTION. At that point, I'm was
ju
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 , , and .
Thanks.
Ramkumar Ramachandra (3):
t/rebase: add failing tests for a peculiar revision
sh-setup: add new peel_committish() helper
reba
On Thu, Jun 13, 2013 at 12:24 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Wed, Jun 12, 2013 at 3:02 PM, Junio C Hamano 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.
>
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 C
The failing tests in t/rebase and t/rebase-interactive pass as a result.
Signed-off-by: Ramkumar Ramachandra
---
git-rebase.sh | 6 +++---
t/t3400-rebase.sh | 2 +-
t/t3404-rebase-interactive.sh | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gi
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
Signed-off-by: Ramkumar Ramachand
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.
Sign
Deduplicate code by moving tree_desc initialtization into a helper
function, fill_tree_desc_strict. It is like fill_tree_descriptor,
except that it only accepts tree hashes and no tree references (tags,
commits). No functional change.
Signed-off-by: René Scharfe
---
match-trees.c | 44
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) be
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
, , and make any difference: I'm testing
exactly the code that I patched.
I have recently been told that I should be testing "en
Ramkumar Ramachandra 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 codepath is n
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
On Thu, Jun 13, 2013 at 1:16 PM, Felipe Contreras
wrote:
> On Thu, Jun 13, 2013 at 12:24 PM, Junio C Hamano 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*
>> have to give their opinion a lot of we
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, t
Ramkumar Ramachandra 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
> , , and make any difference: I'm testing
> exactly the code that I patched.
>
> I have r
On Thu, Jun 13, 2013 at 2:19 PM, René Scharfe
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 no tree references (tags,
Ramkumar Ramachandra 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 v1.8.2
>>
On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
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 || reset_type == HARD) {
> +
On Thu, Jun 13, 2013 at 4:13 PM, Martin von Zweigbergk
wrote:
> On Thu, Jun 13, 2013 at 11:15 AM, Felipe Contreras
> 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
Martin von Zweigbergk 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 part that intern
Ramkumar Ramachandra writes:
> Signed-off-by: Ramkumar Ramachandra
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 function. If head-name, onto or orig-hea
Ramkumar Ramachandra 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 observation. But
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.
We already handle the case where we were not abl
On 06/07/13 11:47, Junio C Hamano wrote:
Scott McPeak 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 similar to what "git
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
[sub
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 no
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
perl-
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 com
88 matches
Mail list logo
