[git-users] Re: cherrypick not syncing all the files
On Friday, January 11, 2013 8:43:59 AM UTC+1, python...@gmail.com wrote: @Thomas -- I get the following message..it saying there are merge conflicts ,even if there are merge conflitcs..it should sync all the files and git status should show them but git status just shows 2 files while there are 10 files in the patch set. error: could not apply d50d931... code: Wait for ack and issue delsta after transmitting the hint: after resolving the conflicts, mark the corrected paths hint: with 'git add paths' or 'git rm paths' hint: and commit the result with 'git commit' Resolved 'file.h' using previous resolution. Resolved 'file2.h' using previous resolution. If a cherry-pick does not cleanly apply, say if you are cherry-picking a commit that includes changes in files that do not exist in your branch, you will get conflicts. Please share with us the following: a) The output of git show --name-status d50d931 b) The output of git status - right after cherry-picking c) The Parent(s) of the Patch-set in the Gerrit UI d) Any Dependencies of the Patch-set in the Gerrit UI e) The output of git rev-parse HEAD (your current commit) f) The log output of git log --pretty=format:%P --graph --all -- this is an anonymized graphical representation of your git log - I want to find the Parent reference and see where it fits in here. --
[git-users] Re: cherrypick not syncing all the files
@Thomas - here is the info you asked http://pastie.org/566 Please share with us the following: a) The output of git show --name-status d50d931 b) The output of git status - right after cherry-picking c) The Parent(s) of the Patch-set in the Gerrit UI d) Any Dependencies of the Patch-set in the Gerrit UI e) The output of git rev-parse HEAD (your current commit) f) The log output of git log --pretty=format:%P --graph --all -- this is an anonymized graphical representation of your git log - I want to find the Parent reference and see where it fits in here. --
[git-users] Re: git checkout bug on Win7 x64
On Fri, 11 Jan 2013 11:30:01 +0400 Ishayahu Lastov meoc...@mail.ru wrote: [...] As I understand after last git checkout in git status I should see that I gave no changes. It looks like an bug, isn't it? Looks like an EOL-conversion problem rather typical to Windows, see http://stackoverflow.com/a/2016426/720999 --
[git-users] Re: cherrypick not syncing all the files
On Friday, January 11, 2013 9:40:47 AM UTC+1, python...@gmail.com wrote: c) The Parent(s) of the Patch-set in the Gerrit UI You pasted the wrong thing in point (c). I'm looking for the parent commit- not dependencies. The parent commit line looks something like this in a Gerrit change: Parent(s)15a6c07b0d414ca35863a55f8dca19dbf44d3533Merge msm8960-common: remove unimplemented devices into mr1-staging --
Re: [git-users] Git doesn't work with Sock5 proxy on MAC
On Thu, 10 Jan 2013 22:14:10 -0800 (PST) Herry Wang tech.he...@gmail.com wrote: [...] git clone http://herry@stash.somesite/a.git Cloning into 'a'... error: Empty reply from server while accessing git/info/refs?service=git-upload-pack fatal: HTTP request failed [...] Bug reports should be directed to the main Git list (for developers) which is git at vger.kernel.org -- see [1] for more info. 1. http://vger.kernel.org/vger-lists.html#git --
Re: [git-users] git merge: error: The following untracked working tree files would be overwritten by merge
I'm not knowledgeable enough to answer your question. I do wonder why you are not tracking the files in obsolete/ . If you truly don't want to track them, then I _think_ that it might be well to add the line: obsolete/ to your .gitignore file. On Fri, Jan 11, 2013 at 4:38 AM, Carsten Fuchs carsten.fu...@cafu.de wrote: Hi all, in my repo, I'm doing this: $ git status # On branch master # Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. # # Untracked files: # (use git add file... to include in what will be committed) # # obsolete/ nothing added to commit but untracked files present (use git add to track) $ git merge origin/master --ff-only Updating f419d57..2da6052 error: The following untracked working tree files would be overwritten by merge: obsolete/e107/Readme.txt obsolete/e107/article.php obsolete/e107/backend.php [...] Well, I seem to understand the problem, and the solution seems to be simple as well: renaming the obsolete/ directory is enough. But why does Git find a problem here at all? Compare with what Subversion did in an analogous case: When I ran svn update and the update brought new files for which there already was an untracked copy in the working directory, Subversion: - started to consider the file as tracked, - but left the file in the working-copy alone. As a result, a subsequent svn status might a) no longer show the file at all, if the foreign copy in the working directory happened to be the same as the one brought by the svn update, or b) flag the file as modified, if different from the one that svn update would have created in its place. So my real question is, why does Git not do something analogous? (Afaics, update the HEAD, update the Index, but leave the working-copy edition alone?) I searched for this beforehand, and most advice involves either stashing, or with git reset --hard the loss of the untracked files. Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- -- Maranatha! John McKown --
[git-users] Git attributes smudge/clean filters
I am trying to implement a filter that updates a Last modified: date
field in a source file comment header on commit. From the reading I've done
so far this seems to be a different approach to the usual mimic RCS
behaviour approach that uses a source file with the $Date$ (or similar)
keyword that gets replaced with the current date on checkout.
Most succintly my approach is thus:
sed s|Last modified: [0-9]*|Last modified: ${currentYear}|
ie. On a clean, look for Last modified: some year text and replace it
with Last modified: this year as the file is committed (a change to a
file isn't real until it is preserved in the repo).
I think this approach makes more sense than the RCS approach because now
the central repository always represents the actual commited changes,
rather than some abstraction using variables and the local files should
also be perfectly aligned with packaging for distribution via tarball or
such because the dates are self-consistent.
The problem is that the local files and the files in the repo end up out of
sync. The local files have the old date, but the repo has the modified
date. I have to rm the file and git checkout myFile to get the change in
my local directory; strangely git checkout --force doesn't pick up the
change either.
Is someone able to explain what I need to do to make this work?
Thanks for your help.
--
[git-users] Re: git merge: error: The following untracked working tree files would be overwritten by merge
Hi John, Am 2013-01-11 14:15, schrieb John McKown: I'm not knowledgeable enough to answer your question. I do wonder why you are not tracking the files in obsolete/ . If you truly don't want to track them, then I _think_ that it might be well to add the line: obsolete/ to your .gitignore file. Thanks for your reply, but this is not the case here: 0. In my example, directory obsolete/ was initially not in any repository, neither in a local nor the central upstream repository, nor in any working tree. 1. I started on computer A, where inside a working tree I initially created the directory obsolete/ and its contents. 2. Then I sent (per SFTP, no Git involved) the complete directory obsolete/ to computer B, into the working tree *there*, because I wanted to test something there before actually committing it on A. (Yes, there are facilities in Git that allow for alternative, more elegant solutions for such cases, but this time, this was what I had to do.) 3. On B, things worked out as expected, so I went back to A, added obsolete/ to the repository (git add obsolete/, git commit), and pushed the new commit upstream (to the central repository, on computer C). 4. Back on A (actually, all this was done via SSH logins to A and B...), I ran git fetch to obtain the new commit from the central repository C, then the git status that you've seen in my original mail. 5. The final git merge origin/master --ff-only failed. Although I saw solutions to the problem, it seems to me that Subversion works better in such cases, and thus I posted here. ;-) Best regards, Carsten On Fri, Jan 11, 2013 at 4:38 AM, Carsten Fuchs carsten.fuchs-sdyparl0...@public.gmane.org wrote: Hi all, in my repo, I'm doing this: $ git status # On branch master # Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. # # Untracked files: # (use git add file... to include in what will be committed) # # obsolete/ nothing added to commit but untracked files present (use git add to track) $ git merge origin/master --ff-only Updating f419d57..2da6052 error: The following untracked working tree files would be overwritten by merge: obsolete/e107/Readme.txt obsolete/e107/article.php obsolete/e107/backend.php [...] Well, I seem to understand the problem, and the solution seems to be simple as well: renaming the obsolete/ directory is enough. But why does Git find a problem here at all? Compare with what Subversion did in an analogous case: When I ran svn update and the update brought new files for which there already was an untracked copy in the working directory, Subversion: - started to consider the file as tracked, - but left the file in the working-copy alone. As a result, a subsequent svn status might a) no longer show the file at all, if the foreign copy in the working directory happened to be the same as the one brought by the svn update, or b) flag the file as modified, if different from the one that svn update would have created in its place. So my real question is, why does Git not do something analogous? (Afaics, update the HEAD, update the Index, but leave the working-copy edition alone?) I searched for this beforehand, and most advice involves either stashing, or with git reset --hard the loss of the untracked files. Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de --
Re: [git-users] Git attributes smudge/clean filters
From: Russell im.russell.smi...@gmail.com The problem is that the local files and the files in the repo end up out of sync. The local files have the old date, but the repo has the modified date. I have to rm the file and git checkout myFile to get the change in my local directory; strangely git checkout --force doesn't pick up the change either. Half of your problem is clear: When you check in a file, the version that gets into the repository is processed as you've arranged for it to be. But of course, that doesn't change the file in the working copy, because that file isn't changed during the checkin process. Exactly why checkout --force doesn't work, I don't know. But presumably git has recorded somewhere that the contents of the repository were generated from the working copy file, and thus considers them the same. Probably this stems from the same design assumption that called the operation clean, that is, that the file contents before and after the transformation are considered to be functionally the same. Dale Dale Worley -- Back in 2004, The Onion predicted that Gillette would release a 5-blade razor in a satire entitled: F**k Everything, We're Doing Five Blades. Well, it happened. It's called the Gillette Fusion. And now, the thing has a battery and vibrates... Do we really need 5 blades that vibrate? -- The Elusive Perfect Shave --
Re: [git-users] Git attributes smudge/clean filters
On Fri, Jan 11, 2013 at 11:56:43AM -0800, Russell wrote:
I am trying to implement a filter that updates a Last modified: date
field in a source file comment header on commit. From the reading I've done
so far this seems to be a different approach to the usual mimic RCS
behaviour approach that uses a source file with the $Date$ (or similar)
keyword that gets replaced with the current date on checkout.
Most succintly my approach is thus:
sed s|Last modified: [0-9]*|Last modified: ${currentYear}|
ie. On a clean, look for Last modified: some year text and replace it
with Last modified: this year as the file is committed (a change to a
file isn't real until it is preserved in the repo).
I think this approach makes more sense than the RCS approach because now
the central repository always represents the actual commited changes,
rather than some abstraction using variables and the local files should
also be perfectly aligned with packaging for distribution via tarball or
such because the dates are self-consistent.
The problem is that the local files and the files in the repo end up out of
sync. The local files have the old date, but the repo has the modified
date. I have to rm the file and git checkout myFile to get the change in
my local directory; strangely git checkout --force doesn't pick up the
change either.
Is someone able to explain what I need to do to make this work?
You seem to misunderstand the concept a bit.
The blobs kept in the repo should have some neutral placeholder, such as
to read something like Last modified $Timestamp$ in them.
Then, in the smudge filter, which is run after checking out the blob
into a file in the work tree, you replace that $Timestamp$ with
something appropriate for your work tree.
Then, in the clean filter, which is run before the new blob is written
to the repository, your task is to *revert* that local change, that is,
to change whatever your smudge filter did back to $Timestamp$.
That way your repository always keeps normalized blobs.
--
[git-users] git pull username password prompt
Hello, I'm using HTTPS (smart-http) for push/pull data to a Git repo. On push the Git client prompts for username and password, after inserting the data will be send. On pulling I must set the origin URL to https://username:password@myserver/my.git, if I remove the username:password@ prefix the Git client creates a 401 error (authentification error). Can I tell the Git client (Linux OSX), that it should prompt on each push and pull for username and password? I wouldn't like to store the username and password within the .git/config file. Thanks Phil --
[git-users] Re: git list files
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.
--
