* [PATCH 2/2] git-p4: Add copy detection support
From: Vitor Antunes @ 2011-01-30 23:19 UTC (permalink / raw)
To: git; +Cc: Vitor Antunes
In-Reply-To: <1296429563-18390-1-git-send-email-vitor.hda@gmail.com>
Add new config options:
git-p4.detectCopies - Enable copy detection.
git-p4.detectCopiesHarder - Find copies harder.
The detectCopies option should be set to a true/false value.
The detectCopiesHarder option should be set to true/false value.
P4Submit can now process diff-tree C status and integrate files accordingly.
---
contrib/fast-import/git-p4 | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 9fb480a..9b67ae2 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -620,6 +620,14 @@ class P4Submit(Command):
else:
diffOpts = ("", "-M")[self.detectRename]
+ detectCopies = gitConfig("git-p4.detectCopies")
+ if len(detectCopies) and detectCopies.lower() != "false" > 0:
+ diffOpts += " -C"
+
+ detectCopiesHarder = gitConfig("git-p4.detectCopiesHarder")
+ if len(detectCopiesHarder) > 0 and detectCopiesHarder.lower() != "false":
+ diffOpts += " --find-copies-harder"
+
diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (diffOpts, id, id))
filesToAdd = set()
filesToDelete = set()
@@ -643,6 +651,15 @@ class P4Submit(Command):
filesToDelete.add(path)
if path in filesToAdd:
filesToAdd.remove(path)
+ elif modifier == "C":
+ src, dest = diff['src'], diff['dst']
+ p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
+ if diff['src_sha1'] != diff['dst_sha1']:
+ p4_system("edit \"%s\"" % (dest))
+ if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
+ filesToChangeExecBit[dest] = diff['dst_mode']
+ os.unlink(dest)
+ editedFiles.add(dest)
elif modifier == "R":
src, dest = diff['src'], diff['dst']
p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] git-p4: Improve rename detection support.
From: Vitor Antunes @ 2011-01-30 23:19 UTC (permalink / raw)
To: git; +Cc: Vitor Antunes
Only open files for edit after integrating if the SHA1 of source and destination
differ from each other.
Add git config option detectRenames to allow permanent rename detection. This
options should be set to a true/false value.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04ce7e3..9fb480a 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -613,7 +613,13 @@ class P4Submit(Command):
def applyCommit(self, id):
print "Applying %s" % (read_pipe("git log --max-count=1 --pretty=oneline %s" % id))
- diffOpts = ("", "-M")[self.detectRename]
+
+ detectRenames = gitConfig("git-p4.detectRenames")
+ if len(detectRenames) and detectRenames.lower() != "false" > 0:
+ diffOpts = "-M"
+ else:
+ diffOpts = ("", "-M")[self.detectRename]
+
diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (diffOpts, id, id))
filesToAdd = set()
filesToDelete = set()
@@ -640,7 +646,8 @@ class P4Submit(Command):
elif modifier == "R":
src, dest = diff['src'], diff['dst']
p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
- p4_system("edit \"%s\"" % (dest))
+ if diff['src_sha1'] != diff['dst_sha1']:
+ p4_system("edit \"%s\"" % (dest))
if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
filesToChangeExecBit[dest] = diff['dst_mode']
os.unlink(dest)
--
1.7.2.3
^ permalink raw reply related
* Re: [RFC] Add --create-cache to repack
From: Nicolas Pitre @ 2011-01-30 22:26 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Johannes Sixt, git, John Hawley
In-Reply-To: <AANLkTi=mbeBsR5tr4J7kQCL6YqiGfttK01VUN016aapC@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1485 bytes --]
On Sun, 30 Jan 2011, Shawn Pearce wrote:
> On Sun, Jan 30, 2011 at 00:05, Junio C Hamano <gitster@pobox.com> wrote:
> > Shawn Pearce <spearce@spearce.org> writes:
> >
> >> Using this for object enumeration shaves almost 1 minute off server
> >> packing time; the clone dropped from 3m28s to 2m29s. That is close to
> >> what I was getting with the cached pack idea, but the network transfer
> >> stayed the small 376 MiB.
> >
> > I like this result.
>
> I'm really leaning towards putting this cached object list into JGit.
>
> I need to shave that 1 minute off server CPU time. I can afford the 41
> MiB disk (and kernel buffer cache), but I cannot really continue to
> pay the 1 minute of CPU on each clone request for large repositories.
> The object list of what is reachable from commit X isn't ever going to
> change, and the path hash function is reasonably stable. With a
> version code in the file we can desupport old files if the path hash
> function changes. 10% more disk/kernel memory is cheap for some of my
> servers compared to 1 minute of CPU, and some explicit cache
> management by the server administrator to construct the file.
Yep, I think this is probably the best short term solution. Just walk
the commit graph as usual, and whenever the commit tip from the cache is
matched then just shove the entire cache content in the object list.
And let's hope that eventually some future developments will make this
cache redundant and obsolete.
Nicolas
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: Shawn Pearce @ 2011-01-30 22:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, git, Junio C Hamano, John Hawley
In-Reply-To: <AANLkTi=U7qRRij=BQXC1Goqa9toDFfaVKT=+-8zYxCcc@mail.gmail.com>
On Fri, Jan 28, 2011 at 17:32, Shawn Pearce <spearce@spearce.org> wrote:
>
> I fully implemented the reuse of a cached pack behind a thin pack idea
> I was trying to describe in this thread. It saved 1m7s off the JGit
> running time, but increased the data transfer by 25 MiB. I didn't
> expect this much of an increase, I honestly expected the thin pack
> portion to be well, thinner.
JGit's thin pack creation is crap. For example, this is the same fetch:
$ git fetch ../tmp_linux26
remote: Counting objects: 61521, done.
remote: Compressing objects: 100% (12096/12096), done.
remote: Total 50275 (delta 42578), reused 45220 (delta 37524)
Receiving objects: 100% (50275/50275), 11.13 MiB | 7.29 MiB/s, done.
Resolving deltas: 100% (42578/42578), completed with 4968 local objects.
$ git fetch git://localhost/tmp_linux26
remote: Counting objects: 144190, done
remote: Finding sources: 100% (50275/50275)
remote: Compressing objects: 100% (106568/106568)
remote: Compressing objects: 100% (12750/12750)
Receiving objects: 100% (50275/50275), 24.66 MiB | 10.93 MiB/s, done.
Resolving deltas: 100% (40345/40345), completed with 2218 local objects.
JGit produced an extra 13.53 MiB for this pack, because it missed
about 2,233 delta opportunities. It turns out we are too aggressive
at pushing objects from the edges into the delta windows. JGit pushes
*everything* in the edge commits, rather than only the paths that are
actually used by the objects we need to send. This floods the delta
search window with garbage, and makes it less likely that an object to
be sent will find a relevant delta base in the search window.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] merge: default to @{upstream}
From: Jonathan Nieder @ 2011-01-30 21:51 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Drew Northup, git
In-Reply-To: <AANLkTi=iMJv+Jtj8YdYhQ_sxu+jBht5YqvSnkS2LUerz@mail.gmail.com>
Hi again,
Felipe Contreras wrote:
[out of order for convenience]
> Anyway, I don't think we can set argv[1] to NULL, because it's
> possible that this is "char *argv[1]", so that would crash.
The original argc is at least 1 (to include "merge" as argv[0]) before
the args are shifted by parse_options_end. But probably that is too
tricky to rely on.
> Sure, I need to add documentation and tests. I should probably have
> sent this as 'RFC'.
No problem. Thanks for keeping the topic alive.
^ permalink raw reply
* Re: [PATCH] Handle rename of case only, for Windows
From: Jonathan Nieder @ 2011-01-30 21:39 UTC (permalink / raw)
To: Tim Abell; +Cc: René Scharfe, git
In-Reply-To: <1296406435.8170.1418006125@webmail.messagingengine.com>
Hi Tim,
Tim Abell wrote:
> Thanks for your feedback, you are undoubtedly right about checking
> the return value
[...]
> What do I need to do from here to make my patch acceptable/useful to
> git's maintainers?
Generic answer: see Documentation/SubmittingPatches, section labelled
"An ideal patch flow". Basically you (or anyone else interested it
getting it accepted) are the maintainer of the patch, so you can make
improvements until you and others are happy with it.
Hope that helps,
Jonathan
^ permalink raw reply
* [PATCH 2/2] Documentation/branch: briefly explain what a branch is
From: Jonathan Nieder @ 2011-01-30 21:35 UTC (permalink / raw)
To: Konstantin Khomoutov
Cc: João Paulo Melo de Sampaio, GIT Mailing List, Jakub Narebski
In-Reply-To: <20110130213258.GA10039@burratino>
The new reader might not know what git refs are, that history is a
graph, the distinction between local, remote-tracking, and remote
branches, or how to visualize what is going on. After this change,
those things are still probably not evident but at least there is an
early reminder of some of it.
Also explain how to create a branch before explaining how to list
them. Based roughly on the description of v0.99.1~53 (Add "git
branch" script, 2005-07-11).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-branch.txt | 35 ++++++++++++++++++++---------------
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index d3eeb94..abad7ba 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -18,6 +18,26 @@ SYNOPSIS
DESCRIPTION
-----------
+Branches are references to commit objects, representing the tip of a
+line of history. The branch you are working on is referred to
+by HEAD and the corresponding reference is updated each time
+linkgit:git-commit[1] or linkgit:git-merge[1] makes a new commit.
+
+'git branch' <branchname> [<start-point>]::
+ Creates a new branch named `<branchname>`.
+ If a starting point is specified, that will be where the branch
+ is created; otherwise, the new branch points to the `HEAD` commit.
++
+This will create a new branch, but it does not switch the working tree
+to it. Use "git checkout <newbranch>" to start working on the new branch.
+
+When a local branch is started off a remote-tracking branch, git sets up the
+branch so that 'git pull' will appropriately merge from
+the remote-tracking branch. This behavior may be changed via the global
+`branch.autosetupmerge` configuration flag. That setting can be
+overridden by using the `--track` and `--no-track` options, and
+changed later using `git branch --set-upstream`.
+
'git branch' [-r | -a]::
With no arguments, existing branches are listed and the current
branch will be highlighted with an asterisk.
@@ -34,21 +54,6 @@ DESCRIPTION
commit will be listed. If the <commit> argument is missing it
defaults to 'HEAD' (i.e. the tip of the current branch).
-'git branch' <branchname> [<start-point>]::
- The command's second form creates a new branch head named <branchname>
- which points to the current 'HEAD', or <start-point> if given.
-+
-Note that this will create the new branch, but it will not switch the
-working tree to it; use "git checkout <newbranch>" to switch to the
-new branch.
-+
-When a local branch is started off a remote-tracking branch, git sets up the
-branch so that 'git pull' will appropriately merge from
-the remote-tracking branch. This behavior may be changed via the global
-`branch.autosetupmerge` configuration flag. That setting can be
-overridden by using the `--track` and `--no-track` options, and
-changed later using `git branch --set-upstream`.
-
'git branch' (-m | -M) <oldbranch> <newbranch>::
With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
If <oldbranch> had a corresponding reflog, it is renamed to match
--
1.7.4.rc3
^ permalink raw reply related
* [PATCH 1/2] Documentation/branch: split description into subsections
From: Jonathan Nieder @ 2011-01-30 21:33 UTC (permalink / raw)
To: Konstantin Khomoutov
Cc: João Paulo Melo de Sampaio, GIT Mailing List, Jakub Narebski
In-Reply-To: <20110130213258.GA10039@burratino>
Add headings for each form of the "git branch" command. Hopefully
this will make the description easier to read straight through without
getting lost and help technical writers to see what needs improvement
in the treatment of each form.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-branch.txt | 53 +++++++++++++++++++++++------------------
1 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 9106d38..d3eeb94 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -18,25 +18,30 @@ SYNOPSIS
DESCRIPTION
-----------
-With no arguments, existing branches are listed and the current branch will
-be highlighted with an asterisk. Option `-r` causes the remote-tracking
-branches to be listed, and option `-a` shows both.
+'git branch' [-r | -a]::
+ With no arguments, existing branches are listed and the current
+ branch will be highlighted with an asterisk.
+ Option `-r` causes the remote-tracking branches to be listed,
+ and option `-a` shows both.
-With `--contains`, shows only the branches that contain the named commit
-(in other words, the branches whose tip commits are descendants of the
-named commit). With `--merged`, only branches merged into the named
-commit (i.e. the branches whose tip commits are reachable from the named
-commit) will be listed. With `--no-merged` only branches not merged into
-the named commit will be listed. If the <commit> argument is missing it
-defaults to 'HEAD' (i.e. the tip of the current branch).
-
-The command's second form creates a new branch head named <branchname>
-which points to the current 'HEAD', or <start-point> if given.
+'git branch' (--contains | --merged | --no-merged) [<commit>]::
+ With `--contains`, shows only the branches that contain the
+ named commit (in other words, the branches whose tip commits are
+ descendants of the named commit). With `--merged`, only
+ branches merged into the named commit (i.e. the branches whose
+ tip commits are reachable from the named commit) will be listed.
+ With `--no-merged` only branches not merged into the named
+ commit will be listed. If the <commit> argument is missing it
+ defaults to 'HEAD' (i.e. the tip of the current branch).
+'git branch' <branchname> [<start-point>]::
+ The command's second form creates a new branch head named <branchname>
+ which points to the current 'HEAD', or <start-point> if given.
++
Note that this will create the new branch, but it will not switch the
working tree to it; use "git checkout <newbranch>" to switch to the
new branch.
-
++
When a local branch is started off a remote-tracking branch, git sets up the
branch so that 'git pull' will appropriately merge from
the remote-tracking branch. This behavior may be changed via the global
@@ -44,16 +49,18 @@ the remote-tracking branch. This behavior may be changed via the global
overridden by using the `--track` and `--no-track` options, and
changed later using `git branch --set-upstream`.
-With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
-If <oldbranch> had a corresponding reflog, it is renamed to match
-<newbranch>, and a reflog entry is created to remember the branch
-renaming. If <newbranch> exists, -M must be used to force the rename
-to happen.
-
-With a `-d` or `-D` option, `<branchname>` will be deleted. You may
-specify more than one branch for deletion. If the branch currently
-has a reflog then the reflog will also be deleted.
+'git branch' (-m | -M) <oldbranch> <newbranch>::
+ With a '-m' or '-M' option, <oldbranch> will be renamed to <newbranch>.
+ If <oldbranch> had a corresponding reflog, it is renamed to match
+ <newbranch>, and a reflog entry is created to remember the branch
+ renaming. If <newbranch> exists, -M must be used to force the rename
+ to happen.
+'git branch' (-d | -D) <branchname>::
+ With a `-d` or `-D` option, `<branchname>` will be deleted. You may
+ specify more than one branch for deletion. If the branch currently
+ has a reflog then the reflog will also be deleted.
++
Use -r together with -d to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
in the remote repository or if 'git fetch' was configured not to fetch
--
1.7.4.rc3
^ permalink raw reply related
* [RFC/PATCH 0/2] Re: Remote branchs -- how can I check them out?
From: Jonathan Nieder @ 2011-01-30 21:32 UTC (permalink / raw)
To: Konstantin Khomoutov
Cc: João Paulo Melo de Sampaio, GIT Mailing List, Jakub Narebski
In-Reply-To: <20110130160556.GI5713@localhost.localdomain>
Konstantin Khomoutov wrote:
> These branches are local to your repository. They are "remote" in the
> sense you're not supposed to modify them directly.
> So to inspect such a branch just use its full name ("origin/next" for
> instance) when working with commands like git-log.
>
> See [1], [2] for more info.
>
> Also your question appears to be quite basic which hints at that you did
> not read a good book on Git before using it. So starting at [3] is
> recommended -- it mentions a bunch of good books and manuals
Pointing to good references is a valuable thing --- thank you for that.
But I also want to point out that if you need to read a book before Git
becomes usable then we are doing something wrong. :)
In this example, perhaps the "git branch" manual page needs some
improvement?
Jonathan Nieder (2):
Documentation/branch: split description into subsections
Documentation/branch: briefly explain what a branch is
Documentation/git-branch.txt | 62 +++++++++++++++++++++++++-----------------
1 files changed, 37 insertions(+), 25 deletions(-)
^ permalink raw reply
* [PATCH v2] Disallow empty section and variable names
From: Libor Pechacek @ 2011-01-30 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <20110127145253.GD6312@fm.suse.cz>
It is possible to break your repository config by creating an invalid key. The
config parser in turn chokes on it.
$ git init
Initialized empty Git repository in /tmp/gittest/.git/
$ git config .foo false
$ git config .foo
fatal: bad config file line 6 in .git/config
This patch makes git-config reject keys which start or end with a dot, adds
tests for these cases and also fixes a typo in t5526-fetch-submodules, which
was exposed by the new check.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
---
Added tests for the cases checked, made git_config_parse_key consistently
return -2 when the key is invalid. Applies on top "Sanity-check config
variable names".
config.c | 8 +++++++-
t/t1300-repo-config.sh | 4 ++++
t/t5526-fetch-submodules.sh | 2 +-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index fde91f5..e27a39f 100644
--- a/config.c
+++ b/config.c
@@ -1120,11 +1120,17 @@ int git_config_parse_key(const char *key, char **store_key, int *baselen_)
* key name separated by a dot, we have to know where the dot is.
*/
- if (last_dot == NULL) {
+ if (last_dot == NULL || *key == '.') {
error("key does not contain a section: %s", key);
return -2;
}
+ i = strlen(key);
+ if (i && key[i-1] == '.') {
+ error("key does not contain variable name: %s", key);
+ return -2;
+ }
+
baselen = last_dot - key;
if (baselen_)
*baselen_ = baselen;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index c3d91d1..568d51d 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -889,6 +889,10 @@ test_expect_success 'key sanity-checking' '
test_must_fail git config foo.1bar &&
test_must_fail git config foo."ba
z".bar &&
+ test_must_fail git config . &&
+ test_must_fail git config .foo &&
+ test_must_fail git config foo. &&
+ test_must_fail git config .foo. &&
git config foo.bar true &&
git config foo."ba =z".bar false
'
diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
index 884a5e5..7106c6c 100755
--- a/t/t5526-fetch-submodules.sh
+++ b/t/t5526-fetch-submodules.sh
@@ -124,7 +124,7 @@ test_expect_success "--recurse-submodules overrides fetchRecurseSubmodules setti
(
cd downstream &&
git fetch --recurse-submodules >../actual.out 2>../actual.err &&
- git config -f --unset .gitmodules submodule.submodule.fetchRecurseSubmodules true &&
+ git config -f .gitmodules --unset submodule.submodule.fetchRecurseSubmodules true &&
git config --unset submodule.submodule.fetchRecurseSubmodules
) &&
test_cmp expect.out actual.out &&
--
1.7.4.rc3.11.g54760
^ permalink raw reply related
* Re: [RFC] Add --create-cache to repack
From: Shawn Pearce @ 2011-01-30 20:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Johannes Sixt, git, John Hawley
In-Reply-To: <7vaaiib1n1.fsf@alter.siamese.dyndns.org>
On Sun, Jan 30, 2011 at 12:02, Junio C Hamano <gitster@pobox.com> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
>>> The amount of transfer being that small was something I didn't quite
>>> expect, though. Doesn't it indicate that our pathname based object
>>> clustering heuristics is not as effective as we hoped?
>>
>> I'm not sure I follow your question.
>
> I didn't see path information in your cachefile that contains C commits, T
> trees, etc. that sped up the object enumeration, but you didn't observe
> much transfer inflation over the stock git.
I didn't store the path itself, I stored the path hash as a 4 byte
int. Its smaller, but still helps to schedule the object into the
right position in the delta search.
--
Shawn.
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Martin Langhoff @ 2011-01-30 20:19 UTC (permalink / raw)
To: Guy Rouillier
Cc: Junio C Hamano, Jonathan Nieder, Emil Medve, git, Pascal Obry,
Clemens Buchacher
In-Reply-To: <4D450655.5090501@burntmail.com>
On Sat, Jan 29, 2011 at 11:33 PM, Guy Rouillier <guyr@burntmail.com> wrote:
> That was my original inclination. As no other opinions have been posted
> since your message, here is my amended patch, incorporating Martin's
> ideas and dieing if the script finds both CVS and CVSNT password files.
ACK! Thanks!
m
--
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: Junio C Hamano @ 2011-01-30 20:02 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Johannes Sixt, git, John Hawley
In-Reply-To: <AANLkTi=mbeBsR5tr4J7kQCL6YqiGfttK01VUN016aapC@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
>> The amount of transfer being that small was something I didn't quite
>> expect, though. Doesn't it indicate that our pathname based object
>> clustering heuristics is not as effective as we hoped?
>
> I'm not sure I follow your question.
I didn't see path information in your cachefile that contains C commits, T
trees, etc. that sped up the object enumeration, but you didn't observe
much transfer inflation over the stock git.
> Ooooh.
>
> I think my test was flawed. I injected the cached pack's tip as the
> edge for the new stuff to delta compress against.
That is one of the things I was wondering. I manually created a thin pack
with only the 1-month-old tip as boundary, and another with all the
boundaries that can be found by rev-list. I didn't find much difference
in the result, though, as "rev-list --boundary --all --not $onemontholdtip"
had only a few boundary entries in my test.
^ permalink raw reply
* Re: New Version Control System to be used for some software development projects
From: Enrico Weigelt @ 2011-01-30 19:42 UTC (permalink / raw)
To: git
In-Reply-To: <20110129225515.GB7676@gmail.com>
* David Aguilar <davvid@gmail.com> wrote:
<snip>
For newcomers I'd suggest reading the paper
"git for computer scientists"
It explains the underlying concepts very well.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Enrico Weigelt @ 2011-01-30 19:36 UTC (permalink / raw)
To: git
In-Reply-To: <20110129232848.GC7676@gmail.com>
* David Aguilar <davvid@gmail.com> wrote:
Hi,
> This is exactly how we do it at my workplace. We have literally
> hundreds of individual git repositories. Naturally, some
> packages depend on others and the only "trick" is building them
> in the correct dependency order. A simple dependency tree
> handles this for us.
perhaps you'd like to have a look at my Briegel build tool:
git://pubgit.metux.de/projects/briegel.git
;-)
> We use same-named branches across several repos when coordinating
> features across many projects. e.g. we had an "el6" branch
> when we were gettings things ready for that platform. It's a
> convention but it helps when writing helper scripts.
Did you have these branches for all packages ?
> We can clone and work on any subset of the entire tree by
> cloning just the repos we are interested in. Setting
> $LD_LIBRARY_PATH and $PATH helps when testing builds in their
> sandboxes. You still need to get the compiler/linker to
> construct paths into the sandboxes instead of the standard
> release area.
I'd suggest pushing everything through a sysroot'ed crosscompiler
and only install the absolute required dependencies in the sysroot
on each package build. This tends to show up a lot of programming
errors that otherwise stay unnoticed for a long time.
(Briegel goes exactly that way and handles it automatically ;-p)
> This is what the pkg-config command does. It respects the
> $PKG_CONFIG_PATH environment variable which can be used to
> point to staged installs so that you don't have to deploy the
> package before building against it.
With sysroot, it's even a bit more cleaner, pkg-config can handle
the path fixups automatically then.
> The idea is so simple that you could write an equivalent command
> in an afternoon and extend it to work however you need in the
> event that pkg-config does not fit.
Actually, I only know of rare cases where pkg-config doesn't
really fit. Mostly due bad software design. Once thing I'm yet
missing is something pkg-config alike which replaces most of
the autofool-tests (eg. whether the target supports some
syscall, stack directions, etc).
> 2. the build must use the pkg-config command when constructing
> include/library paths.
Still there're lots of packages which dont use pkg-config.
Some of those I'm already fixing in my OSS-QM project.
(Everybody's invited to join in ;-))
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: Shawn Pearce @ 2011-01-30 19:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Johannes Sixt, git, John Hawley
In-Reply-To: <7vk4hmbyuo.fsf@alter.siamese.dyndns.org>
On Sun, Jan 30, 2011 at 00:05, Junio C Hamano <gitster@pobox.com> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
>> Using this for object enumeration shaves almost 1 minute off server
>> packing time; the clone dropped from 3m28s to 2m29s. That is close to
>> what I was getting with the cached pack idea, but the network transfer
>> stayed the small 376 MiB.
>
> I like this result.
I'm really leaning towards putting this cached object list into JGit.
I need to shave that 1 minute off server CPU time. I can afford the 41
MiB disk (and kernel buffer cache), but I cannot really continue to
pay the 1 minute of CPU on each clone request for large repositories.
The object list of what is reachable from commit X isn't ever going to
change, and the path hash function is reasonably stable. With a
version code in the file we can desupport old files if the path hash
function changes. 10% more disk/kernel memory is cheap for some of my
servers compared to 1 minute of CPU, and some explicit cache
management by the server administrator to construct the file.
> The amount of transfer being that small was something I didn't quite
> expect, though. Doesn't it indicate that our pathname based object
> clustering heuristics is not as effective as we hoped?
I'm not sure I follow your question.
I think the problem here is old side branches that got recently
merged. Their _best_ delta base was some old revision, possibly close
to where they branched off from. Using a newer version of the file
for the delta base created a much larger delta. E.g. consider a file
where in more recent revisions a function was completely rewritten.
If you have to delta compress against that new version, but you use
the older definition of the function, you need to use insert
instructions
for the entire content of that old function. But if you can delta
compress against the version you branched from (or one much closer to
it in time), your delta would be very small as that function is
handled by the smaller copy instruction.
Our clustering heuristics work fine.
Our thin-pack selection of potential delta base candidates is not. We
are not very aggressive in loading the delta base window with
potential candidates, which means we miss some really good compression
opportunities.
Ooooh.
I think my test was flawed. I injected the cached pack's tip as the
edge for the new stuff to delta compress against. I should have
injected all of the merge bases between the cached pack's tip and the
new stuff. Although the cached pack tip is one of the merge bases,
its not all of them. If we inject all of the merge bases, we can find
the revision that this old side branch is based on, and possibly get a
better delta candidate for it.
IIRC, upload-pack would have walked backwards further and found the
merge base for that side branch, and it would have been part of the
delta base candidates. I think I need to re-do my cached pack test.
Good thing I have history of my source code saved in this fancy
revision control thingy called "git". :-)
--
Shawn.
^ permalink raw reply
* [PATCH v4] Sanity-check config variable names
From: Libor Pechacek @ 2011-01-30 19:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <20110128145323.GE1849@fm.suse.cz>
Sanity-check config variable names when adding and retrieving them. As a side
effect code duplication between git_config_set_multivar and get_value (in
builtin/config.c) was removed and the common functionality was placed in
git_config_parse_key.
This breaks a test in t1300 which used invalid section-less keys in the tests
for "git -c". However, allowing such names there was useless, since there was
no way to set them via config file, and no part of git actually tried to use
section-less keys. This patch updates the test to use more realistic examples
as well as adding its own test.
Signed-off-by: Libor Pechacek <lpechacek@suse.cz>
Acked-by: Jeff King <peff@peff.net>
---
builtin/config.c | 22 ++++++++--
cache.h | 1 +
config.c | 104 ++++++++++++++++++++++++++++++------------------
t/t1300-repo-config.sh | 18 ++++++--
4 files changed, 97 insertions(+), 48 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index ca4a0db..dd17029 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -153,7 +153,6 @@ static int show_config(const char *key_, const char *value_, void *cb)
static int get_value(const char *key_, const char *regex_)
{
int ret = -1;
- char *tl;
char *global = NULL, *repo_config = NULL;
const char *system_wide = NULL, *local;
@@ -168,17 +167,30 @@ static int get_value(const char *key_, const char *regex_)
}
key = xstrdup(key_);
- for (tl=key+strlen(key)-1; tl >= key && *tl != '.'; --tl)
- *tl = tolower(*tl);
- for (tl=key; *tl && *tl != '.'; ++tl)
- *tl = tolower(*tl);
if (use_key_regexp) {
+ char *tl;
+
+ /*
+ * NEEDSWORK: this naive pattern lowercasing obviously does not
+ * work for more complex patterns like "^[^.]*Foo.*bar".
+ * Perhaps we should deprecate this altogether someday.
+ */
+ for (tl = key + strlen(key) - 1;
+ tl >= key && *tl != '.';
+ tl--)
+ *tl = tolower(*tl);
+ for (tl = key; *tl && *tl != '.'; tl++)
+ *tl = tolower(*tl);
+
key_regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, "Invalid key pattern: %s\n", key_);
goto free_strings;
}
+ } else {
+ if (git_config_parse_key(key_, &key, NULL))
+ goto free_strings;
}
if (regex_) {
diff --git a/cache.h b/cache.h
index d83d68c..1e32d63 100644
--- a/cache.h
+++ b/cache.h
@@ -997,6 +997,7 @@ extern int git_config_maybe_bool(const char *, const char *);
extern int git_config_string(const char **, const char *, const char *);
extern int git_config_pathname(const char **, const char *, const char *);
extern int git_config_set(const char *, const char *);
+extern int git_config_parse_key(const char *, char **, int *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
extern int git_config_rename_section(const char *, const char *);
extern const char *git_etc_gitconfig(void);
diff --git a/config.c b/config.c
index 625e051..fde91f5 100644
--- a/config.c
+++ b/config.c
@@ -1099,6 +1099,69 @@ int git_config_set(const char *key, const char *value)
}
/*
+ * Auxiliary function to sanity-check and split the key into the section
+ * identifier and variable name.
+ *
+ * Returns 0 on success, -1 when there is an invalid character in the key and
+ * -2 if there is no section name in the key.
+ *
+ * store_key - pointer to char* which will hold a copy of the key with
+ * lowercase section and variable name
+ * baselen - pointer to int which will hold the length of the
+ * section + subsection part, can be NULL
+ */
+int git_config_parse_key(const char *key, char **store_key, int *baselen_)
+{
+ int i, dot, baselen;
+ const char *last_dot = strrchr(key, '.');
+
+ /*
+ * Since "key" actually contains the section name and the real
+ * key name separated by a dot, we have to know where the dot is.
+ */
+
+ if (last_dot == NULL) {
+ error("key does not contain a section: %s", key);
+ return -2;
+ }
+
+ baselen = last_dot - key;
+ if (baselen_)
+ *baselen_ = baselen;
+
+ /*
+ * Validate the key and while at it, lower case it for matching.
+ */
+ *store_key = xmalloc(strlen(key) + 1);
+
+ dot = 0;
+ for (i = 0; key[i]; i++) {
+ unsigned char c = key[i];
+ if (c == '.')
+ dot = 1;
+ /* Leave the extended basename untouched.. */
+ if (!dot || i > baselen) {
+ if (!iskeychar(c) || (i == baselen+1 && !isalpha(c))) {
+ error("invalid key: %s", key);
+ goto out_free_ret_1;
+ }
+ c = tolower(c);
+ } else if (c == '\n') {
+ error("invalid key (newline): %s", key);
+ goto out_free_ret_1;
+ }
+ (*store_key)[i] = c;
+ }
+ (*store_key)[i] = 0;
+
+ return 0;
+
+out_free_ret_1:
+ free(*store_key);
+ return -1;
+}
+
+/*
* If value==NULL, unset in (remove from) config,
* if value_regex!=NULL, disregard key/value pairs where value does not match.
* if multi_replace==0, nothing, or only one matching key/value is replaced,
@@ -1124,59 +1187,22 @@ int git_config_set(const char *key, const char *value)
int git_config_set_multivar(const char *key, const char *value,
const char *value_regex, int multi_replace)
{
- int i, dot;
int fd = -1, in_fd;
int ret;
char *config_filename;
struct lock_file *lock = NULL;
- const char *last_dot = strrchr(key, '.');
if (config_exclusive_filename)
config_filename = xstrdup(config_exclusive_filename);
else
config_filename = git_pathdup("config");
- /*
- * Since "key" actually contains the section name and the real
- * key name separated by a dot, we have to know where the dot is.
- */
-
- if (last_dot == NULL) {
- error("key does not contain a section: %s", key);
- ret = 2;
+ ret = -git_config_parse_key(key, &store.key, &store.baselen);
+ if (ret)
goto out_free;
- }
- store.baselen = last_dot - key;
store.multi_replace = multi_replace;
- /*
- * Validate the key and while at it, lower case it for matching.
- */
- store.key = xmalloc(strlen(key) + 1);
- dot = 0;
- for (i = 0; key[i]; i++) {
- unsigned char c = key[i];
- if (c == '.')
- dot = 1;
- /* Leave the extended basename untouched.. */
- if (!dot || i > store.baselen) {
- if (!iskeychar(c) || (i == store.baselen+1 && !isalpha(c))) {
- error("invalid key: %s", key);
- free(store.key);
- ret = 1;
- goto out_free;
- }
- c = tolower(c);
- } else if (c == '\n') {
- error("invalid key (newline): %s", key);
- free(store.key);
- ret = 1;
- goto out_free;
- }
- store.key[i] = c;
- }
- store.key[i] = 0;
/*
* The lock serves a purpose in addition to locking: the new
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index d0e5546..c3d91d1 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -876,11 +876,21 @@ test_expect_success 'check split_cmdline return' "
"
test_expect_success 'git -c "key=value" support' '
- test "z$(git -c name=value config name)" = zvalue &&
test "z$(git -c core.name=value config core.name)" = zvalue &&
- test "z$(git -c CamelCase=value config camelcase)" = zvalue &&
- test "z$(git -c flag config --bool flag)" = ztrue &&
- test_must_fail git -c core.name=value config name
+ test "z$(git -c foo.CamelCase=value config foo.camelcase)" = zvalue &&
+ test "z$(git -c foo.flag config --bool foo.flag)" = ztrue &&
+ test_must_fail git -c name=value config core.name
+'
+
+test_expect_success 'key sanity-checking' '
+ test_must_fail git config foo=bar &&
+ test_must_fail git config foo=.bar &&
+ test_must_fail git config foo.ba=r &&
+ test_must_fail git config foo.1bar &&
+ test_must_fail git config foo."ba
+ z".bar &&
+ git config foo.bar true &&
+ git config foo."ba =z".bar false
'
test_done
--
1.7.4.rc3.10.gf91c9
^ permalink raw reply related
* Re: [RFC] Add --create-cache to repack
From: Shawn Pearce @ 2011-01-30 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Johannes Sixt, git, John Hawley
In-Reply-To: <7voc6yc2au.fsf@alter.siamese.dyndns.org>
On Sat, Jan 29, 2011 at 22:51, Junio C Hamano <gitster@pobox.com> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
>> I fully implemented the reuse of a cached pack behind a thin pack idea
>> I was trying to describe in this thread. It saved 1m7s off the JGit
>> running time, but increased the data transfer by 25 MiB. I didn't
>> expect this much of an increase, I honestly expected the thin pack
>> portion to be well, thinner. The issue is the thin pack cannot delta
>> against all of the history, its only delta compressing against the tip
>> of the cached pack. So long-lived side branches that forked off an
>> older part of the history aren't delta compressing well, or at all,
>> and that is significantly bloating the thin pack. (Its also why that
>> "newer" pack is 57M, but should be 14M if correctly combined with the
>> cached pack.) If I were to consider all of the objects in the cached
>> pack as potential delta base candidates for the thin pack, the entire
>> benefit of the cached pack disappears.
>
> What if you instead use the cached pack this way?
>
> 0. You perform the proposed pre-traversal until you hit the tip of cached
> pack(s), and realize that you will end up sending everything.
>
> 1. Instead of sending the new part of the history first and then sending
> the cached pack(s), you send the contents of cached pack(s), but also
> note what objects you sent;
This is the part I was trying to avoid. Making this list of objects
from the cached pack(s) costs working set inside of the pack-objects
process. I had hoped that the cached packs would let me skip this
step.
But lets say that's acceptable cost. We cannot efficiently make a
useful list of objects from the pack. Scanning the .idx file only
tells us the SHA-1. It does not tell us the type, nor does it tell us
what the path hash code would be for the object if it were a tree or
blob. So we cannot efficiently use this pack listing to construct the
delta window.
> 2. Then you send the new part of the history, taking full advantage of
> what you have already sent, perhaps doing only half of the reuse-delta
> logic (i.e. you reuse what you can reuse, but you do _not_ punt on an
> object that is not a delta in an existing pack).
Well, I guess we could go half-way. We could try to use only
non-delta objects from the cached pack as potential delta bases for
this delta search.
To do that we would build the reverse index for the cached pack, then
check each object's type code just before we send that part of the
cached pack. If its non-delta, we can get its SHA-1 from the reverse
index, toss the object into the delta search list, and copy out the
length of the object until the next object starts.
However... I suspect our delta results would be the same as the thin
pack before cached pack test I did earlier. The objects that are
non-delta in the cached pack are (in theory) approximately the objects
immediately reachable from the cached pack's tip. That was already
put into the delta window as the base candidates for the thin pack.
This may be a faster way to find that thin pack edge, but the data
transfer will still be sub-optimal because we cannot consider deltas
as bases.
--
Shawn.
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: A Large Angry SCM @ 2011-01-30 17:41 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Shawn Pearce, Johannes Sixt, git, John Hawley
In-Reply-To: <alpine.LFD.2.00.1101301208270.8580@xanadu.home>
On 01/30/2011 12:14 PM, Nicolas Pitre wrote:
> On Sat, 29 Jan 2011, Junio C Hamano wrote:
>
>> Shawn Pearce<spearce@spearce.org> writes:
>>
>>> I fully implemented the reuse of a cached pack behind a thin pack idea
>>> I was trying to describe in this thread. It saved 1m7s off the JGit
>>> running time, but increased the data transfer by 25 MiB. I didn't
>>> expect this much of an increase, I honestly expected the thin pack
>>> portion to be well, thinner. The issue is the thin pack cannot delta
>>> against all of the history, its only delta compressing against the tip
>>> of the cached pack. So long-lived side branches that forked off an
>>> older part of the history aren't delta compressing well, or at all,
>>> and that is significantly bloating the thin pack. (Its also why that
>>> "newer" pack is 57M, but should be 14M if correctly combined with the
>>> cached pack.) If I were to consider all of the objects in the cached
>>> pack as potential delta base candidates for the thin pack, the entire
>>> benefit of the cached pack disappears.
>>
>> What if you instead use the cached pack this way?
>>
>> 0. You perform the proposed pre-traversal until you hit the tip of cached
>> pack(s), and realize that you will end up sending everything.
>>
>> 1. Instead of sending the new part of the history first and then sending
>> the cached pack(s), you send the contents of cached pack(s), but also
>> note what objects you sent;
>>
>> 2. Then you send the new part of the history, taking full advantage of
>> what you have already sent, perhaps doing only half of the reuse-delta
>> logic (i.e. you reuse what you can reuse, but you do _not_ punt on an
>> object that is not a delta in an existing pack).
>
> The problem is to determine the best base object to delta against. If
> you end up listing all the already sent objects and perform delta
> attempts against them for the remaining non delta objects to find the
> best match then you might end up taking more CPU time than the current
> enumeration phase.
Why worry about best here? Just add the object (or one of the objects)
with the same path from the commit you found in step 0, above, to the
delta base search for each object to pack.
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: Nicolas Pitre @ 2011-01-30 17:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, Johannes Sixt, git, John Hawley
In-Reply-To: <7voc6yc2au.fsf@alter.siamese.dyndns.org>
On Sat, 29 Jan 2011, Junio C Hamano wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I fully implemented the reuse of a cached pack behind a thin pack idea
> > I was trying to describe in this thread. It saved 1m7s off the JGit
> > running time, but increased the data transfer by 25 MiB. I didn't
> > expect this much of an increase, I honestly expected the thin pack
> > portion to be well, thinner. The issue is the thin pack cannot delta
> > against all of the history, its only delta compressing against the tip
> > of the cached pack. So long-lived side branches that forked off an
> > older part of the history aren't delta compressing well, or at all,
> > and that is significantly bloating the thin pack. (Its also why that
> > "newer" pack is 57M, but should be 14M if correctly combined with the
> > cached pack.) If I were to consider all of the objects in the cached
> > pack as potential delta base candidates for the thin pack, the entire
> > benefit of the cached pack disappears.
>
> What if you instead use the cached pack this way?
>
> 0. You perform the proposed pre-traversal until you hit the tip of cached
> pack(s), and realize that you will end up sending everything.
>
> 1. Instead of sending the new part of the history first and then sending
> the cached pack(s), you send the contents of cached pack(s), but also
> note what objects you sent;
>
> 2. Then you send the new part of the history, taking full advantage of
> what you have already sent, perhaps doing only half of the reuse-delta
> logic (i.e. you reuse what you can reuse, but you do _not_ punt on an
> object that is not a delta in an existing pack).
The problem is to determine the best base object to delta against. If
you end up listing all the already sent objects and perform delta
attempts against them for the remaining non delta objects to find the
best match then you might end up taking more CPU time than the current
enumeration phase.
Nicolas
^ permalink raw reply
* Re: [PATCH] Handle rename of case only, for Windows
From: Tim Abell @ 2011-01-30 16:53 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4D44CB60.8000506@lsrfire.ath.cx>
> + struct stat src_st;
> + lstat(src, &src_st);
Shouldn't you check the return value of this call? OK, the source
probably always exists, but still. Oh, we actually know that because
that's the first lstat() call in this for loop. You can reuse its
result instead of calling the function again.
Thanks for your feedback, you are undoubtedly right about checking the return value, I hadn't though of that. Just out of interest I tried moving a file with git mv that i'd removed from the filesystem. Here's the result, so at least it's not dying horribly:
$ rm foo.txt
$ git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# deleted: foo.txt
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git mv foo.txt bar.txt
fatal: bad source, source=foo.txt, destination=bar.txt
--
What do I need to do from here to make my patch acceptable/useful to git's maintainers?
Thanks
Tim Abell
^ permalink raw reply
* Re: Remote branchs -- how can I check them out?
From: Jakub Narebski @ 2011-01-30 16:35 UTC (permalink / raw)
To: João Paulo Melo de Sampaio; +Cc: GIT Mailing List
In-Reply-To: <AANLkTin3Tfcf=WJHJdSA9TwhFXQfaMrnm5+YEWWjo=qj@mail.gmail.com>
João Paulo Melo de Sampaio <jpmelos@gmail.com> writes:
> Hello, people.
>
> When I just cloned git using
>
> git clone git://git.kernel.org/pub/scm/git/git.git
>
> and I type
>
> git branch
>
> it shows me I have only the 'master' branch in my local repository
>
> * master
>
> and when I type
>
> git branch -a
>
> it shows that there's all these branches remotely
>
> * master
> remotes/origin/HEAD -> origin/master
> remotes/origin/html
> remotes/origin/maint
> remotes/origin/man
> remotes/origin/master
> remotes/origin/next
> remotes/origin/pu
> remotes/origin/todo
>
> What do I have to do to be able to see what's in the 'maint', 'next'
> and 'todo' branches, for example?
Those are so called "remote-tracking branches", i.e. refs which follow
branches in some remote repository. For example 'remotes/origin/master'
follows branch 'master' in remote 'origin'. By follow I mean here that
on "git fetch" (also "git pull" and "git remote update") these
remote-tracking branches would get updated to their value at remote.
Now if you only want to check wah's in given branch (beside using
"git show <branch>", "git ls-tree <branch>", "git show <branch>:<file>")
you can use e.g.
$ git checkout origin/next
to check out _state_ of remotr-tracking branch origin/next, landing
in so called "detached HEAD" state, or unnamed branch (no branch).
If you want to do some work based on given branch, you should create
new local branch based on remote-tracking one, e.g. via
$ git checkout -b --track next origin/next
IIRC nowadays doiung simply
$ git checkout -t next
should DWIM to do the same.
> And by the way, what are those branches all about? Their names
> suggests they are maintenance branches (where you keep backward
> compatibility with an older version?), the next version of git (1.7.4
> version?) and future features under implementation (the to-do list?).
It is described in "Notes from maintainer" which you can find in git
mailing list archives, in 'todo' branch of git repository, and on Git
Wiki.
* 'master' - stable development, new major version is cut from it
* 'next' - development branch, not everything that makes it here
would be in next version. Rewound on new major version.
* 'maint' - maintenance branch for last version, minor revisions are
cut from this; only bugfixes, no new development
* 'pu' - proposed updates, merge of interesting topic branches,
very unstable, used to review proposed features
* 'todo' - not wery well maintained TODO list, som scripts used e.g.
to send "What's cooking..." emails to git mailing list
* 'html', 'man' - compiled documentation
todo, html and man are detached branches.
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Remote branchs -- how can I check them out?
From: Konstantin Khomoutov @ 2011-01-30 16:05 UTC (permalink / raw)
To: João Paulo Melo de Sampaio; +Cc: GIT Mailing List
In-Reply-To: <AANLkTin3Tfcf=WJHJdSA9TwhFXQfaMrnm5+YEWWjo=qj@mail.gmail.com>
On Sun, Jan 30, 2011 at 01:05:07PM -0200, João Paulo Melo de Sampaio wrote:
> When I just cloned git using
>
> git clone git://git.kernel.org/pub/scm/git/git.git
>
> and I type
>
> git branch
>
> it shows me I have only the 'master' branch in my local repository
>
> * master
>
> and when I type
>
> git branch -a
>
> it shows that there's all these branches remotely
>
> * master
> remotes/origin/HEAD -> origin/master
> remotes/origin/html
> remotes/origin/maint
> remotes/origin/man
> remotes/origin/master
> remotes/origin/next
> remotes/origin/pu
> remotes/origin/todo
>
> What do I have to do to be able to see what's in the 'maint', 'next'
> and 'todo' branches, for example?
These branches are local to your repository. They are "remote" in the
sense you're not supposed to modify them directly.
So to inspect such a branch just use its full name ("origin/next" for
instance) when working with commands like git-log.
See [1], [2] for more info.
Also your question appears to be quite basic which hints at that you did
not read a good book on Git before using it. So starting at [3] is
recommended -- it mentions a bunch of good books and manuals (some of
which are available freely).
1. http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#examining-remote-branches
2. http://progit.org/book/ch3-5.html
3. http://git-scm.com/documentation
^ permalink raw reply
* Re: Status of dumb http transport?
From: Jakub Narebski @ 2011-01-30 16:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <AANLkTik99NNjNwLbj3-xEvVqiYUENiaREYAeJUC0bwVY@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> What is the state of dumb http transport today, for fetching updates?
> Is the client code smart enough to fetch indexes and use range
> requests? If so, how does that fare for latency?
A good description of "dumb" http transport can be found in Pro Git
book, in chapter 9.6 "Transfer Protocols", section "The Dumb Protocol"
http://progit.org/book/ch9-6.html
In short "dumb" http transport is realy dumb, it consults
.git/info/refs to know where to start from, and
.git/objects/info/packs to know what packfiles are available (both are
generated by git-update-server-info, usually run from update hook).
Starting from appropriate object, it tries to download loose object,
if posible, and if not then it downloads index files to know which
packfile to download. It walks the chain down checking which objects
it has, and if there is one missing it downloads it. It always
downloads _whole_ pack files. It doesn't use range request... what's
more, as far as I know it doesn't know how to resume partially
downloaded packfile (hough it wouldn't re-download packfile it already
got).
> Background: I am looking at whether yum repositories' data (currently
> in sqlite & xml) could benefit from being a git (or very gittish)
> database -- with a bit of re-organizing to make it git-efficient of
> course.
>
> Not the data that would benefit, but rather, users pulling updates
> from fast-moving repos (updates, updates-testing, rawhide...).
>
> One of the constraints is that this has to be http, and work well
> across a universe of mirrors (that won't install or configure
> software) and the good bad and ugly world of http proxies. Yum can be
> taught to use the git proto, but that won't gain widespread use
> quickly -- http is and will be the mainstay for a long time.
Note that from some time we have "smart" http protocol, which is
almost git protocol proxied over http... with addition that http
protocol is stateless. Default git-http-backend CGI script falls back
to "dumb" protocol if client doesn't support smart http transport.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Status of dumb http transport?
From: Martin Langhoff @ 2011-01-30 15:07 UTC (permalink / raw)
To: Git Mailing List
Hi List!
What is the state of dumb http transport today, for fetching updates?
Is the client code smart enough to fetch indexes and use range
requests? If so, how does that fare for latency?
Background: I am looking at whether yum repositories' data (currently
in sqlite & xml) could benefit from being a git (or very gittish)
database -- with a bit of re-organizing to make it git-efficient of
course.
Not the data that would benefit, but rather, users pulling updates
from fast-moving repos (updates, updates-testing, rawhide...).
One of the constraints is that this has to be http, and work well
across a universe of mirrors (that won't install or configure
software) and the good bad and ugly world of http proxies. Yum can be
taught to use the git proto, but that won't gain widespread use
quickly -- http is and will be the mainstay for a long time.
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox