Re: [git-users] git clean vs git status re .gitignore
On Tue, Aug 19, 2014 at 10:06:23PM -0400, Paul Smith wrote:
> One of the platforms I need to build on is Windows and we're using
> cmake to generate MSVC project files. MSVC allows you to build one
> of a small number of different "types" of output, such as "Debug",
> "Release", etc. Additionally, we have many different "targets" that
> are built: one for each library, executable, unit test program, etc.
>
> The way MSVC (or cmake, I'm not sure) organizes the output is that
> for a source directory SRC and a target SOMELIB built for "Debug"
> for example, the object files will be:
>
> SRC/foo.cpp
> SRC/SOMELIB.dir/Debug/foo.obj
>
> Note that here only SRC and SRC/foo.cpp are actually part of the
> Git repository; the other directories/files are not tracked.
Is there a specific reason you aren't using a separate build
directory? (AFAIU this is the convention for CMake.)
> Now, adding all the target directories ("SOMELIB.dir") to .gitignore
> individually is a big pain since there are so many. And adding "*.dir"
> to .gitignore seems like it might match some stuff that we might want.
>
> So, I added the "type" directories to .gitignore, like this:
>
> Debug
> Release
>
> (also, these directories are used by Mac OS Xcode so need to be ignored
> anyway).
>
> This works great for "git status"; it doesn't show the "SOMELIB.dir"
> directory as "untracked" because after the .gitignore stuff is through
> getting rid of files that is just an empty directory.
>
> However after some head-banging today I discovered that "git clean
> -fdX" (which is what I normally use to clean out workspaces) won't
> delete these files. Apparently "git clean -X" uses a different
> algorithm than "git status" for matching .gitignore contents and since
> SOMELIB.dir is not ignored, "git clean" skips over it rather than
> looking inside it for ignored files.
>
> So I had this situation where I had stale object files in my workspace
> and "git status" showed I had no untracked files, but "git clean -fdX"
> didn't clean up the stale object files.
>
> Does it seem incorrect to anyone else that "git clean -X" doesn't delete
> all the files in your workspace that are considered ignored by "git
> status"?
How does `git clean -fdx` behave?
I've never really understood the difference between -x and -X, but
I've always used only -x and it behaves exactly the way I expect it
to.
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus
Perl is another example of filling a tiny, short-term need, and then
being a real problem in the longer term.
-- Alan Kay
pgp4UkikVDciR.pgp
Description: PGP signature
[git-users] git clean vs git status re .gitignore
Hi all. I got pretty frustrated today by some unexpected behavior of
git clean; I wonder if folks thought it was a real problem or just
PEBKAC.
One of the platforms I need to build on is Windows and we're using cmake
to generate MSVC project files. MSVC allows you to build one of a small
number of different "types" of output, such as "Debug", "Release", etc.
Additionally, we have many different "targets" that are built: one for
each library, executable, unit test program, etc.
The way MSVC (or cmake, I'm not sure) organizes the output is that for a
source directory SRC and a target SOMELIB built for "Debug" for example,
the object files will be:
SRC/foo.cpp
SRC/SOMELIB.dir/Debug/foo.obj
Note that here only SRC and SRC/foo.cpp are actually part of the Git
repository; the other directories/files are not tracked.
Now, adding all the target directories ("SOMELIB.dir") to .gitignore
individually is a big pain since there are so many. And adding "*.dir"
to .gitignore seems like it might match some stuff that we might want.
So, I added the "type" directories to .gitignore, like this:
Debug
Release
(also, these directories are used by Mac OS Xcode so need to be ignored
anyway).
This works great for "git status"; it doesn't show the "SOMELIB.dir"
directory as "untracked" because after the .gitignore stuff is through
getting rid of files that is just an empty directory.
However after some head-banging today I discovered that "git clean
-fdX" (which is what I normally use to clean out workspaces) won't
delete these files. Apparently "git clean -X" uses a different
algorithm than "git status" for matching .gitignore contents and since
SOMELIB.dir is not ignored, "git clean" skips over it rather than
looking inside it for ignored files.
So I had this situation where I had stale object files in my workspace
and "git status" showed I had no untracked files, but "git clean -fdX"
didn't clean up the stale object files.
Does it seem incorrect to anyone else that "git clean -X" doesn't delete
all the files in your workspace that are considered ignored by "git
status"?
--
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] Review changes in a concrete line of code
> From: Norike Abe
>
> Is there a command to compare all the changes between two given commits a
> file has suffered, in a given set of lines of code?
There are a number of Git commands to investigate problems like this,
including "git blame" and "git diff".
A tool that I use is "git-history", which is a script to extract all
of the versions of a file that are contained in the current branch.
Once you have all versions of a file, you can use regular Unix tools
to determine many things about the history of the file.
Dale
--
#! /bin/bash
# Get the historical versions of a file.
# First argument is the path of the file in question. It is
# interpreted as GIT interprets path arguments.
# Historical versions of the file will be extracted as
#basename.-mm-ddThh:mm:ss
# in the current directory, where the time is when "git log" notes the
# file (which I think is the first occurrence of that file content).
# The time is shown in the current local timezone.
FILE="$1"
BASENAME="${FILE##*/}"
git log --pretty=tformat:"%H %ci" --date=local -- "$FILE" |
while read HASH DATE TIME ZONE
do
R=( $( git ls-tree --full-tree $HASH "$FILE" ) )
if [[ -n "$R" ]]
then
NAME="$BASENAME.${DATE}T${TIME}"
echo "Creating $NAME..."
git cat-file -p ${R[2]} >$NAME
fi
done
--
--
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] Review changes in a concrete line of code
On Tue, Aug 19, 2014 at 3:58 PM, Norike Abe wrote: > Excuse me if the terminology I use is not exactly the one used in Git. I'm > not very used in this system... > > Imagine you suspect a line of code (or a method) in a file in your project > has changed but you don't know when; and you want to check if that line has > ever changed, when this happened, who did the commit(s) and of course see > the diff(s). You can use `git blame` to see who last changed a line and when. If you are a fugitive user (excellent Vim plugin) then you can use ':Gblame' and jump around in history a bit as well. > Is there a command to compare all the changes between two given commits a > file has suffered, in a given set of lines of code? AFAIK you'll always see all changes to a file. The command is `git diff -- `. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- 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] Review changes in a concrete line of code
git-log comes to the rescue. You can pass --since DATE to git-log, and can even give a path or file name, too. For example: git log --since '4 days' src/susp.c will display every commit in the last 4 day that modified src&susp.c On 19 Aug 2014 15:59, "Norike Abe" wrote: > Excuse me if the terminology I use is not exactly the one used in Git. I'm > not very used in this system... > > Imagine you suspect a line of code (or a method) in a file in your project > has changed but you don't know when; and you want to check if that line has > ever changed, when this happened, who did the commit(s) and of course see > the diff(s). > > Is there a command to compare all the changes between two given commits a > file has suffered, in a given set of lines of code? > > -- > 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.
Re: [git-users] post-merge hook not running
I ended up using icrond to launch my "hook" whenever a file in /salt/.git/logs was modified, wich fill my need. Thank you again! On Monday, August 18, 2014 6:18:11 AM UTC-4, Konstantin Khomoutov wrote: > > On Fri, 15 Aug 2014 07:55:36 -0700 (PDT) > Etienne Pouliot > wrote: > > > > > I'm trying to get my post-merge hook to run but I can't get it to > > > > work. > > > [...] > > > > #git pull > [...] > > > The merge did not happen because `git merge` (which was run as a > > > part of the `git pull` work flow) performed a fast-forward. > [...] > > That make sense. > > > > Any other way to run a hook everytime I do a "git pull" ? > > I think no, there's no way to do that (you can try to find the word > "pull" in the githooks manual page). But the next question is why you > need to have a hook for this in the first place? Hooks can't be > committed (and hence be made automatically available and armed in > remote repositories) and hence they have to be considered to be "local > configuration". If so, why not just have a wrapper program (a shell > script could be the simplest way to make one) which calls `git pull` > and dances around its outcome? > -- 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] git svn "unable to chdir up to '.'"
I use a local git with a SVN remote server, everything works fine but after my last reboot I get the following error with everything related to git svn. unable to chdir up to '.' -- 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] Changes lost after Git automatic (three-way) merge
Hi, I've been experiencing some weird merges lately, where Git's automatic three-way merge will take the wrong change. Let's say I created a branch *develop* off of *master*. Here's the situation given a line in a particular file: *develop:* line has no change *master:* line changed I am on *develop* and I do git pull origin master. There won't be any merge conflicts for that file, but Git will ignore the change on branch-B and keep mine. It SEEMS like Git is using the "ours" merge strategy, but there is nowhere I am specfiying to use this merge strategy, including in my git config. It's also not happening consistently. Has anyone experienced this before or have any insight? I can provide more information if necessary. -- 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] Review changes in a concrete line of code
Excuse me if the terminology I use is not exactly the one used in Git. I'm not very used in this system... Imagine you suspect a line of code (or a method) in a file in your project has changed but you don't know when; and you want to check if that line has ever changed, when this happened, who did the commit(s) and of course see the diff(s). Is there a command to compare all the changes between two given commits a file has suffered, in a given set of lines of code? -- 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] Re: Breakage in UMTSFemto GIT repository
On Friday, 8 August 2014 18:11:35 UTC+2, ab wrote: > > Hi all, > > I am trying to create a GIT clone and followed below steps > 1. Set Environment Variables > a. export > PATH=/auto/mitg-sw/tools/debian/git/bin:/auto/mitg-sw/tools/bin:$PATH > 2. Generate Keys > a. ssh-keygen -t rsa > b. chmod 700 ~/.ssh > c. chmod go-w ~ > d. cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys > e. /auto/mitg-sw/oak/bin/git-request-access > 3. Clone Creation > a. git-ws qa/autotest autotest.mainline > 4. Popultaing components > a. Goto mainline directory - ‘cd autotest.mainline’ > b. git populate utils suites/BaseClasses suites/UMTSFemto > > > > Upto step 4(a) everything is working fine but when I am trying to fire git > populate utils suites/BaseClasses suites/UMTSFemto command I get below error > > anisal@rtppnkvm36-vm1 Temp]$cd autotest.mainline/ > anisal@rtppnkvm36-vm1 autotest.mainline]$git populate utils > suites/BaseClasses suites/UMTSFemto > suites/BaseClasses : Could not find a suitable local directory for a git > repository cache. > suites/UMTSFemto : Could not find a suitable local directory for a git > repository cache. > utils : Could not find a suitable local directory for a git > repository cache. > suites/UMTSFemto : Populated suites/UMTSFemto > suites/UMTSFemto : error: pathspec 'suites/UMTSFemto' did not match any > file(s) known to git. > suites/UMTSFemto : Did you forget to 'git add'? > suites/UMTSFemto : Error: Could not checkout in suites/UMTSFemto! > (perhaps due to a bad default HEAD on server?) > > utils : Populated utils > utils : Resetting current branch 'mainline'... > suites/BaseClasses : Populated suites/BaseClasses > suites/BaseClasses : Resetting current branch 'mainline'... > suites/BaseClasses : HEAD is now at ef45143 CSCuq30696 - [SAMOG] 17.0 > behavior change with CSCuo04492 fix on 16.0 cases > Waiting for 1 package to finish loading... > Checking out files: 100% (3264/3264), done.3% (110/3264) > utils : HEAD is now at ae4ce1a New files added > Errors were encountering while populating suites/UMTSFemto > anisal@rtppnkvm36-vm1 autotest.mainline]$ > anisal@rtppnkvm36-vm1 autotest.mainline]$ > > > > > Can anybody please help me on this !!! > > > Hey ab, it looks to me like this has nothing to do with git itself, rather with whatever tool you are trying to use. I've never heard of a git command called git-populate, so it must be something specific to this "UMTSFemto" thing which I know nothing about. I don't think anybody in this mailing list could help you with this, maybe you'll have a better luck by reaching to whoever maintains "UMTSFemto" instead? -- 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] Commit Refactoring: Best Practice
On Tue, 19 Aug 2014 01:22:24 -0700 (PDT) Sverre Moe wrote: > What is the preferred Git best practice when it comes to commit > refactoring? > > When I refactor some Java files in Eclipse, Git recognizes it has > been renamed and places the file under "Changes to be committed". > I addition because the Java class file has been renamed the Class and > all other classes that has references to it is listed under "Changes > not staged for commit". [...] > Should I first commit the rename, and then commit the changes? [...] > What is the preferred Git best practice when it comes to commit > refactoring changes? My advice is to record the rename of the file and classes in it in a single commit. The reasoning is: this is a single change from the logical standpoint. The fact you *observe* Eclipse splitting your changes in two steps is just an artifact of how this is implemented in Eclipse. On a bare command-line you'd see these changes "combined" as being not staged for commit *unless* you have used `git mv` to rename the file before modifying it. Eclipse is just trying to be helpful for some imaginary general case. Another perspective is that Git is said to track not files but rather project contents (with file renaming being irrelevant to the evolution of the project's code). So you're advised to rather concentrate on how the contents (code) is change and only consider renames as a byproduct of the fact the code is organized in files. You might find this [1] interesting to get the idea better. 1. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217 -- 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] Commit Refactoring: Best Practice
What is the preferred Git best practice when it comes to commit refactoring? When I refactor some Java files in Eclipse, Git recognizes it has been renamed and places the file under "Changes to be committed". I addition because the Java class file has been renamed the Class and all other classes that has references to it is listed under "Changes not staged for commit". So I get this in Git: Changes to be committed: (use "git reset HEAD ..." to unstage) renamed:src/main/java/com/company/utils/MyConnectionFactory.java -> src/main/java/com/company/utils/ConnectionFactory.java Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: src/main/java/com/company/utils/ConnectionFactory.java Should I first commit the rename, and then commit the changes? If I add the modified changes to be committed with the rename I get: Changes to be committed: (use "git reset HEAD ..." to unstage) modified:src/main/java/com/company/utils/ConnectionFactory.java What is the preferred Git best practice when it comes to commit refactoring changes? -- 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.
