* Re: [RFC PATCH 6/8] Remove special casing of http, https and ftp
From: Daniel Barkalow @ 2009-12-01 19:15 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1259675838-14692-7-git-send-email-ilari.liusvaara@elisanet.fi>
On Tue, 1 Dec 2009, Ilari Liusvaara wrote:
> HTTP, HTTPS and FTP are no longer special to transport code. Also
> add support for FTPS (curl supports it so it is easy).
We've been through this extensively, and settled on having a special case
for URLs that specify a pure location. That is, the distinction between
http and ftp is at the level of how you get to the content for that
location, not what you do to interact with it. (Even with webdav or the
git-specific smart server support, we use the same detection method on all
locations, and ftp simply never has the possibility of having these
features detected.)
It would be fine to add "ftps" to the list of URL schemes that indicate a
pure location, except that it's plausible that ftps supports writing, but
obviously not by webdav, which is what the push support via curl will
attempt, so it's more likely to be confusing than helpful.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] get_ref_states: strdup entries and free util in stale list
From: Junio C Hamano @ 2009-12-01 19:20 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Junio C Hamano, Johannes Schindelin, Jay Soffian, git
In-Reply-To: <36ca99e90912011014sd7372d0yc234873a26c2ae43@mail.gmail.com>
Bert Wesarg <bert.wesarg@googlemail.com> writes:
> A quick test with my use case does not show errors in the maint
> branch. So it should not be needed (except the memory leak fix of the
> .util member). And valgrind confirms this.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 4/8] Support remote helpers implementing smart transports
From: Shawn O. Pearce @ 2009-12-01 19:22 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1259675838-14692-5-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> index 5cfdc0c..adf815c 100644
> --- a/Documentation/git-remote-helpers.txt
> +++ b/Documentation/git-remote-helpers.txt
> @@ -90,6 +90,28 @@ Supported if the helper has the "push" capability.
> +
> Supported if the helper has the "import" capability.
>
> +'connect-r' <service>::
> + Connects to given service. Stdin and stdout of helper are
> + connected to specified service (no git or git- prefixes are used,
> + so e.g. fetching uses 'upload-pack' as service) on remote side.
This flies against every other convention we have. git:// uses the
string 'git-upload-pack' and 'git-receive-pack', and so does the
smart-http code. We should continue to use the git- prefix here,
to be consistent, even though by context its clearly implied.
> + Valid replies to this command are 'OK' (connection established),
Why 'OK'? Currently remote-helpers return an empty blank line
to any successful command, not 'OK'.
> + 'FALLBACK' (no smart transport support, fall back to dumb
> + transports) and 'ERROR' (can't connect, don't bother trying to
> + fall back).
FALLBACK almost makes sense, but ERROR we don't do in the
the existing helper protocol. Instead the helper simply
prints its error message(s) to stderr and does exit(128).
aka what die() does.
> +Supported if the helper has the "connect-r" capability. Not used if
> +helper has the "invoke-r" capability, as invoke is preferred to connect.
> +
> +'invoke-r' <cmdlength> <cmd>::
> + Like connect-r command, but instead of service name, command
> + line is given. The length of command field is given in command
> + length field.
> ++
> +Supported if the helper has the "invoke-r" capability.
Why both connect-r and invoke-r? Why isn't connect-r sufficient
here? Isn't it sufficient for any service that runs over git:// ?
--
Shawn.
^ permalink raw reply
* [PATCH] help: Do not unnecessarily look for a repository
From: David Aguilar @ 2009-12-01 19:27 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
Although 'git help' actually doesn't need to be run inside a git
repository and uses no repository-specific information, it looks for a git
directory. Searching for a git directory can be annoying in auto-mount
environments. With this commit, 'git help' no longer searches for a
repository when run without any options.
7c3baa9 originally modified 'git help -a' to not require a repository.
This applies the same fix for 'git help'.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
builtin-help.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-help.c b/builtin-help.c
index ca08519..09ad4b0 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -427,9 +427,6 @@ int cmd_help(int argc, const char **argv, const char *prefix)
return 0;
}
- setup_git_directory_gently(&nongit);
- git_config(git_help_config, NULL);
-
if (!argv[0]) {
printf("usage: %s\n\n", git_usage_string);
list_common_cmds_help();
@@ -437,6 +434,9 @@ int cmd_help(int argc, const char **argv, const char *prefix)
return 0;
}
+ setup_git_directory_gently(&nongit);
+ git_config(git_help_config, NULL);
+
alias = alias_lookup(argv[0]);
if (alias && !is_git_command(argv[0])) {
printf("`git %s' is aliased to `%s'\n", argv[0], alias);
--
1.6.5.3
^ permalink raw reply related
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Shawn O. Pearce @ 2009-12-01 19:30 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Sverre Rabbelier, git
In-Reply-To: <20091201171908.GA15436@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> On Tue, Dec 01, 2009 at 08:52:45AM -0800, Shawn O. Pearce wrote:
>
> > Or better, why this is even necessary?
>
> I have seen requests for gits:// (and in fact, I have plans to
> implement that protocol).
>
> For instance, to support new types of authentication for smart transports
> without patching client git binaries (SSH has lots of failure modes that
> are quite nasty to debug) or abusing GIT_PROXY (yuck).
So the bulk of this series is about making a proxy for git://
easier to tie into git?
Forgive me if I sound stupid, but for gits:// shouldn't that just
be a matter of git_connect() forking a git-remote-gits process
linked against openssl? Or, maybe it just runs `openssl s_client`?
Why go through all of this effort of making a really generic proxy
protocol system when the long-term plan is to just ship native
gits:// support as part of git-core?
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH 6/8] Remove special casing of http, https and ftp
From: Ilari Liusvaara @ 2009-12-01 19:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091201182414.GK21299@spearce.org>
On Tue, Dec 01, 2009 at 10:24:14AM -0800, Shawn O. Pearce wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>
> These should all be hardlinks to a single executable, not duplicate
> relinks of the same object files.
Fixed for next round (probably send that out in few days).
-Ilari
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Junio C Hamano @ 2009-12-01 20:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ilari Liusvaara, Sverre Rabbelier, git
In-Reply-To: <20091201193009.GM21299@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>>
>> For instance, to support new types of authentication for smart transports
>> without patching client git binaries (SSH has lots of failure modes that
>> are quite nasty to debug) or abusing GIT_PROXY (yuck).
>
> So the bulk of this series is about making a proxy for git://
> easier to tie into git?
>
> Forgive me if I sound stupid, but for gits:// shouldn't that just
> be a matter of git_connect() forking a git-remote-gits process
> linked against openssl? Or, maybe it just runs `openssl s_client`?
>
> Why go through all of this effort of making a really generic proxy
> protocol system when the long-term plan is to just ship native
> gits:// support as part of git-core?
I didn't know what the long-term plan was to be honest, but after skimming
the series, I think your response is a good summary.
It is somewhat unfortunate that a few changes I liked (e.g. the "debug"
bit), even though it was somewhat painful to read them due to coding style
differences, were not at the beginning of the series but instead buried
after changes that are much bigger and controversial (e.g. [6/8]).
^ permalink raw reply
* Re: "git merge" merges too much!
From: Dmitry Potapov @ 2009-12-01 20:50 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NFXpl-000knKC@most.weird.com>
On Tue, Dec 01, 2009 at 01:52:18PM -0500, Greg A. Woods wrote:
> At Mon, 30 Nov 2009 22:22:12 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
> Subject: Re: "git merge" merges too much!
> >
> > The key difference comparing to what you may got used is that branches
> > are normally based on the oldest branch in what this feature may be
> > included. Thus normally changes are not backported to old branches,
> > because you can merge them directly.
>
> Hmmm... the idea of creating topic branches based on the oldest branch
> where the feature might be used is indeed neither intuitive, nor is it
> mentioned anywhere I've so far read about using topic branches in Git.
Most things that we consider "intuitive" are those that we got used to.
Git is different in many aspect than other VCSes (such as CVS/SVN), and
the workflow that good for those VCSes may not be optimal for Git. There
is a good description that provide basic knowledge how to use Git:
man gitworkflows
or online:
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
If you do not base your changes on the oldest branch then you will not
be able to merge changes, which implies you will have to cherry-pick
manually without ability automatic to track what changes were merged
and what were not, this is a recipe for a disaster...
> At the moment I'm leaning towards a process where the configuration
> branch is re-created for every build -- i.e. the merges are redone from
> every topic branch to a freshly configured branch forked from the
> locally supported release branch, hopefully making use of git-rerere to
> solve most conflicts in as automated a fashion as is possible.
I am not quite sure that I fully understood your idea of configuration
branches, but I want to warn you about one serious limitations of
git-rerere -- it stores conflict resolution per-file basis. This means
that if resolution of some conflict implies some change to another file
then git-rerere will not help you here. So, it handles maybe 80-90%
cases, but not all of them.
>
> Perhaps Stacked-Git really is the best answer. I will have to
> investigate more.
There is also TopGit. I have never used any of them, but if you are
interested in patch management system, you probably should look at both
of them. StGit is modelled after quilt, while TopGit is aimed to be
better integrated with Git and better fit to work in distributed
environment. But as I said, I do not have any first hand experience
with any of them. (Personally, I would look at TopGit first, but maybe
I am biased here).
> >
> > $ git branch new-foo foo
> >
> > $ git rebase --onto newbase oldbase new-foo
>
> Hmmm.... I'll have to think about that. It makes some sense, but I
> don't intuitively read the command-line parameters well enough to
> predict the outcome in all of the scenarios I'm interested in.
>
> what is "oldbase" there? I'm guessing it means "base of foo" (and for
> the moment, "new-foo" too)?
You have:
o---o---o---o---o newbase
\
o---o---o---o---o oldbase
\
o---o---o foo
and you want this:
o---o---o---o---o newbase
| \
| o´--o´--o´ new-foo
\
o---o---o---o---o oldbase
\
o---o---o foo
Dmitry
^ permalink raw reply
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Dmitry Potapov @ 2009-12-01 21:18 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NFXvL-000kn2C@most.weird.com>
On Tue, Dec 01, 2009 at 01:58:05PM -0500, Greg A. Woods wrote:
>
> > > I just disagreed that "git archive" was a reasonable alternative to
> > > leaving the working directory alone during the entire time of the build.
> >
> > Using "git archive" allows you avoid running long time procedure such as
> > full clean build and testing in the working tree. Also, it is guaranteed
> > that you test exactly what you put in Git and some other garbage in your
> > working tree does not affect the result.
>
> Sure, but let's be very clear here: "git archive" is likely even more
> impossible for some large projects to use than "git clone" would be to
> use to create build directories.
AFAIK, "git archive" is cheaper than git clone. I do not say it is fast
for huge project, but if you want to run a process such as clean build
and test that takes a long time anyway, it does not add much to the
total time.
>
> Disk bandwidth is almost always more expensive than disk space.
Disk bandwidth is certainly more expensive than disk space, and the
whole point was to avoid a lot of disk bandwidth by using hot cache.
If you have two working tree then it is likely that only one will be
in the hot cache, that is why you can switch faster (and to recompile
a few files) than going to another working tree. It has never been
about disk space, it is about disk cache and keeping it hot.
>
> Multiple working directories are really the only sane solution
> sometimes.
Sure, sometimes... I do not know details to say what will be better in
your case, but I just wanted to say that you should weight that against
switching, because switching in Git is very fast. Much faster than with
any other VCS...
Another thing to consider is that if you put a really huge project in one
Git repo than Git may not be as fast as you may want, because Git tracks
the whole project as the whole. So, you may want to split your project in
a few relatively independent modules (See git submodule).
Dmitry
^ permalink raw reply
* Re: "git merge" merges too much!
From: Greg A. Woods @ 2009-12-01 21:58 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <20091201205057.GD11235@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 5801 bytes --]
At Tue, 1 Dec 2009 23:50:57 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!
>
> > >
> > > $ git branch new-foo foo
> > >
> > > $ git rebase --onto newbase oldbase new-foo
> >
> > Hmmm.... I'll have to think about that. It makes some sense, but I
> > don't intuitively read the command-line parameters well enough to
> > predict the outcome in all of the scenarios I'm interested in.
> >
> > what is "oldbase" there? I'm guessing it means "base of foo" (and for
> > the moment, "new-foo" too)?
>
> You have:
>
> o---o---o---o---o newbase
> \
> o---o---o---o---o oldbase
> \
> o---o---o foo
Yes, sort of -- in the ideal situation, but not in my particular example
where "oldbase" is just a tag, not a real branch.
So yes, "oldbase" is in fact "base of foo". Trickier still is when the
"oldbase" branch has one or more commits newer then "base of foo". Does
Git not have a symbolic name for the true base of a branch? I.e. is
there not some form of symbolic name for "N" in the following?
o---o---o---o---o---o---o---o master
\
o---o---N---o---o release-1
\
o---o---o local-release-1
(now of course if it is discovered that "release-1" has progressed since
the base of "foo" then "foo" should be rebased first, but perhaps there
is not time to do this before the other release has to be supported)
> and you want this:
>
> o---o---o---o---o newbase
> | \
> | o'--o'--o' new-foo
> \
> o---o---o---o---o oldbase
> \
> o---o---o foo
Yes, sort of I suppose, if you trim all the non-relevant branches.
What I really want, I think, is something like this where at least the
non-relevant "master" branch is still shown:
1'--2'--3' new-foo
/
o---o---o newbase
/
o---o---o---o---o---o---o---o master
\
o---o---o oldbase
\
1---2---3 foo
Here's part of my confusion -- "newbase" as used above is actually older
than "oldbase". :-) so ideally "oldbase" should always be described in
terms of "foo", not just given an arbitrary unrelated name.
Of course that doesn't rule out the following scenario either where
"newbase" really is newer than "oldbase" -- in my world a given project
might become locally supported first on either a newer release, or an
older release, so both above and below might happen:
1'--2'--3' new-foo
/
o---o---o newbase
/
o---o---o---o---o---o---o---o master
\
o---o---o oldbase
\
1---2---3 foo
And eventually I want to also merge whatever is still relevant from foo
to a "local" branch off master so that those changes can be sent
(usually as patches) upstream.
Sometimes I want to do development on a topic branch as close to the tip
of "master" so that it can most easily be pushed upstream, and then
back-port those changes to older release branches.
In fact the latter is exactly how I picture release branches to work in
normal development, and this is how several of the big projects I'd like
to get using Git are doing development (now usually with CVS).
Note too that in these kinds of projects "topic" branches are _always_
forked from the current tip of "master", long-running ones sometimes
rebased to keep up with "master", small fixes and changes are made
directly to the master branch; and small fixes, as well as relevant
features, sometimes those developed on "topic" branches, are back-ported
to release branches.
Note I'm not talking about ideals of best practises specific for Git
here -- I'm talking about actual working operational practises that
people are _very_ familiar with and which have been well proven using a
vast wide variety of different VCS's in the past. For example I
seriously doubt any of the developers of the projects I'm thinking of
that I'd like to switch to using Git are ever going to want to fork
their topic branches from the oldest release branch base that they
intend to support, and many such projects will necessarily always have
at least a few long-running topic branches that will have to be
frequently rebased to keep up with the trunk so that their eventual
merging will go as smoothly as possible, and yet once any of these topic
branches is finally "closed" their changes may also have to be
back-ported to release branches.
To me the natural way to do these kinds of back-porting "merges" is to
restrict the merge to select only the commits on the branch, i.e. from
its base to its tip, thus the motivation for the topic of my thread (and
I think the motivation for the "What is the best way to backport a
feature?" thread as well). I think if Git could do this kind of
"partial" merging directly without having to "copy" deltas with "rebase"
or "cherry-pick" or "am" or whatever, and thus create separate histories
for them, then it would be much better at supporting this traditional
practice of using branches to manage releases. Without such ability it
truly does look as though some form of "patch" management tool is also a
necessary thing(evil?), as "rebase" and "cherry-pick" could quickly get
way out of control and be way too much work otherwise.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* What's cooking in git.git (Dec 2009, #01; Tue, 01)
From: Junio C Hamano @ 2009-12-01 22:10 UTC (permalink / raw)
To: git
I am this close to actually tagging 1.6.6-rc1, but I am reasonably sure
that I missed and did not pick up a few important fixes that should go
into it, so here is the current status.
What's cooking in git.git (Dec 2009, #01; Tue, 01)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planned changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* "git send-email" won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* "git status" won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
* "git diff -w/-b" won't even produce "diff --git" header when all changes
are about whitespaces.
http://thread.gmane.org/gmane.comp.version-control.git/133256
--------------------------------------------------
[Graduated to "master"]
* fc/maint-format-patch-pathspec-dashes (2009-11-26) 2 commits.
+ format-patch: add test for parsing of "--"
+ format-patch: fix parsing of "--" on the command line
* bw/diff-color-hunk-header (2009-11-27) 2 commits
(merged to 'next' on 2009-11-29 at c446977)
+ Give the hunk comment its own color
(merged to 'next' on 2009-11-27 at 42ab131)
+ emit_line(): don't emit an empty <SET><RESET> followed by a newline
* jc/maint-am-keep (2009-11-27) 1 commit.
(merged to 'next' on 2009-11-27 at 7663874)
+ Remove dead code from "git am"
* ns/send-email-no-chain-reply-to (2009-11-29) 1 commit
+ prepare send-email for smoother change of --chain-reply-to default
(this branch is used by ns/1.7.0-send-email-no-chain-reply-to.)
This starts warning about the change to --no-chain-reply-to
in 1.7.0 for smoother transition.
* uk/maint-shortlog-encoding (2009-11-25) 1 commit.
- shortlog: respect commit encoding
* fc/send-email-envelope (2009-11-26) 2 commits.
(merged to 'next' on 2009-11-27 at 2d0257d)
+ send-email: automatic envelope sender
+ t9001: test --envelope-sender option of send-email
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
(merged to 'next' on 2009-11-25 at 09d498f)
+ mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Jim Meyering sent a patch to do a subset of what this does; to allow
keeping '[SECURITY]' when the subject says '[SECURITY][PATCH]', you need
to also teach "am" to pass the new -b option, but that is independent of
what Jim showed the need in real-world, so I think this can go in as-is.
* jn/gitweb-blame (2009-11-24) 8 commits.
(merged to 'next' on 2009-11-25 at 0a5b649)
+ gitweb.js: fix padLeftStr() and its usage
+ gitweb.js: Harden setting blamed commit info in incremental blame
+ gitweb.js: fix null object exception in initials calculation
+ gitweb: Minify gitweb.js if JSMIN is defined
+ gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
With two more changes to disable this by default to make it
suitable as "new feature with known breakages" for 1.6.6
* em/commit-claim (2009-11-04) 1 commit
(merged to 'next' on 2009-11-23 at b5df6fd)
+ commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
* cc/bisect-doc (2009-11-08) 1 commit
(merged to 'next' on 2009-11-27 at c46d648)
+ Documentation: add "Fighting regressions with git bisect" article
* jc/pretty-lf (2009-10-04) 1 commit.
(merged to 'next' on 2009-11-27 at 73651c4)
+ Pretty-format: %[+-]x to tweak inter-item newlines
--------------------------------------------------
[New Topics]
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix but otherwise seemed good.
* mo/bin-wrappers (2009-11-29) 3 commits
- INSTALL: document a simpler way to run uninstalled builds
- run test suite without dashed git-commands in PATH
- build dashless "bin-wrappers" directory similar to installed bindir
--------------------------------------------------
[Stalled]
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
* jn/rfc-pull-rebase-error-message (2009-11-12) 1 commit
- git-pull.sh --rebase: overhaul error handling when no candidates are found
I heard this needs at least retitling among other changes?
* jh/notes (2009-11-20) 10 commits
- Add more testcases to test fast-import of notes
- Rename t9301 to t9350, to make room for more fast-import tests
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
Johan waits for an Ack from Shawn on "fast-import" one.
* tr/maint-merge-ours-clarification (2009-11-15) 1 commit
(merged to 'next' on 2009-11-21 at fadaf7b)
+ rebase: refuse to rebase with -s ours
I do not think we reached a concensus for solving conflicts between "give
them rope" and "protect users from clearly meaningless combinations". The
author obviously is for the latter (and I am inclined to agree); Dscho
seems to think otherwise.
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong. Sigh. We won't have a
proper fix in 1.6.6.
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Sverre is working on a re-roll to address comments from Shawn.
--------------------------------------------------
[Cooking]
* tr/http-updates (2009-11-27) 2 commits
- Add an option for using any HTTP authentication scheme, not only basic
- http: maintain curl sessions
It seems that this is still under discussion...
* jc/diff-whitespace-prepare (2009-11-28) 2 commits
- diff: flip the default diff.bwoutputonly to true
- diff: optionally allow traditional "-b/-w affects only output" semantics
(this branch uses gb/1.7.0-diff-whitespace-only-output and jc/1.7.0-diff-whitespace-only-status; is used by jc/1.7.0-diff-whitespace-prepare.)
This is to redo the two -b/-w semantic changes to prepare the migration of
existing users before 1.7.0 happens.
* sr/vcs-helper (2009-11-18) 12 commits
(merged to 'next' on 2009-11-27 at 83268ab)
+ Add Python support library for remote helpers
+ Basic build infrastructure for Python scripts
+ Allow helpers to report in "list" command that the ref is unchanged
+ Fix various memory leaks in transport-helper.c
+ Allow helper to map private ref names into normal names
+ Add support for "import" helper command
+ Allow specifying the remote helper in the url
+ Add a config option for remotes to specify a foreign vcs
+ Allow fetch to modify refs
+ Use a function to determine whether a remote is valid
+ Allow programs to not depend on remotes having urls
+ Fix memory leak in helper method for disconnect
Should be among the first to graduate after 1.6.6 final.
* jc/grep-full-tree (2009-11-24) 1 commit.
- grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
* jc/checkout-merge-base (2009-11-20) 2 commits
- "rebase --onto A...B" replays history on the merge base between A and B
- "checkout A...B" switches to the merge base between A and B
I've been using the first one for a while myself but do not see many users
want this (yet); the new feature is not urgent anyway.
* tr/reset-checkout-patch (2009-11-19) 1 commit.
(merged to 'next' on 2009-11-22 at b224950)
+ {checkout,reset} -p: make patch direction configurable
I do not particularly like a configuration like this that changes the
behaviour of a command in a drastic way---it will make helping others
much harder.
* nd/sparse (2009-11-25) 20 commits.
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
There were some test glitches reported and at least one test seems to
be broken in the sense that it is not testing what it is trying to.
Fix-up expected.
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-11-27) 7 commits.
(merged to 'next' on 2009-11-27 at 91691ec)
+ t7508-status.sh: Add tests for status -s
+ status -s: respect the status.relativePaths option
(merged to 'next' on 2009-11-21 at 884bb56)
+ docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
Immediately after 1.6.6 while rebuilding 'next', we may want to reorder a
few commits at the tip, as "docs: affects only long format" describes a
limitation that will disappear soon.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
As the title says.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change,
and jc/diff-whitespace-prepare topic is meant to ease the transition.
* gb/1.7.0-diff-whitespace-only-output (2009-11-19) 1 commit
(merged to 'next' on 2009-11-21 at 3375bf4)
+ No diff -b/-w output for all-whitespace changes
(this branch is used by jc/1.7.0-diff-whitespace-prepare and jc/diff-whitespace-prepare.)
Likewise but for the output of "diff --git" headers.
* jc/1.7.0-diff-whitespace-prepare (2009-11-28) 2 commits
- diff: disable diff.bwoutputonly warning
- diff: flip the diff.bwoutputonly default to false
(this branch uses gb/1.7.0-diff-whitespace-only-output, jc/1.7.0-diff-whitespace-only-status and jc/diff-whitespace-prepare.)
And this is to actually flip the default and eventually remove the warning.
* ns/1.7.0-send-email-no-chain-reply-to (2009-08-22) 1 commit
- send-email: make --no-chain-reply-to the default
And this is to actually flip the default in 1.7.0.
--------------------------------------------------
[Reverted from 'next']
* jc/botched-maint-cygwin-count-objects (2009-11-24) 2 commits
(merged to 'next' on 2009-11-25 at 8aa62a0)
+ Revert "ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)"
(merged to 'next' on 2009-11-22 at 4ba5880)
+ ST_BLOCKS_COUNTS_IN_BLKSIZE to say on-disk size is (st_blksize * st_blocks)
This is a revert of the tip one I merged prematurely to 'next'. The real
fix from Ramsay is already in 'master'.
* ks/precompute-completion (2009-11-15) 4 commits.
(merged to 'next' on 2009-11-15 at 23cdb96)
+ Revert ks/precompute-completion series
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
Reverted out of 'next', to be replaced with jn/faster-completion-startup
topic.
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
. git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. It appears nobody wants to have this, so I dropped it.
* ne/rev-cache (2009-10-19) 7 commits.
. support for commit grafts, slight change to general mechanism
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
The author indicated that there is another round coming. Does not seem to
pass the tests when merged to 'pu', so it has been ejected for now.
* pb/gitweb-no-project-list (2009-11-06) 3 commits.
. gitweb: Polish the content tags support
. gitweb: Support for no project list on gitweb front page
. gitweb: Refactor project list routines
I picked these up but didn't queue as Warthog9's comments made certain
amount of sense to me.
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Robin Rosenberg @ 2009-12-01 22:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Sixt, Thomas Singer, git
In-Reply-To: <20091201162627.GE21299@spearce.org>
tisdag 01 december 2009 17:26:27 skrev du:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
> > Thomas Singer schrieb:
> > > To be more precise: Who is interpreting the bytes in the file names as
> > > characters? Windows, Git or Java?
> >
> > In the case of git: Windows does it, using the console's codepage to
> > convert between bytes and Unicode.
> >
> > I don't know about Java, but I guess that no conversion is necessary
> > because Java is Unicode-aware.
>
> Actually, conversion is necessary, and its something that is proving
> to be really painful within JGit.
>
> The Java IO APIs use UTF-16 for file names. However we are reading
> a stream of unknown bytes from the index file and tree objects.
> Thus JGit must convert a stream of bytes into UTF-16 just to get
> to the OS.
>
> The JVM then turns around and converts from UTF-16 to some other
> encoding for the filesystem.
>
> On Win32 I suspect the JVM uses the native UTF-16 file APIs, so
> this translation is lossless.
>
> On POSIX, I suspect the JVM uses $LANG or some other related
> environment variable to guess the user's preferred encoding, and
> then converts from UTF-16 to bytes in that encoding. And I have
> no idea how they handle normalization of composed code points.
>
> All of these layers make for a *very* confusing situation for us
> within JGit:
>
> git tree
> +---------+
>
> | bytes | -+
>
> +---------+ \
> \ +--------+ +---------+
> +-- JGit --> | UTF-16 | -- JVM --> | OS call |
> .git/index / +--------+ +---------+
> +---------+ /
>
> | bytes | -+
>
> +---------+
>
> Its impossible for us to do what C git does, which is just use the
> bytes used by the OS call within the git datastructure. Which of
> course also isn't always portable, e.g. the Mac OS X HFS+ mess.
We can decode the index anyway we like but not file names coming from
the file system. On Windows, any sane name (it does allow invalid UTF-16 too,
but...) will be readable by JGit, but on a UTF-8 posix that may not be so, if
the filename is actually Latin.-1 encoded. In that case the Java runtime will
return a decoded filename containing an "invalid" code point and any attempt to
access the file from java will fail. I can see some horribly expensive ways to
work around that but...
As for the more sane cases I have a compare routine that works on mixed
encodings that may help to solve some of the problems. Ideally it would not
only be able to compare filenames with unknown encodings to handling case
folding and composing characters in one go too. I guess one could make it
fall back to another encoding than Latin-1, but with lesser certainty, but
it will not (for sure) work with any arbitrary set of encodings. You'll have
to choose, so it's only a legacy workaround, as opposed to a solution.
-- robin
^ permalink raw reply
* [PATCH] Documentation: commit: explain the non-meaning of S-o-b
From: Jan Krüger @ 2009-12-01 22:25 UTC (permalink / raw)
To: Git ML
In the manpage for git commit, the option --signoff is mentioned but
there is no explanation of what it actually means. Add a brief hint that
S-o-b doesn't have a pre-defined meaning.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
Documentation/git-commit.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index d227cec..cae510b 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -100,7 +100,8 @@ OPTIONS
-s::
--signoff::
Add Signed-off-by line by the committer at the end of the commit
- log message.
+ log message. This line has no inherent meaning; what it stands for
+ is up to whoever includes this commit in a repository.
-n::
--no-verify::
--
1.6.5.3.171.ge36e
^ permalink raw reply related
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Jeff Epler @ 2009-12-01 22:25 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <20091201211830.GE11235@dpotapov.dyndns.org>
On Wed, Dec 02, 2009 at 12:18:30AM +0300, Dmitry Potapov wrote:
> AFAIK, "git archive" is cheaper than git clone. I do not say it is fast
> for huge project, but if you want to run a process such as clean build
> and test that takes a long time anyway, it does not add much to the
> total time.
If you want to keep a separate copy of your source tree in order to get
consistent builds, "git archive" is not much cheaper in disk space or in
time, at least on this unix system:
$ find orig -exec md5sum {} + > /dev/null 2>&1 # ensure hot cache
$ time git clone orig temp-clone
Initialized empty Git repository in
/usr/local/jepler/src/temp-clone/.git/
0.6 real 0.3 user 0.6 system
$ time (GIT_DIR=orig/.git git archive --format tar --prefix temp-archive/ HEAD | tar xf -)
0.5 real 0.2 user 0.5 system
$ du -s orig temp-clone temp-archive
41880 orig
14640 temp-clone # du excludes files already accounted for by 'orig'
14304 temp-archive
.. and the next run to bring temp-clone up to date can be even faster,
since it's just 'git pull' and will only touch changed files.
Jeff
^ permalink raw reply
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Greg A. Woods @ 2009-12-01 22:44 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <20091201211830.GE11235@dpotapov.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 4046 bytes --]
At Wed, 2 Dec 2009 00:18:30 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
>
> AFAIK, "git archive" is cheaper than git clone.
It depends on what you mean by "cheaper" It's clearly going to require
less disk space. However it's also clearly going to require more disk
bandwidth, potentially a _LOT_ more disk bandwidth.
> I do not say it is fast
> for huge project, but if you want to run a process such as clean build
> and test that takes a long time anyway, it does not add much to the
> total time.
I think you need to try throwing around an archive of, say, 50,000 small
files a few times simultaneously on your system to appreciate the issue.
(i.e. consider the load on a storage subsystem, say a SAN or NAS, where
with your suggestion there might be a dozen or more developers running
"git archive" frequently enough that even three or four might be doing
it at the same time, and this on top of all the i/o bandwidth required
for the builds all of the other developers are also running at the same
time.)
> > Disk bandwidth is almost always more expensive than disk space.
>
> Disk bandwidth is certainly more expensive than disk space, and the
> whole point was to avoid a lot of disk bandwidth by using hot cache.
Huh? Throwing around the archive has nothing to do with the build
system in this case.
Please let me worry about optimizing the builds -- that's well under
control already and is not really yet an issue for the VCS, at least
not yet, and maybe never in many cases.
I'm just not willing to even consider using what would really be the
most simplistic and most expensive form of updating a working directory
as could ever be imagined. "Git archive" is truly unintelligent, as-is.
Perhaps if "git archive" could talk intelligently to an rsync process
and be smart about updating an existing working directory it would be
the ideal answer, but _NEVER_ with the current method of just unpacking
an archive over an existing directory! (Now there's a good Google SoC,
or masters, project for someone eager to learn about rsync & git
internals!)
Local filesystem "git clone" is usable in many scenarios, but it just
won't work nearly so efficiently in a scenario where users have local
repos on their workstations and use an NFS NAS to feed the build
servers. As I understand it this 'git-new-workdir' script will work
though since it uses symlinks that can be pointed across the mount back
to the local disk on the user's workstation. They can just mount the
build directory and go into it and run a "git checkout" and start
another build on the build server(s).
A major further advantage of multiple working directories is that this
eliminates one more point of failure -- i.e. you don't end up with
multiple copies of the repo that _should_ be effectively read-only for
everything but "push", and perhaps then only to one branch. I don't
like giving developers too much rope, especially in all the wrong
places. "git archive" does achieve the same even better I suppose, but
without something like a "--format=rsync" option it's completely out of
the question.
> Another thing to consider is that if you put a really huge project in one
> Git repo than Git may not be as fast as you may want, because Git tracks
> the whole project as the whole. So, you may want to split your project in
> a few relatively independent modules (See git submodule).
Indeed -- but sometimes I think this is not feasible either.
I know of at least three very real-world projects where there are tens
of thousands of small files that really must be managed as one unit, and
where running a build in that tree could take a whole day or two on even
the fastest currently available dedicated build server. Eg. pkgsrc.
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH v2] Add --track option to git clone
From: David Soria Parra @ 2009-12-01 22:51 UTC (permalink / raw)
To: git
Update:
+ added a test
The following series adds a --track option to git clone. If the --track option
is specified only the given remote branch will be received and checked out.
It tries to make the following usecase possible:
Imagine you are working on a project that has 1.x and a 2.x branch. The project
itself requires a complex setup (webserver, configuration files, etc). Setting up
1.x and 2.x branch requires a lot of work, but a developer needs to maintain both.
He'll use the --track option to clone the 2.x branch into a directory and does the same
with the 1.x branch, where he setup the project. He can use locally separate repositories
while still being able to push to just one remote repository.
I'm aware that it's not possible to give more than one --track option. Implementing
the possibility to specify multiple --track option would certainly a good improvment
later, but would also require a lot more work as far as I understand the clone code.
Being able to specify just one --track option is a compromise of doing a small change
and implementing this feature.
^ permalink raw reply
* [PATCH v2 1/2] Teach clone to clone just one remote branch using --track
From: David Soria Parra @ 2009-12-01 22:51 UTC (permalink / raw)
To: git; +Cc: David Soria Parra
In-Reply-To: <1259707865-6561-1-git-send-email-sn_@gmx.net>
From: David Soria Parra <dsp@php.net>
Add a --track option that can be used to clone just the
given branch from the remote and nothing else. This is done
by setting the remote.<branch>.fetch option before cloning.
This option cannot be used together with --mirror.
For example using
git clone --track next git://git.kernel.org/pub/scm/git/git.git
will just clone the next branch from the git.git repository.
The option is called --track to ensure clean wording with
'git remote add --track'.
Signed-off-by: David Soria Parra <dsp@php.net>
---
builtin-clone.c | 12 +++++++++++-
t/t5708-clone-track.sh | 43 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+), 1 deletions(-)
create mode 100755 t/t5708-clone-track.sh
diff --git a/builtin-clone.c b/builtin-clone.c
index 5df8b0f..bc335ee 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -43,6 +43,7 @@ static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
+static char *option_track = NULL;
static int option_verbose;
static struct option builtin_clone_options[] = {
@@ -76,6 +77,8 @@ static struct option builtin_clone_options[] = {
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
"create a shallow clone of that depth"),
+ OPT_STRING('t', "track", &option_track, "branch",
+ "remote branche to track"),
OPT_END()
};
@@ -483,7 +486,14 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
strbuf_addf(&branch_top, "refs/remotes/%s/", option_origin);
}
- strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
+ if (option_track) {
+ if (option_mirror)
+ return error("Cannot use --track together with --mirror");
+ strbuf_addf(&value, "+%s%s:%s%s", src_ref_prefix, option_track, branch_top.buf, option_track);
+ option_branch = option_track;
+ } else {
+ strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
+ }
if (option_mirror || !option_bare) {
/* Configure the remote */
diff --git a/t/t5708-clone-track.sh b/t/t5708-clone-track.sh
new file mode 100755
index 0000000..71b8461
--- /dev/null
+++ b/t/t5708-clone-track.sh
@@ -0,0 +1,43 @@
+#!/bin/sh
+
+test_description='clone --track option'
+. ./test-lib.sh
+
+check_HEAD() {
+ echo refs/heads/"$1" >expect &&
+ git symbolic-ref HEAD >actual &&
+ test_cmp expect actual
+}
+
+check_file() {
+ echo "$1" >expect &&
+ test_cmp expect file
+}
+
+test_expect_success 'setup' '
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file && git commit -m one &&
+ git checkout -b two &&
+ echo two >file && git add file && git commit -m two &&
+ git checkout master)
+'
+
+test_expect_success 'vanilla clone has both branches' '
+ git clone parent clone &&
+ (cd clone &&
+ git branch -r | grep master &&
+ git branch -r | grep two
+ )
+'
+
+test_expect_success 'clone -t chooses specified remote branch' '
+ git clone -t two parent clone-two &&
+ (cd clone-two &&
+ !(git branch -r | grep master) &&
+ git branch -r | grep two &&
+ check_HEAD two
+ )
+'
+
+test_done
--
1.6.6.rc0.268.g1c272
^ permalink raw reply related
* [PATCH v2 2/2] Documentation: Add --track option to the git clone manpage
From: David Soria Parra @ 2009-12-01 22:51 UTC (permalink / raw)
To: git; +Cc: David Soria Parra
In-Reply-To: <1259707865-6561-1-git-send-email-sn_@gmx.net>
From: David Soria Parra <dsp@php.net>
Signed-off-by: David Soria Parra <dsp@php.net>
---
Documentation/git-clone.txt | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7ccd742..c2ab645 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
- [-o <name>] [-b <name>] [-u <upload-pack>] [--reference <repository>]
+ [-o <name>] [-b <name>] [-t <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--recursive] [--] <repository> [<directory>]
DESCRIPTION
@@ -135,6 +135,12 @@ objects from the source repository into a pack in the cloned repository.
instead. In a non-bare repository, this is the branch that will
be checked out.
+--track <name>::
+-t <name>::
+ Instead of cloning the complete remote repository, only the given
+ remote branch `<name>` will be tracked and checked out.
+ This implies --branch `<name>`.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
--
1.6.6.rc0.268.g1c272
^ permalink raw reply related
* [PATCH] git-pull.sh: Fix call to git-merge for new command format
From: Horst H. von Brand @ 2009-12-01 22:44 UTC (permalink / raw)
To: git, gitster; +Cc: Horst H. von Brand
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
---
git-pull.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index bfeb4a0..a875809 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -218,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
exec git-rebase $diffstat $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
- "$merge_name" HEAD $merge_head $verbosity
+exec git-merge $verbosity -m $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
+ "$merge_name" $merge_head
--
1.6.6.rc0.114.gc8648
^ permalink raw reply related
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Shawn O. Pearce @ 2009-12-01 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, Sverre Rabbelier, git
In-Reply-To: <7vskbuwhmy.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> It is somewhat unfortunate that a few changes I liked (e.g. the "debug"
> bit), even though it was somewhat painful to read them due to coding style
> differences, were not at the beginning of the series but instead buried
> after changes that are much bigger and controversial (e.g. [6/8]).
I agree about that debug patch, I actually thought that was
interesting, and wish I had done more of that sort of work during
smart-http. It would have helped me to debug it in the early stages.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format
From: Junio C Hamano @ 2009-12-01 23:54 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <1259707451-20661-1-git-send-email-vonbrand@inf.utfsm.cl>
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> writes:
> Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
> ---
> git-pull.sh | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-pull.sh b/git-pull.sh
> index bfeb4a0..a875809 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -218,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
> test true = "$rebase" &&
> exec git-rebase $diffstat $strategy_args --onto $merge_head \
> ${oldremoteref:-$merge_head}
> -exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
> - "$merge_name" HEAD $merge_head $verbosity
> +exec git-merge $verbosity -m $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
> + "$merge_name" $merge_head
> --
> 1.6.6.rc0.114.gc8648
Heh, embarrasing.
But I think you wanted to have -m immediately before "$merge_name", no?
^ permalink raw reply
* Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
From: Dmitry Potapov @ 2009-12-02 0:10 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NFbSE-000kn2C@most.weird.com>
On Tue, Dec 01, 2009 at 05:44:15PM -0500, Greg A. Woods wrote:
> At Wed, 2 Dec 2009 00:18:30 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
> Subject: Re: multiple working directories for long-running builds (was: "git merge" merges too much!)
> >
> > AFAIK, "git archive" is cheaper than git clone.
>
> It depends on what you mean by "cheaper"
You said:
>>> "git archive" is likely even more
>>> impossible for some large projects to use than "git clone"
My point was that I do not see why you believe "git archive" is more
expensive than "git clone". Accordingly to Jeff Epler's numbers,
"git archive" is 20% faster than "git clone"...
> It's clearly going to require
> less disk space. However it's also clearly going to require more disk
> bandwidth, potentially a _LOT_ more disk bandwidth.
Well, it does, but as I said earlier it is not the case where I expect
things being instantaneous. If you do not a full build and test, then it
is going to take a lot of time anyway, and git-archive is not likely to
be a big overhead in relative terms.
> > I do not say it is fast
> > for huge project, but if you want to run a process such as clean build
> > and test that takes a long time anyway, it does not add much to the
> > total time.
>
> I think you need to try throwing around an archive of, say, 50,000 small
> files a few times simultaneously on your system to appreciate the issue.
>
> (i.e. consider the load on a storage subsystem, say a SAN or NAS, where
> with your suggestion there might be a dozen or more developers running
> "git archive" frequently enough that even three or four might be doing
> it at the same time, and this on top of all the i/o bandwidth required
> for the builds all of the other developers are also running at the same
> time.)
First of all, I do not see why it should be done frequently. The full
build and test may be run once or twice a day, and the full test and
build may take an hour. git-archive will take probably less than minute
for 50,000 small files (especially if you use tmpfs). In other words, it
is 1% overhead, but you get a clean build, which is fully tested. You
can sure that no garbage left in the worktree that could influence the
result.
>
> > > Disk bandwidth is almost always more expensive than disk space.
> >
> > Disk bandwidth is certainly more expensive than disk space, and the
> > whole point was to avoid a lot of disk bandwidth by using hot cache.
>
> Huh? Throwing around the archive has nothing to do with the build
> system in this case.
"git archive" to do full build and test, which is rarely done. Normally,
you just switch between branches, which means a few files are changed
and rebuild, and no archive is involved here.
>
> I'm just not willing to even consider using what would really be the
> most simplistic and most expensive form of updating a working directory
> as could ever be imagined. "Git archive" is truly unintelligent, as-is.
"git archive" is NOT for updating your working tree. You use "git
checkout" to switch between branches. "git checkout" is intelligent
enough to overwrite only those files that actually differ between
two versions.
> A major further advantage of multiple working directories is that this
> eliminates one more point of failure -- i.e. you don't end up with
> multiple copies of the repo that _should_ be effectively read-only for
> everything but "push", and perhaps then only to one branch.
Multiple copies of the same repo is never a problem (except taking some
disks space). I really do not understand why you say that some copies
should be effectively read-only... You can start to work on some feature
at one place (using one repo) and then continue in another place using
another repo. (Obviously, it will require to fetch changes from the
first repo, before you will be able to continue, but it is just one
command). In other words, I really do not understand what are you
talking about here.
>
> I know of at least three very real-world projects where there are tens
> of thousands of small files that really must be managed as one unit, and
> where running a build in that tree could take a whole day or two on even
> the fastest currently available dedicated build server. Eg. pkgsrc.
Tens of thousands files should not be a problem... For instance, the
Linux kernel has around 30 thousands and Git works very well in this
case. But I would consider to split if it has hundrends of thousands...
Dmitry
^ permalink raw reply
* Re: "git merge" merges too much!
From: Dmitry Potapov @ 2009-12-02 0:22 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <m1NFak0-000kn2C@most.weird.com>
On Tue, Dec 01, 2009 at 04:58:34PM -0500, Greg A. Woods wrote:
> At Tue, 1 Dec 2009 23:50:57 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
> Subject: Re: "git merge" merges too much!
> >
> > > >
> > > > $ git branch new-foo foo
> > > >
> > > > $ git rebase --onto newbase oldbase new-foo
> > >
> > > Hmmm.... I'll have to think about that. It makes some sense, but I
> > > don't intuitively read the command-line parameters well enough to
> > > predict the outcome in all of the scenarios I'm interested in.
> > >
> > > what is "oldbase" there? I'm guessing it means "base of foo" (and for
> > > the moment, "new-foo" too)?
> >
> > You have:
> >
> > o---o---o---o---o newbase
> > \
> > o---o---o---o---o oldbase
> > \
> > o---o---o foo
>
> Yes, sort of -- in the ideal situation, but not in my particular example
> where "oldbase" is just a tag, not a real branch.
It does not matter whether it is tag or branch or just SHA-1. You can
use any two reference as newbase and oldbase. They specify two points
in DAG. The only thing that has to be a branch in my example is new-foo.
>
> So yes, "oldbase" is in fact "base of foo". Trickier still is when the
> "oldbase" branch has one or more commits newer then "base of foo". Does
> Git not have a symbolic name for the true base of a branch? I.e. is
> there not some form of symbolic name for "N" in the following?
>
> o---o---o---o---o---o---o---o master
> \
> o---o---N---o---o release-1
> \
> o---o---o local-release-1
You can always find SHA-1 for N using the following command:
git merge-base release-1 local-release-1
but you do not have to do that to rebase your changes. You just can run:
# create a copy of local-release-1, so it will not disappear
git branch copy-release-1 local-release-1
# rebase the branch to master
git rebase --onto master release-1 copy-release-1
Dmitry
^ permalink raw reply
* [StGit PATCH v2 1/6] stg mail: Refactor __send_message and friends
From: Alex Chiang @ 2009-12-02 0:46 UTC (permalink / raw)
To: catalin.marinas; +Cc: git, Karl Wiberg
In-Reply-To: <20091202003503.7737.51579.stgit@bob.kio>
Instead of passing all the various smtp* args to __send_message
individually, let's just pass the options list instead.
The main motivation is for future patches. The end goal is to
thin out stg mail's implementation and make it a minimal wrapper
around git send-email. By passing the options list to __send_message
we prepare to pass options directly to git send-email.
As a bonus, this change results in a cleaner internal API.
Finally, it also pushes the smtp logic where it belongs, viz. into
__send_message_smtp, instead of cluttering up the main body of
mail.func().
Cc: Karl Wiberg <kha@treskal.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
---
stgit/commands/mail.py | 43 +++++++++++++++++++------------------------
1 files changed, 19 insertions(+), 24 deletions(-)
diff --git a/stgit/commands/mail.py b/stgit/commands/mail.py
index abd42e4..a38e3e6 100644
--- a/stgit/commands/mail.py
+++ b/stgit/commands/mail.py
@@ -190,10 +190,20 @@ def __send_message_sendmail(sendmail, msg):
cmd = sendmail.split()
Run(*cmd).raw_input(msg).discard_output()
-def __send_message_smtp(smtpserver, from_addr, to_addr_list, msg,
- smtpuser, smtppassword, use_tls):
+def __send_message_smtp(smtpserver, from_addr, to_addr_list, msg, options):
"""Send the message using the given SMTP server
"""
+ smtppassword = options.smtp_password or config.get('stgit.smtppassword')
+ smtpuser = options.smtp_user or config.get('stgit.smtpuser')
+ smtpusetls = options.smtp_tls or config.get('stgit.smtptls') == 'yes'
+
+ if (smtppassword and not smtpuser):
+ raise Exception('SMTP password supplied, username needed')
+ if (smtpusetls and not smtpuser):
+ raise Exception('SMTP over TLS requested, username needed')
+ if (smtpuser and not smtppassword):
+ smtppassword = getpass.getpass("Please enter SMTP password: ")
+
try:
s = smtplib.SMTP(smtpserver)
except Exception, err:
@@ -203,7 +213,7 @@ def __send_message_smtp(smtpserver, from_addr, to_addr_list, msg,
try:
if smtpuser and smtppassword:
s.ehlo()
- if use_tls:
+ if smtpusetls:
if not hasattr(socket, 'ssl'):
raise CmdException, "cannot use TLS - no SSL support in Python"
s.starttls()
@@ -218,17 +228,17 @@ def __send_message_smtp(smtpserver, from_addr, to_addr_list, msg,
s.quit()
-def __send_message(smtpserver, from_addr, to_addr_list, msg,
- smtpuser, smtppassword, use_tls):
+def __send_message(from_addr, to_addr_list, msg, options):
"""Message sending dispatcher.
"""
+ smtpserver = options.smtp_server or config.get('stgit.smtpserver')
+
if smtpserver.startswith('/'):
# Use the sendmail tool
__send_message_sendmail(smtpserver, msg)
else:
# Use the SMTP server (we have host and port information)
- __send_message_smtp(smtpserver, from_addr, to_addr_list, msg,
- smtpuser, smtppassword, use_tls)
+ __send_message_smtp(smtpserver, from_addr, to_addr_list, msg, options)
def __build_address_headers(msg, options, extra_cc = []):
"""Build the address headers and check existing headers in the
@@ -543,8 +553,6 @@ def func(parser, options, args):
"""Send the patches by e-mail using the patchmail.tmpl file as
a template
"""
- smtpserver = options.smtp_server or config.get('stgit.smtpserver')
-
applied = crt_series.get_applied()
if options.all:
@@ -564,17 +572,6 @@ def func(parser, options, args):
raise CmdException, 'Cannot send empty patch "%s"' % p
out.done()
- smtppassword = options.smtp_password or config.get('stgit.smtppassword')
- smtpuser = options.smtp_user or config.get('stgit.smtpuser')
- smtpusetls = options.smtp_tls or config.get('stgit.smtptls') == 'yes'
-
- if (smtppassword and not smtpuser):
- raise CmdException, 'SMTP password supplied, username needed'
- if (smtpusetls and not smtpuser):
- raise CmdException, 'SMTP over TLS requested, username needed'
- if (smtpuser and not smtppassword):
- smtppassword = getpass.getpass("Please enter SMTP password: ")
-
total_nr = len(patches)
if total_nr == 0:
raise CmdException, 'No patches to send'
@@ -616,8 +613,7 @@ def func(parser, options, args):
out.stdout_raw(msg_string + '\n')
else:
out.start('Sending the cover message')
- __send_message(smtpserver, from_addr, to_addr_list, msg_string,
- smtpuser, smtppassword, smtpusetls)
+ __send_message(from_addr, to_addr_list, msg_string, options)
time.sleep(sleep)
out.done()
@@ -648,8 +644,7 @@ def func(parser, options, args):
out.stdout_raw(msg_string + '\n')
else:
out.start('Sending patch "%s"' % p)
- __send_message(smtpserver, from_addr, to_addr_list, msg_string,
- smtpuser, smtppassword, smtpusetls)
+ __send_message(from_addr, to_addr_list, msg_string, options)
# give recipients a chance of receiving related patches in the
# correct order.
if patch_nr < total_nr:
^ permalink raw reply related
* [StGit PATCH v2 0/6] add support for git send-email
From: Alex Chiang @ 2009-12-02 0:46 UTC (permalink / raw)
To: catalin.marinas; +Cc: git, Karl Wiberg
This is v2 of the series that starts teaching stg mail how to
call git send-email.
I made all the changes that Karl recommended, and made sure to
run the t1900-mail.sh test at every point in the series (passes
successfully).
I also experimented with adding another test case for --git
mode, basically duplicating t1900-mail.sh, and then adding the
--git argument wherever it made sense.
However, that resulted in failure of the last 3 test cases,
which is due to the fact that we no longer parse To/Cc/Bcc
command line args in --git mode, and the resulting mbox file was
missing the expected recipient addresses.
I played around with that for a while, thinking that I could use
git send-email --dry-run to do something equivalent, but then
realized that git send-email's run-run mode is definitely not
analogous to stg mail's --mbox mode.
The upshot is that in stg mail, --git and --mbox don't interact
well, and the resulting mbox file will lack the recipients. This
might be fixed in the future if we teach git send-email how to
generate mbox files, but then we introduce a versioning problem.
So let's just accept this wart for now, and say, if you want an
mbox file generated, don't use --git. That seems reasonable to
me.
This mail was sent with the following command line:
./stg mail --git -a -e --auto -v v2 --prefix=StGit
--to=catalin.marinas@gmail.com --cc=git
Note that the --cc= contains an alias for the git mailing list
that I defined in my ~/.mutt.aliases file (and specified in
.gitconfig -> sendemail.aliasesfile and sendemail.aliasfiletype.
Thanks,
/ac
---
Alex Chiang (6):
stg mail: Refactor __send_message and friends
stg mail: reorder __build_[message|cover] parameters
stg mail: make __send_message do more
stg mail: factor out __update_header
stg mail: add basic support for git send-email
stg mail: don't parse To/Cc/Bcc in --git mode
stgit/commands/mail.py | 196 +++++++++++++++++++++++++++---------------------
1 files changed, 112 insertions(+), 84 deletions(-)
^ 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