* [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jari Aalto @ 2009-10-21 20:07 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/fetch-options.txt | 48 +++++++++++++++++++-------------------
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 5eb2b0e..2886874 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,25 +1,13 @@
-ifndef::git-pull[]
--q::
---quiet::
- Pass --quiet to git-fetch-pack and silence any other internally
- used git commands.
-
--v::
---verbose::
- Be verbose.
-endif::git-pull[]
-
-a::
--append::
Append ref names and object names of fetched refs to the
existing contents of `.git/FETCH_HEAD`. Without this
option old data in `.git/FETCH_HEAD` will be overwritten.
---upload-pack <upload-pack>::
- When given, and the repository to fetch from is handled
- by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
- the command to specify non-default path for the command
- run on the other end.
+--depth=<depth>::
+ Deepen the history of a 'shallow' repository created by
+ `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
+ by the specified number of commits.
-f::
--force::
@@ -29,6 +17,10 @@ endif::git-pull[]
fetches is a descendant of `<lbranch>`. This option
overrides that check.
+-k::
+--keep::
+ Keep downloaded pack.
+
ifdef::git-pull[]
--no-tags::
endif::git-pull[]
@@ -49,10 +41,6 @@ endif::git-pull[]
flag lets all tags and their associated objects be
downloaded.
--k::
---keep::
- Keep downloaded pack.
-
-u::
--update-head-ok::
By default 'git-fetch' refuses to update the head which
@@ -62,7 +50,19 @@ endif::git-pull[]
implementing your own Porcelain you are not supposed to
use it.
---depth=<depth>::
- Deepen the history of a 'shallow' repository created by
- `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1])
- by the specified number of commits.
+--upload-pack <upload-pack>::
+ When given, and the repository to fetch from is handled
+ by 'git-fetch-pack', '--exec=<upload-pack>' is passed to
+ the command to specify non-default path for the command
+ run on the other end.
+
+ifndef::git-pull[]
+-q::
+--quiet::
+ Pass --quiet to git-fetch-pack and silence any other internally
+ used git commands.
+
+-v::
+--verbose::
+ Be verbose.
+endif::git-pull[]
--
1.6.4.3
^ permalink raw reply related
* Re: keeping track of where a patch begins
From: Junio C Hamano @ 2009-10-21 20:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: E R, git, Jeff King
In-Reply-To: <alpine.LFD.2.00.0910211402490.21460@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
> On Wed, 21 Oct 2009, E R wrote:
>
>> What solutions have you come up with to either to catch or prevent
>> this from happening? It is possible to determine what node a branch
>> started from?
>
> This can be determined by looking at the gitk output.
>
> Also 'git merge-base' can give you that node, given the main branch and
> the topic branch. See documentation about git-merge-base.
>
> Then if you need to move a branch to another starting node, then 'git
> rebase' is what you need (again the git-rebase documentation is pretty
> detailed).
That is a correct way to diagnose the mistake and recover from it, but
unfortunately it is a rather weak tool to identify the mistake in the
first place.
A branch in git, as Randal often used to say on #git, is an illusion---it
points only at the top and does not identify the bottom.
But it does _not_ have to stay that way at the Porcelain level.
Here is a rough sketch of one possible solution. It is not fully thought
out; the basic idea is probably sound but I did not try to exhaustively
cover changes to various tools that are necessary to maintain the
invariants this scheme requires.
(0) Define a way to identify the bottom of a branch. One way to do this
is by an extra ref (e.g. refs/branchpoints/frotz). Then the commits
between refs/branchpoints/frotz..refs/heads/frotz identifies the
commits on the branch. None of the additional restrictions below
applies when the branch does not have such bottom defined (i.e.
created by the current git without this extension).
(1) At branch creation, the branchpoint is noted. E.g.
$ git branch frotz master~4
would internally become
$ git update-ref refs/heads/frotz master~4
$ git update-ref refs/branchpoints/frotz master~4
You would also need to cover "checkout -b".
(2) You can grow the branch naturally with "commit", "am" and "merge".
The bottom of the branch does not have to move with these operations.
(3) Operations that alter histories, e.g. "commit --amend", "rebase",
"reset", while on a branch that records its bottom need to be taught
to pay attention to not break its bottom. Paying attention needs to
take different forms depending on the operation; some probably will
forbid the operation while others would automatically adjust the
bottom.
Examples (not exhaustive):
(3-a) "branch -f frotz $commit"
This moves the tip of the branch. Unless $commit is already some
part of the existing frotz branch, we should probably forbid it for
simplicity, when a bottom is defined for the branch.
We could later loosen the rule so that $commit is only required to be
a descendant of existing bottom of the branch to support a workflow
like this:
$ git checkout -b frotz master~4 ;# records branchpoint
$ edit; git add; git commit; ... ;# builds history
$ git checkout HEAD^ ;# go back somewhere on frotz
$ edit; git add; git commit; ... ;# builds an alternate history
$ git show-branch HEAD frotz ;# check progress
$ git diff frotz HEAD ;# is this one better?
$ git branch -f frotz ;# I prefer this new one better
(3-b) "reset $commit" (with or without --hard/--soft/--mixed)
This is similar to (3-a) above; $commit has to be a descendant of
existing bottom.
(3-c) "commit --amend"
$ git checkout -b frotz master~4 ;# records branchpoint
$ git commit --amend ;# rewrite the bottom???
would probably be a mistake, as the end result would make the frotz
branch forked from master~5 with the first commit on the branch a
fix-up to what is already in the master branch.
However, this is a valid way to work:
$ git checkout -b frotz master~4 ;# records branchpoint
$ edit; git add; git commit ;# builds history
$ git commit --amend ;# fix the tip
and it does not have to do anything to the bottom.
(3-d) "rebase"
$ git checkout -b frotz master~4 ;# records branchpoint
$ edit; git add; git commit; ... ;# builds history
$ git rebase --onto master ;# transplants the branch
would make the "onto" commit the new bottom. Another interesting
thing to note is that we do not have to compute which commits to
transplant with merge-base with the "onto" commit, because we know
the bottom commit of the branch.
(4) Operations that browse histories, e.g. "log", "show-branch", while on
a branch that records its bottom can be taught to pay attention to
the bottom. For example, it is conceivable that
$ git log
$ git log -- Documentation/
without an explicit branch name that fell back to the default HEAD
while on branch "frotz" might be better run with an implicit bottom
^refs/branchpoint/frotz.
We probably could kill the other bird in the nearby thread that wants to
add a description to a branch, if this scheme is fully implemented (no, I
am not going to start coding right away, as this message is just a sketch
of what we _could_ do), As we will fully know in what operations we need
to update the branchpoint ref, we could make the refs/branchpoints/frotz
an annotated tag, and store the description for the branch in that tag.
Whenever we need to adjust the branchpoint, we update it while carrying
the branch description message over to the new tag object.
^ permalink raw reply
* [PATCH] everyday: fsck and gc are not everyday operations
From: Anders Kaseorg @ 2009-10-21 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Back in 2005 when this document was written, it may have made sense to
introduce ‘git fsck’ (then ‘git fsck-objects’) as the very first example
command for new users of Git 0.99.9. Now that Git has been stable for
years and does not actually tend to eat your data, it makes significantly
less sense. In fact, it sends an entirely wrong message.
‘git gc’ is also unnecessary for the purposes of this document, especially
with gc.auto enabled by default.
The only other commands in the “Basic Repository” section were ‘git init’
and ‘git clone’. ‘clone’ is already listed in the “Participant” section,
so move ‘init’ to the “Standalone” section and get rid of “Basic
Repository” entirely.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
Documentation/everyday.txt | 51 +++----------------------------------------
1 files changed, 4 insertions(+), 47 deletions(-)
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 9310b65..e0ba8cc 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -1,13 +1,8 @@
Everyday GIT With 20 Commands Or So
===================================
-<<Basic Repository>> commands are needed by people who have a
-repository --- that is everybody, because every working tree of
-git is a repository.
-
-In addition, <<Individual Developer (Standalone)>> commands are
-essential for anybody who makes a commit, even for somebody who
-works alone.
+<<Individual Developer (Standalone)>> commands are essential for
+anybody who makes a commit, even for somebody who works alone.
If you work with other people, you will need commands listed in
the <<Individual Developer (Participant)>> section as well.
@@ -20,46 +15,6 @@ administrators who are responsible for the care and feeding
of git repositories.
-Basic Repository[[Basic Repository]]
-------------------------------------
-
-Everybody uses these commands to maintain git repositories.
-
- * linkgit:git-init[1] or linkgit:git-clone[1] to create a
- new repository.
-
- * linkgit:git-fsck[1] to check the repository for errors.
-
- * linkgit:git-gc[1] to do common housekeeping tasks such as
- repack and prune.
-
-Examples
-~~~~~~~~
-
-Check health and remove cruft.::
-+
-------------
-$ git fsck <1>
-$ git count-objects <2>
-$ git gc <3>
-------------
-+
-<1> running without `\--full` is usually cheap and assures the
-repository health reasonably well.
-<2> check how many loose objects there are and how much
-disk space is wasted by not repacking.
-<3> repacks the local repository and performs other housekeeping tasks.
-
-Repack a small project into single pack.::
-+
-------------
-$ git gc <1>
-------------
-+
-<1> pack all the objects reachable from the refs into one pack,
-then remove the other packs.
-
-
Individual Developer (Standalone)[[Individual Developer (Standalone)]]
----------------------------------------------------------------------
@@ -67,6 +22,8 @@ A standalone individual developer does not exchange patches with
other people, and works alone in a single repository, using the
following commands.
+ * linkgit:git-init[1] to create a new repository.
+
* linkgit:git-show-branch[1] to see where you are.
* linkgit:git-log[1] to see what happened.
--
1.6.5.1
^ permalink raw reply related
* Re: [Foundation-l] Wikipedia meets git
From: Bernie Innocenti @ 2009-10-21 19:49 UTC (permalink / raw)
To: Samuel Klein; +Cc: Wikimedia Foundation Mailing List, git
In-Reply-To: <5396c0d10910210543i4c0a3350je5bee4c6389a2292@mail.gmail.com>
[cc+=git@vger.kernel.org]
El Wed, 21-10-2009 a las 08:43 -0400, Samuel Klein escribió:
> That sounds like a great idea. I know a few other people who have
> worked on git-based wikis and toyed with making them compatible with
> mediawiki (copying bernie innocenti, one of the most eloquent :).
Then I'll do my best to sound as eloquent as expected :)
While I think git's internal structure is wonderfully simple and
elegant, I'm a little worried about its scalability in the wiki usecase.
The scenario for which git's repository format was designed is "patch
oriented" revision control of a filesystem tree. The central object of a
git tree is the "commit", which represents a set of changes on multiple
files. I'll disregard all the juicy details on how the changes are
actually packed together to save disk space, making git's repository
format amazingly compact.
Commits are linked to each other in order to represent the history. Git
can efficiently represent a highly non-linear history with thousands of
branches, each containing hundreds of thousands revisions. Branching and
merging huge trees is so fast that one is left wondering if anything has
happened at all.
So far, so good. This commit-oriented design is great if you want to
track the history *the whole tree* at once, applying related changes to
multiple files atomically. In Git, as well as most other version control
systems, there's no such thing as a *file* revision! Git manages entire
trees. Trees are assigned unique revision numbers (in fact, ugly sha-1
hashes), and can optionally by tagged or branched at will.
And here's the the catch: the history of individual files is not
directly represented in a git repository. It is typically scattered
across thousands of commit objects, with no direct links to help find
them. If you want to retrieve the log of a file that was changed only 6
times in the entire history of the Linux kernel, you'd have to dig
through *all* of the 170K revisions in the "master" branch.
And it takes some time even if git is blazingly fast:
bernie@giskard:~/src/kernel/linux-2.6$ time git log --pretty=oneline REPORTING-BUGS | wc -l
6
real 0m1.668s
user 0m1.416s
sys 0m0.210s
(my laptop has a low-power CPU. A fast server would be 8-10x faster).
Now, the English Wikipedia seems to have slightly more than 3M articles,
with--how many? tenths of millions of revisions for sure. Going through
them *every time* one needs to consult the history of a file would be
100x slower. Tens of seconds. Not acceptable, uh?
It seems to me that the typical usage pattern of an encyclopedia is to
change each article individually. Perhaps I'm underestimating the role
of bots here. Anyway, there's no consistency *requirement* for mass
changes to be applied atomically throughout all the encyclopedia, right?
In conclusion, the "tree at a time" design is going to be a performance
bottleneck for a large wiki, with no useful application. Unless of
course the concept of changesets was exposed in the UI, which would be
an interesting idea to explore.
Mercurial (Hg) seems to have a better repository layout for the "one
file at a time" access pattern... Unfortunately, it's also much slower
than git for almost any other purpose, sometimes by an order of
magnitude. I'm not even sure how well Hg would cope with a repository
containing 3M files and some 30M revisions. The largest Hg tree I've
dealt with is the "mozilla central" repo, which is already unbearably
slow to work with.
It would be interesting to compare notes with the other DSCM hackers,
too.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
^ permalink raw reply
* Re: git submodules
From: Avery Pennarun @ 2009-10-21 19:38 UTC (permalink / raw)
To: Steven Noonan; +Cc: Git Mailing List, crawl-ref-discuss
In-Reply-To: <f488382f0910171015j1a6d4d9fg690867154334c514@mail.gmail.com>
On Sat, Oct 17, 2009 at 1:15 PM, Steven Noonan <steven@uplinklabs.net> wrote:
> We're using git submodules for the contributing libraries. When I
> commit changes to those contribs, it correctly shows in the parent
> repository that those folders have different revisions than what's
> currently committed. However, if someone pulls those changes, it
> doesn't automatically update the contribs to match the committed
> version. But doing a pull or merge _should_ update the working tree to
> match the committed versions. It does with file data, so why not
> update the submodules? Especially if the submodule revision matched
> the committed version -before- the pull. Why are we forced into using
> 'git submodule update'?
<advertisement>
git-subtree (http://github.com/apenwarr/git-subtree) is an alternative
to submodules that doesn't have this problem.
</advertisement>
But it probably has other problems. :) Works great for my purposes,
though, and quite a few people have contacted me to say they're using
it happily.
Have fun,
Avery
^ permalink raw reply
* [PATCH v2] Quote ' as \(aq in manpages
From: Thomas Rast @ 2009-10-21 18:57 UTC (permalink / raw)
To: git; +Cc: Anders Kaseorg, Miklos Vajna, Junio C Hamano, bill lam
In-Reply-To: <alpine.DEB.2.00.0910211357160.5105@dr-wily.mit.edu>
The docbook/xmlto toolchain insists on quoting ' as \'. This does
achieve the quoting goal, but modern 'man' implementations turn the
apostrophe into a unicode "proper" apostrophe (given the right
circumstances), breaking code examples in many of our manpages.
Quote them as \(aq instead, which is an "apostrophe quote" as per the
groff_char manpage.
Unfortunately, as Anders Kaseorg kindly pointed out, this is not
portable beyond groff, so we add an extra Makefile variable GNU_ROFF
which you need to enable to get the new quoting.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[Reinstated the Cc list, which I accidentally dropped when sending the
first patch...]
Anders Kaseorg wrote:
> \(aq is not portable to non-GNU roff. See
> http://bugs.debian.org/507673#65
> http://sourceforge.net/tracker/index.php?func=detail&aid=2412738&group_id=21935&atid=373747
> for a proposed portable solution.
Thanks for pointing that out. Makes things a lot easier though. I'm
really beginning to enjoy the whole doc toolchain.
I could not find a way to insert the proposed definitions into the
header by tweaking the xsls, so unless someone comes up with a way of
doing that, this is the best I can do.
To save you the effort of clicking the links, the header definitions
would be
.ie \n(.g .ds Aq \(aq
.el .ds Aq '
and you then have to change the template to quote to \(Aq instead.
Documentation/Makefile | 3 +++
Documentation/manpage-quote-apos.xsl | 16 ++++++++++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 Documentation/manpage-quote-apos.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 06b0c57..68876d0 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -102,6 +102,9 @@ endif
ifdef DOCBOOK_SUPPRESS_SP
XMLTO_EXTRA += -m manpage-suppress-sp.xsl
endif
+ifdef GNU_ROFF
+XMLTO_EXTRA += -m manpage-quote-apos.xsl
+endif
SHELL_PATH ?= $(SHELL)
# Shell quote;
diff --git a/Documentation/manpage-quote-apos.xsl b/Documentation/manpage-quote-apos.xsl
new file mode 100644
index 0000000..aeb8839
--- /dev/null
+++ b/Documentation/manpage-quote-apos.xsl
@@ -0,0 +1,16 @@
+<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+ version="1.0">
+
+<!-- work around newer groff/man setups using a prettier apostrophe
+ that unfortunately does not quote anything when cut&pasting
+ examples to the shell -->
+<xsl:template name="escape.apostrophe">
+ <xsl:param name="content"/>
+ <xsl:call-template name="string.subst">
+ <xsl:with-param name="string" select="$content"/>
+ <xsl:with-param name="target">'</xsl:with-param>
+ <xsl:with-param name="replacement">\(aq</xsl:with-param>
+ </xsl:call-template>
+</xsl:template>
+
+</xsl:stylesheet>
--
1.6.5.1.144.g316236
^ permalink raw reply related
* [PATCH v2 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Thomas Rast @ 2009-10-21 18:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <95535b01e2181d321190c6d93b2834188612a389.1256149428.git.trast@student.ethz.ch>
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Evidently I shouldn't send any patches after dinner, or before, for
that matter (but for lack of wifi in the restaurant, *during* dinner
is not an option either). Or at least I shouldn't re-read them after
sending :-(
v1 had a completely misplaced option parsing for the new option.
Very embarrassing. Really.
I also sneak fixed the commit message above; you only need two -- if
you want rev-list options, e.g.,
git filter-branch -- --all -- README
in which case the first one of course needs to appear before the first
<refs> argument.
Documentation/git-filter-branch.txt | 13 ++++++++++++-
git-filter-branch.sh | 9 ++++++++-
t/t7003-filter-branch.sh | 18 ++++++++++++++++++
3 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2b40bab..394a77a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -159,7 +159,18 @@ to other tags will be rewritten to point to the underlying commit.
--subdirectory-filter <directory>::
Only look at the history which touches the given subdirectory.
The result will contain that directory (and only that) as its
- project root.
+ project root. Implies --remap-to-ancestor.
+
+--remap-to-ancestor::
+ Rewrite refs to the nearest rewritten ancestor instead of
+ ignoring them.
++
+Normally, positive refs on the command line are only changed if the
+commit they point to was rewritten. However, you can limit the extent
+of this rewriting by using linkgit:rev-list[1] arguments, e.g., path
+limiters. Refs pointing to such excluded commits would then normally
+be ignored. With this option, they are instead rewritten to point at
+the nearest ancestor that was not excluded.
--prune-empty::
Some kind of filters will generate empty commits, that left the tree
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3890c22..be36db4 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -125,6 +125,7 @@ filter_subdir=
orig_namespace=refs/original/
force=
prune_empty=
+remap_to_ancestor=
while :
do
case "$1" in
@@ -137,6 +138,11 @@ do
force=t
continue
;;
+ --remap-to-ancestor)
+ shift
+ remap_to_ancestor=t
+ continue
+ ;;
--prune-empty)
shift
prune_empty=t
@@ -182,6 +188,7 @@ do
;;
--subdirectory-filter)
filter_subdir="$OPTARG"
+ remap_to_ancestor=t
;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
@@ -364,7 +371,7 @@ done <../revs
# revision walker. Fix it by mapping these heads to the unique nearest
# ancestor that survived the pruning.
-if test "$filter_subdir"
+if test "$remap_to_ancestor" = t
then
while read ref
do
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 329c851..9503875 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -288,4 +288,22 @@ test_expect_success 'Prune empty commits' '
test_cmp expect actual
'
+test_expect_success '--remap-to-ancestor with filename filters' '
+ git checkout master &&
+ git reset --hard A &&
+ test_commit add-foo foo 1 &&
+ git branch moved-foo &&
+ test_commit add-bar bar a &&
+ git branch invariant &&
+ orig_invariant=$(git rev-parse invariant) &&
+ git branch moved-bar &&
+ test_commit change-foo foo 2 &&
+ git filter-branch -f --remap-to-ancestor \
+ moved-foo moved-bar A..master \
+ -- -- foo &&
+ test $(git rev-parse moved-foo) = $(git rev-parse moved-bar) &&
+ test $(git rev-parse moved-foo) = $(git rev-parse master^) &&
+ test $orig_invariant = $(git rev-parse invariant)
+'
+
test_done
--
1.6.5.1.142.g4bac9
^ permalink raw reply related
* [PATCH v2 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Thomas Rast @ 2009-10-21 18:28 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <95535b01e2181d321190c6d93b2834188612a389.1256148512.git.trast@student.ethz.ch>
Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused. Furthermore,
the case for --subdirectory-filter supplies its own --, so the user
cannot provide one himself (though there is also very little point in
doing so).
Instead, tack the $filter_subdir onto $@ in the right place
automatically, and only use a -- if it was not already provided by the
user.
We set non_ref_args again after changing "$@"; the next patch wants to
use it again afterwards, so we better not leave a stale value in
there.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[Same as v1.]
This is preparatory for the next patch; introducing another 'case'
along the lines of the existing one annoyed me, so I went for this
instead. I would greatly appreciate extra eyes on my use of 'eval'.
I originally expected this to work without eval, but apparently this
is how one does it. Quoting rules in the shell are annoying.
Incidentally, the last hunk sneak fixes a previously unquoted use of
$ref that is my fault from back in a0e4639 (filter-branch: fix ref
rewriting with --subdirectory-filter, 2008-08-12).
git-filter-branch.sh | 28 +++++++++++++++++++++-------
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a480d6f..3890c22 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -257,15 +257,29 @@ git read-tree || die "Could not seed the index"
# map old->new commit ids for rewriting parents
mkdir ../map || die "Could not create map/ directory"
+non_ref_args=$(git rev-parse --no-revs --sq "$@")
+dashdash=--
+for arg in "$non_ref_args"; do
+ if test arg = --; then
+ dashdash=
+ break
+ fi
+done
+
case "$filter_subdir" in
"")
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@"
+ filter_subdir_sq=
;;
*)
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@" -- "$filter_subdir"
-esac > ../revs || die "Could not get the commits"
+ filter_subdir_sq=$(git rev-parse --sq-quote "$filter_subdir")
+esac
+
+eval "set -- \"\$@\" $dashdash $filter_subdir_sq"
+non_ref_args=$(git rev-parse --no-revs --sq "$@")
+
+git rev-list --reverse --topo-order --default HEAD \
+ --parents --simplify-merges "$@" \
+ > ../revs || die "Could not get the commits"
commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -356,8 +370,8 @@ then
do
sha1=$(git rev-parse "$ref"^0)
test -f "$workdir"/../map/$sha1 && continue
- ancestor=$(git rev-list --simplify-merges -1 \
- $ref -- "$filter_subdir")
+ ancestor=$(eval "git rev-list --simplify-merges " \
+ "-1 \"$ref\" $non_ref_args")
test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
done < "$tempdir"/heads
fi
--
1.6.5.1.142.g4bac9
^ permalink raw reply related
* [PATCH 2/2] filter-branch: nearest-ancestor rewriting outside subdir filter
From: Thomas Rast @ 2009-10-21 18:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <95535b01e2181d321190c6d93b2834188612a389.1256148512.git.trast@student.ethz.ch>
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch <refs> -- -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This came up on IRC the other day (see a pattern?), when someone
wanted to split out the history for a single file, and first had to
point all relevant refs at the corresponding nearest relevant
ancestor.
I think we could even make this option the default if it wasn't for
backwards compatibility; after all, what use is rewriting the commits
if you do not get a ref pointing to them?
Documentation/git-filter-branch.txt | 13 ++++++++++++-
git-filter-branch.sh | 7 ++++++-
t/t7003-filter-branch.sh | 18 ++++++++++++++++++
3 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2b40bab..394a77a 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -159,7 +159,18 @@ to other tags will be rewritten to point to the underlying commit.
--subdirectory-filter <directory>::
Only look at the history which touches the given subdirectory.
The result will contain that directory (and only that) as its
- project root.
+ project root. Implies --remap-to-ancestor.
+
+--remap-to-ancestor::
+ Rewrite refs to the nearest rewritten ancestor instead of
+ ignoring them.
++
+Normally, positive refs on the command line are only changed if the
+commit they point to was rewritten. However, you can limit the extent
+of this rewriting by using linkgit:rev-list[1] arguments, e.g., path
+limiters. Refs pointing to such excluded commits would then normally
+be ignored. With this option, they are instead rewritten to point at
+the nearest ancestor that was not excluded.
--prune-empty::
Some kind of filters will generate empty commits, that left the tree
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3890c22..d18f82d 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -125,6 +125,7 @@ filter_subdir=
orig_namespace=refs/original/
force=
prune_empty=
+remap_to_ancestor=
while :
do
case "$1" in
@@ -182,10 +183,14 @@ do
;;
--subdirectory-filter)
filter_subdir="$OPTARG"
+ remap_to_ancestor=t
;;
--original)
orig_namespace=$(expr "$OPTARG/" : '\(.*[^/]\)/*$')/
;;
+ --remap-to-ancestor)
+ remap_to_ancestor=t
+ ;;
*)
usage
;;
@@ -364,7 +369,7 @@ done <../revs
# revision walker. Fix it by mapping these heads to the unique nearest
# ancestor that survived the pruning.
-if test "$filter_subdir"
+if test "$remap_to_ancestor" = t
then
while read ref
do
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 329c851..9503875 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -288,4 +288,22 @@ test_expect_success 'Prune empty commits' '
test_cmp expect actual
'
+test_expect_success '--remap-to-ancestor with filename filters' '
+ git checkout master &&
+ git reset --hard A &&
+ test_commit add-foo foo 1 &&
+ git branch moved-foo &&
+ test_commit add-bar bar a &&
+ git branch invariant &&
+ orig_invariant=$(git rev-parse invariant) &&
+ git branch moved-bar &&
+ test_commit change-foo foo 2 &&
+ git filter-branch -f --remap-to-ancestor \
+ moved-foo moved-bar A..master \
+ -- -- foo &&
+ test $(git rev-parse moved-foo) = $(git rev-parse moved-bar) &&
+ test $(git rev-parse moved-foo) = $(git rev-parse master^) &&
+ test $orig_invariant = $(git rev-parse invariant)
+'
+
test_done
--
1.6.5.1.139.g12527
^ permalink raw reply related
* [PATCH 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Thomas Rast @ 2009-10-21 18:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Handling $filter_subdir in the usual way requires a separate case at
every use, because the variable is empty when unused. Furthermore,
the case for --subdirectory-filter supplies its own --, so the user
cannot provide one himself (though there is also very little point in
doing so).
Instead, tack the $filter_subdir onto $@ in the right place
automatically, and only use a -- if it was not already provided by the
user.
We set non_ref_args again after changing "$@"; the next patch wants to
use it again afterwards, so we better not leave a stale value in
there.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This is preparatory for the next patch; introducing another 'case'
along the lines of the existing one annoyed me, so I went for this
instead. I would greatly appreciate extra eyes on my use of 'eval'.
I originally expected this to work without eval, but apparently this
is how one does it. Quoting rules in the shell are annoying.
Incidentally, the last hunk sneak fixes a previously unquoted use of
$ref that is my fault from back in a0e4639 (filter-branch: fix ref
rewriting with --subdirectory-filter, 2008-08-12).
git-filter-branch.sh | 28 +++++++++++++++++++++-------
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a480d6f..3890c22 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -257,15 +257,29 @@ git read-tree || die "Could not seed the index"
# map old->new commit ids for rewriting parents
mkdir ../map || die "Could not create map/ directory"
+non_ref_args=$(git rev-parse --no-revs --sq "$@")
+dashdash=--
+for arg in "$non_ref_args"; do
+ if test arg = --; then
+ dashdash=
+ break
+ fi
+done
+
case "$filter_subdir" in
"")
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@"
+ filter_subdir_sq=
;;
*)
- git rev-list --reverse --topo-order --default HEAD \
- --parents --simplify-merges "$@" -- "$filter_subdir"
-esac > ../revs || die "Could not get the commits"
+ filter_subdir_sq=$(git rev-parse --sq-quote "$filter_subdir")
+esac
+
+eval "set -- \"\$@\" $dashdash $filter_subdir_sq"
+non_ref_args=$(git rev-parse --no-revs --sq "$@")
+
+git rev-list --reverse --topo-order --default HEAD \
+ --parents --simplify-merges "$@" \
+ > ../revs || die "Could not get the commits"
commits=$(wc -l <../revs | tr -d " ")
test $commits -eq 0 && die "Found nothing to rewrite"
@@ -356,8 +370,8 @@ then
do
sha1=$(git rev-parse "$ref"^0)
test -f "$workdir"/../map/$sha1 && continue
- ancestor=$(git rev-list --simplify-merges -1 \
- $ref -- "$filter_subdir")
+ ancestor=$(eval "git rev-list --simplify-merges " \
+ "-1 \"$ref\" $non_ref_args")
test "$ancestor" && echo $(map $ancestor) >> "$workdir"/../map/$sha1
done < "$tempdir"/heads
fi
--
1.6.5.1.139.g12527
^ permalink raw reply related
* Re: keeping track of where a patch begins
From: Nicolas Pitre @ 2009-10-21 18:14 UTC (permalink / raw)
To: E R; +Cc: git
In-Reply-To: <3a69fa7c0910210745r311cf18xf966f5c63650cde6@mail.gmail.com>
On Wed, 21 Oct 2009, E R wrote:
> What solutions have you come up with to either to catch or prevent
> this from happening? It is possible to determine what node a branch
> started from?
This can be determined by looking at the gitk output.
Also 'git merge-base' can give you that node, given the main branch and
the topic branch. See documentation about git-merge-base.
Then if you need to move a branch to another starting node, then 'git
rebase' is what you need (again the git-rebase documentation is pretty
detailed).
Nicolas
^ permalink raw reply
* Re: [PATCH] Quote ' as \(aq in manpages
From: Anders Kaseorg @ 2009-10-21 18:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <ab31eb03b25272341b91e1f1132dab9d8a49e5b6.1256113282.git.trast@student.ethz.ch>
On Wed, 21 Oct 2009, Thomas Rast wrote:
> The docbook/xmlto toolchain insists on quoting ' as \'. This does
> achieve the quoting goal, but modern 'man' implementations turn the
> apostrophe into a unicode "proper" apostrophe (given the right
> circumstances), breaking code examples in many of our manpages.
>
> Quote them as \(aq instead, which is an "apostrophe quote" as per the
> groff_char manpage.
\(aq is not portable to non-GNU roff. See
http://bugs.debian.org/507673#65
http://sourceforge.net/tracker/index.php?func=detail&aid=2412738&group_id=21935&atid=373747
for a proposed portable solution.
Anders
^ permalink raw reply
* Re: confusion with git diff-tree output
From: Jan Krüger @ 2009-10-21 17:51 UTC (permalink / raw)
To: David Roundy; +Cc: git
In-Reply-To: <117f2cc80910211043q3a92a7b6o15464cc049ee33dc@mail.gmail.com>
> David Roundy <roundyd@physics.oregonstate.edu> wrote:
> I've been struggling with trying to figure out how to make diff-tree
> output the actual files changed. Below is the output when I run
> diff-tree on a given commit. It reports that the directory is
> modified, rather than that a single file within that directory is
> modified.
Tree objects are recursively nested, i.e.
> 66b67ea1763799c0b2ac01f6803177ca870f6544 M Iolaus
is a reference to another tree object... and since a file in that
subtree changed, a new tree object that contains a different file
record is now referenced as "Iolaus".
By default git diff-tree doesn't recurse, but you can use -r for that.
Which is documented, I might add. ;)
Jan
^ permalink raw reply
* confusion with git diff-tree output
From: David Roundy @ 2009-10-21 17:43 UTC (permalink / raw)
To: git
Hi all,
I've been struggling with trying to figure out how to make diff-tree
output the actual files changed. Below is the output when I run
diff-tree on a given commit. It reports that the directory is
modified, rather than that a single file within that directory is
modified. I can find out what *file* was modified by running
diff-tree -p --raw, which gives me output similar to what I expected
from a plain old diff-tree. Is there a flag that will make diff-tree
give this information?
As background, what I really want is --name-only, which rarely reports
the files modified, instead reporting the directories as modified, and
I've been struggling to figure out what is going on. The
documentation seems to imply that the --raw diff output will report
modified files, and I haven't found anything indicating when it would
report the directories containing the modified files instead.
Thanks!
David
$ git diff-tree fd99a198222c14cf42fee82087a13467ff4a8205
fd99a198222c14cf42fee82087a13467ff4a8205
:040000 040000 8cdb796ea801da99c34d8f60045d8eb08fbb0e41
66b67ea1763799c0b2ac01f6803177ca870f6544 M Iolaus
$ git diff-tree fd99a198222c14cf42fee82087a13467ff4a8205 -p --raw
fd99a198222c14cf42fee82087a13467ff4a8205
:100644 100644 dab4c531f3f69f08e5dc202ad8b6dfad9e8855fe
0e3f305e641a6440bb478765dfcd089e0420c155 M Iolaus/Lcs2.hs
diff --git a/Iolaus/Lcs2.hs b/Iolaus/Lcs2.hs
index dab4c53..0e3f305 100644
--- a/Iolaus/Lcs2.hs
+++ b/Iolaus/Lcs2.hs
(changes cut)
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Avery Pennarun @ 2009-10-21 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git, Johannes Schindelin, Jay Soffian
In-Reply-To: <7v7huspjg0.fsf@alter.siamese.dyndns.org>
On Sun, Oct 18, 2009 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> On Sun, Oct 18, 2009 at 10:01, Junio C Hamano <gitster@pobox.com> wrote:
>>> + OPT_SET_INT(0, "nodwim", &dwim_new_local_branch,
>>> + "do not dwim local branch creation", 0),
>>
>> Isn't there a special negation support for --no-something in parse-options?
>
> There probably is, but this is a whetherbaloon patch without documentation
> and pretty much Porcelain only, so I took the lazy route.
>
> Helping hands in polishing it up is very welcome.
I find the idea of an option for "don't do what I mean" to be pretty
entertaining. Or maybe just misleading :)
Have fun,
Avery
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Clemens Buchacher @ 2009-10-21 17:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Daniel Barkalow, Thomas Rast, git
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>
On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:
> For example, I am in favor of deprecating the "pull $there $src:$dst"
> notation. Before we standardized on the separate remote layout, it was
> sometimes handy to be able to use $dst that is a local branch, but these
> days, especially when repository $there has remote.$there.fetch mapping
> configured so that we can compute from $src what remote tracking branch we
> should store the fetched commit, the flexibility is more confusing than it
> is useful.
I emphatically agree. I was always uncomfortable with the refspec syntax,
because it is too flexible. Why would I ever want to access branch refs
other than refs/heads/ on the remote, and why would I ever want to write
directly to the local refs/heads/ namespace (in a non-bare repo), as opposed
to refs/remotes/<name>? Unless he wants to do something unusual, the user
should not be confronted with questions like that.
Clemens
^ permalink raw reply
* [PATCH] modernize fetch/merge/pull examples
From: Clemens Buchacher @ 2009-10-21 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Daniel Barkalow, Thomas Rast, git
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>
The "git pull" documentation has examples which follow an outdated
style. Update the examples to use "git merge" where appropriate and
move the examples to the corresponding manpages.
Furthermore,
o show that pull is equivalent to fetch and merge, which is still a
frequently asked question,
o explain the default fetch refspec.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
On Tue, Oct 20, 2009 at 11:22:16PM -0700, Junio C Hamano wrote:
> For example, I am in favor of deprecating the "pull $there $src:$dst"
> notation.
A first step in that direction.
Clemens
Documentation/git-fetch.txt | 29 +++++++++++++++++++++++++
Documentation/git-merge.txt | 33 +++++++++++++++++++++++++++++
Documentation/git-pull.txt | 49 +++---------------------------------------
3 files changed, 66 insertions(+), 45 deletions(-)
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index d3164c5..c76077d 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -37,6 +37,35 @@ include::pull-fetch-param.txt[]
include::urls-remotes.txt[]
+
+EXAMPLES
+--------
+
+* Update the remote-tracking branches:
++
+------------------------------------------------
+$ git fetch origin
+------------------------------------------------
++
+The above command copies all branches from the remote refs/heads/
+namespace and stores them to the local refs/remotes/origin/ namespace,
+unless the branch.<name>.fetch option is used to specify a non-default
+refspec.
+
+* Using refspecs explicitly:
++
+------------------------------------------------
+$ git fetch origin +pu:pu maint:tmp
+------------------------------------------------
++
+This updates (or creates, as necessary) branches `pu` and `tmp` in
+the local repository by fetching from the branches (respectively)
+`pu` and `maint` from the remote repository.
++
+The `pu` branch will be updated even if it is does not fast-forward;
+the others will not be.
+
+
SEE ALSO
--------
linkgit:git-pull[1]
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index d05f324..2a41d62 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -212,6 +212,39 @@ You can work through the conflict with a number of tools:
common ancestor, 'git show :2:filename' shows the HEAD
version and 'git show :3:filename' shows the remote version.
+
+EXAMPLES
+--------
+
+* Bundle branches `fixes` and `enhancements` on top of
+ the current branch, making an Octopus merge:
++
+------------------------------------------------
+$ git merge fixes enhancements
+------------------------------------------------
+
+* Merge branch `obsolete` into the current branch, using `ours`
+ merge strategy:
++
+------------------------------------------------
+$ git merge -s ours obsolete
+------------------------------------------------
+
+* Merge branch `maint` into the current branch, but do not make
+ a commit automatically:
++
+------------------------------------------------
+$ git merge --no-commit maint
+------------------------------------------------
++
+This can be used when you want to include further changes to the
+merge, or want to write your own merge commit message.
++
+You should refrain from abusing this option to sneak substantial
+changes into a merge commit. Small fixups like bumping
+release/version name would be acceptable.
+
+
SEE ALSO
--------
linkgit:git-fmt-merge-msg[1], linkgit:git-pull[1],
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 7578623..de2bcd6 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -131,54 +131,13 @@ $ git pull origin next
------------------------------------------------
+
This leaves a copy of `next` temporarily in FETCH_HEAD, but
-does not update any remote-tracking branches.
-
-* Bundle local branch `fixes` and `enhancements` on top of
- the current branch, making an Octopus merge:
-+
-------------------------------------------------
-$ git pull . fixes enhancements
-------------------------------------------------
-+
-This `git pull .` syntax is equivalent to `git merge`.
-
-* Merge local branch `obsolete` into the current branch, using `ours`
- merge strategy:
-+
-------------------------------------------------
-$ git pull -s ours . obsolete
-------------------------------------------------
-
-* Merge local branch `maint` into the current branch, but do not make
- a commit automatically:
+does not update any remote-tracking branches. Using remote-tracking
+branches, the same can be done by invoking fetch and merge:
+
------------------------------------------------
-$ git pull --no-commit . maint
+$ git fetch origin
+$ git merge origin/next
------------------------------------------------
-+
-This can be used when you want to include further changes to the
-merge, or want to write your own merge commit message.
-+
-You should refrain from abusing this option to sneak substantial
-changes into a merge commit. Small fixups like bumping
-release/version name would be acceptable.
-
-* Command line pull of multiple branches from one repository:
-+
-------------------------------------------------
-$ git checkout master
-$ git fetch origin +pu:pu maint:tmp
-$ git pull . tmp
-------------------------------------------------
-+
-This updates (or creates, as necessary) branches `pu` and `tmp` in
-the local repository by fetching from the branches (respectively)
-`pu` and `maint` from the remote repository.
-+
-The `pu` branch will be updated even if it is does not fast-forward;
-the others will not be.
-+
-The final command then merges the newly fetched `tmp` into master.
If you tried a pull which resulted in a complex conflicts and
--
1.6.5.1
^ permalink raw reply related
* Re: [RFC] pull/fetch rename
From: Daniel Barkalow @ 2009-10-21 17:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Thomas Rast, git
In-Reply-To: <20091021115740.GA25049@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 12514 bytes --]
On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> On 2009.10.21 00:22:18 -0400, Daniel Barkalow wrote:
> > On Wed, 21 Oct 2009, Björn Steinbrink wrote:
> >
> > > 3) User expects "pull" to update all branch heads that have a configured
> > > upstream
> > >
> > > 08:31 dimsuz hi guys! suppose i'm currently on master. then run git
> > > fetch. which delivers updates to master and other
> > > branches. I don't merge anything, but do checkout some
> > > branch (which is not master). Question: will these new
> > > updates get into this branch automatically after i check
> > > it out? question2: will branch master contain those
> > > updates when i ckeck it out later?
> > > 08:32 Circuitsoft dimsuz. After a fetch, no.
> > > 08:33 Circuitsoft However, if you pull, any branches that were set
> > > up as local tracking branches will get updated.
> > > 08:33 Circuitsoft Otherwise, only remote tracking branches will be
> > > updated.
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-20#l969
> > > (No idea about that one, have seen that once before, but it's definitely
> > > not even remotely as common as the others)
> >
> > I'd guess that's due to having local branches with no local changes, just
> > to avoid detached HEAD, and therefore thinking it's normal to have a bunch
> > of local branches that could be updated without merges. But I'm on a crazy
> > "everybody really wants detached HEAD and is needlessly scared" kick, and
> > I'm probably reading too much into it.
>
> Just to clarify: I didn't mean the question (which I didn't really
> understand) in this case, but the answer from Circuitsoft (second to
> last line). But maybe you also meant that? The question confuses me
> enough not to be able to follow.
Yeah. I think that Circuitsoft, and a lot of the people in these
conversations, have local branches they never commit to, and only update
with pull, and only use the --track feature to maintain these branches,
and may not even ever use "git pull" for anything other than to maintain
these branches. That would give the impression that "git pull" always
leaves the current branch holding the commit that the remote branch is
holding (i.e., "reset --hard") and the guess that this could apply to
non-current branches.
But these local branches don't actually give the users any benefit,
because they're always the same as the ref in remotes/ unless they're
out-of-date.
> > > 4) User expects "pull" to create branches
> > >
> > > 07:25 fynn Hey, I just pulled a branch from remote, and I don't see
> > > it in "git branch"
> > > 07:25 doener fynn: if you "pull" that means "fetch this and merge it
> > > to what I have checked out"
> > > 07:25 fynn doener: hm, I just did "git pull" and it showed the new
> > > branch
> > > 07:26 fynn but I don't see it in my branches...
> > > 07:26 fynn doener: should I create that branch as a tracking branch
> > > first?
> > > 07:26 doener fynn: you're looking at "git branch -r" or "git branch
> > > -a", right?
> > > 07:26 fynn doener: yeah, I'm seeing it in origin/foo, but not
> > > local.
> > > 07:26 doener fynn: the "git fetch" should have created a remote
> > > tracking branch, as usual, not a local branch head
> > > (which would be shown by just "git branch")
> > > 07:27 fynn doener: OK, what should I do to create it locally then?
> > > 07:28 doener fynn: just the usual "git branch foo origin/foo", or to
> > > checkout at the same time: "git checkout -b foo
> > > origin/foo" or "git checkout -t origin/foo" (shortcut)
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-19#l830
> > > (Note how my "fetch this and merge it" is actually inaccurate for just
> > > "git pull", there is no "this" and that case. I took "pulled a branch"
> > > to mean that he did "git pull <remote> <branch>", which wouldn't have
> > > created/update the remote tracking branch [or did patches for that go
> > > in? I lost track...])
> >
> > That sounds like a real converse of "push", including creating like-named
> > local branches. Or, perhaps, this is someone expecting that "pull" is like
> > "clone" in creating an initial local branch with the name and value of a
> > specified remote branch.
>
> Reading that one again, I realize that I've still been confused by the
> "pulled a branch". What happened was that the user did "git pull", which
> ran "git fetch <remote>", which fetched a new branch head and has shown
> that. At that point, the user (and me) got confused for maybe two reasons:
>
> a) He didn't clearly distinguish between the fetch and the merge part.
> The new branch wasn't pulled, but just fetched. That caused the user to
> think that he "pulled the branch" (wrong terminology), which in term
> confused me (wrong use-case assumed).
Right; when pull shows a branch, it's the fetching step. But I think that
shouldn't have been confusing to you; the merging step certainly doesn't
show anything interesting.
> b) He expected local branch heads to be created, instead of remote
> tracking branches. If my memory doesn't play tricks on me, that's
> actually not to be expected from that specific user (I think we told him
> about remote tracking branches before, and the last part of the
> conversation actually suggests that, too). If I don't forget, I'll try
> to get feedback from him the next time he's around.
He seems to get the thing about remote tracking branches (he says that got
created); he's fine on the "pull = fetch + (X)" portion, but he's got (X)
wrong, and thinks that creates a local branch.
That's why I think he may be confused by clone's behavior, because clone
does: (create a repo), fetch something, and create a co-named local
branch. If clone were init + pull (wrong, but a reasonable guess), then
clone - init = fetch + checkout -b; so I think he's not totally lost but
rather just wrong about what compound operations "pull" is.
> > > 5) User possibly expecting "pull" to be able to act as "reset --hard"
> > >
> > > 21:01 aidan What do I do about this: html/config/core.php: needs
> > > update
> > > 21:02 aidan git pull (gives that)
> > > 21:02 Ilari aidan: You have uncommitted changes to that file...
> > > 21:15 aidan Ilari: how can I just pull master and overwrite any
> > > changes?
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-18#l2130
> > > (I'm not sure about that one, "overwrite any changes" might mean "drop
> > > uncommitted changes and merge" or "just get me the remote's state,
> > > dropping my commits and uncommitted changes". Most of the time I've seen
> > > similar requests, the user wanted the latter).
> >
> > So I think that's a desire for "git checkout ." first of all (with the
> > assumption that the content without modifications has to come from
> > somewhere remote). I don't know what's up with people not wanting to save
> > their commits, though.
>
> You haven't seen the multitude of "I have merge conflicts and just want
> to take theirs/mine" requests. That often gets more weird than just
> "drop my commits" ;-)
Ah, okay; I tend to think of those as content-focused, rather than
history-focused. Like, I think people often run into: "I reformatted files
A and B and made important changes to file A; someone else made important
changes to file B; I get a awful merge conflict in file B." I bet it's
common to want to keep your commit history, but throw away their
conflicting changes in the resulting content.
There's also the occasional case where the right solution is to rename a
branch to "things-that-seemed-like-a-good-idea-at-the-time", create a new
branch from upstream with the old name, and never speak of it again.
But this is all a different topic.
> > > 6) User says "pull" but probably means "fetch"
> > >
> > > 14:08 Alien_Freak once I have a clone of a repo I know you can do
> > > a checkout tag but is there anyway to pull just
> > > the tag?
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-16#l1664
> > > (There was no answer, thus it's hard to tell, but I guess he wanted
> > > something like:
> > > git init; git fetch --no-tags url tag <tag>; git checkout <tag>
> > > At least I'm quite sure he didn't mean "pull" as in "git pull")
> >
> > I don't know; you can actually do:
> >
> > $ git init; git pull --no-tags <url> tag <tag>
> >
> > It updates the master branch and working directory from (nothing) to the
> > fetched tag.
>
> Hm, yeah, that works (didn't think of it), but it's a rather special
> case. Teaching that might lead to misunderstandings about what "pull"
> does, I think. It would look somewhat like "fetch + reset --hard".
Well, "merge" looks like "reset --hard" any time it's a fast forward.
I don't think this is a good thing to teach, but if the answer to what the
user wants to do when saying "How can I just pull a tag in a single
command" is "pull tag <foo>", it's hard to say that's a misuse of the
term.
> > > 8) "reset --hard" again
> > >
> > > 20:10 roger_padactor i commited then did a pull how do i get back to
> > > my commit. the pull over wrote the files
> > > 20:11 merlin83 roger_padactor: you can't, pull == fetch + hard
> > > reset to latest commit
> > >
> > > http://colabti.de/irclogger/irclogger_log/git?date=2009-10-14#l2306
> > > (Someone being told that pull is fetch + reset --hard is actually new to
> > > me. Only saw that as an expectation previously.)
> >
> > That's odd. How could you not notice that it doesn't actually do that,
> > even if you try to get it to?
>
> Hm? roger_padactor noticed that "pull" changed his files and wants to go
> back. And merlin83 says that that is impossible because pull supposedly
> does reset --hard. There's nothing in there (I could see) that suggests
> that anyone tried to make "pull" do "reset --hard".
I'm surprised that merlin83 can think that pull = fetch + reset --hard;
people often seem to try to do fetch + reset --hard with pull, but it
doesn't actually work for them.
> merlin83 basically made three mistakes, I think:
> 1) Assume that roger_padactor was talking about uncommitted changes
> 2) Assume that pull is fetch + reset --hard
> 3) Assume that you can't undo a reset --hard for committed changes
>
> (OK, 3) isn't actually valid when you consider 1), but 1) is so invalid
> that I kept 3). After all, "pull" would complain about a dirty tree...)
>
>
> > Actually, I wonder if the right formula is update = fetch + checkout.
> > There are a lot of people (IMHO) want "git fetch origin; git checkout
> > origin/master", and I think their first idea is "git update", but that
> > doesn't exist, and they find "pull" as the closest thing.
>
> That has a precondition that the user is already using a detached HEAD.
> Otherwise that fetch + checkout would likely mean that the get baffled
> when they do:
> git checkout master
> git update
> git checkout foo
> git checkout master
>
> Seeing that "master" is out of date "again".
Agreed; I think:
$ git checkout master
$ git update
You are on a local branch. Local branches are under your complete control,
so there is nowhere to get updates from. If you would like to merge remote
commits into your local branch, you could use "git pull". If you would
rather look at a remote branch, you could use "git checkout <some
plausible remote branch>".
Of course, without this message:
$ git checkout master
$ git update
would be the same as:
$ git chekcout master
$ git fetch
$ git checkout master
which would already not show any changes. (I'm thinking of the target of
the checkout in update-with-no-target as being whatever you typed last
time, and the fetch being whatever fetch normally updates that target.)
Personally, I often run:
$ git fetch; git checkout origin/next
This suggests that this is a useful combination of commands.
> I agree though, that users might look for "git update" and because it is
> missing, they just look for the closest thing. Adding Junio's statement
> that users seem to want recipes instead of flexibility (and seeing
> "update" as just "get me new stuff from upstream" without meaning any
> specific method of updating), I think that "git update" could be a "recipe
> collection" tool. I'll hack that into my proof-of-concept thing (which
> I hope to have ready for a RFC next week).
I'll be interested to see that.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Document the delta attribute
From: Nasser Grainawi @ 2009-10-21 17:11 UTC (permalink / raw)
To: Git Mailing List
After spending a bit of time searching through the pack-objects source
I figured a small blurb of text documenting the existence of this attribute
would be useful.
Feel free to enhance/improve/correct the text.
Nasser
Signed-off-by: Nasser Grainawi <nasser@codeaurora.org>
---
Documentation/gitattributes.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 1195e83..132e7b3 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -577,6 +577,16 @@ If this attribute is not set or has an invalid value, the
value of the
(See linkgit:git-config[1]).
+Packing objects
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+`delta`
+^^^^^^^^^^
+
+Delta compression will not be attempted for files and directories with
+the attribute `delta` unset.
+
+
USING ATTRIBUTE MACROS
----------------------
--
1.6.5
^ permalink raw reply related
* [PATCH v5 7/8] mingw: enable OpenSSL
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-7-git-send-email-kusmabite@gmail.com>
Since we have OpenSSL in msysgit now, enable it to support SSL
encryption for imap-send.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 0d13af3..986483b 100644
--- a/Makefile
+++ b/Makefile
@@ -952,7 +952,7 @@ else
ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 2/8] imap-send: use separate read and write fds
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-2-git-send-email-kusmabite@gmail.com>
This is a patch that enables us to use the run-command
API, which is supported on Windows.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 37 +++++++++++++++++++++++--------------
1 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 8da7a94..7216453 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -151,7 +151,7 @@ struct imap_list {
};
struct imap_socket {
- int fd;
+ int fd[2];
SSL *ssl;
};
@@ -301,8 +301,12 @@ static int ssl_socket_connect(struct imap_socket *sock, int use_tls_only, int ve
ssl_socket_perror("SSL_new");
return -1;
}
- if (!SSL_set_fd(sock->ssl, sock->fd)) {
- ssl_socket_perror("SSL_set_fd");
+ if (!SSL_set_rfd(sock->ssl, sock->fd[0])) {
+ ssl_socket_perror("SSL_set_rfd");
+ return -1;
+ }
+ if (!SSL_set_wfd(sock->ssl, sock->fd[1])) {
+ ssl_socket_perror("SSL_set_wfd");
return -1;
}
@@ -324,11 +328,12 @@ static int socket_read(struct imap_socket *sock, char *buf, int len)
n = SSL_read(sock->ssl, buf, len);
else
#endif
- n = xread(sock->fd, buf, len);
+ n = xread(sock->fd[0], buf, len);
if (n <= 0) {
socket_perror("read", sock, n);
- close(sock->fd);
- sock->fd = -1;
+ close(sock->fd[0]);
+ close(sock->fd[1]);
+ sock->fd[0] = sock->fd[1] = -1;
}
return n;
}
@@ -341,11 +346,12 @@ static int socket_write(struct imap_socket *sock, const char *buf, int len)
n = SSL_write(sock->ssl, buf, len);
else
#endif
- n = write_in_full(sock->fd, buf, len);
+ n = write_in_full(sock->fd[1], buf, len);
if (n != len) {
socket_perror("write", sock, n);
- close(sock->fd);
- sock->fd = -1;
+ close(sock->fd[0]);
+ close(sock->fd[1]);
+ sock->fd[0] = sock->fd[1] = -1;
}
return n;
}
@@ -358,7 +364,8 @@ static void socket_shutdown(struct imap_socket *sock)
SSL_free(sock->ssl);
}
#endif
- close(sock->fd);
+ close(sock->fd[0]);
+ close(sock->fd[1]);
}
/* simple line buffering */
@@ -911,7 +918,7 @@ static void imap_close_server(struct imap_store *ictx)
{
struct imap *imap = ictx->imap;
- if (imap->buf.sock.fd != -1) {
+ if (imap->buf.sock.fd[0] != -1) {
imap_exec(ictx, NULL, "LOGOUT");
socket_shutdown(&imap->buf.sock);
}
@@ -939,7 +946,7 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
ctx = xcalloc(sizeof(*ctx), 1);
ctx->imap = imap = xcalloc(sizeof(*imap), 1);
- imap->buf.sock.fd = -1;
+ imap->buf.sock.fd[0] = imap->buf.sock.fd[1] = -1;
imap->in_progress_append = &imap->in_progress;
/* open connection to IMAP server */
@@ -966,7 +973,8 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
close(a[0]);
- imap->buf.sock.fd = a[1];
+ imap->buf.sock.fd[0] = a[1];
+ imap->buf.sock.fd[1] = dup(a[1]);
imap_info("ok\n");
} else {
@@ -1043,7 +1051,8 @@ static struct store *imap_open_store(struct imap_server_conf *srvc)
goto bail;
}
- imap->buf.sock.fd = s;
+ imap->buf.sock.fd[0] = s;
+ imap->buf.sock.fd[1] = dup(s);
if (srvc->use_ssl &&
ssl_socket_connect(&imap->buf.sock, 0, srvc->ssl_verify)) {
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 8/8] MSVC: Enable OpenSSL, and translate -lcrypto
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Marius Storm-Olsen, Erik Faye-Lund
In-Reply-To: <1256144691-2908-8-git-send-email-kusmabite@gmail.com>
From: Marius Storm-Olsen <mstormo@gmail.com>
We don't use crypto, but rather require libeay32 and
ssleay32. handle it in both the Makefile msvc linker
script, and the buildsystem generator.
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
compat/vcbuild/scripts/clink.pl | 3 +++
contrib/buildsystems/engine.pl | 3 +++
3 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 986483b..1e1a2f2 100644
--- a/Makefile
+++ b/Makefile
@@ -900,7 +900,7 @@ ifdef MSVC
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
NO_PREAD = YesPlease
- NO_OPENSSL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
NO_IPV6 = YesPlease
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index f9528c0..8a2112f 100644
--- a/compat/vcbuild/scripts/clink.pl
+++ b/compat/vcbuild/scripts/clink.pl
@@ -29,6 +29,9 @@ while (@ARGV) {
push(@args, "zlib.lib");
} elsif ("$arg" eq "-liconv") {
push(@args, "iconv.lib");
+ } elsif ("$arg" eq "-lcrypto") {
+ push(@args, "libeay32.lib");
+ push(@args, "ssleay32.lib");
} elsif ("$arg" =~ /^-L/ && "$arg" ne "-LTCG") {
$arg =~ s/^-L/-LIBPATH:/;
push(@args, $arg);
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 20bd061..d506717 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -315,6 +315,9 @@ sub handleLinkLine
$appout = shift @parts;
} elsif ("$part" eq "-lz") {
push(@libs, "zlib.lib");
+ } elsif ("$part" eq "-lcrypto") {
+ push(@libs, "libeay32.lib");
+ push(@libs, "ssleay32.lib");
} elsif ($part =~ /^-/) {
push(@lflags, $part);
} elsif ($part =~ /\.(a|lib)$/) {
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 6/8] mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-6-git-send-email-kusmabite@gmail.com>
SSL_set_fd (and friends) expects a OS file handle on Windows, not
a file descriptor as on UNIX(-ish).
This patch makes the Windows version of SSL_set_fd behave like the
UNIX versions, by calling _get_osfhandle on it's input.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
compat/mingw.h | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 5b5258b..6907345 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -124,6 +124,27 @@ static inline int waitpid(pid_t pid, int *status, unsigned options)
return -1;
}
+#ifndef NO_OPENSSL
+#include <openssl/ssl.h>
+static inline int mingw_SSL_set_fd(SSL *ssl, int fd)
+{
+ return SSL_set_fd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_fd mingw_SSL_set_fd
+
+static inline int mingw_SSL_set_rfd(SSL *ssl, int fd)
+{
+ return SSL_set_rfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_rfd mingw_SSL_set_rfd
+
+static inline int mingw_SSL_set_wfd(SSL *ssl, int fd)
+{
+ return SSL_set_wfd(ssl, _get_osfhandle(fd));
+}
+#define SSL_set_wfd mingw_SSL_set_wfd
+#endif
+
/*
* implementations of missing functions
*/
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 4/8] imap-send: fix compilation-error on Windows
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-4-git-send-email-kusmabite@gmail.com>
mmsystem.h (included from windows.h) defines DRV_OK to 1. To avoid
an error due to DRV_OK redefenition, this patch undefines the old
definition (i.e the one from mmsystem.h) before defining DRV_OK.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
imap-send.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/imap-send.c b/imap-send.c
index 72ed640..69e6142 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -94,6 +94,7 @@ struct msg_data {
unsigned int crlf:1;
};
+#undef DRV_OK
#define DRV_OK 0
#define DRV_MSG_BAD -1
#define DRV_BOX_BAD -2
--
1.6.4.msysgit.0
^ permalink raw reply related
* [PATCH v5 5/8] imap-send: build imap-send on Windows
From: Erik Faye-Lund @ 2009-10-21 17:04 UTC (permalink / raw)
To: git; +Cc: msysgit, Erik Faye-Lund
In-Reply-To: <1256144691-2908-5-git-send-email-kusmabite@gmail.com>
Since the POSIX-specific tunneling code has been replaced
by the run-command API (and a compile-error has been
cleaned away), we can now enable imap-send on Windows
builds.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index fea237b..0d13af3 100644
--- a/Makefile
+++ b/Makefile
@@ -354,6 +354,7 @@ EXTRA_PROGRAMS =
PROGRAMS += $(EXTRA_PROGRAMS)
PROGRAMS += git-fast-import$X
PROGRAMS += git-hash-object$X
+PROGRAMS += git-imap-send$X
PROGRAMS += git-index-pack$X
PROGRAMS += git-merge-index$X
PROGRAMS += git-merge-tree$X
@@ -1075,7 +1076,6 @@ EXTLIBS += -lz
ifndef NO_POSIX_ONLY_PROGRAMS
PROGRAMS += git-daemon$X
- PROGRAMS += git-imap-send$X
endif
ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
--
1.6.4.msysgit.0
^ permalink raw reply related
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