[git-users] git fetch doesn't update latest tags on a bare repo.
Hi, i have a bare repo, when i do a git fetch, the remote tags are not getting updated, though the 'fetch command' runs successfully. please shed some light. thanks. -- 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/d/optout.
Re: [git-users] Git doesn't detect change, if file modification time is restored to original one
Hi Konrád (The original enquirer?), From: Paul Smith p...@mad-scientist.net On Thu, 2015-07-23 at 01:23 -0700, Konrád Lőrinczi wrote: I should somehow ignore atime and mtime when doing diff for status. Just to be clear, what this would involve is for every file in the repo, Git would have to extract the HEAD version into a temporary file (or memory buffer) then compare it to what's currently in the work tree. I've added a reply to the https://github.com/msysgit/git/issues/312 basically changing the problem from, one of getting Git to _auto_ detect such an issue, to one where the user is responsible for forcing the staging of such a file that they know they have fudged. In the response I thought that it may need coding but now I suspect that it can be done via a 'git-hash-object' and a 'git-update-index --index-info', but it probably requires better minds than me to confirm the required stage # so that you have essentially done a 'git add --forced -- path' (who's option does not exist, and would possibly be called --ignore-stat) Given that the whole of git started as a few scripts, it should still be possible, but would need a shift of mental image - an XY_problem. I'm not saying that such a thing should be impossible; adding some kind of flag that does this sort of 100% reliable check could be useful. But, it's not surprising that no one would want to use such a flag (and hence why it's not implemented now). Of course, you could write a script that would do this yourself, and explicitly git add any file determined to be changed. I wonder if it wouldn't be simpler to just modify the tool you're using so it doesn't reset the timestamp on the file in the first place... Philip -- 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/d/optout.
Re: [git-users] git fetch doesn't update latest tags on a bare repo.
On Thu, 23 Jul 2015 06:44:41 -0700 (PDT) dexter ietf dexter.i...@gmail.com wrote: i have a bare repo, when i do a git fetch, the remote tags are not getting updated, though the 'fetch command' runs successfully. please shed some light. thanks. That's almost zero information in your problem statement. So, to being with, have you read and understood everything which is written in the DESCRIPTION section in the `git fetch` manual page? If yes, have your verified that the behaviour you're experiencing differ from your expectations given the exact command you're running and the repository configuration which affects it? -- 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/d/optout.
Re: [git-users] bare repository checkout
On Thu, 2015-07-23 at 06:43 -0700, dexter ietf wrote: git clone with --bare option was significantly faster, so i just assumed it fetches the bare-minimum data. thanks for your detailed answer, it all makes sense now. The difference in time tells you how long it takes to extract a working tree from your Git repository :) -- 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/d/optout.
Re: [git-users] Git doesn't detect change, if file modification time is restored to original one
On Thu, 2015-07-23 at 01:23 -0700, Konrád Lőrinczi wrote: I should somehow ignore atime and mtime when doing diff for status. Just to be clear, what this would involve is for every file in the repo, Git would have to extract the HEAD version into a temporary file (or memory buffer) then compare it to what's currently in the work tree. I'm not saying that such a thing should be impossible; adding some kind of flag that does this sort of 100% reliable check could be useful. But, it's not surprising that no one would want to use such a flag (and hence why it's not implemented now). Of course, you could write a script that would do this yourself, and explicitly git add any file determined to be changed. I wonder if it wouldn't be simpler to just modify the tool you're using so it doesn't reset the timestamp on the file in the first place... -- 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/d/optout.
[git-users] bare repository checkout
Hi, bare repository only contains the meta data, but when i clone from a bare-repo full tree will be checked out. how does git manage to achieve that. i know it's a newbie question. but surprised by the fact that git can do that. so curious to know the answer asap. thanks. -dexter -- 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/d/optout.
Re: [git-users] Git doesn't detect change, if file modification time is restored to original one
I tried to set core to: trustctime = false checkStat = minimal Unfortunately the change is still not detected :( It seems isn't a way to force fallback to file checking and completely ignore file modification date :( 2015. július 22., szerda 21:10:56 UTC+2 időpontban Konstantin Khomoutov a következőt írta: On Wed, 22 Jul 2015 11:17:13 -0700 (PDT) Konrád Lőrinczi klor...@gmail.com javascript: wrote: I wrote a search replace perl script, which recursively searches files and replaces text in them. After replace, it restores original modification time (mtime) of file. Interesting, that git status doesn't show replaced changes, if the mtime is same as original. Is there a way to force git status to show changes, even if the file dates are the same? Check out the `core.trustctime` and `core.checkstat` options. On the other hand, I'd say that even those options won't do what you want. See also [1] which contains pointers to interesting discussions in its most upvoted answer. From that discussion I gather that `git status` relies on mtime but creating actual commit still rehashes all the stuff so may be what's really required in your case is `git add -f -u` or `git add -f -A`, I dunno. 1. http://stackoverflow.com/q/1778862/720999 -- 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/d/optout.
Re: [git-users] Git doesn't detect change, if file modification time is restored to original one
Does 'git update-index' offer any opportunies? (I've not RTFM'd it) - Original Message - From: Konrád Lőrinczi To: Git for human beings Cc: flatw...@users.sourceforge.net Sent: Thursday, July 23, 2015 8:26 AM Subject: Re: [git-users] Git doesn't detect change, if file modification time is restored to original one I tried to set core to: trustctime = false checkStat = minimal Unfortunately the change is still not detected :( It seems isn't a way to force fallback to file checking and completely ignore file modification date :( 2015. július 22., szerda 21:10:56 UTC+2 időpontban Konstantin Khomoutov a következőt írta: On Wed, 22 Jul 2015 11:17:13 -0700 (PDT) Konrád Lőrinczi klor...@gmail.com wrote: I wrote a search replace perl script, which recursively searches files and replaces text in them. After replace, it restores original modification time (mtime) of file. Interesting, that git status doesn't show replaced changes, if the mtime is same as original. Is there a way to force git status to show changes, even if the file dates are the same? Check out the `core.trustctime` and `core.checkstat` options. On the other hand, I'd say that even those options won't do what you want. See also [1] which contains pointers to interesting discussions in its most upvoted answer. From that discussion I gather that `git status` relies on mtime but creating actual commit still rehashes all the stuff so may be what's really required in your case is `git add -f -u` or `git add -f -A`, I dunno. 1. http://stackoverflow.com/q/1778862/720999 -- 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/d/optout. -- 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/d/optout.
[git-users] pushing a private branch to a remote master branch.
Hi, This is what i did, git main repo, call it (M): - clone (M) call it (M-merge) - clone (M) call it (C-merge) - on C-merge, add a new remote for (M-merge), call it Remote-M - on C-merge, create a branch called SC-merge and set it track Remote-M - make a commit to SC-merge and try to push it. it says everything is up-to-date, but clearly i have one commit, which i want it to be pushed to (M-merge). when i googled around, i realized the problem seem to be we can't push a local branch to a remote master branch. But that's precisely is my requirement, how do i get around this 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/d/optout.
