Re: [git-users] whats the difference?
On Sat, 23 Aug 2014 00:08:49 -0700 (PDT) eamira...@gmail.com wrote: would you please tell me what advantages will I get if I change our source control system from sourcesafe to git? I know about the differences but please tell me about the branching part!!!if we change similar files in our master code and they wont be done on our different projects(different depositories) and the opposite I mean that if we change some files in some projects and want to do the changes in our master code or other projects so why you think git is better? you told me that its not possible!what is a solution? Please take time and download (or buy) an introductory-level book on Git and read a couple of blog posts on it, really. Git is so popular there's really no shortage of information on it, so there's no need to ask here for what's already available. -- 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] Cherry picking fails for obscure reasons
- Original Message - From: Torsten Bronger To: git-users@googlegroups.com Sent: Friday, August 22, 2014 12:24 PM Subject: [git-users] Cherry picking fails for obscure reasons Hallöchen! I try to merge two repos, yielding a flat (aka interleaved) history. I do this along the lines of http://stackoverflow.com/a/14839653/188108, under History rewrite:. The two branches to merge are in master and src/master. Then, I write: $ git checkout --orphan new-master $ git cherry-pick 9d325d6d 3f4c52ba error: a cherry-pick or revert is already in progress hint: try git cherry-pick (--continue | --quit | --abort) fatal: cherry-pick failed $ git cherry-pick 9d325d6d git cherry-pick 3f4c52ba [new-master 10f0277] Initial revision. 7 files changed, 194 insertions(+) create mode 100644 __init__.py create mode 100644 manage.py create mode 100644 samples/__init__.py create mode 100644 samples/models.py create mode 100644 samples/views.py create mode 100644 settings.py create mode 100644 urls.py [new-master 08e083c] Fixed field name in SixChambersLayer. Added Sample.current_place. 1 file changed, 2 insertions(+), 1 deletion(-) So, why does the first cherry pick command fail, but the split command works? I use git 1.9.1. Tschö, Torsten. How are the two commits related? Do they form a commit range? The command doesn't take a list of commits, rather you need to look at the gitrevisions guide and git-rev-list as decribed on the git cherry-pick man page. Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] strange histories from git filter-branch
From: Bernard Clark berniecla...@gmail.com I've been running the git filter-branch described here http://stackoverflow.com/questions/14759345/how-to-split-a-git-repository-and-follow-directory-renames. . 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 http://stackoverflow.com/questions/15161809/git-duplicate-parent-causes-half-the-history-to-to-disappear 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 http://stackoverflow.com/questions/7489713/git-duplicate-parent/7501703#7501703, 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?
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
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.
[git-users] Git rebase command!
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 machine-name 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 -- 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!
- Original Message - From: Gopi Naidu To: git-users@googlegroups.com Sent: Monday, August 25, 2014 10:29 AM Subject: [git-users] Git rebase command! 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 machine-name 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 -- Hi Gopi, As the message says, the 'git' command cannot find any of it's sub-commands (internally spelt git-cmd. i.e. all the sub commands are real commands in their own right. This suggests that the installation path isn't right. e.g. the 'git' (three characters) command is linked by some special mechanism on your machine. Philip -- -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Cherry picking fails for obscure reasons
Am Dienstag, 26. August 2014 20:38:56 UTC+2 schrieb Philip Oakley: - Original Message - *From:* Torsten Bronger javascript: *To:* git-...@googlegroups.com javascript: *Sent:* Friday, August 22, 2014 12:24 PM *Subject:* [git-users] Cherry picking fails for obscure reasons The two branches to merge are in master and src/master. Then, I write: $ git checkout --orphan new-master $ git cherry-pick 9d325d6d 3f4c52ba error: a cherry-pick or revert is already in progress hint: try git cherry-pick (--continue | --quit | --abort) fatal: cherry-pick failed $ git cherry-pick 9d325d6d git cherry-pick 3f4c52ba [new-master 10f0277] Initial revision. 7 files changed, 194 insertions(+) create mode 100644 __init__.py create mode 100644 manage.py create mode 100644 samples/__init__.py create mode 100644 samples/models.py create mode 100644 samples/views.py create mode 100644 settings.py create mode 100644 urls.py [new-master 08e083c] Fixed field name in SixChambersLayer. Added Sample.current_place. 1 file changed, 2 insertions(+), 1 deletion(-) So, why does the first cherry pick command fail, but the split command works? I use git 1.9.1. How are the two commits related? Do they form a commit range? Yes, they are consecutive commits in one of the branches. But I don't see why they must. It should work in any case. The command doesn't take a list of commits, rather you need to look at the gitrevisions guide and git-rev-list as decribed on the git cherry-pick man page. The gitrevisions guide suggests that giving A B means to, well, apply A and B. I cannot see any text saying that a list of commits is forbidden. Besides, git's error message is opaque to me. -- 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.
