git glob pattern in .gitignore and git command

[Yubin Ruan]

To ignore all .js file under a directory `lib', I can use "lib/**/js" to match
them. But when using git command such as "git add", using "git add lib/\*.js"
is sufficient. Why is this difference in glob mode?

I have heard that there are many different glob mode out there (e.g., bash has
many different glob mode). So, which classes of glob mode does these two
belong to? Do they have a name?

Yubin

[RFC] git clone add option to track all remote branches

[Yubin Ruan]

Hi,

I am writing to ask that whether or not you think will be appropriate to add
an option to "git clone" so that whenever a repo is cloned, branches are
created automatically to track corresponding remote branches. (or is there any
equivelant option?)

You can obviously do this by a bash command like this

git branch -r | grep -v '\->' | while read remote; do git branch --track 
"${remote#origin/}" "$remote"; done

but it will be better if we can have an option in "git clone".

Regards,
Yubin

Re: Draft of Git Rev News edition 33

[Yubin Ruan]

2017-11-20 16:33 GMT+08:00 Christian Couder :
> Hi,
>
> A draft of a new Git Rev News edition is available here:
>
>   
> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-33.md
>
> Everyone is welcome to contribute in any section either by editing the
> above page on GitHub and sending a pull request, or by commenting on
> this GitHub issue:
>
>   https://github.com/git/git.github.io/issues/262
>
> You can also reply to this email.
>
> In general all kinds of contribution, for example proofreading,
> suggestions for articles or links, help on the issues in GitHub, and
> so on, are very much appreciated.
>
> I tried to cc everyone who appears in this edition, but maybe I missed
> some people, sorry about that.
>
> Thomas, Jakub, Markus and myself plan to publish this edition on
> Wednesday November 22nd.

Nice post.

For the CRLF issue: I am not really that concerned with this issue
because I mostly develop all my project on Linux. But can't git treat
CRLF and LF just as the same thing? That will solves the problem
gracefully.

Yubin

Re: Meaning of two commit-ish hash in git diff

[Yubin Ruan]

Thanks Philip,

On 11/01/2017 08:27 AM, Philip Oakley wrote:
> Yubin ,
> 
> From: "Junio C Hamano" <gits...@pobox.com>
>> Yubin Ruan <ablacktsh...@gmail.com> writes:
>>
>>> diff --git a/path/somefile b/path/somefile
>>> index f8886b4..a1c96df 100644
>>> --- a/path/somefile
>>> +++ b/path/somefile
>>> 
>>>
>>> This is output by a `git diff` between two adjacent commits but they are
>>> not any commit hash. I grep through the whole $(git log) but still cannot
>>> find those hash.
>>
>> The f8886b4 you see on the left is the name of the blob object on
>> the left hand side of the comparison that produced this output;
>> similarly a1c96df is the name of the blob object on the right hand
>> side of the comparison.
>>
>> IOW, if you have the contents of the blob whose object name is
>> f8886b4, by applying this patch, you will get a blob whose object
>> name is a1c96df.
>>
>> The information is used by "git am -3" when the patch does not apply
>> cleanly to fall back to the 3-way merge.
> 
> The ability to 'git describe` those blob object IDs is currently the subject 
> of a patch series
> https://public-inbox.org/git/20171031211852.13001-1-sbel...@google.com/
> 
> Maybe see if would have helped ;-)

What would be other use case of the blob object / blob name ?

Yubin

Meaning of two commit-ish hash in git diff

[Yubin Ruan]

Hi,

Can anyone tell me what does the "f8886b4..a1c96df" mean in a git diff output,
as below?

diff --git a/path/somefile b/path/somefile
index f8886b4..a1c96df 100644
--- a/path/somefile
+++ b/path/somefile


This is output by a `git diff` between two adjacent commits but they are
not any commit hash. I grep through the whole $(git log) but still cannot
find those hash.

And BTW, are there any special meanings for that .. ?

Thanks,
Yubin

checking out from branch A to branch B brings along a folder from A. Why

[Yubin Ruan]

Hi,

I got three branch: master, A, B.

I have a directory in branch A: "/path/to/repo/somefolder" (and that
folder is in the working tree, not working directory), but that folder
doesn't exist in either branch B or master. When in branch A, if I do

$ git checkout B

that "somefolder" will be brought to branch B (this is weird)

But when I do

$ git checkout master

then it will not be brought along (this works as expected)

That is weird because AFAIK checkout out to branch B will not bring
any file from the working tree from other branch.

I have tried to updated git from 1.5.4.7 to 2.9.

I am in a CI server so there might be some mis-configuration. What
should I check for? Has anyone ever encountered such a situation?

Yubin

Re: will git rebase has side effect

[Yubin Ruan]

2017-10-01 22:17 GMT+08:00 Kevin Daudt <m...@ikke.info>:
> Forgot to cc the mailing list.
>
> On Sun, Oct 01, 2017 at 09:23:23PM +0800, Yubin Ruan wrote:
>> Suppose that I have such a history of commit locally:
>>
>> A --> B --> C --> D
>>
>> If I then add a few more commits locally
>>
>> A --> B --> C --> D --> E --> F --> G
>>
>> And then I do a rebase and squash F and G into one single commit H.
>> What side effect will this rebase have? How will this affect "git push
>> origin master"?
>>
>> Yubin
>
> Hello Yubin,
>
> So the situation is this:
>
> [origin/master]
>   |
> A --> B --> C --> D --> E --> F --> G
> |
>  [master]
>
> Then you squash (F' is the result of squashing F and G):
>
> [origin/master]
>   |
> A --> B --> C --> D --> E --> F'
>   |
>[master]
>
> When you want to push now, it's just as if you just created just two
> commits in the first place, and you can just push normally (assuming no
> one else has pushed in the mean time.

Hmm..You mean, if I do a squash, it will only affects those commits
that has been squashed, not any other commits, and their parent-child
relations remain the same?

Yubin

> The situation is different when you have pushed already:
>
>   [origin/master]
> |
> A --> B --> C --> D --> E --> F --> G
> |
>  [master]
>
> Then after you squash, the history would look as follows:
>
>   [origin/master]
> |
> A --> B --> C --> D --> E --> F --> G
>  \
>   --> F'
>   |
>[master]
>
> This sitation would look to git like you created F', and someone else
> had pushed F and G. It will reject the push, saying you would need to
> merge these changes first (but you don't want this, because you are
> merging the same changes together).
>
> To solve this, you can use git push --force-with-lease=master origin,
> which will force the push, overwriting the history the remote already
> had.
>
> Hope this helps, Kevin.
>
> nb. --force-with-lease is a safer version of just (-f|--force), because
> it will prevent you from overwriting history you don't have locally, for
> example when someone else did push already.
>
>

will git rebase has side effect

[Yubin Ruan]

Suppose that I have such a history of commit locally:

A --> B --> C --> D

If I then add a few more commits locally

A --> B --> C --> D --> E --> F --> G

And then I do a rebase and squash F and G into one single commit H.
What side effect will this rebase have? How will this affect "git push
origin master"?

Yubin

Re: git diff doesn't quite work as documented?

[Yubin Ruan]

2017-09-08 0:31 GMT+08:00 Olaf Klischat :
> oklischat@oklischat:/tmp$ mkdir gittest
> oklischat@oklischat:/tmp$ cd gittest/
> oklischat@oklischat:/tmp/gittest$ git init
> Initialized empty Git repository in /private/tmp/gittest/.git/
> oklischat@oklischat:/tmp/gittest$ echo foo > foo.txt
> oklischat@oklischat:/tmp/gittest$ git add foo.txt
> oklischat@oklischat:/tmp/gittest$ git commit -m foo
> [master (root-commit) 54d55f2] foo
>  1 file changed, 1 insertion(+)
>  create mode 100644 foo.txt
> oklischat@oklischat:/tmp/gittest$ echo bar > bar.txt
> oklischat@oklischat:/tmp/gittest$ git add bar.txt
> oklischat@oklischat:/tmp/gittest$ git commit -m bar
> [master 83b2e74] bar
>  1 file changed, 1 insertion(+)
>  create mode 100644 bar.txt
> oklischat@oklischat:/tmp/gittest$ git tag bar-added
> oklischat@oklischat:/tmp/gittest$ git rm bar.txt
> rm 'bar.txt'
> oklischat@oklischat:/tmp/gittest$ git commit -m 'rm bar'
> [master 3ca4ff9] rm bar
>  1 file changed, 1 deletion(-)
>  delete mode 100644 bar.txt
> oklischat@oklischat:/tmp/gittest$
> oklischat@oklischat:/tmp/gittest$ git checkout bar-added -- bar.txt
> oklischat@oklischat:/tmp/gittest$ git reset HEAD
> oklischat@oklischat:/tmp/gittest$ git status
> On branch master
> Untracked files:
>   (use "git add ..." to include in what will be committed)
>
> bar.txt
>
> nothing added to commit but untracked files present (use "git add" to track)
> oklischat@oklischat:/tmp/gittest$ git diff bar-added   # would expect this to 
> show no differences
> diff --git a/bar.txt b/bar.txt
> deleted file mode 100644
> index 5716ca5..000
> --- a/bar.txt
> +++ /dev/null
> @@ -1 +0,0 @@
> -bar
> oklischat@oklischat:/tmp/gittest$
> oklischat@oklischat:/tmp/gittest$ git diff bar-added  -- bar.txt   # dito
> diff --git a/bar.txt b/bar.txt
> deleted file mode 100644
> index 5716ca5..000
> --- a/bar.txt
> +++ /dev/null
> @@ -1 +0,0 @@
> -bar

Michael J Gruber is correct about the working-dir/working-tree things.
A quick example: add a new file with

$ echo bzz > bzz.txt

then do "git diff bar-added".

The result is the same, because "bzz.txt" is not in the working-tree.

Yubin

> oklischat@oklischat:/tmp/gittest$
>
>
> `git diff --help' says:
>
> git diff [--options]  [--] [...]
>This form is to view the changes you have in your working tree 
> relative to the named .
>
> If that were entirely true, the last two commands shouldn't have shown
> any differences, right?
>
> On closer inspection, it seems that what `git diff ' really
> does is take only those paths in the working directory that are also
> in  and compare the resulting tree against .
>
> We should add some option to that git diff form to make it really do
> what the docs claim it does.
>
> Or am I missing something?

Re: [RFC] Add warning when git discard changes on another branch?

[Yubin Ruan]

On Mon, May 08, 2017 at 03:07:02PM +0900, Junio C Hamano wrote:
> Yubin Ruan <ablacktsh...@gmail.com> writes:
> 
> > That would be helpful. But, frankly, if a user would be aware of that 
> > `advice.*'
> > variable, he would have enough knowledge of Git to be aware of that 
> > situation.
> > So, I think that 'M lala.txt' in transitions from branch to branch would be
> > sufficient.
> 
> Ah, you got the advice.* thing wrong.  The "advice" messages are by
> default noisy, and experts can turn them down by setting advice.* to
> "false", saying "I know Git well enough that I do not need handholding
> in this area."
> 
> So a newbie does not have to know about "advice.*".  When s/he gets
> experienced enough to get annoyed by noisy messages, s/he can tune
> it out.

You are right. I might have had too much drug right then...
But still, I don't think that advice.* is necessary.

---
Yubin

Re: [RFC] Add warning when git discard changes on another branch?

[Yubin Ruan]

On Mon, May 08, 2017 at 01:19:58PM +0900, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
> > But to help "some users are not aware of this" situation, an opt-in
> > "feature" would not help all that much.  The same number of lines in
> > the documentation to tell end-users how to toggle on such a "safety"
> > feature can be spent to teach them that their local changes in the
> > working tree do *not* belong to any particular branch, and as soon
> > as it is understood, the user would be OK.
> >
> > So...
> 
> It might help if we treat this similarly to how we treat the
> "detached HEAD" state.  By default when you do "git checkout HEAD^0"
> (not "git checkout --detach HEAD"), you would get a large warning,
> which you can silence by the advice.detachedhead configuration.  In
> addition to the list of "these paths have local modifications" that
> we show as a reminder, perhaps you want to show a warning that tells
> the user that the local modifications in these paths are not
> recorded anywhere else, or somesuch, and silence it with a new
> advice.* variable?

That would be helpful. But, frankly, if a user would be aware of that `advice.*'
variable, he would have enough knowledge of Git to be aware of that situation.
So, I think that 'M lala.txt' in transitions from branch to branch would be
sufficient.

---
Yubin

Re: [RFC] Add warning when git discard changes on another branch?

[Yubin Ruan]

On Mon, May 08, 2017 at 12:41:03PM +0900, Junio C Hamano wrote:
> Yubin Ruan <ablacktsh...@gmail.com> writes:
> 
> > I understand this. I just suggest that git add some warning in case some 
> > users
> > are not aware of this, as it does when , on branch 'issue', changes to 
> > 'lala.txt'
> > are based on a commit different from where the checkout happened, i.e.
> >   
> >  on branch 'master'
> >  |
> >  |  <-- git checkout -b issue
> >   \
> >\  <-- modification to git happened on a commit different from 
> > where
> >   the checkout happened
> >  
> > in this situation, git would warn us something like this:
> >  
> >  error: Your local changes to the following files would be overwritten 
> > by checkout:
> > lala.txt
> >  Please, commit your changes or stash them before you can switch 
> > branches.
> >  Aborting
> 
> That does not have much to do with "are commits the same?".  If
> 'master' and 'issue' branches are pointing at different commit, as
> long as they record the same content at the path "lala.txt", you can
> check out between these branches freely, as we can do so without
> having to resort to merging the edit the user made to the working
> tree to the different contents of "lala.txt".
> 
> There already is an indication that you have local modification in
> the working tree when we check out another branch (you would have
> seen "M lala.txt" when you did a "checkout" of another branch while
> you have local changes to the path).  

That is convincing :)
 
> Because it is a quite commonly used feature that you can checkout
> another branch and carry local changes with you, making it error out
> like we do when the branches record different contents for the
> locally changed paths when we do not have to would be a bad change
> that hurts productivity of users who do use Git correctly, which
> would mean that we need to make it an opt-in feature. 

I agree.

> But to help "some users are not aware of this" situation, an opt-in
> "feature" would not help all that much.  The same number of lines in
> the documentation to tell end-users how to toggle on such a "safety"
> feature can be spent to teach them that their local changes in the
> working tree do *not* belong to any particular branch, and as soon
> as it is understood, the user would be OK.
> 
> So...
> 

---
Yubin

Re: [RFC] Add warning when git discard changes on another branch?

[Yubin Ruan]

On Mon, May 08, 2017 at 12:05:31PM +0900, Junio C Hamano wrote:
> Yubin Ruan <ablacktsh...@gmail.com> writes:
> 
> > I think it would be better if git can warn use if we switch to another 
> > branch
> > without committing the modification. Git will warn if the modification is 
> > based
> > on a commit different from where the checkout happened.
> >
> > For example, say I am now on branch 'master' and all files *clean*. Now if 
> > I do:
> > $ git checkout -b issue
> > and make some changes to a file:
> > $ echo "modification on branch issue" >> lala.txt
> > and then switch back to branch 'master':
> > $ git checkout master
> > and git can see the changes:
> > $ git status
> >   On branch master
> >   Changes not staged for commit:
> > (use "git add ..." to update what will be committed)
> > (use "git checkout -- ..." to discard changes in working 
> > directory)
> >   
> > modified:   lala.txt
> >   
> >   no changes added to commit (use "git add" and/or "git commit -a")
> >   
> > Now, if I do "git checkout -- lala.txt", then I will lose that change on 
> > branch
> > 'issue' too!!! 
> 
> There may be a fundamental misunderstanding here.  In Git, changes
> you make in the working tree do *not* belong to any branch.  The
> request "git checkout -- lala.txt" you made in this step does *not*
> say "Hey, Git, these changes to lala.txt are not necessary in the
> 'master' branch".  It says "I started editing lala.txt, but it turns
> out that I do not need that change at all, anywhere, please remove
> it."

I understand this. I just suggest that git add some warning in case some users
are not aware of this, as it does when , on branch 'issue', changes to 
'lala.txt'
are based on a commit different from where the checkout happened, i.e.
  
 on branch 'master'
 |
 |  <-- git checkout -b issue
  \
   \  <-- modification to git happened on a commit different from where
  the checkout happened
 
in this situation, git would warn us something like this:
 
 error: Your local changes to the following files would be overwritten by 
checkout:
lala.txt
 Please, commit your changes or stash them before you can switch branches.
 Aborting

> If you meant the changes while you were on "issues" branch were not
> yet ready to be committed, but now you want to work on "master"
> branch without having to worry about these changes, "git stash" may
> be a useful tool.  Alternatively, you can just create a temporary
> commit while on "issues" branch before checking out "master" branch
> to work on something else, and when you are ready to continue
> working on the "issues" branch, check out "issues" branch and either
> (1) start with "reset HEAD^" or (2) just continue working on it and
> conclude with "commit --amend".
 
Nice suggestion though.

---
Yubin

[RFC] Add warning when git discard changes on another branch?

[Yubin Ruan]

Hi,
I think it would be better if git can warn use if we switch to another branch
without committing the modification. Git will warn if the modification is based
on a commit different from where the checkout happened.

For example, say I am now on branch 'master' and all files *clean*. Now if I do:
$ git checkout -b issue
and make some changes to a file:
$ echo "modification on branch issue" >> lala.txt
and then switch back to branch 'master':
$ git checkout master
and git can see the changes:
$ git status
  On branch master
  Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working 
directory)
  
modified:   lala.txt
  
  no changes added to commit (use "git add" and/or "git commit -a")
  
Now, if I do "git checkout -- lala.txt", then I will lose that change on branch
'issue' too!!! 

If, on branch 'issue', the changes to 'lala.txt' are based on a commit different
from where the checkout happened, i.e.
 
on branch 'master'
|
|  <-- git checkout -b issue
 \
  \  <-- modification to git happened on a commit different from where
 the checkout happened

then git would warn us something like this:

error: Your local changes to the following files would be overwritten by 
checkout:
lala.txt
Please, commit your changes or stash them before you can switch branches.
Aborting

So, I think it is better to add some similar warinings if the modification
happened on a commit the *same* as where the checkout happened, i.e.

on branch 'master'
|
|  <-- git checkout -b issue
   <-- modification to git happened on a commit different from where
   the checkout happened

I already lost some of my work by this ...

(p.s please add me to the Cc because I am not in this list)
---
Yubin