Re: [git-users] I'm struggling with the basics (2.2)

[Dale R. Worley]

> From: icevermin 
> 
> I'm trying to figure out how to do the "check status stuff"

In general, it's easier to learn Git by experimenting, starting with
an empty directory, setting up a repository for it, then adding a few
files and seeing how Git handles them.  Starting by applying Git to an
existing project is much more confusing.

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.

Re: [git-users] .gitignore question

[Dale R. Worley]

> From: wtriker@gmail.com
> 
> I have some files that I want to ignore but can't seem to come up with the 
> correct format. There are multiple sub-directories with the same path that 
> I want to ignore. Specifically, the are '/system/cache' and 
> all start with 'cache.'. The .gitignore entry I am using is:
> 
> system/cache/cache.*
> 
> But that does not work. What is the correct syntax to ignore these files? 

One solution is to put "cache" in each /system/.gitignore file.

I would start by reading the rules for how gitignore entries are
interpreted, which is in the "gitignore" manual page.  In particular,
I see:

   Two consecutive asterisks ("**") in patterns matched against full
   pathname may have special meaning:

   ·   A leading "**" followed by a slash means match in all directories.
   For example, "**/foo" matches file or directory "foo" anywhere, the
   same as pattern "foo". "**/foo/bar" matches file or directory "bar"
   anywhere that is directly under directory "foo".

This suggests the answer is to put "**/system/cache" in the top-level
.gitignore file.

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.

Re: [git-users] Branching with dependencies

[Dale R. Worley]

> From: Andrew 
> 
> My problem: suppose that I have two independent branches A and B, which may 
> not even touch the same files. Now I start a new development branch C which 
> wants to use features from different commits in A and B. I'd like C to to 
> branch off BOTH A and B.

You can do such a thing, if the base commit of C lists two commits,
one from A and one from B, as parents.  This is what happens normally
when you execute a merge, one parent is the one that was checked out
in the working copy, and another parent is the commit that was merged
from.

But it's not clear to me that it would be worth the bother in your
case.  Having Git record that commit 2 is the descendent of commit 1
is only useful if a comparison of the two shows something useful, that
a diff (or "delta") taken between the two clearly expresses the
changes from the one to the other.  If C is a mashup of features taken
from A and B, is there enough correspondence between C's files and A's
files to make a diff useful?

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.

Re: [git-users] Git vs Subversion

[Dale R. Worley]

> From: Akira Tsuchiya 

> Do you think Git will get more popularity than Subversion and Subversion 
> will be obsolete in the near future?

Git may become more popular than Subversion, but Subversion won't
become obsolete in the overall market.  (Consider that there are
hundreds of programming languages being used today.  Most of them
aren't very popular, but none that are being used to write new code
are obsolete.)

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.

Re: [git-users] Re: Behaviour of "git add --all" in 1.8.5

[Dale R. Worley]

> From: Thomas Ferris Nicolaisen 

> > Now running either of these commands results in `fatal: pathspec '.' did 
> > not match any files` as output.

> This sounds like a bit of a corner-case feature (albeit it is a useful 
> warning, so it's probably intended), so perhaps it was not flagged high 
> among the release notes, which in any case you can find on the Git 
> development mailing list [1].

But it doesn't say "warning:", it says "fatal:", and presumably has a
return status of 1.  That's a more significant difference.

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.

Re: [git-users] how to delete a commit?

[Dale R. Worley]

> From: "Jagadeesh N. Malakannavar" 

> May I know how to delete one intermidate commit? 
> For ex: git one line log 
> 
> c4ab7b9 commit 6
> a2396a2 commit 5
> 85020f2 commit 4
> 8779285 commit 3
> 4c0b83b commit 2
> 4498573 commit 1
> 
> I want to delete 
> 8779285 commit 3
> 
> how to do that?

The first thing is to specify what you mean by "delete a commit".  Do
you mean that you want the change (the delta) that was introduced by
87792 to be removed from the code that is the later commits?  Or do
you want to bundle the changes that were made in 87792 with the
changes in 85050 into one new commit?

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.

Re: [git-users] BC3 tabs for each diff/merge

[Dale R. Worley]

> From: Werner Beroux 

> On Linux especially but generally for any diff/merge tool it would be nice 
> to have the possibility to run the tool multiple times to have it show the 
> diff/merge of all files at once in tabs.
> 
> For example currently Git mergetool would do something equivalent to:
> 
>1. bcompare left1 right1 merge2
>2. bcompare left2 right2 merge2
>3. bcompare left3 right3 merge3
> 
> It would be great to allow:
> 
>1. bcompare left1 right1 merge2 &
>2. bcompare left2 right2 merge2 &
>3. bcompare left3 right3 merge3
>
> This would show multiple tabs in Beyond Compare 3 and improve productivity 
> especially on diff/merges. I tried setting the tool manually for add '&' 
> after all command-line but it didn't work well. I guess it should be 
> supported directly inside Git to support launching an application multiple 
> times and wait for all processes to exit only at the end (i.e., wait for 
> all launched processes to exit).

The typical Un*x way to handle this is to write a script to do the
work.  Certainly you can get a script to run a bunch of things and
wait for them all to finish, e.g.,

#! /bin/sh
prog1 &
prog2 &
prog3 &
wait

And then you tell Git to use your script to do comparisons.

Is there a way to get what you want with a script?

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.

Re: [git-users] Git for windows behind a proxy: no address associated with name

[Dale R. Worley]

> From: Steven Masfaraud 

> git clone ssh://usern...@labserver.fr:2333/Path/Repositery/ LocalFolder/ 
> answers:
> ssh: labserver.fr: no address associated with name

There may be other problems, but what this message shows (if I'm
right) is that the host name "labserver.fr" doesn't have any addresses
associated with it in DNS.  So Git starts SSH and SSH tries to connect
to "labserver.fr", but it can't figure out what the network address is
for labserver.fr.

The first thing to check is that you got the name right.

The next thing is to see what DNS records your system can see for the
name.  If I have it right, this is the Linux system, so you can do:

$ dig any labserver.fr

and see what the results are.  Can you use labserver.fr in other
commands you execute from that system?

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.

Re: [git-users] gitk: file name too long

[Dale R. Worley]

> From: Tom Steynen 

> None of my colleagues who are working with the same repository have the 
> problem and I have already shortened the path the my clone directory.

One thing I'd check is whether the name of the repository directory on
my system is longer than the name on other people's systems.

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.

Re: [git-users] ignore files with hard definition

[Dale R. Worley]

> From: Gergely Polonkai 

> I don't know of any method built into git, but how about denying commits
> that modify the .gitignore file(s)? This way your hook must only check if
> the commit has modifications to any files called .gitignore.

My understanding is that you can write such a hook, one that examines
the files that will be changed and rejects the commit if it will
change files with certain names.

It is useful to have such a hook even if there is no concern that
users will not intend to change the files, because occasionally one
changes a file that one did not intend to change.

Make sure that there is at least one user that will not be stopped by
the hook.  Otherwise, there is no way to change the hard-defined files
without disabling the hook entirely.

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.

Re: [git-users] hook file encoding for text files

[Dale R. Worley]

> From: Philipp Kraus 

> I would like to check the file encoding on all text files, so how
> can I get all file types that are handled as text file from git.

Well, you first have to come up with a concrete definition of what
distinguishes a file as "a text file".  Then you have to determine
what is an acceptable "file encoding".  Those two tasks are probably
harder to do in a way that actually works in your environment than you
think it is.

After you've done that, I expect that writing the hook is
straightforward, though I'm not familiar how hooks works.

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.

Re: [git-users] Can you build git-remote-http with no dependencies on libcrypto and libssl?

[Dale R. Worley]

> From: dbmccro...@gmail.com
> 
> The issue is that git 1.8.3 has a dependency on libcrypto.so.6 and 
> libssl.so.6. Or more precisely, git-remote-http seems to have dependencies 
> on these libraries. On our RH5.6 boxes, not a problem as they are found in 
> /lib64. On RH6 (kernel version 2.6.32-431), big problem, they aren't found 
> at all when I run git, or do "ldd git-remote-http" to check the 
> dependencies. As best I can tell, these libraries are not included in the 
> RH6 standard installation. Now I could beg our IT to install the necessary 
> RPMs on our RH6 boxes (and yes it will take considerable groveling and 
> begging) but it doesn't seem that will solve the problem when our s/w is 
> installed by RH6 customers. They will presumably see the same:

This may or may not help you, but one possibility is to build an RPM
that states a dependency on the RPM(s) that contain libcrypto and
libssl.  Or rather, I think you can state a dependency on those
versions of the library.  Then, when customers try to load the new Git
RPM, it requires them to load the dependencies.  This assumes that the
customers actually have the dependency RPMs to load.

If you can't expect the customers to have the dependency RPMs, all you
can do is build a special version that doesn't contain the commands
(or whatever) that needs the dependencies.

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.

Re: [git-users] Avoiding a conflict when two commits add to a list

[Dale R. Worley]

> From: Andrew Steady 

> Whilst considering a refactoring exercise to alleviate the issue, I 
> wondered if there is instead a way to inform Git that certain files are of 
> a particular nature for which changes from both sides should be honored, 
> even if they affect the same or adjacent lines. There is the complication 
> of the delimiter of course - e.g. when you add a line at the end of a list, 
> the line beneath may need a delimiter adding or the line above have one 
> removing if you remove from the list.
> 
> I saw options on different merge strategies but couldn't understand any 
> difference in how the process at the line level.

My vague understanding is that you can tell Git to use any particular
merge program you want to.  (See merge.tool in the git-config man
page.)  So presumably, if you can define a merge program that will
merge these apparently-conflicting changes in a way that is always
satisfying, you can write a wrapper script that uses your merge
program for certain specified files and whatever the default is for
all other files.  Then Git should automatically handle the class of
conflicts you've described.

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] Core dumps

[Dale R. Worley]

I'm getting core dumps from "git add" (git version 1.8.3.1).  Are
there known problems of that sort, or should I try to make up a decent
bug report about it?

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.

Re: [git-users] Core dumps

[Dale R. Worley]

> From: "Philip Oakley" 

> So if you can determine the problem and how to replicate it, expecially 
> if you are able to confirm it on 1.9.0 I'm sure the dev's would be 
> happy.

OK, I'll work on it.  I just built a non-optimized 1.9.0, so I should
be able to get useful backtraces from the core files.

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.

Re: [git-users] Core dumps

[Dale R. Worley]

> OK, I'll work on it.  I just built a non-optimized 1.9.0, so I should
> be able to get useful backtraces from the core files.

Given the pattern of errors, I suspect the problem lies with files
that are being changed while "git add" runs.

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.

Re: [git-users] Weird commit order in "git log", commits missing etc. ...

[Dale R. Worley]

> From: tombert 
> 
> I am doing a clone from https://github.com/tcltk/tcl and trying to create a 
> changelog file from the git history.
> 
> When doing:
> ># git log a45650c^..0fb4a39 --pretty="format:%h" --reverse > test.txt
> I get 10140 lines of commits.
> [...]

I'm not an expert, but IIRC, a45650c^ means "the (first) parent of
a45650c", and "a45650c^..0fb4a39" means "all the commits which have
a45650c^ as an ancestor and have 0fb4a39 as a descendent" (both tests
being "inclusive").  There's no guarantee that the repository contains
a single, linear string of commits.  And IIRC, git-log is only
required to provide *a linearization* of the set of commits that are
selected, that is, there isn't a unique linear order that is
compatible with the "partial order" of commit ancestry.

But I might be wrong about this.  In any case, I suggest that getting
Git to show you the actual ancestry relationships would probably prove
illuminating.

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] Question about .gitignore

[Dale R. Worley]

> From: Chuck 

> Putting .gitignore inside the file itself doesn't negate it's behavior.
> Just seems like something that should be built in because a) no one wants
> to see this listed as an untracked file and b) no one wants this included
> in their actual project repository.

The primary purpose of .gitignore is to prevent Git from noticing
built files.  And since anyone else who has a copy of the project will
be building files with the same names as your built files, all
developers want a common .gitignore.

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] "git rm dirname" didn't work

[Dale R. Worley]

> From: lgp8...@gmail.com
> 
> I want to rm a directory from the repository. I use "git rm dirname", but 
> it didn't work. Somebody help me!

I'm not sure what problem you're seeing, but (according to the man
page) you can't remove a directory with "git rm dirname", you have to
do "git rm -r dirname".  Basically Git doesn't track directories, it
tracks files, and you have to tell Git to remove all files under that
directory name, and it won't do that without "-r".

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] Undoable reset hard

[Dale R. Worley]

> From: Johannes Müller 
> 
> I tried thinking of a way to prevent accidental deletion by git reset
> --hard command, as I recently faced such a problem. How can you write a
> wrapper replacing the command, so that it first does something like the
> following? It should create a new branch backup with all changes before
> resetting.
> 
> current_branch = git command
> git checkout -b backup_`date`
> git add -A && git commit -m "backup before git reset --hard"
> git checkout $current_branch
> actual git reset --hard command

That seems to be the normal way things like this are done in Git.  But
usually, the backup branch seems to be put in
refs/original/, e.g.,
refs/original/refs/heads/master.

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] fatal: Not a valid object name master^{tree}

[Dale R. Worley]

> From: Jirong Hu 
> 
> $ git cat-file -p master^{tree}
> fatal: Not a valid object name master^{tree}
> 
> I am reading the GIT Pro and GIT Internal. The command above doesn't work. 
> Can you help to fix it?

My guess is that "master" is a branch name, and so is a commit, not a
tree.  Since "master" isn't a tag, it can't be dereferenced.  But in a
lot of situations, it seems that a commit identifier can be used where
a tree identifier is expected, and the command will obtain the tree
within the commit.

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.

[git-users] Crashes in Git -- git add doesn't like the file changing

[Dale R. Worley]

I have been running a cron job that does a "git add" and "git commit"
of my entire home directory every minute.  It provides a record of
what I've been doing.  (Every night, I run a script to prune some of
the older commits to keep the disk usage under control.)

The "git add" would occasionally crash, leaving the Git lock file in
place.  After that, every minute, the two Git commands would complain
that there was a lock file in place.

Eventually, I worked out the general outline of the problem and its
solution.

Normally, "gid add" compresses a new file by calling the bzlib
library.  It does this by *mapping* the new file into memory and
calling a library function on the block of memory.  It looks like the
problem comes when the file is changed or deleted, causing some of
that block of memory to become un-mapped while bzlib is compressing
it.

The solution is to build Git with the NO_MMAP configuration option (in
the Makefile).  This forces Git to read the file in the ordinary way,
which is not confused if the file is being changed 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/d/optout.

[git-users] Infinite spawning of "git status"

[Dale R. Worley]

I ran into a failure which caused a "git status" process to spawn a
child "git status" process, which spawned another "git status" child
process, etc., for several dozen levels at least.  Does anyone know
what might cause this to happen?

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] Infinite spawning of "git status"

[Dale R. Worley]

> From: "Philip Oakley" 
> 
> Wild thoughts / just guessing :
> Any sub-modules in your repo?
> 
> Could be an accidental circular reference (within the various 
> .gitmodules files)

No, I'm definitely not using submodules.

> Could be a symlink somewhere creating a circular ref.

Unfortunately, it was set off by a cron job, and I have cron jobs
doing Git archiving of large parts of my file system, and there are
certainly circular symlinks hidden in various places.

What I'm really wondering is What can cause "git status" to start a
subprocess?  I would expect for efficiency's sake, only very rare
circumstances would cause that.  And knowing that, it would probably
make it easier to guess what the underlying cause is.

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] Infinite spawning of "git status"

[Dale R. Worley]

> From: "Philip Oakley" 
> 
> > Unfortunately, it was set off by a cron job, and I have cron jobs
> > doing Git archiving of large parts of my file system, and there are
> > certainly circular symlinks hidden in various places.
> 
> Definately worth looking then ;-)

I've got a reproducible test case now, and for the entire stack of
"git status" processes, I have their CWDs, command lines, and
environments.  So I should be able to trace git-status and determine
exactly how it is freaking out.

There may be some submodule issues involved -- the repository is not
in the top level directory, but core.worktree is '/', and at least
some messages I'm seeing suggest that Git sees the repository as a
submodule.

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] git showing modified files right after branch chekout

[Dale R. Worley]

> From: Stas Fedotov 
> 
> I am using git on Cygwin. 
> 
> Today I figured out that this is .gitattributes file which is messing the 
> stuff. .gitattributes contains only 
> * text = auto
> 
> After removing the file - problem was gone.
> 
> But I still wonder why? Because the both git-scm book and github tutorial 
> on lineendings told that .gitattributes should solve my problem.

My guess is that it involved line endings:  somehow, the file as it is
checked out does not match git-status's expectations, and so it is
flagged as being changed.  It seems like it must be a bug in some way.

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.

[git-users] "git status" spawns processes forever

[Dale R. Worley]

I've tracked down the problem I've been having with "git status"
spawning a subordinate "git status" which spawns a subordinate "git
status", etc.

As someone suggested, the root problem is that the "git status" sees
the repository *itself* as a submodule, and so the usual recursion
where "git status" incorporates the statuses of each included
submodule causes infinite recursion.

The reason for this recursive submodule situation is that the
repository is for capturing the state of a subset of the system's file
tree (specifically the directories /boot /etc /opt /srv /usr), so
core.worktree is /.

But an abetting reason is that while updates were directed to ignore
the repository directory itself (both through exclusion and that
git-add wasn't told to examine the parent directory), during some
early experimentation I had unintentionally added the repository's
parent directory to the repository itself, and I have a hard time
remembering that with Git, once something is added to a repository, it
has to be explicitly removed, exclusions do not remove the visibility
of things already in the cache or commits.

Once I did a "git rm -r" to remove record of the repository's parent
directory from the repository, "git status" started working correctly.

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] bad repo

[Dale R. Worley]

One thing you can do is run "git fsck" on the repo.  It will check
whether it thinks the repository is properly structured.

> From: Konstantin Khomoutov 

> 1) Copy (literally) the whole project directory onto a
>filesystem/storage which is in the known good state.
> 2) Copy it again somewhere else to have a "reference" "post-mortem"
>snapshot.
> 
>Any recovery procedures are then to be taken on the copy obtained on
>step (1).  If you think you've spoiled it during the steps you'll
>be carying, just replace it with the copy obtained on step (2)
>and start over.

Actually, "If you think you've spoiled it during the steps you'll be
carying, just make *another* copy of (2) and replace (1) with the new
copy."  Do not change copy (2) until you *know* your problem is
solved.

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] git log in XML format

[Dale R. Worley]

> From: Yves Goergen 

> I'd like to suggest adding the XML output format to the git log
> command so that this information can be parsed without any
> uncertainties caused by the actual commit message content. I don't
> care much about the exact XML schema. The SVN schema may serve as a
> starting point, but Git probably needs other elements for its data.

Well, you could simulate it by using git-log to get the commit hashes
and then using "git cat-file -p [commit hash]" to get the information
about each commit.  The cat-file output isn't very difficult to parse,
and doesn't seem to suffer from ambiguity.

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] Convert file system with backup into git repo

[Dale R. Worley]

> From: George Georgiev 
> 
> I am researching how I can convert file system with backup history into a 
> git repository.
> 
> I would like to do this in phases. The first phase is to create a shallow 
> repo with only the head files. And then I would like to unshallow it step 
> by step. The goal is to have a valid git repo to start working with asap.

The details depend on the specifics of your situation.  But as long as
you can create copies of the file trees which are the historical
snapshots, you can add them to the repository and string them together
to form a series of commits.  The problem is that adding a commit to
the *beginning* of the chain requires a bit of work, because you have
to recreate all of the later commits so they reference the first
commit.  I don't think there's a "porcelain" command to do that, you
have to use "plumbing" commands to recreate each commit in the chain
one by one.

I don't know of any references, but following is a short Perl program
I use to prune out some of the commits in a repository if they are too
closely spaced together compared to their time in the past.  It shows
how you go about recreating a chain of commits.

Dale

#! /bin/perl

use strict;

# Process the -d switch, which must have a numeric argument.
my($debug) = 0;
if ($ARGV[0] =~ /^-d([\d]+)$/) {
$debug = $1;
print STDERR "\$debug = $debug\n";
shift;
}
die "Unknown argument(s): ", join(' ', @ARGV) if $#ARGV >= 0;

# This is the rate at which commits are to be retained:
my($rate);
# At a time N in the past, commits should be spaced at most N/$rate
# apart.
# Thus, larger $rate values mean to keep more commits around.
# The rate is stored in the Git configuration as time-warp.rate.
# If the user entered it on the command line, it would be easier for
# the user to fumble-finger a small value and delete much of the
# history he wanted to save.
my($config_name) = 'time-warp.rate';
my($command) = 'git config ' . $config_name;
chomp($rate = `$command`);
my($r) = $? >> 8;
if ($r != 0) {
warn "Could not obtain Git configuration value '$config_name'.\n";
die "Error executing '$command': exit code $r\n" if $r;
} elsif ($rate !~ /^\d+$/ && $rate >= 1) {
die "Rate value '$rate' is syntactically incorrect or less than 1.\n";
}
print STDERR "\$rate = $rate\n" if $debug;

# Get the hashes and times of the commit history.
# Note that we are assuming that the current branch of the repository
# is the branch to be operated upon.
$command = "git log --pretty=tformat:'%H %ct'";
print STDERR "\$command = $command\n" if $debug >= 3;
open(GIT, "-|", $command) ||
die "Error executing '$command' for input: $!\n";
# Note that "git log" lists commits going back in time, so @hashes and @times
# will describe the latest commits first.
my(@hashes, @times);
while () {
chomp;
my($hash, $time) = split;
push(@hashes, $hash);
push(@times, $time);
print STDERR "\$hashes[", $#hashes, "] = $hash, \$times[", $#times, "] = 
$time\n" if $debug >= 2;
}
close GIT || die "Error closing '$command': $!\n";

# Get the "now" time, which is the time of the last commit.
my($now) = $times[0];
print STDERR "\$now = $now\n" if $debug;

# Now, working from oldest to newest, look at each commit and decide whether
# to recreate it.
# The last commit we've recreated and its time.
my($last_commit) = '';
my($last_commit_time) = 0;
my($commits_created) = 0;
print STDERR "\$last_commit = $last_commit, \$last_commit_time = 
$last_commit_time\n"
if $debug;
# Cycle through the commits from the oldest to the newest, recreating
# the commit chain, retaining the commits we desire.
for (my $i = $#hashes; $i >= 0; $i--) {
print STDERR "\$i = $i, \$hashes[$i] = $hashes[$i], \$times[$i] = 
$times[$i]\n"
if $debug;
# Test if commit $i-1 (the next-newer commit than this one) is
# close enough to $last_commit that we can omit creating a new
# commit from this one, commit $i.  We always generate a new
# commit from commit 0, which is the newest.
if ($i > 0 && $debug) {
print STDERR "\$times[", $i-1, "] = $times[$i-1], \$last_commit_time = 
$last_commit_time, \$now = $now, \$last_commit_time = $last_commit_time\n";
print STDERR $times[$i-1] - $last_commit_time, ' > ', ($now - 
$times[$i-1]) / $rate, "\n";
}
if ($i == 0 ||
$times[$i-1] - $last_commit_time >= ($now - $times[$i-1]) / $rate) {
print STDERR "Recreate commit $i: $hashes[$i]\n" if $debug;
# Commit $i-1 (the next-newer commit than this one) is too far from
# the last new commit we created, so we have to create a new
# commit out of commit $i.
$last_commit = &create_new_commit($hashes[$i], $last_commit);
$last_commit_time = $times[$i];
$commits_created++;
print STDERR "\$last_commit = $last_commit, \$last_commit_time = 
$last_commit_time\n"
if $debug;
}
}

# Set the HEAD to the new commit

Re: [git-users] Convert file system with backup into git repo

[Dale R. Worley]

> From: George Georgiev 
> 
> >  The problem is that adding a commit to the *beginning* of the chain 
> > requires a bit of work, because you have to recreate all of the later 
> > commits so they reference the first commit. 
> 
> Are you certain about this. At first pass reading through the git
> shallow.c code I am having the feeling that I will be able to avoid
> this with creating the objects with a shallow flag. Then when I need
> to add a parent I could just attach the parent and unregistered the
> object as shallow without a need to recreate it. (exactly as it
> seems --unshallow works)

I'm not familiar with "shallow", but as I understand it, it fetches
only the latest commits from a repository and inserts them into a new
repository.  Thus, the oldest commit in the chain has a "dangling
pointer" to its parent.

The difference between that and the situation you describe is that
adding a new commit to the beginning of the commit chain changes the
hashes of all the commits, because the information that does into the
hash function to get the commit name includes the hash of the parent
commit.  "Shallow repositories" work because you already know the
proper hash for the latest commit.  You even know the proper hash for
the first commit that you're fetching.

But if you want to add a parent to the current root commit, that
changes the information in the current root commit, which changes its
hash.  And in the *next* commit, you have to update the parent
pointer, which changes *its* hash, etc.

But it's not tremendously difficult to recreate a chain of commits.

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] Out of memory while cloning large (cca. 48000 commits) SVN repo

[Dale R. Worley]

> From: Gergely Polonkai 

> to dump all the repo into a new Git repository. It ran for around 24
> hours to report an Out of memory error at the end. Although I realised
> since then that this is a somewhat bad idea, but I still don’t think
> it should happen this way. Or should it?

It looks like some data structure is kept in memory, and that data
structure grows very large when cloning/converting your repository.

In a perfect world, the Git code would be improved to allow the data
structure to be put on disk.  But in order to finish your task, the
fastest solution is probably to add a large swap file/partition to
your system temporarily, and then run the process again.

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] Convert file system with backup into git repo

[Dale R. Worley]

> From: George Georgiev 

> My concern is time to have, not difficulty to do. I would like users to
> have a git repo as soon as possible. In same cases creating full repo might
> take many hours.

I don't see the trouble with that.  You can create a shallow
repository, or rather, a shallow chain of commits within a repository,
and make it available to your users to clone.

Then you create the full chain, which is a different branch in the
same repository.  When users have their working directories in a good
position, they switch to the full branch.  Any commits that they've
added to the shallow chain, you rebase onto the full branch and
commit.

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] Out of memory while cloning large (cca. 48000 commits) SVN repo

[Dale R. Worley]

> Do you have insanely huge files somewhere in those commits?
> I'm speculating that the sole number of commits should not affect Git
> that much but huge files *could* -- due to it using the xdelta
> compression when packing files (which, in turn, in typical builds uses
> memory mapping).

You might want to check the various config parameters to see if that
reduces memory usage.  I've used pack.packSizeLimit = 1g.

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.

[git-users] Weird messages

[Dale R. Worley]

The thought of adding a filter

DROP messages MATCHING "git-users" IN SUBJECT AND "PEDOPHILE" IN SUBJECT

makes me giggle like a 12 year old!

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] Re: documentation for bfg

[Dale R. Worley]

> From: joeriel...@gmail.com

> I was wondering if there was a way to delete a file in a particular 
> directory; the name of the file is used in multiple directories, but I 
> wanted to delete just the one. The --delete-files option only takes the 
> filename, not the path.

git-filter-branch should do the job.  The manual page seems to be
reasonably complete and comprehensive.

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] Damaged repo

[Dale R. Worley]

> From: fpefpe 
> 
> Hello -- Not sure how much harm this could do, but I run git via
> windows -- I ran a shell script that would lower-case files in the
> directory and all subdirectories -- I forgot one of those sub-dirs
> was a git ripo (.git) and all the files in it were lower cased -- Is
> there a way to repair this repo?  Thanks

If it just lower-cased the file *names*, you can probably fix that
manually by comparing with a known-good repository.  If you
lower-cased the file *contents*, that's going to be a horrible to fix,
because the recorded file contents are now wrong.

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] What is the best way to visualize branch history line?

[Dale R. Worley]

> From: Leonardo Petry 
> 
> What would be the best command to view a branch history?

"git log --graph" helps my intuition.

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] worlds slowest git repo- what to do?

[Dale R. Worley]

> From: John Fisher 

> FYI we are archiving compressed Linux disk images for VMs and
> hypervisors.

A core problem is that you've got the worst sort of data for something
like Git.  Your files are huge, and being compressed, any effort to
compress saved files or find duplicate strings between them is totally
wasted.  Your workload is anti-optimized for any "source management
system".

Here's something that might work (ugh):  Use Subversion, which I seem
to recall will do "delta encoding" between versions of a single file
but not *between* files.  Have a directory (or directories) which
contain all the big files.  Whenever you change a big file, delete the
old version and create the new version *under a different name* (so
Subversion doesn't try to delta-encode the new version relative to the
old one).  Now, for your "real" files, keep a directory tree like
normal, but for each of the big files, use a symbolic link (under the
desired name) that points to the actual file (off in the storage
directory).  (Not "svn mv", but just a filesystem move, so that
Subversion doesn't try to connect different versions of a binary.)  I
*think* that will prevent Subversion from trying to do anything clever
with big, low-redundancy binary files.

You could probably write a script that would go through the structure
and groom it into the proper shape to be committed:  Move any big
files in the "real" tree into the storage directory, replacing them
with links, deleting any non-linked-to files in the storage directory,
etc.  The trick would be having a way to generate the name in the
storage directory in a way that is uniquely determined by the file
contents (and possibly modification date).  You don't want to hash the
whole file, that would be too slow...

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] Bare repository

[Dale R. Worley]

> From: Alain 
> 
> but what i do not understand is if only 1 person manage the bare repository 
> (setting access right to this repository) on local disk, how can he prevent 
> other people to modify, stage and push changes to it ?
> Moreover, the bare repository is not for only 1 file... :(
> 
> I would like to understand the mechanism. How people can pull/push (having 
> non bare clone) to it, and the person managing the bare repository will 
> manage the pushes/pulls to define what is going or not ?
> i'm lost with it.

Fundamentally, access to a repository is controlled by the file-access
mechanisms of the system that contains it.  Another user on the same
system can push changes to it if the user has permission to write the
files in the repository structure.  A user on another system can
remotely push changes if the remote-access program (usually sshd)
allows the remote user to run a program on the system that has
permission to write the files in the repository structure.

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] About the spam

[Dale R. Worley]

Here's a more accurate count:

  3 1 May 2014
  5 3 May 2014
  2 4 May 2014
  6 5 May 2014
 11 9 May 2014
  7 11 May 2014
  6 19 May 2014
  2 20 May 2014
 13 21 May 2014
 30 23 May 2014

My first script was inaccurate because some of the spam doesn't have
"PEDO" in the Subject header!

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] How to find out (fast) if a commit is on a _specific_ branch

[Dale R. Worley]

> From: Paul Smith 

> I know about "git branch --contains" but that checks ALL the branches to
> see if the commit is on any them, and with the number of branches we
> have that takes a non-trivial amount of time.  Since this is in a push
> hook I really need it to be as fast as possible, and it seems to me that
> if I could ask for just a specific branch, "is this commit on this
> specific branch" rather than "what are all the branches this commit is
> on", it would be faster.

I think this works:

$ git-rev-list HEAD..commit

The output will be empty if commit is an ancestor of HEAD and
non-empty if not (due to the definition of '..').

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] diff most recent commit

[Dale R. Worley]

> From: dexter ietf 

> git log lists all the commits, how about if just want to see most recent 
> commit
> or most recent 2 commits on a file and per line basis.
> can we achieve the same with 'git diff', because this will help me view the 
> diff
> from vimdiff. with git log i can't achieve that. 

Try:

$ git log -1 -p filename

"-n" limits git-log to the last n commits.

git-blame is useful for annotating a file regarding which commit last
affected each line.

If you want to diff the versions of a file between the previous commit
and the current commit, you want

$ git diff HEAD^ HEAD -- filename

If you're interesting in diff'ing, you should read *all* of the
git-diff manual page.  What you want is probably in there somewhere.

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] Git extensions to use enhanced difference detection

[Dale R. Worley]

> From: Hugh Gleaves 

> I'm newish to Git and see that it seems to do change detection using a line 
> by line kind of algorithm.

Actually, Git uses binary comparison -- a file is changed if any byte
in the file is changed.

What you can configure is how "differences" are computed by the
commands that take differences and display them.

But I've never heard of a configuration that changes the definition of
when a file has changed.  I suppose you could write a script that
looks at files and decides which to git-add and which to not.  Since
only the git-add'ed files are put in the new commit, that would have
much the same effect.

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] git reset with staged changes

[Dale R. Worley]

> From: André Hänsel 

> Before I did the reset I actually checked the list of files and saw them 
> but I assumed that after the reset those files would be unstaged and 
> untracked again. It just seemed the most natural bahavior.
> 
> Is this a missing feature or is it in fact more logical to delete them?

It sounds to me like you're looking for "git reset --merge", but I
don't fully understand the manual page, so I might be wrong.  It seems
to me that the word "hard" is rather a warning that that optionj might
cause drastic changes.

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] git reset with staged changes

[Dale R. Worley]

> From: André Hänsel 

> As usual I made sure that I had 
> no uncommited changes. There were only a few untracked files laying around 
> and my untracked (so I thought) but staged file, so I felt safe to reset. I 
> was expecting to see my migration file as untracked afterwards, ready to be 
> staged again.

Ah, an interesting gotcha!  Since you'd staged the file, it was
tracked, and thus it was vulnerable to git-reset--hard.  (I've got in
my notes, "A file is tracked if it is in the base commit of the
repository or if it is in the index.")

> From: "Philip Oakley" 
>  
> An alternative question would be, "Could the man page be improved so
> that what you ned was spotted sooner?". 

In the manual page:

   --hard
   Resets the index and working tree. Any changes to tracked files
   in the working tree since  are discarded.

it might be useful to add "Beware that files that have been staged
(added) but never committed are tracked and so will be discarded."

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] Re: git reset with staged changes

[Dale R. Worley]

> From: Pierre-François CLEMENT 

> Ah, my mistake I've misread you in the first place. You're right, it feels
> natural they should return to their "untracked" state rather than being
> deleted. And it sounds definitely possible to implement: git could just
> check if the file was tracked or not before deleting it, the same way it
> can tell the file has been "added" or "modified".

Beware, though.  I don't have my Git reference to hand, but I've noted
that if the file is in the index, it is "tracked" and the git-reset
manual page says:

   --hard
   Resets the index and working tree. Any changes to tracked files
   in the working tree since  are discarded.

What you want is an exception for files that are in the index but
*not* in the base commit.  Or perhaps the criterion should be "files
that are in the commit", rather than "tracked files".

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] Re: git reset with staged changes

[Dale R. Worley]

> From: Pierre-François CLEMENT 
> 
> Really? Sounds a bit strange. I feel like "tracked files" are committed
> files, and that staged files are "about-to-be-tracked files" so in a sort
> of a transient state.

Yeah, but what one *feels* is the definition of the word is not
relevant.  To work consistently, Git has to have a definition of
"tracked" and stick with it.  (Though one can reasonably argue that
Git would work better with a different definition, one has to think
long and hard about changing such a central design decision.)

> So I'm not sure what to think here. I've searched through the git-glossary,
> git-add, git-update-index, git-status etc man pages and couldn't find any
> hints on wether staged files are tracked files or not. Can anyone shed some
> light on this?

Unfortunately, you're running into the problem that Git isn't at all
well documented.  I can't find the source right now, but I'm certain
that the definition I quoted was from the O'Reilly book.  But I have
no idea where that author got it from; perhaps he found it by
experimentation.

The online book is particularly treacherous:
http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository

Remember that each file in your working directory can be in one of
two states: tracked or untracked. Tracked files are files that
were in the last snapshot; they can be unmodified, modified, or
staged. Untracked files are everything else — any files in your
working directory that were not in your last snapshot and are not
in your staging area.

If you read carefully, you'll note that it is self-contradictory:  His
definition of tracked excludes staged-but-not-in-the-head-commit files
but his definition of untracked also excludes those files.

> From: Paul Smith 
> 
> A tracked file is a file that Git knows about.  An untracked file is a
> file Git doesn't know about.  More concretely, any file that has ever
> been "git add"'d is tracked.  Files that have never been "git add"'d are
> not tracked.

That's not true either.  If in one commit a file was added, and in the
next commit, it was deleted, then *now* it is untracked (even though
it was once added).

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] git commands running *very* slowly after transfer from Reiser -> ext3

[Dale R. Worley]

What you're really asking is "Why is Git running much slower on one
computer than another?"

I don't know all the factors to consider, but I suspect that one is
whether all of the directory information about all of the component
files is cached in RAM.  On a developer's machine, all of that stuff
is likely to get into RAM and stay there.  On a "server", there are
likely competing demands for RAM, and the directory information for
the working copy is likely to get pushed out of RAM.

One thing would be to use utilities like xosview and free to see how
the demand for memory is on the server.  You could also try running
the command twice in quick succession on the server -- after the first
one, all of the needed information will have been pulled into the
cache.

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] git commands running *very* slowly after transfer from Reiser -> ext3

[Dale R. Worley]

> From: tomgra...@gmail.com
> 
> By the way, if you want to know why its an ext3 install with an ext4 
> mounted 'data' disk - this is because it is a rackspace 'cloud' hosted 
> server.

My understanding is that with cloud servers, you don't actually have a
particular system, you have a virtual system which can get loaded onto
any of a zillion real systems.  That doesn't matter much, except that
your disk isn't directly attached to the system that runs your code.
Your disk is part of a huge disk farm that only appears to be directly
attached.  So the problem is likely to have something to do with how
Rackspace's disks work.

One thing to check is what the basic disk I/O rate is.  You can use dd
to and from a really large file (much bigger than your RAM) to test
that.  Depending on what Rackspace has done to the OS, accessing
directory information might be strange.  Try doing "time file
[working-copy] >/dev/null" a couple of times in a row to see how
long it takes to work through directory structures.

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] Re: git reset with staged changes

[Dale R. Worley]

> From: Paul Smith 
> 
> There are a million special case situations and it's too exhausting for
> both the author and the reader to be sure to cover all of them every
> time, which is why you perceive ambiguities in the documentation.

There is a definition of "tracked" which was settled upon by the
people who established the overall design of Git.  The code within Git
is written to match that definition of "tracked" (assuming there are
no bugs).  So you should write the documentation to give that
definition.  That way the documentation is *correct in every
situation*.  You don't leave the poor user stuck with having to
experiment to see what Git actually does in some peculiar case.

> From: Pierre-François CLEMENT 
>  
> It somehow is IMO, as I got that feeling from my day-to-day use of git and 
> from reading its manual, so it might be the symptoma of some incoherences 
> across the tool's usage and/or definitions.

That's true, there may be incoherences, that is, there may be errors
in that the code or documentation does not implement the designers'
choices.

> > Remember that each file in your working directory can be in one of 
> > two states: tracked or untracked. Tracked files are files that 
> > were in the last snapshot; they can be unmodified, modified, or 
> > staged. Untracked files are everything else — any files in your 
> > working directory that were not in your last snapshot and are not 
> > in your staging area. 
> >
> > If you read carefully, you'll note that it is self-contradictory:  His 
> > definition of tracked excludes staged-but-not-in-the-head-commit files 
> > but his definition of untracked also excludes those files.
>
> It is a bit self-contradictory, but only in the listing of what such files 
> can be. Apart from that, the definition *"Tracked files are files that were 
> in the last snapshot [...]. Untracked files are everything else"* is pretty 
> clear, and describes exactly my understanding of such files. So, to answer 
> André's original question, I think might indeed be either a bug or a 
> missing feature.

Yes, I wasn't reading carefully enough myself.  But you'll not that
"Untracked files are everything else" is different from "any files in
your working directory that were not in your last snapshot and are not
in your staging area" -- files that are in the working directory, are
in the staging area, but are not in the last commit are included in
the first description but aren't included in the second description.
And it is precisely those files that are causing the confusion here.

> I think I'm gonna mail g...@vger.kernel.org (the "official" mailing list 
> ) to see what they think about it. Would it 
> be wrong to reply to this conversation with a summary of it, CC'ed to 
> g...@vger.kernel.org? I'm not quite confident with using public mailing 
> lists just yet.

It would be a very good idea if you get an "authoritative" answer to
add it to the discussion here.

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] git commands running *very* slowly after transfer from Reiser -> ext3

[Dale R. Worley]

> From: tomgra...@gmail.com

> # On branch master
> nothing to commit (working directory clean)
> 
> real0m0.558s
> user0m0.157s
> sys0m0.387s
> 
> 
> ... on my company's:
> 
> # On branch master
> nothing to commit (working directory clean)
> 
> real0m57.812s
> user0m14.764s
> sys0m7.998s

Here's something that might be worth thinking about:  Somehow the new
computer's setup interferes with Git's algorithm for checking whether
files in the working directory have changed.  I know Git is quite
clever about checking for changed files, because a "git add" can be
quite fast even if the working directory contains thousands of files.

One thing that stands out to me is the subprojects.  They may somehow
not work quite correctly because you didn't install them directly.

It be worth asking about asking about this on the main Git mailing
list.

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] Get file SHA just prior to tag

[Dale R. Worley]

> From: John Fisher 

> This is his complaint:
>   git ls-tree -r 
> 
>- snip -
>100644 blob 990c3e0f7efc8ddf869dbb39ba0065c9e9578df4rmapi_bcmxlat.c
>-snip-
> 
>root@oa4-hv-B1net:bcm# git log rmapi_bcmxlat.c | grep 990c3e0f7ef
>There is no such SHA in git log output
> 
> *Ultimately he wants to know which version of a file was in the tag.*
> 
> git diff  filename  shows the diff, but that doesn't seem to 
> satisfy his needs.

You're not clear what the question is.  You ask "which version of a
file is in the tag" and the answer is "the version with hash
990c3e0f7efc8ddf869dbb39ba0065c9e9578df4".

Do you mean "Which commit introduced that version of that file?",
"What are the contents of that file in that tag?" ... ?

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] Get file SHA just prior to tag

[Dale R. Worley]

> From: John Fisher 

> The SHA for the tag is not the SHA for the individual file. OK thats 
> obvious to experienced Git users, and the main point here. He wants to know 
> what the SHA for the file is just prior to the tag, (shown in Gitk BTW) . I 
> have shown him how to get the contents of a file by tag, but he wants the 
> SHA. ls-tree does not satisfy this as it associates a SHA with the file, a 
> SHA that is not listed in git log output.
> 
> Why does ls-tree do this?
> How can he get a SHA listed in git log, that was created just before the 
> tag? ( without using dates which are FU'ed for extraneous reasons)

There is still some confusion here.

First, a tag is a name for a commit, not a bookmark that separates
"commits before the tag" from "commits after the tag".  The command
"git tag " should print the commit id (which is a hash) for
the commit named by the tag.

"git ls-tree" lists the files that are contained in a commit.  It also
takes arguments to list only specific files within the commit.  So I
can say:

$ git ls-tree -r HEAD .bash_login
100644 blob 563ba2e54ebdf3977cf2ab744eaa4d457b58fc24.bash_login

This lists the SHA of the version of .bash_login which is in the
commit HEAD.  Of course, I can replace HEAD with a tag name.

You ask "He wants to know what the SHA for the file is just prior to
the tag".  Do you mean, the SHA for the version of the file that
precedes the version in the tag?  There are two ways to answer that.

One is "What is the SHA for the file in the commit just before the
commit named by the tag?"  That is easy to answer, because
"^" names the commit before the commit .

I think he's asking "What is the SHA for the last different version of
the file before the tag?"

I think what will work is:

1) Find the first commit before the tag that has a different content
for the file:

$ git log -n 1 ^ -- 
commit b3282e06e39e1ddaa44806eadbfac06a19fabe09
...

2) Find the SHA of the file as it is in that commit

$ git ls-tree  -- 
100644 blob   

3) Get the contents of the file within that commit

$ git cat-file blob 

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] Looking for Suggestions

[Dale R. Worley]

> From: HOWARD ROSENBLOOM 
> 
> We are a small company that has not been using any form of 
> configuration/tracking in the past. We have 2-3 programmers and have gotten 
> into the situation where we need to get control of any work being done. 
> Since none of us have any experience in this area I am looking for 
> suggestions as to whether GIT is right for what we are looking for, or is 
> there a better/more appropriate solution. 

I've used both Git and Subversion.  If you're a small operation, and
you've not used version control before, and if you do not need the
distributed development facilities of Git, I believe that you'll find
Subversion easier to learn and use.  The drawback of Subversion is
that you need to have a server that is accessible by each worker for
all check-ins and check-outs.

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] Get file SHA just prior to tag

[Dale R. Worley]

> From: John Fisher 

> I still don't understand what the commit-SHA given out by git ls-tree is 
> for? If it doesn't correspond to a commit on the file as seen in git log, 
> what's it used for?

The *commit* has a SHA, and that is what is listed in the git-log
entry for the commit.

The commit points to a *file tree*, which has its own SHA.

The file tree points to all of the *file objects", each of which has
its own SHA.

Every commit contains the complete set of files that are in the file
tree at the moment the commit is made.

git-ls-tree, when given the SHA of a commit, lists the SHAs of the
file objects pointed to by the file tree that is pointed to by the
commit.

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] Get file SHA just prior to tag

[Dale R. Worley]

> From: Gergely Polonkai 

> Now that we know this, git-bisect is exactly the tool he needs! He
> specifies the last known commit without the bug, and the first known commit
> with the bug. Git will then choose intermediate commits for you to test if
> the bug still exists, and point you to the first bad one.

Yes -- and git-bisect handles nicely the situation where the bug was
introduced not by the latest commit that affected the file in
question, but by some previous commit.

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] Get file SHA just prior to tag

[Dale R. Worley]

> From: John Fisher 
> 
> [...] 
> [1:text/plain Hide]> *but that output does not agree with git log!*

I am totally lost what you're talking about.

"git log" lists *commits* and their SHAs.  You say you entered "git
log rmapi_bcmxlat.c" and you seem to expect it to contain the SHAs of
(versions of) rmapi_bcmxlat.c.  But it won't do that, because "git
log" lists *commits*, in this case, the commits that change the named
file.

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] Looking for Suggestions

[Dale R. Worley]

> From: Thomas Ferris Nicolaisen 

> There is an argument whether Git is actually easier to learn than SVN for 
> people who have never used version control systems before. After all, Git 
> has more in common with the kind of version control system you would invent 
> by yourself if there were none available [1].

One way to attack the decision is to buy the O'Reilly books on Git and
Subversion and read them both (especially if you're likely to be the
administrator of the source control system).  That will make the
differences a lot clearer.

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] create Repository problem in local

[Dale R. Worley]

> From: RAMA KRISHNA MEESALA 
> 
> Hi
>   My Name Is Rama Krishna, I was Trying to create repositary in local
> 
> it's gives an earror
> 
> my Machine win7 64 bit
> 
> i installed git 1.9 version
> 
> i need .git/config file 
> command :: *D:\SETUP\GIT>git config --local user.name 
>  "Rama"*
> 
>
> error: could not lock config file .git/config: No such file or directory

Have you created the repository with "git init"?  The message suggests
that the .git directory does not exist.

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] Git 2.0

[Dale R. Worley]

> From: Konstantin Khomoutov 

> Just please keep in mind that when you ask technical-savvy folks for
> help, do try to provide precise details of your problems.  We're not 
> magicians of wizards: we take the description of a problem, apply our
> knowledge to it and reason about its possible causes; so we just have
> to have precise details, otherwise we're restricted to plain
> guessing. ;-)

A very good (and hilarious) introduction to bug reporting is:

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
How to Report Bugs Effectively
by Simon Tatham, professional and free-software programmer 

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] How did I make this mess?

[Dale R. Worley]

I'm hardly an expert, but what I see for the description of the 9:11
commit (5f5345a) is "Merge branch 'master' of https://github.com...";.
First question is, What is the full name of that commit?  Second
question is, does the full URL in that commit make sense in the
context of your work?

I'd guess that the Pull that you did merged your working copy with all
those commits from github, and the Push sent it to your master.  Are
you sure that the connections from your working copy to the master are
set up correctly?  And it git-pull the command you really want?

Do you have some sort of log that shows exactly what Git commands you
executed?

I expect that you can reset the HEAD and contents of your working copy
to the parent of 7f78507, re-apply your changes for that commit, and
re-execute the Pull and cause the problem to happen again.  Then look
at the commit history of your working copy.  Heh -- do this in a copy
of your working copy, not the live one.

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] Remove files and folders permanently from commit history and pack files

[Dale R. Worley]

> From: cemico 
> 
> How do i remove let's say a "concept_art" folder from all commits (i have 
> about 50 commits by now) and from the pack file?
> 
> I tried many things now. e.g:
> - http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/
> - http://rtyley.github.io/bfg-repo-cleaner/
> - filter-branch with "rm"
> - git gc with prune=now and aggresive
> 
> and the thing i thought which must really work:
> http://git-scm.com/book/en/Git-Tools-Rewriting-History#The-Nuclear-Option:-filter-branch

First, be aware that what you want to do is intrinsically difficult.
Git is oriented toward allowing you to manipulate commits, etc.  But
removing objects from storage is not a task that it is designed to
make easy.  I have had a little experience and I think I can provide
some useful guidance.

You already know how to recreate all your commits with certain
directories or files removed:

git filter-branch --index-filter $SCRIPT HEAD

You also know how to remove a stored object if it is no longer
referenced:

git gc --aggressive --prune=now

What is difficult is ensuring that you have removed all references to
the object.  In general, this involves removing records of past states
of the HEAD, and there are a lot of those records.  You have to remove
the record of the previous version of the branch you are manipulating.
(You have to do this before git-filter-branch, so that
git-filter-branch actually runs, and after it, to remove the value
that git-filter-branch put there.)  Your command looks to me like it
should suffice:

rm -rf .git/refs/original/

Where I think you have a problem is with the reflog.  In the
repository on which I use git-filter-branch, I have configured

git config core.logallrefupdates false

To ensure that no reflog entries are generated.  In your case, you use

git reflog expire --all

But as far as I can tell from the manual page, that means "examine all
reflogs to find expired entries".  You probably need to add
"--expire=now" so that all entries are considered expired.

You can probably examine .git/logs to see if there are any reflog
entries, and what their values are.  My suspicion is that one value
points to a commit that points to the files you want to excise.

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] Re: Git and binary files ... once more

[Dale R. Worley]

> From: Dominik Rauch 

> (c) the estimated upper limits to work with a repository in reasonable time 
> on a "normal" machine (i.e. if my repository reaches 20GB and all of a 
> sudden it takes five minutes per commit, etc.)

Most of the cases where this sort of behavior is seen come from
"thrashing", where the memory demand of the program exceeds the
available memory.  So you can look for these problems in advance by
asking "What situations cause Git to consume a great deal of memory?"

> From: Konstantin Khomoutov 

> 1) Git always compresses objects it writes; and after a certain
>threshold it compacts "loose" object files into the so-called
>"packfiles" which are big indexed archives.
> 
>What matters is that all these [de]compression operations are
>performed "in core" -- that is, a file is slurped in, operated upon
>then written out.  So you ought to have enough free physical memory
>to do all of that.

However, you can limit the size of the pack files that Git will
generate through configuration:

[pack]
packSizeLimit = 99m

There may be ways to force Git to not attempt to compress files that
are above a certain size.

Doing that will probably eliminate most situations where Git attempts
to consume excessive memory.

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] Remove files and folders permanently from commit history and pack files

[Dale R. Worley]

> From: cemico 

> thank you for your very detailed information.
> But i can't get it to work.

Try the following script.  It's not efficient, but if the man pages
are correct, if you give it a blob hash (the full hash), it will show
what file names it has in what commits.  Then for each commit, it will
show what refs have that commit as an ancestor.  And at the bottom, it
lists all the refs that (indirectly) point to the blob in question.

You have to clear out the reflogs yourself.

But that should give you enough information to make the blob
un-referenced and then "git gc --prune=now --aggressive" should be
able to remove it.

I suppose it could be improved by searching through the reflogs and
seeing which of them point to commits that contain the blob.

Dale
--
#! /bin/bash

# Find a given blob, given its hash.

BLOB="${1:?First argument is the blob hash.}"

# Temporary file name base.
T=${TMPDIR:-/tmp}/${0##*/}.$$

# Make a copy of stdout, since we will be redirecting stdout within the script.
exec 3>&1

# Find the commits in which the blob exists.

# List all commits.
git rev-list --all |
while read COMMIT
do
# COMMIT_ADDED records whether this commit hash has been stored or not.
COMMIT_ADDED=no
# List all files within the commit.
git ls-tree --full-tree $COMMIT |
while read MODE TYPE HASH NAME
do
# If this file matches the blob, report it.
if [ "$HASH" = "$BLOB" ]
then
echo >&3 Commit $COMMIT Name "$NAME"
if [ "$COMMIT_ADDED" = no ]
then
# Send the commit onward.
echo $COMMIT
COMMIT_ADDED=yes
fi
# Beware that the same blob may appear multiple times, so we
# have to continue searching through this tree.
fi
done
done >$T.commits

# Find the refs that lead to the commits.

# List all the refs.
git show-ref |
while read COMMIT REF
do
# REF_ADDED records whether this ref has been stored or not.
REF_ADDED=no
# List all the commits in the ref that contain the blob.
git rev-list $REF |
grep -f $T.commits |
while read COMMIT
do
echo >&3 Commit $COMMIT Ref "$REF"
if [ "$REF_ADDED" = no ]
then
# Send the ref onward.
echo "$REF"
REF_ADDED=yes
fi
done
done >$T.refs

# Write out the refs.

sed <$T.refs -e 's/^/Ref /'
--

-- 
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] Finding and eliminating big files

[Dale R. Worley]

Here's an improved version of the script that finds what refs and what
commits contain a particular file blob.  You give it the blob (the
full blob) as an argument and it traces what commits contain it, and
what refs and what reflog lines point (directly or indirectly) to
those commits.

As far as I can tell, it's correct, but I haven't paid any attention
to efficiency.  On my computer, it takes about 15 minutes to search a
clone of the Git repository.

Following is the script and an example of its use.  No doubt it can be
improved significantly.

Dale
--
#! /bin/bash

# git-find-blob - Find a given blob, given its hash.

BLOB="${1:?First argument is the blob hash.}"

# Temporary file name base.
T=${TMPDIR:-/tmp}/${0##*/}.$$

# Make a copy of stdout, since we will be redirecting stdout within the script.
exec 3>&1

# Find the commits in which the blob exists.

# List all commits.
git rev-list --all |
while read COMMIT
do
# COMMIT_ADDED records whether this commit hash has been stored or not.
COMMIT_ADDED=no
# List all files within the commit.
git ls-tree --full-tree $COMMIT |
while read MODE TYPE HASH NAME
do
# If this file matches the blob, report it.
if [ "$HASH" = "$BLOB" ]
then
echo >&3 Commit $COMMIT Name "$NAME"
if [ "$COMMIT_ADDED" = no ]
then
# Send the commit onward.
echo $COMMIT
COMMIT_ADDED=yes
fi
# Beware that the same blob may appear multiple times, so we
# have to continue searching through this tree.
fi
done
done >$T.commits

# Find the refs that lead to the commits.

# Both of the following functions produce lines of the form:  hash ref-name

# A function to list all of the refs.
function all_refs () {
git show-ref
}

# A function to list all of the entries in all of the reflogs.
function all_reflogs () {
# Go to the .git/logs directory and find all the reflog files.
cd $( git rev-parse --git-dir )
find logs -type f |
while read REFLOG
do
# Read each reflog file.
LINE=1
cat "$REFLOG" |
while read BEFORE AFTER DATA
do
# Turn every line into two lines:  hash reflog-name
echo $BEFORE "$REFLOG:$LINE"
echo $AFTER "$REFLOG:$LINE"
(( LINE++ ))
done
done
}

# List all the refs.
( all_refs ; all_reflogs ) |
while read COMMIT REF
do
# Skip the null commit if it shows up.
[ $COMMIT =  ] && continue

# REF_ADDED records whether this ref has been stored or not.
REF_ADDED=no
# List all the commits in the ref that contain the blob.
git rev-list $COMMIT |
grep -f $T.commits |
while read COMMIT
do
echo >&3 Commit $COMMIT Ref "$REF"
if [ "$REF_ADDED" = no ]
then
# Send the ref onward.
echo "$REF"
REF_ADDED=yes
fi
done
done >$T.refs

# Write out the refs.
<$T.refs sort -u |
sed -e 's/^/Ref /'
--
$ time git-find-blob 07c2aba4f2c2434551a436d626447902f0c1872d
Commit fee106fafa1a9ee6029ad6390a7404f66b10d656 Name Makefile
Commit bd6350770e454c0bdef312419289ef6e0ba6bc81 Name Makefile
Commit f7c69c45befd9772282f1d45e988d5f62f54696b Name Makefile
Commit f918f7b13d09fbb93c2892899f680da80ed51ac1 Name Makefile
Commit 771a1a04e6c038cf974123b2303baccf5dfc4e98 Name Makefile
Commit cf5a8e3c1f4571f3a9daf59537026a2700e1f5ce Name Makefile
Commit ad158af1429bb1283f1605245b941699d3d1bc7b Name Makefile
Commit c9a507c3b8072891c5ce164ac82e8009d20c9b1f Name Makefile
Commit bf7b47d405b5f7e72058157df3b18e840ce4d0ac Name Makefile
Commit b3f76e372d66e61c06bc28def35b2e991a0692e1 Name Makefile
Commit 05ef0f3cf0cb7a398b552d61325898bc72da818c Name Makefile
Commit 9e6c9b4ee355cec3f7f48758107300d6daca34ae Name Makefile
Commit b0b86cfed2094c983b41a926d74e313f220d7e58 Name Makefile
Commit 6f128b42fb40916e4b9c233557bdde5a7b90c86a Name Makefile
Commit bcf3cbc25b543e485bfab373ef9852f5a67bee43 Name Makefile
Commit a77e57b2054683340bcf0dc0dd717e2b559d97d0 Name Makefile
^- meaning that in these commits, at the indicated file name, is a
   file with hash 07c2aba4f2c2434551a436d626447902f0c1872d
Commit fee106fafa1a9ee6029ad6390a7404f66b10d656 Ref refs/remotes/origin/pu
Commit bd6350770e454c0bdef312419289ef6e0ba6bc81 Ref refs/remotes/origin/pu
Commit f7c69c45befd9772282f1d45e988d5f62f54696b Ref refs/remotes/origin/pu
Commit f918f7b13d09fbb93c2892899f680da80ed51ac1 Ref refs/remotes/origin/pu
Commit 771a1a04e6c038cf974123b2303baccf5dfc4e98 Ref refs/remotes/origin/pu
Commit cf5a8e3c1f4571f3a9daf59537026a2700e1f5ce Ref refs/remotes/origin/pu
Commit ad158af1429bb1283f1605245b941699d3d1bc7b Ref refs/remotes/origin/pu
Commit c9a507c3b8072891c5ce164ac82e8009d20c9b1f Ref refs/r

[git-users] Finding and eliminating big files

[Dale R. Worley]

Here is how I find big files that have gotten into the repository.
The shell script grovels through the repository history listing every
file in every commit in the history of HEAD, along with its length.
Duplicates are removed from this list, and then a space-use analysis
is done of the files, grouping them by the directories they are
recorded within.  The output graph shows how much space is attributed
to each directory and file, with output for small directories and
files suppressed.

The script is crude in that it doesn't take into account space that is
saved by compression, either of a file individually or multiple
similar files in a pack file.  It also doesn't notice if identical
files are stored under different names in different commits.  But it
works well enough for finding that gigabyte file that has crept into
the respository.

Once you've obtained the blob hash, you can use git-find-blob to
determine exactly how it is referenced.

Dale
--
#! /bin/bash

# git-space-use
# List a tree showing the space breakdown of all the different files
# in all commits.

# Generate all the commit identifiers.
git rev-list --all |
# Process each commit.
while read COMMIT
do
# List all the files in the commit, with their lengths.
git ls-tree --full-tree -l -r $COMMIT |
while read MODE TYPE HASH LENGTH NAME
do
# Output a line like 'du' would make.
echo $LENGTH$'\t'./"$NAME"/$HASH
done
done |
# Remove duplicate mentions of the same file with the same contents.
sort -u -nr | tee ${TMPDIR:-/tmp}/${0##*/}.$$ |
# Assemble a space-use graph.
dugraph -c
--
/* dugraph.c - program to make a pretty graph out of a du report */

/* Option -c forces the sizes of directories with listed children to be
   calculated from the sizes of the listed children.  This helps if the
   input du listing has had subtrees chopped out of it (for instance, if
   they really reside on other filesystems than the root of the tree), but
   generally requires a -a listing to give sensible results, otherwise the
   calculated size for a directory containing subdirectories will ignore
   the files contained directly in the directory. */

/* Must be compiled with gcc rather than g++, because the types of function
   arguments are given in the old style. */

/* Define I64 to use unsigned 64-bit integers for sizes and totals. */
#define I64

#ifdef I64
  #define SIZE uint64_t
  /* In C99, uint64_t is defined in stdint.h. */
  #include 
  /* Get the macro PRIu64 which is the modifer-and-format-letter for uint64_t. 
*/
  #define __STDC_FORMAT_MACROS
  #include 
#else
  #define SIZE unsigned long int
#endif

#include 
#include 
#include 

/* number of lines the listing should occupy */
int length = 60;
/* message for suppressed directories */
#define SUPPRESSED  "(etc.)"

/* format of a tree node */
struct node {
struct node *lson;  /* left son */
struct node *rbrother;/* right brother */
SIZE   size;   /* size of directory in kbytes */
SIZE   cum_size;/* size of everything listed before
 * this directory */
int loc;/* location we will print it at */
int print_col;/* column to print name in */
int print_limit;
/* location we can't print on or
 * after */
int last;   /* are we last son of our father? */
charname[1];/* name */
  };

/* root of the tree */
struct node *root = NULL;
/* total size of things listed */
SIZEtotal_size;
/* current line number we are on (0-origin) */
int current_line = 0;
/* list of where to put bars */
int bar_list[50];
/* number of bars in the list */
int bar_count = 0;
/* set to force recalculation of sizes of directories */
int calculate_sizes = 0;

/* declare functions */
voidread_input();
struct node *insert_in_tree();
voiddfs();
voiddfs1();
voidmissing_sizes();
voidcalc_cum_size();
voidsort();
voidcalc_loc();
voidblank();
voidmark_last();
voidcalc_pc();
voidoutput();
voidposition();

int main(argc, argv)
 intargc;
 char   **argv;
{
struct node *t; /* scratch */

/* process the options */
if (argv[1] != NULL && strcmp(argv[1], "-c") == 0)
{
calculate_sizes = 1;
}

/* read the input and form a tree */
read_input();
root->size = 0;
/* put sizes on entries that have none */
dfs(NULL, missing_sizes);
/* sort each directory */
dfs(sort, NULL);
/* calculate cumulative size before each entry */
root->cum_size = 0;
dfs(calc_cum_size

Re: [git-users] Re: Submodul with push

[Dale R. Worley]

> From: Pierre-François CLEMENT 

> I don't see any other option than chaining your commands by joining them 
> with *&&* (or *;* if you want each command to be executed even if one of 
> them fails, but I doubt it).
> 
> $ git clone --recursive myproject && cd mainproject/submodule1 && touch 
> test.txt && git add test.txt && git commit && git push

For a very long sequence of commands, it might be a bit easier to do:

$ ( set -e 
git clone --recursive myproject
cd mainproject/submodule1
touch test.txt
git add test.txt
git commit
git push
  )

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] repo init not working in GIT BASH

[Dale R. Worley]

> From: scmmanage 

> $ repo init
> sh.exe": /c/Users/vikram.sadasivam.LGE/bin/repo: /usr/bin/env: bad 
> interpreter:
> Permission denied
> 
> Please do ask me if anything I left out.

It has something to do with an executable file that is organized as an
"interpreter script" (an intro at
http://en.wikipedia.org/wiki/Pound_bang) which specifies
"/usr/bin/env" as the interpreter.  /usr/bin/env (on your system) is
either not present, or you are for some reason not allowed to execute
it as a program.

If I read the message correctly,
/c/Users/vikram.sadasivam.LGE/bin/repo (which is probably the same as
C:\Users\vikram.sadasivam.LGE\bin\repo) is the "executable file" in
question.

My guess is that /usr/bin/env on your system does not designate an
installed file.  I don't know what you need to do to obtain that file.

Do you know that repo can be installed and run on Windows?

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] Problem with commit

[Dale R. Worley]

> From: DavidFreed 
> 
> Dear Friends,
> I have this problem with Git , please advice me.
> 
> git commit -am "commit all"

Please tell us what you do not like about Git's behavior.

This will give you some advice:
http://www-mice.cs.ucl.ac.uk/multimedia/software/documentation/ReportingBugs.html

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] git clone fails when invoked with python/php scripts.

[Dale R. Worley]

> From: Vaibhav Chauhan 
> 
> I am trying to clone a git repo when running git clone command when run as 
> www-data, an apache user, it fails with* "**git clone -v 
> ssh://git.***.com/home/repo/qa/morrison-test/common.git 
> /tmp/tempGit_1408125949.48' returned exit status 128: ssh: Could not 
> resolve hostname git.blurdev.com: Name or service not known."*. As a matter 
> of fact when I am running the same python script locally I am able to clone 
> it flawlessly.
> 
> Can someone take a look at the question at 
> http://stackoverflow.com/questions/25317557/python-script-fails-to-git-clone-when-run-with-php

One thing to do is create a PHP page that just executes the 'git
clone' command.  That simplifies the situation by eliminating the
Python program around it.

Another is to have a page output all of the permission information.
On my system (Fedora 19), the plain "id" command shows all the uid/gid
information, as well as the SELinux context.

Then you can get on the server in question, su to the right account,
execute the commands to set up *exactly* the same permission state,
and execute the 'git clone' manually.

Another approach is to run Wireshark on the server and watch the
connection to git.*.com fail.  Although I'm not sure what you need to
do to be able to see what's going on inside the SSH connection.
(Perhaps there is a way to set the account's ~/.ssh/config options to
force it to use the null cipher?

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] issues with downloading project files from git

[Dale R. Worley]

> From: John McKown 
> 
> Try
> 
> git clone https://github.com/laravel/laravel.git
> 
> It works for me.
> 
> The command you used looks more like it is only for the owner. The form
> "g...@github.com:laravel/laravel.git" looks more like what I use when I'm
> updating my own repositories, not cloning somebody else's repository.

Hmmm, yes.  Syntaxes like "u...@host.com:path" usually mean "log in as
'user' onto host 'host.com' and then access the file identified by
'path'".

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] Review changes in a concrete line of code

[Dale R. Worley]

> 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] strange histories from git filter-branch

[Dale R. Worley]

> From: Bernard Clark 
> 
> I've been running the git filter-branch described here 
> 
> . But the resulting history includes at least two extraneous commits, i.e., 
> commits that appear to affect no files in the subdirectory of interest. 
> (The corresponding commits in the original history do affect files, but 
> those files are in another subdirectory.)

My guess is that the inner script doesn't correctlty notice that one
of the old commits, when limited to the subdirectory, doesn't change
anythihng, and does not signal to the wrapper that no new commit needs
to be created.

(H, that could be messy if the old commit was a merge commit,
because you'd need a new commit to record the merge, even if no file
is changed (relative to one parent).)

> I also noticed the occurrence of several "duplicate parent" errors during 
> the git filter-branch. This page 
> 
>  
> says that those errors can produce an incomplete new history, so I'm now 
> wondering if, in addition to including extraneous commits, my new history 
> might also be missing some. Along with this page 
> ,
>  
> the page says that the "duplicate parent" errors should disappear if "git 
> filter-branch" is first run with no filter. But that didn't work for me.
> 
> Thoughts?

It could be messy -- as you create new commits, sometimes two old
commits will map into identical new commits.  If filter-branch notices
that, it might wind up giving that one new commit twice as parents of
a new commit.  Does filter-branch have a strategy for dealing with
that?

I'd sit down and draw a diagram of what the new commit structure
*should* look like, together with the mapping from the old commits,
and then see whether filter-branch's output matches what you expect.
That should show you the specific situations that are causing the
problem, and may allow you to deduce how filter-branch is handling
them.

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.

[git-users] What happens when the repository is bigger than gc.autopacklimit * pack.packSizeLimit?

[Dale R. Worley]

A number of commands invoke "git gc --auto" to clean up the repository
when there might be a lot of dangling objects and/or there might be
far too many unpacked files.  The manual pages say:

git gc:
   --auto
   With this option, git gc checks whether any housekeeping is
   required; if not, it exits without performing any work. Some git
   commands run git gc --auto after performing operations that could
   create many loose objects.

   Housekeeping is required if there are too many loose objects or too
   many packs in the repository. If the number of loose objects
   exceeds the value of the gc.auto configuration variable, then all
   loose objects are combined into a single pack using git repack -d
   -l. Setting the value of gc.auto to 0 disables automatic packing of
   loose objects.

git config:
   gc.autopacklimit
   When there are more than this many packs that are not marked with
   *.keep file in the repository, git gc --auto consolidates them into
   one larger pack. The default value is 50. Setting this to 0
   disables it.

What happens when the amount of data in the repository exceeds
gc.autopacklimit * pack.packSizeLimit?  According to the
documentation, "git gc --auto" will then *always* repack the
repository, whether it needs it or not, because the data will require
more than gc.autopacklimit pack files.

And it appears from an experiment that this is what happens.  I have a
repository with pack.packSizeLimit = 99m, and there are 104 pack
files, and even when "git gc" is done, if I do "git gc --auto", it
will do git-repack.

Looking at the code, I see:

builtin/gc.c:
static int too_many_packs(void)
{
struct packed_git *p;
int cnt;

if (gc_auto_pack_limit <= 0)
return 0;

prepare_packed_git();
for (cnt = 0, p = packed_git; p; p = p->next) {
if (!p->pack_local)
continue;
if (p->pack_keep)
continue;
/*
 * Perhaps check the size of the pack and count only
 * very small ones here?
 */
cnt++;
}
return gc_auto_pack_limit <= cnt;
}

Yes, perhaps you *should* check the size of the pack!

What is a good strategy for making this function behave as we want it to?

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.

[git-users] Making repacking faster

[Dale R. Worley]

I've got a Git repository that I use to log updates to system files.
Not things in /var that change every day, but configuration files in
/etc, binaries in /usr, etc.  Of course, the repository is large, 9 or
10 GB now.

I've just discovered that setting core.bigFileThreshold = 10k speeds
up garbage collection and repacking tremendously, like from 9 hours to
1/2 hour.  This works well in this situation, because files that are
larger than 10k are almost all binaries, and don't benefit from delta
compression.  And it turns out that delta compression takes a lot of
time if you have a lot of data.

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] git and filename case sensitivity

[Dale R. Worley]

> From: Konstantin Khomoutov 

> What I'm leading you to, is that, IMO, trying to fight this behaviour
> relied upon by so many pieces of software is counter-productive except
> for very special and isolated cases.
> So I'd rather fix the project you're working on to have portable
> filenames (say, all_lowercase or ConsistentlyCamelCased etc).

My observation is that even if you're working on Unix (which
consistently distinguishes filename case), it's asking for trouble to
have two files whose names only differ by case -- the computer is
case-sensitive, but *humans* are not consistently case-sensitive.

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] Git rebase command!

[Dale R. Worley]

> From: Gopi Naidu 
> 
> getting the issue with git rebase command on HPIA machine
>  
> bash-4.0$ git version
> git version 2.0.4
> bash-4.0$ uname -a
> HP-UX  B.11.31 U ia64 1660207278 unlimited-user license
> bash-4.0$ git rebase
> fatal: Uh oh. Your system reports no Git commands at all.
> bash-4.0$
>  
> please help

The git-rebase operation is actually done by a program named
"git-rebase", which the "git" program runs.  On my system, git-rebase
is in /usr/libexec/git-core/git-rebase.  The message strongly suggests
that "git" cannot find "git-rebase" on your system.

You can probably find where your git-rebase is with the command
"locate -b git-rebase", since you seem to be running a Unix-type
system.

I don't know how "git" finds its sub-programs.  It is not done through
PATH because /usr/libexec/git-core is not in my PATH.  You probably
have a "git-rebase" program, but some configuration needs to be
adjusted so that "git" can find it.

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] Confusion about Key-based SSH authentication

[Dale R. Worley]

> From: Xavier Yin 
> 
> Hi, every one!
> 
> I recently read Git on the Server - Setting Up the Server 
> , I 
> have a confusion about this paragraph as below:
> 
> 
> Key-based SSH authentication usually enforces security by requiring 
> restricted rights on the involved files. To prevent SSH from refusing to 
> work, type this:
> 
> $ chmod -R go= ~/.ssh
> ---

I don't know exactly what causes your issue, and I am not an expert in
SSH.  But I do know that the SSH server daemon enforces certain
restrictions on the permissions of the files in ~user/.ssh.  For
security it is important that no-one other than the user can read any
of the private key files.  Similarly, it is important that no-one
other than the user can modify any of the files in .ssh.  When a
client tries to authenticate as the user, the SSH daemon verifies that
the files in ~user/.ssh meet these requirements, and if they do not,
the daemon refuses the connection.  Probably the easiest way to ensure
that the .ssh directory meets these requirements is the chmod command
listed above.

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] Confusion about Key-based SSH authentication

[Dale R. Worley]

> From: Konstantin Khomoutov 

> Directory/file insecurities related to SSH on the server are typically
> logged appropriately (on a stock Debian-based system that will
> be /var/log/auth.log).

On Fedora, it looks like they go into either /var/log/messages or
/var/log/secure.

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] linking/sync individual files from different folders in the same repo

[Dale R. Worley]

> From: Norike Abe 

> I'm studying the migration from our old Version Manager, Team Coherence 
> , to Git.
> 
> One of the features we use in that system are "file links":
> Imagine a repo with this file structure:
> - MyRepo1
>   - Folder1
> - *FileA*
> - FileB
>   - Folder2
> - *FileA*
> - FileC
> 
> I want FileA from both Folder1 and Folder2 to be synchronized.

What I don't see is why you'd want to have what is intended to be one
file implemented by two different files.  That requires some sort of
machinery to ensure that the two instances of the file are always the
same, and introduces the constant possiblity of error.

One way to avoid this is to have one FileA be a symbolic link to the
other.  But I suspect you're using Windows, and it doesn't have
symbolic links.

Another way is to just tell every compilation and/or program that
wants to access FileA the location of the one copy of FileA.  Indeed,
the fact that the stuff in each folder wants to access the same file
suggests that the meaning or import of FileA transcends the specifics
of either Folder1 or Folder2.

The migration to Git might be the opportunity to rationalize your file
structure.

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] Identify added/changed lines since a specific commit

[Dale R. Worley]

> From: gituser 
> 
> I am wondering if it's possible to determine if a specific line in the code 
> (of the curent version of a file) was added or changed after a specific 
> commit?

Of course, the question is not perfectly well-defined, because there
is no absolute definition of what constitutes "a specific line" of a
file and all of its ancestors.  (E.g., consider a line containing a
solitary close brace.)  But it seems like an easy way to get a
reasonably good answer is to run git-blame

git-blame - Show what revision and author last modified each line of a file

and see what it notes as the last change.

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] git replace

[Dale R. Worley]

> From: Alcolo Alcolo 

> There is a way to remove all old replaced commits for ever ?

"git gc --aggressive" works, but you have to purge all the recorded
references to old commits.  The ones I know of are:

You have to set core.logallrefupdates to 'false' to prevent logs from
containing references, and gc.pruneexpire to 'now'.  And many scripts
that rewrite history leave the old head value in refs/original/..., so
you have to do something like:

git update-ref -d refs/original/refs/heads/$BRANCH

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] git replace

[Dale R. Worley]

> From: Alcolo Alcolo 

> My git history is complex and it's a nightmare to rebase from old commits.

I'm not sure what you're attempting to do, but this might help.  It's
a rebasing script I wrote.  It appears that it was based on something
Junio wrote.  The concept is that it rebases the current branch, but
unlike the standard git-rebase, it replicates the merging structure
between the merge-base commit and the head of the branch.  (IIRC, the
standard git-rebase creates a linear branch based on some ordering of
the commits in the old branch.)

Dale
--
#!/bin/bash
#
# Copyright (c) 2010 Junio C Hamano.
# Modified by Dale R. Worley.

# Usage:  git-rebase--merge-safe 
#
# Rebase the current branch to commit/branch , replicating the commit
# graph between HEAD and the merge base.

. git-sh-setup

prec=4

set -ex

# Ensure the work tree is clean.
require_clean_work_tree "rebase" "Please commit or stash them."

onto_name=$1
onto=$(git rev-parse --verify "${onto_name}^0") ||
die "Does not point to a valid commit: $1"

head_name=$( git symbolic-ref HEAD )
orig_head=$(git rev-parse --verify $head_name) ||
exit 1

echo onto=$onto
echo head_name=$head_name
echo orig_head=$orig_head

# Get the merge base, which is the root of the branch that we are rebasing.
# (For now, ignore the question of whether there is more than one merge base.)
mb=$(git merge-base "$onto" "$orig_head")
echo mb=$mb

# Get the list of commits to rebase, which is everything between $mb and
# $orig_head.
# Note that $mb is not included.
revisions=`git rev-list --reverse --ancestry-path $mb..$orig_head`
echo revisions=$revisions

# Set up the list mapping the commits on the original branch to the commits
# on the branch we are creating.
# Its format is ",old-hash1/new-hash1,old-hash2/new-hash2,...,".
# The initial value maps $mb to $onto.
map=",$mb/$onto,"

# Export these so git commit can see them.
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE

# Process each commit in forward topological order.
for cmt in $revisions
do
# Examine the commit to extract information we will need to reconstruct it.
# First parent of the commit that has a mapping, i.e., is part of the
# branch (and has thus been rebuilt already.
first_mapped_parent=
# The new commit that was made of $first_mapped_parent.
first_mapped_parent_mapped=
# List of -p options naming the parent commits, or their new commits if they
# are in the branch.
parents=
# Dissect the old commit's data.
# Output the commit data into FD 3.
exec 3< <( git cat-file commit $cmt )

while read keyword rest <&3
do
case $keyword in
tree)
# Ignored
;;
parent)
# See if the parent is mapped, i.e., is in the
# original branch.
if [[ "$map" == *,$rest/* ]]
then
# This parent has been mapped.  Get the new commit.
parent_mapped=${map#*,$rest/}
parent_mapped=${parent_mapped%%,*}
if test -z "$first_mapped_parent"
then
first_mapped_parent=$rest
first_mapped_parent_mapped=$parent_mapped
fi
else
# This parent has not been mapped.
parent_mapped=$rest
fi
# $parent_mapped is a parent of the new commit.
parents="$parents -p $parent_mapped"
;;
author)
# Extract the information about the author.
GIT_AUTHOR_NAME="${rest%% <*}"
GIT_AUTHOR_EMAIL="${rest##* <}"
GIT_AUTHOR_EMAIL="${GIT_AUTHOR_EMAIL%%> *}"
GIT_AUTHOR_DATE="${rest##*> }"
;;
committer)
# Ignored:  The new commit will have this user's name
# as committer.
;;
'')
# End of fixed fields, remainder is the commit comment.
# Leave contents of FD 3 queued to be read later by
# git commit-tree.
break
;;
*)
# Ignore all other keywords.
;;
esac
done

echo GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME"
echo GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL"
echo GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE"
echo parents="$parents"
echo first_mapped_parent=$first_mapped_parent
echo first_mapped_parent_mapped=$first_mapped_parent_mapped

test -n "$first_mapped

Re: [git-users] git replace

[Dale R. Worley]

> From: Alcolo Alcolo 

> My job is done!
> I don't need git replace any more !

Ah, great!

I've integrated your changes into my copy.

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] Delete all commits starting from a given commit

[Dale R. Worley]

> From: Simon Joseph Aquilina 

> The change was successful. However all previous commits still exist. In 
> other words for each commit with the wrong name / email I have another 
> commit with good name / email.
> 
> Is there a way how I can delete the old (those containing wrong name / 
> email) commits? 

Do these commits still show in the history of HEAD?  If the procedure
is correct, they shouldn't.  I'd expect that old, unreferenced commits
will eventually be garbage-collected.

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] Sort specific hash ids in reverse chronological order..

[Dale R. Worley]

> From: Kumar 

> I've got C, F, Z , Y to revert.  I need to have the recent id first, like 
> Z, Y, F, C so that the revert is correct and smooth.  

It looks like you can use "git log -1 " to find the date of each
hash.  Then use those to sort the hashes in time-order.  To automate
that, you'll probably have to construct a custom output format for
git-log.

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] removing old history from the archive

[Dale R. Worley]

> From: Michael Mossey 
> 
> I'm very new to git, and so far I'm using it more like a system to back up 
> files and transfer them from computer to computer, no branching or anything 
> complicated yet. In one directory tree, most of my files are binary files, 
> so git can't take advantage of storing only deltas and can't compress the 
> files much. My database size has skyrocketed in the past month as a result. 
> At the moment I really don't need versions of certain files or directories 
> older than, say, 2 weeks. Is there a way to delete old history by that 
> criteria (say anything before a specific date?).

If you're dealing with binary files whose contents change rapidly,
there aren't any good solutions.

I have some Git repositories which I use to track large parts of my
system.  One tracks all the "system" files.  I only do a commit once a
week or so, but since those files rarely change, the fact that many of
the files are binaries and don't compress well doesn't matter.

For my home directory, I keep a repository I call "time warp", which
is somewhat like Apple's Time Machine.  cron does a Git commit every
minute.  But every night I run a cron job to "prune" it by removing a
subset of the commits.  That requires recreating all of the commits,
because the parents of the commits changes.

There is a "rate" R, and the goal is that for times that are X minutes
in the past, only keep commits that are spaced X/R minutes apart.  In
this case, I set "git config time-warp.rate 365", so commits from two
days ago are pruned to be about 8 minutes apart, while commits from a
year ago are pruned to be about 1 day apart.  In the long run, the
number of commits grows about as the logarithm of how long I've been
running time-warp.

Dale
--
time-warp-prune

#! /bin/perl

use strict;

# Process the switches.

# $debug is the debugging print level.
my($debug) = 0;
# $do_gc is true if git-gc is to be done after pruning.
my($do_gc) = 1;
while ($ARGV[0] =~ /^-/) {
# The -d switch must have a numeric argument.
if ($ARGV[0] =~ /^-d([\d]+)$/) {
$debug = $1;
shift;
}
# The --no-gc switch suppresses the garbage collection afterward.
elsif ($ARGV[0] eq '--no-gc') {
$do_gc = 0;
shift;
}
# Handle unknown options.
else {
die "Unknown option: '", $ARGV[0], "'\n"
}
}
# Handle unknown arguments.
die "Unknown argument(s): ", join(' ', @ARGV) if $#ARGV >= 0;
if ($debug) {
print STDERR "\$debug = $debug\n";
print STDERR "\$do_gc = $do_gc\n";
}

# This is the rate at which commits are to be retained:
my($rate);
# At a time N in the past, commits should be spaced at most N/$rate
# apart.
# Thus, larger $rate values mean to keep more commits around.
# The rate is stored in the Git configuration as time-warp.rate.
# If the user entered it on the command line, it would be easier for
# the user to fumble-finger a small value and delete much of the
# history he wanted to save.
my($config_name) = 'time-warp.rate';
my($command) = 'git config ' . $config_name;
chomp($rate = `$command`);
my($r) = $? >> 8;
if ($r != 0) {
warn "Could not obtain Git configuration value '$config_name'.\n";
die "Error executing '$command': exit code $r\n" if $r;
} elsif (!($rate =~ /^\d+$/ && $rate >= 1)) {
die "Rate value '$rate' is syntactically incorrect or less than 1.\n";
}
print STDERR "\$rate = $rate\n" if $debug;

# Get the hashes and times of the commit history.
# Note that we are assuming that the current branch of the repository
# is the branch to be operated upon.
$command = "git log --pretty=tformat:'%H %ct'";
print STDERR "\$command = $command\n" if $debug >= 3;
open(GIT, "-|", $command) ||
die "Error executing '$command' for input: $!\n";
# Note that "git log" lists commits going back in time, so @hashes and @times
# will describe the latest commits first.
my(@hashes, @times);
while () {
chomp;
my($hash, $time) = split;
push(@hashes, $hash);
push(@times, $time);
print STDERR "\$hashes[", $#hashes, "] = $hash, \$times[", $#times, "] = 
$time\n" if $debug >= 2;
}
close GIT || die "Error closing '$command': $!\n";

# Get the "now" time, which is the time of the last commit.
my($now) = $times[0];
print STDERR "\$now = $now\n" if $debug;

# Now, working from oldest to newest, look at each commit and decide whether
# to recreate it.
# The last commit we've recreated and its time.
my($last_commit) = '';
my($last_commit_time) = 0;
my($commits_created) = 0;
print STDERR "\$last_commit = $last_commit, \$last_commit_time = 
$last_commit_time\n"
if $debug;
# Cycle through the commits from the oldest to the newest, recreating
# the commit chain, retaining the commits we desire.
for (my $i = $#hashes; $i >= 0; $i--) {
print STDERR "\$i = $i, \$hashes[$i] = $hashes[$i], \$times[$i] = 
$times[$i]\n"
if $debug;
# Test if co

Re: [git-users] Can't clean "untracked changes."

[Dale R. Worley]

> From: Chris Carter 
> 
> `git status` showed lines resembling this:
> modified:(untracked content)
> 
> I found that these commands refused to properly restore me to a "pristine" 
> state, matching my remote:

I'm no expert, but I'd say it's a design decision:  If Git isn't
supposed to track xyzzy, then it also shouldn't delete it.

The usual way of getting untracked stuff into your working directory
is by compiling things, and the usual way of getting rid of it is
"make clean" or "make distclean".

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] Git on WD My Cloud Drive

[Dale R. Worley]

> From: Kevin Brooks 
> 
> Has anyone set up a Git repository on a WD My Cloud Drive?  If so I could 
> use some help.

It would be more efficient if you told us what wasn't working as
expected.

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] git rev-list --objects doesn't show moves

[Dale R. Worley]

> From: Roman Neuhauser 
> 
> i'm writing an alternative to git-requet-pull.  its output includes
> a log of the commit range, eg:
> 
>   1/3 76a23b86 043603cc README fancier
>   162441d0 README
>   2/3 87990615 ab984c9b ignore vim swapfiles
>   32682119 .gitignore
>   3/3 2c842d2d 2ab371a4 README is now README.txt
> 
> each commit is represented by a line giving its position in the range,
> the treeid, the commitid and the subject line, followed by a series of
> lines identifying affected files, each line with the objectid and path.
> 
> i'm gathering the data with `git-rev-list --objects`, but it doesn't
> mention objects that were moved (git mv) in a given commit; this is
> visible in the last (3/3) commit in the example above: that commit was
> just `git mv README README.txt`.
> 
> i want the output to identify moves and copies.  what are my options?
> am i missing an option in git-rev-list(1)?  should i use a different
> piece of plumbing?

The fundamental problem is that Git's data structures don't list moves
and copies.  For that matter, they don't list adds and deletes,
either.  As stored, each commit just tells the contents of the
directory tree.  What you appear to want is something that compares
one or more commits and tells what the differences between them are.

OTOH, is that what you *really* want?  You say that you're "writing an
alternative to git-request-pull".  What is the definition of this
output?  What purposes do you expect the output to be put to?

For instance, when you're pulling commit 3/3 from the remote, you
don't *need* to download the blob that is the current contents of
README.txt (and the former contents of README) because you already
have it in your repository.  So "git-rev-list --objects" doesn't list
it.

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] git rev-list --objects doesn't show moves

[Dale R. Worley]

> From: Roman Neuhauser 

> yup, i'd like a plumbing equivalent of `git log --raw ...`.  AFAICT
> the closest to that is git-diff-tree, except that implies N invocations
> instead of one, a sad loss of efficiency i'd love to avoid.

You may be beyond my knowledge here, but if you want to list the
changes that were made to the file-tree by each of a series of
commits, you will pretty much have to do one invocation of diff-tree
for each commit, or something else that is functionally equivalent.
The reason is that there is no stored summary of "what is changed by
this commit", the only way to determine that information is to compare
each file reference of each commit with the cognate file reference in
its predecessor commit.  There's no way to do that whose run time is
not proportional to both the number of commits and the number of
files.

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] Re: File dates after CHECKOUT

[Dale R. Worley]

Ultimately, the reason that Git (and other Un*x-focused SCMs) behave
this way is so that if you check out a new version and then run
'make', everything needed is rebuilt.  If a file had new contents but
its creation date is in the past, then files derived from it might not
be rebuilt.

> From: Gergely Polonkai 
> 
> That said, it still can be done, although it is not natively supported, you
> may do it with some custom tool. By finding the last commit a specific file
> was modified in, you may apply the date of the commit to that file.
> However, if you have a large repository, looking at this information for
> each single file may take really long. Still, it looks like an interesting
> project if your build environment really requires it…

You know, a C program that walked up the tree of ancestor commits
reading out the blob indexes in the file trees to assemble that data
would run rather fast, because there's not a lot of data to be
processed.

There is a treacherous design question of defining exactly what date
you want on each file.  What *exactly* is the debugger looking for?
(It probably isn't the date the file contents were first committed to
the repository.)  If the answer is "I need the file creation dates to
match the dates recorded in XYZ." probably the easiest solution is to
read the dates out of XYZ and apply them to the files.

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] Is it possible to git add a set of files as non-text, irrespective of any .gitattributes files?

[Dale R. Worley]

> From: Sam Roberts 

> I could write a local .gitattributes, do the `git add -A -f .`, and
> remove the .gitattributes... but that's not "atomic". I'm doing this
> all in a much larger script, I'm worried about damaging the local
> user's repo.

I'm no expert here, but how would it "damage the local user's repo"?
All you have to ensure is that the .gitattributes not be part of the
commit, and that during the git-add, it contains the right contents to
get the effect you want.

You *might* leave the modified .gitattributes file in the user's
working directory, but as long as you arrange that the modifications
only describe the "temporary" text files, that shouldn't interfere
with any "real" files.

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] git rev-list --objects doesn't show moves

[Dale R. Worley]

> From: Roman Neuhauser 

> the inefficiency i'd like to avoid is in the diff-tree initialization.
> while the strace output is nice and short, most of it is loading shared
> libraries and reading the various .git* files; i hoped there would be
> a way to spend that energy once per N commits described.

That might be less important than it seems:

I once wrote a revision of "tar" that could write compressed tar files
to a tape drive.  (The tape drive did not have built-in compression.)
The standard "tar" can do that, but it compresses the entire tar file
as a unit, so if any part of the file is corrupted, you can't read the
remainder of the file.  This is not good for a backup tape.

So I modified tar to compress each file individually before putting it
into the tar file.  As a first implementation, I had tar simply create
a subprocess which ran gzip -- once for each file that was written.
So gzip was run tens to hundreds of thousands of times when writing a
backup tape.

The effect on performance was zero.  (And this was on a processor that
ran at tens of MHz.)  The reason seemed to be that once all the files
that are needed to get a gzip process running are in the disk cache,
the process starts *very* quickly.  Yes, it takes a zillion CPU
cycles, but that's not the slow part of the computer.

So don't fret about the efficiency of part of your system before you
know that it is actually performance-limiting.

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] Is it possible to git add a set of files as non-text, irrespective of any .gitattributes files?

[Dale R. Worley]

> From: Sam Roberts 
> 
> And that after, its removed, even if the user SIGTERMed your command
> during the add, before the script got to removing the .gitattributes.

One possiblity is to make sure that the temporary files you are
concerned with have names that are disjoint from any non-temporary
files.  Then if .gitattributes gets polluted, it doesn't matter,
because the temporary entries can never affect a non-temporary file.

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] git add --all --no-binaries

[Dale R. Worley]

> From: Constantine Tarasenkov 
> 
> Wouldn't be cool to have a flag that skips binary files on staging area? 
> I'm pretty sure Git can detect binary files before the commit. Does someone 
> knows other ways not including them automatically?

The trouble is that "binary" isn't the criterion you want.  Sometimes
binary files are original files in a software distribution.  And
sometimes text files are generated files.

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] Files are commiting without staging

[Dale R. Worley]

> From: John Hite 

> Is there some config setting that causes my modified files to be
> staged automatically?

Well, if you accidentally used "git commit -a", it would do that.  But
there doesn't seem to be a config setting to force that behavior.

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] Combining multiple repositories into one

[Dale R. Worley]

> From: Richard Kennaway 
> 
> This is an obviously insane arrangement, but never mind how it got like 
> that, it is like that. I would like move from the current state, which is a 
> directory Z containing repositories A, B, C, D, to having a git repository 
> Z, containing directories A, B, C, D.
> 
> If I didn't care about preserving history or any but master branches I 
> could just export everything from all the repositories and create a brand 
> new repository. But I do want to preserve history and branches.

One approach that should be workable runs like this.  Unfortunately, I
don't know Git well enough to know exactly the right commands, but if
it does what you want, you can work out how to do it, and probably
write a script that does it fairly automatically.

1. Create a new, empty repository.

2. For each branch that you want to merge:  (That is, you want to combine
branch A.b1 of A, branch B.b1 of B, branch C.b1 of C, etc., into
branch b1 of the new repository.)

3. Import each of the branches into the new repository using
git-fetch.  Give each one a unique branch name in some manner.  This
gets all the needed objects for the new branch into the new
repository's object store.

4. Delete all the files in the working directories of the new
repository and manually assemble the file tree that you want in the
working directories.  If all you want is one directory containing
subdirectories that contain copies of each component branch, this can
be done by script, copying the file trees from the old repositories.
Use git-add to force the index to match the working directories.

5. Use git-write-tree to create a tree object from the index.

6. Use git-commit-tree to create a new commit, giving it the hash of
the tree created in step 5 as the tree pointer, and using multiple -p
arguments to list as parents the hashes of all of the source branches.

7. Use git-update-ref to update the corresponding branch head in the
new repository with the commit created in step 6.

The result is a branch in the new repository whose head commit has the
contents you want, and which lists as parents all of the component
branches you combined to create it.  Presumably the Git commands which
try to track the origins of each file can find which of the parents
each file came from.

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] Trying to commit to branches from different local folders.

[Dale R. Worley]

> From: Martyn Leeper 

> I'm pretty new to Git. I've managed to do different things like pull, push, 
> fetch, delete, etc to and from Github using Git. I'm wondering, is it 
> possible to making commits (upload) from different local folders (on my 
> computer e.g. C:\Branches\Foo & C:\Branches\Boo) to different Branches on 
> my Github account.
> 
> Essentially doing the following:
> 
> Foo (Local) -> Foo (Github)
> Boo (Local) -> Boo (Github)

I describe it this way:

If C:\Branches\Foo and C:\Branches\Boo are two different repositories,
then each of them can upload commits that have been made locally to
the "master" repository on Github.

If they are part of one repository, what you are asking is if you can
create a commit locally out of the files in directory Foo (part of the
working tree) and then upload that commit to Github.

The central point is that what is uploaded and downloaded are
*commits*.  When a commit is moved, all of the objects that it
references are copied as well (if they aren't already present in the
destination repository).

I believe that you can create a commit in a repository that only
contains the changes made in a specific subdirectory.  You do that by
invoking "git-add" with a pathspec which is the directory.  It may be
more difficult to add it to a particular branch if it is not the
normal case where the files in the working tree reflect the head of
that branch.

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.