[PATCH] t5533: make it pass on case-sensitive filesystems

[PATCH] t5533: make it pass on case-sensitive filesystems

[Johannes Schindelin]

The newly-added test case wants to commit a file "c.t" (note the lower
case) when a previous test case already committed a file "C.t". This
confuses Git to the point that it thinks "c.t" was not staged when "git
add c.t" was called.

Simply make the naming of the test commits consistent with the previous
test cases: use upper-case, and advance in the alphabet.

This came up in local work to rebase the Windows-specific patches to the
current `next` branch. An identical fix was suggested by John Keeping.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Published-As: https://github.com/dscho/git/releases/tag/t5533-case-insensitive-v1
Fetch-It-Via: git fetch https://github.com/dscho/git t5533-case-insensitive-v1
 t/t5533-push-cas.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
index 09899af..a2c9e74 100755
--- a/t/t5533-push-cas.sh
+++ b/t/t5533-push-cas.sh
@@ -220,7 +220,7 @@ test_expect_success 'new branch already exists' '
 	(
 		cd src &&
 		git checkout -b branch master &&
-		test_commit c
+		test_commit F
 	) &&
 	(
 		cd dst &&
-- 
2.9.0.281.g286a8d9

base-commit: 9813b109b4ec6630220e5f3d8aff275e23cba59e

Re: [PATCH] t5533: make it pass on case-sensitive filesystems

[Junio C Hamano]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> The newly-added test case wants to commit a file "c.t" (note the lower
> case) when a previous test case already committed a file "C.t". This
> confuses Git to the point that it thinks "c.t" was not staged when "git
> add c.t" was called.
>
> Simply make the naming of the test commits consistent with the previous
> test cases: use upper-case, and advance in the alphabet.
>
> This came up in local work to rebase the Windows-specific patches to the
> current `next` branch. An identical fix was suggested by John Keeping.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> Published-As: https://github.com/dscho/git/releases/tag/t5533-case-insensitive-v1
> Fetch-It-Via: git fetch https://github.com/dscho/git t5533-case-insensitive-v1

Thanks.  It may make it easier to see to have a blank line here,
separating them from the diffstat.

>  t/t5533-push-cas.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t5533-push-cas.sh b/t/t5533-push-cas.sh
> index 09899af..a2c9e74 100755
> --- a/t/t5533-push-cas.sh
> +++ b/t/t5533-push-cas.sh
> @@ -220,7 +220,7 @@ test_expect_success 'new branch already exists' '
>  	(
>  		cd src &&
>  		git checkout -b branch master &&
> -		test_commit c
> +		test_commit F
>  	) &&
>  	(
>  		cd dst &&

Thanks.

> -- 
> 2.9.0.281.g286a8d9
> 
> base-commit: 9813b109b4ec6630220e5f3d8aff275e23cba59e

A totally unrelated tangent.

This line turns out to be less than useful at least in this
particular case.

The fix is meant for jk/push-force-with-lease-creation topic, but I
had to find it out by the old fashioned way, i.e. running blame for
these lines in 'pu' to find eee98e74f9 is the culprit and then
running "git branch --with eee98e74f9".  The only thing the line
made easier is I _could_ start the blame at the named commit (which
is on 'next') instead of 'pu'.  When I took that "base-commit"
series, I was hoping that it would give us a lot more useful
information.

Re: [PATCH] t5533: make it pass on case-sensitive filesystems

[Johannes Schindelin]

Hi Junio,

On Thu, 4 Aug 2016, Junio C Hamano wrote:

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > The newly-added test case wants to commit a file "c.t" (note the lower
> > case) when a previous test case already committed a file "C.t". This
> > confuses Git to the point that it thinks "c.t" was not staged when "git
> > add c.t" was called.
> >
> > Simply make the naming of the test commits consistent with the previous
> > test cases: use upper-case, and advance in the alphabet.
> >
> > This came up in local work to rebase the Windows-specific patches to the
> > current `next` branch. An identical fix was suggested by John Keeping.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > Published-As: https://github.com/dscho/git/releases/tag/t5533-case-insensitive-v1
> > Fetch-It-Via: git fetch https://github.com/dscho/git t5533-case-insensitive-v1
> 
> Thanks.  It may make it easier to see to have a blank line here,
> separating them from the diffstat.

Good suggestion! I made it so:

	https://github.com/dscho/mail-patch-series/commit/1776cb18

> > base-commit: 9813b109b4ec6630220e5f3d8aff275e23cba59e
> 
> A totally unrelated tangent.
> 
> This line turns out to be less than useful at least in this
> particular case.
> 
> The fix is meant for jk/push-force-with-lease-creation topic, but I
> had to find it out by the old fashioned way, i.e. running blame for
> these lines in 'pu' to find eee98e74f9 is the culprit and then
> running "git branch --with eee98e74f9".  The only thing the line
> made easier is I _could_ start the blame at the named commit (which
> is on 'next') instead of 'pu'.  When I took that "base-commit"
> series, I was hoping that it would give us a lot more useful
> information.

Sorry for that. The way my mail-patch-series.sh script works is that it
tries to determine which branch between `master`, `next` or `pu` is the
base (and it then submits *all* commits that are on top of that branch).

So my branch was indeed based on `next` for that reason, not on
top of `jk/push-force-with-lease-creation`. Otherwise, I would have
resubmitted John's patches because the script would have determined that
my patch is on top of `master`, not on top of `next`.

Will try to think of a better way,
Dscho

Re: [PATCH] t5533: make it pass on case-sensitive filesystems

[Jeff King]

On Fri, Aug 05, 2016 at 04:19:08PM +0200, Johannes Schindelin wrote:

> > The fix is meant for jk/push-force-with-lease-creation topic, but I
> > had to find it out by the old fashioned way, i.e. running blame for
> > these lines in 'pu' to find eee98e74f9 is the culprit and then
> > running "git branch --with eee98e74f9".  The only thing the line
> > made easier is I _could_ start the blame at the named commit (which
> > is on 'next') instead of 'pu'.  When I took that "base-commit"
> > series, I was hoping that it would give us a lot more useful
> > information.
> 
> Sorry for that. The way my mail-patch-series.sh script works is that it
> tries to determine which branch between `master`, `next` or `pu` is the
> base (and it then submits *all* commits that are on top of that branch).
> 
> So my branch was indeed based on `next` for that reason, not on
> top of `jk/push-force-with-lease-creation`. Otherwise, I would have
> resubmitted John's patches because the script would have determined that
> my patch is on top of `master`, not on top of `next`.

Do you fetch from the main git.git repository, or Junio's gitster/git
workspace on GitHub?

I usually fetch the latter, and then you have all the information you
need. So to work on somebody else's existing topic, you can do[1]:

  git checkout jk/push-force-with-lease-creation

which will check out the branch, tracking Junio's version of the topic
as your "upstream". Then things like "git rebase -i" just work, and you
can extract the patches as @{u}..HEAD.

It does get weird when he picks up your patch but you want to do further
work, because you would probably not want to "rebase -i" on top of it
(your version of the patch would become obsolete!).

-Peff

[1] I'm assuming you know the topic name. If not, then I usually find
    the commit through the usual archaeology, and then run "git branch
    a --contains" on it (or "for-each-ref" works for that these days,
    and you can restrict it to a pattern matching topic branches).

Re: [PATCH] t5533: make it pass on case-sensitive filesystems

[Johannes Schindelin]

Hi Peff,

On Mon, 8 Aug 2016, Jeff King wrote:

> On Fri, Aug 05, 2016 at 04:19:08PM +0200, Johannes Schindelin wrote:
> 
> > > The fix is meant for jk/push-force-with-lease-creation topic, but I
> > > had to find it out by the old fashioned way, i.e. running blame for
> > > these lines in 'pu' to find eee98e74f9 is the culprit and then
> > > running "git branch --with eee98e74f9".  The only thing the line
> > > made easier is I _could_ start the blame at the named commit (which
> > > is on 'next') instead of 'pu'.  When I took that "base-commit"
> > > series, I was hoping that it would give us a lot more useful
> > > information.
> > 
> > Sorry for that. The way my mail-patch-series.sh script works is that
> > it tries to determine which branch between `master`, `next` or `pu` is
> > the base (and it then submits *all* commits that are on top of that
> > branch).
> > 
> > So my branch was indeed based on `next` for that reason, not on top of
> > `jk/push-force-with-lease-creation`. Otherwise, I would have
> > resubmitted John's patches because the script would have determined
> > that my patch is on top of `master`, not on top of `next`.
> 
> Do you fetch from the main git.git repository, or Junio's gitster/git
> workspace on GitHub?

Neither. I typically fetch from https://github.com/git/git.

Even so, I can in general find out relatively easily what commit is the
tip of the branch I am looking for.

In this here case, I was just too lazy (or too busy with other stuff,
depending on your point of view), is all ;-)

Ciao,
Dscho