git bug

git bug

[PANEL Christian]

someting is not logical in the behaviour of git :

suppose I have a project and a file in it I don't want to include initially in.
so I put this file name in .gitignore
now all is OK when I write "git status" : the file is ignored.

but later I want this one be a part of my project.
I delete in .gitignore the line that named this file.
but now a "git status" command ignore always this file.

what is wrong ?
did I missed something ?

thanks for any answer 

Re: Git bug

[Gabriel Furstenheim Milerud]

In case someone stumbles onto this. The right way to do it is:

git rev-parse --symbolic-full-name --abbrev-ref=loose @{-1}

On Sat, 15 Apr 2023 at 11:00, Gabriel Furstenheim Milerud
<furstenheim@gmail.com> wrote:
>
> Sorry, my bad. I didn't realize that it worked based on commits. I got confused by git checkout -, which doesn't.
>
> Cheers
>
> On Fri, 14 Apr 2023, 18:07 René Scharfe, <l.s.r@web.de> wrote:
>>
>> Am 14.04.23 um 11:41 schrieb Gabriel Furstenheim Milerud:
>> > Thank you for filling out a Git bug report!
>> > Please answer the following questions to help us understand your issue.
>> >
>> > What did you do before the bug happened? (Steps to reproduce your issue)
>> >> repository in branch A
>> > git name-rev $(git rev-parse HEAD) --name-only
>> >> returns A
>> > git checkout B
>> > git name-rev $(git rev-parse HEAD) --name-only
>> >
>> >
>> >
>> > What did you expect to happen? (Expected behavior)
>> > It should return B
>> >
>> > What happened instead? (Actual behavior)
>> > It returns A
>>
>> Do you have a short recipe for creating the branches to reproduce this
>> behavior?  Here's my (failed) attempt:
>>
>>    # create repository
>>    git init -q /tmp/repo
>>    cd /tmp/repo
>>
>>    # create branch a
>>    echo a >a
>>    git add a
>>    git commit -q -m a
>>    git branch a
>>
>>    # create branch b
>>    echo b >b
>>    git add b
>>    git commit -q -m b
>>    git branch b
>>
>> With that done Git v2.34.1 gives me the output you expect:
>>
>>    $ git switch a
>>    Switched to branch 'a'
>>    $ git name-rev $(git rev-parse HEAD) --name-only
>>    a
>>
>>    $ git switch b
>>    Switched to branch 'b'
>>    $ git name-rev $(git rev-parse HEAD) --name-only
>>    b
>>
>> > What's different between what you expected and what actually happened?
>> > git rev-parse does not seem to update. Same is happenning with git
>> > rev-parse @{-1}
>>
>>    $ git name-rev $(git rev-parse @{-1}) --name-only
>>    a
>>
>> This is expected because @{-1} means the branch/commit checked out
>> before the current one.
>>
>> What does "git rev-parse HEAD" return for you in each case?  Do your
>> branches perhaps have the same HEAD commit?
>>
>> > Anything else you want to add:
>> > git version 2.34.1
>> >
>> > I recently migrated to ubuntu 22. In ubuntu 18 with previous git
>> > version is was working as expected.
>>
>> I guess you use LTS releases, i.e. jammy (22.04) and bionic (18.04)?
>> bionic shipped with Git 2.17.1 according to https://packages.ubuntu.com/
>>
>> René
>>

Re: Git bug

[René Scharfe]

Am 14.04.23 um 11:41 schrieb Gabriel Furstenheim Milerud:
> Thank you for filling out a Git bug report!
> Please answer the following questions to help us understand your issue.
>
> What did you do before the bug happened? (Steps to reproduce your issue)
>> repository in branch A
> git name-rev $(git rev-parse HEAD) --name-only
>> returns A
> git checkout B
> git name-rev $(git rev-parse HEAD) --name-only
>
>
>
> What did you expect to happen? (Expected behavior)
> It should return B
>
> What happened instead? (Actual behavior)
> It returns A

Do you have a short recipe for creating the branches to reproduce this
behavior?  Here's my (failed) attempt:

   # create repository
   git init -q /tmp/repo
   cd /tmp/repo

   # create branch a
   echo a >a
   git add a
   git commit -q -m a
   git branch a

   # create branch b
   echo b >b
   git add b
   git commit -q -m b
   git branch b

With that done Git v2.34.1 gives me the output you expect:

   $ git switch a
   Switched to branch 'a'
   $ git name-rev $(git rev-parse HEAD) --name-only
   a

   $ git switch b
   Switched to branch 'b'
   $ git name-rev $(git rev-parse HEAD) --name-only
   b

> What's different between what you expected and what actually happened?
> git rev-parse does not seem to update. Same is happenning with git
> rev-parse @{-1}

   $ git name-rev $(git rev-parse @{-1}) --name-only
   a

This is expected because @{-1} means the branch/commit checked out
before the current one.

What does "git rev-parse HEAD" return for you in each case?  Do your
branches perhaps have the same HEAD commit?

> Anything else you want to add:
> git version 2.34.1
>
> I recently migrated to ubuntu 22. In ubuntu 18 with previous git
> version is was working as expected.

I guess you use LTS releases, i.e. jammy (22.04) and bionic (18.04)?
bionic shipped with Git 2.17.1 according to https://packages.ubuntu.com/

René

Git bug

[Gabriel Furstenheim Milerud]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
> repository in branch A
git name-rev $(git rev-parse HEAD) --name-only
> returns A
git checkout B
git name-rev $(git rev-parse HEAD) --name-only



What did you expect to happen? (Expected behavior)
It should return B

What happened instead? (Actual behavior)
It returns A

What's different between what you expected and what actually happened?
git rev-parse does not seem to update. Same is happenning with git
rev-parse @{-1}

Anything else you want to add:
git version 2.34.1

I recently migrated to ubuntu 22. In ubuntu 18 with previous git
version is was working as expected.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.19.0-38-generic #39~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC
Fri Mar 17 21:16:15 UTC 2 x86_64
compiler info: gnuc: 11.3
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Re: Git bug.

[Kristoffer Haugsbakk]

On Fri, Apr 14, 2023, at 10:29, Gabriel Furstenheim Milerud wrote:
> Hi,
> Sorry if this is not the right address to report bugs. I'm following
> https://stackoverflow.com/questions/10728104/where-can-i-report-a-git-bug/10733251#10733251

LGTM.

VonC has amazing Git answers on SO, but I feel that this changelog-type
answer is *too much* for a procedure which is just (based on the bug
reports from the last month or so):

1. Run `git bugreport`
2. Edit the file by filling out the blanks and removing irrelevant stuff
   (follow the instructions)
3. Post the report as an inline plaintext email

So basically the sibling answer https://stackoverflow.com/a/70175922/1725151

-- 
Kristoffer Haugsbakk

Git bug.

[Gabriel Furstenheim Milerud]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

Hi,
Sorry if this is not the right address to report bugs. I'm following
https://stackoverflow.com/questions/10728104/where-can-i-report-a-git-bug/10733251#10733251

Cheers
Gabriel Fürstenheim

[-- Attachment #2: git-bugreport-2023-04-14-1018.txt --]
[-- Type: text/plain, Size: 1239 bytes --]

Thank you for filling out a Git bug report!
Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
> repository in branch A
git name-rev $(git rev-parse HEAD) --name-only
> returns A
git checkout B
git name-rev $(git rev-parse HEAD) --name-only



What did you expect to happen? (Expected behavior)
It should return B

What happened instead? (Actual behavior)
It returns A

What's different between what you expected and what actually happened?
git rev-parse does not seem to update. Same is happenning with git rev-parse @{-1}

Anything else you want to add:
git version 2.34.1

I recently migrated to ubuntu 22. In ubuntu 18 with previous git version is was working as expected.

Please review the rest of the bug report below.
You can delete any lines you don't wish to share.


[System Info]
git version:
git version 2.34.1
cpu: x86_64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
uname: Linux 5.19.0-38-generic #39~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 17 21:16:15 UTC 2 x86_64
compiler info: gnuc: 11.3
libc info: glibc: 2.35
$SHELL (typically, interactive shell): /bin/bash


[Enabled Hooks]

Re: git bug

[PANEL Christian]

thanks a lot.
It was exactly what I was seaching (and havent' read yet ;) )

best regards

Le lundi 10 août 2020 à 07:56 +0200, René Scharfe a écrit :
> Am 07.08.20 um 02:02 schrieb Jeff King:
> > 
> > On Thu, Aug 06, 2020 at 10:23:54PM +0200, René Scharfe wrote:
> > 
> > > 
> > > So "file" is no longer ignored.  Committing the .gitignore change
> > > doesn't change that:
> > > 
> > >   $ git add .gitignore
> > >   $ git commit -m 2nd
> > >   [master d4c95a1] 2nd
> > >    1 file changed, 1 deletion(-)
> > >   $ git status
> > >   On branch master
> > >   Untracked files:
> > >     (use "git add <file>..." to include in what will be committed)
> > >   	file
> > > 
> > >   nothing added to commit but untracked files present (use "git add" to track)
> > > 
> > > Which steps did you take to arrive at a different result?
> > Perhaps also:
> > 
> >   git check-ignore -v file
> > 
> > would be helpful for seeing why Git thinks it might be ignored (e.g.,
> > another wildcard rule that happens to match it).
> Right.  And there is more than one possible place to specify files to be
> ignored.  E.g. you can use info/exclude in your Git directory (i.e.
> .git/info/exclude by default) for repository-specific patterns don't
> want to share.  See https://git-scm.com/docs/gitignore or the manpage
> of gitignore(5) for more details.
> 
> René

Re: git bug

[René Scharfe]

Am 07.08.20 um 02:02 schrieb Jeff King:
> On Thu, Aug 06, 2020 at 10:23:54PM +0200, René Scharfe wrote:
>
>> So "file" is no longer ignored.  Committing the .gitignore change
>> doesn't change that:
>>
>>   $ git add .gitignore
>>   $ git commit -m 2nd
>>   [master d4c95a1] 2nd
>>    1 file changed, 1 deletion(-)
>>   $ git status
>>   On branch master
>>   Untracked files:
>>     (use "git add <file>..." to include in what will be committed)
>>   	file
>>
>>   nothing added to commit but untracked files present (use "git add" to track)
>>
>> Which steps did you take to arrive at a different result?
>
> Perhaps also:
>
>   git check-ignore -v file
>
> would be helpful for seeing why Git thinks it might be ignored (e.g.,
> another wildcard rule that happens to match it).

Right.  And there is more than one possible place to specify files to be
ignored.  E.g. you can use info/exclude in your Git directory (i.e.
.git/info/exclude by default) for repository-specific patterns don't
want to share.  See https://git-scm.com/docs/gitignore or the manpage
of gitignore(5) for more details.

René

Re: git bug

[Jeff King]

On Thu, Aug 06, 2020 at 10:23:54PM +0200, René Scharfe wrote:

> So "file" is no longer ignored.  Committing the .gitignore change
> doesn't change that:
> 
>   $ git add .gitignore
>   $ git commit -m 2nd
>   [master d4c95a1] 2nd
>    1 file changed, 1 deletion(-)
>   $ git status
>   On branch master
>   Untracked files:
>     (use "git add <file>..." to include in what will be committed)
>   	file
> 
>   nothing added to commit but untracked files present (use "git add" to track)
> 
> Which steps did you take to arrive at a different result?

Perhaps also:

  git check-ignore -v file

would be helpful for seeing why Git thinks it might be ignored (e.g.,
another wildcard rule that happens to match it).

-Peff

Re: git bug

[René Scharfe]

Am 06.08.20 um 16:48 schrieb PANEL Christian:
> someting is not logical in the behaviour of git :
>
> suppose I have a project and a file in it I don't want to include initially in.
> so I put this file name in .gitignore
> now all is OK when I write "git status" : the file is ignored.

Like this, right?

  $ git init a
  Initialized empty Git repository in /tmp/a/.git/
  $ cd a
  $ echo ignore for now >file
  $ echo file >.gitignore
  $ git add .gitignore
  $ git commit -m initial
  [master (root-commit) 2df5d68] initial
   1 file changed, 1 insertion(+)
   create mode 100644 .gitignore
  $ git status
  On branch master
  nothing to commit, working tree clean

> but later I want this one be a part of my project.
> I delete in .gitignore the line that named this file.
> but now a "git status" command ignore always this file.
>
> what is wrong ?
> did I missed something ?

This seems to work as expected for me (continued from above):

  $ >.gitignore
  $ git status
  On branch master
  Changes not staged for commit:
    (use "git add <file>..." to update what will be committed)
    (use "git restore <file>..." to discard changes in working directory)
  	modified:   .gitignore

  Untracked files:
    (use "git add <file>..." to include in what will be committed)
  	file

  no changes added to commit (use "git add" and/or "git commit -a")

So "file" is no longer ignored.  Committing the .gitignore change
doesn't change that:

  $ git add .gitignore
  $ git commit -m 2nd
  [master d4c95a1] 2nd
   1 file changed, 1 deletion(-)
  $ git status
  On branch master
  Untracked files:
    (use "git add <file>..." to include in what will be committed)
  	file

  nothing added to commit but untracked files present (use "git add" to track)

Which steps did you take to arrive at a different result?

René

git bug

[PANEL Christian]

someting is not logical in the behaviour of git :

suppose I have a project and a file in it I don't want to include initially in.
so I put this file name in .gitignore
now all is OK when I write "git status" : the file is ignored.

but later I want this one be a part of my project.
I delete in .gitignore the line that named this file.
but now a "git status" command ignore always this file.

what is wrong ?
did I missed something ?

thanks for any answer 

git BUG

[Коньков Евгений]

Hi, git

I have get git bug while merging branches.

the farm has branch one year old. say b1
I have develop some feature in this year so I start new branch
  git checkout master
  git checkout -b b2

I get task to develop feature b1. b1 require changes in b2
  git checkout b1
  git merge b2
  git checkout --theirs
  git commit

after some time I need new code from master
  git merge master

after this merge I notice that some code, that was developed in b2, is
disappeared despite on it was merged into b1

so I start to merge it again:
  git merge b2

No results. So I decide to do some testing. I go to b2
  git checkout b2

make changes into file on b2:
diff --git a/lib/SRS/Domain.pm b/lib/SRS/Domain.pm
index 8fa1b1a..23a9429 100644
--- a/lib/SRS/Domain.pm
+++ b/lib/SRS/Domain.pm
@@ -2804,6 +2804,7 @@ sub can_renew_state {
 sub zone {
     my ( $self ) =  @_;

+
     load_class 'SRS::Comm::Zone::Domain';

     return

I have add one empty line to subroutine that have developed in b2.
  git commit
  git checkout b1
  git merge b2

and I get conflict:
+++ b/lib/SRS/Domain.pm
@@@ -2830,24 -2801,20 +2830,29 @@@ sub can_renew_state

  =cut

 -sub zone {
 -    my ( $self ) =  @_;
 +sub can_cancel_transin {
 +    my $self = shift;

++<<<<<<< HEAD
 +    return if $self->{freeze_date};
 +    return unless $self->{create_method} eq 'trans' && $self->{state} eq 'N';
++=======
+
+     load_class 'SRS::Comm::Zone::Domain';
++>>>>>>> yandex_mail_new_api

 -    return
 -        SRS::Comm::Zone::Domain->new(
 -            dname   => $self->{dname},
 -            service => $self,
 -        );
 +    my ( $pos_id ) = dbh_rw->selectrow_array(
 +        'SELECT bi.pos_id FROM billitems bi JOIN bills b ON b.bill_id = bi.bill_id WHERE service_id =
 +        undef,
 +        $self->{service_id}, $self->{user_id}
 +    );
 +
 +    return $pos_id;
  }

 -=back
 +=item cancel_transin
 +
 +Ф-ция отмены переноса

  =cut


As you can see conflict at 'can_cancel_transin' subroutine
but I do changes in 'zone' subroutine


Please help to resolve that CONFLICT and return code from b2 to be
alive again in b1.

And, if you can, please explain why this occur

-- 
 С уважением,
 Коньков Евгений
 Программист
 Регистратор доменных имен REG.RU
 Телефон: +38 (097) 7654-676
 www.reg.ru
 ___________________
 Sincerely yours,
 Konkov Eugen
 Developer
 Accredited domain Registrar REG.RU, LLC.
 Phone: +38 (097) 7654-676
 www.reg.ru/en/

mailto:kes@reg.ru