* [PATCH/RFC 2/6] docs: note that status configuration affects only long format
From: Jeff King @ 2009-09-05 8:52 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
The short format does not respect any of the usual status.*
configuration.
Signed-off-by: Jeff King <peff@peff.net>
---
Combined with the --short/--porcelain distinction introduced later in
the series, should short perhaps respect status.relativePaths and
status.submoduleSummary? Which would mean replacing this patch with ones
to make those things work. :)
Documentation/git-status.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index b5939d6..fd71a7a 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -109,13 +109,13 @@ compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
If the config variable `status.relativePaths` is set to false, then all
-paths shown are relative to the repository root, not to the current
-directory.
+paths shown in the long format are relative to the repository root, not
+to the current directory.
If `status.submodulesummary` is set to a non zero number or true (identical
-to -1 or an unlimited number), the submodule summary will be enabled and a
-summary of commits for modified submodules will be shown (see --summary-limit
-option of linkgit:git-submodule[1]).
+to -1 or an unlimited number), the submodule summary will be enabled for
+the long format and a summary of commits for modified submodules will be
+shown (see --summary-limit option of linkgit:git-submodule[1]).
SEE ALSO
--------
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* [PATCH/RFC 1/6] status: typo fix in usage
From: Jeff King @ 2009-09-05 8:50 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905084809.GA13073@coredump.intra.peff.net>
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 6cb0e40..812470e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -975,7 +975,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose),
OPT_BOOLEAN('s', "short", &shortstatus,
- "show status concicely"),
+ "show status concisely"),
OPT_BOOLEAN('z', "null", &null_termination,
"terminate entries with NUL"),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg,
--
1.6.4.2.418.g1a1d3.dirty
^ permalink raw reply related
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 8:48 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090905062846.GD29863@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:
> I see. I still think you may want to improve "commit --dry-run" with a
> plumbing format, though, instead of "git status". Then it would
> automagically support "--amend", as well as other dry-run things (e.g.,
> "git commit --dry-run --porcelain --amend foo.c"). And not having looked
> at the code, I would guess it is a one-liner patch to switch the "output
> format" flag that commit passes to the wt-status.c code.
OK, it was a bit more complex than that. But here is a series which does
a few things. It is still missing a few bits, so is RFC.
These first two are unrelated fixups that I noticed while working.
[1/6]: status: typo fix in usage
[2/6]: docs: note that status configuration affects only long format
These are the --porcelain patches we discussed. The first two are
obviously cleanup.
[3/6]: status: refactor short-mode printing to its own function
[4/6]: status: refactor format option parsing
[5/6]: status: add --porcelain output format
This brings the new formats to "commit --dry-run" to handle your case.
Conceptually, it could come before (or instead) of 4/6 and 5/6, but as
it adds both --short and --porcelain, there is an obvious dependency.
[6/6]: commit: support alternate status formats
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Clemens Buchacher @ 2009-09-05 8:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, SZEDER Gábor, git
In-Reply-To: <7v8wgt98ms.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:02:35AM -0700, Junio C Hamano wrote:
> I personally find "add -u" that defaults to the current directory more
> natural than always going to the root; same preference for "grep".
> Besides, "add -u subdir" must add subdir relative to the cwd, without
> going to the root. Why should "add -u" sans argument behave drastically
> differently?
Sorry for stating the obvious here, but the following commands affect the
entire repository, even though they limit themselves to the current
directory, if passed a '.'.
git commit
git log
git diff
git checkout
git reset
Due to the frequent use of these commands, I believe many users (myself
included) expect "git add" and "git grep" to do the same. AFAICT the
following commands are the only non-plumbing ones that behave differently:
git add -u
git add -A
git grep
So I argue that _that_ is the real inconsistency.
> If "git add -u ../.." (I mean "the grand parent directory", not "an
> unnamed subdirectory") did not work, it would be unexcusable and we would
> want to devise an migration path, but otherwise I do not think it is such
> a big deal.
> I would say the commands that are used to incrementally build
> towards the next commit should be friendly to the practice of limiting the
> scope of the work by chdir.
"git add -u ." is friendly enough. Just like "git commit ." versus "git
commit -a", which is exactly the same concept and should therefore have the
same behavior.
You are assuming that people are in a subdirectory because they want to
limit the scope. But I am usually in a subdirectory for totally
versioning-unrelated reasons. Like running tests in git.git:t/ . I
mistakenly use "git add -u" in there all the time, because I think I don't
have to worry about which directory I'm in. Except in this instance I do.
In any case, I think it is better to have consistent behavior than to try
and read users' minds with defaults.
Clemens
^ permalink raw reply
* What's cooking in git.git (Sep 2009, #01; Sat, 05)
From: Junio C Hamano @ 2009-09-05 8:35 UTC (permalink / raw)
To: git
What's cooking in git.git (Sep 2009, #01; Sat, 05)
--------------------------------------------------
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.
After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change. 1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.
During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.
I will probably do 1.6.5-rc0 this weekend, leaving some topics still
cooking in 'next'.
--------------------------------------------------
[Graduated to "master"]
* lt/approxidate (2009-08-30) 6 commits
(merged to 'next' on 2009-08-30 at e016e3d)
+ fix approxidate parsing of relative months and years
+ tests: add date printing and parsing tests
+ refactor test-date interface
+ Add date formatting and parsing functions relative to a given time
(merged to 'next' on 2009-08-26 at 62853f9)
+ Further 'approxidate' improvements
+ Improve on 'approxidate'
* mr/gitweb-snapshot (2009-08-25) 3 commits
(merged to 'next' on 2009-08-30 at e4edd0b)
+ gitweb: add t9501 tests for checking HTTP status codes
+ gitweb: split test suite into library and tests
+ gitweb: improve snapshot error handling
* tf/diff-whitespace-incomplete-line (2009-08-23) 2 commits.
(merged to 'next' on 2009-08-26 at 4fc7784)
+ xutils: Fix xdl_recmatch() on incomplete lines
+ xutils: Fix hashing an incomplete line with whitespaces at the end
--------------------------------------------------
[New Topics]
* pk/fast-import-tars (2009-09-03) 1 commit
- import-tars: Allow per-tar author and commit message.
* jc/maint-1.6.0-blank-at-eof (2009-09-04) 9 commits.
- diff --color: color blank-at-eof
- diff --whitespace=warn/error: fix blank-at-eof check
- diff --whitespace=warn/error: obey blank-at-eof
- diff.c: the builtin_diff() deals with only two-file comparison
- apply --whitespace: warn blank but not necessarily empty lines at EOF
- apply --whitespace=warn/error: diagnose blank at EOF
- apply.c: split check_whitespace() into two
- apply --whitespace=fix: detect new blank lines at eof correctly
- apply --whitespace=fix: fix handling of blank lines at the eof
--------------------------------------------------
[Stalled]
* jh/notes (2009-08-27) 12 commits.
- Add '%N'-format for pretty-printing commit notes
- Add flags to get_commit_notes() to control the format of the note string
- notes.c: Implement simple memory pooling of leaf nodes
- Selftests verifying semantics when loading notes trees with various fanouts
- Teach the notes lookup code to parse notes trees with various fanout schemes
- 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
I heard the cvs-helper series depends on this one. It seems that the
fan-out strategy is being rethought?
--------------------------------------------------
[Cooking]
* db/vcs-helper (2009-09-03) 16 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
- Use a clearer style to issue commands to remote helpers
- Make the "traditionally-supported" URLs a special case
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper)
* 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)
Builds on db/vcs-helper. There is a re-roll planned.
* pk/fast-import-dirs (2009-09-03) 1 commit
- Add script for importing bits-and-pieces to Git.
With an updated key-value quoting rules, which I haven't carefully looked
at. Aren't there standard libraries to do this sort of thing without us
having to hand-roll these logic every time, I have to wonder...
* 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
- 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. The first part should be in 'next' shortly.
* js/stash-dwim (2009-07-27) 1 commit.
(merged to 'next' on 2009-08-16 at 67896c4)
+ Make 'git stash -k' a short form for 'git stash save --keep-index'
(this branch is used by tr/reset-checkout-patch.)
* tr/reset-checkout-patch (2009-08-18) 10 commits.
(merged to 'next' on 2009-09-03 at d4f2ed7)
+ stash: simplify defaulting to "save" and reject unknown options
(merged to 'next' on 2009-08-27 at d314281)
+ Make test case number unique
(merged to 'next' on 2009-08-18 at e465bb3)
+ tests: disable interactive hunk selection tests if perl is not available
(merged to 'next' on 2009-08-16 at 67896c4)
+ DWIM 'git stash save -p' for 'git stash -p'
+ Implement 'git stash save --patch'
+ Implement 'git checkout --patch'
+ Implement 'git reset --patch'
+ builtin-add: refactor the meat of interactive_add()
+ Add a small patch-mode testing library
+ git-apply--interactive: Refactor patch mode code
(this branch uses js/stash-dwim.)
DWIMmery of the two series tightened for safety. This should be ready for
1.6.5.
* jc/upload-pack-hook (2009-08-28) 2 commits
(merged to 'next' on 2009-08-31 at f9933a5)
+ upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook
+ upload-pack: add a trigger for post-upload-pack hook
* jk/clone-b (2009-08-26) 1 commit
(merged to 'next' on 2009-08-30 at 10a68d1)
+ clone: add --branch option to select a different HEAD
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-08-30 at b6455c2)
+ send-email: confirm on empty mail subjects
The existing tests to covers 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"?)
* jc/mailinfo-scissors (2009-08-26) 5 commits
(merged to 'next' on 2009-08-30 at 5fc6248)
+ mailinfo.scissors: new configuration
+ am/mailinfo: Disable scissors processing by default
+ Documentation: describe the scissors mark support of "git am"
+ Teach mailinfo to ignore everything before -- >8 -- mark
+ builtin-mailinfo.c: fix confusing internal API to mailinfo()
I didn't pick up the patch to simplify the definition of scissors. I do
not have strong opinion on it either way, but the list would hopefully
decide it before too long.
* cc/sequencer-rebase-i (2009-08-28) 15 commits
- rebase -i: use "git sequencer--helper --cherry-pick"
- sequencer: add "--cherry-pick" option to "git sequencer--helper"
- sequencer: add "do_commit()" and related functions working on "next_commit"
- pick: libify "pick_help_msg()"
- revert: libify cherry-pick and revert functionnality
- rebase -i: use "git sequencer--helper --fast-forward"
- sequencer: let "git sequencer--helper" callers set "allow_dirty"
- sequencer: add "--fast-forward" option to "git sequencer--helper"
- sequencer: add "do_fast_forward()" to perform a fast forward
- rebase -i: use "git sequencer--helper --reset-hard"
- sequencer: add "--reset-hard" option to "git sequencer--helper"
- sequencer: add "reset_almost_hard()" and related functions
- rebase -i: use "git sequencer--helper --make-patch"
- sequencer: add "make_patch" function to save a patch
- sequencer: add "builtin-sequencer--helper.c"
Migrating "rebase -i" bit by bit to C.
* sr/gfi-options (2009-09-02) 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
Re-rolled again.
* 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]
* jc/1.7.0-status (2009-08-15) 3 commits
(merged to 'next' on 2009-08-22 at b3507bb)
+ 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"
With this, "git status" is no longer "git commit --preview".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ 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-08-30 at 0623572)
+ diff.c: fix typoes in comments
(merged to 'next' on 2009-08-27 at 81fb2bd)
+ Make test case number unique
(merged to 'next' on 2009-08-02 at 9c08420)
+ 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-08-02 at 38b82fe)
+ 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.
* ar/maint-1.6.2-merge-recursive-d-f (2009-05-11) 2 commits.
. Fix for a merge where a branch has an F->D transition
. Add a reminder test case for a merge with F/D transition
* jc/merge-convert (2009-01-26) 1 commit.
. git-merge-file: allow converting the results for the work tree
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* ps/blame (2009-03-12) 1 commit.
. blame.c: start libifying the blame infrastructure
* pb/tracking (2009-07-16) 7 commits.
. branch.c: if remote is not config'd for branch, don't try delete push config
. branch, checkout: introduce autosetuppush
. move deletion of merge configuration to branch.c
. remote: add per-remote autosetupmerge and autosetuprebase configuration
. introduce a struct tracking_config
. branch: install_branch_config and struct tracking refactoring
. config: allow false and true values for branch.autosetuprebase
Has been ejected from 'pu' for some time, expecting a reroll.
* ne/rev-cache (2009-08-21) 6 commits
. 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
Updated but seems to break upload-pack tests when merged to 'pu'; given
what this series touches, breakages in that area are expected.
May discard if a working reroll comes, to give it a fresh start.
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 8:23 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905080249.GA8801@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I agree that we agreed to disagree. But there is still one open
> question: would you take a patch for a "full-tree" config variable that
> would impact add (and probably grep) for 1.7.0?
Unless there is a simple and sane way for script writers (and by "script",
I do not mean "Porcelain that is supposed to be written using only the
plumbing", but things like scripts you would give to "git bisect run",
which would freely use Porcelains like "git reset" etc.) to defeat the
configuration without much pain, I am fairly negative on adding any
configuration variable of that nature.
We could probably declare "In 1.X.0 everything will be relative to the
root and you have to give an explicit '.' if you mean the cwd".
Three questions:
#1 What are the commands that will be affected, other than "add -u" and
"grep"? Are there others?
#2 Do all the commands in the answer to #1 currently behave exactly the
same when run without any path parameter and when run with a single
'.'?
#3 Do all the commands that are already relative to the root currently
limit their action to the cwd when run with a single '.'?
If the number of commands in the answer to #1 is not too excessive, it is
a plus, but even if it is more than just several, we will be getting
consistency and sanity if #2 and #3 hold. However, if there are even a
single violator in #2 and #3, we would need to fix them first before we
can proceed. And the transition clock starts ticking after everything is
fixed (if such a fix is indeed needed). As usual, I'd prefer to keep the
clock running for at least 6 months, preferrably longer, and during that
time, we may need the usual "You invoked me without any paths, but this
command will start behaving differently in 1.X.0, you have been warned."
A command line option to explicitly ask full-tree can be added anytime
without waiting for 1.7.0. I do not think it will be ready for 1.6.5 but
we can always have 1.6.6 if needed.
^ permalink raw reply
* Re: git+http:// proof-of-concept (not using CONNECT)
From: Eric Wong @ 2009-09-05 8:23 UTC (permalink / raw)
To: Douglas Campos; +Cc: Tony Finch, Constantine Plotnikov, git
In-Reply-To: <ed88cb980908260734x78382052t30d4cdcf07451134@mail.gmail.com>
Douglas Campos <douglas@theros.info> wrote:
> Any news about this approach? I've heard some noise about a CGI
> implementation....
Hi Douglass,
I've been busy with other things. This approach is probably
too limited to get around HTTP-aware proxies to be useful for
non-git:// users anyways.
It also turns out the curl patch that made it into 7.19.6 was still
unsuitable for bidirectional tunneling, looks like I'll have to port
curl over to the curl_multi_* interface to get it working properly
instead...
--
Eric Wong
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 8:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905072017.GA5152@coredump.intra.peff.net>
On Sat, Sep 05, 2009 at 03:20:17AM -0400, Jeff King wrote:
> As I mentioned above, not only is that annoying to use, but the real
> problem is that I _expect_ the other behavior and it silently does the
> opposite of what I want. You can argue that my brain is defective (for
> not remembering, I mean -- we _know_ it's defective in other ways), but
> certainly a config option would be useful to me.
Bah. Even after this long thread, I _still_ forgot. I just now typed
"git add -u" from t/ and got annoyed that my changes in the root weren't
added.
-Peff
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: Jeff King @ 2009-09-05 8:17 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Tim Visher, Git Mailing List
In-Reply-To: <fabb9a1e0909020118m2fe2e6e1g79cc83ce941ac000@mail.gmail.com>
On Wed, Sep 02, 2009 at 10:18:54AM +0200, Sverre Rabbelier wrote:
> On Wed, Sep 2, 2009 at 09:57, Jeff King<peff@peff.net> wrote:
> > 2. Count the commits on each side that are not in the other.
>
> [...]
>
> > You can also do that by parsing the output of:
> > git rev-list --left-right $a...$b --
>
> Perhaps it is useful to introduce a --left-right-count or such?
I'm not opposed to that if it is something a lot of people found useful,
but I am not sure we have established that as the case (I am curious to
hear from Tim what his actual use case is).
-Peff
^ permalink raw reply
* Re: [git-svn] [FEATURE-REQ] track merges from git
From: Eric Wong @ 2009-09-05 8:03 UTC (permalink / raw)
To: Ximin Luo; +Cc: git
In-Reply-To: <4A9565ED.4010608@cam.ac.uk>
Ximin Luo <xl269@cam.ac.uk> wrote:
> Hi,
Hi, sorry for the late reply.
> I'm have 2 separate svn projects from googlecode imported into a single git
> repo. One is a semi-fork of the other, so I thought I'd be able to use git's
> merge feature to repeatedly merge from the mother project (and possibly vice
> versa too).
>
> However, this doesn't happen. I "git pull" and this works fine, but when I "git
> svn dcommit" back into svn, this rewrites my git history and it loses track of
> the merge (and next time I try to pull, the same conflicts appear).
You may want to try the "set-tree" function of git svn instead of
dcommit, it was originally named "commit" back in the day set-tree does
not rewrite any history.
It fell out of favor because you could end up with a lot of non-linear
history making it difficult for sharing diffs with SVN-using cow-orkers.
It is useful if you don't want to share your individual changesets, but
push your work upstream to the SVN repos as one big ugly change.
But if you want a staircase effect in gitk, set-tree can be used to make
individual commits where every change ends up as a merge (and you'll see
two commits for every change you made)
> For now I just have a .git/info/grafts, but this doesn't get exported anywhere,
> so if other people "git svn clone" from svn, or "git clone" from my git repo,
> they don't get the merge information.
>
> It would be nice if git-svn saved the merge info somewhere instead of getting
> rid of it. #git tells me this is impossible at the moment, hence the mail.
> Relevant parts of the convo are pasted below.
It should actually get logged to the unhandled.log file, but right
now I'm not aware of any tools that reads that file (which is designed
to be machine parseable).
> I understand if this is a low priority, but I don't think it would be a major
> PITA to implement (some suggestions are listed in the convo log). And it'd be
> useful for people converting from svn to git.
I've considered stuffing git commit information in SVN properties,
but that information is likely to not even be useful to git users
other than yourself
> Thanks for your time.
>
> X
>
> P.S. please don't troll me.
Don't worry, despite my domain name, it's been a long time since I've
done any real trolling :)
> (17:13:14) infinity0: hi
> (17:13:21) infinity0: i've used git-svn to import two svn repo
> (17:13:23) infinity0: repos*
> (17:13:28) infinity0: and used git to merge the two
> (17:13:45) infinity0: the problem is, when i git-svn dcommit back to svn,
> git-svn rewrites my git history
> (17:13:50) infinity0: and loses the merge i just did
> (17:14:01) offby1: infinity0: of course
> (17:14:04) infinity0: how do i get it to retain knowledge of the merge?
> (17:14:11) offby1: infinity0: you don't. Next questions.
> (17:14:16) infinity0: why not?
> (17:14:29) offby1: svn is incapable of storing a merge, at least in the sense
> that we git people use the term "merge"
I'm not sure if that statement is still true with newer SVN versions;
I still haven't had the time to look too hard at newer SVN features.
On the other hand, SVN could be storing "merges" that git simply can't
track as merges; SVN branches and directories are interchangeable, so
SVN could be merging from places that git isn't tracking at all or
merging individual files.
> (17:14:46) Grum: you should be able to store the result of a merge as a commit
> (17:14:51) offby1: sure
> (17:14:57) infinity0: sure, but why does git-svn have to rewrite my *git*
> history to remove knowledge of the merge?
> (17:15:02) offby1: but not as a "merge commit", whatever that might mean in svn
> (17:15:35) Grum: because it has to be representative of the svn repo after you
> dcommit there obviously
> (17:15:42) offby1: infinity0: it's trying to mirror the svn repository in your
> git repository. I assume the original, un-rewritten commits are still in your
> git repository; they're just not pointed at by any branch. Poke around in the
> reflog; I imagine you'll find 'em in there
> (17:16:09) infinity0: ok, but that's not useful if they're dangling
> (17:16:26) infinity0: it's trying to mirror the svn repo yes... but as you
> said, svn doesn't know about merges
> (17:16:26) ***offby1 idly wonders if it'd be possible for git svn to indeed
> store merge commits, by applying the appropriate svn:mergeinfo properties
Some of should be mappable to git merges, it depends on the project and
the type of merge done. As I said earlier, SVN could be merging
from places git svn doesn't know about and can't track... SVN can
get extremely complicated :<
I'm not sure how widely used that feature is used in the SVN world,
either.
> (17:16:40) infinity0: i read a thread where it says those are different things
> (17:16:41) offby1: infinity0: I suspect you're using git svn for something for
> which it wasn't designed.
> (17:17:17) infinity0: would it be possible, in theory, to have git-svn store
> the git merge information in eg. the same way it stores the git-svn tag in the
> svn commit message
> (17:17:33) Grum: then just use svn?
> (17:17:37) Grum: and a postit?
I don't agree with having git-specific metadata on the SVN side itself.
Often times that git-specific metadata has SHA1s unique to the user that
committed it, so it wouldn't be useful to anyone else unless users are
merging from each others git repos (which is not an easy/natural
workflow if SVN is the mainline). Patch exchange is more
reliable/easier...
I've also worked in places where alternative tools are frowned upon, so
sending git-specific metadata over to SVN should always be optional.
The majority of folks I've worked with on SVN-hosted projects have never
known about my git usage (that is changing as git popularity increases,
however).
> (17:18:01) infinity0: i'm trying to link two separate svn repos together via git
> (17:18:17) Grum: and that is just what offby1 said
> (17:18:30) infinity0: "what" is
> (17:18:40) Grum: I suspect you're using git svn for something for which it
> wasn't designed.
> (17:18:42) infinity0: as you all are saying, git merges and svn "merges" are
> different things
> (17:18:58) infinity0: ok, but it would be possible to make git-svn have this
> functionality? or not
> (17:18:59) offby1: certainly
> (17:19:16) offby1: I fear not, since Eric Wong seems like a smart fella; if it
> were doable, I suspect he'd have done it already.
> (17:19:21) offby1: But then ... who knows, maybe he's busy.
I'm not smart but I am busy :)
Summary of the git svn merge tracking situation:
Mapping git <-> git merges to SVN:
* already doable for the committing user with set-tree,
but makes history ugly for:
a) yourself (with every commit set-tree'd individually)
b) SVN users (single set-tree with the newest commit)
c) all of the above (varying granularity)
* Pushing git metadata to SVN will annoy SVN-only users
* Putting git metadata in SVN may not be useful since SHA1s
may be specific to the user that made that commit.
Mapping SVN <-> SVN merges to SVN via git svn:
* most likely to be doable, they'll become plain SVN <-> SVN merges,
see problems with getting SVN <-> SVN merges back to git, however...
Mapping SVN <-> SVN merges to git:
* SVN can represent merges that git can't, SVN can be/is extremely
complicated when it comes to merges.
* I don't see many projects (I care about) use SVN merge tracking,
which projects actually use it? Maybe it's still too new and
distros/users are behind the upgrade curve...
I've probably missed some, I've been dozing off while replying to
emails...
--
Eric Wong
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <7v3a717rgl.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:58:50AM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I assume you mean "ls-files". I have every once in a while been annoyed
> > by that, but given how infrequently I run ls-files, it is not a big
> > deal. :)
>
> I did mean ls-tree, but I misspelled the name of the escape hatch.
Oh, I never noticed that behavior before. For "ls-files", I think it is
at least a little sane, but it makes no sense whatsoever for ls-tree.
> At this moment (as my brain is not quite functioning), I can only say we
> agreed to disagree what feels more natural here.
I agree that we agreed to disagree. But there is still one open
question: would you take a patch for a "full-tree" config variable that
would impact add (and probably grep) for 1.7.0? You can sleep on it if
you want. ;)
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 7:58 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905072017.GA5152@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I assume you mean "ls-files". I have every once in a while been annoyed
> by that, but given how infrequently I run ls-files, it is not a big
> deal. :)
I did mean ls-tree, but I misspelled the name of the escape hatch.
Try this:
$ cd Documentation
$ git ls-tree HEAD
If I were designing this as a proper plumbing command from scratch, I
wouldn't have given it a cwd behaviour. ls-files is somewhat more
understandable, as it has other cruft relating the work tree, but ls-tree
is worse:
$ cd Documentation
$ git ls-tree origin/html
Whoa??? Yes, it tried to do what "git ls-tree origin/html:Documentation"
would have done if it were unaware of cwd. It's just crazy.
>> If "git add -u ../.." (I mean "the grand parent directory", not "an
>> unnamed subdirectory") did not work, it would be unexcusable and we would
>> want to devise an migration path, but otherwise I do not think it is such
>> a big deal. I would say the commands that are used to incrementally build
>
> As I mentioned above, not only is that annoying to use, but the real
> problem is that I _expect_ the other behavior and it silently does the
> opposite of what I want. You can argue that my brain is defective (for
> not remembering, I mean -- we _know_ it's defective in other ways), but
> certainly a config option would be useful to me.
At this moment (as my brain is not quite functioning), I can only say we
agreed to disagree what feels more natural here.
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 7:25 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <7v8wgt98ms.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> I suspect it is too late to change it due to compatibility issues. OTOH,
>> I think the intent of v1.7.0 is to allow a few small breakages like
>> these. You could always write an RFC patch and generate some discussion;
>> I'm not 100% sure that there are enough people that agree with us to
>> change the default.
>
> The intent of 1.7.0 is to fix usability glitches and warts that everybody
> has long agreed are problematic. People have *just started* discussing
> about this---it is not remotely close to "everybody has long agreed are
> problematic" criteria. It is too late for 1.7.0.
I just wanted to see if I am being fair. Here are the topics that we may
have in 1.7.0.
* jc/1.7.0-push-safety
Prevents gremlin updates from sideways to a repository with a work
tree, that confused countless new people. I've resisted this change
for a long time on the backward compatiblity ground, but it is very
fair to say that it was long agreed that the benefit from the change
far outweigh the donesides of having to say "I do want the old
behaviour" by setting an configuration variable or two.
* jc/1.7.0-send-email-no-thread-default
Defaults multi-message send-email to thread shallowly. This change was
requested by kernel folks for a long time ago, and discussion on-list
resulted in a declaration that unless nobody objects 1.6.2 release
notes will say the default will change in 1.6.3. We did not hear any
objection, but the switchover did not happen ;-).
* jc/1.7.0-status
Everybody hated that "status $args" being "commit --dry-run $args"
since 1.4.0 days. We will give "commit --dry-run $args" in 1.6.5.
* jc/1.7.0-diff-whitespace-only-status
We said "diff -w" only affects the appearance but not the exit code, so
"diff -w --exit-code" never returned success if there were only
whitespace changes. It was noticed to be illogical since day one
of the introduction of --exit-code, but we simply did not bother to fix
the implementation of -b and -w, since the combination of these two
options were thought to be unlikely, and we were simply lazy ;-)
I think the first three are clearly 1.7.0 candidates, judging from the
benefit/downside perspective and also from the escape-hatch perspective,
The last one is probably less so, but on the other hand it is of far
lessor impact that we could even roll it out as a bugfix on 'maint'.
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <7v8wgt98ms.fsf@alter.siamese.dyndns.org>
On Sat, Sep 05, 2009 at 12:02:35AM -0700, Junio C Hamano wrote:
> The intent of 1.7.0 is to fix usability glitches and warts that everybody
> has long agreed are problematic. People have *just started* discussing
> about this---it is not remotely close to "everybody has long agreed are
> problematic" criteria. It is too late for 1.7.0.
What about a config option that could change the behavior? True, the
time-frame for discussion is much shorter, but we are not proposing to
make a change that would affect users who do not agree to it. And I
think the point of giving a long time-frame for discussion is to let
people decide whether a change that users do not agree to may affect
them in a bad way.
The real danger here is that users of the config option may be breaking
an interface that is used by scripts. But I feel that 1.7.0 is probably
the best time in the forseeable future to do that, as script-writers
already must be wary of the version change.
> I personally find "add -u" that defaults to the current directory more
> natural than always going to the root; same preference for "grep".
> Besides, "add -u subdir" must add subdir relative to the cwd, without
> going to the root. Why should "add -u" sans argument behave drastically
> differently?
I agree that there is a certain consistency to the current behavior. But
I also find it terribly annoying, because I _always_ want it to do the
other thing, and it silently accepts the command without even telling
me, leaving me to find out ten minutes later that what I thought was
added was not ("git add", by contrast, yells at you in the same
situation).
I also happen to prefer the other behavior because it is easy to switch
the two options: "git add -u" versus "git add -u .", whereas with
current behavior I am stuck calculating (and typing) the correct number
of "../" markers.
But I respect the fact that even if we had infinite time for discussion,
there would be people who prefer it the opposite way to me. So how about
that config option?
> Speaking of cwd-ness, I sometimes find ls-tree irritating, but I think
> this is in "if we had known better we would have designed it differently,
> but because we didn't, because many scripts already depend on the current
> behaviour, and because we have an --full-name escape hatch, we are not
> likely to change it, ever" category.
I assume you mean "ls-files". I have every once in a while been annoyed
by that, but given how infrequently I run ls-files, it is not a big
deal. :)
> If "git add -u ../.." (I mean "the grand parent directory", not "an
> unnamed subdirectory") did not work, it would be unexcusable and we would
> want to devise an migration path, but otherwise I do not think it is such
> a big deal. I would say the commands that are used to incrementally build
As I mentioned above, not only is that annoying to use, but the real
problem is that I _expect_ the other behavior and it silently does the
opposite of what I want. You can argue that my brain is defective (for
not remembering, I mean -- we _know_ it's defective in other ways), but
certainly a config option would be useful to me.
> Oh, "git grep -e foo ../..", however, does not seem to work. That might be
> something people may want to tackle.
Thanks for mentioning "git grep"; I had forgotten that I have been
bitten by expecting full-tree behavior from that in the past, too. A
config option should cover that, too. ;)
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Junio C Hamano @ 2009-09-05 7:02 UTC (permalink / raw)
To: Jeff King; +Cc: Clemens Buchacher, SZEDER Gábor, git
In-Reply-To: <20090905061804.GB29863@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I suspect it is too late to change it due to compatibility issues. OTOH,
> I think the intent of v1.7.0 is to allow a few small breakages like
> these. You could always write an RFC patch and generate some discussion;
> I'm not 100% sure that there are enough people that agree with us to
> change the default.
The intent of 1.7.0 is to fix usability glitches and warts that everybody
has long agreed are problematic. People have *just started* discussing
about this---it is not remotely close to "everybody has long agreed are
problematic" criteria. It is too late for 1.7.0.
I agree that there are parts of git that is very whole tree oriented, and
the later "usability" part that are cwd centric. "add -u" and "grep" are
examples of the latter.
I personally find "add -u" that defaults to the current directory more
natural than always going to the root; same preference for "grep".
Besides, "add -u subdir" must add subdir relative to the cwd, without
going to the root. Why should "add -u" sans argument behave drastically
differently?
Speaking of cwd-ness, I sometimes find ls-tree irritating, but I think
this is in "if we had known better we would have designed it differently,
but because we didn't, because many scripts already depend on the current
behaviour, and because we have an --full-name escape hatch, we are not
likely to change it, ever" category.
If "git add -u ../.." (I mean "the grand parent directory", not "an
unnamed subdirectory") did not work, it would be unexcusable and we would
want to devise an migration path, but otherwise I do not think it is such
a big deal. I would say the commands that are used to incrementally build
towards the next commit should be friendly to the practice of limiting the
scope of the work by chdir, i.e. they should be cwd centric. On the other
hand, the commands that are used to review the next commit as a whole,
e.g. diff and patch, should be whole-tree oriented.
Oh, "git grep -e foo ../..", however, does not seem to work. That might be
something people may want to tackle.
^ permalink raw reply
* Use case I don't know how to address
From: Alan Chandler @ 2009-09-05 7:02 UTC (permalink / raw)
To: git
I have a use case that I don't know how to address. I have a feeling
that the way I propose is not using git to its best advantage, and am
therefore asking for advice.
As an intermittent software developer I have been using git for a long
time to track software (GPL licenced) I have developed for a web site
that I operate supporting a fan club. [Ajax based Chat, a real time Air
Hockey Game with associated club Ladder, and an American Football
Results Picking Competition]
Each application uses a pattern like that shown below
Basically I have two branches that interact as follows
2' - 2a - 3' - 4' SITE
/ / /
1 - 2 ------ 3 - 4 MASTER
I develop and test Locally on the master branch, in the commit 2a I
update settings (such as database password etc that I need for the
site), and then progressively merge commits made on master when I am
happy that they work in the test environment. A git hook rsyncs the
site branch to site on each merge or commit on that branch.
The master branch is also pushed to my public git repository (which is
why passwords are changed on the site branch. The change made back in
2a is "remembered" by git, so provided I don't go editing the password
on the master branch things work fine.
My applications tend to be "skinned" (if that is the right word for the
html page that forms the backdrop for them) with the fan club web site
look and feel. However, I am now trying to make a demo site on my home
server for these applications, and as such I would like to remove the
fan club skinning and add my own look and feel. In fact there are other
changes necessary, because many of the applications use the associated
fan club membership information of the user to display - so generically,
I need to make quite a lot of modifications to make it all work and
would end up with 4 branches as shown, with the difference in commits
between 4 and 5 as that major work to update the application.
2' - 2a - 3' - 4' SITE
/ / /
1 - 2 ------ 3 - 4 TEST
\
5 ------ 6 MASTER
\ \
5' - 5a- 6' DEMO
As you can see, in the process I have renamed Master to Test - the
transition to 5a adds passwords to access the database on my demo site.
The problem comes when I want to now merge back further work that I did
on the master branch (the 5-6 transition) to the fan club site
2' - 2a - 3' - 4' ----------------- 6' SITE
/ / / /
1 - 2 ------ 3 - 4 ------------6'''- 6a TEST
\ /
5 ------ 6 MASTER
\ \
5''- 5a- 6'' DEMO
What will happen is the changes made in 4->5 will get applied to the
(now) Test branch as part of the 6->6'' merge, and I will be left having
to add a new commit, 6a, to undo them all again. Given this is likely
to be quite a substantial change I want to try and avoid it if possible.
Is there any way I could use git to remember the 4->5 transition,
reverse it and apply it back to the Test branch before hand.
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: [git-svn] always prompted for passphrase with subversion 1.6
From: Eric Wong @ 2009-09-05 6:46 UTC (permalink / raw)
To: Tim Potter; +Cc: git
In-Reply-To: <4A95D58C.1070409@hp.com>
Tim Potter <tpot@hp.com> wrote:
> Hi everyone. I am using git-svn with the Subversion 1.6 client compiled
> with GNOME Keyring support. This neat features allows a SSL client
> certificate password to be cached inside GNOME Keyring instead of being
> prompted to enter it every time. However the git-svn script doesn't
> appear to know about this and always prompts for a password.
>
> Obviously there's some tweak required in the _auth_providers()
> subroutine but I don't know enough about the Subversion Perl client to
> figure out a fix.
>
> Has anyone else run in to this problem? I did a quick search on the
> list but didn't find anything relevant.
Hi Tim,
I think one user wanted to get SSL certificate authentication going but
my SSL knowledge was too weak at the time[1] and I think we both forgot
about it or lost interest.
[1] and probably still so, though I have recently managed to set
*something* up with SSL client certs and maybe it's done
right. SSL is just one of those things that never really
"clicked" for me (ssh on the other hand...)
--
Eric Wong
^ permalink raw reply
* unpack-trees traversing with index quite broken...
From: Junio C Hamano @ 2009-09-05 6:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Linus,
I found an issue I do not know how to resolve.
Suppose you try to merge these three trees:
- Tree #1 (ancestor)
t tree, in which there is an entry f that is a blob
t/f blob
- Tree #2 (ours)
t blob
t-f blob
- Tree #3 (theirs)
t-f blob
The index matches our tree.
The callchain that causes "read-tree -m -u #1 #2 #3" misbehave looks like this.
unpack_trees()
->traverse_trees()
entry[0] = "t" (tree taken from Tree #1)
entry[1] = "t" (blob taken from Tree #2)
entry[2] = nothing
->unpack_callback()
ce = "t" (blob taken from the index)
->unpack_nondirectories()
src[0] = "t" (blob from the index)
src[1] = conflict (tree taken from Tree #1)
src[2] = "t" (blob taken from Tree #2)
src[3] = NULL
->call_unpack_fn()
This callback is perfectly fine.
/* Now handle any directories.. unpack-trees.c, ll.336- */
->traverse_trees_recursive()
Now we stepped into tree "t".
->traverse_trees()
entry[0] = "f" (blob from "t/" tree in Tree #1)
entry[1] = nothing (Tree #2 does not have "t/" subtree)
entry[2] = nothing (Tree #3 does not have "t/" subtree)
->unpack_callback()
ce = "t-f" (blob taken from the index)
->compare_entry(ce, entry[])
<- "t-f" comes anything in "t/" directory, return negative
Because we are processing "t/something" at this level, and
"t-f" that should come earlier than any "t/something", we
assume that there is no matching entries in the trees.
->unpack_index_entry(ce = "t-f")
->call_unpack_fn()
This callback is utterly wrong. "t-f" from the index
has a matching entry in Tree #2 and Tree #3, but we
haven't seen them yet!
At first, I thought that we could fudge this particular example by
noticing that "t-f" is earlier only because "t-f" sorts before "t/", the
path-prefix of the problematic level, and pretend the negative return from
compare_entry() as if it was positive (i.e. deferring the processing of
the index entry). While this approach lets the problematic level
correctly feed only "t/f" to call_unpack_fn() and come back, and the rest
may proceed cleanly for this particular case, I do not think it is the
right solution.
If Tree #3 had another tree "t/" in it, the situation would look like this
instead:
- Tree #1 (ancestor)
t tree, in which there is an entry f that is a blob
t/f blob
- Tree #2 (ours, matches the index)
t blob
t-f blob
- Tree #3 (theirs)
t-f blob
t tree, in which there is an entry f that is a blob
Since traverse_trees() wants to walk the trees in parallel, never seeking
back, I do not think it would feed t-f from Tree #2 and Tree #3 to the
unpack_callback() sanely. Worse yet, the logic to walk the index in
parallel while this is happening (i.e. "Are we supposed to look at the
index too?" part) does not want to seek o->pos pointer back either, so I
am stuck X-<...
^ permalink raw reply
* Re: [PATCH v2] status: list unmerged files last
From: Jeff King @ 2009-09-05 6:28 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Johannes Sixt, bill lam, git
In-Reply-To: <20090903011234.GA7415@gmail.com>
On Wed, Sep 02, 2009 at 06:12:36PM -0700, David Aguilar wrote:
> The only use case would be for --amend.
> Which is why I asked about --porcelain; really what I want is
> something like
>
> git status --porcelain HEAD^
>
> Rolling a patch to make --porcelain an alias for --short seems
> like a good idea. If we want to support HEAD^ and HEAD^ only
> then perhaps an --amend flag is useful.
>
> The real crux of my question was about being able to script
> it, which is why commit --dry-run is not enough.
I see. I still think you may want to improve "commit --dry-run" with a
plumbing format, though, instead of "git status". Then it would
automagically support "--amend", as well as other dry-run things (e.g.,
"git commit --dry-run --porcelain --amend foo.c"). And not having looked
at the code, I would guess it is a one-liner patch to switch the "output
format" flag that commit passes to the wt-status.c code.
-Peff
^ permalink raw reply
* Re: Hosting Git repositories: how useful will git-gc be?
From: Jeff King @ 2009-09-05 6:24 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq1vmo9xai.fsf@bauges.imag.fr>
On Thu, Sep 03, 2009 at 11:45:25AM +0200, Matthieu Moy wrote:
> A question: is it necessary/recommanded/useless to set up a cron job
> doing a "git gc" in each repository? My understanding is that a push
> through ssh will do some packing, is it correct? Does receiving a pack
> trigger a "git gc --auto"?
The objects are transferred as a pack. If the number of objects is less
than receive.unpackLimit (default 100), then they are unpacked to loose
objects. If more, we keep the pack, after completing any missing deltas
used by a thin pack.
So if you tend to push frequently, you will end up with a lot of loose
objects. Even if you have packs, they will be larger than necessary
because you will be missing deltas between objects across packs. And of
course you will eventually end up with a large number of packs, which is
less efficient (each pack has an index, but I believe we search the
indices linearly).
Receiving a pack does not (AFAICT looking at the code) trigger a "gc
--auto". Running it has other benefits, too, like pruning cruft and
packing refs. So I think it is probably a good idea to run it
periodically.
Running it daily or weekly is probably reasonable. You could run it on
every push using the post-update hook, but that may cause excessive I/O
for very little benefit.
-Peff
^ permalink raw reply
* Re: [BUG] 'add -u' doesn't work from untracked subdir
From: Jeff King @ 2009-09-05 6:18 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: SZEDER Gábor, git
In-Reply-To: <20090904070216.GA3996@darc.dnsalias.org>
On Fri, Sep 04, 2009 at 09:02:16AM +0200, Clemens Buchacher wrote:
> On Wed, Sep 02, 2009 at 04:19:17AM -0400, Jeff King wrote:
>
> > [1] I would prefer "git add -u ." to add only the current directory, and
> > "git add -u" to touch everything.
>
> FWIW, I feel the same way. And there is no easy way to do that now. (cd `git
> rev-parse --show-cdup`; git add -u) ?
I suspect it is too late to change it due to compatibility issues. OTOH,
I think the intent of v1.7.0 is to allow a few small breakages like
these. You could always write an RFC patch and generate some discussion;
I'm not 100% sure that there are enough people that agree with us to
change the default.
I guess we could add a "git add --absolute" option, though it is
slightly annoying, because I generally do not realize that I needed to
use such an option until several minutes after running "git add".
I would be fine with a "be absolute, not relative" config option such as
what we have for status (in fact, a global "be absolute, not relative"
option to cover all commands might be handy). The only obstacle is that
I think "git add" is often used as plumbing in scripts (arguably, they
should be using update-index, but "git add ." is just so convenient).
-Peff
^ permalink raw reply
* Re: how to skip branches on git svn clone/fetch when there are errors
From: Eric Wong @ 2009-09-05 6:16 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <9accb4400908310126v15b08c7fr425c9daff26012f3@mail.gmail.com>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> Hi,
>
> I'm trying to clone a big repository.
>
> I follow this steps:
>
> git init
> git svn init svn://svn.mydomain.com/path/to/repo -T HEAD -b BRANCHES -t TAGS
>
> vim .git/config # edited the svn-remote config as follow (add /root to
> branches and tag) to match the repo structure
> [svn-remote "svn"]
> url = svn://svn.mydomain.com
> fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
> branches = path/to/repo/BRANCHES/*/root:refs/remotes/svn/*
> tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
>
> git svn fetch
>
> When I reach revision ~7500 (I don't remember the exact number) I get an error:
>
> $ git svn fetch
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/SVN/Core.pm line 584.
> Authorization failed: at /usr/bin/git-svn line 1415
>
>
> After some debugging I found out the reason is something strange on
> the SVN server: there is a folder in the SVN that give an error when
> trying to access:
>
> $ svn info svn://svn.mydomain.com/path/to/repo/BRANCHES/V2.1-A
> svn: Authorization failed
>
> The same error with svn list.
>
> I don't know what's wrong with that branch but I just want to skip it...
Ouch :(
> I tried modifying the .git/config svn-remote configuration adding this:
>
> ignore-paths = path\\/to\\/repo\\/BRANCHES\\/V2\\.1-A
> and re-launching git svn fetch.
ignore-paths is only for paths that get converted into part of
the git tree
> I had no luck.
>
> Ho do I skip a path on the svn repository?
It's unfortunate, but there's not yet an exclude/ignore directive
when globbing. You'll have to change your $GIT_CONFIG to only
have a list of branches you want, something like this:
[svn-remote "svn"]
url = svn://svn.mydomain.com
fetch = path/to/repo/HEAD/root:refs/remotes/svn/trunk
; have one "fetch" line for every branch except the one you want
fetch = path/to/repo/BRANCHES/a/root:refs/remotes/svn/a
fetch = path/to/repo/BRANCHES/b/root:refs/remotes/svn/b
fetch = path/to/repo/BRANCHES/c/root:refs/remotes/svn/c
; you can do the same for tags if you have the same problem
tags = path/to/repo/TAGS/*/root:refs/remotes/svn/tags/*
But you shouldn't have to worry about having "fetch" entries for
stale/old branches/tags you've already imported.
--
Eric Wong
^ permalink raw reply
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-05 6:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, Pete Wyckoff, git
In-Reply-To: <20090904185949.GA21583@atjola.homenet>
On Fri, Sep 04, 2009 at 08:59:49PM +0200, Björn Steinbrink wrote:
> "git pull --rebase" is not the same as:
> "git fetch origin && git rebase origin/foo", but:
>
> git fetch origin && git rebase --onto origin/foo $reflog_merge_base
>
> Where $reflog_merge_base is the first merge base is found between the
> current branch head, and the reflog entries for origin/foo.
Thanks, I didn't know about the trick (not being, as I mentioned, a pull
--rebase user). I can see arguments for or against a rebase-default
using that feature. On one hand, it simplifies the explanation for
people going between "pull --rebase" and "fetch && rebase". And I think
it should generally Do What You Mean in the case that upstream hasn't
rebased. Are there cases you know of where it will do the wrong thing?
I don't know if people would be confused that "git rebase" does not
exactly default to "git rebase $upstream", which is at least easy to
explain.
> > The biggest question is whether it should respect branch.*.merge, or
> > just branch.*.rebase (I never use the latter simply because I never use
> > "git pull", but I think it is probably reasonable to restrict it to
> > cases where you said you are interested in rebasing in general).
>
> Hm, you'll probably want "git merge" to pickup the default as well then,
> right? And that should only do so if branch.*.rebase is not set. So
> effectively, you still have to use the right command, but can skip the
> argument. Having to deal a lot with git-svn, I also regulary use its
> "git svn rebase --local", which means "just rebase, don't fetch".
I hadn't considered whether "git merge" should get a default. To be
honest, my intended use case was not really to replace pull, but as a
shorthand for running "git rebase -i". Upstream has the published
commits, so it is a nice shortcut to say "let me munge all of the
commits that I haven't published yet".
Of course the "published" status of those commits is not guaranteed
(they might have been published in another branch, your
tracking refs might not be up to date, etc) but I think it's a good rule
of thumb.
And by automating the shorthand we reduce the chance of errors. For
example, I usually base my topic branches from origin/master. But the
other day I happened to be building a new branch, jk/date, off of
lt/approxidate, salvaged from origin/pu. I did "git rebase -i
origin/master" and accidentally rewrote the early part of
lt/approxidate.
> Now, basically "git svn rebase" is pretty much git-svn's "pull". Maybe
> its idea could be taken, so we get "git pull --local" to just skip the
> fetch part, but keep "git rebase" and "git merge" 'dumb', requiring
> explicit arguments.
That wouldn't help me, because you can't "pull -i". :)
-Peff
^ permalink raw reply
* Re: Question about git-svn
From: Eric Wong @ 2009-09-05 6:09 UTC (permalink / raw)
To: martin liste larsson; +Cc: git
In-Reply-To: <b4abed330908310601h197f8909h8f626e918f8e5090@mail.gmail.com>
martin liste larsson <martin.liste.larsson@gmail.com> wrote:
> I have a problem using git-svn. Is this the right place to ask then?
Hi, Yes, feel free to Cc me directly as well.
> I have followed Andy Delcambre's
> http://herebeforeatreplies.com/2008/03/04/git-svn-workflow.html, but
> it seems that not all my tags and branches are being imported from svn
> to (local) git. That is, 'git branch -a' gives much less output (about
> half) of the combination 'svn list http://repos/branches' and 'svn
> list http://repos/tags'.
Are there branches/tags in subdirectories?
As in, do you have stuff in http://repos/branches/foo/* as well
as just http://repos/branches/* ?
You'll need git 1.6.4 to handle that with multiple branches entries:
before:
[svn-remote "svn"]
branches = project/branches/*:refs/remotes/*
after:
[svn-remote "svn"]
branches = project/branches/*:refs/remotes/*
branches = project/branches/foo/*: refs/remotes/foo/*
> What's missing seems to be the newest
> branches and tags.
Just checking the obvious, you are running "git svn fetch", right?
--
Eric Wong
^ permalink raw reply
* Re: Error with git svn show-ignore: forbidden access
From: Eric Wong @ 2009-09-05 5:57 UTC (permalink / raw)
To: Yann Simon; +Cc: git
In-Reply-To: <551f769b0909010246u524599bcoc5b227f4a6279259@mail.gmail.com>
Yann Simon <yann.simon.fr@gmail.com> wrote:
> Hi,
>
> with git version 1.6.4:
>
> $ git svn show-ignore > .gitignore
> RA layer request failed: Server sent unexpected return value (403
> Forbidden) in response to PROPFIND request for
> '/repos/XXX/YYY/ZZZ/trunk/aaa' at /usr/lib/git-core/git-svn line 2243
>
> Is git svn show-ignore making request to the svn server?
Hi Yann,
Yes, git svn has to read the svn:ignore property remotely since it
doesn't do anything with it when it fetches. Do you have read
permissions to /repos/XXX/YYY/ZZZ/trunk/aaa on that repo?
> I tried also with the --no-minimize-url option but get as answer:
> $ git svn --no-minimize-url show-ignore
> Unknown option: no-minimize-url
>
> Thanks for the help
For everything besides initialization/clone, git svn reads the url in
your $GIT_CONFIG. --minimize-url is only used for the initial setup.
You can edit it to move the URL down/up a level if you edit your
corresponding fetch/branches/tags lines:
before:
[svn-remote "svn"]
url = http://example.com/
fetch = project/trunk:refs/remotes/trunk
branches = project/branches/*:refs/remotes/*
tags = project/tags/*:refs/remotes/tags/*
after:
[svn-remote "svn"]
url = http://example.com/project
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
--
Eric Wong
^ 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