* Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Nanako Shiraishi @ 2009-03-05 10:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpsg2sgx.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> * jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
> + never fallback relative times to absolute
>
> I think I sent out a "here is how" patch for something related to
> --date=<format> option that may be related to this topic; I seem to have
> lost it.
Do you mean this one?
http://article.gmane.org/gmane.comp.version-control.git/112033
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: How to ignore a modified file?
From: Sverre Rabbelier @ 2009-03-05 10:09 UTC (permalink / raw)
To: Quim K Holland; +Cc: dealmaker, git
In-Reply-To: <20090305145308.6117@qkholland.gmail.com>
Heya,
On Thu, Mar 5, 2009 at 09:53, Quim K Holland <qkholland@gmail.com> wrote:
> You can run "git checkout directory".
Yes, but that would destroy his changes, I do not get the impression
that that's what he wants...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Junio C Hamano @ 2009-03-05 10:07 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, but embarrasingly enough we
already have a real commit on 'maint'.
----------------------------------------------------------------
[New Topics]
* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
- cvsimport: add test illustrating a bug in cvsps
Yet more tests without fixing anything...
* jc/clone-branch-rebase (Tue Mar 3 22:29:55 2009 -0800) 1 commit
- Make git-clone respect branch.autosetuprebase
This is rewrite of a patch from Pat Notz.
* mg/maint-submodule-normalize-path (Tue Mar 3 16:08:21 2009 +0100) 2 commits
- git submodule: Fix adding of submodules at paths with ./, .. and //
- git submodule: Add test cases for git submodule add
* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
- stat_tracking_info(): only count real commits
This gives the merge commits zero weight when talking about how many
commits you have ahead (or behind) of the branch you are tracking. Even
though I agree that they should carry much less weight than the "real"
commits, because your repeated merge from the other branch does not really
add any real value to the end result, giving them absolute zero weight
somehow feels wrong. At least it shows that your have been _active_ on the
branch. But I do not feel very strongly about it.
* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit
- rebase -i: avoid 'git reset' when possible
----------------------------------------------------------------
[Will merge to 'master' soon]
* jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
+ never fallback relative times to absolute
I think I sent out a "here is how" patch for something related to
--date=<format> option that may be related to this topic; I seem to have
lost it.
* 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
* 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
* 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
* 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.
* 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. Jakub seems to want this for gitweb.
* 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
----------------------------------------------------------------
[Discarded]
* 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().
* ns/stash-keep (Thu Feb 12 06:25:14 2009 +0900) 1 commit
. stash: --keep option just saves
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* 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/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.
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.
* 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, so I'll probably discard these three
shortly.
----------------------------------------------------------------
[Actively cooking]
* kb/checkout-optim (Wed Mar 4 18:47:40 2009 +0100) 15 commits
- better introduction of GIT with USE_NSEC defined
+ 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
* 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.
* jc/push-to-create (Mon Mar 2 22:36:16 2009 -0800) 1 commit
- Push to create
This was a failed weatherbaloon patch to allow creation of a new
repository from the remote side. Will discard.
* 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
* 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
* jk/clone-post-checkout (Tue Mar 3 00:37:51 2009 -0500) 1 commit
- clone: run post-checkout hook when checking out
* 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
* 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
* el/blame-date (Fri Feb 20 14:51:11 2009 -0800) 1 commit
- Make git blame's date output format configurable, like git log
I think the above seven series were basically Ok; I'll hopefully have time
to re-read them and merge them to 'next'.
* 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
Tests without fixes are of dubious value. Any takers?
* 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
Tests?
* 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
This is in response to Linus's "Really slow 'git gc'" ($gmane/110743)
* en/maint-hash-object (Sat Feb 28 12:56:49 2009 -0700) 1 commit
+ Ensure proper setup of git_dir for git-hash-object
Obvious fix that can also go to 1.6.1.X
* 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 (Wed Feb 18 11:17:27 2009 -0800) 14 commits
- tests: fix "export var=val"
- 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
Rebased and then kicked back to 'pu' to give the author a chance to
rearrange if necessary. I might do some trivial squashing myself.
----------------------------------------------------------------
[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
These are for 1.7.0, but the messages when they trigger together may need
to be rethought.
* 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.
Will be discarded.
^ permalink raw reply
* What's in git.git (Mar 2009, #02; Thu, 05)
From: Junio C Hamano @ 2009-03-05 10:07 UTC (permalink / raw)
To: git
The release is out, and immediately after that somebody spots a minor
bug.
If things go as planned, tomorrow we will see a mass graduation to the
master branch of topics that have been cooking in next during the pre
release freeze period.
* The 'maint' branch has these fixes since v1.6.2
John Tapsell (1):
Make the 'lock file' exists error more informative
Junio C Hamano (1):
Beginning of 1.6.2 maintenance track
* The 'master' branch has these since v1.6.2 in addition to the above.
Carlos Manuel Duclos Vergara (1):
git-archive: add --output=<file> to send output to a file
Christian Couder (1):
rev-list: estimate number of bisection step left
Jeff King (1):
improve missing repository error message
John Tapsell (3):
Modify description file to say what this file is
Google has renamed the imap folder
Improve error message for git-filter-branch
Keith Cascio (2):
Use DIFF_XDL_SET/DIFF_OPT_SET instead of raw bit-masking
Fix neglect of diff_setup()/diff_setup_done() symmetry.
^ permalink raw reply
* Re: More git bisect modes
From: Nanako Shiraishi @ 2009-03-05 10:05 UTC (permalink / raw)
To: John Tapsell; +Cc: Git Mailing List
In-Reply-To: <43d8ce650903050149u4ca98444w28efceb9084efa68@mail.gmail.com>
Quoting John Tapsell <johnflux@gmail.com>:
> * An exponential back-off. Typically I know that HEAD is broken, and
> I don't know when it used to work.
I thought 'git bisect' already worked with only bad commit(s) without any good commit for a long time?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* More git bisect modes
From: John Tapsell @ 2009-03-05 9:49 UTC (permalink / raw)
To: Git Mailing List
Hi,
Although "git bisect" is called, well, bisect, it would be nice to
have other modes.
* A completely linear version - check every version. Particularly
useful after rebasing to make sure all the commits still compile.
* An allow-for-mistakes-bisect. This would use a bisection technique
that would allow for a minimum of 1 mistake when marking a commit good
or bad. This point isn't particularly to help those with fat fingers,
but for bugs that are subtle and for bugs that are caused by multiple
commits. (I can go into the details of how to do such a bisect
later).
* An exponential back-off. Typically I know that HEAD is broken, and
I don't know when it used to work. It would be nice to exponentially
go back through the commits to find the first working commit, then
bisect from there.
Before I start working on the code for any of these, do people like
this? Would this fit into the 'git bisect' command?
John
^ permalink raw reply
* Re: git push
From: Finn Arne Gangstad @ 2009-03-05 9:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, John Tapsell, Git Mailing List
In-Reply-To: <49AF9117.1020407@op5.se>
On Thu, Mar 05, 2009 at 09:45:11AM +0100, Andreas Ericsson wrote:
> Worst-case scenario, you commits that were never intended for publication
> enter your public wateringhole and needs a revert later on. Big deal.
It could be a very big deal depending on what the contents are. I
think you can split developers in two groups - those who like to learn
a lot about version control systems, and those who just see it as a
necessary evil to get their job done. The latter seems to be the
majority.
The first group will know how to undo the damage from a bad push (and
probably configure their setup so they do not necessarily happen),
while the second group will not necessarily notice that it happened or
know how to undo it. So, bad pushes go through, and are not detected
before 3 other people base their work on it, and we get a lot of
hassle.
>> It is not realistic to believe that in a big project with many
>> developers, no one will ever do the mistake of typing "git push". It
>> is also not realistic to believe that everyone will know how to (or
>> remember to) configure this away.
>
> But it *is* realistic to not assume that they will also use --force
> while doing so.
Our public repos are set up so that only a few chosen people are
allowed to force pushes, so this is not an issue for us.
>> If "git push" could do nothing at all without configuring anything, that
>> would be a big improvement to us.
>
> I can buy this, I guess. I always type the remote-name I want to push to
> anyways. A sane no-op default would probably be to list the pre-configured
> remotes along with a short usage message. I still don't quite see the point
> of it.
I'll try to whip up a small patch series tonight and see what it ends
up looking like.
- Finn Arne
^ permalink raw reply
* Re: can not clone via git:// anymore
From: Hinko Kocevar @ 2009-03-05 9:16 UTC (permalink / raw)
To: Jeff King; +Cc: Michael J Gruber, git
In-Reply-To: <20090304142459.GB17874@coredump.intra.peff.net>
Jeff King wrote:
> On Wed, Mar 04, 2009 at 02:28:40PM +0100, Hinko Kocevar wrote:
>
>> git-daemon was/is running:
>>
>> CETRTAPOT\zidarhw@zidar:~$ ps -ef | grep git
>> root 3207 1 0 14:15 ? 00:00:00 runsvdir -P /etc/service log: d user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?
>> root 3208 3207 0 14:15 ? 00:00:00 runsv git-daemon
>> root 3373 3208 0 14:16 ? 00:00:00 git-daemon --verbose --base-path=/var/cache /var/cache/git
>> 11418 3399 2762 0 14:16 pts/0 00:00:00 grep git
>
> See all the runsvdir errors? That probably means that git-daemon's log
> output is going nowhere, since the log is not running. Which means
> eventually the pipe from git-daemon to the log will get full, and
> git-daemon will block writing out the log. And then stop dealing with
> requests.
>
> So even if restarting helps now, it may fill up again unless you fix the
> logging problem (presumably by creating the right "gitlog" user).
I added the 'gitlog' user yesterday too, when I noticed that unusual runsvdir line.
ps output:
CETRTAPOT\zidarhw@zidar:~$ ps -ef | grep git
git 5547 1 0 Mar04 ? 00:00:00 /usr/bin/git-daemon --reuseaddr --verbose --detach --base-path=/home/git/repositories/ --export-all
Thank you!
--
Hinko Kočevar, OSS developer
ČETRTA POT, d.o.o.
Planina 3, 4000 Kranj, SI EU
tel ++386 (0) 4 280 66 03
e-mail hinko.kocevar@cetrtapot.si
http www.cetrtapot.si
^ permalink raw reply
* Re: [PATCH] '%S' option for pretty printing to support --source
From: Jeff King @ 2009-03-05 9:17 UTC (permalink / raw)
To: Petri Hodju; +Cc: Deskin Miller, git, gitster
In-Reply-To: <200903050918.29051.petri.hodju@yumesystems.com>
On Thu, Mar 05, 2009 at 09:18:28AM +0200, Petri Hodju wrote:
> +static void format_source(struct strbuf *sb, const struct commit *commit)
> +{
> + if (commit->util)
> + strbuf_addstr(sb, (char *) commit->util);
> +}
> +
Hmm. This is the second patch in the last few weeks to use commit->util
to carry information for --pretty=format: (I am cc'ing Deskin Miller,
who wrote the first).
They cannot both work, obviously. So we need to do one of:
- refactor the information out of commit->util to somewhere else
- allow multiple commit->util users somehow (which I think is a
potential performance problem -- the simplistic design is meant to
avoid things like allocation overhead)
- gracefully block concurrent use of conflicting features
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Johannes Sixt @ 2009-03-05 9:11 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Junio C Hamano
In-Reply-To: <6d937a859ca499f534eea08720fca84f3d4ded2f.1236187259.git.barvik@broadpark.no>
Kjetil Barvik schrieb:
> - istate->timestamp.sec = st.st_mtime;
> -#ifdef USE_NSEC
> + istate->timestamp.sec = (unsigned int)st.st_mtime;
> istate->timestamp.nsec = (unsigned int)st.st_mtim.tv_nsec;
> -#else
> - istate->timestamp.nsec = 0;
> -#endif
Doesn't this break on systems where st_mtime is time_t and st_mtim does
not exist?
-- Hannes
^ permalink raw reply
* Re: ignored files stilll listed in git ls-files
From: Jeff King @ 2009-03-05 9:09 UTC (permalink / raw)
To: David Shen; +Cc: git
In-Reply-To: <53e35fd50903041731v1a3c10c9sbb9295f322a819ce@mail.gmail.com>
On Thu, Mar 05, 2009 at 09:31:55AM +0800, David Shen wrote:
> I add all the files to git before I learned the .gitignore file. Then
> I remove those unwanted files from the index. But those files still
> appear in git ls-files. This is really annoying. Is there any want to
> prevent those ignored files from git ls-files?
If they are appearing in "git ls-files", then you didn't actually remove
them from the index. Can you show us exactly which commands you ran,
what output they produced, and how it differs from what you expected?
-Peff
^ permalink raw reply
* Re: Chicken/egg problem building from a 'git clone'
From: Andreas Ericsson @ 2009-03-05 9:06 UTC (permalink / raw)
To: gyles19; +Cc: Junio C Hamano, Jeff King, Miles Bader, Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.44.0903010945290.4675-100000@localhost.localdomain>
Joi Ellis wrote:
> On Fri, 6 Feb 2009, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> Now, in this case, it was only one tweak and other responders have
>>> already pointed him in the right direction. So just making that tweak
>>> manually is probably the sane thing to do in this situation.
>>>
>>> But I wanted to point out that autoconf is not totally without value
>>> here.
>> I am not saying something that strong, either. If autoconf generated
>> configure works _for you_ without hassle, great. Keep using it.
>>
>> The original message that started this thread was what to do when it does
>> NOT work for you, and my point was in general it is much nicer to point at
>> the knob to tweak from the make invocation command line (or in config.mak)
>> than having you spend time on upgrade autoconf, generate configure and run
>> it.
>
> Actually, guys, if you go back and re-read my original message, I was
> pointing out that if you use a 'git clone' to get a build tree, THERE IS
> NO CONFIGURE SCRIPT in the tree.
>
> The problem is not that the configure script does not work. I pointed
> out in the first paragraph that the configure script in the TARBALL
> works just fine. What I pointed out is that the build tree DOES NOT
> PROVIDE THE CONFIGURE SCRIPT. All I asked you to do is to consider
> adding the configure script to the repository so that it gets pushed out
> in a clone.
>
>> Fanboys may say that autoconf generated configure is the greatest thing
>> since sliced bread. But let's face it. Honestly, the track record of
>> those people in keeping autoconf part in this project up-to-date has not
>> been all that great. There are things that the generated configure file
>> does not detect nor configure correctly (we had --with-expat patch, and we
>> also saw "the trailing slash in template_dir definition in config.mak.in"
>> discussed fairly recently). You are much better off tweaking known
>> peculiarity of your platform in config.mak, when configure does not work
>> out of box for you.
>
> I've been building and installing multi-platform *nix software on
> various flavors for two decades now. "./configure && make && make install" has
> been the standard build process even before GNU. The whole point of
> autoconf/configure/make tools is to eliminate the need to manually tweak
> makefiles so that software is easily portable between platforms.
>
./configure is a generated script. Including it in the repository is not
something many projects do, since one of the things developers will be
working on is to change how that file is generated. Including it in the
release tar-balls is something every project (that uses autoconf) does,
since those are aimed at end-users.
It has not been the standard since before GNU, as the GNU project was
started quite a long time (well over a decade) before autoconf's inception.
> I got such a rash of SNOTTY messages from you folks, all directed to me
> privately, that I nearly deleted git from my laptop altogether.
I guess you're referring to the "To: " and "Cc: " fields of the emails
you received containing your address. For this particular list, that's
part of how we do things. It's quite common on high-volume lists to do
that, as people would otherwise have to sift through *all* the mail on
the list to figure out which emails are replies to their own questions
or patches. Somewhere in the Cc list you will see git@vger.kernel.org,
I'm sure.
> You can be
> sure I will not bother attempting to build git from a clone ever again.
> I took the time to debug and diagnose the build failures I was getting,
> and I tried to politely pass it along in case anyone cares.
>
Thank you for that.
> Clearly, you don't. I shall not waste your or my time any further.
>
And again, thank you for that.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: git push
From: Andreas Ericsson @ 2009-03-05 8:45 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Junio C Hamano, John Tapsell, Git Mailing List
In-Reply-To: <20090225225826.GA13510@pvv.org>
Finn Arne Gangstad wrote:
> Sorry to people receiving this mail twice, the list ate my first reply
> since it managed to hit the spam-filter (maybe I should take a hint... :)
>
> On Tue, Feb 24, 2009 at 11:01:38PM -0800, Junio C Hamano wrote:
>> [...]
>>
>> But if you are talking about changing the default when "git push" is run
>> without any parameter, I have to say it is a terrible idea, for two
>> reasons, and one is too obvious to state so I wouldn't repeat it and talk
>> only about the other one.
>
> The current default behaviour of git push is very annoying for us at
> least. The current behaviour is _dangerous_ and leads to serious
> problems. It is too easy for someone to write "git push". They hit
> enter too soon, or they write it expecting to get usage
> information. They do not necessarily expect to overwrite random
> branches in a remote repository.
>
> Most git commands are not destructive with no arguments at all, and
> push is the _only_ command that really can screw things up for others,
> so this command in particular should refrain from destructive default
> behaviour.
>
> An example of random branch overwriting:
> $ mkdir a
> $ cd a
> $ git init
> $ echo contents > file
> $ git add file
> $ git commit -m message
> $ cd ..
> $ git clone a b
> $ cd b
> $ git checkout -b gif-support
> $ echo foo > somefile
> $ git add somefile
> $ git commit -m message
> $ ( cd ../a && git branch gif-support) # Assume done by someone else
> $ git checkout master
> $ # <hack away, maybe commit a bit>
> $ git push # <-- OOOPS! pushes gif-support!
>
> Notice that what branches git push ends up pushing is out of your
> control, since new branches can appear in the remote repository at any
> time. This is very unfriendly in our setup with a shared incoming repo.
>
> If developer A creates "gif-support", shares it with developer B, who
> does an additional commit on it to make it print more debug info (but
> has no intent of pushing it anywhere), and A pushes it to the "incoming"
> repo, developer B risks overwriting that with his debug version.
>
git push will never overwrite changes in the remote repo unless you
specify --force. If anyone *blindly* uses --force, they really shouldn't
have write-access to anything so precious as your code repositories.
Worst-case scenario, you commits that were never intended for publication
enter your public wateringhole and needs a revert later on. Big deal.
> It is not realistic to believe that in a big project with many
> developers, no one will ever do the mistake of typing "git push". It
> is also not realistic to believe that everyone will know how to (or
> remember to) configure this away.
>
But it *is* realistic to not assume that they will also use --force
while doing so.
>> If you shoot for the least damage for such people, the sanest default for
>> "git push" would be to do nothing. You *always* say what to push where,
>> then there is no risk of pushing something you did not intend to. Perhaps
>> "push.default = never" configuration may not be such a bad idea?
>
> If "git push" could do nothing at all without configuring anything, that
> would be a big improvement to us.
>
I can buy this, I guess. I always type the remote-name I want to push to
anyways. A sane no-op default would probably be to list the pre-configured
remotes along with a short usage message. I still don't quite see the point
of it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: just curious: what influences a commit hash?
From: Uwe Kleine-König @ 2009-03-05 9:02 UTC (permalink / raw)
To: Matt Enright; +Cc: stoecher, git
In-Reply-To: <1236237939.2421.38.camel@virgil>
Hi,
On Thu, Mar 05, 2009 at 02:25:39AM -0500, Matt Enright wrote:
> On Thu, 2009-03-05 at 07:36 +0100, stoecher@gmx.at wrote:
> > Hi,
> >
> > being new to git I did some experiments with commits looking at the hashes. What I observed:
> > * The same commit (same file, same committer, same message) into different empty repositories (git init) gives different hashes. So I assume that also the time of the commit influences the hash. Is this intended? For what reason?
Yes, commit time and commit date influence the hash.
But the hashes for the corresponding trees should be the same.
Check the output of git rev-parse $commit^{tree}.
If you want to reproduce the exact same commit, you need to set
the env variables GIT_AUTHOR_DATE and GIT_COMMITTER_DATE. (Not sure,
but GIT_AUTHOR_DATE might be handled by git am.)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: git push
From: John Tapsell @ 2009-03-05 8:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Finn Arne Gangstad, Junio C Hamano, Git Mailing List
In-Reply-To: <49AF9117.1020407@op5.se>
2009/3/5 Andreas Ericsson <ae@op5.se>:
> Finn Arne Gangstad wrote:
>>
>> Sorry to people receiving this mail twice, the list ate my first reply
>> since it managed to hit the spam-filter (maybe I should take a hint... :)
>>
>> On Tue, Feb 24, 2009 at 11:01:38PM -0800, Junio C Hamano wrote:
>>>
>>> [...]
>>>
>>> But if you are talking about changing the default when "git push" is run
>>> without any parameter, I have to say it is a terrible idea, for two
>>> reasons, and one is too obvious to state so I wouldn't repeat it and talk
>>> only about the other one.
>>
>> The current default behaviour of git push is very annoying for us at
>> least. The current behaviour is _dangerous_ and leads to serious
>> problems. It is too easy for someone to write "git push". They hit
>> enter too soon, or they write it expecting to get usage
>> information. They do not necessarily expect to overwrite random
>> branches in a remote repository.
>>
>> Most git commands are not destructive with no arguments at all, and
>> push is the _only_ command that really can screw things up for others,
>> so this command in particular should refrain from destructive default
>> behaviour.
>>
>> An example of random branch overwriting:
>> $ mkdir a
>> $ cd a
>> $ git init
>> $ echo contents > file
>> $ git add file
>> $ git commit -m message
>> $ cd ..
>> $ git clone a b
>> $ cd b
>> $ git checkout -b gif-support
>> $ echo foo > somefile
>> $ git add somefile
>> $ git commit -m message
>> $ ( cd ../a && git branch gif-support) # Assume done by someone else
>> $ git checkout master
>> $ # <hack away, maybe commit a bit>
>> $ git push # <-- OOOPS! pushes gif-support!
>>
>> Notice that what branches git push ends up pushing is out of your
>> control, since new branches can appear in the remote repository at any
>> time. This is very unfriendly in our setup with a shared incoming repo.
>>
>> If developer A creates "gif-support", shares it with developer B, who
>> does an additional commit on it to make it print more debug info (but
>> has no intent of pushing it anywhere), and A pushes it to the "incoming"
>> repo, developer B risks overwriting that with his debug version.
>>
>
> git push will never overwrite changes in the remote repo unless you
> specify --force. If anyone *blindly* uses --force, they really shouldn't
> have write-access to anything so precious as your code repositories.
It's seems a very likely scenario to me.
I work on a remote branch with one other person, to make some new
feature. Once we are done, I rebase and get rid of the cruft from the
history, then "git push --force" to update the branch. Whoops, I've
just unknowingly wiped out a completely different branch.
>
> Worst-case scenario, you commits that were never intended for publication
> enter your public wateringhole and needs a revert later on. Big deal.
>
>> It is not realistic to believe that in a big project with many
>> developers, no one will ever do the mistake of typing "git push". It
>> is also not realistic to believe that everyone will know how to (or
>> remember to) configure this away.
>>
>
> But it *is* realistic to not assume that they will also use --force
> while doing so.
>
>>> If you shoot for the least damage for such people, the sanest default for
>>> "git push" would be to do nothing. You *always* say what to push where,
>>> then there is no risk of pushing something you did not intend to.
>>> Perhaps
>>> "push.default = never" configuration may not be such a bad idea?
>>
>> If "git push" could do nothing at all without configuring anything, that
>> would be a big improvement to us.
>>
>
> I can buy this, I guess. I always type the remote-name I want to push to
> anyways. A sane no-op default would probably be to list the pre-configured
> remotes along with a short usage message. I still don't quite see the point
> of it.
If people don't agree on changing 'git push' to affect only the
current branch, I would also go for making 'git push' a noop.
John
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
> Considering the successes of the wars on alcohol, poverty, drugs and
> terror, I think we should give some serious thought to declaring war
> on peace.
>
^ permalink raw reply
* Re: How to ignore a modified file?
From: Quim K Holland @ 2009-03-05 8:53 UTC (permalink / raw)
To: dealmaker; +Cc: git
You can run "git checkout directory".
> Hi,
> I run "git status", and I saw the a modified file in a directory. I want
> to ignore all files in that directory. I put the directory name into
> .gitignore, but it still shows as modified file. Why? How do I ignore the
> directory?
> Thanks.
> --
> View this message in context: http://n2.nabble.com/How-to-ignore-a-modified-file--tp2428157p2428157.html
> Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Clarify the "cannot lock existing info/refs" error
From: Clemens Buchacher @ 2009-03-05 8:50 UTC (permalink / raw)
To: John Tapsell; +Cc: git
In-Reply-To: <43d8ce650903050000g4466ab2fne5fb8ed009808346@mail.gmail.com>
On Thu, Mar 05, 2009 at 08:00:37AM +0000, John Tapsell wrote:
> On google I found that people had been getting that error if they have
> the wrong password.
That's easy enough to verify. Using the wrong username/password I get
error: Cannot access URL $url, return code 22
error: failed to push some refs to '$url'
which is not very helpful, but otherwise unrelated.
> -fprintf(stderr, "Error: cannot lock existing info/refs\n");
> +error("cannot lock existing info/refs on remote server\n");
That's a less ambiguous but equally unhelpful error message.
^ permalink raw reply
* Re: How to ignore a modified file?
From: Sverre Rabbelier @ 2009-03-05 8:50 UTC (permalink / raw)
To: dealmaker; +Cc: git
In-Reply-To: <1236242659559-2428157.post@n2.nabble.com>
Heya,
On Thu, Mar 5, 2009 at 09:44, dealmaker <vinkhc@gmail.com> wrote:
> [...] How do I ignore [a tracked] directory?
$ git rm -rf --cached dirname && git commit -m "Removed directory from git"
Git will tell you about changes to the contents of the directory until
you stop tracking it. --cached will prevent the folder from actually
being removed from your harddisk.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* How to ignore a modified file?
From: dealmaker @ 2009-03-05 8:44 UTC (permalink / raw)
To: git
Hi,
I run "git status", and I saw the a modified file in a directory. I want
to ignore all files in that directory. I put the directory name into
.gitignore, but it still shows as modified file. Why? How do I ignore the
directory?
Thanks.
--
View this message in context: http://n2.nabble.com/How-to-ignore-a-modified-file--tp2428157p2428157.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* how to track a file which index has been removed?
From: David Shen @ 2009-03-05 8:37 UTC (permalink / raw)
To: git
Hi,
I removed the index of a file using git update-index --remove by
mistake. I tried to use git update-index --add to add it back. But the
change to the file still not tracked. how to fix this?
--
Best Regards,
David Shen
^ permalink raw reply
* Re: [PATCH] Clarify the "cannot lock existing info/refs" error
From: John Tapsell @ 2009-03-05 8:00 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <20090304192853.GA10567@localhost>
2009/3/4 Clemens Buchacher <drizzd@aon.at>:
> On Wed, Mar 04, 2009 at 03:37:06PM +0000, John Tapsell wrote:
>> -fprintf(stderr, "Error: cannot lock existing info/refs\n");
>> +error("cannot lock existing info/refs on remote server\nPerhaps the
>> server is currently busy, or your ~/.netrc file is not configured
>> correctly.");
>
> In my experience this is usually caused by http-push crashing and leaving
> stale locks behind until it times out after 10 minutes. I don't think we
> should speculate here unless we can narrow down the error condition.
Yeah, I was thinking of trying to narrow it down as well.
I personally get that error 3 out of 4 times, roughly, that I try to
push. But that's probably because I'm using a very busy git server.
So in my case, I just keep retrying until it succeeds.
On google I found that people had been getting that error if they have
the wrong password.
Can we at least change it to:
-fprintf(stderr, "Error: cannot lock existing info/refs\n");
+error("cannot lock existing info/refs on remote server\n");
It's currently confusing as to whether it's a local error or a remote error.
John
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Junio C Hamano @ 2009-03-05 7:38 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <86prgwqvzr.fsf@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> How does this affect a use case where the same index file used with two
>> instances of git (one compiled with and another without USE_NSEC)?
>
> If both persons in this use case use this patch, the one with USE_NSEC
> defined will now be able to take full advantage of the nanosecond
> timestamps at all times.
>
> The one without USE_NSEC defined should not be able to tell the
> difference (without looking into to details of the index file).
As long as the implementation does not give false cleanliness it is
perfectly fine; false dirtinesss is just a bit of wasted cycle.
Thanks.
^ permalink raw reply
* Re: [PATCH] http authentication via prompts
From: Junio C Hamano @ 2009-03-05 7:34 UTC (permalink / raw)
To: Mike Gaffney; +Cc: git
In-Reply-To: <49AF25BF.5060706@gmail.com>
Mike Gaffney <mr.gaffo@gmail.com> writes:
> Currently git over http only works with a .netrc file which required that you store your password on the file system in plaintext. This commit adds to configuration options for http for a username and an optional password. If a http.username is set, then the .netrc file is ignored and the username is used instead. If a http.password is set, then that is used as well, otherwise the user is prompted for their password.
>
> With the old .netrc working, this patch provides backwards compatibility while adding a more secure option for users whose http password may be sensitive (such as if its a domain controller password) and do not wish to have it on the filesystem.
Please wrap lines to readable length, such as under 72 cols.
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index f5152c5..821bf48 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -920,6 +920,13 @@ help.autocorrect::
> value is 0 - the command will be just shown but not executed.
> This is the default.
>
> +http.username, http.password:
> + The username and password for http authentication. http.username is
> + required, http.password is optional. If supplied, the .netrc file will
> + be ignored. If a password is not supplied, git will prompt for it.
> + Be careful when configuring a password as it will be stored in plain text
> + on the filesystem.
> +
> http.proxy::
List item ends with double colons; two headline items that are described
with the same description are listed each on its own line. I.e.
http.username::
http.password::
The username and ...
> diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
> index 622ee5c..462a9d4 100644
> --- a/Documentation/howto/setup-git-server-over-http.txt
> +++ b/Documentation/howto/setup-git-server-over-http.txt
> @@ -189,8 +189,19 @@ Make sure that you have HTTP support, i.e. your git was built with
> libcurl (version more recent than 7.10). The command 'git http-push' with
> no argument should display a usage message.
>
> -Then, add the following to your $HOME/.netrc (you can do without, but will be
> -asked to input your password a _lot_ of times):
> +There are 2 ways to authenticate with git http, netrc and via the git config.
> +The netrc option requires that you put the username and password for the connection
> +in $HOME/.netrc. The configuration method allows you to specify a username and
> +optionally a password. If the password is not supplied then git will prompt you
> +for the password. The downside to the netrc method is that you must have your
> +username and password in plaintext on the filesystem, albeit in a protected file.
> +If the username/password combo is a sensitive one, you may wish to use the
> +git config method. The downside of the config method is that you will be prompted
> +for your password every time you push or pull to the remote repository.
The contents look readable, but each line is a bit too long.
> @@ -204,7 +215,7 @@ instead of the server name.
>
> To check whether all is OK, do:
>
> - curl --netrc --location -v http://<username>@<servername>/my-new-repo.git/HEAD
> + curl --netrc --location -v http://<servername>/my-new-repo.git/HEAD
Why?
> @@ -213,12 +224,31 @@ Now, add the remote in your existing repository which contains the project
> you want to export:
>
> $ git-config remote.upload.url \
> - http://<username>@<servername>/my-new-repo.git/
> + http://<servername>/my-new-repo.git/
Why?
> +Using git config:
The bulk of text before this does not have a subtitle like this. Perhaps
you would want to add one? The presense of this subtitle makes it clear
that you are going to talk about _another_ way, but for first time readers
it is unclear how that other way is different and what its advantages are.
Perhaps drop this subtitle, and instead give one short paragraph, e.g.
Instead of storing your password in plaintext $HOME/.netrc file, you
can store only the username in the configuration file and have the
program prompt for a password. Here is how.
Alternatively keep the subtitle and explain what the subsection is about
in a similar way.
But I think this section raises a bigger usability and user perception
issue.
When "http://user@host/rest" URL is given to your "git push/fetch",
without .netrc nor http.username configuration, we allow the curl library
to prompt for a password, and because we do not reuse the password (and
reinstantiate the curl handle), we end up asking the user million times.
But from the end user's point of view, that's all implementation detail.
It does not explain why "http://user@host/rest" acts in a silly way, and
"http://host/rest" with http.username configuration doesn't.
Perhaps you instead inspect the URL and see if you have the "user" part
(without password), and then:
(1) transform the URL to http://host/rest" before giving it to libcurl;
and
(2) use your CURLOPT_USERPWD logic with your own getpass() call in
init_curl_http_auth()?
That way you do not have (even though you could) to introduce a new
configuration, nor have a new section in the documentation. It will be a
straightforward fix of the "will be asked ... a lot of times" bug you
removed from the documentation, no?
> diff --git a/http.c b/http.c
> index ee58799..348b9fb 100644
> --- a/http.c
> +++ b/http.c
> @@ -26,6 +26,9 @@ static long curl_low_speed_time = -1;
> static int curl_ftp_no_epsv = 0;
> static const char *curl_http_proxy = NULL;
>
> +static const char *curl_http_username = NULL;
> +static const char *curl_http_password = NULL;
> +
Please do not introduce new initializations of static variables to 0 or
NULL. As a clean-up, before your patch, you can send in a patch to fix
existing such initializations.
> +static void init_curl_http_auth(CURL* result){
> +#if LIBCURL_VERSION_NUM >= 0x070907
> + struct strbuf userpass;
> + strbuf_init(&userpass, 0);
> + if (curl_http_username != NULL) {
> + strbuf_addstr(&userpass, curl_http_username);
> + strbuf_addstr(&userpass, ":");
> + if (curl_http_password != NULL) {
> + strbuf_addstr(&userpass, curl_http_password);
> + } else {
> + strbuf_addstr(&userpass, getpass("Password: "));
> + }
> + curl_easy_setopt(result, CURLOPT_USERPWD, userpass.buf);
> + curl_easy_setopt(result, CURLOPT_NETRC, CURL_NETRC_IGNORED);
Why NETRC_IGNORED?
On CURLOPT_NETRC, http://curl.haxx.se/libcurl/c/curl_easy_setopt.html says
libcurl uses a user name (and supplied or prompted password)
supplied with CURLOPT_USERPWD in preference to any of the options
controlled by this parameter.
Does it not work as advertised?
In short, I think what you did in init_curl_http_auth() makes a lot of
sense except for the NETRC_IGNORED bit, but:
(1) I think http.password configuration has the exact same "plaintext
password in a read-protected file" issue as .netrc; it is
unnecessary.
(2) http.username is used by your patch primarily as a way to trigger the
new logic to call getpass() and use CURLOPT_USERPWD. It would be a
lot nicer to inspect the URL to notice that there is a username part
in it and triggering the same codepath. That would be a genuine
improvement (and you can even claim it is a bugfix). And if that
works, the new configuration variable does not add much value (except
that different people involved in the same project can use the same
URL but their own (username, password) pair to access it.
^ permalink raw reply
* Re: just curious: what influences a commit hash?
From: Matt Enright @ 2009-03-05 7:25 UTC (permalink / raw)
To: stoecher; +Cc: git
In-Reply-To: <20090305063632.42880@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
On Thu, 2009-03-05 at 07:36 +0100, stoecher@gmx.at wrote:
> Hi,
>
> being new to git I did some experiments with commits looking at the hashes. What I observed:
> * The same commit (same file, same committer, same message) into different empty repositories (git init) gives different hashes. So I assume that also the time of the commit influences the hash. Is this intended? For what reason?
> * Having created two repositories exactly the same way (the history is the same except for the commit times and hashes) I applied the same patch (using git am) and again I got different hashes for these commits. So in some way also the repository/branch influences the hash of a commit!?
This should be expected if the initial hashes in the history are
different. The hash of a commit is based also on the hashes of all
parent commits - in this way git 'protects' the repository history by
guaranteeing that if two objects have the same hash, they will come from
the same history.
So the second issue is a consequence of the first, though I am not
certain why the first occurs (if the file contents and size are the
same, I would expect the hash for the blob/tree to be the same - maybe
due to git's special handling of initial commits?)
> From reading the Git user's manual, chapter 10, object storage format, I was not expecting this. Can someone explain or give a link to a more detailed description?
>
> thank you,
>
> Wolfgang
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] '%S' option for pretty printing to support --source
From: Petri Hodju @ 2009-03-05 7:18 UTC (permalink / raw)
To: git, gitster
From 79f817e25aada377ccb40ebf76c29af7f21e1ec4 Mon Sep 17 00:00:00 2001
From: Petri Hodju <petrihodju@yahoo.com>
Date: Thu, 5 Mar 2009 09:00:39 +0200
Subject: [PATCH] '%S' option for pretty printing to support --source
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Print out the ref name by which each commit was reached. Works only when --source option is used
Examples:
git-log --graph --pretty=format:"%h(%S) — %s (%cr)" --abbrev-commit --date=relative --source
Show ref by which each commit is reachable in current branch
git-log --graph --pretty=format:"%h(%S) — %s (%cr)" --abbrev-commit --date=relative --source --all
Show ref by which each commit is reachable globally
Signed-off-by: Petri Hodju <petrihodju@yahoo.com>
---
pretty.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 6cd9149..cf05b37 100644
--- a/pretty.c
+++ b/pretty.c
@@ -544,6 +544,12 @@ static void format_decoration(struct strbuf *sb, const struct commit *commit)
strbuf_addch(sb, ')');
}
+static void format_source(struct strbuf *sb, const struct commit *commit)
+{
+ if (commit->util)
+ strbuf_addstr(sb, (char *) commit->util);
+}
+
static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
void *context)
{
@@ -650,6 +656,9 @@ static size_t format_commit_item(struct strbuf *sb, const char *placeholder,
case 'd':
format_decoration(sb, commit);
return 1;
+ case 'S':
+ format_source(sb, commit);
+ return 1;
}
/* For the rest we have to parse the commit header. */
--
1.6.2.rc2.22.g1d035.dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox