[git-users] Re: git merge problem

2013-03-19 Thread Blind 
Hi

I think the problem is here:
---
while on branch new_function_find all new changes from master
were merged as:
#git merge -s recursive -Xignore-space-change master
---

I think with this you in fact state something like when merging master and 
new_branch, I prefer the white spaces like on new_branch.
So when you try to merge back new_branch to your master, git takes the 
result of your last merge of master into your new_branch.
Generally speaking you end up with exactly the opposite of what you 
expected...

I think while you are on your new_branch merge changes from master without 
the -Xignore-space-change, and all will be fine.

But thats for the future.

From my point of view now you have several possibilities...
If the merge master on your new_branch is the last commit, then simply 
reset back to previous commit, and you should be fine,
else I think you can try rebuilding a new_branch_1 by cherry-pick the 
non-merges commits from new_branch, and then you should be fine too (by 
merging new_branch_1 into the master)...
just lets hope you don't have too much commits to cherry-pick from your 
new_branch :-)

Blind.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] Interlocking

2013-02-28 Thread Blind 
I've cloned the kernel repo (as I am sure it is big enough for this kind of 
experiments), 
and I tried pushing, committing, pruning and another gc, while gc already 
running,

... couldn't brake it.

So I went deeper ( I have a clone of the git repo itself),
and I found out that before git version 1.5.1 git-gc was still a shell 
script,
in which the main points are infact git-repack and git-prune.
git prune shouldn't make any problems,
git-repack is still a shell script, where we can see that it is basically 
git pack-objects,
which on his turn is well prepared for simultaneous processes (I beleive).

Blind.

27 февруари 2013, сряда, 17:54:44 UTC+2, Dale Worley написа:

  From: Konstantin Khomoutov flat...@users.sourceforge.net javascript: 


  Depends on what you call the same directory. 
  Git commands also fall into different categories depending on what they 
  do. 

 I'm particularly interested in what happens if a process executes git 
 gc --aggressive.  Are there dangers if another process executes Git 
 command simultaneously? 

 Dale 


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[git-users] Re: File modified after git clone

2013-02-27 Thread Blind 
If people who push to your project use different OS, you may find the 
configurations core.autocrlf and core.safecrlf as interesting. (usually 
setting both to false works well)

27 февруари 2013, сряда, 04:31:01 UTC+2, José Guilherme Vanz написа:

 After clone a github repository in my PC, a file is showing like a 
 modified file. But the last modification in this file was done 8 months 
 ago. How is possible? I tried execute git checkout -- . but the file 
 continues like a modified file.

 Anybody have a tip/solution for the problem?


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[git-users] Re: To know the string in which branch

2013-02-22 Thread Blind 
$ git log --source --all -Sfoo


21 февруари 2013, четвъртък, 09:35:48 UTC+2, lei yang написа:

 Hi expert,

 Is there a git command to know string foo contains in which branch? 

 Lei



-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [git-users] Re: Rebasing problems

2013-02-03 Thread Blind 
Maybe I didn't express myself clear :-), sorry. 
I was speaking for at this point, means if you stop (cut) your script at 
the point after adding T commit.
before the rebasings ...
... after the rebase all goes wrong, shure.

03 февруари 2013, неделя, 21:52:54 UTC+2, Dale Worley написа:

  From: Blind stoycho@gmail.com javascript: 
  
  there is still nothing wrong here, 
  just use the -m option for the git log (same for diff-tree -m 
 infact). 

 If you go to the end of the new branch (git checkout rebase, but at 
 the end of the script, that is where you are already), and look at the 
 file file, you will see the 7.5 line is not there. 

 Dale 


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[git-users] Re: Using Git Notes inside Gerrit Hooks

2013-02-02 Thread Blind 
exit code 128 normally means that you are not inside a git repo directory.

anyway, if you mention refs/notes, then it is supposed that you fave a 
.git/refs accessible somewhere (in the current dir or upstairs).

02 февруари 2013, събота, 02:45:40 UTC+2, krishna chaitanya kurnala написа:

 Hello 

 I am trying to come up with a hook that would parse the commit message of 
 any change that is Approved/Merged in Gerrit and add a portion of the 
 commit message to git notes.
 I added a snippet to change-merged gerrit hook, for example, 
 git fetch origin +refs/notes/*:refs/notes/*  $hook_logfile

 I get single entry exit status 128 in the log file.

 Does git notes need a valid workspace to execute ? Did anyone try using 
 git notes inside gerrit hooks. kindly advise. i really appeciate any 
 insights/guidance.

 thanks
 Krishna

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[git-users] Re: Rebasing problems

2013-02-02 Thread Blind 
you can try the same thing, but with adding --interactive to your $ git 
rebase --preserve-merges invocation.

so he will open-up your default editor with the following text:

pick (some SHA1) Commit P
pick (...) Commit Q
pick (...) Commit R
pick (...) Commit S
pick (...) Commit T

(note that the SHA1 of the S commit is the same as for the original S 
commit (fa07bef in your example),
so he still didn't lose his mind at this point.)

then you change the pick to edit in the line with Commit S, then save 
and exit the editor,
he will continue to work and he will stop at what he beleives is S 
commit, but is not really infact.

(you can do a $git show HEAD at this point to see that 5.5 and 6.5 are 
noticed, but no mention of 7.5.)

then you do $git checkout SHA1-OF-ORIGINAL-S (fa07bef in your example, 
but of course it will be something different now)

he will display some usefull information, endindg with HEAD is now at 
(fa07bef) Commit S

then you do $git rebase --continue

... and you end up with the expected picture, and most important - the file 
has hiw 7.5 line.


So generally speaking, I think its a bug of git rebase, he never really 
checks the merge commits to see if they introduce some changes themselves.

I think it is a good idea if you post this problem to the official git 
mailing list (http://news.gmane.org/gmane.comp.version-control.git)

Cheers,
Blind.

31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:

 I'm investigating how rebase works, and I'm finding that it doesn't 
 work well if the rebased branch contains merges.  Am I using rebase 
 incorrectly? 

 In particular, if there are merge commits on the old branch that 
 contain changes that are not contained in either of the commits that 
 are merged, rebase doesn't carry them properly into the new branch. 

 (This sort of merge is not unusual; there may be adjustments needed to 
 combine two sets of changes for reasons other than a purely textual 
 collision between the changes.) 

 As far as I can tell, rebase without --preserve-merges entirely 
 ignores merge commits on the old branch.  Rebase with 
 --perserve-merges seems to recreate the new merges de novo rather than 
 by examining the old merge to determine what it changes.  Neither of 
 these actions is optimal (IMHO). 

 As a test case, I've written the following shell script.  It's written 
 for Linux, but the comments should be clear enough to allow manually 
 executing the git commands on other systems.  The places where I think 
 Git is behaving poorly are marked with ***.  Following the script is 
 the output of my execution of the script. 

 The beginning of the script creates this commit structure: 

A---B---C---D master 
 \ 
  \   Q   
   \ / \ 
P   S---T dev 
 \ / 
  R   

 The goal is to rebase dev (calling it branch 'rebase') to the head of 
 master.  But getting the changes that are in S that are not in Q or R 
 carried into the new branch seems to be impossible. 

 -- 
 set -ve 

 # Create a temporary directory and go into it. 
 DIR=temp.$$ 
 mkdir $DIR 
 cd $DIR 

 # Create a Git repository. 
 git init 

 # Create a file containing the lines 1 to 10. 
 seq 1 10 file 
 git add file 
 git commit -m 'Commit A' 

 # Start the dev branch at commit A. 
 git branch dev HEAD 

 # Add lines 1.5, 2.5, and 3.5 in a series of commits on master. 
 # This sed command adds a line 1.5 before the line 2. 

 sed --in-place -e '/^2$/i1.5' file 
 git commit -a -m 'Commit B' 

 sed --in-place -e '/^3$/i2.5' file 
 git commit -a -m 'Commit C' 

 sed --in-place -e '/^4$/i3.5' file 
 git commit -a -m 'Commit D' 

 # Show the commit structure of master. 
 git log --graph --oneline master 
 git log --graph -p master 

 # Go to the dev branch and create commits with a non-trivial merge. 
 git checkout dev 

 sed --in-place -e '/^5$/i4.5' file 
 git commit -a -m 'Commit P' 

 git branch dev1 HEAD 

 sed --in-place -e '/^6$/i5.5' file 
 git commit -a -m 'Commit Q' 

 git checkout dev1 

 sed --in-place -e '/^7$/i6.5' file 
 git commit -a -m 'Commit R' 

 git checkout dev 

 # Merge commits Q and R, but add the additional line 7.5 (to simulate 
 # fixes that were needed to resolve the merge). 

 git merge --no-commit dev1 
 sed --in-place -e '/^8$/i7.5' file 
 git commit -a -m 'Commit S' 

 sed --in-place -e '/^9$/i8.5' file 
 git commit -a -m 'Commit T' 

 # Show the commit structure of dev. 
 git log --graph --oneline dev 
 # *** Note that the diffs do not show the line 7.5 added in commit S. 
 git log --graph -p dev 

 # Rebase the dev branch to the tip of master. 
 git checkout dev 
 git branch -f rebase dev 
 git checkout rebase 
 git rebase master 

 # Show the commit structure. 
 git log --graph --oneline 
 # *** Note that the line 7.5 added in commit S isn't carried into the new

[git-users] Re: Rebasing problems

2013-02-02 Thread Blind 
a very quick warning to my previous post:

as they say, don't do this at home kids,

it is completely illegal and will brake the whole rabase,

it was just to demonstrate that the S' commit was wrongly rebuilt by the 
rebase.

Blind.

02 февруари 2013, събота, 17:11:14 UTC+2, Blind написа:

 you can try the same thing, but with adding --interactive to your $ git 
 rebase --preserve-merges invocation.

 so he will open-up your default editor with the following text:

 pick (some SHA1) Commit P
 pick (...) Commit Q
 pick (...) Commit R
 pick (...) Commit S
 pick (...) Commit T

 (note that the SHA1 of the S commit is the same as for the original S 
 commit (fa07bef in your example),
 so he still didn't lose his mind at this point.)

 then you change the pick to edit in the line with Commit S, then 
 save and exit the editor,
 he will continue to work and he will stop at what he beleives is S 
 commit, but is not really infact.

 (you can do a $git show HEAD at this point to see that 5.5 and 6.5 are 
 noticed, but no mention of 7.5.)

 then you do $git checkout SHA1-OF-ORIGINAL-S (fa07bef in your example, 
 but of course it will be something different now)

 he will display some usefull information, endindg with HEAD is now at 
 (fa07bef) Commit S

 then you do $git rebase --continue

 ... and you end up with the expected picture, and most important - the 
 file has hiw 7.5 line.


 So generally speaking, I think its a bug of git rebase, he never really 
 checks the merge commits to see if they introduce some changes themselves.

 I think it is a good idea if you post this problem to the official git 
 mailing list (http://news.gmane.org/gmane.comp.version-control.git)

 Cheers,
 Blind.

 31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:

 I'm investigating how rebase works, and I'm finding that it doesn't 
 work well if the rebased branch contains merges.  Am I using rebase 
 incorrectly? 

 In particular, if there are merge commits on the old branch that 
 contain changes that are not contained in either of the commits that 
 are merged, rebase doesn't carry them properly into the new branch. 

 (This sort of merge is not unusual; there may be adjustments needed to 
 combine two sets of changes for reasons other than a purely textual 
 collision between the changes.) 

 As far as I can tell, rebase without --preserve-merges entirely 
 ignores merge commits on the old branch.  Rebase with 
 --perserve-merges seems to recreate the new merges de novo rather than 
 by examining the old merge to determine what it changes.  Neither of 
 these actions is optimal (IMHO). 

 As a test case, I've written the following shell script.  It's written 
 for Linux, but the comments should be clear enough to allow manually 
 executing the git commands on other systems.  The places where I think 
 Git is behaving poorly are marked with ***.  Following the script is 
 the output of my execution of the script. 

 The beginning of the script creates this commit structure: 

A---B---C---D master 
 \ 
  \   Q   
   \ / \ 
P   S---T dev 
 \ / 
  R   

 The goal is to rebase dev (calling it branch 'rebase') to the head of 
 master.  But getting the changes that are in S that are not in Q or R 
 carried into the new branch seems to be impossible. 

 -- 
 set -ve 

 # Create a temporary directory and go into it. 
 DIR=temp.$$ 
 mkdir $DIR 
 cd $DIR 

 # Create a Git repository. 
 git init 

 # Create a file containing the lines 1 to 10. 
 seq 1 10 file 
 git add file 
 git commit -m 'Commit A' 

 # Start the dev branch at commit A. 
 git branch dev HEAD 

 # Add lines 1.5, 2.5, and 3.5 in a series of commits on master. 
 # This sed command adds a line 1.5 before the line 2. 

 sed --in-place -e '/^2$/i1.5' file 
 git commit -a -m 'Commit B' 

 sed --in-place -e '/^3$/i2.5' file 
 git commit -a -m 'Commit C' 

 sed --in-place -e '/^4$/i3.5' file 
 git commit -a -m 'Commit D' 

 # Show the commit structure of master. 
 git log --graph --oneline master 
 git log --graph -p master 

 # Go to the dev branch and create commits with a non-trivial merge. 
 git checkout dev 

 sed --in-place -e '/^5$/i4.5' file 
 git commit -a -m 'Commit P' 

 git branch dev1 HEAD 

 sed --in-place -e '/^6$/i5.5' file 
 git commit -a -m 'Commit Q' 

 git checkout dev1 

 sed --in-place -e '/^7$/i6.5' file 
 git commit -a -m 'Commit R' 

 git checkout dev 

 # Merge commits Q and R, but add the additional line 7.5 (to simulate 
 # fixes that were needed to resolve the merge). 

 git merge --no-commit dev1 
 sed --in-place -e '/^8$/i7.5' file 
 git commit -a -m 'Commit S' 

 sed --in-place -e '/^9$/i8.5' file 
 git commit -a -m 'Commit T' 

 # Show the commit structure of dev. 
 git log --graph --oneline dev 
 # *** Note that the diffs do not show the line 7.5

Re: [git-users] Why Same Files show up with different Statuses in Git?

2013-02-01 Thread Blind 
default is true.
make
$ git config core.filemode false
and then try again


31 януари 2013, четвъртък, 21:31:28 UTC+2, Matthew Johnson написа:

 git config --list does not show core.filemode at all. Nor does git 
 config --get core.filemode (both in Cygwin/windows). So what does it 
 default to?

 On Wednesday, January 30, 2013 10:03:47 PM UTC-8, Blind wrote:

 Just out of curiosity, what you have as filemode configuration?
 Maybe if you do 

 $git config core.filemode false

 the files will no longer show as modified?

 31 януари 2013, четвъртък, 03:40:58 UTC+2, Matthew Johnson написа:

 What differences does it display? It lists about a hundred .ogg files 
 (like the one I included) as 'modified'. I did not want to burden the group 
 with the whole list, so I mentioned only one .ogg file. But here are the 
 first few lines, which include ogg, jpb, and png files:

 [mejohnsn@localhostThinkpad mr.ed]$ git status
 # On branch master
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working 
 directory)
 #
 #   modified:   fix_ogg.py
 #   modified:   lesson1/images/home-icon.jpg
 #   modified:   lesson1/images/home-icon.png
 #   modified:   lesson1/images/left-arrow.png
 #   modified:   lesson1/images/right-arrow.png
 #   modified:   lesson2/images/home-icon.jpg
 #   modified:   lesson3/images/home-icon.jpg
 #   modified:   lesson3/lesson_a/images/home-icon.jpg
 #   modified:   lesson3/lesson_a/sounds/1.ogg
 #   modified:   lesson3/lesson_a/sounds/10.ogg
 ...

 It even includes one Python file I forgot to mention since I have no 
 intention of checking it into the repository;)

 None of these show up as modified when I type the same git status in a 
 Cygwin command line.

 On Wednesday, January 30, 2013 8:21:37 AM UTC-8, Dale Worley wrote:

  From: Matthew Johnson mejo...@gmail.com 
  
  Under Windows (cygwin) git status shows nothing to commit, only 
 untracked 
  files, which is what I expect; only under F17 do I get several 
 modified 
  files -- and these have old dates (e.g. Nov 27). 

 My guess is that it has something to do with line-endings or some 
 subtlety about how file modification times are handled. 

 Under F17, when you do a git diff, what differences does it display? 

 Dale 



-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[git-users] Re: Rebasing problems

2013-02-01 Thread Blind 
I tryed your thing, and yes in both cases we end up with a file without 7.5 
line in it ...
this is not good from my point of view...

git rebase --preserve-merges still keeps the S, 
but he keeps only the info of the changes introduced from the both parents, 
he forgot about your manual change.

I guess a further investigation at the point of:

git merge --no-commit dev1 
sed --in-place -e '/^8$/i7.5' file 
git commit -a -m 'Commit S' 

wil make sence.

I am still not sure if it is a git commit problem in case of middle of 
merge,
or maybe somebody forgot to diff-tree correctly the things...

I am surely very interested how this will turn out.

31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:

 I'm investigating how rebase works, and I'm finding that it doesn't 
 work well if the rebased branch contains merges.  Am I using rebase 
 incorrectly? 

 In particular, if there are merge commits on the old branch that 
 contain changes that are not contained in either of the commits that 
 are merged, rebase doesn't carry them properly into the new branch. 

 (This sort of merge is not unusual; there may be adjustments needed to 
 combine two sets of changes for reasons other than a purely textual 
 collision between the changes.) 

 As far as I can tell, rebase without --preserve-merges entirely 
 ignores merge commits on the old branch.  Rebase with 
 --perserve-merges seems to recreate the new merges de novo rather than 
 by examining the old merge to determine what it changes.  Neither of 
 these actions is optimal (IMHO). 

 As a test case, I've written the following shell script.  It's written 
 for Linux, but the comments should be clear enough to allow manually 
 executing the git commands on other systems.  The places where I think 
 Git is behaving poorly are marked with ***.  Following the script is 
 the output of my execution of the script. 

 The beginning of the script creates this commit structure: 

A---B---C---D master 
 \ 
  \   Q   
   \ / \ 
P   S---T dev 
 \ / 
  R   

 The goal is to rebase dev (calling it branch 'rebase') to the head of 
 master.  But getting the changes that are in S that are not in Q or R 
 carried into the new branch seems to be impossible. 

 -- 
 set -ve 

 # Create a temporary directory and go into it. 
 DIR=temp.$$ 
 mkdir $DIR 
 cd $DIR 

 # Create a Git repository. 
 git init 

 # Create a file containing the lines 1 to 10. 
 seq 1 10 file 
 git add file 
 git commit -m 'Commit A' 

 # Start the dev branch at commit A. 
 git branch dev HEAD 

 # Add lines 1.5, 2.5, and 3.5 in a series of commits on master. 
 # This sed command adds a line 1.5 before the line 2. 

 sed --in-place -e '/^2$/i1.5' file 
 git commit -a -m 'Commit B' 

 sed --in-place -e '/^3$/i2.5' file 
 git commit -a -m 'Commit C' 

 sed --in-place -e '/^4$/i3.5' file 
 git commit -a -m 'Commit D' 

 # Show the commit structure of master. 
 git log --graph --oneline master 
 git log --graph -p master 

 # Go to the dev branch and create commits with a non-trivial merge. 
 git checkout dev 

 sed --in-place -e '/^5$/i4.5' file 
 git commit -a -m 'Commit P' 

 git branch dev1 HEAD 

 sed --in-place -e '/^6$/i5.5' file 
 git commit -a -m 'Commit Q' 

 git checkout dev1 

 sed --in-place -e '/^7$/i6.5' file 
 git commit -a -m 'Commit R' 

 git checkout dev 

 # Merge commits Q and R, but add the additional line 7.5 (to simulate 
 # fixes that were needed to resolve the merge). 

 git merge --no-commit dev1 
 sed --in-place -e '/^8$/i7.5' file 
 git commit -a -m 'Commit S' 

 sed --in-place -e '/^9$/i8.5' file 
 git commit -a -m 'Commit T' 

 # Show the commit structure of dev. 
 git log --graph --oneline dev 
 # *** Note that the diffs do not show the line 7.5 added in commit S. 
 git log --graph -p dev 

 # Rebase the dev branch to the tip of master. 
 git checkout dev 
 git branch -f rebase dev 
 git checkout rebase 
 git rebase master 

 # Show the commit structure. 
 git log --graph --oneline 
 # *** Note that the line 7.5 added in commit S isn't carried into the new 
 branch. 
 git log --graph -p 

 # Rebase the dev branch to the tip of master using --preserve-merges. 
 git checkout dev 
 git branch -f rebase dev 
 git checkout rebase 
 git rebase --preserve-merges master 

 # Show the commit structure. 
 git log --graph --oneline 
 # *** Note that the line 7.5 added in commit S isn't carried into the new 
 branch. 
 git log --graph -p 
 -- 
 $ # Create a temporary directory and go into it. 
 $ DIR=temp.$$ 
 $ mkdir $DIR 
 $ cd $DIR 

 $ # Create a Git repository. 
 $ git init 
 Initialized empty Git repository in 
 /common/not-replicated/worley/T7/temp.21586/.git/ 

 $ # Create a file containing the lines 1 to 10. 
 $ seq 1 10

Re: [git-users] Why Same Files show up with different Statuses in Git?

2013-01-30 Thread Blind 
Just out of curiosity, what you have as filemode configuration?
Maybe if you do 

$git config core.filemode false

the files will no longer show as modified?

31 януари 2013, четвъртък, 03:40:58 UTC+2, Matthew Johnson написа:

 What differences does it display? It lists about a hundred .ogg files 
 (like the one I included) as 'modified'. I did not want to burden the group 
 with the whole list, so I mentioned only one .ogg file. But here are the 
 first few lines, which include ogg, jpb, and png files:

 [mejohnsn@localhostThinkpad mr.ed]$ git status
 # On branch master
 # Changes not staged for commit:
 #   (use git add file... to update what will be committed)
 #   (use git checkout -- file... to discard changes in working 
 directory)
 #
 #   modified:   fix_ogg.py
 #   modified:   lesson1/images/home-icon.jpg
 #   modified:   lesson1/images/home-icon.png
 #   modified:   lesson1/images/left-arrow.png
 #   modified:   lesson1/images/right-arrow.png
 #   modified:   lesson2/images/home-icon.jpg
 #   modified:   lesson3/images/home-icon.jpg
 #   modified:   lesson3/lesson_a/images/home-icon.jpg
 #   modified:   lesson3/lesson_a/sounds/1.ogg
 #   modified:   lesson3/lesson_a/sounds/10.ogg
 ...

 It even includes one Python file I forgot to mention since I have no 
 intention of checking it into the repository;)

 None of these show up as modified when I type the same git status in a 
 Cygwin command line.

 On Wednesday, January 30, 2013 8:21:37 AM UTC-8, Dale Worley wrote:

  From: Matthew Johnson mejo...@gmail.com 
  
  Under Windows (cygwin) git status shows nothing to commit, only 
 untracked 
  files, which is what I expect; only under F17 do I get several modified 
  files -- and these have old dates (e.g. Nov 27). 

 My guess is that it has something to do with line-endings or some 
 subtlety about how file modification times are handled. 

 Under F17, when you do a git diff, what differences does it display? 

 Dale 



-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[git-users] Re: git grief

2013-01-16 Thread Blind 


I suppose its a system difference issue

try:

git config core.filemode false


and then git status again


16 януари 2013, сряда, 02:07:54 UTC+2, JavaSrvcs написа:

 I have not changed any code and just tried to do a git pull and get the 
 following message:

 Updating 527f1ee..18cf73e
 error: Your local changes to the following files would be overwritten by 
 merge:
 java//Info.java
 Please, commit your changes or stash them before you can merge.
 Aborting
 --


 I HAVE NOT CHANGED THIS FILE.  It is telling me that my local changes 
 huh? I have not changed or modified the file.

 
 When I do a $git status I see a lot of other files that begin with:

 *#   modified: /Some.java*
 many lines like the above


 How do I get out of this mess?  I do not want to reset head.  I want to 
 get back to the state where it does not think I have modified a specific 
 set of files... namely the files that I did not change.


 How did I get into this state?  How do I prevent from getting into this 
 state in the future?  How do I get out of this state now?


 thanks for all the help.

 J.V.


--

Re: [git-users] git list files

2013-01-12 Thread Blind 
Thanks alot for your answer, Konstantin, I will try to think a bit more for 
some acceptable user-level solution,
and if I don't come up with anything good I will bring up the question to 
main Git list, as you suggest.

Thanks again,
Blind.


12 януари 2013, събота, 13:04:45 UTC+2, Konstantin Khomoutov написа:

 On Sat, 12 Jan 2013 14:47:03 +0400 
 Konstantin Khomoutov flat...@users.sourceforge.net javascript: wrote: 

 [...] 
  You could roll your own history walking using calls to the 
  `git cat-file` plumbing command 
 [...] 
  You could first try a no-brainer approach though: start from the 
  specified revision (say, HEAD), capture what's available in the tree 
  associated with it and then go down the history looking for a moment 
  where the *name* of an object as recorded in the tree of the starting 
  revision changes its SHA-1 
 [...] 

 As to implementation: 

 1) Call `git cat-file commit rev` for the starting revision, 
parse out committer, author, date, SHA-1 hashes of the parent commits 
and the tree associated with this revision. 

 2) Call `git cat-file tree tree_sha1_hash` on the tree's hash obtained 
on the previous step.  Parse the contents of the returned tree 
object, remember the names, types and SHA-1 hashes of all the 
objects listed in it. 

 3) Take the first parent commit obtained on step (1), and perform steps 
(1) and (2) for it.  After the step (2), compare the trees, object 
by object: an object might be either missing in this parent tree 
which means it was added in the tree you started with, or change its 
SHA-1 hash which means it has been changed in the tree you started 
with. 

 Note that lines of history ending in a merge commit might converge to a 
 single commit down the history which is typical for a feature branches. 
 The `git merge-base` command is there to find such base commits. 


--

[git-users] Re: git list files

2013-01-11 Thread Blind 
In other words, do you think something like:

 ls -1 | awk '{git log -1 --pretty=format:\%ci %h %an\ -- $1 | getline 
g; print g, $1; close(git log -1 --pretty=format:\%ci %h %an\ -- $1)}'

is efficient enough, or you have better ideas?

11 януари 2013, петък, 22:05:56 UTC+2, Blind написа:

 Hi.

 I was wandering, 
 is there an easy git-way to make a list of files (inside a git 
 repository, of course), which outputs the same as ls, plus last commit 
 date and author who changed the file?

 I was doing some experiments with #git ls-files, but he provides me the 
 hash of the blob, who have no info about dates and commits in it.
 It surely must be some clever git command to do this because I see similar 
 output when listing github projects on the tab Files. For example the git 
 source itself on github looks like:
 


 templates https://github.com/git/git/tree/master/templatesa year agoMerge 
 branch 'maint-1.7.6' into 
 mainthttps://github.com/git/git/commit/411e6cf1971936ba31ffa142a6d5dc5c06dc8f7a
  [gitster 
 https://github.com/gitster]vcs-svnhttps://github.com/git/git/tree/master/vcs-svn3
  
 months agoremote-svn: add incremental 
 importhttps://github.com/git/git/commit/8e43a1d010e22a0e432de440b08cc4389d8370f9
  [flyingflo 
 https://github.com/flyingflo]xdiffhttps://github.com/git/git/tree/master/xdiff8
  
 months agoMerge branch 
 'rs/xdiff-fast-hash-fix'https://github.com/git/git/commit/0bc8bea2b4d73b20ce418b88300f498396d0a924
  [gitster 
 https://github.com/gitster].gitattributeshttps://github.com/git/git/blob/master/.gitattributes3
  
 years ago.gitattributes: detect 8-space indent in shell 
 scriptshttps://github.com/git/git/commit/2df3299d860feb55c1caa8487238851c0f4622aa
  [gitster 
 https://github.com/gitster].gitignorehttps://github.com/git/git/blob/master/.gitignorea
  
 day agoMerge branch 
 'nd/wildmatch'https://github.com/git/git/commit/2adf7247ec1f82032f52682918c200716145bffd
  [gitster 
 https://github.com/gitster].mailmaphttps://github.com/git/git/blob/master/.mailmapa
  
 month ago.mailmap: normalize emails for Linus 
 Torvaldshttps://github.com/git/git/commit/0e230644273ba903d6bc57bdf6db82acf4fad4d3
  [peff 
 https://github.com/peff]COPYINGhttps://github.com/git/git/blob/master/COPYING3
  
 years agoUpdate COPYING with GPLv2 with new FSF 
 addresshttps://github.com/git/git/commit/703601d6780c32d33dadf19b2b367f2f79e1e34c
  [gitster 
 https://github.com/gitster]GIT-VERSION-GENhttps://github.com/git/git/blob/master/GIT-VERSION-GEN9
  
 days agoStart 1.8.2 
 cyclehttps://github.com/git/git/commit/298caa7e9e2a813e6d80cf77c64f87ae04c731ff
  [gitster https://github.com/gitster]
 
 Do you have some idea about a simple way to receive such a list?

 Thanks alot,
 Blind.


--