Re: [PATCH] submodule: Improve documentation of update subcommand
On Mon, Feb 23 2015, Junio C Hamano wrote: Michal Sojka sojk...@fel.cvut.cz writes: The documentation of 'git submodule update' has several problems: Thanks, this round looks much better. diff --git a/Documentation/config.txt b/Documentation/config.txt index ae6791d..fb2ae37 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2411,12 +2411,17 @@ status.submodulesummary:: submodule.name.path:: submodule.name.url:: +The path within this project and URL for a submodule. These +variables are initially populated by 'git submodule init'; +edit them to override the URL and other values found in the +`.gitmodules` file. See linkgit:git-submodule[1] and +linkgit:gitmodules[5] for details. + The sentence edit them to override talks about other values, which in the original wanted to cover not just path but update as well. By splitting 'update' into its own entry, edit them to override is lost from 'update'. But stepping back a bit, edit them to override applies to all configuration variables. The user edits the configuration file to customize things. I wonder if we even need to say this for .path and url in the first place? Note: not a request to remove it because I hinted so, but a request for comments and discussion, as I do not have a firm opinion. I also thing that edit them to override is kind of useless here so I removed it. submodule.name.update:: -The path within this project, URL, and the updating strategy -for a submodule. These variables are initially populated -by 'git submodule init'; edit them to override the -URL and other values found in the `.gitmodules` file. See -linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. +The default updating strategy for a submodule. This variable +is populated by `git submodule init` from the +linkgit:gitmodules[5] file. See description of 'update' +command in linkgit:git-submodule[1]. diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 8e6af65..067d616 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -154,27 +154,51 @@ If `--force` is specified, the submodule's work tree will be removed even if it contains local modifications. update:: -Update the registered submodules, i.e. clone missing submodules and -checkout the commit specified in the index of the containing repository. -This will make the submodules HEAD be detached unless `--rebase` or -`--merge` is specified or the key `submodule.$name.update` is set to -`rebase`, `merge` or `none`. `none` can be overridden by specifying -`--checkout`. Setting the key `submodule.$name.update` to `!command` -will cause `command` to be run. `command` can be any arbitrary shell -command that takes a single argument, namely the sha1 to update to. + +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The updating can be done in several ways depending +on command line options and the value of `submodule.name.update` +configuration variable. Supported update methods are: If you read the description of --remote (sorry, I didn't notice it until I formatted the result of this patch and tried to read the whole thing), we already use update procedure to mean these modes of updates collectively. Either use update procedures here (and everywhere else in this patch where it is called update method), or adjust the existing update procedure to update method. Either way is fine, but because update procedure is not wrong per-se, I think it would be better to use that phrasing that may already be familiar with the git submodule users. OK, I replaced the method (and strategy in config.txt) with procedure. In the previous version was also a typo, which is fixed now. v5 will follow shortly. Thanks. -Michal -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6] submodule: Improve documentation of update subcommand
Thanks, will queue. I think this round should be ready for 'next'. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] struct ref_lock: delete the force_write member
Michael Haggerty mhag...@alum.mit.edu writes:
Instead, compute the value when it is needed.
@@ -2318,8 +2317,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
lock-ref_name = xstrdup(refname);
lock-orig_ref_name = xstrdup(orig_refname);
ref_file = git_path(%s, refname);
- if ((flags REF_NODEREF) (type REF_ISSYMREF))
- lock-force_write = 1;
retry:
switch (safe_create_leading_directories(ref_file)) {
@@ -3787,8 +3784,13 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
struct ref_update *update = updates[i];
if (!is_null_sha1(update-new_sha1)) {
- if (!update-lock-force_write
- !hashcmp(update-lock-old_sha1, update-new_sha1))
{
+ if (!((update-type REF_ISSYMREF)
+(update-flags REF_NODEREF))
+ !hashcmp(update-lock-old_sha1,
update-new_sha1)) {
+ /*
+ * The reference already has the desired
+ * value, so we don't need to write it.
+ */
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock,
update-new_sha1,
The code before and after the change are equivalent.
It shouldn't be the case, but somehow I find the original slightly
easier to understand. The before and after says the same thing,
i.e. the code used to be:
- We say do the write-out without questioning when we are
updating a symbolic ref without dereferencing.
- Do nothing and unlock if we are not told to do the write-out
without questioning and the update will be a no-op anyway.
while the code after the change says:
+ Do nothing and unlock if we are not handling update a symbolic
ref without dereferencing and the update will be a no-op anyway.
Perhaps the former has the same effect as avoid a single complex
sentence and use two short sentences instead.
The negation in the condition does not help, either.
* If we are updating a symbolic ref without dereferencing, or if we
are updating with a different object name, we definitely have to
write.
would be easier to understand, perhaps? I.e.
if (hashcmp(update-lock-old_sha1, update-lock-new_sha1) ||
((update-type REF_ISSYMREF) (update-flags REF_NO_DEREF))) {
/* do the write-out thing */
} else {
/* the request to update from the same to the same is a no-op */
unlock_ref(update-lock);
update-lock = NULL;
}
I dunno.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] submodule: Improve documentation of update subcommand
The documentation of 'git submodule update' has several problems: 1) It mentions that value 'none' of submodule.$name.update can be overridden by --checkout, but other combinations of configuration values and command line options are not mentioned. 2) The documentation of submodule.$name.update is scattered across three places, which is confusing. 3) The documentation of submodule.$name.update in gitmodules.txt is incorrect, because the code always uses the value from .git/config and never from .gitmodules. 4) Documentation of --force was incomplete, because it is only effective in case of checkout method of update. Fix all these problems by documenting submodule.*.update in git-submodule.txt and make everybody else refer to it. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Jens Lehmann jens.lehm...@web.de Signed-off-by: Michal Sojka sojk...@fel.cvut.cz --- Documentation/config.txt| 15 ++ Documentation/git-submodule.txt | 66 - Documentation/gitmodules.txt| 21 ++--- 3 files changed, 65 insertions(+), 37 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index ae6791d..fb2ae37 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2411,12 +2411,17 @@ status.submodulesummary:: submodule.name.path:: submodule.name.url:: + The path within this project and URL for a submodule. These + variables are initially populated by 'git submodule init'; + edit them to override the URL and other values found in the + `.gitmodules` file. See linkgit:git-submodule[1] and + linkgit:gitmodules[5] for details. + submodule.name.update:: - The path within this project, URL, and the updating strategy - for a submodule. These variables are initially populated - by 'git submodule init'; edit them to override the - URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + The default updating strategy for a submodule. This variable + is populated by `git submodule init` from the + linkgit:gitmodules[5] file. See description of 'update' + command in linkgit:git-submodule[1]. submodule.name.branch:: The remote branch name for a submodule, used by `git submodule diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 8e6af65..067d616 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -154,27 +154,51 @@ If `--force` is specified, the submodule's work tree will be removed even if it contains local modifications. update:: - Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. + +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The updating can be done in several ways depending +on command line options and the value of `submodule.name.update` +configuration variable. Supported update methods are: + + checkout;; the commit recorded in the superproject will be + checked out in the submodule on a detached HEAD. This is + done when `--checkout` option is given, or no option is + given, and `submodule.name.update` is unset, or if it is + set to 'checkout'. ++ +If `--force` is specified, the submodule will be checked out (using +`git checkout --force` if appropriate), even if the commit specified +in the index of the containing repository already matches the commit +checked out in the submodule. + + rebase;; the current branch of the submodule will be rebased + onto the commit recoded in the superproject. This is done + when `--rebase` option is given, or no option is given, and + `submodule.name.update` is set to 'rebase'. + + merge;; the commit recorded in the superproject will be merged + into the current branch in the submodule. This is done + when `--merge` option is given, or no option is given, and + `submodule.name.update` is set to 'merge'. + + custom command;; arbitrary shell command that takes a single + argument (the sha1 of the commit recorded in the + superproject) is executed. This is done when no option is + given, and
What's cooking in git.git (Mar 2015, #01; Mon, 2)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Fifth batch of topics have been merged to 'master', including both
fixes and enhancements. First maintenance release for v2.3 was cut
with many fixes that have already been merged to 'master'.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* ew/svn-fixes (2015-02-26) 2 commits
- Merge branch 'svn-maint-fixes' into svn-fixes
- git-svn: lazy load some modules
(this branch uses ew/svn-maint-fixes.)
Will merge to 'next'.
* ew/svn-maint-fixes (2015-02-26) 2 commits
- Git::SVN::*: avoid premature FileHandle closure
- git-svn: fix localtime=true on non-glibc environments
(this branch is used by ew/svn-fixes.)
Will merge to 'next' and soon to 'master'.
* mr/doc-clean-f-f (2015-02-26) 1 commit
- Documentation/git-clean.txt: document that -f may need to be given twice
Will merge to 'next'.
* ye/http-accept-language (2015-02-26) 1 commit
- gettext.c: move get_preferred_languages() from http.c
Compilation fix for a recent topic in 'master'.
Will merge to 'next'.
* jk/diffcore-rename-duplicate (2015-02-27) 2 commits
- diffcore-rename: avoid processing duplicate destinations
- diffcore-rename: split locate_rename_dst into two functions
A corrupt input to git diff -M can cause us to segfault.
Will merge to 'next'.
* nd/grep-exclude-standard-help-fix (2015-02-27) 1 commit
- grep: correct help string for --exclude-standard
Will merge to 'next'.
* nd/versioncmp-prereleases (2015-02-27) 1 commit
- versionsort: support reorder prerelease suffixes
The versionsort.prerelease configuration variable can be used to
specify that v1.0-pre1 comes before v1.0.
Will merge to 'next'.
* ja/clean-confirm-i18n (2015-03-02) 1 commit
- Add hint interactive cleaning
The prompt string remove? used when git clean -i asks the user
if a path should be removed was localizable, but the code always
expects a substring of yes to tell it to go ahead. Always show
[y/N] as part of this prompt to hint that the answer is not (yet)
localized.
Will merge to 'next'.
* mk/diff-shortstat-dirstat-fix (2015-03-02) 1 commit
- diff --shortstat --dirstat: remove duplicate output
Will merge to 'next'.
--
[Stalled]
* jk/push-config (2015-02-17) 4 commits
- [NEEDSACK] push: allow --follow-tags to be set by config push.followTags
- cmd_push: pass flags pointer to config callback
- cmd_push: set atomic bit directly
- git_push_config: drop cargo-culted wt_status pointer
Waiting for Ack and/or update for the tip one from Dave Olszewski
($gmane/263880, $gmane/263991).
* nd/untracked-cache (2015-02-09) 24 commits
- git-status.txt: advertisement for untracked cache
- untracked cache: guard and disable on system changes
- mingw32: add uname()
- t7063: tests for untracked cache
- update-index: test the system before enabling untracked cache
- update-index: manually enable or disable untracked cache
- status: enable untracked cache
- untracked-cache: temporarily disable with $GIT_DISABLE_UNTRACKED_CACHE
- untracked cache: mark index dirty if untracked cache is updated
- untracked cache: print stats with $GIT_TRACE_UNTRACKED_STATS
- untracked cache: avoid racy timestamps
- read-cache.c: split racy stat test to a separate function
- untracked cache: invalidate at index addition or removal
- untracked cache: load from UNTR index extension
- untracked cache: save to an index extension
- ewah: add convenient wrapper ewah_serialize_strbuf()
- untracked cache: don't open non-existent .gitignore
- untracked cache: mark what dirs should be recursed/saved
- untracked cache: record/validate dir mtime and reuse cached output
- untracked cache: make a wrapper around {open,read,close}dir()
- untracked cache: invalidate dirs recursively if .gitignore changes
- untracked cache: initial untracked cache validation
- untracked cache: record .gitignore information and dir hierarchy
- dir.c: optionally compute sha-1 of a .gitignore file
Need extra sets of eyes to review this.
* ak/stash-store-create-help (2015-01-13) 1 commit
- stash: show create and store subcommands in usage-help
Will discard.
* bp/diff-relative-config (2015-01-07) 2 commits
- diff: teach diff.relative to give default to --relative=value
- diff: teach --no-relative to override earlier --relative
No comments? No interests?
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
(this branch uses jc/diff-test-updates.)
git diff -B -M produced incorrect patch when the postimage of a
completely rewritten file
Re: weaning distributions off tarballs: extended verification of git tags
On Tue, Mar 3, 2015 at 1:12 AM, Joey Hess i...@joeyh.name wrote: I support this proposal, as someone who no longer releases tarballs of my software, when I can possibly avoid it. I have worried about signed tags / commits only being a SHA1 break away from useless. As to the implementation, checksumming the collection of raw objects is certainly superior to tar. Colin had suggested sorting the objects by checksum, but I don't think that is necessary. Just stream the commit object, then its tree object, followed by the content of each object listed in the tree, recursing into subtrees as necessary. That will be a stable stream for a given commit, or tree. It could be simplified a bit by using ls-tree -r (so you basically have a single big tree). Then hash commit, ls-tree -r output and all blobs pointed by ls-tree in listed order. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] reflog: improve and update documentation
Michael Haggerty mhag...@alum.mit.edu writes:
+Reference logs, or reflogs, record when the tips of branches and
+other references were updated in the local repository. Reflogs are
+useful in various Git commands, to specify the old value of a
+reference. For example, `HEAD@{2}` means where HEAD used to be two
+moves ago, `master@{one.week.ago}` means where master used to point
+to one week ago, and so on. See linkgit:gitrevisions[7] for more
+details.
Looks very good, especially the part that mentions in the local
repository. It seems to be a common novice misunderstanding what
`master@{one.week.ago}` means, and it might be beneficial to be more
verbose by saying where master used to point to one week ago in
this local repository.
+The expire subcommand prunes older reflog entries. Entries older
+than `expire` time, or entries older than `expire-unreachable` time
+and not reachable from the current tip, are removed from the reflog.
+This is typically not used directly by end users -- instead, see
+linkgit:git-gc[1].
+
+The delete subcommand deletes single entries from the reflog. Its
+argument must be an _exact_ entry (e.g. `git reflog delete
+master@{2}`).
Just like expire, delete should be accompanied by the same
typically not. I do not think it is even worth mentioning that it
exists merely as an implementation detail for likgit:git-stash[1]
and for no other reason.
+Options for `expire` and/or `delete`
+
I think this started from a hope that these two share many, but
looking at the result I notice the shared ones are a tiny and
trivial minority. It probably makes sense to retitle this section
Options for expire (and remove For the expire command only), and
add an Options for delete section immediately after it that looks
like:
Options for `delete`
--updateref::
--rewrite::
--dry-run::
The `delete` command takes these options whose
meanings are the same as those for `expire`.
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 49c64f9..dd68a72 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -13,9 +13,9 @@
*/
static const char reflog_expire_usage[] =
-git reflog expire [--verbose] [--dry-run] [--stale-fix] [--expire=time]
[--expire-unreachable=time] [--all] refs...;
+git reflog expire [--expire=time] [--expire-unreachable=time]
[--rewrite] [--updateref] [--stale-fix] [--dry-run | -n] [--verbose] [--all]
refs...;
static const char reflog_delete_usage[] =
-git reflog delete [--verbose] [--dry-run] [--rewrite] [--updateref]
refs...;
+git reflog delete [--rewrite] [--updateref] [--dry-run | -n] [--verbose]
refs...;
static unsigned long default_reflog_expire;
static unsigned long default_reflog_expire_unreachable;
Thanks for being complete, but I sense that it may be time we
switched to parse-options here, which gives us the help string for
free. Perhaps throw in a comment line before this hunk
/* NEEDSWORK: switch to parse-options */
or something to leave hint for other people?
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Fix some problems with reflog expiration
Michael Haggerty mhag...@alum.mit.edu writes: This is v2 of the patch series. Thanks to Eric Sunshine, Stefan Beller, Peff, and Junio for their comments about v1 [1]. Thanks for a pleasant read. Will replace what has been queued. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GSoC idea] Resumable clone
Among GSoC 2011 ideas of git [1], it was proposed that a GSoC project could be implementing resumable clone for git. AFAIK, this feature is still missing in git but could be a great idea to be implemented. Does that sound OK to the community? [1]: https://git.wiki.kernel.org/index.php/SoC2011Ideas#Resumable_clone -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6] submodule: Improve documentation of update subcommand
The documentation of 'git submodule update' has several problems: 1) It mentions that value 'none' of submodule.$name.update can be overridden by --checkout, but other combinations of configuration values and command line options are not mentioned. 2) The documentation of submodule.$name.update is scattered across three places, which is confusing. 3) The documentation of submodule.$name.update in gitmodules.txt is incorrect, because the code always uses the value from .git/config and never from .gitmodules. 4) Documentation of --force was incomplete, because it is only effective in case of checkout method of update. Fix all these problems by documenting submodule.*.update in git-submodule.txt and make everybody else refer to it. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Jens Lehmann jens.lehm...@web.de Signed-off-by: Michal Sojka sojk...@fel.cvut.cz --- Documentation/config.txt| 14 + Documentation/git-submodule.txt | 66 - Documentation/gitmodules.txt| 21 ++--- 3 files changed, 64 insertions(+), 37 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index ae6791d..0a6852d 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2411,12 +2411,16 @@ status.submodulesummary:: submodule.name.path:: submodule.name.url:: + The path within this project and URL for a submodule. These + variables are initially populated by 'git submodule init'. See + linkgit:git-submodule[1] and linkgit:gitmodules[5] for + details. + submodule.name.update:: - The path within this project, URL, and the updating strategy - for a submodule. These variables are initially populated - by 'git submodule init'; edit them to override the - URL and other values found in the `.gitmodules` file. See - linkgit:git-submodule[1] and linkgit:gitmodules[5] for details. + The default update procedure for a submodule. This variable + is populated by `git submodule init` from the + linkgit:gitmodules[5] file. See description of 'update' + command in linkgit:git-submodule[1]. submodule.name.branch:: The remote branch name for a submodule, used by `git submodule diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index 8e6af65..2c25916 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -154,27 +154,51 @@ If `--force` is specified, the submodule's work tree will be removed even if it contains local modifications. update:: - Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. Setting the key `submodule.$name.update` to `!command` - will cause `command` to be run. `command` can be any arbitrary shell - command that takes a single argument, namely the sha1 to update to. + +-- +Update the registered submodules to match what the superproject +expects by cloning missing submodules and updating the working tree of +the submodules. The updating can be done in several ways depending +on command line options and the value of `submodule.name.update` +configuration variable. Supported update procedures are: + + checkout;; the commit recorded in the superproject will be + checked out in the submodule on a detached HEAD. This is + done when `--checkout` option is given, or no option is + given, and `submodule.name.update` is unset, or if it is + set to 'checkout'. ++ +If `--force` is specified, the submodule will be checked out (using +`git checkout --force` if appropriate), even if the commit specified +in the index of the containing repository already matches the commit +checked out in the submodule. + + rebase;; the current branch of the submodule will be rebased + onto the commit recorded in the superproject. This is done + when `--rebase` option is given, or no option is given, and + `submodule.name.update` is set to 'rebase'. + + merge;; the commit recorded in the superproject will be merged + into the current branch in the submodule. This is done + when `--merge` option is given, or no option is given, and + `submodule.name.update` is set to 'merge'. + + custom command;; arbitrary shell command that takes a single + argument (the sha1 of the commit recorded in the + superproject) is executed. This is done when no option is + given, and `submodule.name.update` has the form of + '!command'. + +When no option is given and
Re: weaning distributions off tarballs: extended verification of git tags
Duy Nguyen pclo...@gmail.com writes: On Tue, Mar 3, 2015 at 1:12 AM, Joey Hess i...@joeyh.name wrote: I support this proposal, as someone who no longer releases tarballs of my software, when I can possibly avoid it. I have worried about signed tags / commits only being a SHA1 break away from useless. As to the implementation, checksumming the collection of raw objects is certainly superior to tar. Colin had suggested sorting the objects by checksum, but I don't think that is necessary. Just stream the commit object, then its tree object, followed by the content of each object listed in the tree, recursing into subtrees as necessary. That will be a stable stream for a given commit, or tree. It could be simplified a bit by using ls-tree -r (so you basically have a single big tree). Then hash commit, ls-tree -r output and all blobs pointed by ls-tree in listed order. What problem are you trying to solve here, though, by deliberately deviating what Git internally used to store these objects? If it is OK to ignore the tree boundary, then you probably do not even need trees in this secondary hash for validation in the first place. For example, you can hash a stream: commit object contents + N * (pathname + NUL + blob object contents) as long as the pathnames are sorted in a predictable order (like in the index order) in the output. That would be even simpler (I am not saying it is necessarily better, and by inference neither is your simplification). I was about to suggest another alternative. Pretend as if Git internally used SHA-512 (or whatever hash you want to use) instead of SHA-1, compute the object names that way. Recompute the contents of a tree object is by replacing the 20-byte SHA-1 field in it with a field with whatever necessary length to hold the longer object names of elements in the tree. But then a realization hit me: what new value will be placed in the parent field in the commit object? You cannot have SHA-512 variant of commit object name without recomputing the whole history. Now, if the final objective is to replace signature of tarballs, does it matter to cover the commit object, or is it sufficient to cover the tree contents? Among the ideas raised so far, I like what Joey suggested, combined with each should have 'type lengthNUL' header from Sam Vilain the best. That is, hash the stream: commit length NUL + commit object contents + tree length NUL + top level tree contents + ... list the entries in the order you would find by ... some defined traversal order people can agree on. with whatever the preferred strong hash function of the age. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC idea] Resumable clone
On Tue, Mar 3, 2015 at 6:47 AM, Junio C Hamano gits...@pobox.com wrote: Koosha Khajehmoogahi koosha.kha...@gmail.com writes: Among GSoC 2011 ideas of git [1], it was proposed that a GSoC project could be implementing resumable clone for git. AFAIK, this feature is still missing in git but could be a great idea to be implemented. Does that sound OK to the community? [1]: https://git.wiki.kernel.org/index.php/SoC2011Ideas#Resumable_clone Depends on how it will be implemented, I guess. I still want to pursue stable pack approach [1]. It's not a good fit for clone case (cached bundles would be much better). On the other hand it does not need special support like cached bundles and can work with upload-pack-v1. It might fit in gsoc scope. I guess whether it may have a chance to get merged after gsoc is the deciding factor. I highly suspect that it would not fly well if it is added as a part of the current protocol, as people are actively discussing how to revamp it. And I have a feeling that the v2 protocol would not ready for a student to build upon by this summer. [1] http://thread.gmane.org/gmane.comp.version-control.git/184490/focus=184705 Though what I had in mind (and patches) does not need on-disk caching at all. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git notes from incoming patch
Hi,
I am wondering whether it is possible to read from a format-patch input
and add notes when we generate the applied patch.
The use case is to be able to send patches that had notes appended via
$git format-patch --notes ...
And have notes objects created on the remote repository to store this
information.
Is there any way to do this? and/or is there a way to get the same
results that maybe doesn't use notes?
The problem we are trying to solve is a way to track some information
about a patch that we need internally without submitting it upstream
when we submit the patches later. We use email to handle internal patch
queues, so essentially we want to be able to add note objects to the
format-patch and send them via email.
Regards,
Jake
N�r��yb�X��ǧv�^�){.n�+ا���ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf
Re: [GSoC idea] Resumable clone
Koosha Khajehmoogahi koosha.kha...@gmail.com writes: Among GSoC 2011 ideas of git [1], it was proposed that a GSoC project could be implementing resumable clone for git. AFAIK, this feature is still missing in git but could be a great idea to be implemented. Does that sound OK to the community? [1]: https://git.wiki.kernel.org/index.php/SoC2011Ideas#Resumable_clone Depends on how it will be implemented, I guess. I highly suspect that it would not fly well if it is added as a part of the current protocol, as people are actively discussing how to revamp it. And I have a feeling that the v2 protocol would not ready for a student to build upon by this summer. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: weaning distributions off tarballs: extended verification of git tags
On Tue, Mar 3, 2015 at 6:44 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: On Tue, Mar 3, 2015 at 1:12 AM, Joey Hess i...@joeyh.name wrote: I support this proposal, as someone who no longer releases tarballs of my software, when I can possibly avoid it. I have worried about signed tags / commits only being a SHA1 break away from useless. As to the implementation, checksumming the collection of raw objects is certainly superior to tar. Colin had suggested sorting the objects by checksum, but I don't think that is necessary. Just stream the commit object, then its tree object, followed by the content of each object listed in the tree, recursing into subtrees as necessary. That will be a stable stream for a given commit, or tree. It could be simplified a bit by using ls-tree -r (so you basically have a single big tree). Then hash commit, ls-tree -r output and all blobs pointed by ls-tree in listed order. What problem are you trying to solve here, though, by deliberately deviating what Git internally used to store these objects? If it is OK to ignore the tree boundary, then you probably do not even need trees in this secondary hash for validation in the first place. For example, you can hash a stream: commit object contents + N * (pathname + NUL + blob object contents) as long as the pathnames are sorted in a predictable order (like in the index order) in the output. That would be even simpler (I am not saying it is necessarily better, and by inference neither is your simplification). I did nearly that [1]. But this morning I realized trees carry file permission. We should keep that in the final checksum as well. Now, if the final objective is to replace signature of tarballs, does it matter to cover the commit object, or is it sufficient to cover the tree contents? Among the ideas raised so far, I like what Joey suggested, combined with each should have 'type lengthNUL' header from Sam Vilain the best. That is, hash the stream: commit length NUL + commit object contents + tree length NUL + top level tree contents + ... list the entries in the order you would find by ... some defined traversal order people can agree on. with whatever the preferred strong hash function of the age. A bit harder to script, but simpler to provide from cat-file, I think. [1] http://article.gmane.org/gmane.comp.version-control.git/260211 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Mon, Mar 02, 2015 at 04:21:36PM +0700, Duy Nguyen wrote: On Sun, Mar 01, 2015 at 07:47:40PM -0800, Junio C Hamano wrote: It seems, however, that our current thinking is that it is OK to do the allow new v1 clients to notice the availabilty of v2 servers, so that they can talk v2 the next time thing, so my preference is to throw this client first and let server notice into maybe doable but not our first choice bin, at least for now. OK let's see if first choice like this could work. Very draft but it should give some idea how to make a prototype to test it out. Note that the server still speaks first in this proposal. And ref discovery phase could be modified by new capabilities. For example, -- 8 -- diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index 56c11b4..56a8c2e 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -304,3 +304,36 @@ language code. The default language code is unspecified, even though it's usually English in ASCII encoding. + +compressed-refs +--- + +This is applicable to upload-pack-2 and receive-pack-2 only. The +client expects ref list in reference discovery phase to be sent in +compressed format: + + - Each PKT-LINE may contain more than one ref + - SHA-1 is in binary encoding (i.e. 20 bytes instead of + 40 bytes as hex string) + - ref name is prefix compressed, see index-format.txt version 4. + - Ref list ends with flush-pkt + +glob-refs +- + +This is applicable to upload-pack-2 and receive-pack-2 only. In +reference discovery phase, a new mode glob is supported. Where the +arguments are wildmatch patterns. Negative patterns begin with '!'. +Only refs matching requested patterns are sent to the client. + +stateful-refs +- + +This is applicable to upload-pack-2 and receive-pack-2 only. In +reference discovery phase, a new mode stateful is supported. Where +the first argument is a string representing the ref list that was sent +by the same server last time. The remaining arguments are glob. + +The first ref line that the server sends should carry a new state +string after ref name. The server may send only updated refs it if +understands the state string sent by the client. Still under discussion. -- 8 -- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git: make was_alias and done_help non-static
On Mon, Mar 02, 2015 at 06:02:37PM +0600, Alexander Kuleshov wrote:
'was_alias' variable does not need to store it's value on each
iteration in the loop, anyway this variable changes it's value with run_argv.
'done_help' variable does not need to be static variable too if we'll move it
out the loop.
So these variables do not need to be static.
Agreed, but...
diff --git a/git.c b/git.c
index 1780233..96723b8 100644
--- a/git.c
+++ b/git.c
@@ -619,6 +619,7 @@ int main(int argc, char **av)
{
const char **argv = (const char **) av;
const char *cmd;
+ int done_help, was_alias;
Now done_help is not initialized, but we read from it before assigning
it. And I think there is no need for was_alias to go outside the loop,
right?
startup_info = git_startup_info;
@@ -681,8 +682,6 @@ int main(int argc, char **av)
setup_path();
while (1) {
- static int done_help = 0;
- static int was_alias = 0;
was_alias = run_argv(argc, argv);
Dropping the initialization of was_alias is fine, since we always assign
to it before reading. That becomes more obvious if we leave it in the
loop, and we can even assign in its declaration.
So all together, like:
diff --git a/git.c b/git.c
index acde36a..8dbe12f 100644
--- a/git.c
+++ b/git.c
@@ -635,6 +635,7 @@ int main(int argc, char **av)
{
const char **argv = (const char **) av;
const char *cmd;
+ int done_help = 0;
startup_info = git_startup_info;
@@ -697,9 +698,7 @@ int main(int argc, char **av)
setup_path();
while (1) {
- static int done_help = 0;
- static int was_alias = 0;
- was_alias = run_argv(argc, argv);
+ int was_alias = run_argv(argc, argv);
if (errno != ENOENT)
break;
if (was_alias) {
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use unsigned char to squash compiler warnings
Ben Walton bdwal...@gmail.com writes:
Sun Studio on Solaris issues warnings about improper initialization
values being used when defining tolower_trans_tbl in
ctype.c. tolower_trans_tbl is defined as char[], which studio's
compiler defaults to signed char[] due to the Solaris ABI. To resolve
this, instead of supplying -xchar or another option at build time,
declare tolower_trans_tbl as unsigned char. Update all appropriate
references to the new type.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
ctype.c | 2 +-
git-compat-util.h | 2 +-
kwset.c | 8
kwset.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/ctype.c b/ctype.c
index 0bfebb4..fc0225c 100644
--- a/ctype.c
+++ b/ctype.c
@@ -30,7 +30,7 @@ const unsigned char sane_ctype[256] = {
};
/* For case-insensitive kwset */
-const char tolower_trans_tbl[256] = {
+const unsigned char tolower_trans_tbl[256] = {
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
It is not obvious from the context but later elements in this array
have values above 0x7f. So you are saying your compiler complains
when you write:
signed char ch = 0xff;
which sort of makes sense (because you actually are storing -1 not
255 to the variable). Throughout our codebase (and kwset is a
borrowed code that does not count as our codebase ;-) we do use
unsigned when we mean we want 255 and not -1, and this patch fixes
that borrowed code to be in line with the rest.
The conversion looked good from a cursory view; I didn't check it
very carefully though.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] gitk: write only changed configuration variables
On Mon, Mar 02, 2015 at 10:47:30AM +1100, Paul Mackerras wrote: On Mon, Nov 10, 2014 at 12:20:01AM +0200, Max Kirillov wrote: +lappend views_modified_names $current_viewname($v) This view_modified_names variable doesn't seem to be used anywhere. If you don't mind me taking out this line, I'll do that and apply the patch. Yes, sure. Thank you. Must be some editing leftover. I could not recover what was my intention, even if something meaningful was ever committed it is rebased and gc-ed by now. -- Max -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: weaning distributions off tarballs: extended verification of git tags
On 03/02/2015 12:08 PM, Junio C Hamano wrote: I have a hazy recollection of what it would take to replace SHA-1 in git with something else; it should be possible (though tricky) to do it lazily, where a tree entry has bits (eg, some of the currently unused file mode bits) to denotes which hash algorithm is in use for the entry. However I don't think that got past idea stage... I think one reason why it didn't was because it would not work well. That bit that tells this is a new object or old would mean that a single tree can have many different object names, depending on which of its component entries are using that bit and which aren't. There goes the we know two trees with the same object name are identical without recursing into them optimization out the window. Also it would make it impossible to do what you suggest to Joey to do, i.e. exactly the same way that git does, once you start saying that a tree object can be encoded in more than one different ways, wouldn't it? I was reasoning that people would rather not have to rewrite their whole history in order to switch checksum algorithms, and that by allowing trees to be lazily converted that this would make things more efficient. However, I think I see your point here that this doesn't work. However, as a per-commit header, then only first commit which changes the hashing algorithm would have to re-checksum each of the files: but just in the current tree, not all the way back to the beginning of history. The delta logic should not have to care, and these objects with the same content but different object ID should pack perfectly, so long as git-pack-objects knows to re-checksum objects with the available hash algorithms and spot matches. Other operations like diff which span commit hashing algorithms might be able to get away with their existing object ranking algorithms and cache alternate object IDs for content as they operate to facilitate exact matching across hash algorithm changes. But actually, for the original problem - just producing a signature with a different hashing algorithm - probably it would be sufficient to just re-hash the current commit and the current tree recursively, and the mixed hash-algorithm case does not need to exist. But I'm just thinking it might not be too hard to make git nicely generic, to be well prepared for when a second pre-image attack on SHA-1 becomes practical. Sam -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Documentation/git-hash-object.txt: add verbose option for hash-object
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-hash-object.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/git-hash-object.txt b/Documentation/git-hash-object.txt index 02c1f12..efec7c6 100644 --- a/Documentation/git-hash-object.txt +++ b/Documentation/git-hash-object.txt @@ -9,8 +9,8 @@ git-hash-object - Compute object ID and optionally creates a blob from a file SYNOPSIS [verse] -'git hash-object' [-t type] [-w] [--path=file|--no-filters] [--stdin] [--] file... -'git hash-object' [-t type] [-w] --stdin-paths [--no-filters] list-of-paths +'git hash-object' [-t type] [-w] [-v] [--path=file|--no-filters] [--stdin] [--] file... +'git hash-object' [-t type] [-w] [-v] --stdin-paths [--no-filters] list-of-paths DESCRIPTION --- @@ -31,6 +31,9 @@ OPTIONS -w:: Actually write the object into the object database. +-v:: + Prints file path near the hash. + --stdin:: Read the object from standard input instead of from a file. -- 2.3.1.167.g7f4ba4b.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] diff --shortstat --dirstat: remove duplicate output
When --shortstat is used in conjunction with --dirstat=changes, git diff will output the dirstat information twice: first as calculated by the 'lines' algorithm, then as calculated by the 'changes' algorithm: $ git diff --dirstat=changes,10 --shortstat v2.2.0..v2.2.1 23 files changed, 453 insertions(+), 54 deletions(-) 33.5% Documentation/RelNotes/ 26.2% t/ 46.6% Documentation/RelNotes/ 16.6% t/ The same duplication happens for --shortstat together with --dirstat=files, but not for --shortstat together with --dirstat=lines. Limit output to only include one dirstat part, calculated as specified by the --dirstat parameter. Also, add test for this. Signed-off-by: Mårten Kongstad marten.kongs...@gmail.com --- v3: change how tests count (part of) the dirstat number of lines: instead of 'grep -c', use 'grep filename test_line_count'. Thanks to Torsten Bögershausen and SZEDER Gábor for pointing out how to improve the tests. diff.c | 2 +- t/t4047-diff-dirstat.sh | 11 +++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/diff.c b/diff.c index d1bd534..abc32c8 100644 --- a/diff.c +++ b/diff.c @@ -4541,7 +4541,7 @@ void diff_flush(struct diff_options *options) show_stats(diffstat, options); if (output_format DIFF_FORMAT_SHORTSTAT) show_shortstats(diffstat, options); - if (output_format DIFF_FORMAT_DIRSTAT) + if (output_format DIFF_FORMAT_DIRSTAT dirstat_by_line) show_dirstat_by_line(diffstat, options); free_diffstat_info(diffstat); separator++; diff --git a/t/t4047-diff-dirstat.sh b/t/t4047-diff-dirstat.sh index ed7e093..065d74f 100755 --- a/t/t4047-diff-dirstat.sh +++ b/t/t4047-diff-dirstat.sh @@ -973,4 +973,15 @@ test_expect_success 'diff.dirstat=future_param,0,lines should warn, but still wo test_i18ngrep -q diff\\.dirstat actual_error ' +test_expect_success '--shortstat --dirstat should output only one dirstat' ' + git diff --shortstat --dirstat=changes HEAD^..HEAD | grep dst/copy/changed/$ actual_diff_shortstat_dirstat_changes + test_line_count = 1 actual_diff_shortstat_dirstat_changes + + git diff --shortstat --dirstat=lines HEAD^..HEAD | grep dst/copy/changed/$ actual_diff_shortstat_dirstat_lines + test_line_count = 1 actual_diff_shortstat_dirstat_lines + + git diff --shortstat --dirstat=files HEAD^..HEAD | grep dst/copy/changed/$ actual_diff_shortstat_dirstat_files + test_line_count = 1 actual_diff_shortstat_dirstat_files +' + test_done -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git: make was_alias and done_help non-static
'was_alias' variable does not need to store it's value on each
iteration in the loop, anyway this variable changes it's value with run_argv.
'done_help' variable does not need to be static variable too if we'll move it
out the loop.
So these variables do not need to be static.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
---
git.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 1780233..96723b8 100644
--- a/git.c
+++ b/git.c
@@ -619,6 +619,7 @@ int main(int argc, char **av)
{
const char **argv = (const char **) av;
const char *cmd;
+ int done_help, was_alias;
startup_info = git_startup_info;
@@ -681,8 +682,6 @@ int main(int argc, char **av)
setup_path();
while (1) {
- static int done_help = 0;
- static int was_alias = 0;
was_alias = run_argv(argc, argv);
if (errno != ENOENT)
break;
--
2.3.1.422.ge618558
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Move commits not in origin to a branch
How do I move commits I haven't pushed into a new branch? % git log origin..master --pretty=format:'%h' f7d3a19 1f186c9 66d99f6 Which I'd like to be in a new branch. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] hash-object: add -v/--verbose option
This patch provides ability to pass -v/--verbose option to the
git hash-object command. hash-object will print not only hash,
but also file path of a file from what hash was calculated.
It can be useful in scripting, especially with --stdin-paths
option.
For example:
$ git hash-object -v test
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391test
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
builtin/hash-object.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/builtin/hash-object.c b/builtin/hash-object.c
index 207b90c..97961ee 100644
--- a/builtin/hash-object.c
+++ b/builtin/hash-object.c
@@ -10,6 +10,8 @@
#include parse-options.h
#include exec_cmd.h
+static int verbose;
+
/*
* This is to create corrupt objects for debugging and as such it
* needs to bypass the data conversion performed by, and the type
@@ -43,7 +45,10 @@ static void hash_fd(int fd, const char *type, const char
*path, unsigned flags,
die((flags HASH_WRITE_OBJECT)
? Unable to add %s to database
: Unable to hash %s, path);
- printf(%s\n, sha1_to_hex(sha1));
+ if (verbose)
+ printf(%s\t%s\n, sha1_to_hex(sha1), path);
+ else
+ printf(%s\n, sha1_to_hex(sha1));
maybe_flush_or_die(stdout, hash to stdout);
}
@@ -79,7 +84,7 @@ static void hash_stdin_paths(const char *type, int
no_filters, unsigned flags,
int cmd_hash_object(int argc, const char **argv, const char *prefix)
{
static const char * const hash_object_usage[] = {
- N_(git hash-object [-t type] [-w] [--path=file |
--no-filters] [--stdin] [--] file...),
+ N_(git hash-object [-t type] [-w] [-v] [--path=file |
--no-filters] [--stdin] [--] file...),
N_(git hash-object --stdin-paths list-of-paths),
NULL
};
@@ -99,6 +104,7 @@ int cmd_hash_object(int argc, const char **argv, const char
*prefix)
OPT_BOOL( 0 , no-filters, no_filters, N_(store file as is
without filters)),
OPT_BOOL( 0, literally, literally, N_(just hash any random
garbage to create corrupt objects for debugging Git)),
OPT_STRING( 0 , path, vpath, N_(file), N_(process file as
it were from this path)),
+ OPT__VERBOSE(verbose, N_(show hash and file path)),
OPT_END()
};
int i;
@@ -108,6 +114,11 @@ int cmd_hash_object(int argc, const char **argv, const
char *prefix)
argc = parse_options(argc, argv, NULL, hash_object_options,
hash_object_usage, 0);
+ if (verbose literally)
+ errstr = Can't use --verbose with --literally;
+ else if (verbose hashstdin)
+ errstr = Can't use --verbose with --stdin;
+
if (flags HASH_WRITE_OBJECT) {
prefix = setup_git_directory();
prefix_length = prefix ? strlen(prefix) : 0;
--
2.3.1.167.g7f4ba4b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] t1007-hash-object: add tests for verbose hash-object
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- t/t1007-hash-object.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh index f83df8e..fa957bf 100755 --- a/t/t1007-hash-object.sh +++ b/t/t1007-hash-object.sh @@ -201,4 +201,15 @@ test_expect_success 'corrupt tag' ' test_must_fail git hash-object -t tag --stdin /dev/null ' +filename=hello +hello_sha1_verbose=$hello_sha1\t$filename + +test_expect_success 'hash-object verbose' ' + test $(echo $hello_sha1_verbose) = $(git hash-object -v $filename) +' + +test_expect_success Can't use --verbose and --stdin together ' + echo example | test_must_fail git hash-object --verbose --stdin +' + test_done -- 2.3.1.167.g7f4ba4b.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Move commits not in origin to a branch
shawn wilson venit, vidit, dixit 02.03.2015 14:25: How do I move commits I haven't pushed into a new branch? % git log origin..master --pretty=format:'%h' f7d3a19 1f186c9 66d99f6 Which I'd like to be in a new branch. Do you want them to be on the new branch as they are, i.e. as commits built on top of master? Then git branch mybranch master will create a new branch mybranch which contains those commits. If you want to remove them from master, then git checkout master # unless you are there already git reset --keep origin/master to rewind master to commit origin/master. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote.txt: describe behavior without --tags and --no-tags
Francis Moreau venit, vidit, dixit 02.03.2015 14:36: Hi, On 03/02/2015 02:08 PM, Michael J Gruber wrote: Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/git-remote.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index a77607b..f3f6f0d 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -56,7 +56,10 @@ With `--tags` option, `git fetch name` imports every tag from the remote repository. + With `--no-tags` option, `git fetch name` does not import tags from the remote repository. ++ +By default, only tags on fetched branches are imported +(see linkgit:git-fetch[1]). + So the default is neither --no-tags nor --tags ? Thanks. By default, only tags on fetched branches are imported. That is: When the fetch is done, all tags are imported that point to commits that are reachable from refs that you are fetching, in short: tags on fetched branches. That is in between none (--no-tags) and all (--tags). Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] write_ref_sha1(): Move write elision test to callers
write_ref_sha1() previously skipped the write if the reference already
had the desired value, unless lock-force_write was set. Instead,
perform that test at the callers.
Two of the callers (in rename_ref()) unconditionally set force_write
just before calling write_ref_sha1(), so they don't need the extra
check at all. Nor do they need to set force_write anymore.
The last caller, in ref_transaction_commit(), still needs the test.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index e82d503..dd30bfa 100644
--- a/refs.c
+++ b/refs.c
@@ -2877,7 +2877,6 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
error(unable to lock %s for update, newrefname);
goto rollback;
}
- lock-force_write = 1;
hashcpy(lock-old_sha1, orig_sha1);
if (write_ref_sha1(lock, orig_sha1, logmsg)) {
error(unable to write current sha1 into %s, newrefname);
@@ -2893,7 +2892,6 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
goto rollbacklog;
}
- lock-force_write = 1;
flag = log_all_ref_updates;
log_all_ref_updates = 0;
if (write_ref_sha1(lock, orig_sha1, NULL))
@@ -3079,10 +3077,6 @@ static int write_ref_sha1(struct ref_lock *lock,
static char term = '\n';
struct object *o;
- if (!lock-force_write !hashcmp(lock-old_sha1, sha1)) {
- unlock_ref(lock);
- return 0;
- }
o = parse_object(sha1);
if (!o) {
error(Trying to write ref %s with nonexistent object %s,
@@ -3796,15 +3790,21 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
struct ref_update *update = updates[i];
if (!is_null_sha1(update-new_sha1)) {
- if (write_ref_sha1(update-lock, update-new_sha1,
- update-msg)) {
+ if (!update-lock-force_write
+ !hashcmp(update-lock-old_sha1, update-new_sha1))
{
+ unlock_ref(update-lock);
+ update-lock = NULL;
+ } else if (write_ref_sha1(update-lock,
update-new_sha1,
+ update-msg)) {
update-lock = NULL; /* freed by write_ref_sha1
*/
strbuf_addf(err, Cannot update the ref '%s'.,
update-refname);
ret = TRANSACTION_GENERIC_ERROR;
goto cleanup;
+ } else {
+ /* freed by write_ref_sha1(): */
+ update-lock = NULL;
}
- update-lock = NULL; /* freed by write_ref_sha1 */
}
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] lock_ref_sha1_basic(): do not set force_write for missing references
If a reference is missing, its SHA-1 will be null_sha1, which can't
possibly match a new value that ref_transaction_commit() is trying to
update it to. So there is no need to set force_write in this scenario.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index dd30bfa..3ed9ea6 100644
--- a/refs.c
+++ b/refs.c
@@ -2258,7 +2258,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
int type, lflags;
int mustexist = (old_sha1 !is_null_sha1(old_sha1));
int resolve_flags = 0;
- int missing = 0;
int attempts_remaining = 3;
lock = xcalloc(1, sizeof(struct ref_lock));
@@ -2297,13 +2296,13 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
orig_refname, strerror(errno));
goto error_return;
}
- missing = is_null_sha1(lock-old_sha1);
- /* When the ref did not exist and we are creating it,
-* make sure there is no existing ref that is packed
-* whose name begins with our refname, nor a ref whose
-* name is a proper prefix of our refname.
+ /*
+* If the ref did not exist and we are creating it, make sure
+* there is no existing packed ref whose name begins with our
+* refname, nor a packed ref whose name is a proper prefix of
+* our refname.
*/
- if (missing
+ if (is_null_sha1(lock-old_sha1)
!is_refname_available(refname, skip, get_packed_refs(ref_cache)))
{
last_errno = ENOTDIR;
goto error_return;
@@ -2319,8 +2318,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
lock-ref_name = xstrdup(refname);
lock-orig_ref_name = xstrdup(orig_refname);
ref_file = git_path(%s, refname);
- if (missing)
- lock-force_write = 1;
if ((flags REF_NODEREF) (type REF_ISSYMREF))
lock-force_write = 1;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] struct ref_lock: delete the force_write member
From: Stefan Beller sbel...@google.com
Instead, compute the value when it is needed.
Signed-off-by: Stefan Beller sbel...@google.com
Edited-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index 3ed9ea6..f2e9883 100644
--- a/refs.c
+++ b/refs.c
@@ -12,7 +12,6 @@ struct ref_lock {
struct lock_file *lk;
unsigned char old_sha1[20];
int lock_fd;
- int force_write;
};
/*
@@ -2318,8 +2317,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
lock-ref_name = xstrdup(refname);
lock-orig_ref_name = xstrdup(orig_refname);
ref_file = git_path(%s, refname);
- if ((flags REF_NODEREF) (type REF_ISSYMREF))
- lock-force_write = 1;
retry:
switch (safe_create_leading_directories(ref_file)) {
@@ -3787,8 +3784,13 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
struct ref_update *update = updates[i];
if (!is_null_sha1(update-new_sha1)) {
- if (!update-lock-force_write
- !hashcmp(update-lock-old_sha1, update-new_sha1))
{
+ if (!((update-type REF_ISSYMREF)
+ (update-flags REF_NODEREF))
+!hashcmp(update-lock-old_sha1,
update-new_sha1)) {
+ /*
+* The reference already has the desired
+* value, so we don't need to write it.
+*/
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock,
update-new_sha1,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] reflog_expire(): ignore --updateref for symbolic references
If we are expiring reflog entries for a symbolic reference, then how
should --updateref be handled if the newest reflog entry is expired?
Option 1: Update the referred-to reference. (This is what the current
code does.) This doesn't make sense, because the referred-to reference
has its own reflog, which hasn't been rewritten.
Option 2: Update the symbolic reference itself (as in, REF_NODEREF).
This would convert the symbolic reference into a non-symbolic
reference (e.g., detaching HEAD), which is surely not what a user
would expect.
Option 3: Error out. This is plausible, but it would make the
following usage impossible:
git reflog expire ... --updateref --all
Option 4: Ignore --updateref for symbolic references.
We choose to implement option 4.
Note: another problem in this code will be fixed in a moment.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-reflog.txt | 3 ++-
refs.c | 15 ---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 3af9422..d49db7c 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -89,7 +89,8 @@ Options for `expire` and/or `delete`
--updateref::
Update the reference to the value of the top reflog entry (i.e.
- ref@\{0\}) if the previous top entry was pruned.
+ ref@\{0\}) if the previous top entry was pruned. (This
+ option is ignored for symbolic references.)
--rewrite::
While expiring or deleting, adjust each reflog entry's old
diff --git a/refs.c b/refs.c
index f2e9883..bd47d23 100644
--- a/refs.c
+++ b/refs.c
@@ -4026,6 +4026,7 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
struct ref_lock *lock;
char *log_file;
int status = 0;
+ int type;
memset(cb, 0, sizeof(cb));
cb.flags = flags;
@@ -4037,7 +4038,7 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
* reference itself, plus we might need to update the
* reference if --updateref was specified:
*/
- lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, NULL);
+ lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, type);
if (!lock)
return error(cannot lock ref '%s', refname);
if (!reflog_exists(refname)) {
@@ -4074,10 +4075,18 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
(*cleanup_fn)(cb.policy_cb);
if (!(flags EXPIRE_REFLOGS_DRY_RUN)) {
+ /*
+* It doesn't make sense to adjust a reference pointed
+* to by a symbolic ref based on expiring entries in
+* the symbolic reference's reflog.
+*/
+ int update = (flags EXPIRE_REFLOGS_UPDATE_REF)
+ !(type REF_ISSYMREF);
+
if (close_lock_file(reflog_lock)) {
status |= error(couldn't write %s: %s, log_file,
strerror(errno));
- } else if ((flags EXPIRE_REFLOGS_UPDATE_REF)
+ } else if (update
(write_in_full(lock-lock_fd,
sha1_to_hex(cb.last_kept_sha1), 40) != 40 ||
write_str_in_full(lock-lock_fd, \n) != 1 ||
@@ -4088,7 +4097,7 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
} else if (commit_lock_file(reflog_lock)) {
status |= error(unable to commit reflog '%s' (%s),
log_file, strerror(errno));
- } else if ((flags EXPIRE_REFLOGS_UPDATE_REF)
commit_ref(lock)) {
+ } else if (update commit_ref(lock)) {
status |= error(couldn't set %s, lock-ref_name);
}
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] write_ref_sha1(): remove check for lock == NULL
None of the callers pass NULL to this function, and there doesn't seem
to be any usefulness to allowing them to do so.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
refs.c | 4
1 file changed, 4 deletions(-)
diff --git a/refs.c b/refs.c
index ab2f2a9..e82d503 100644
--- a/refs.c
+++ b/refs.c
@@ -3079,10 +3079,6 @@ static int write_ref_sha1(struct ref_lock *lock,
static char term = '\n';
struct object *o;
- if (!lock) {
- errno = EINVAL;
- return -1;
- }
if (!lock-force_write !hashcmp(lock-old_sha1, sha1)) {
unlock_ref(lock);
return 0;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-remote.txt: describe behavior without --tags and --no-tags
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/git-remote.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index a77607b..f3f6f0d 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -56,7 +56,10 @@ With `--tags` option, `git fetch name` imports every tag from the remote repository. + With `--no-tags` option, `git fetch name` does not import tags from the remote repository. ++ +By default, only tags on fetched branches are imported +(see linkgit:git-fetch[1]). + With `-t branch` option, instead of the default glob refspec for the remote to track all branches under -- 2.3.1.303.g5174db1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-remote.txt: describe behavior without --tags and --no-tags
Hi, On 03/02/2015 02:08 PM, Michael J Gruber wrote: Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/git-remote.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index a77607b..f3f6f0d 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -56,7 +56,10 @@ With `--tags` option, `git fetch name` imports every tag from the remote repository. + With `--no-tags` option, `git fetch name` does not import tags from the remote repository. ++ +By default, only tags on fetched branches are imported +(see linkgit:git-fetch[1]). + So the default is neither --no-tags nor --tags ? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature request: excluding files/paths from git grep
On Sun, Mar 01, 2015 at 03:22:11PM -0800, Junio C Hamano wrote: Trevor Saunders tbsau...@tbsaunde.org writes: ... For these per-invocation differences, attributes to declare permenent/inherent nature of the contents is much less suited than per-invocation inclusion/exclusion mechanism based on pathspecs, I would think. I think that makes some amount of sense, however typing stuff like --exclude=ChangeLog all the time is not terribly easy on the hands. Would it make sense to instead add a config variable grep.exclude? I do not think it makes much more sense for at least three reasons. for one thing, It still goes against per-invocation nature of what is being done. Your for this invocation I do not want ChangeLog does not have to be limited to 'grep'. And also I end up having to give these pathspecs all the time is not limited to negative ones. I think what is somewhat special about grep is that I want to ignore a set of paths such a large majority of the time that I really want to change the default. I could see someone wanting to do the same thing for diff or log maybe, and so adding diff.exclude, but personally I don't have a use for it. We have magic pathspecs, like This pattern is used to match the string case-insensitively, This pattern specifies that the path should *not* match it, etc. How about adding a new feature that lets you say This is a short hand to giving these pathspecs and call that pathspec macro? If you get tired to keep having to type $ git log -- Documentation/ ':!Documentation/technical/' every time you want to check the end-user facing documentation pages, you could for example say (I am using a made-up 'macro' pathspec magic that is introduced by ':*' followed by a macro name): $ git log -- ':*userdoc' and the same macro specification could be used for all the other things that take pathspecs (grep, add, diff, etc.). I can certainly see use cases for that, say git log -- :!t/ :!foo/tests/ :!bar/testsuite/ to see what non test changes have happened in a project that doesn't have a standardized name for test directories. You could then have something like this to define your own nolog macro: [pathspecMacro] nolog = ':!ChangeLog' ':!ChangeLog.*' to shorten your invocation of grep by appending it when you want to exclude some files, i.e. $ git grep -e pattern -- \*.c ':*nolog' and the same pathspec macro can be used in other places, not just grep. Wouldn't it make more sense? I think they solve somewhat different problems, but maybe my problem is so specialized I should just have a wrapper around grep that changes defaults. Trev -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Sun, Mar 01, 2015 at 07:47:40PM -0800, Junio C Hamano wrote: It seems, however, that our current thinking is that it is OK to do the allow new v1 clients to notice the availabilty of v2 servers, so that they can talk v2 the next time thing, so my preference is to throw this client first and let server notice into maybe doable but not our first choice bin, at least for now. OK let's see if first choice like this could work. Very draft but it should give some idea how to make a prototype to test it out. Note that the server still speaks first in this proposal. -- 8 -- diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 462e206..32a1186 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -1,11 +1,11 @@ Packfile transfer protocols === -Git supports transferring data in packfiles over the ssh://, git:// and +Git supports transferring data in packfiles over the ssh://, git://, http:// and file:// transports. There exist two sets of protocols, one for pushing data from a client to a server and another for fetching data from a server to a client. All three transports (ssh, git, file) use the same -protocol to transfer data. +protocol to transfer data. http is documented in http-protocol.txt. The processes invoked in the canonical Git implementation are 'upload-pack' on the server side and 'fetch-pack' on the client side for fetching data; @@ -14,6 +14,12 @@ data. The protocol functions to have a server tell a client what is currently on the server, then for the two to negotiate the smallest amount of data to send in order to fully update one or the other. +upload-pack-2 and receive-pack-2 are the next generation of +upload-pack and receive-pack respectively. The first two are +referred as version 2 in this document and pack-capabilities.txt +while the last two are version 1. Unless stated otherwise, version 1 +is implied. + Transports -- There are three transports over which the packfile protocol is @@ -42,7 +48,8 @@ hostname parameter, terminated by a NUL byte. -- git-proto-request = request-command SP pathname NUL [ host-parameter NUL ] - request-command = git-upload-pack / git-receive-pack / + request-command = git-upload-pack / git-upload-pack-2 / + git-receive-pack / git-receive-pack-2 / git-upload-archive ; case sensitive pathname = *( %x01-ff ) ; exclude NUL host-parameter= host= hostname [ : port ] @@ -67,7 +74,6 @@ gracefully with an error message. error-line = PKT-LINE(ERR SP explanation-text) - SSH Transport - @@ -124,9 +130,58 @@ has, the first can 'fetch' from the second. This operation determines what data the server has that the client does not then streams that data down to the client in packfile format. +Capability discovery (v2) +- -Reference Discovery +In version 1, capability discovery is part of reference discovery and +covered in reference discovery section. + +In versino 2, when the client initially connects, the server +immediately sends its capabilities to the client. Then the client must +send the list of server capabilities it wants to use to the server. + + S: 00XXcapabilities multi_ack thin-pack ofs-delta lang\n + C: 00XXcapabilities thin-pack ofs-delta lang=en\n + + + cap = PKT-LINE(capabilities SP capability-list LF) + capability-list = capability *(SP capability) + capability = 1*(LC_ALPHA / DIGIT / - / _ / =) + LC_ALPHA = %x61-7A + + +The client MUST NOT ask for capabilities the server did not say it +supports. + +Server MUST diagnose and abort if capabilities it does not understand +was sent. Server MUST NOT ignore capabilities that client requested +and server advertised. As a consequence of these rules, server MUST +NOT advertise capabilities it does not understand. + +See protocol-capabilities.txt for a list of allowed server and client +capabilities and descriptions. + +XXX: this approach wastes one round trip in smart-http because the +client would speak first. Perhaps we could allow client speculation. +It can assume what server caps will send and send commands based on that +assumption. If it turns out true, we save one round trip. E.g. fast +path: + + C: You are supposed to send caps A, B. I would respond with cap B. + Then I would send want-refs refs/heads/foo. + S: (yes we are sending caps A and B), validate client caps, + execute want-refs and return ref list + +and slow path: + + C: You are supposed to send caps A, B. I would respond with cap B. + Then I would send want-refs refs/heads/foo. + S: Send caps A, B and C. ignore the rest from client + C: Want caps A and C. Send want-refs foo + S: return ref foo + +Reference Discovery (v1) +
[PATCH v2 7/7] reflog_expire(): never update a reference to null_sha1
Currently, if --updateref is specified and the very last reflog entry
is expired or deleted, the reference's value is set to 0{40}. This is
an invalid state of the repository, and breaks, for example, git
fsck and git for-each-ref.
The only place we use --updateref in our own code is when dropping
stash entries. In that code, the very next step is to check if the
reflog has been made empty, and if so, delete the refs/stash
reference entirely. Thus that code path ultimately leaves the
repository in a valid state.
But we don't want to the repository in an invalid state even
temporarily, and we don't want to leave an invalid state if other
callers of git reflog expire|delete --updateref don't think to do
the extra cleanup step.
So, if git reflog expire|delete leaves no more entries in the
reflog, just leave the reference unchanged.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index bd47d23..f6b04d9 100644
--- a/refs.c
+++ b/refs.c
@@ -4078,10 +4078,13 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
/*
* It doesn't make sense to adjust a reference pointed
* to by a symbolic ref based on expiring entries in
-* the symbolic reference's reflog.
+* the symbolic reference's reflog. Nor can we update
+* a reference if there are no remaining reflog
+* entries.
*/
int update = (flags EXPIRE_REFLOGS_UPDATE_REF)
- !(type REF_ISSYMREF);
+ !(type REF_ISSYMREF)
+ !is_null_sha1(cb.last_kept_sha1);
if (close_lock_file(reflog_lock)) {
status |= error(couldn't write %s: %s, log_file,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git-remote add: --no-tags/--tags which one is the default option
Hi, git remote add has --no-tags/--tags option, but I can't find in the man page which one is the default. Could anybody tell me the default option ? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] reflog: improve and update documentation
Revamp the git reflog usage documentation in the manpage and the
command help to match the current reality and improve its clarity:
* Add documentation for some options that had been left out.
* Group the subcommands and options more logically and move more
common subcommands/options higher.
* Improve some explanations.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-reflog.txt | 138 +--
builtin/reflog.c | 4 +-
2 files changed, 81 insertions(+), 61 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 70791b9..3af9422 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -17,81 +17,101 @@ The command takes various subcommands, and different
options
depending on the subcommand:
[verse]
-'git reflog expire' [--dry-run] [--stale-fix] [--verbose]
- [--expire=time] [--expire-unreachable=time] [--all] refs...
-'git reflog delete' ref@\{specifier\}...
'git reflog' ['show'] [log-options] [ref]
+'git reflog expire' [--expire=time] [--expire-unreachable=time]
+ [--rewrite] [--updateref] [--stale-fix]
+ [--dry-run] [--verbose] [--all | refs...]
+'git reflog delete' [--rewrite] [--updateref]
+ [--dry-run] [--verbose] ref@\{specifier\}...
+
+Reference logs, or reflogs, record when the tips of branches and
+other references were updated in the local repository. Reflogs are
+useful in various Git commands, to specify the old value of a
+reference. For example, `HEAD@{2}` means where HEAD used to be two
+moves ago, `master@{one.week.ago}` means where master used to point
+to one week ago, and so on. See linkgit:gitrevisions[7] for more
+details.
+
+This command manages the information recorded in the reflogs.
+
+The show subcommand (which is also the default, in the absence of
+any subcommands) shows the log of the reference provided in the
+command-line (or `HEAD`, by default). The reflog covers all recent
+actions, and in addition the `HEAD` reflog records branch switching.
+`git reflog show` is an alias for `git log -g --abbrev-commit
+--pretty=oneline`; see linkgit:git-log[1] for more information.
+
+The expire subcommand prunes older reflog entries. Entries older
+than `expire` time, or entries older than `expire-unreachable` time
+and not reachable from the current tip, are removed from the reflog.
+This is typically not used directly by end users -- instead, see
+linkgit:git-gc[1].
+
+The delete subcommand deletes single entries from the reflog. Its
+argument must be an _exact_ entry (e.g. `git reflog delete
+master@{2}`).
-Reflog is a mechanism to record when the tip of branches are
-updated. This command is to manage the information recorded in it.
-The subcommand expire is used to prune older reflog entries.
-Entries older than `expire` time, or entries older than
-`expire-unreachable` time and not reachable from the current
-tip, are removed from the reflog. This is typically not used
-directly by the end users -- instead, see linkgit:git-gc[1].
-
-The subcommand show (which is also the default, in the absence of any
-subcommands) will take all the normal log options, and show the log of
-the reference provided in the command-line (or `HEAD`, by default).
-The reflog will cover all recent actions (HEAD reflog records branch switching
-as well). It is an alias for `git log -g --abbrev-commit --pretty=oneline`;
-see linkgit:git-log[1].
+OPTIONS
+---
-The reflog is useful in various Git commands, to specify the old value
-of a reference. For example, `HEAD@{2}` means where HEAD used to be
-two moves ago, `master@{one.week.ago}` means where master used to
-point to one week ago, and so on. See linkgit:gitrevisions[7] for
-more details.
+Options for `show`
+~~
-To delete single entries from the reflog, use the subcommand delete
-and specify the _exact_ entry (e.g. `git reflog delete master@{2}`).
+`git reflog show` accepts any of the options accepted by `git log`.
-OPTIONS
+Options for `expire` and/or `delete`
+
---stale-fix::
- This revamps the logic -- the definition of broken commit
- becomes: a commit that is not reachable from any of the refs and
- there is a missing object among the commit, tree, or blob
- objects reachable from it that is not reachable from any of the
- refs.
-+
-This computation involves traversing all the reachable objects, i.e. it
-has the same cost as 'git prune'. Fortunately, once this is run, we
-should not have to ever worry about missing objects, because the current
-prune and pack-objects know about reflogs and protect objects referred by
-them.
+--all::
+ (For the `expire` command only.) Process the reflogs of all
+ references.
--expire=time::
- Entries older than this time are pruned. Without the
- option it is taken from configuration `gc.reflogExpire`,
-
[PATCH v2 0/7] Fix some problems with reflog expiration
This is v2 of the patch series. Thanks to Eric Sunshine, Stefan Beller, Peff, and Junio for their comments about v1 [1]. The two main changes since v1: * Don't change the locking policy for changing symbolic references. Even though the existing policy is partly broken, the change proposed in v1 would have introduced an incompatibility with older versions of Git and with libgit2 and possibly other Git clients. I will try to implement the transition plan described in [2], but I will do it in a separate patch series. * I rewrote the git reflog documentation more completely, following Junio's suggestion. Other changes since v1: * Rebased onto a more recent version of upstream master (because master now includes mh/reflog-expire and sb/atomic-push). The rebase was conflict-free. * Tweaked some commit messages and added some Reviewed-by lines. * Appended a patch by Stefan Beller to delete the force_write member of struct ref_lock. [1] http://thread.gmane.org/gmane.comp.version-control.git/263552 [2] http://article.gmane.org/gmane.comp.version-control.git/263811 Michael Haggerty (6): write_ref_sha1(): remove check for lock == NULL write_ref_sha1(): Move write elision test to callers lock_ref_sha1_basic(): do not set force_write for missing references reflog: improve and update documentation reflog_expire(): ignore --updateref for symbolic references reflog_expire(): never update a reference to null_sha1 Stefan Beller (1): struct ref_lock: delete the force_write member Documentation/git-reflog.txt | 139 +-- builtin/reflog.c | 4 +- refs.c | 63 +++- 3 files changed, 117 insertions(+), 89 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Sun, Mar 01, 2015 at 11:06:21PM -, Philip Oakley wrote:
OK, maybe not exactly about protocol, but a possible option would be the
ability to send the data as a bundle or multi-bundles; Or perhasps as an
archive, zip, or tar.
Data can then be exchanged across an airgap or pigeon mail. The airgap
scenario is likely a real case that's not directly prominent at the
moment, just because it's not tha direct.
There has been discussion about servers having bundles available for
clones, but with a multi-bundle, one could package up a large bundle
(months) and an increment (weeks, and then days), before an final easy
to pack last few hours. That would be a server work trade-off, and
support a CDN view if needed.
If such an approach was reasonable would the protocol support it? etc.
It came up several times. Many people are in favor of it. Some
references..
http://thread.gmane.org/gmane.comp.version-control.git/264305/focus=264565
http://thread.gmane.org/gmane.comp.version-control.git/263898/focus=263928
http://thread.gmane.org/gmane.comp.version-control.git/263898/focus=264000
http://thread.gmane.org/gmane.comp.version-control.git/238472/focus=238844
This is what I got so far. I think the hard part is how to let
projects control this in a clean and flexible way. Not written in the
patch, but I'm thinking maybe we can allow hooking a remote helper in
standard git://, ssh://, http://... That would give total control to
projects.
-- 8 --
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/technical/protocol-capabilities.txt
index ecb0efd..2b99464 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -260,3 +260,34 @@ v2
'git-upload-pack' and 'git-receive-pack' may advertise this capability
if the server supports 'git-upload-pack-2' and 'git-receive-pack-2'
respectively.
+
+redirect
+
+
+This capability is applicable for upload-pack and upload-pack-v2
+only. When the client requests this capability it must specify
+supported transport protocol separated by colon,
+e.g. redirect=http:ftp:ssh:torrent.
+
+Instead of sending a packfile data to the client, the server may send
+4-byte signature { 'L', 'I', 'N', 'K' } followed by a NUL-terminated
+URLs, each one pointing to a bundle. This fake pack ends with an empty
+string.
+
+The bundle does not have to contain all refs requested by the
+client. Different bundles from different URLs could have different
+content. The client must follow one of the links to get a bundle.
+The server must not send URL in a protocol that the client does not
+support.
+
+FIXME: do we keep current connection alive until the bundle is
+downloaded and get a normal pack, or let the client initiate a new
+connection? Or perhaps if the client fails to get the bundle for
+whatever reason, it could send NAK to the server and the server
+sends normal packfile data.
+
+FIXME: how do we implement this exactly? The decision to redirect
+should probably be delegated to some hook. Maybe sending all want
+lines to the script is enough.. Sending have lines is more difficult
+because the server decides when to stop receiving them. That decision
+must be moved to the hook...
-- 8 --
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Tweaking the gitk window title.
On 15-01-06 12:51 PM, Marc Branchaud wrote: The first patch simply changes the title from gitk: dir to dir - gitk, which is the title layout used by most of the applications on my Kubuntu box. The second patch is the one that I'm more keen to see accepted. It relies on the first only in that it follows the new title layout. Ping? M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Move commits not in origin to a branch
On Mon, Mar 2, 2015 at 9:54 AM, Michael J Gruber g...@drmicha.warpmail.net wrote: shawn wilson venit, vidit, dixit 02.03.2015 14:25: How do I move commits I haven't pushed into a new branch? % git log origin..master --pretty=format:'%h' f7d3a19 1f186c9 66d99f6 Which I'd like to be in a new branch. Do you want them to be on the new branch as they are, i.e. as commits built on top of master? Then git branch mybranch master Oh cool, I think that's what I wanted. I didn't realize it was that easy - I said screw it and went and pushed them, but... for next time (or I'll stop being stupid and work in a branch from now on). Thanks -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hash-object: add -v/--verbose option
Alexander Kuleshov venit, vidit, dixit 02.03.2015 14:55:
This patch provides ability to pass -v/--verbose option to the
git hash-object command. hash-object will print not only hash,
but also file path of a file from what hash was calculated.
It can be useful in scripting, especially with --stdin-paths
option.
Hmmm. You mean it's useful because -v would dupe the input stream as
one column in the output stream in this case? Hmmm.
For example:
$ git hash-object -v test
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 test
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
builtin/hash-object.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/builtin/hash-object.c b/builtin/hash-object.c
index 207b90c..97961ee 100644
--- a/builtin/hash-object.c
+++ b/builtin/hash-object.c
@@ -10,6 +10,8 @@
#include parse-options.h
#include exec_cmd.h
+static int verbose;
+
Other flags are passed down as argument to hash_fd(). Is there a reason
this one has to be a (file) global?
/*
* This is to create corrupt objects for debugging and as such it
* needs to bypass the data conversion performed by, and the type
@@ -43,7 +45,10 @@ static void hash_fd(int fd, const char *type, const char
*path, unsigned flags,
die((flags HASH_WRITE_OBJECT)
? Unable to add %s to database
: Unable to hash %s, path);
- printf(%s\n, sha1_to_hex(sha1));
+ if (verbose)
+ printf(%s\t%s\n, sha1_to_hex(sha1), path);
+ else
+ printf(%s\n, sha1_to_hex(sha1));
maybe_flush_or_die(stdout, hash to stdout);
}
@@ -79,7 +84,7 @@ static void hash_stdin_paths(const char *type, int
no_filters, unsigned flags,
int cmd_hash_object(int argc, const char **argv, const char *prefix)
{
static const char * const hash_object_usage[] = {
- N_(git hash-object [-t type] [-w] [--path=file |
--no-filters] [--stdin] [--] file...),
+ N_(git hash-object [-t type] [-w] [-v] [--path=file |
--no-filters] [--stdin] [--] file...),
N_(git hash-object --stdin-paths list-of-paths),
NULL
};
@@ -99,6 +104,7 @@ int cmd_hash_object(int argc, const char **argv, const
char *prefix)
OPT_BOOL( 0 , no-filters, no_filters, N_(store file as is
without filters)),
OPT_BOOL( 0, literally, literally, N_(just hash any random
garbage to create corrupt objects for debugging Git)),
OPT_STRING( 0 , path, vpath, N_(file), N_(process file as
it were from this path)),
+ OPT__VERBOSE(verbose, N_(show hash and file path)),
OPT_END()
};
int i;
@@ -108,6 +114,11 @@ int cmd_hash_object(int argc, const char **argv, const
char *prefix)
argc = parse_options(argc, argv, NULL, hash_object_options,
hash_object_usage, 0);
+ if (verbose literally)
+ errstr = Can't use --verbose with --literally;
+ else if (verbose hashstdin)
+ errstr = Can't use --verbose with --stdin;
+
I fail to see why those should be incompatible. All these modes just use
hash_fd() which you patch to show the 2nd column with -v.
[And we would write here to be safe and make the intention clearer.]
if (flags HASH_WRITE_OBJECT) {
prefix = setup_git_directory();
prefix_length = prefix ? strlen(prefix) : 0;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: weaning distributions off tarballs: extended verification of git tags
On Sat, Feb 28, 2015, at 03:34 PM, Morten Welinder wrote: Is there a point to including a different checksum inside a git tag? If someone can break the SHA-1 checksum in the repository then the recorded SHA-256 checksum can be changed. In other words, wouldn't you be just as well off handing someone a SHA-1 commit id? The issue is more about what the checksum covers, as well as its strength. Git uses a hash tree, which means that an attacker only has to find a collision for *one* of the objects, and the signature is still valid. And that collision is valid for *every* commit that contains that object. This topic has been covered elsewhere pretty extensively, here's a link: https://www.whonix.org/forum/index.php/topic,538.msg4278.html#msg4278 Now I think rough consensus is still that git is secure or secure enough - but with this proposal I'm just trying to overcome the remaining conservatism. (Also, while those discussions were focusing on corrupting an existing repository, the attack model of MITM also exists, and there you don't have to worry about deltas, particularly if the attacker's goal is to get a downstream to do a build and thus execute their hostile code inside the downstream network). It's really not that expensive to do once per release, basically free for small repositories, and for a large one like the Linux kernel: $ cd ~/src/linux $ git describe v3.19-7478-g796e1c5 $ time /bin/sh -c 'git archive --format=tar HEAD|sha256sum' 4a5c5826cea188abd52fa50c663d17ebe1dfe531109fed4ddbd765a856f1966e - real0m3.772s user0m6.132s sys 0m0.279s $ With this proposal, the checksum covers an entire stream of objects for a given commit at once; making it significantly harder to find a collision. At least as good as checksummed tarballs, and arguably better since it's pre-compression. So to implement this, perhaps something like: $ git archive --format=raw as a base primitive, and: $ git tag --archive-raw-checksum=SHA256 -s -m ... ? git fsck could also learn to optionally use this. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: weaning distributions off tarballs: extended verification of git tags
I support this proposal, as someone who no longer releases tarballs of my software, when I can possibly avoid it. I have worried about signed tags / commits only being a SHA1 break away from useless. As to the implementation, checksumming the collection of raw objects is certainly superior to tar. Colin had suggested sorting the objects by checksum, but I don't think that is necessary. Just stream the commit object, then its tree object, followed by the content of each object listed in the tree, recursing into subtrees as necessary. That will be a stable stream for a given commit, or tree. -- see shy jo signature.asc Description: Digital signature
Re: [PATCH v6 0/4] commit: Add commit.verbose configuration
Hey Torstein. I'd planned to come back with a heavily simplified version of this that didn't include any of the related changes, just the feature and the new test, since a lot of that seemed controversial. That said, I haven't done so and you're welcome to take a whack at this feedback if you'd like. Caleb Thompson On Fri, Feb 27, 2015 at 10:13:36AM +0100, Torstein Hegge wrote: On Tue, Jun 17, 2014 at 14:38:56 -0500, Caleb Thompson wrote: This patch allows people to set commit.verbose to implicitly send --verbose to git-commit. It introduces several cleanup patches to t/t7505-commit-verbose.sh to bring it closer to the current state of the tests as they have been explained to me, then adds the verbose config and --no-verbose flag. Since the last version of this patch (http://thread.gmane.org/gmane.comp.version-control.git/251486), there have been a couple of commit message clarifications and the body of the check-for-no-diff script in the last patch was changed to simply negate check-for-diff. Hi Caleb, Do you intend to work further on this topic? I have been using a similar (but less polished) patch, and would like to see this included in Git. If you don't have time to work on it, I can incorporate the comments on this version and submit a v7. Torstein pgpHUN8rOy5a8.pgp Description: PGP signature
Re: Git Scaling: What factors most affect Git performance for a large repo?
On Tue, Feb 24, 2015 at 1:44 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 02/20/2015 03:25 PM, Ævar Arnfjörð Bjarmason wrote:
On Fri, Feb 20, 2015 at 1:09 PM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
On Fri, Feb 20, 2015 at 1:04 AM, Duy Nguyen pclo...@gmail.com wrote:
On Fri, Feb 20, 2015 at 6:29 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
Anecdotally I work on a repo at work (where I'm mostly the Git guy)
that's:
* Around 500k commits
* Around 100k tags
* Around 5k branches
* Around 500 commits/day, almost entirely to the same branch
* 1.5 GB .git checkout.
* Mostly text source, but some binaries (we're trying to cut down[1] on
those)
Would be nice if you could make an anonymized version of this repo
public. Working on a real large repo is better than an artificial
one.
Yeah, I'll try to do that.
tl;dr: After some more testing it turns out the performance issues we
have are almost entirely due to the number of refs. Some of these I
knew about and were obvious (e..g. git pull), but some aren't so
obvious (why does git log without --all slow down as a function of
the overall number of refs?).
I'm assuming that you pack your references periodically. (If not, you
should, because reading lots of loose references is very expensive for
the commands that need to iterate over all references!)
Yes, as mentioned in another reply of mine, like this:
git --git-dir={} gc
git --git-dir={} pack-refs --all --prune
git --git-dir={} repack -Ad --window=250 --depth=100
--write-bitmap-index --pack-kept-objects
On the other hand, packed refs also have a downside, namely that
whenever even a single packed reference has to be read, the whole
packed-refs file has to be read and parsed. One way that this can bite
you, even with innocuous-seeming commands, is if you haven't disabled
the use of replace references (i.e., using git --no-replace-objects
CMD or GIT_NO_REPLACE_OBJECTS). In that case, almost any Git command
has to read the refs/replace/* namespace, which, in turn, forces the
whole packed-refs file to be read and parsed. This can take a
significant amount of time if you have a very large number of references.
Interesting. I tried the rough benchmarks I posted above with
GIT_NO_REPLACE_OBJECTS=1 and couldn't see any differences, although as
mentioned in another reply --no-decorate had a big effect on git-log.
So try your experiments with replace references disabled. If that helps,
consider disabling them on your server if you don't need them.
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Add hint interactive cleaning
Jean-Noel Avila jn.av...@free.fr writes:
For translators, specify that a y/N reply is needed.
Signed-off-by: Jean-Noel Avila jn.av...@free.fr
---
builtin/clean.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 7e7fdcf..98c103f 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -754,7 +754,8 @@ static int ask_each_cmd(void)
/* Ctrl-D should stop removing files */
if (!eof) {
qname = quote_path_relative(item-string, NULL, buf);
- printf(_(remove %s? ), qname);
+ /* TRANSLATORS: Make sure to keep [y/N] as is */
+ printf(_(Remove %s [y/N]? ), qname);
if (strbuf_getline(confirm, stdin, '\n') != EOF) {
strbuf_trim(confirm);
} else {
Thanks. All other interactive prompts from this command
(i.e. menu_opts.prompt) seem to capitalize their first word, so
upcasing this message is a good change, too.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: weaning distributions off tarballs: extended verification of git tags
On 03/02/2015 10:12 AM, Joey Hess wrote: I support this proposal, as someone who no longer releases tarballs of my software, when I can possibly avoid it. I have worried about signed tags / commits only being a SHA1 break away from useless. As to the implementation, checksumming the collection of raw objects is certainly superior to tar. Colin had suggested sorting the objects by checksum, but I don't think that is necessary. Just stream the commit object, then its tree object, followed by the content of each object listed in the tree, recursing into subtrees as necessary. That will be a stable stream for a given commit, or tree. I would really just do it exactly the same way that git does: checksum the objects including their headers with the new hashes. I have a hazy recollection of what it would take to replace SHA-1 in git with something else; it should be possible (though tricky) to do it lazily, where a tree entry has bits (eg, some of the currently unused file mode bits) to denotes which hash algorithm is in use for the entry. However I don't think that got past idea stage... Sam -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Scaling: What factors most affect Git performance for a large repo?
On Fri, Feb 20, 2015 at 10:04 PM, Junio C Hamano gits...@pobox.com wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com writes: I actually ran this a few times while testing it, so this is a before and after on a hot cache of linux.git with 406 tags v.s. ~140k. I ran the gc + repack + bitmaps for both repos noted in an earlier reply of mine, and took the fastest run out of 3: $ time (git log master -100 /dev/null) Before: real0m0.021s After: real0m2.929s Do you force --decorate with some config? Or do you see similar performance difference with git rev-parse master, too? Yes, I had log.decorate=short set in my config. With --no-decorate: $ time (git log --no-decorate -100 /dev/null) # Before: real0m0.010s # After: real0m0.065s $ time (git status /dev/null) # Around 150ms, no noticeable difference This is understandable, as it will not look at any ref other than HEAD. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t5516-fetch-push: Correct misspelled pushInsteadOf
Anders Kaseorg ande...@mit.edu writes: Signed-off-by: Anders Kaseorg ande...@mit.edu --- t/t5516-fetch-push.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 85c7fec..594d7a6 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -238,7 +238,7 @@ test_expect_success 'push with pushInsteadOf' ' test_expect_success 'push with pushInsteadOf and explicit pushurl (pushInsteadOf should not rewrite)' ' mk_empty testrepo test_config url.trash2/.pushInsteadOf testrepo/ - test_config url.trash3/.pusnInsteadOf trash/wrong + test_config url.trash3/.pushInsteadOf trash/wrong test_config remote.r.url trash/wrong test_config remote.r.pushurl testrepo/ git push r refs/heads/master:refs/remotes/origin/master Interesting. Now an obvious and natural question after seeing this change is how the original test passed with misspelled configuration. Is a test that pushes into trash/wrong checking the right outcome? If the reason why the existing tests passed without this patch is because they do not test the right thing, then shouldn't they be corrected together with the above fix? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Use unsigned char to squash compiler warnings
Sun Studio on Solaris issues warnings about improper initialization
values being used when defining tolower_trans_tbl in
ctype.c. tolower_trans_tbl is defined as char[], which studio's
compiler defaults to signed char[] due to the Solaris ABI. To resolve
this, instead of supplying -xchar or another option at build time,
declare tolower_trans_tbl as unsigned char. Update all appropriate
references to the new type.
Signed-off-by: Ben Walton bdwal...@gmail.com
---
ctype.c | 2 +-
git-compat-util.h | 2 +-
kwset.c | 8
kwset.h | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/ctype.c b/ctype.c
index 0bfebb4..fc0225c 100644
--- a/ctype.c
+++ b/ctype.c
@@ -30,7 +30,7 @@ const unsigned char sane_ctype[256] = {
};
/* For case-insensitive kwset */
-const char tolower_trans_tbl[256] = {
+const unsigned char tolower_trans_tbl[256] = {
0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
diff --git a/git-compat-util.h b/git-compat-util.h
index 3455c5e..5eae2b2 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -694,7 +694,7 @@ static inline size_t xsize_t(off_t len)
}
/* in ctype.c, for kwset users */
-extern const char tolower_trans_tbl[256];
+extern const unsigned char tolower_trans_tbl[256];
/* Sane ctype - no locale, and works with signed chars */
#undef isascii
diff --git a/kwset.c b/kwset.c
index a0f49b3..e6236a0 100644
--- a/kwset.c
+++ b/kwset.c
@@ -80,13 +80,13 @@ struct kwset
struct trie *next[NCHAR];/* Table of children of the root. */
char *target;/* Target string if there's only one. */
int mind2; /* Used in Boyer-Moore search for one string. */
- char const *trans; /* Character translation table. */
+ unsigned char const *trans; /* Character translation table. */
};
/* Allocate and initialize a keyword set object, returning an opaque
pointer to it. Return NULL if memory is not available. */
kwset_t
-kwsalloc (char const *trans)
+kwsalloc (unsigned char const *trans)
{
struct kwset *kwset;
@@ -381,7 +381,7 @@ kwsprep (kwset_t kws)
register struct kwset *kwset;
register int i;
register struct trie *curr;
- register char const *trans;
+ register unsigned char const *trans;
unsigned char delta[NCHAR];
kwset = (struct kwset *) kws;
@@ -590,7 +590,7 @@ cwexec (kwset_t kws, char const *text, size_t len, struct
kwsmatch *kwsmatch)
register int d;
register char const *end, *qlim;
register struct tree const *tree;
- register char const *trans;
+ register unsigned char const *trans;
accept = NULL;
diff --git a/kwset.h b/kwset.h
index a21b2ea..61a134f 100644
--- a/kwset.h
+++ b/kwset.h
@@ -39,7 +39,7 @@ typedef struct kwset_t* kwset_t;
if enough memory cannot be obtained. The argument if non-NULL
specifies a table of character translations to be applied to all
pattern and search text. */
-extern kwset_t kwsalloc(char const *);
+extern kwset_t kwsalloc(unsigned char const *);
/* Incrementally extend the keyword set to include the given string.
Return NULL for success, or an error message. Remember an index
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: weaning distributions off tarballs: extended verification of git tags
Sam Vilain s...@vilain.net writes: As to the implementation, checksumming the collection of raw objects is certainly superior to tar. Colin had suggested sorting the objects by checksum, but I don't think that is necessary. Just stream the commit object, then its tree object, followed by the content of each object listed in the tree, recursing into subtrees as necessary. That will be a stable stream for a given commit, or tree. I would really just do it exactly the same way that git does: checksum the objects including their headers with the new hashes. I tend to agree that it is a good idea. I also suspect that would make the implementation simpler by allowing it to share more code, but I didn't look into it too deeply. I have a hazy recollection of what it would take to replace SHA-1 in git with something else; it should be possible (though tricky) to do it lazily, where a tree entry has bits (eg, some of the currently unused file mode bits) to denotes which hash algorithm is in use for the entry. However I don't think that got past idea stage... I think one reason why it didn't was because it would not work well. That bit that tells this is a new object or old would mean that a single tree can have many different object names, depending on which of its component entries are using that bit and which aren't. There goes the we know two trees with the same object name are identical without recursing into them optimization out the window. Also it would make it impossible to do what you suggest to Joey to do, i.e. exactly the same way that git does, once you start saying that a tree object can be encoded in more than one different ways, wouldn't it? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git is accepted for Google Summer of Code 2015.
On Mon, Mar 02, 2015 at 09:05:50PM +0100, Matthieu Moy wrote: Everything is in the title :-). As a reminder, we have a list of ideas here: http://git.github.io/SoC-2015-Ideas.html As another reminder, we're short of potential mentors, so if you're willing to mentor a project this summer and you did not already say so, then please speak up. Thanks. Student applications start on March 16th, but students may be looking at our ideas page before then. So if you have been considering adding entries to the ideas list, please do it soon. If you are a potential mentor and would like to help evaluate applications, please create a profile at: https://google-melange.com and connect with the Git organization. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git is accepted for Google Summer of Code 2015.
Everything is in the title :-). As a reminder, we have a list of ideas here: http://git.github.io/SoC-2015-Ideas.html As another reminder, we're short of potential mentors, so if you're willing to mentor a project this summer and you did not already say so, then please speak up. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git is accepted for Google Summer of Code 2015.
On 03/03/2015 01:35 AM, Matthieu Moy wrote: Everything is in the title :-). As a reminder, we have a list of ideas here: http://git.github.io/SoC-2015-Ideas.html As another reminder, we're short of potential mentors, so if you're willing to mentor a project this summer and you did not already say so, then please speak up. As a student looking forward to GSOC, this is brilliant news. Was sitting with my fingers crossed. Looking forward to apply. @Matthieu sorry for replying only to you. Regards -Karthik -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Scaling: What factors most affect Git performance for a large repo?
Ævar Arnfjörð Bjarmason ava...@gmail.com writes: On Fri, Feb 20, 2015 at 10:04 PM, Junio C Hamano gits...@pobox.com wrote: Ævar Arnfjörð Bjarmason ava...@gmail.com writes: I actually ran this a few times while testing it, so this is a before and after on a hot cache of linux.git with 406 tags v.s. ~140k. I ran the gc + repack + bitmaps for both repos noted in an earlier reply of mine, and took the fastest run out of 3: $ time (git log master -100 /dev/null) Before: real0m0.021s After: real0m2.929s Do you force --decorate with some config? Or do you see similar performance difference with git rev-parse master, too? Yes, I had log.decorate=short set in my config. With --no-decorate: $ time (git log --no-decorate -100 /dev/null) # Before: real0m0.010s # After: real0m0.065s There you have the answer to your earlier question, then, which was: tl;dr: After some more testing it turns out the performance issues we have are almost entirely due to the number of refs. Some of these I knew about and were obvious (e..g. git pull), but some aren't so obvious (why does git log without --all slow down as a function of the overall number of refs?). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
