* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jari Aalto, git
In-Reply-To: <7vhbts3285.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Ah, in your defense ;-) I think you looked only at git-fetch.txt without
> checking where else this file is included. Then the patch certainly is
> understandable. It would probably make git-fetch.{1,html} easier to scan,
> while making things not worse for git-pull.{1,html}
Can't we introduce subsections in the OPTIONS section to
group them together, like this (sorry, not a patch)?
OPTIONS
-------
Options related to merging <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::merge-options.txt[]
:git-pull: 1
--rebase::
Instead of a merge, perform a rebase after fetching. If
there is a remote ref for the upstream branch, and this branch
was rebased since last fetched, the rebase uses that information
to avoid rebasing non-local changes. To make this the default
for branch `<name>`, set configuration `branch.<name>.rebase`
to `true`.
+
[NOTE]
This is a potentially _dangerous_ mode of operation.
It rewrites history, which does not bode well when you
published that history already. Do *not* use this option
unless you have read linkgit:git-rebase[1] carefully.
--no-rebase::
Override earlier --rebase.
Options related to fetching <---- added
~~~~~~~~~~~~~~~~~~~~~~~~~~~ <---- added
include::fetch-options.txt[]
include::pull-fetch-param.txt[]
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Daniel Barkalow, Johan Herland, git
In-Reply-To: <20091015204543.GP10505@spearce.org>
Quoting "Shawn O. Pearce" <spearce@spearce.org>
> Actually, after some further research, the bug is not Johan's but is
> actually Daniel's. Johan, I apologize for claiming it was your bug.
> ...
> Long story short, transport_close() is what is supposed to perform
> the work that disconnect_helper does, as its the final thing right
> before we free the struct transport block. Free'ing the data block
> inside of the fetch or push functions is wrong.
>
> Its fine to close the helper and restart it within the single
> lifespan of a struct transport, but dammit, don't free the
> struct helper_data until transport_close().
Ping? Are there any progress on this issue?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given
From: Nanako Shiraishi @ 2009-10-22 10:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Clemens Buchacher, Bjorn Steinbrink, Daniel Barkalow,
Thomas Rast
In-Reply-To: <7vpr8g1l2a.fsf_-_@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Traditionally "git merge --no-commit" meant just that: do not create a new
> commit even when a merge succeeds. But this leads to confusion when the
> merged commit is a descendant of the current commit, in which case we
> succeed the merge by fast-forwarding and without creating a new commit.
> Also when the merged commit is already a part of the history, we succeeded
> without doing anything.
>
> Error out when --no-commit is given but the merge would result in a
> fast-forward or an up-to-date.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> * This is the first alternative. I think it makes more sense than the
> other one, but I am unsure, as I obviously do not get confused when
> --no-commit becomes no-op due to a fast-forward nor an up-to-date and
> am rather happy with the current behaviour.
I think this is good (but I am saying this only from your
description without understanding the updated code), but
the change breaks --squash to merge a branch, doesn't it?
% git checkout feature # from your master branch
% work; git commit; work; git commit
% git checkout master # go back to your master branch
% git merge --squash feature
This is a useful way to clean up changes that were built
in small steps that turned out to be worth only a commit.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-22 9:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, Daniel Barkalow, git
In-Reply-To: <7vk4ypb71j.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > So that's ten days of #git. I left out a bunch of duplications (most
> > were "pull == fetch", "pull == update" and "pull to update
> > non-checked-out branch").
>
> Interesting; this shows that people who do not understand what "pull" does
> expect different behaviour from "pull", use the word "pull" to express
> what they want to happen, expect other people interpret the word to mean
> the way they think it does. At the same time, judging from different
> behaviour expected by these people, push/pull asymmetry does not seem to
> have much to do with the confusion.
This of course is where our conclusions differ. I haven't counted
them, but Björn (thanks again for the excellent survey) points out
that most duplicates are confusion with fetch, (imagined) update or
"update to not checked out branch".
Pull is none of these, but if it was (current) fetch, at least the
first group of people would have had the right idea of what it does.
> I am actually even Ok, at least in the long run (like in 3 years), if we
> were to deprecate the refspecs with colon given on the command line to
> "pull" and "fetch" altogether [*1*].
As an aside, there are actually some use-cases, e.g., to grab the
git-svn refs from a freshly cloned repository you would run:
git fetch origin refs/remotes/*:refs/remotes/*
(and then 'git svn init' etc.) I've also had some weird requests on
IRC that could be solved by clever (and of course dangerous) use of
'git fetch . glob:otherglob'.
Hiding that power behind an option could be a good idea though.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
From: Jari Aalto @ 2009-10-22 9:24 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/merge-options.txt | 79 ++++++++++++++++++++-------------------
1 files changed, 41 insertions(+), 38 deletions(-)
The --option and --no-options have been grouped together as in:
--option
--no-option
The alphabetical order is according to the --option.
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index adadf8e..f1fdb65 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,43 +1,42 @@
--q::
---quiet::
- Operate quietly.
-
--v::
---verbose::
- Be verbose.
+--commit::
+--no-commit::
+ Perform the merge and commit the result. This option can
+ be used to override --no-commit.
---stat::
- Show a diffstat at the end of the merge. The diffstat is also
- controlled by the configuration option merge.stat.
+ With --no-commit perform the merge but pretend the merge
+ failed and do not autocommit, to give the user a chance to
+ inspect and further tweak the merge result before committing.
--n::
---no-stat::
- Do not show a diffstat at the end of the merge.
+--ff::
+--no-ff::
+ Do not generate a merge commit if the merge resolved as
+ a fast-forward, only update the branch pointer. This is
+ the default behavior of git-merge.
---summary::
---no-summary::
- Synonyms to --stat and --no-stat; these are deprecated and will be
- removed in the future.
+ With --no-ff Generate a merge commit even if the merge
+ resolved as a fast-forward.
--log::
+--no-log::
In addition to branch names, populate the log message with
one-line descriptions from the actual commits that are being
merged.
---no-log::
- Do not list one-line descriptions from the actual commits being
- merged.
+ With --no-log do not list one-line descriptions from the
+ actual commits being merged.
---no-commit::
- Perform the merge but pretend the merge failed and do
- not autocommit, to give the user a chance to inspect and
- further tweak the merge result before committing.
---commit::
- Perform the merge and commit the result. This option can
- be used to override --no-commit.
+--stat::
+-n::
+--no-stat::
+ Show a diffstat at the end of the merge. The diffstat is also
+ controlled by the configuration option merge.stat.
+
+ With -n or --no-stat do not show a diffstat at the end of the
+ merge.
--squash::
+--no-squash::
Produce the working tree and index state as if a real
merge happened (except for the merge information),
but do not actually make a commit or
@@ -47,18 +46,9 @@
top of the current branch whose effect is the same as
merging another branch (or more in case of an octopus).
---no-squash::
- Perform the merge and commit the result. This option can
- be used to override --squash.
---no-ff::
- Generate a merge commit even if the merge resolved as a
- fast-forward.
-
---ff::
- Do not generate a merge commit if the merge resolved as
- a fast-forward, only update the branch pointer. This is
- the default behavior of git-merge.
+ With --no-squash perform the merge and commit the result. This
+ option can be used to override --squash.
-s <strategy>::
--strategy=<strategy>::
@@ -67,3 +57,16 @@
If there is no `-s` option, a built-in list of strategies
is used instead ('git-merge-recursive' when merging a single
head, 'git-merge-octopus' otherwise).
+
+--summary::
+--no-summary::
+ Synonyms to --stat and --no-stat; these are deprecated and will be
+ removed in the future.
+
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
--
1.6.4.3
^ permalink raw reply related
* Re: [PATCH] Documentation/fetch-options.txt: order options alphabetically
From: Jari Aalto @ 2009-10-22 9:23 UTC (permalink / raw)
To: git
In-Reply-To: <7vhbts3285.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think you looked only at git-fetch.txt without
> checking where else this file is included. Then the patch certainly is
> understandable. It would probably make git-fetch.{1,html} easier to scan,
> while making things not worse for git-pull.{1,html}
Yes. Unfortunately there doesn't seem to be a way to arrange all nicely,
so perhaps you could accept the following patch to accompany with it. At
least there would be ordered "git-fetch" and semi ordered "git-pull".
Subject: [PATCH] Documentation/merge-options.txt: order options in alphabetical groups
Jari
^ permalink raw reply
* Re: [PATCH] modernize fetch/merge/pull examples
From: Thomas Rast @ 2009-10-22 8:51 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Junio C Hamano, Björn Steinbrink, Daniel Barkalow, git
In-Reply-To: <20091021172123.GB27495@localhost>
Clemens Buchacher wrote:
> 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.
I think this is a good change independently of the deprecation.
> +------------------------------------------------
> +$ git fetch origin +pu:pu maint:tmp
> +------------------------------------------------
[...]
> +The `pu` branch will be updated even if it is does not fast-forward;
> +the others will not be.
I think to a new user it is not immediately clear if this means "will
not be updated, period" or "will not be updated if ...". How about
The `pu` branch will always be updated; the `tmp` branch only if it
is a fast-forward update.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Jakub Narebski @ 2009-10-22 8:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Giuseppe Bilotta, Mark Rada, Stephen Boyd, Nick Edelen,
Nguyen Thai Ngoc Duy
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * gb/maint-gitweb-esc-param (2009-10-13) 1 commit.
> (merged to 'next' on 2009-10-14 at 105f997)
> + gitweb: fix esc_param
> (this branch is used by sb/gitweb-link-author.)
Good. Beside fixing excaping of multibyte Unicode characters this
also finally makes gitweb use '+' and not '%20' to encode space ' '
in CGI parameters.
This reminds me that gitweb really should do conversion / marking data
as UTF-8 _on input_, to avoid situations where output is mangled
because of problems with Unicode. That goes to my gitweb's TODO.
> * mr/gitweb-snapshot (2009-09-26) 2 commits.
> - gitweb: append short hash ids to snapshot files
> (merged to 'next' on 2009-10-11 at 22ba047)
> + gitweb: check given hash before trying to create snapshot
>
> I lost track of the discussion around the tip commit. The bottom one may
> better go to 'master' regardless.
The tip commit should be fixed before accepting. There are some
problems with it as it is now:
* $hash parameter is abused to hold version suffix of snapshot
filename (and archive prefix), e.g. 'next-ae4ab03'; it really
should be done using separate variable, and perhaps even separate
subroutine which would generate snapshot name.
* I don't think it works with fully qualified refnames that gitweb
itself generate, e.g. 'refs/heads/next' or 'refs/tags/v1.6.0',
nor with hierarchical branch names such as 'mr/gitweb-snapshot';
snapshot name can't include '/', and prefix shouldn't include '/'
* when new test is running with --debug option, it dumps whole output
of gitweb for 'snapshot' action, which includes *binary data*, and
not only HTTP headers like it should (at least in first version).
> * sb/gitweb-link-author (2009-10-15) 1 commit
> - gitweb: linkify author/committer names with search
>
> Soon in 'next'.
Is this version that uses title attribute to show that this link is
different in that it leads to search results, not an action view?
> * jn/gitweb-blame (2009-09-01) 5 commits.
> - 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
>
> Ajax-y blame. Probably the first three should go to 'master' by now?
The first three makes fairly 'invisible' change, but introduce
possibility of using JavaScript in gitweb. I'd like more testing with
different browsers than mine, but corrections if any can be done
in-tree.
The "Create links" patch is not ready yet.
> * rs/pretty-wrap (2009-10-17) 1 commit
> - Implement wrap format %w() as if it is a mode switch
> (this branch uses js/log-rewrap; is related to jc/strbuf-nested-expand.)
>
> When it comes to design issues to keep unnecessary complexity out, I tend
> to trust Rene (and Nico) a lot more than I trust myself. Tonight's 'pu'
> queues this series instead of my "nested" one.
> * jc/strbuf-nested-expand (2009-10-18) 3 commits
> . Teach --wrap to only indent without wrapping
> . Add %[wrap(width,in1,in2)<<any-string>>%] implementation
> . strbuf_nested_expand(): allow expansion to interrupt in the middle
> (this branch uses js/log-rewrap; is related to rs/pretty-wrap.)
>
> Ejected from 'pu' to let rs/pretty-wrap in as described above.
I think nested expand is easier to use than a mode switch: using
scoping (well, kind of) like in high-level programming languages is
IMVHO easier than programming a state machine like in assembler (or
e.g. OpenGL).
On the other hand this makes pretty format into a mini-language; also
we already have and use mode switches in the form of color codes.
Perhaps if color also used wrapping / nested expand, so one doesn't
have to track where to turn off and on which toggle...
> * jg/log-format-body-indent (2009-09-19) 1 commit.
> . git-log --format: Add %B tag with %B(x) option
...and this was yet another alternate solution (less generic, though)
> * jc/pretty-lf (2009-10-04) 1 commit.
> - Pretty-format: %[+-]x to tweak inter-item newlines
I understand that %a%+b expands to %a%n%b if %b has non-empty
expansion, and to %a if %b is empty, but what %-b is used for?
> * js/log-rewrap (2008-11-10) 2 commits
> - Add strbuf_add_wrapped_text() to utf8.[ch]
> - print_wrapped_text(): allow hard newlines
> (this branch is used by jc/strbuf-nested-expand and rs/pretty-wrap.)
>
> Soon in 'next'; regardless of how wrapping is exposed to --pretty=format,
> this code will be used, and it seems to be leak-free and reasonably done.
>
> We _might_ want to cherry-pick the tip of jc/strbuf-nested-expand to this
> series, though.
> --------------------------------------------------
> [Cooking]
>
> * 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
>
> Still unstable? Has an extra test squashed in; tonight's 'pu' does not
> pass tests.
BTW. I would really prefer if this series was send with cover letter
explaining series and perhaps differences from previous version of
series as a whole (reordering, splitting and joining patches, new
patches etc.), and individual patches in series replies to this cover
letter, without 'Re: ' prefix in subject, and with explanation of the
difference from previous version (if any) in the commentary area.
> * nd/sparse (2009-08-20) 19 commits.
> - 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
Hmmm... what is happening with that series?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Stephen Boyd @ 2009-10-22 8:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kirill Smelkov, Shawn O. Pearce
In-Reply-To: <7veiovly35.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * ks/precompute-completion (2009-10-05) 1 commit.
> (merged to 'next' on 2009-10-14 at adf722a)
> + Speedup bash completion loading
>
> Are people happy with this?
No. I now have rebase.sh, am.sh, etc. in my completion because of how
git help -a fully lists git commands in libexec and elsewhere in my
$PATH (which gets pointed to my build directory during make).
It's late and I'm tired, but I think we can just ignore files ending in
*.sh, *.perl, etc.
diff --git a/contrib/completion/git-completion.bash.generate b/contrib/completion/git-completion.bash.generate
index 33b1d1d..6487fd5 100755
--- a/contrib/completion/git-completion.bash.generate
+++ b/contrib/completion/git-completion.bash.generate
@@ -24,6 +24,7 @@ __git_all_commands ()
do
case $i in
*--*) : helper pattern;;
+ *.sh|*.perl) : build scripts;;
*) echo $i;;
esac
done
^ permalink raw reply related
* Re: Finding a commit
From: Soham Mehta @ 2009-10-22 8:32 UTC (permalink / raw)
To: git
Thanks for all the answers! Sorry for the delayed reply.
Like Douglas Campos suggested, git-cherry (which uses git-patch-id like
Thomas Rast suggests) works for me. Here is what I tried:
from first repo$: git fetch second-repo
from first repo$: git cherry -v second-repo/branch-in-question sha1 sha1^
- sha1 <commit message>
Outputs the sha1 with a minus sign in front, which means the change is
already present in second-repo/branch-in-question, and is what I expect.
-Soham
thus spake Daniele Segato , On 10/21/2009 6:55 AM:
> On Wed, Oct 21, 2009 at 2:37 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>
>>> Commit -> Tree ---> Blob1, Blob2, Blob3
>>>
>>> Commit, Trees and Blobs are all identified by sha1
>>> the commit should keep information on the author, the "parent"
>>> commit(s) and so on..
>>> the tree should just keep the "snapshot" of the data..
>>>
>>> so I think that if you search for the SHA-1 of the tree you should be fine..
>>>
>> Not if you really want to find out if X was cherry-picked into this
>> repository, because the tree is the *final state* at that commit,
>> which of course includes all preceding changes.
>>
>> So suppose you have two patches A.diff and B.diff introducing files of
>> the same name; then if you combine them into history as
>>
>> A -- B
>>
>> the tree state at B has both files, and hence is different from the
>> tree state of B' in
>>
>> B' -- A'
>>
>> because there it only has the file B.
>>
>
> Yes... obviously...
> the tree is the snapshot of a complete data set: so if you apply the
> same patch to different data set you get different trees...
> thanks for pointing it out.. :)
>
> Regards,
> Daniele
>
^ permalink raw reply
* Re: [PATCH v2 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-10-22 8:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <200910221005.11813.trast@student.ethz.ch>
Thomas Rast schrieb:
> Well, I just observed while writing the patch that you cannot say
>
> git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
Please include this in the commit message.
> Johannes Sixt wrote:
>> Thomas Rast schrieb:
>>> @@ -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
>> At this point $non_ref_args might contain one or more IFS-separatable
>> words, but if you say "$non_ref_args" here, this loop will be entered
>> exactly once. But even if you drop the dquotes, the --sq quoting that you
>> requested from rev-parse bought you nothing.
>
> Hrm. Ok, so the ".." were clearly in mistake, but why could I remove
> the --sq? Doesn't the shell expand the arguments provided by
> $non_ref_args if I use it without quotes nor --sq, so that it might
> accidentally expand paths or such?
When the shell expands $variable (outside quotes), it does not apply
quotes anymore, but only word-splits using $IFS. In your code, the words
would contain literal single-quotes, and paths with spaces would still be
split into words.
Wouldn't it be sufficient to just check whether any non-rev arguments are
present, and to suppress '--' if there are, like:
dashdash=
test -z "$(git rev-parse --no-revs "$@")" && dashdash=--
OK, this still leaves you with the problem that you want to separate
non-rev arguments from rev arguments. Right?
For this I suggest that you extract revs into a regular variable (because
the SHA1s can be word-split in a predictable way), and that you leave the
non-rev arguments in $@:
revs=$(git rev-parse --revs "$@") # don't know if this works
eval set -- "$(git rev-parse --no-revs --sq "$@")" # dquotes?
or so... This way you 'eval' should not be needed in later code.
-- Hannes
^ permalink raw reply
* Re: keeping track of where a patch begins
From: Thomas Rast @ 2009-10-22 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, E R, git, Jeff King
In-Reply-To: <7veiow4iqc.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> 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. [...]
>
> (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. [...]
>
> (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. [...]
I think this not only changes the model of branches, but also commits,
to some extent. Currently, commit have no intrinsic branch
membership; if you say
git branch foo bar
you cannot distinguish whether the commits on 'bar' were created on
'foo' or on 'bar'. (By git's means; of course the decision would
favour 'master' if I had used that instead.)
Technically your proposal does not change this fact very much; it is
still possible to create "clones" of branches that are
indistinguishable. However, to the *user* I think we would create a
notion that "a commit belongs to one specific branch", in that, during
the course of normal operations, a commit will end up on exactly one
git rev-list --first-parent base..branch
range.
(Not sure if I consider this as an argument in favour or against yet,
but I wanted to point it out anyway.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH v3] Quote ' as \(aq in manpages
From: Thomas Rast @ 2009-10-22 8:19 UTC (permalink / raw)
To: git; +Cc: Anders Kaseorg, Miklos Vajna, Junio C Hamano, bill lam
In-Reply-To: <alpine.DEB.2.00.0910211824220.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.
Thanks also to Miklos Vajna for documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Anders Kaseorg wrote:
> On Wed, 21 Oct 2009, Junio C Hamano wrote:
> > > +# Define GNU_ROFF if you have GNU roff and you don't want to have pretty
> > > +# apostrophe so that cut&pasting examples to the shell will work.
> >
> > This makes it sound as if groff is the only roff implementation that has
> > this problem---iow, if we use non-GNU roff then the documentation comes
> > out just fine. Is that the case?
>
> Yes:
I'll take your word for it, but I cannot test with anything non-GNU.
> In order to build a manpage that can be viewed correctly on both
> platforms, the conditional logic should live in the manpage itself (as per
> the bug comments I linked to and Thomas quoted from).
I reworded Miklos' doc patch a bit to indicate that it's about the
target system, and also added a slightly longer comment to the
Documentation/Makefile for completeness.
Documentation/Makefile | 8 ++++++++
Documentation/manpage-quote-apos.xsl | 16 ++++++++++++++++
Makefile | 4 ++++
3 files changed, 28 insertions(+), 0 deletions(-)
create mode 100644 Documentation/manpage-quote-apos.xsl
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 06b0c57..cd5b439 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -103,6 +103,14 @@ ifdef DOCBOOK_SUPPRESS_SP
XMLTO_EXTRA += -m manpage-suppress-sp.xsl
endif
+# If your target system uses GNU groff, it may try to render
+# apostrophes as a "pretty" apostrophe using unicode. This breaks
+# cut&paste, so you should set GNU_ROFF to force them to be ASCII
+# apostrophes. Unfortunately does not work with non-GNU roff.
+ifdef GNU_ROFF
+XMLTO_EXTRA += -m manpage-quote-apos.xsl
+endif
+
SHELL_PATH ?= $(SHELL)
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
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>
diff --git a/Makefile b/Makefile
index fea237b..2ccbe4a 100644
--- a/Makefile
+++ b/Makefile
@@ -159,6 +159,10 @@ all::
# Define ASCIIDOC_NO_ROFF if your DocBook XSL escapes raw roff directives
# (versions 1.72 and later and 1.68.1 and earlier).
#
+# Define GNU_ROFF if your target system uses GNU groff. This forces
+# apostrophes to be ASCII so that cut&pasting examples to the shell
+# will work.
+#
# Define NO_PERL_MAKEMAKER if you cannot use Makefiles generated by perl's
# MakeMaker (e.g. using ActiveState under Cygwin).
#
--
1.6.5.1.144.g316236
^ permalink raw reply related
* Re: [PATCH v2 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Thomas Rast @ 2009-10-22 8:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4ADFF66F.1080005@viscovery.net>
Johannes Sixt wrote:
> Thomas Rast schrieb:
> > 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).
>
> I understand that this is a preparatory patch, but you seem to argue that
> even without the follow-up patch there is a problem. But from your
> explanation I do not understand what it is. An example invocation that
> shows the problem would be very helpful.
Well, I just observed while writing the patch that you cannot say
git filter-branch --subdirectory-filter subdir -- --all -- subdir/file
because the --subdirectory-filter supplies its own -- to the rev-list
invocation, i.e., it calls
git rev-list --all -- subdir/file -- subdir
which filters for a file called --.
I doubt anyone ever needed this operation though, and it can easily be
done in two separate filtering steps.
> > @@ -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
>
> At this point $non_ref_args might contain one or more IFS-separatable
> words, but if you say "$non_ref_args" here, this loop will be entered
> exactly once. But even if you drop the dquotes, the --sq quoting that you
> requested from rev-parse bought you nothing.
Hrm. Ok, so the ".." were clearly in mistake, but why could I remove
the --sq? Doesn't the shell expand the arguments provided by
$non_ref_args if I use it without quotes nor --sq, so that it might
accidentally expand paths or such?
> > + if test arg = --; then
>
> Did you mean $arg here? Even then this test will succeed only if
> $non_ref_args contains exactly one word and that word is '--'. Is that
> what you mean?
No, it should find a -- argument to see if we need to supply our own
before the $filter_subdir.
> This looks so convoluted; there must be a simpler way to achieve your goal.
I'll try with more 'case's later... maybe I can at least avoid the
eval.
Thanks for your comments!
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Martin Langhoff @ 2009-10-22 8:01 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: newsgroups, git
In-Reply-To: <200909272001.48180.robin.rosenberg.lists@dewire.com>
On Sun, Sep 27, 2009 at 8:01 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> söndag 27 september 2009 14:24:32 skrev Anteru <newsgroups@catchall.shelter13.net>:
>> Mercurial's revision number system: With git, I get an SHA1 hash for
>> every commit, but it's not possible to see whether Hash1 is newer than
>> Hash2, while Mecurial also adds a running number to each commit. What's
>
> But those numbers cannot be communicated since they are local to your
> clone.
You can use git-describe, which will look for the latest tag, and make
a combo of latest tag, commits since the tag, short form of sha1. So
you get "v1.6.3-33-g1234" - 33 commits after 1.6.3. Works very well to
integrate in versioning. The git project itself uses it in the
Makefile to set the versions, same as the kernel folk do -- I use it
to version even RPM/DEBs.
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Anteru @ 2009-10-22 7:35 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910220012r6d53f759u374a69d41dc4a4db@mail.gmail.com>
Dilip M schrieb:
> Surprised to know. I was expecting hg or GIT :)
Yeah, me too, actually, Bzr was no contender at first.
> Do you mind to share the checks done / piloting done while choosing
> Bzr over GIT or HG
>
> I bet, it is useful for many ppl in this list too.
I'm going to blog about this, in the hope that it will help more people
who want to switch away from SVN. I'm not so sure whether sending it
here will help, because in order to be fair, I would have to send the
same to the Bzr and Hg mailing lists, and this is a sure recipe for a
flame-war :)
Cheers,
Anteru
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Dilip M @ 2009-10-22 7:12 UTC (permalink / raw)
To: newsgroups; +Cc: git
In-Reply-To: <4AE000B7.4090708@shelter13.net>
On Thu, Oct 22, 2009 at 12:20 PM, Anteru <Anteru@shelter13.net> wrote:
> Bzr, it has even better SVN interop, works the same across all
> platforms, performance-wise, Bzr 2.x turned out to be more than
> sufficient and the UI tools are quite polished.
>
> Thanks for all the comments on Git and Hg!
Surprised to know. I was expecting hg or GIT :)
Do you mind to share the checks done / piloting done while choosing
Bzr over GIT or HG
I bet, it is useful for many ppl in this list too.
--
Dilip
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Erik Faye-Lund @ 2009-10-22 7:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nanako Shiraishi, Avery Pennarun, Junio C Hamano, Alex Riesen,
git, Jay Soffian
In-Reply-To: <alpine.DEB.1.00.0910220226270.4985@pacific.mpi-cbg.de>
On Thu, Oct 22, 2009 at 2:27 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> My take on it:
>
> 1) --no-porcelain
>
> 2) we all are bike-shedding, not being constructive at all
In that case, I propose "--yellow".
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Deciding between Git/Mercurial
From: Anteru @ 2009-10-22 6:50 UTC (permalink / raw)
To: Dilip M; +Cc: git
In-Reply-To: <c94f8e120910211938v3cc7991en3c385fc2f98b28a3@mail.gmail.com>
Dilip M schrieb:
> Hi Anteru,
>
> On Sun, Sep 27, 2009 at 5:54 PM, Anteru wrote:
>
> ..snip..
>
>> So far, my key arguments are that git is more robust (more projects using
>> it, larger developer base), of course git's excellent performance and the
>> much better support for SVN, which is important for us as we can slowly
>> migrate from SVN->Git, while hgmercurial is still in the making (and
>> Python's SVN->Hg switch is for instance waiting for it).
>
> So finally which you choosed? Just curious?
Bzr, it has even better SVN interop, works the same across all
platforms, performance-wise, Bzr 2.x turned out to be more than
sufficient and the UI tools are quite polished.
Thanks for all the comments on Git and Hg!
Cheers,
Anteru
^ permalink raw reply
* What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Junio C Hamano @ 2009-10-22 6:52 UTC (permalink / raw)
To: git
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 planeed 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
--------------------------------------------------
[Graduated to "master"]
* gb/maint-gitweb-esc-param (2009-10-13) 1 commit.
(merged to 'next' on 2009-10-14 at 105f997)
+ gitweb: fix esc_param
(this branch is used by sb/gitweb-link-author.)
--------------------------------------------------
[New Topics]
* vl/git-gui (2009-10-16) 1 commit.
- git-gui: adjust the minimum height of diff pane for shorter screen height
Shawn?
* cb/doc-fetch-pull-merge (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-21 at 1d9190d)
+ modernize fetch/merge/pull examples
* ja/fetch-doc (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-21 at bf09f62)
+ Documentation/fetch-options.txt: order options alphabetically
Helps 'git-fetch.{1,html}' without helping 'git-pull.{1,html}'.
* jc/1.7.0-no-commit-no-ff-2 (2009-10-21) 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. I haven't described this at the beginning of this message
yet, as it is not clear if this is even necessary, but since I already
wrote it and many people seem to be interested in UI and behaviour
warts,...
Some tests expect the traditional behaviour of silently ignoring --no-commit
upon fast-forward, and tonight's 'pu' does not pass them.
* jc/1.7.0-no-commit-no-ff (2009-10-21) 1 commit.
. git-merge: imply --no-ff when --no-commit is given
This is an alternative patch to the same issue.
* jc/fsck-default-full (2009-10-20) 1 commit
(merged to 'next' on 2009-10-21 at 1375192)
+ fsck: default to "git fsck --full"
Should be safe enough to be in 'master' soon.
* jc/maint-fix-unpack-zlib-check (2009-10-21) 1 commit.
- Fix incorrect error check while reading deflated pack data
This is the final round from 2009-10-21, not my earlier botched attempts.
* jc/receive-pack-auto (2009-10-20) 2 commits.
(merged to 'next' on 2009-10-21 at fef13ef)
+ receive-pack: run "gc --auto --quiet" and optionally "update-server-info"
+ gc --auto --quiet: make the notice a bit less verboase
* jp/dirty-describe (2009-10-21) 1 commit.
- Teach "git describe" --dirty option
Ack?
* tr/filter-branch (2009-10-21) 2 commits.
- filter-branch: nearest-ancestor rewriting outside subdir filter
- filter-branch: stop special-casing $filter_subdir argument
J6t already has some comments on this.
* tr/maint-roff-quote (2009-10-21) 2 commits.
- Document GNU_ROFF in Makefile
- Quote ' as \(aq in manpages
The doc may need to be clarified a bit more.
* bg/clone-doc (2009-10-20) 1 commit.
(merged to 'next' on 2009-10-21 at 3016736)
+ git-clone.txt: Fix grammar and formatting
Should be correct enough to be in 'master' soon.
* iv/tar-lzma-xz (2009-10-20) 1 commit.
(merged to 'next' on 2009-10-21 at cb0df8a)
+ import-tars: Add support for tarballs compressed with lzma, xz
Should be safe enough to be in 'master' soon.
* rs/pretty-wrap (2009-10-17) 1 commit
- Implement wrap format %w() as if it is a mode switch
(this branch uses js/log-rewrap; is related to jc/strbuf-nested-expand.)
When it comes to design issues to keep unnecessary complexity out, I tend
to trust R辿ne (and Nico) a lot more than I trust myself. Tonight's 'pu'
queues this series instead of my "nested" one.
* sr/blame-incomplete (2009-10-19) 1 commit.
- blame: make sure that the last line ends in an LF
I think this is _good enough_ as-is; although it would be better if we
added some hint to the output for Porcelain implementations, that can be
done as a follow-up fix.
--------------------------------------------------
[Stalled]
* mr/gitweb-snapshot (2009-09-26) 2 commits.
- gitweb: append short hash ids to snapshot files
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
I lost track of the discussion around the tip commit. The bottom one may
better go to 'master' regardless.
* db/vcs-helper-rest (2009-09-03) 6 commits.
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
(this branch is used by jh/cvs-helper.)
This holds the remainder of the db/vcs-helper topic that has already
merged in 1.6.5. If people want to replace this with improvements it
would be a good time to do so.
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* 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
* 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"?)
* jh/cvs-helper (2009-08-18) 8 commits.
. More fixes to the git-remote-cvs installation procedure
. Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
. Add simple selftests of git-remote-cvs functionality
. git-remote-cvs: Remote helper program for CVS repositories
. 2/2: Add Python support library for CVS remote helper
. 1/2: Add Python support library for CVS remote helper
. Basic build infrastructure for Python scripts
. Allow helpers to request marks for fast-import
(this branch uses db/vcs-helper-rest.)
* jc/strbuf-nested-expand (2009-10-18) 3 commits
. Teach --wrap to only indent without wrapping
. Add %[wrap(width,in1,in2)<<any-string>>%] implementation
. strbuf_nested_expand(): allow expansion to interrupt in the middle
(this branch uses js/log-rewrap; is related to rs/pretty-wrap.)
Ejected from 'pu' to let rs/pretty-wrap in as described above.
--------------------------------------------------
[Cooking]
* 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
Still unstable? Has an extra test squashed in; tonight's 'pu' does not
pass tests.
* ak/bisect-reset-to-switch (2009-10-13) 1 commit.
- bisect reset: Allow resetting to any commit, not just a branch
Soon in 'next'.
* fc/doc-fast-forward (2009-10-11) 1 commit.
- user-manual: use 'fast-forward'
* jc/maint-1.6.3-graft-trailing-space (2009-10-14) 1 commit.
- info/grafts: allow trailing whitespaces at the end of line
Soon in 'next'.
* jk/maint-cvsimport-pathname (2009-10-19) 1 commit.
(merged to 'next' on 2009-10-19 at 77824f2)
+ cvsimport: fix relative argument filenames
Should be safe enough to be in 'master' soon.
* jn/show-normalized-refs (2009-10-12) 3 commits.
- check-ref-format: simplify --print implementation
- git check-ref-format --print
- Add tests for git check-ref-format
This was for helping Porcelains like git-gui to sanely cope with user
input that has redundant // in refnames. Are potential users happy with
the series? I think this is ready for 'next'.
* sb/gitweb-link-author (2009-10-15) 1 commit
- gitweb: linkify author/committer names with search
Soon in 'next'.
* jc/checkout-auto-track (2009-10-18) 3 commits
- git checkout --no-guess
- DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
- check_filename(): make verify_filename() callable without dying
The final shape of this series ended up to be more or less exactly what
Dscho hinted he wanted to have in one of the discussion. Is everybody
happy with this kind of new user-friendliness? I think it is safe enough
to be queued to 'next'.
* tr/stash-format (2009-10-19) 5 commits
- stash list: drop the default limit of 10 stashes
- stash list: use new %g formats instead of sed
- Introduce new pretty formats %g[sdD] for reflog information
- reflog-walk: refactor the branch@{num} formatting
- Refactor pretty_print_commit arguments into a struct
Soon in 'next'.
* ks/precompute-completion (2009-10-05) 1 commit.
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
Are people happy with this?
* sp/smart-http (2009-10-14) 17 commits
- Smart HTTP fetch: gzip requests
- Smart fetch over HTTP: client side
- Smart push over HTTP: client side
- Discover refs via smart HTTP server when available
- Smart fetch and push over HTTP: server side
- Add stateless RPC options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- Move WebDAV HTTP push under remote-curl
- remote-helpers: Support custom transport options
- remote-helpers: Fetch more than one ref in a batch
- fetch: Allow transport -v -v -v to set verbosity to 3
- remote-curl: Refactor walker initialization
- Add multi_ack_detailed capability to fetch-pack/upload-pack
- Move "get_ack()" back to fetch-pack
- fetch-pack: Use a strbuf to compose the want list
- pkt-line: Make packet_read_line easier to debug
- pkt-line: Add strbuf based functions
What's the doneness of this series?
* ef/msys-imap (2009-10-21) 8 commits.
- MSVC: Enable OpenSSL, and translate -lcrypto
- mingw: enable OpenSSL
- mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
- imap-send: build imap-send on Windows
- imap-send: fix compilation-error on Windows
- imap-send: use run-command API for tunneling
- imap-send: use separate read and write fds
- imap-send: remove useless uid code
Another re-roll. Waiting for an Ack from MSVC folks but otherwise it is
ready for 'next', I think.
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* js/log-rewrap (2008-11-10) 2 commits
- Add strbuf_add_wrapped_text() to utf8.[ch]
- print_wrapped_text(): allow hard newlines
(this branch is used by jc/strbuf-nested-expand and rs/pretty-wrap.)
Soon in 'next'; regardless of how wrapping is exposed to --pretty=format,
this code will be used, and it seems to be leak-free and reasonably done.
We _might_ want to cherry-pick the tip of jc/strbuf-nested-expand to this
series, though.
* js/diff-verbose-submodule (2009-10-14) 2 commits.
- add tests for git diff --submodule-summary
- Add the --submodule option to the diff option family
I should retitle and fix some comments in the tip commit (the tests have
already been adjusted to use the real option name), but otherwise I think
this is ready for 'next'.
* jc/fix-tree-walk (2009-09-14) 10 commits.
- 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
+ unpack_callback(): use unpack_failed() consistently
+ unpack-trees: typofix
+ diff-lib.c: fix misleading comments on oneway_diff()
This is my replacement for Linus's lt/maint-traverse-trees-fix patch. It
is not so much as a counter-proposal; I originally thought it might make
sense to walk the index and drive the walker to return the entries from
trees to match entries from the index, but I ended up doing pretty much
what Linus outlined --- walk the trees, and have the index walker follow
it. It turned out that the index side also needed some hairy look-ahead,
This includes the fix to aggressive mode of three-way merge used by the
resolve strategy.
* jh/notes (2009-10-09) 22 commits.
- 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
- Add selftests verifying concatenation of multiple notes for the same commit
- Refactor notes code to concatenate multiple notes annotating the same object
- Add selftests verifying that we can parse notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- Teach notes code to free its internal data structures on request
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
Rebased so that it does not pull in anything else. Presumably it is ready
for next?
* jn/gitweb-blame (2009-09-01) 5 commits.
- 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
Ajax-y blame. Probably the first three should go to 'master' by now?
* nd/sparse (2009-08-20) 19 commits.
- 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
--------------------------------------------------
[For 1.7.0]
* jk/1.7.0-status (2009-09-05) 5 commits.
- 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".
* 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
* 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 changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* 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
--------------------------------------------------
[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/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* jg/log-format-body-indent (2009-09-19) 1 commit.
. git-log --format: Add %B tag with %B(x) option
^ permalink raw reply
* Re: Introduction and Wikipedia and Git Blame
From: jamesmikedupont @ 2009-10-22 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <ee9cc730910170942p7869d62ra08571948675d696@mail.gmail.com>
Hi all,
I have creates a group here mediawiki-vcs and you are invited to join,
it will be to create a git/vcs backend for the mediawiki.
http://groups.google.com/group/mediawiki-vcs/browse_thread/thread/ad3e0a194c8ac1d5#
Also, I have started to document the git internal structure, with the
idea of a gitbus, a dbus like system for doing rpc calls over git for
expensive and repeatable operations.
http://github.com/h4ck3rm1k3/GitBus
thanks,
mike
^ permalink raw reply
* Re: [PATCH] git-merge: imply --no-ff when --no-commit is given
From: Clemens Buchacher @ 2009-10-22 6:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Björn Steinbrink, Daniel Barkalow, Thomas Rast
In-Reply-To: <7viqe81ktx.fsf_-_@alter.siamese.dyndns.org>
On Wed, Oct 21, 2009 at 02:46:50PM -0700, Junio C Hamano wrote:
> Make --no-commit imply --no-ff; --no-commit is a request by the user to
> tweak the resulting merge and it is clear indication that the user wants
> to have a merge, even if it is an extra one, to futz with.
I think --no-commit makes sense in case of a real merge, because a 3-way
diff can help fix any semantic errors. Apart from that, one can simply do a
regular merge and --amend it later.
In case of a fast-forward merge, there is not going to be a 3-way diff
anyways. So it's pointless to use --no-commit in this case.
I'm therefore in favor of your other proposal, even though it may be
confusing to users who don't understand the difference between n-way and
fast-forward merge. But that's something they will have to learn.
And --no-ff can always be used explicitly.
Clemens
^ permalink raw reply
* Re: [bug][bisected] git-svn with root branches
From: Eric Wong @ 2009-10-22 6:30 UTC (permalink / raw)
To: Daniel Cordero, Adam Brewster; +Cc: git
In-Reply-To: <20091021144113.GA7440@cumin>
Daniel Cordero <theappleman@gmail.com> wrote:
> Hello,
>
> when trying to clone a svn repo with the command-line:
>
> $ git svn clone -b / http://svn.collab.net/repos/svn/
>
> (that is, each folder in the root of the repo should be considered it's
> own branch)
> the clone sometimes[1] fails saying:
>
> ref: 'refs/remotes/' ends with a trailing slash, this is not permitted by git nor Subversion
>
> The offending config is:
> [svn-remote "svn"]
> url = http://svn.collab.net/repos/svn
> branches = /*:refs/remotes/*
>
>
> This used to work in the past; I bisected the bad commit to
>
> commit 6f5748e14cc5bb0a836b649fb8e2d6a5eb166f1d
> Author: Adam Brewster <adambrewster@gmail.com>
> Date: Tue Aug 11 23:14:03 2009 -0400
>
> svn: allow branches outside of refs/remotes
>
>
> Thanks in advance.
Thanks for bisecting it for us!
Reverting the left hand side of these two regexps from Adam's commit
seems to fix the problem.
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..56af221 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1765,7 +1765,7 @@ sub read_all_remotes {
my $use_svm_props = eval { command_oneline(qw/config --bool
svn.useSvmProps/) };
$use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
- my $svn_refspec = qr{\s*/?(.*?)\s*:\s*(.+?)\s*};
+ my $svn_refspec = qr{\s*(.*?)\s*:\s*(.+?)\s*};
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
if (m!^(.+)\.fetch=$svn_refspec$!) {
my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
@@ -1979,7 +1979,7 @@ sub find_ref {
my ($ref_id) = @_;
foreach (command(qw/config -l/)) {
next unless m!^svn-remote\.(.+)\.fetch=
- \s*/?(.*?)\s*:\s*(.+?)\s*$!x;
+ \s*(.*?)\s*:\s*(.+?)\s*$!x;
my ($repo_id, $path, $ref) = ($1, $2, $3);
if ($ref eq $ref_id) {
$path = '' if ($path =~ m#^\./?#);
---
I'm not sure why Adam decided the leading slash needed to be removed for
the git refspec. That said, the globbing/branching code still makes me
want to hide under a rock and I'm generally afraid to touch it.
I'll wait for Adam to chime in since he's braver than I am :)
--
Eric Wong
^ permalink raw reply related
* Re: Wikipedia meets git
From: jamesmikedupont-gM/Ye1E23mwN+BqQ9rBEUg @ 2009-10-22 6:27 UTC (permalink / raw)
To: David Gerard; +Cc: Bernie Innocenti, Wikimedia Foundation Mailing List, git
In-Reply-To: <fbad4e140910211636hd772962x4535ccbda6faa3c7-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Ok,
I have started a google group called mediawiki-vcs
http://groups.google.com/group/mediawiki-vcs
We should just move the discussion there.
Additionaly, I did not name it git, but vcs, for the reason that we
should support multiple backends via a plugin. I am interested in
using git because i think git is great, but others should be free to
use cvs if they feel it is needed.
mike
On Thu, Oct 22, 2009 at 1:36 AM, David Gerard <dgerard-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 2009/10/21 jamesmikedupont-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org <jamesmikedupont-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>:
>
>> most people are working on very small subsets of the data. Very few
>> people will want to have all the data, think about getting all the
>> versions from all the git repos, it would be the same.
>> My idea is for smaller chapters who want to get started easily, or
>> towns, regions to host their own branches of relevant data.
>> Given a world full of such servers, the sum would be great but the
>> individual branches needed at one time would be small.
>
>
> A distributed backend is a nice idea anyway - imagine a meteor hitting
> the Florida data centres ...
>
> And there are third-party users who could benefit from a highly
> distributed backend, such as Wikileaks.
>
> This thread should probably move to mediawiki-l ...
>
>
> - d.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
_______________________________________________
foundation-l mailing list
foundation-l-RusutVdil2icGmH+5r0DM0B+6BGkLq7r@public.gmane.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
^ permalink raw reply
* Re: [PATCH v2 1/2] filter-branch: stop special-casing $filter_subdir argument
From: Johannes Sixt @ 2009-10-22 6:06 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <95535b01e2181d321190c6d93b2834188612a389.1256149428.git.trast@student.ethz.ch>
Thomas Rast schrieb:
> 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.
I understand that this is a preparatory patch, but you seem to argue that
even without the follow-up patch there is a problem. But from your
explanation I do not understand what it is. An example invocation that
shows the problem would be very helpful.
> @@ -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
At this point $non_ref_args might contain one or more IFS-separatable
words, but if you say "$non_ref_args" here, this loop will be entered
exactly once. But even if you drop the dquotes, the --sq quoting that you
requested from rev-parse bought you nothing.
> + if test arg = --; then
Did you mean $arg here? Even then this test will succeed only if
$non_ref_args contains exactly one word and that word is '--'. Is that
what you mean?
> + 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
This looks so convoluted; there must be a simpler way to achieve your goal.
-- Hannes
^ 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