Re: [git-users] Git says there are local changes, but there are no changes. (Windows)

[tombert]

you need to do a "git checkout ." in order to overwrite local changes (note 
the dot after the checkout command).

On Friday, 4 March 2016 22:05:19 UTC+1, Ben Page wrote:
>
> The repos that exhibit this behavior are Visual Studio projects and the 
> problem files are text files.
>
> I don't think the problem is line endings. git diff returns nothing and 
> the projects have * text=auto in the .gitattributes file and core.autocrlf 
> set 
> to true.
>
> I believe the problem is caused by Visual Studio. This never happens on 
> any project that doesn't use it. But I don't know what it's doing to the 
> files.
>
> What I'm most confused by is why doesn't git checkout or git reset --hard 
> resolve 
> the problem. Why do I have to delete the .git\index for git to properly 
> recreate these file?
>
> On Wednesday, February 24, 2016 at 10:03:24 AM UTC-6, Dale R. Worley wrote:
>>
>> Ben Page  writes: 
>> >>git status 
>> > On branch master 
>> > Your branch is behind 'origin/master' by 2 commits, and can be 
>> > fast-forwarded. 
>> >   (use "git pull" to update your local branch) 
>> > Changes not staged for commit: 
>> >   (use "git add ..." to update what will be committed) 
>> >   (use "git checkout -- ..." to discard changes in working 
>> directory) 
>> > modified: XXX 
>> > modified: YYY 
>> > no changes added to commit (use "git add" and/or "git commit -a") 
>>
>> Certainly one thing you can do is "git diff XX" and see what Git 
>> thinks the changes are. 
>>
>> Unfortunately, I don't know if git-diff is completely rigid about 
>> reporting different ends-of-lines.  You can 
>> mv XX XX.old 
>> git reset --hard 
>> diff XX XX.old 
>> if you know that the diff you are using reports all byte differences. 
>>
>> As the other responder said, the underlying cause is likely file name 
>> casing or ends-of-lines, which are the sort of things that get 
>> translated between files in the working directory and the repository. 
>>
>> 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/d/optout.

Re: [git-users] stash for remote?

[Pablo Rodríguez]

On 02/29/2016 12:44 PM, Konstantin Khomoutov wrote:
> On Mon, 29 Feb 2016 00:29:07 +0100 Pablo Rodríguez wrote:
> 
>> is there any way to stash already commited local changes against the
>> published version in the remote server?
> 
> No, but why would you want to?

Many thanks for your reply again, Konstantin.

Well, after your reply I realized that I had to start using branches.
(This was something I avoided as I considered too cumbersome for my
basic needs [it seems that I was totally wrong].)

> If you merely need to have a series of commits available somehow while
> you'd like to temporarily reset the branch they were made on to its
> state in a remote repo, just do exactly that: either fork a branch off
> the tip of your updated branch or tag its tip and then reset the branch.
> 
> If we suppose we're talking about the branch "master", and the remote
> server is known as "origin", then you'd do something like this:
> 
> First do
> 
> git fetch origin
> 
> to have origin/master updated to the state of "master" at "origin".
> 
> Then either do
> 
> git branch temp master

Probably I prefer creating a branch. But isn’t it better to create the
branch before fetching contents from the remote server?

> Next, reset your local "master" to "origin/master":
> 
> git checkout master
> git reset --hard origin/master
> 
> You might want to omit --hard or use --soft -- depending on whether
> you'd like to keep your local changes in the index and/or in the work
> tree.

I guess hard would be the best option for me.

> You then have your "master" "synchronized" with the same-named branch
> as held at the remote server, so whatever you commit on it will push
> cleanly to origin--of course, unless someone will have updated it by
> their code in the mean time.

No problem with that.

> Having had local "master" reset to its remote state and its previous
> state kept in a branch or tag, you might wish to bring those changes
> back on the "rewound" state of "master"--by merely merging them
> (`git merge`) or using cherry-picking (`git cherry-pick`).

Welll, I would do that in due time.

> You might also consider rebasing.  If your original problem was to deal
> with the case where you have a series of local commits on a branch
> you'd like to push "upstream" but the upstream version of your branch
> got updated so your commits can't be used to fast-forward it (don't push
> cleanly) then you might use `git rebase`:
> 
> git fetch origin
> git checkout master
> git rebase origin/master
> 
> Would first reset your local "master" to point to the same commit
> "origin/master" points at then find a point where the local "master" and
> "origin/master" have diverged and then try to apply all the commits
> your "master" have past that point--one-by-one--to that reset state.
> The result, if all comes smoothly, will be the local "master" having all
> your "unpushed" commits rebased onto the state of "origin/master", which
> means you will be able to safely push your "master" to "origin".

Fine, but too complex for me. And origin hasn’t been updated.

> TL;DR
> Don't try to abuse the stash.  It's only use case is to save uncommitted
> changes--those kept in the work tree compared to the index, and
> those kept in the index compared to HEAD--and, possibly, untracked
> files as well.  That is, the stash keeps whatever changes would have
> constituted a commit.  If you need to preserve a series of commits just
> preserve them naturally--by having a branch or a tag of them.

Now I understand what I did wrong. I had expected from stash to behave
like a branch.

Many thanks for your help again,


Pablo
-- 
http://www.ousia.tk

-- 
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] dropped stash without applying

[Pablo Rodríguez]

On 01/26/2016 09:42 AM, Konstantin Khomoutov wrote:
> On Tue, 26 Jan 2016 06:56:27 +0100 Pablo Rodríguez wrote:
> 
>> I’m a git newbie and I wanted to stash a git repository containing
>> text files. There were some uncommited changes in some files.
>>
>> I stashed with "git stash".
>>
>> I corrected the two typos, committed with "git commit -p" and pushed
>> changes to GitHub with "git push origin master".
>>
>> Since this was my first stash, I dropped the stash without having
>> applied it first (I didn’t know that I had to apply it).
> 
> Didn't the word "drop" ring any bells for you? ;-)
> To drop is to get rid of, throw away etc.

Many thanks for your lengthy and highly instructive reply, Konstatin.
(And sorry for my excessively delayed answer [too much chaos here].)

Dropping a stash makes sense to me now. But as I did it was that the
files were reverted to its previous state before the stash.

Thinking about it now, even if remove or delete were used instead of
drop, I would make the same mistake. For the newbie, it didn’t help me
to read about stash drop before stash pop.

And what I had to do was to create a branch from the stash (reading it
right now from “Pro Git” book). Or at least, this is what I have to do
in the future.

> For the future, note that in normal (non-bare) Git repositories by
> default all "drastic head movements" are recorded in the so-called
> "reflog" which can be examined/controlled via the `git reflog` command.
> Branch deletions / forced updates (say via `git reset --hard` or
> `git branch -M`) are all recorded there.  Stash drops too.  This is a
> "safety belt" intended for recovering from occasional "oopsies" like
> yours.

Many thanks for this advice. What I see know is that "git reflog" only
shows a limited number of movements. Not all of them as with "git log".

As far as I know, all my repos are normal. I don’t know how to get
non-bare repositories (no idea of what these might be).

Many thanks for your reply,

Pablo
-- 
http://www.ousia.tk

-- 
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] does `git commit` modify $GIT_DIR/index?

[ozzloy]

for the benefit of future git travelers, here is a small correction to the
prior post.  the command i use is this:

git checkout-index --prefix="${stage_dir}/" --all

the trailing slash in the prefix is important.  without it, the script was
trying to checkout files like "$GIT_WORK_TREE/foo" to locations like
"/tmp/tmp.UDIlPsCQamfoo" instead of "/tmp/tmp.UDIlPsCQam/foo".  this is
because mktemp returns values like "/tmp/tmp.UDIlPsCQam" without a trailing
slash.

less importantly, the '--work-tree="$PWD"' is unnecessary because PWD is
the default for the working directory.


On Tue, Jan 5, 2016 at 12:15 PM ozzloy  wrote:

> thanks for the tip about checkout-index!
> the idea to use git checkout-index works, but it took me a while to
> figure it out completely.  you're right, it ends up being much shorter
> and does a lot less stuff than the other method.  here's the
> checkout-index that worked for me:
>
> git --work-tree="$PWD" checkout-index --prefix="${stage_dir}" --all
>
>
> "why are you concerned with the state of the file representing
> the index"
>
> partially because i didn't know about checkout-index.  this is
> definitely helpful.  i've converted to using this for now.  however,
> even though this works, i'm still exploring the in-place method for 2
> reasons:
>
> 0. it seems like it would be much more efficient.  it only modifies
> files that have changed since the last commit, rather than making copies
> of all project files in a new directory.  so far, the
> checkout-index method works fast enough, but i've only used it on
> small projects.
>
> 1. it is unclear to me how difficult it is to get some of the projects
> i work on to build in arbitrary directories.  some of the projects i
> work on are built via eclipse and configuring eclipse to build in a new
> location of the files has been difficult.  probably i can find a way to
> convince eclipse to build in other places.  i'm not sure, so i'm
> exploring.  but even if i do get that to work, then i've only got it
> to work for eclipse and i'll have to look into the specifics of the next
> build environment, and the one after that, and so on.
>
> thanks for the suggestion!  it's working great!
>
>
> On Wed, Oct 28, 2015 at 10:30 AM Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
>
>> On Tue, 27 Oct 2015 22:12:51 -0700 (PDT)
>> ozzloy  wrote:
>>
>> > i am writing a script to test exactly what's staged for the next
>> > commit. this should work even on root commit, and in orphan branches,
>> > so using stash by itself doesn't work because there's no HEAD for
>> > stash to stash on.
>> >
>> > my current solution in those situations is to:
>> > 0 commit the index
>> > 1 stash unstaged unignored files
>> > 2 run tests and save result
>> > 3 stash pop
>> > 4 delete HEAD
>> > 5 return the saved test result
>> >
>> > my concern is that step 0 might modify the index.
>> >
>> > if there's a better way to test the index, i'd be happy to hear it
>>
>> I have one ide and one question.
>>
>> The idea: use `git checkout-index` with a relocated work tree
>> (something like the result of running `mktemp -d /tmp/gitXX`)
>> and build there.  This will basically replace step 0 and remove
>> steps 1,3-5.  Basically, you'd do:
>>
>>   DIR=`mktemp -d /tmp/gitXX`
>>   trap "rm -rf '$DIR'" TERM INT EXIT
>>   git --work-tree="$DIR" checkout-index --all
>>   make test -C "$DIR"
>>
>> The question is: why are you concerned with the state of the file
>> representing the index at all?  As I've already hinted, the behaviour
>> of the index file during committing appears to be not documented which
>> means Git is free to actually update the index when it records a commit.
>> So what would maintaining the index's file mtime etc would buy you?
>>
>

-- 
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] Objects randomly corrupting

[Konstantin Khomoutov]

On Wed, 9 Mar 2016 15:01:01 -0800 (PST)
"Jerome O'Connor"  wrote:

[...]
> so yeah, 4 separate operations, 9 different corrupted objects. Any
> ideas what's happening here and how i can fix it? 
> I'm running Win7 Ultimate SP1. Drive F: is a 1TB windows software
> RAID 1. Drives D: and G: are 1TB partitions on the same 2TB single
> HDD. Using TortoiseGit 1.8.11 and
> git 1.9.4.msysgit.1
> and the corruption happens regardless of whether i'm using the
> tortoisegit gui, or the command line for git

Before other things, can you verify it's not memory errors (check out
memtest and memtest86+, run them both, for several hours) or disk errors
(use smartmontools for Windows and do a "long" / "offline" test of your
drives -- if you're not running an expensive RAID array which should
have certain knobs to run SMART checks of its own).

I mean, if your box does not have ECC RAM, occasional bit flips might
lead to what you're observing.

Trying a recent version of Git is also a good idea--it's now following
the upstream releases pretty close.  160GB archive also appears to be a
good candidate for processing with 64-bit software (though using 32-bit
Git should not matter for the kind of problem you're facing).

-- 
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.