* Re: What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Jeff King @ 2009-03-03 9:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vprgzdlom.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 03, 2009 at 01:01:45AM -0800, Junio C Hamano wrote:
> As an experiment, 'next' and 'pu' stayed open during this release freeze;
> new topics have been accepted. I have to say that the experiment was a
> moderate success, and many topics in 'next' seem to be of fairly high
> quality already, which would mean that we will have a shorter cycle before
> 1.6.3.
I was going to stay quiet on this issue until after 1.6.3 released, but
now you have opened the topic. :)
I think seeing the quality of topics in 'next' is only half of
"success". You have to also consider how much attention was given to the
about-to-be-released version (and its impact on quality). And I think we
won't know about that until we see how quickly we need 1.6.3.1. :)
Personally, I know that I have spent much less time focusing on
'master'. Like everyone else, I have limited git bandwidth, and topics
in 'next' are simply more interesting. I think it's easier to put them
aside for a few weeks if everybody agrees to do so (rather than having
interesting discussion proceeding without you if you choose to focus on
'master').
-Peff
^ permalink raw reply
* What's in git.git (Mar 2009, #01; Tue, 03)
From: Junio C Hamano @ 2009-03-03 9:09 UTC (permalink / raw)
To: git
Hopefully the last "What's in" before 1.6.2 final. Small fixes here and
there and nothing earth shattering.
* The 'maint' branch has these fixes since the last announcement.
Danijel Tasov (1):
added missing backtick in git-apply.txt
David J. Mellor (1):
Documentation: minor grammatical fixes.
Gerrit Pape (1):
Documentation/git-push: --all, --mirror, --tags can not be combined
Junio C Hamano (1):
tests: fix "export var=val"
Matthieu Moy (2):
Document git blame --reverse.
More friendly message when locking the index fails.
Michael Spang (1):
Skip timestamp differences for diff --no-index
Todd Zullinger (1):
Documentation: Note file formats send-email accepts
* The 'master' branch has these since the last announcement
in addition to the above.
Abhijit Menon-Sen (1):
Convert git-* invocations to "git *" in the svnimport example.
Alexandre Julliard (3):
git.el: Make sure that file lists are sorted as they are created.
git.el: Improve the confirmation message on remove and revert.
Add a README in the contrib/emacs directory.
Allan Caffee (1):
trace: Fixed a minor typo in an error message.
Ben Walton (2):
git-svn fix to avoid using strftime %z
git-svn - return original format_svn_date semantics
Brian Gernhardt (1):
git-svn: Create leading directories in create-ignore
Christian Couder (3):
README: fix path to "gitcvs-migration.txt" and be more consistent
bisect: fix quoting TRIED revs when "bad" commit is also "skip"ped
bisect: fix another instance of eval'ed string
David J. Mellor (3):
Documentation: minor grammatical fixes.
Documentation: minor grammatical fixes.
Documentation: minor grammatical fixes.
Dévai Tamás (1):
git-svn: Fix for rewriteRoot URL containing username.
Eric Wong (2):
git-svn: fix delete+add branch tracking with empty files
git-svn: disable broken symlink workaround by default
Felipe Contreras (2):
git add: trivial codestyle cleanup
sha1_file.c: fix typo
Gerrit Pape (2):
Install builtins with the user and group of the installing personality
git-quiltimport: preserve standard input to be able to read user input
Giuseppe Bilotta (1):
gitweb: fix wrong base URL when non-root DirectoryIndex
Jay Soffian (3):
disallow providing multiple upstream branches to rebase, pull --rebase
Allow HTTP tests to run on Darwin
t5540-http-push.sh: avoid non-portable grep -P
Johannes Schindelin (2):
Introduce the function strip_path_suffix()
system_path(): simplify using strip_path_suffix(), and add suffix "git"
Johannes Sixt (2):
gitattributes.txt: Path matching rules are explained in gitignore.txt
t3400-rebase: Move detached HEAD check earlier
Junio C Hamano (4):
git-svn: fix parsing of timestamp obtained from svn
Make sure objects/pack exists before creating a new pack
GIT 1.6.2-rc2
git-am: make --abort less dangerous
Lars Noschinski (1):
filter-branch -d: Export GIT_DIR earlier
Linus Torvalds (1):
Support 'raw' date format
Marc Branchaud (1):
Docs: Expand explanation of the use of + in git push refspecs.
Marcel M. Cary (2):
gitweb: Fix warnings with override permitted but no repo override
gitweb: Hyperlink multiple git hashes on the same commit message line
Michael J Gruber (2):
Fix typo in contrib/examples/git-svnimport.txt
git-am: Keep index in case of abort with dirty index
Mike Ralphson (1):
Fix odb_mkstemp() on AIX
Paul Mackerras (1):
gitk: Fix possible infinite loop and display corruption
Pete Wyckoff (1):
git-p4: avoid syncing duplicate changes
Peter Oberndorfer (1):
git-svn: read the dcommit url from the config file on a per remote basis
René Scharfe (1):
builtin-receive-pack.c: fix compiler warnings about format string
SZEDER Gábor (2):
bash: add missing 'git merge' options
bash: update 'git svn' options
Thomas Rast (2):
bash completion: refactor common log, shortlog and gitk options
bash completion: only show 'log --merge' if merging
Todd Zullinger (1):
git-rebase: Update --whitespace documentation
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Johannes Schindelin @ 2009-03-03 9:07 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Junio C Hamano, git
In-Reply-To: <1236040414-19089-1-git-send-email-torarnv@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 499 bytes --]
Hi,
On Tue, 3 Mar 2009, Tor Arne Vestbø wrote:
> Something like this?
Leaving unnecessary initialization and funny indentation aside for a
moment, what about the objection that it might not be necessary?
Keep in mind: your change (as every change) bears the potential to
introduce bugs and to complicate the user interface. The change must be
worth those risks.
So could you make a case (if you resubmit a patch, in the commit message,
please) why your change is desirable?
Thanks,
Dscho
^ permalink raw reply
* Re: remote branches, and branch names in general
From: Jeff King @ 2009-03-03 9:05 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Jakub Narebski, John Dlugosz, git
In-Reply-To: <200903030958.56150.markus.heidelberg@web.de>
On Tue, Mar 03, 2009 at 09:58:55AM +0100, Markus Heidelberg wrote:
> > Yes. I don't know if they are documented anywhere, but the complete
> > lookup order is:
> >
> > $ git grep -h -A8 ref_rev_parse_rules refs.c
> > const char *ref_rev_parse_rules[] = {
> > "%.*s",
> > "refs/%.*s",
> > "refs/tags/%.*s",
> > "refs/heads/%.*s",
> > "refs/remotes/%.*s",
> > "refs/remotes/%.*s/HEAD",
> > NULL
> > };
>
> Documented in git-rev-parse -> specifying revisions.
Oh, indeed. Thanks for pointing it out.
Though I think this may be part of what people mean when they say git
documentation sucks. I had no idea where to look for such a thing, and
it turns out it is in the manpage for a plumbing command that in theory
I should never have to use.
-Peff
^ permalink raw reply
* What's cooking in git.git (Mar 2009, #01; Tue, 03)
From: Junio C Hamano @ 2009-03-03 9:01 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 branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
The master branch is slightly past 1.6.2-rc2. It's been a week and I
think I can declare the final on this Wednesday, *if* I am not too mired
by the day job, but I do not know what would happen yet.
As an experiment, 'next' and 'pu' stayed open during this release freeze;
new topics have been accepted. I have to say that the experiment was a
moderate success, and many topics in 'next' seem to be of fairly high
quality already, which would mean that we will have a shorter cycle before
1.6.3.
----------------------------------------------------------------
[New Topics]
* jk/clone-post-checkout (Tue Mar 3 00:37:51 2009 -0500) 1 commit
- clone: run post-checkout hook when checking out
* hv/cvsimport (Mon Mar 2 18:59:36 2009 +0100) 1 commit
- cvsimport: add test illustrating a bug in cvsps
* jc/push-to-create (Mon Mar 2 22:36:16 2009 -0800) 1 commit
- Push to create
* fc/parseopt-config (Sat Feb 21 02:49:29 2009 +0200) 11 commits
- git config: don't allow --get-color* and variable type
- git config: don't allow extra arguments for -e or -l.
- git config: don't allow multiple variable types
- git config: don't allow multiple config file locations
- git config: reorganize to use parseopt
- git config: reorganize get_color*
- git config: trivial rename in preparation for parseopt
- git_config(): not having a per-repo config file is not an error
+ git config: trivial cleanup for editor action
+ git config: codestyle cleanups
+ config: Add new option to open an editor.
* tr/format-patch-thread (Thu Feb 19 22:26:33 2009 +0100) 4 commits
- format-patch: support deep threading
- format-patch: thread as reply to cover letter even with in-reply-
to
- format-patch: track several references
- format-patch: threading test reactivation
* ns/pretty-format (Tue Feb 24 15:33:29 2009 +0200) 5 commits
+ bash completion: add --format= and --oneline options for "git log"
+ Add tests for git log --pretty, --format and --oneline.
+ Add --oneline that is a synonym to "--pretty=oneline --abbrev-
commit"
+ Give short-hands to --pretty=tformat:%formatstring
+ Add --format that is a synonym to --pretty
* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
- Add a test of "git cvsimport"'s handling of tags and branches
- Add some tests of git-cvsimport's handling of vendor branches
- Test contents of entire cvsimported "master" tree contents
- Use CVS's -f option if available (ignore user's ~/.cvsrc file)
- Start a library for cvsimport-related tests
* tr/maint-1.6.0-send-email-irt (Sun Mar 1 23:45:41 2009 +0100) 1 commit
- send-email: respect in-reply-to regardless of threading
* jc/maint-1.6.0-keep-pack (Sat Feb 28 00:37:19 2009 -0800) 6 commits
+ is_kept_pack(): final clean-up
+ Simplify is_kept_pack()
+ Consolidate ignore_packed logic more
+ has_sha1_kept_pack(): take "struct rev_info"
+ has_sha1_pack(): refactor "pretend these packs do not exist"
interface
+ git-repack: resist stray environment variable
* en/maint-hash-object (Sat Feb 28 12:56:49 2009 -0700) 1 commit
+ Ensure proper setup of git_dir for git-hash-object
* el/blame-date (Fri Feb 20 14:51:11 2009 -0800) 1 commit
- Make git blame's date output format configurable, like git log
* js/remote-improvements (Wed Feb 25 03:32:28 2009 -0500) 22 commits
- builtin-remote: new show output style for push refspecs
- builtin-remote: new show output style
- remote: make guess_remote_head() use exact HEAD lookup if it is
available
- builtin-remote: add set-head subcommand
- builtin-remote: teach show to display remote HEAD
- builtin-remote: fix two inconsistencies in the output of "show
<remote>"
- builtin-remote: make get_remote_ref_states() always populate
states.tracked
- builtin-remote: rename variables and eliminate redundant function
call
- builtin-remote: remove unused code in get_ref_states
- builtin-remote: refactor duplicated cleanup code
- string-list: new for_each_string_list() function
- remote: make match_refs() not short-circuit
- remote: make match_refs() copy src ref before assigning to
peer_ref
- remote: let guess_remote_head() optionally return all matches
- remote: make copy_ref() perform a deep copy
- remote: simplify guess_remote_head()
- move locate_head() to remote.c
- move duplicated ref_newer() to remote.c
- move duplicated get_local_heads() to remote.c
- refactor find_ref_by_name() to accept const list
- add basic http clone/fetch tests
- test scripts: refactor start_httpd helper
* js/clone-depth-local (Fri Feb 27 00:04:06 2009 -0800) 3 commits
. parse_options(): do not "increment" boolean
. clone: ignore --depth when cloning locally (implicitly --local)
. clone: do not ignore --no-local option
Jeff had a good suggestion for this series but it was tripped by
a misfeature in parse_options().
* rs/memmem (Tue Mar 3 00:19:30 2009 +0100) 2 commits
- optimize compat/ memmem()
- diffcore-pickaxe: use memmem()
As always with patches from René, this is already next material.
* mv/parseopt-ls-files (Tue Feb 17 15:27:11 2009 +0100) 2 commits
- parse-opt: migrate builtin-ls-files.
- Turn the flags in struct dir_struct into a single variable
* jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
+ never fallback relative times to absolute
* tv/rebase-stat (Sun Mar 1 22:28:28 2009 +0100) 2 commits
- git-pull: Allow --stat and --no-stat to be used with --rebase
- git-rebase: Add --stat and --no-stat for producing diffstat on
rebase
----------------------------------------------------------------
[Discarded]
* jc/fsck (Fri Jan 30 02:33:47 2009 -0800) 4 commits
- fsck: three levels of validation
- verify-pack: add --quick
- verify_pack(): allow a quicker verification for a pack with
version 2 idx
- pack-check.c: minor formatting fix to match coding style
J6t has a good point that if this had any value then medium level should
replace the default. I am tempted to actually dropping this as a failed
experiment.
* js/remote-set-head (Sat Feb 14 05:30:30 2009 -0500) 5 commits
- builtin-remote: better handling of multiple remote HEADs
- builtin-remote: add set-head subcommand
- builtin-remote: teach show to display remote HEAD
- builtin-remote: move duplicated cleanup code its own function
- builtin-clone: move locate_head() to remote.c so it can be re-used
* jk/head-lookup (Sun Feb 15 01:18:18 2009 -0500) 5 commits
- remote: use exact HEAD lookup if it is available
- remote: refactor guess_remote_head
- refactor find_refs_by_name to accept const list
- add basic http clone/fetch tests
- test scripts: refactor start_httpd helper
These two are now consolidated into Jay's remove-improvements series
listed above.
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* gb/gitweb-base (Sun Feb 15 10:18:36 2009 +0100) 1 commit
- gitweb: fix wrong base URL when non-root DirectoryIndex
* ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
- stash: --keep option just saves
Do we want to keep this one?
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
- archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
I thought recent tig discussion may blow new life into it, but is this
unneeded? If so I'd rather revert it (or discard after 1.6.2).
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
- builtin-replace: use "usage_msg_opt" to give better error messages
- parse-options: add new function "usage_msg_opt"
- builtin-replace: teach "git replace" to actually replace
- Add new "git replace" command
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
I think the code is much cleaner than the first round, but I am not
convinced it is doing the right thing in the connectivity traverser.
Independent review sorely needed.
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
Design discussion between Jakub and Sebastien seems to have stalled, but
Jakub seems to be taking this over.
----------------------------------------------------------------
[Reverted]
* mh/unify-color (Fri Jan 23 01:25:23 2009 -0800) 3 commits
? Revert previous two commits
? move the color variables to color.c
? handle color.ui at a central place
This broke git-format-patch badly.
* js/rebase-error-a-bit-more-verbose (Sun Feb 8 21:22:18 2009 -0800) 2 commits
? Revert "rebase: explain why when the HEAD could not be detached"
? rebase: explain why when the HEAD could not be detached
This turned out to be unnecessary.
* rs/maint-1.6.0-windows-ceiling (Sat Feb 7 12:40:40 2009 -0800) 2 commits
? Revert "fix t1504 on Windows"
? fix t1504 on Windows
I'm giving a fresh start to J6t's series which contains this.
* lh/reverted-submodule-tree-traversal (Sun Jan 25 18:39:55 2009 -0800) 4 commits
? Revert round #1 of the series
? builtin-ls-tree: enable traversal of submodules
? archive.c: enable traversal of submodules
? tree.c: add support for traversal of submodules
I'm giving a fresh start to Lars's second iteration.
----------------------------------------------------------------
[Will merge to 'next' soon]
* js/send-email (Mon Mar 2 23:52:18 2009 -0500) 5 commits
- send-email: add --confirm option and configuration setting
+ send-email: don't create temporary compose file until it is needed
+ send-email: --suppress-cc improvements
+ send-email: handle multiple Cc addresses when reading mbox message
+ send-email: allow send-email to run outside a repo
----------------------------------------------------------------
[Ready for 'master' after 1.6.2]
* sg/rerere-cleanup (Sat Feb 14 23:21:04 2009 +0100) 1 commit
+ rerere: remove duplicated functions
* jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
+ git-add -i/-p: learn to unwrap C-quoted paths
* jw/imap-preformatted-html (Thu Feb 12 08:58:12 2009 -0600) 1 commit
+ imap.preformattedHTML to tell Thunderbird to send non-flowed text
The patch text should be identical to Jeremy's "Virtual Patch", except
that the configuration variable was renamed per list discussion.
* jw/format-patch-attach (Thu Feb 12 09:51:55 2009 -0600) 1 commit
+ Enable setting attach as the default in .gitconfig for git-format-
patch.
* sr/force-rebase (Fri Feb 13 23:48:01 2009 +0100) 1 commit
+ Teach rebase to rebase even if upstream is up to date
* fg/exclude-bq (Tue Feb 10 15:20:17 2009 +0100) 1 commit
+ Support "\" in non-wildcard exclusion entries
* dm/add-i-edit-abort (Thu Feb 12 00:19:41 2009 -0500) 1 commit
+ add -i: revisit hunk on editor failure
* tp/completion (Sat Feb 21 15:48:43 2009 +0100) 6 commits
+ Fixup: Add bare repository indicator for __git_ps1
+ Add bare repository indicator for __git_ps1
+ completion: More fixes to prevent unbound variable errors
+ completion: Better __git_ps1 support when not in working directory
+ completion: Use consistent if [...] convention, not "test"
+ completion: For consistency, change "git rev-parse" to __gitdir
calls
* js/branch-symref (Wed Feb 18 22:34:44 2009 -0500) 4 commits
+ add basic branch display tests
+ branch: clean up repeated strlen
+ Avoid segfault with 'git branch' when the HEAD is detached
+ builtin-branch: improve output when displaying remote branches
* al/ansi-color (Fri Feb 13 22:53:41 2009 +0100) 2 commits
+ builtin-branch.c: Rename branch category color names
+ Clean up use of ANSI color sequences
* kb/checkout-optim (Mon Feb 23 19:02:57 2009 +0100) 14 commits
+ write_index(): update index_state->timestamp after flushing to
disk
+ verify_uptodate(): add ce_uptodate(ce) test
+ make USE_NSEC work as expected
+ fix compile error when USE_NSEC is defined
+ check_updates(): effective removal of cache entries marked
CE_REMOVE
+ lstat_cache(): print a warning if doing ping-pong between cache
types
+ show_patch_diff(): remove a call to fstat()
+ write_entry(): use fstat() instead of lstat() when file is open
+ write_entry(): cleanup of some duplicated code
+ create_directories(): remove some memcpy() and strchr() calls
+ unlink_entry(): introduce schedule_dir_for_removal()
+ lstat_cache(): swap func(length, string) into func(string, length)
+ lstat_cache(): generalise longest_match_lstat_cache()
+ lstat_cache(): small cleanup and optimisation
* js/valgrind (Thu Feb 5 22:03:00 2009 +0100) 9 commits
+ valgrind: do not require valgrind 3.4.0 or newer
+ test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
+ Tests: let --valgrind imply --verbose and --tee
+ Add a script to coalesce the valgrind outputs
+ t/Makefile: provide a 'valgrind' target
+ test-lib.sh: optionally output to test-results/$TEST.out, too
+ Valgrind support: check for more than just programming errors
+ valgrind: ignore ldso and more libz errors
+ Add valgrind support in test scripts
----------------------------------------------------------------
[Actively cooking]
* tr/gcov (Thu Feb 19 12:13:42 2009 +0100) 8 commits
- Test git-patch-id
- Test rev-list --parents/--children
- Test log --decorate
- Test fsck a bit harder
- Test log --graph
- Test diff --dirstat functionality
- Test that diff can read from stdin
- Support coverage testing with GCC/gcov
* js/notes (Sat Feb 14 21:23:25 2009 +0100) 13 commits
- notes: refuse to edit notes outside refs/notes/
- t3301: use test_must_fail instead of !
- t3301: fix confusing quoting in test for valid notes ref
- notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
- notes: only clean up message file when editing
- handle empty notes gracefully
+ git notes show: test empty notes
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
Earlier part was merged to master and then reverted there. Will be
rebased 1.6.2 to keep my sanity.
* fc/config-editor (Sat Feb 21 02:48:54 2009 +0200) 3 commits
+ git config: trivial cleanup for editor action
+ git config: codestyle cleanups
+ config: Add new option to open an editor.
Rerolled and looked sane.
----------------------------------------------------------------
[On Hold]
* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
- receive-pack: default receive.denyDeleteCurrent to refuse
* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
- Refuse updating the current branch in a non-bare repository via
push
This is for 1.7.0.
* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
- git commit: pathspec without -i/-o implies -i semantics during a
merge
- builtin-commit: shorten eye-sore overlong lines
- Add "partial commit" tests during a conflicted merge
This was only meant as a weatherballoon to help facilitate discussion.
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user. I do not need it in 1.6.2
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
^ permalink raw reply
* Re: remote branches, and branch names in general
From: Markus Heidelberg @ 2009-03-03 8:58 UTC (permalink / raw)
To: Jeff King; +Cc: Jakub Narebski, John Dlugosz, git
In-Reply-To: <20090303041631.GB18136@coredump.intra.peff.net>
Jeff King, 03.03.2009:
> On Mon, Mar 02, 2009 at 04:38:42PM -0800, Jakub Narebski wrote:
>
> > > I see the remote branches with names of the form remotes/pub/name where
> > > pub is the nickname of the place I pull from. To specify such branches,
> > > must I always spell it out with the leading "remotes/", or can that be
> > > shorted or implied somehow?
> >
> > You usually can omit "remotes/" prefix, and just use
> > "<remote>/<branch>" (or even "<remote>" for "<remote>/HEAD"). You need
> > it only if there is need for disambiguation.
>
> Yes. I don't know if they are documented anywhere, but the complete
> lookup order is:
>
> $ git grep -h -A8 ref_rev_parse_rules refs.c
> const char *ref_rev_parse_rules[] = {
> "%.*s",
> "refs/%.*s",
> "refs/tags/%.*s",
> "refs/heads/%.*s",
> "refs/remotes/%.*s",
> "refs/remotes/%.*s/HEAD",
> NULL
> };
Documented in git-rev-parse -> specifying revisions.
Markus
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Junio C Hamano @ 2009-03-03 8:45 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <buo8wnnrpcf.fsf@dhlpc061.dev.necel.com>
Miles Bader <miles@gnu.org> writes:
> I can use "git log --date=iso" to get YYYY-MM-DD format for dates, or
> "git log --date=local" to force the dates to use my local time zone, but
> if I use _both_ of these options together, it uses only the last one,
> and ignores any preceding --date (even those in this case, the two
> --date options affect orthogonal properties of dates). Is there a way
> to get YYYY-MM-DD format dates, but in my local time-zone?
No, there isn't.
But this patch may help you get started.
Just like any other patches I send out to only show a way to competent
people I can trust to carry it forward, it is not even compile tested,
though.
---
builtin-for-each-ref.c | 2 +-
builtin-log.c | 2 +-
cache.h | 15 ++++++++-------
date.c | 27 +++++++++++++++------------
revision.c | 2 +-
5 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index e46b7ad..3a9f64b 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -361,7 +361,7 @@ static void grab_date(const char *buf, struct atom_value *v, const char *atomnam
formatp = strchr(atomname, ':');
if (formatp != NULL) {
formatp++;
- date_mode = parse_date_format(formatp);
+ date_mode = parse_date_format(formatp, 0);
}
if (!eoemail)
diff --git a/builtin-log.c b/builtin-log.c
index 2ae39af..618922a 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -41,7 +41,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
DIFF_OPT_SET(&rev->diffopt, ALLOW_TEXTCONV);
if (default_date_mode)
- rev->date_mode = parse_date_format(default_date_mode);
+ rev->date_mode = parse_date_format(default_date_mode, 0);
argc = setup_revisions(argc, argv, rev, "HEAD");
diff --git a/cache.h b/cache.h
index 189151d..a3ecf63 100644
--- a/cache.h
+++ b/cache.h
@@ -692,19 +692,20 @@ extern struct object *peel_to_type(const char *name, int namelen,
enum date_mode {
DATE_NORMAL = 0,
- DATE_RELATIVE,
- DATE_SHORT,
- DATE_LOCAL,
- DATE_ISO8601,
- DATE_RFC2822,
- DATE_RAW
+ DATE_RELATIVE = 1,
+ DATE_SHORT = 2,
+ DATE_ISO8601 = 3,
+ DATE_RFC2822 = 4,
+ DATE_RAW = 5,
+
+ DATE_LOCAL = 16, /* OR'ed in to others */
};
const char *show_date(unsigned long time, int timezone, enum date_mode mode);
int parse_date(const char *date, char *buf, int bufsize);
void datestamp(char *buf, int bufsize);
unsigned long approxidate(const char *);
-enum date_mode parse_date_format(const char *format);
+enum date_mode parse_date_format(const char *format, enum date_mode so_far);
#define IDENT_WARN_ON_NO_NAME 1
#define IDENT_ERROR_ON_NO_NAME 2
diff --git a/date.c b/date.c
index d75dff4..8d04418 100644
--- a/date.c
+++ b/date.c
@@ -89,6 +89,10 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
struct tm *tm;
static char timebuf[200];
+ if (mode & DATE_LOCAL)
+ tz = local_tzoffset(time);
+ mode &= ~DATE_LOCAL;
+
if (mode == DATE_RAW) {
snprintf(timebuf, sizeof(timebuf), "%lu %+05d", time, tz);
return timebuf;
@@ -136,9 +140,6 @@ const char *show_date(unsigned long time, int tz, enum date_mode mode)
/* Else fall back on absolute format.. */
}
- if (mode == DATE_LOCAL)
- tz = local_tzoffset(time);
-
tm = time_to_tm(time, tz);
if (!tm)
return NULL;
@@ -604,24 +605,26 @@ int parse_date(const char *date, char *result, int maxlen)
return date_string(then, offset, result, maxlen);
}
-enum date_mode parse_date_format(const char *format)
+enum date_mode parse_date_format(const char *format, enum date_mode so_far)
{
+ int or_in_local = so_far & DATE_LOCAL;
+
if (!strcmp(format, "relative"))
- return DATE_RELATIVE;
+ return DATE_RELATIVE | or_in_local;
else if (!strcmp(format, "iso8601") ||
!strcmp(format, "iso"))
- return DATE_ISO8601;
+ return DATE_ISO8601 | or_in_local;
else if (!strcmp(format, "rfc2822") ||
!strcmp(format, "rfc"))
- return DATE_RFC2822;
+ return DATE_RFC2822 | or_in_local;
else if (!strcmp(format, "short"))
- return DATE_SHORT;
- else if (!strcmp(format, "local"))
- return DATE_LOCAL;
+ return DATE_SHORT | or_in_local;
else if (!strcmp(format, "default"))
- return DATE_NORMAL;
+ return DATE_NORMAL | or_in_local;
else if (!strcmp(format, "raw"))
- return DATE_RAW;
+ return DATE_RAW | or_in_local;
+ else if (!strcmp(format, "local"))
+ return DATE_LOCAL | so_far;
else
die("unknown date format %s", format);
}
diff --git a/revision.c b/revision.c
index 286e416..be9bbc4 100644
--- a/revision.c
+++ b/revision.c
@@ -1177,7 +1177,7 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
} else if (!strcmp(arg, "--relative-date")) {
revs->date_mode = DATE_RELATIVE;
} else if (!strncmp(arg, "--date=", 7)) {
- revs->date_mode = parse_date_format(arg + 7);
+ revs->date_mode = parse_date_format(arg + 7, revs->date_mode);
} else if (!strcmp(arg, "--log-size")) {
revs->show_log_size = 1;
}
^ permalink raw reply related
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-03 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <7v1vtff1op.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 3, 2009 at 3:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> And we haven't heard from them at all
Well, not here anyway, they seem to just complain about it on their
blogs and git's reputation suffers in silence. :-(
(I don't know when the heck I started to care about git's reputation.)
j.
^ permalink raw reply
* Re: orthogonal cases of log --date option
From: Jeff King @ 2009-03-03 8:34 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <buo8wnnrpcf.fsf@dhlpc061.dev.necel.com>
On Tue, Mar 03, 2009 at 05:18:56PM +0900, Miles Bader wrote:
> I can use "git log --date=iso" to get YYYY-MM-DD format for dates, or
> "git log --date=local" to force the dates to use my local time zone, but
> if I use _both_ of these options together, it uses only the last one,
> and ignores any preceding --date (even those in this case, the two
> --date options affect orthogonal properties of dates).
Yuck. It sounds like --date=local is really the wrong way to have
implemented it. It really should be:
git log --date=iso --local-dates
I don't think there is currently a way to do what you want, but it is
not too late to add an option (and keep --date=local as a synonym for
--date=default --local-dates for compatibility).
> Is there a way to get YYYY-MM-DD format dates, but in my local
> time-zone?
Short of using --date=raw and munging the output with perl, I don't
think so.
-Peff
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Junio C Hamano @ 2009-03-03 8:30 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20090303082706.GC3158@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But I think that coincides with what I was trying to say in my original
> response to the series, which is "this issue is complex, and we need to
> hear from the people who would really want this exactly what it is they
> want".
And we haven't heard from them at all, unless you and/or Shawn are
interested. After all we may not have to worry about this at all ;-)
And that answers your question (1) in the other message. The standard way
for users to create a repository becomes:
mkdir this-new-directory
cd this-new-directory
git init
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jeff King @ 2009-03-03 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7v63irf21u.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 03, 2009 at 12:22:53AM -0800, Junio C Hamano wrote:
> Yes and no. I think "git shell" sites fall broadly into two categories.
> The ones arranged ala gitosis without per-user UNIX account, it certainly
> is an issue. The ones with per-user UNIX account would not let anywhere
> other than $HOME written, so it is not.
Right. My problem is that for the former case, there is no switch.
People upgrading git would just get this new feature which has security
implications. So I think any patch needs to default to "off".
> My sole interest lies in building a track record of suggested patches to
> eliminate the excuse people would use to complain that we do not attempt
> to allow repositories to be created remotely. I've shown two possible
> ways. It now is turn for those who want to have the feature to fill in
> the details. These are weatherbaloon patches, and it is not my itch to
> scratch anyway.
Well, that's sneaky of you. ;P
But I think that coincides with what I was trying to say in my original
response to the series, which is "this issue is complex, and we need to
hear from the people who would really want this exactly what it is they
want".
-Peff
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jeff King @ 2009-03-03 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Shawn O. Pearce, git
In-Reply-To: <7vtz6bf392.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 02, 2009 at 11:56:57PM -0800, Junio C Hamano wrote:
> > I concur w/Jeff and I think git probably should not as well. I think
> > that instead adding it to init might be interesting
>
> The thing is Jeff and Shawn already rejected that route.
Since when do you listen to me? ;P
I think there are actually two issues to be resolved, though:
1. What is a standardized way for clients to ask for repo creation?
2. How do users trigger that repo creation.
I think once you have (1), then (2) is easy. You can have "git init
host:dir", "git push --init remote", or whatever, and they can all
trigger the same mechanism. For systems which have an out-of-band
method, they can continue to behave as they have, or they can hook into
the standardized mechanism as if they were clients themselves. So there
is not that much point in debating (2), I think, until there is a
working (1).
Now (1) is much harder. Some parameters come from the user, but some
(including whether creation is allowed at all) must come from the site
administrator. And some site administrators will a hook to do whatever
site-specific magic they need.
What about the client just calling init-serve on the server as a program
which does whatever it wants to create a repo? The shipped default would
be:
#!/bin/sh
echo >&2 Sorry, repo creation not allowed.
exit 1
Sites who want to give their users full creation access would do (and
obviously the --mkdir option would need to be added):
#!/bin/sh
exec git init --mkdir "$@"
Sites which want to restrict can do:
#!/bin/sh
for i in "$@"; do
case "$i" in
--bare) ;;
*) echo >&2 Forbidden argument: $i; exit 1 ;;
esac
done
exec git init --mkdir "$@"
Sites like GitHub or Gerrit can munge the arguments as appropriate. They
could even allow site-specific options if they wanted as long as they
were syntactically correct (i.e., "git init --gerrit-base=foo remote"
would pass the argument through to the remote unharmed).
-Peff
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Junio C Hamano @ 2009-03-03 8:22 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20090303080603.GA3158@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Mar 02, 2009 at 11:55:51PM -0800, Junio C Hamano wrote:
>
>> As with the previous "git init --remote" patch, my design constraints
>> includes keeping the door open for "git shell" users to optionally allow
>> this mode of operation.
>
> OK, I thought your original comment was "I don't think this constraint
> (thinking only of normal shell users) is right, but here is a patch
> anyway". Which did leave me confused, since it seemed like your patch
> did not cater just to such users. But I see now what you meant.
Yeah, I wanted to see if we can give git-shell only people a sane way to
host a group project, so that was why I mentioned "chgrp/chmod" in the
follow-up message to the "init --remote" series.
> However, if you are thinking of "git shell" users, then is it not a
> potential security problem to allow them to create new repositories
> without the admin explicitly enabling it? If a site is depending on
> hooks in existing repositories to implement some kind of policy, then
> isn't this a way to bypass it (not to make changes in those existing
> repos, obviously, but let's say there is a policy about how disk usage
> is counted).
Yes and no. I think "git shell" sites fall broadly into two categories.
The ones arranged ala gitosis without per-user UNIX account, it certainly
is an issue. The ones with per-user UNIX account would not let anywhere
other than $HOME written, so it is not.
My sole interest lies in building a track record of suggested patches to
eliminate the excuse people would use to complain that we do not attempt
to allow repositories to be created remotely. I've shown two possible
ways. It now is turn for those who want to have the feature to fill in
the details. These are weatherbaloon patches, and it is not my itch to
scratch anyway.
> Even if it isn't a security issue, it might simply be broken. Shawn has
> said that Gerrit needs extra magic when creating a repository, and I
> wouldn't be surprised if github and repo.or.cz were the same. With your
> patch, what switch should a Gerrit admin flip to prevent people from
> creating broken repos?
>
> What about places that might simply want to put some policy in place,
> like kernel.org having all linux repos point to Linus as alternates?
These are all valid points and people who are interested in creating
repositories remotely must think about them when they finally decide to
scratch their own itch. I am merely helping by showing where to add
hooks.
^ permalink raw reply
* orthogonal cases of log --date option
From: Miles Bader @ 2009-03-03 8:18 UTC (permalink / raw)
To: git
I can use "git log --date=iso" to get YYYY-MM-DD format for dates, or
"git log --date=local" to force the dates to use my local time zone, but
if I use _both_ of these options together, it uses only the last one,
and ignores any preceding --date (even those in this case, the two
--date options affect orthogonal properties of dates). Is there a way
to get YYYY-MM-DD format dates, but in my local time-zone?
Thanks,
-Miles
--
I'd rather be consing.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-03 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <7vk577f2vq.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 3, 2009 at 3:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> It was called "init --remote".
>
> No need to look for it; it is one of the message on the References line of
> this message, iow, in *this* thread.
Ah, not in gmail's web interface. :-(
j.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jeff King @ 2009-03-03 8:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, git
In-Reply-To: <7vy6vnf3aw.fsf@gitster.siamese.dyndns.org>
On Mon, Mar 02, 2009 at 11:55:51PM -0800, Junio C Hamano wrote:
> As with the previous "git init --remote" patch, my design constraints
> includes keeping the door open for "git shell" users to optionally allow
> this mode of operation.
OK, I thought your original comment was "I don't think this constraint
(thinking only of normal shell users) is right, but here is a patch
anyway". Which did leave me confused, since it seemed like your patch
did not cater just to such users. But I see now what you meant.
However, if you are thinking of "git shell" users, then is it not a
potential security problem to allow them to create new repositories
without the admin explicitly enabling it? If a site is depending on
hooks in existing repositories to implement some kind of policy, then
isn't this a way to bypass it (not to make changes in those existing
repos, obviously, but let's say there is a policy about how disk usage
is counted).
Even if it isn't a security issue, it might simply be broken. Shawn has
said that Gerrit needs extra magic when creating a repository, and I
wouldn't be surprised if github and repo.or.cz were the same. With your
patch, what switch should a Gerrit admin flip to prevent people from
creating broken repos?
What about places that might simply want to put some policy in place,
like kernel.org having all linux repos point to Linus as alternates?
-Peff
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Junio C Hamano @ 2009-03-03 8:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <76718490903030002u5a7babe2k6f26b4cc4b48c9d1@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Tue, Mar 3, 2009 at 2:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jay Soffian <jaysoffian@gmail.com> writes:
>>
>>> I concur w/Jeff and I think git probably should not as well. I think
>>> that instead adding it to init might be interesting
>>
>> The thing is Jeff and Shawn already rejected that route.
>
> Okay. I missed that, so I'll go search for it, but it still seems like
> "init [<path>|ssh://]" should be the basis for "push --init".
It was called "init --remote".
No need to look for it; it is one of the message on the References line of
this message, iow, in *this* thread.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Junio C Hamano @ 2009-03-03 8:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <76718490903030002u5a7babe2k6f26b4cc4b48c9d1@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Tue, Mar 3, 2009 at 2:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jay Soffian <jaysoffian@gmail.com> writes:
>>
>>> I concur w/Jeff and I think git probably should not as well. I think
>>> that instead adding it to init might be interesting
>>
>> The thing is Jeff and Shawn already rejected that route.
>
> Okay. I missed that, so I'll go search for it, but it still seems like
> "init [<path>|ssh://]" should be the basis for "push --init".
It was called "init --remote".
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-03 8:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <7vtz6bf392.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 3, 2009 at 2:56 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> I concur w/Jeff and I think git probably should not as well. I think
>> that instead adding it to init might be interesting
>
> The thing is Jeff and Shawn already rejected that route.
Okay. I missed that, so I'll go search for it, but it still seems like
"init [<path>|ssh://]" should be the basis for "push --init".
j.
^ permalink raw reply
* Re: git-add and index
From: Junio C Hamano @ 2009-03-03 8:00 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090303072008.GB7478@b2j>
bill lam <cbill.lam@gmail.com> writes:
> I have 2 questions related to index
> 1. Is it safe to just git-add (without commit) for local changes made
> before checkout or switch to another branch?
As long as the other branch does not touch the same path, it should be kept
in the index during the branch switching.
"Is it safe" and "does it work like this" questions are easier to answer by
a bit of experimenting in a toy repository these days ;-).
> 2. How to checkout the changes as recorded in index from git-add that
> not yet commit to the working tree?
"git checkout -- path"? If you do not have a revision that can be referred
to as path (iow the file you are trying to check out of the index is not
e.g. "master"), you do not have to say -- and just "git checkout path"
should suffice.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Junio C Hamano @ 2009-03-03 7:56 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Shawn O. Pearce, git
In-Reply-To: <76718490903022337n79a0c11cw95e80d99cd598d17@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> I concur w/Jeff and I think git probably should not as well. I think
> that instead adding it to init might be interesting
The thing is Jeff and Shawn already rejected that route.
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Lars Noschinski @ 2009-03-03 7:56 UTC (permalink / raw)
To: Peter Krefting; +Cc: Thomas Rast, git
In-Reply-To: <alpine.DEB.2.00.0903022135360.20047@perkele.intern.softwolves.pp.se>
* Peter Krefting <peter@softwolves.pp.se> [09-03-02 21:41]:
> Indeed. It is unfortunate that this wasn't properly specified to start with.
> It's mostly a minor issue since *most* people will not use non-ASCII file
> names. At least for most of the kind of projects that Git have attracted so
> far, so the problem is not that big. The problem is if Git is to attract "the
> masses". Especially on Windows, where file names using non-ASCII are common,
> this needs to be addressed eventually.
Using no encoding for filenames was the obvious (and I would argue)
correct choice. Unix filenames are specified to be a sequence of bytes,
excluding '/' and '\0'. A lot of these sequences are not valid UTF-8.
Further, the encoding needed for filenames depends on the encoding used
in the source code for referencing these files. Again, for the unix file
handling functions, this means no encoding.
Changing the filename (on checkout), so that the user sees an Ü
regardless of his or her locale (instead of an \0xDC, which only
resolves to an Ü on latin-1) would be an absolutely broken concept here.
> >[*] I'm _extremely_ tempted to write "people using non-broken OSes", but let's
> >pretend to be neutral for a second.
>
> In most cases, I would most definitely agree with you on calling it that, but
> when it comes to Unicode support, Windows is one of the least broken OSes (with
> Symbian being my favourite).
IMHO having encoding specific open functions is begging for problems.
- Lars.
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Junio C Hamano @ 2009-03-03 7:55 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn O. Pearce, git
In-Reply-To: <20090303070937.GB30609@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> If you are going to limit it in that way, wouldn't it be better to do it
> entirely client-side? As in, "git push --create remote" will literally
> do:
>
> ssh remote_host "mkdir -p remote_dir && cd remote_dir && git init --bare"
>
> ? Then you don't have to care about whether the remote side is recent
> enough to support this, and there are no potential security issues; git
> is merely saving you from typing the commands you could have done
> yourself.
As with the previous "git init --remote" patch, my design constraints
includes keeping the door open for "git shell" users to optionally allow
this mode of operation.
^ permalink raw reply
* Re: topgit patches
From: martin f krafft @ 2009-03-03 7:54 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: Petr Baudis, git
In-Reply-To: <20090302162641.GB15229@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2009.03.02.1726 +0100]:
> > it. But if someone else has the time, maybe we can prepare a 0.6
> > without a new option parser?
> I assume you planned to use git rev-parse --parseopt?
Yes.
> Since topgit-0.5 we have some fixes, a new export method and improved
> bash completion. Just repackaging the current state into a new Debian
> package closes 4 bugs in the Debian BTS.
>
> Before 0.6 I still need to write some documentation for the new export
> method, but after that I consider releasing the then current state as
> 0.6 is a good idea.
>
> martin, Petr, others: any comments? Should I just tag if I feel ready?
Sounds good to me, even without parseopt. Thanks Uwe for stepping in
to help us!
> martin: I can try to prepare the Debian package, AFAIK I cannot
> upload it, so here I need your help. (And maybe you should check
> the package, because up to now I only created Debian packages for
> my private use.)
Possibly the easiest way to do this is http://mentors.debian.net, so
if that's okay with you, send me the URL to the uploaded .dsc file
and I will look at it and get back to you. If you don't want to
bother creating the source package, just let me know which commit ID
to build (don't tag debian/* until after the upload).
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"if you are going to run a rinky-dink distro made by a couple of
volunteers, why not run a rinky-dink distro made by a lot of
volunteers?"
-- jaldhar h. vyas
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] git filter-branch: Process commits in --date-order
From: Johannes Sixt @ 2009-03-03 7:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Peter Rosin, Git Mailing List
In-Reply-To: <7vbpsjl97d.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I am wondering if it even makes sense to allow users to disable
> topological ordering.
>
> Doesn't filter-branch have the same "child commits build on top of parent
> commits" dependency as fast-export has? And didn't you guys fix
> fast-export recently?
Doesn't --date-order have the same guarantee as --topo-order with respect
to parents and children, only that commits that can be rearranged such
that the guarantee remains are emitted in date order?
Anyway, the patch is unnecessary: If --date-order is needed, it can be
passed on the command line; this will override --topo-order.
-- 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